Anagh Lal <[EMAIL PROTECTED]> writes:
> ... 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?
Well, sure. A join node *must* do a projection, no? I
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.
Anagh Lal <[EMAIL PROTECTED]> writes:
> 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 attribute
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
kee
