Re: [HACKERS] TIME QUALIFICATION

Vadim wrote:

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

Yes, the parser could allways put NULL into the RTE's
snapshot name field (or the name later for named snapshots).
But it's the rewrite system that has to tell for unnamed
snapshots, which ones have to be used on which RTE's.

Let's have two simple tables with a rule (and assume in the
following that snapshot includes scan command Id):

create table t1 (a int4);
create table t2 (b int4);

create rule r1 as on delete to t1
do delete from t2 where b = old.a;

We execute the following commands:

begin;
delete from t1 where a = 5;
insert into t2 values (5);
commit;

If 5 is in t2 after commit depends on if the rule is deferred
or not. If it isn't deferred, 5 should be there, otherwise
not.

The rule will create a parsetree like this:

delete from t2 where t1.a = 5 and b = t1.a;

So the tree has a rangetable containing t2 and t1 (along with
some other unused entries). But only the rule system knows,
that the RTE for t2 came from the rule and must be scanned
with the visibility of commit time while t1 came from the
original query and must be scanned with the visibility that
was when the original delete from t1 was executed (they are
already deleted, but the rule actions scan must find em).

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
action itself must get the snapshot when the rules command is
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.

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

That's a point I forgot and I will allready have that problem
in prepared SPI plans. One SPI query could also fire rules
resulting in multiple plans.

So I must change it. The parser rewrite combo allways put's
QueryId's starting with 0 into the queries and their RTE's,
telling which RTE's belong to which queries execution times.
And these must then be offset when the plans get actually
added to either the current execution tree list or the
deferred execution tree list.

And SPI must know about deferred queries, because for
prepared plans, one must get deferred for every SPI_execp()
call. It's not the rewriter who's managing the deferred tree
list. It must be it's caller. So the deferred information is
part of the querytree.

Better now, thanks Vadim.

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