Re: [HACKERS] TIME QUALIFICATION - Mailing list pgsql-hackers

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