|Subject||Re: [Firebird-Architect] RFC: Proposal for the implementation of Temporary Tables.|
> I would simply add ATTACHMENT_ID system column (probably withWhy we need extra info when we already has it ? Each record version
> appropriate index) to tables declared as temporary and taught optimizer
> to filter out rows which should not be visible by current attachment. At
> startup engine may perform simple clean up process (it doesn't require
> exclusive access to database and thus may be performed in background)
> which can delete rows belonging to old attachments.
alredy has transaction number. We can track sbm of all attachmnent
transactions to distinguish records that our attachtment\transaction
can see. We can merge this sbm's to global database-level sbm after
attachment end to garbage collect unneeded records. Only minus i see - is
wrong index selectivity
> It looks like such implementation may be done in a few days and doesn'tExactly. I think my offer even easeer ;)
> require big modifications of the engine.
But i prefer temporary page space for temp data. It's much efficient
especially at cleanup time - we just drop temp table instance data and index
pages - no headache with garbage collection at all.
Don't forget about readonly database. If they could work with temporary data
(which live not in db file) it can be beautiful, imho