Re: [HACKERS] TIME QUALIFICATION

Vadim wrote:

> > > 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
> ^^^^^^^^^^^^^^^^
> Note: "current" here is "when actual execution will start", not
> "when query was parsed/rewritten". ExecutorStart will substitute
> QuerySnapshot for NULL snapshot pointers.

Yepp - snapshots are allways built just before execution
starts.

The reason why I need the QueryId and it's lookup is that the
time of ExecutorStart() for one query hasn't anything to do
with where it was coming from or when it has been
parsed/rewritten. Due to the rewriting, RTE's in different
queries have relationships. Only the rewrite system knows
them, and the only place where this information could be
stored is the RTE. All RTE's that are related to each other
across queries must use the same snapshot when they get
scanned.

> And so for deffered rules rewrite system will:
>
> 1. set t2' RTE snapshot pointer to NULL - this will guarantee
> that snapshot of execution time (commit or set immediate time)
> will be used;
> 2. set t1' RTE snapshot pointer to current QuerySnapshot
> (and increment its refcount).

At parse/rewrite time there is no actual snapshot. And for
SPI prepared plan, the snapshot to use will be different for
each execution. The RTE cannot hold the snapshot itself. It
could only tell, which of all the snapshots created during a
transaction to use for it.

>
> > And there could also be rules fired on t2. This results in
> > recursive rewriting and it's not that easy to foresee the
> > order in which all these commands will then get executed.
> > During recursion there is no difference between a command
> > coming from the user and one that is already generated by
> > another rule.
> >
> > The problem here is, that the RTE's in a rule generated query
> > resulting from the former command (that fired them) must get
> > scanned against the snapshot of the time when the former
> > command get's executed. But the RTE's coming from the rule
> ^^^^^^^^^^^^^^^^^^^^^^^^
> So - you use QuerySnapshot as it was in this time.
>
> > action itself must get the snapshot when the rules command is
>
> Set RTE' snapshot pointer to NULL.
>
> > executed. Only this way the quals added to the rule from the
> > former command will see what the former command saw.
> >
> > The executor cannot know where all the RTE's where coming
> > from. Except we have a QueryId and associate the QueryId with
> > a snapshot at the time of execution. And I think we must do
> > this lookup, because the order commands are executed will not
> > be the same as they got created. The executor only has to
> > override the RTE's snapshot if the RTE's snapshot name isn't
> > NULL.
>
> + set NULL snapshot pointers to QuerySnapshot.

That way, the executor would have to set all the snapshot
pointers in related RTE's of other queries (not yet executed)
too so they point to the same snapshot. I can only think
about an ordered set to link all the related RTE's to each
other. That would be some kind of ordered set over the
related RTE's, but I would get into deep trouble when copying
rangetables during rewrite or SPI_saveplan() to keep these
set's alive.

Maybe I'm not able to explain exactly enough what I have
vaguely in mind how it could work. But after you've helped
not to forget prepared plans I think I have all the odds and
ends to build it.

I'll hack around a little. Then let's discuss the final
details while having a prototype to look at.

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) #