Hi, In the merge join as well as in the nested loop join, we do ExecProject() after we have found tuples from the relations involved in the join. For a join query involving just two relations and merge join being used, the outer plan will be NodeSort. Now, NodeSort will create Temp files and keep a sorted version of the relation in these Temp files. (correct?) I was wondering, Why do we not just store the attributes required in the join (i.e. those in the join qual conditions and the ones in the select list) and then perform sorting and retrieval on these tuples rather than on the possibly larger tuples with more attributes which we project out in the end anyway.
Is there any reason why this is infeasible to implement or is this simply a wrong approach theoretically? If none, is this being used anywhere? (hope the answers is not postgres... i would have embarrassed myself no limit then) Another way of putting this would be, why don't we push the projection operator as far down as possible. In this case we also add the attributes in the selection operator (of relational algebra) to the projection. And then perform a join on the smaller resulting relation. Regards, Anagh Lal. __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]