> > > 1) Data storage

...

> CCH also tends to preserve as much pages in RAM (okay, not in RAM, but in
> virtual memory) as possible :-) It just flushes them too often from the temp
> tables POV. And I'm not sure that temp page I/O should follow the careful
> writes strategy. I have no other problems with CCH. But I tend to think that
> in this case CCH should have two independent page pools (for generic pages
> and temp ones), because I'd expect these two buffers to be configured
> independently.

Now i understand and agreed ;)

So - we need more lightweight and simple TempCacheManager. Ideally
it can be inherited from abstract base CacheManager class
...

> > > 2) Data visibility
> > >
> > > I see two ways to allow per-session data visibility:
> > >
> > > 1) One TempSpace instance per attachment. It means that different
> > > attachments work with different temporary files.
> >
> > In fact we can imagine 4 tempspace scope :
> > a) one per temporary table instance
> > b) one per attachment
> > c) one per database
> > d) one per engine
> >
> > Option d) seems to be not practically useful, at least with
> > current engine implementation
> >
> > Option c) seems to be not very friendly to classic server, but
> > allows to avoid frequent file creation\deletion
> >
> > Option a) is most granulated but add most overhead from file
> > system
> >
> > So, i prefer option b) for CS and c) for SS, or one per engine
> > process.
>
> I'd stick to (b) for both architectures, just to unify the code. Note that
> (b) doesn't require anything else to support attachment-level visibility per
> se. No hidden columns, no transaction SBMs...

Page space doesn't require nor hidden columns, nor trans SBM's. But
it requires page allocation policy (each page must be "owned" by exactly one
instance of temp table data\index). Since each instance of temp table has its
own primary PIP and index root page then such allocation policy allows us to
have appropriate visibility of data (for any kind of temp tables) and instant
clean
up after use.

Option a) needs no data page management, it simple create new file for temp
table data and more files for its indeces. All other options require to track
empty
pages list and to provide above allocation policy.

...

> Your suggestion requires to collect txn id's on a per attachment basis. How
> big will be such a SBM in the case of long 24x7 attachments and PRESERVE
> ROWS option?

It's can be big, agreed. But i believe that we'll choose "page space"
implementation ;-)


Regards,
Vlad