Re: [HACKERS] TIME QUALIFICATION

Jan Wieck wrote:
>
> 1. Add a command counter field to the SnapshotData struct.
> The command counter in the snapshot is that used in heap
> scanning instead of the global command counter.

Ok. For the SnapshotNow and SnapshotSelf, used in catalog scans,
global command counter will be used, as now.

>
> 3. Add QueryID fields to the querytree and rangetable entry
> structures.
>
> 3. Create a new global memory context "Snapshot". The
> lifetime of this memory context is one transaction (at
> every transaction end/abort an AllocSetReset() is issued
> on it).
>
> 4. Create a new internal counter, the QueryCounter. The
> counter is also reset between transactions. At parse
> time, the query and all it's initial RTE's get the same,
> new QueryCounter. When the rule system generates new
> queries, only the RTE's coming with the rule (except NEW
> and OLD) get the QueryId of the new query. All others
> remain as they are. For every QueryId an entry in the
> "Snapshot" context is created, which holds the number of
> RTE's using this snapshot. RTE's in different queries
> (copied by rules) count multipe.
>
> 5. On ExecutorStart(), the actual QuerySnapshot data is
> copied into the "Snapshot" context and held in the array
> of Snapshot pointers. The CommandId of the snapshot it
> set to the current command ID.
>
> 6. The executor uses the saved snapshots on
> heap_beginscan(). The RTE's QueryID tells, which of the
> snapshots to use. This way, every Scan node in a plan can
> have a different snapshot and command ID. So we have
> different visibilities in one query execution.
>
> 7. On ExecutorEnd() the snapshot's reference counts is
> decremented and unused snapshot's thrown away.

It seems too complex to me. I again propose to use refcount
inside snapshot itself to prevent free-ing of snapshots.
Benefits: no copying in Executor, no QueryId --> Snapshot
lookup. Just add pointer to RTE. Parser will put NULL there:
as flag that current snapshot has to be used. ExecutorStart
and deffered rules will increment refcount of current snapshot.
Deffered rules will also set snapshot pointers of appropriate
RTEs (to the current snapshot).

> In v6.6 we could also implement the suggested named
> snapshots. This only requires that a query Id can be
> associated with a name. The CREATE SNAPSHOT utilities query
> Id is that of the snapshot and during parse this Id is placed
^^^^^^^^^^^^
Snapshot names have to be resolved by Executor or just before
execution: someday we'll implement stored procedures/functions:
no parsing before execution...
We could add bool to RTE: use name from snapshot pointer
to get real snapshot. Or something like this.

> into the RTE's. Named snapshots are never freed until
> transaction end or FREE SNAPSHOT.
>
> This should be the core functionality that makes deferred
> queries possible at all. And it must solve the problem with
> the portal where inserts/updates inside the fetch loop get
> visible too. Since the portals heapgettup() will use the
> command counter from the CREATE CURSOR instead of the current
> command counter, the portal will not see them. The portal
> will see the database exactly in the state at CREATE CURSOR
> time. But another SELECT issued after an UPDATE in the same
> transaction will, as it is supposed to.

Nice.

Vadim