Re: Improving EXPLAIN's display of SubPlan nodes

On Fri, 16 Feb 2024 at 19:39, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> > So now I'm thinking that we do have enough detail in the present
> > proposal, and we just need to think about whether there's some
> > nicer way to present it than the particular spelling I used here.
>

One thing that concerns me about making even greater use of "$n" is
the potential for confusion with generic plan parameters. Maybe it's
always possible to work out which is which from context, but still it
looks messy:

drop table if exists foo;
create table foo(id int, x int, y int);

explain (verbose, costs off, generic_plan)
select row($3,$4) = (select x,y from foo where id=y) and
       row($1,$2) = (select min(x+y),max(x+y) from generate_series(1,3) x)
from generate_series(1,3) y;

                                                  QUERY PLAN
---------------------------------------------------------------------------------------------------------------
 Function Scan on pg_catalog.generate_series y
   Output: (($3 = $0) AND ($4 = $1) AND (ROWCOMPARE (($1 = $3) AND ($2
= $4)) FROM SubPlan 2 (returns $3,$4)))
   Function Call: generate_series(1, 3)
   InitPlan 1 (returns $0,$1)
     ->  Seq Scan on public.foo
           Output: foo.x, foo.y
           Filter: (foo.id = foo.y)
   SubPlan 2 (returns $3,$4)
     ->  Aggregate
           Output: min((x.x + y.y)), max((x.x + y.y))
           ->  Function Scan on pg_catalog.generate_series x
                 Output: x.x
                 Function Call: generate_series(1, 3)

Another odd thing about that is the inconsistency between how the
SubPlan and InitPlan expressions are displayed. I think "ROWCOMPARE"
is really just an internal detail that could be omitted without losing
anything. But the "FROM SubPlan ..." is useful to work out where it's
coming from. Should it also output "FROM InitPlan ..."? I think that
would risk making it harder to read.

Another possibility is to put the SubPlan and InitPlan names inline,
rather than outputting "FROM SubPlan ...". I had a go at hacking that
up and this was the result:

                                                      QUERY PLAN

-----------------------------------------------------------------------------------------------------------------------
 Function Scan on pg_catalog.generate_series y
   Output: (($3 = (InitPlan 1).$0) AND ($4 = (InitPlan 1).$1) AND
((($1 = (SubPlan 2).$3) AND ($2 = (SubPlan 2).$4))))
   Function Call: generate_series(1, 3)
   InitPlan 1 (returns $0,$1)
     ->  Seq Scan on public.foo
           Output: foo.x, foo.y
           Filter: (foo.id = foo.y)
   SubPlan 2 (returns $3,$4)
     ->  Aggregate
           Output: min((x.x + y.y)), max((x.x + y.y))
           ->  Function Scan on pg_catalog.generate_series x
                 Output: x.x
                 Function Call: generate_series(1, 3)

It's a little more verbose in this case, but in a lot of other cases
it ended up being more compact.

The code is a bit messy, but I think the regression test output
(attached) is clearer and easier to interpret. SubPlans and InitPlans
are displayed consistently, and it's easier to distinguish
SubPlan/InitPlan outputs from external parameters.

There are a few more regression test changes, corresponding to cases
where InitPlans are referenced, such as:

  Seq Scan on document
-   Filter: ((dlevel <= $0) AND f_leak(dtitle))
+   Filter: ((dlevel <= (InitPlan 1).$0) AND f_leak(dtitle))
    InitPlan 1 (returns $0)
      ->  Index Scan using uaccount_pkey on uaccount
            Index Cond: (pguser = CURRENT_USER)

but I think that's useful extra clarification.

Regards,
Dean