Re: making update/delete of inheritance trees scale better

On Tue, Mar 30, 2021 at 12:51 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Maybe that could be made more robust, but the other problem
> is that the EXPLAIN output is just about unreadable; nobody will
> understand what "(0)" means.

I think this was an idea that originally came from me, prompted by
what we already do for:

rhaas=# explain verbose select 1 except select 2;
QUERY PLAN
-----------------------------------------------------------------------------
HashSetOp Except (cost=0.00..0.06 rows=1 width=8)
Output: (1), (0)
-> Append (cost=0.00..0.05 rows=2 width=8)
-> Subquery Scan on "*SELECT* 1" (cost=0.00..0.02 rows=1 width=8)
Output: 1, 0
-> Result (cost=0.00..0.01 rows=1 width=4)
Output: 1
-> Subquery Scan on "*SELECT* 2" (cost=0.00..0.02 rows=1 width=8)
Output: 2, 1
-> Result (cost=0.00..0.01 rows=1 width=4)
Output: 2
(11 rows)

That is admittedly pretty magical, but it's a precedent. If you think
the relation OID to subplan index lookup is fast enough that it
doesn't matter, then I guess it's OK, but I guess my opinion is that
the subplan index feels like the thing we really want, and if we're
passing anything else up the plan tree, that seems to be a decision
made out of embarrassment rather than conviction. I think the real
problem here is that the deparsing code isn't in on the secret. If in
the above example, or in this patch, it deparsed as (Subplan Index) at
the parent level, and 0, 1, 2, ... in the children, it wouldn't
confuse anyone, or at least not much more than EXPLAIN output does in
general.

Or even if we just output (Constant-Value) it wouldn't be that bad.
The whole convention of deparsing target lists by recursing into the
children, or one of them, in some ways obscures what's really going
on. I did a talk a few years ago in which I made those target lists
deparse as $OUTER.0, $OUTER.1, $INNER.0, etc. and I think people found
that pretty enlightening, because it's sort of non-obvious in what way
table foo is present when a target list 8 levels up in the join tree
claims to have a value for foo.x. Now, such notation can't really be
recommended in general, because it'd be too hard to understand what
was happening in a lot of cases, but the recursive stuff is clearly
not without its own attendant confusions.

Thanks to both of you for working on this! As I said before, this
seems like really important work.

--
Robert Haas
EDB: http://www.enterprisedb.com