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@debis.com (Jan Wieck) #