"Hicham G. Elmongui" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match