On Thu, Feb 4, 2021 at 10:14 PM Amit Langote <amitlangot...@gmail.com> wrote: > I guess it would depend on how many of those hidden columns there need > to be (in addition to the existing "ctid" hidden column) and how many > levels of the plan tree they would need to climb through when bubbling > up.
My memory is a bit fuzzy because I haven't looked at this in a while, but I feel like there were basically two: a 64-bit UndoRecPtr and an integer slot number. I could be misremembering, though. 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. At any point in time, the value for some column A.x should be the same in all of those intermediate slots as it is in the current tuple for the baserel scan of A. I *think* the only time it's different is when we've advanced the scan for A but haven't gotten around to advancing the joins yet. But that just underscores the point: if we didn't have all of these intermediate slots around we wouldn't have to keep advancing them all separately. Instead we could have the slot at the top, representing the final join, pull directly from the baserel slots and skip all the junk in the middle. Maybe there's a real reason that won't work, but the only reason I know about why it wouldn't work is that we don't have the bookkeeping to make it work. -- Robert Haas EDB: http://www.enterprisedb.com
