Anagh Lal <anaghlal2001@yahoo.com> 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
