Two parts to the mail
> We already do --- the scan nodes project out only
> the needed columns.
I tried looking for what you are saying in the source
code... [before and after doing a cvs update].. but I
am still confused by the following:
In the state (the switch case) EXEC_MJ_JOINTUPLES
we still do ExecProject(), what does this do?
(this is what prompted my incorrect assumption in the
I was able to trace the ExecProject() which takes
place (due to the SeqScan node) in the
ExecScan function of /executor/execScan.c
(I made an error in assuming the tuple returned
by the function passed as an argument to ExecScan was
being returned directly )...
so now i see what you were saying in the mail but
am not clear about why we have a ExecProject() higher
up in the join nodes..its there in the NestedLoop node
> As you indicate, that's probably a net loss
> when there's a Sort node directly above the scan
> node. Needs more thought...
Some food for thought,
Let's ignore the attributes listed in the select
and work only with the where clause (join condition)
attributes. And as a back reference store the
tupleid of the original whole tuple in the "working"
tuple. At the final output stage perform a lookup to
retrieve the select clause attributes of only the
qualifying tuple. Thus enabling us to work with really
small sized data.
worth trying out?
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?