Projection while performing joins.

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