Robert Haas <robertmhaas@gmail.com> writes:
> It's a bit annoying that we percolate things up the tree the way we do
> at all. I realize this is far afield from the topic of this thread.
> But suppose that I join 5 tables and select a subset of the table
> columns in the output. Suppose WLOG the join order is A-B-C-D-E. Well,
> we're going to pull the columns that are needed from A and B and put
> them into the slot representing the result of the A-B join. Then we're
> going to take some columns from that slot and some columns from C and
> put them into the slot representing the result of the A-B-C join. And
> so on until we get to the top. But the slots for the A-B, A-B-C, and
> A-B-C-D joins don't seem to really be needed.
You do realize that we're just copying Datums from one level to the
next? For pass-by-ref data, the Datums generally all point at the
same physical data in some disk buffer ... or if they don't, it's
because the join method had a good reason to want to copy data.
If we didn't have the intermediate tuple slots, we'd have to have
some other scheme for identifying which data to examine in intermediate
join levels' quals. Maybe you can devise a scheme that has less overhead,
but it's not immediately obvious that any huge win would be available.
regards, tom lane
