| Subject | Re: [Firebird-Architect] RFC: Proposal for the implementation of Temporary Tables. |
|---|---|
| Author | Jim Starkey |
| Post date | 2004-11-24T02:35:11Z |
Ann W. Harrison wrote:
respects like an ordinary table, but each row is tagged with a
arguablely invisible column containing the session id of the owner, and
the compiler generates a filter so each session sees only the records
created by that session.
In the other corner, from the fertile brain of Ms. Harrison, has a
separate page number space, residing in a per-session temporary table,
for each's session's temporary tables. The page number space, at the
end of the session, sublimates into the ether leaving no more than a
fond memory of the temporary table(s).
Nickolay's proposal is elegantly simple, but requires a cleanup
mechanism to delete a session's detrious on session exit. The cleanup
mechanism, among other things, must remove cruft from any indexes
created for the temporary table. If the temporary table is large or,
perhaps, very large, this is an expensive operation. Ms. Harrison's
proposal, on the other paw, requires no cleanup other than closing a
file declared to the OS as temporary.
Ms. Harrison's proposal has a serious drawback, however. Independent
page spaces are simple to implement (Netfrastructure, you guessed it,
uses them to implement blob respositories), but are an attractive
nuisance. I shudder to think what the creative Firebird developers
might implement on top of a general multi-file space.
Nickolay's proposal is cute and is more likely to keep the project out
of trouble. Ann's has, in my most objective, humble opinion, a bit more
depth.
But the debate is young. Let's bash it around some more.
>Ah. Nickolay just called and explained what I had missed. The ideaNickolay's idea is beastly clever. A temporary table is in most
>is that a temporary table has one more column than its definition
>includes. That column contains the attachment id of the transaction
>that stored the record. Attachment ids are handed out like transaction
>ids, through the header page, but without the record-keeping that
>transactions require.
>
>The temporary table also has a special system created index on
>the attachment id. If it has a primary key or unique index, the
>attachment id becomes a segment of that key.
>
>
>
respects like an ordinary table, but each row is tagged with a
arguablely invisible column containing the session id of the owner, and
the compiler generates a filter so each session sees only the records
created by that session.
In the other corner, from the fertile brain of Ms. Harrison, has a
separate page number space, residing in a per-session temporary table,
for each's session's temporary tables. The page number space, at the
end of the session, sublimates into the ether leaving no more than a
fond memory of the temporary table(s).
Nickolay's proposal is elegantly simple, but requires a cleanup
mechanism to delete a session's detrious on session exit. The cleanup
mechanism, among other things, must remove cruft from any indexes
created for the temporary table. If the temporary table is large or,
perhaps, very large, this is an expensive operation. Ms. Harrison's
proposal, on the other paw, requires no cleanup other than closing a
file declared to the OS as temporary.
Ms. Harrison's proposal has a serious drawback, however. Independent
page spaces are simple to implement (Netfrastructure, you guessed it,
uses them to implement blob respositories), but are an attractive
nuisance. I shudder to think what the creative Firebird developers
might implement on top of a general multi-file space.
Nickolay's proposal is cute and is more likely to keep the project out
of trouble. Ann's has, in my most objective, humble opinion, a bit more
depth.
But the debate is young. Let's bash it around some more.