From: Tom Lane <tgl@sss.pgh.pa.us>
To: Aleksander Alekseev <aleksander@timescale.com>
cc: pgsql-hackers@lists.postgresql.org,
        Chantal Keller <chantal.keller@universite-paris-saclay.fr>
Subject: Re: Improving EXPLAIN's display of SubPlan nodes
In-reply-to: 
 <CAJ7c6TMApZ62NOOk73_BmKkKtdhV+i=tyvXR52DAB-YVuFANDA@mail.gmail.com>
References: <2838538.1705692747@sss.pgh.pa.us>
 <CAJ7c6TMApZ62NOOk73_BmKkKtdhV+i=tyvXR52DAB-YVuFANDA@mail.gmail.com>
Comments: In-reply-to Aleksander Alekseev <aleksander@timescale.com>
	message dated "Mon, 22 Jan 2024 15:35:33 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3791429.1705943243.1@sss.pgh.pa.us>
Date: Mon, 22 Jan 2024 12:07:23 -0500
Message-ID: <3791430.1705943243@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3791430.1705943243%40sss.pgh.pa.us>
Precedence: bulk

Aleksander Alekseev <aleksander@timescale.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