Two parts to the mail
> We already do --- the scan nodes project out only
> the needed columns.
ok..thats great.
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 /backend/executor/nodeMergeJoin.c
in ExecMergeJoin()
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
first place).

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

part 2)
>  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?

Anagh Lal

Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day

---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?


Reply via email to