Re: planner & target lists - Mailing list pgsql-hackers

From Tom Lane
Subject Re: planner & target lists
Date
Msg-id 21712.1096037652@sss.pgh.pa.us
Whole thread Raw
In response to planner & target lists  ("Hicham G. Elmongui" <elmongui@cs.purdue.edu>)
List pgsql-hackers
"Hicham G. Elmongui" <elmongui@cs.purdue.edu> writes:
> In other words, in the following tree, a variable in B that shows in Op1's
> target list, does it have its relation as INNER (which is B) or OUTER (which
> is Op2)

>          Op1
>          / \
>         /   \
>        /     \
>      Op2     Op3
>      / \     / \
>     /   \   /   \
>    A     B C     D


IIRC, up to the point where setrefs.c runs, all Vars have varnos that
refer to their parent relation in the rangetable list --- so B's vars
look the same no matter where they are in the tree.

setrefs.c changes Vars that are in JOIN plan nodes to have varno INNER
or OUTER, indicating whether the value is coming from the inner or outer
(right or left) input of *that particular plan node*.  IIRC it also
relabels varattno to be the column number of that value in the
tuples emitted by that input.  So after this happens, the "same" Var
might look completely different at each tree level it appears in.

The executor is never particularly interested in rangetable positions
--- all Vars it deals with can be resolved by looking in either the
current table's scanned tuple (at the bottom scan level) or one of the
input tuples to the current upper-level plan node.  So basically setrefs
is transforming the Var from a planner-friendly representation to an
executor-friendly one.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: PostgreSQL 8.0 beta3 on Monday
Next
From: Joe Conway
Date:
Subject: Re: SQL-Invoked Procedures for 8.1