"Jim Starkey" <jas@...> wrote:

>
> But the debate is young. Let's bash it around some more.

We have two issue to solve:

1) Data storage

Temporary data by its definition doesn't require any recovery policies. If
it disappears because of a hardware/software failure, it means no actual
data loss. Temporary data is also expected to have shorter life-time than
persistent data and to provide faster access. All this means that it should
be preserved in memory as much/long as possible and flushed on disk only if
there's not enough buffers to keep all temp data. Hence I consider CCH a
wrong module to handle temporary I/O. The required allocation/caching
algorithm is provided by the SortMem class, which can be extended to produce
a generic multi-purpose temp space manager. Perhaps, CCH could be also
enhanced to provide different allocation/caching patterns and in this case
it could be used for our purposes, although this doesn't look like an easy
work. But, regardless of the CCH usage, I consider the whole idea of storing
temp data inside the database via the existing PIO wrong, as it's just
provides the required semantics without any performance and/or cleanup
benefits. If the proper solution requires a separate page numbers space, so
be it.

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.
2) Nickolay's ATTACHMENT_ID idea to add a hidden column to both data and
indices and teach the optimizer to filter the rows.

Personally, I don't have any strong preference, but so far Nickolay's idea
looks nice enough to agree on.


Dmitry