Re: making update/delete of inheritance trees scale better

On Thu, Feb 4, 2021 at 10:14 PM Amit Langote <amitlangote09(at)gmail(dot)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