From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Hicham G(dot) Elmongui" <elmongui(at)cs(dot)purdue(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: planner & target lists |
Date: | 2004-09-24 14:54:12 |
Message-ID: | 21712.1096037652@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Hicham G. Elmongui" <elmongui(at)cs(dot)purdue(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2004-09-24 15:08:15 | Re: SQL-Invoked Procedures for 8.1 |
Previous Message | Marc G. Fournier | 2004-09-24 14:37:47 | PostgreSQL 8.0 beta3 on Monday |