Hi, Two parts to the mail 1) > 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 too. 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 clause 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? Thanks Anagh Lal __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
