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? It can't simply return either the left or the right input tuple (except in the vanishingly-small fraction of cases where you don't actually need any columns from the right or the left respectively; which are cases that we don't currently bother to optimize). To create a tuple that's not exactly one or the other you must project. > 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? Not sure there's a lot of traction here. In many cases, the bottom-level scan gets advanced one or more rows before the top-level nodes can pop out a result. (Consider GROUP BY as an example.) I don't see the advantage of adding bookkeeping/copying for past rows in order to avoid copying current-row data around. But feel free to prove me wrong ;-) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster