Re: Improving EXPLAIN's display of SubPlan nodes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Aleksander Alekseev <aleksander(at)timescale(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Chantal Keller <chantal(dot)keller(at)universite-paris-saclay(dot)fr>
Subject: Re: Improving EXPLAIN's display of SubPlan nodes
Date: 2024-01-22 17:07:23
Message-ID: 3791430.1705943243@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Aleksander Alekseev <aleksander(at)timescale(dot)com> writes:
> Although something like:

> ```
> + Filter: (ANY (base_tbl.a = $1) FROM SubPlan 1 (returns $1))
> + SubPlan 1 (returns $1)
> ```

> ... arguably doesn't give much more information to the user comparing
> to what we have now:

> ```
> - Filter: (SubPlan 1)
> - SubPlan 1
> ```

Yeah, I would probably not have thought to do this on my own; but
we had an actual user request for it. I think arguably the main
benefit is to confirm "yes, this is the sub-select you think it is".

The main thing that's still missing compared to what is in the plan
data structure is information about which Param is which. I think
we have the subplan output Params relatively well covered through
the expedient of listing them in the generated plan_name, but it's
still not apparent to me how we could shoehorn subplan input
Params into this (or whether it's worth doing).

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Dolgov 2024-01-22 17:07:27 Re: pg_stat_statements and "IN" conditions
Previous Message Robert Haas 2024-01-22 17:01:29 Re: the s_lock_stuck on perform_spin_delay