Subject | RE: [Firebird-Architect] RFC: Proposal for the implementation of Temporary Tables. |
---|---|
Author | Ann W. Harrison |
Post date | 2004-11-24T00:22:26Z |
At 05:20 PM 11/23/2004, Samofatov, Nickolay wrote:
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.
Regards,
Ann
>Hi, Arno!Ah. Nickolay just called and explained what I had missed. The idea
>
> > Can we rely on the ATTACHMENT_ID after a server crash. Isn't
> > there a chance the same (or lower) one is choosen?
>
>Attachment ID is generated from header page the same way as transaction
>ID.
>Modified header page doesn't stay in cache for too long, it should get
>written to disk before any data page is written for attachment due to
>transaction cleanup reasons.
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.
Regards,
Ann