TIME QUALIFICATION

It's time,

as we've seen on the recent question, the time qualification
code has to be modified again. I think a little extension to
Vadim's SnapshotData could do the trick. Following is what I
so far have in mind to support deferred queries later in
v6.6.

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.

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.

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
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.

Have I forgotten something?

Vadim, please comment on this.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck(at)debis(dot)com (Jan Wieck) #