Hi,
I am confused about an internal point of the planner.

Consider a select query and the output target list at the root of the tree.
This target lists points to some Vars. Each of which has as relation either
INNER/OUTER.
Does this INNER/OUTER refer to the inner/outer relations of the top-most
node in the tree or to the bottom-most one.

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

Regards,
--h

Search Discussions

  • Tom Lane at Sep 24, 2004 at 2:54 pm

    "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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedSep 24, '04 at 1:22p
activeSep 24, '04 at 2:54p
posts2
users2
websitepostgresql.org...
irc#postgresql

2 users in discussion

Tom Lane: 1 post Hicham G. Elmongui: 1 post

People

Translate

site design / logo © 2022 Grokbase