"Samofatov, Nickolay" <nickolay@...> wrote:

>
> They are not going to be slower than normal tables and we'll have
> motivation to optimize normal access paths, not one special case of
> temporary tables.

If TTs would have any intention to be slower, then I'd drop the proposed
implementation completely. I agree that we should optimize the existing
access paths, but we don't need any extra motivation for this, just some
available time. IMO, TTs should be _designed_ properly to provide maximum
performance and effective cleanup abilities.

> BTW, note that due to multiple transactions allowed for one connection
> update conflicts are possible for temporary tables and the most of the
> versioning, conflict resolution and GC logic of CCH, DPM and VIO modules
> still applies.

Agreed. What I have in mind is another PIO layer than the current one. VIO,
CCH and DPM still work, but I/O is redirected.

> Do what's asked. Delete rows from temp table in DFW handler at commit
> time.

I'm afraid, a startup recovery is also required in this case.


Dmitry