TIME QUALIFICATION - Mailing list pgsql-hackers
From | jwieck@debis.com (Jan Wieck) |
---|---|
Subject | TIME QUALIFICATION |
Date | |
Msg-id | m109tV1-000EBRC@orion.SAPserv.Hamburg.dsh.de Whole thread Raw |
List | pgsql-hackers |
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@debis.com (Jan Wieck) #
pgsql-hackers by date: