| From: | Chantal Keller <chantal(dot)keller(at)universite-paris-saclay(dot)fr> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Aleksander Alekseev <aleksander(at)timescale(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Improving EXPLAIN's display of SubPlan nodes |
| Date: | 2024-01-22 17:11:23 |
| Message-ID: | 47787399-bdfe-45c2-b1ad-7d497301d901@universite-paris-saclay.fr |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Aleksander and Tom
I do confirm that I requested to get this information, in order to
recover the formula to filter on.
Thanks to both of you
Chantal
Le 22/01/2024 à 18:07, Tom Lane a écrit :
> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Arne Roland | 2024-01-22 17:14:14 | Re: Permute underscore separated components of columns before fuzzy matching |
| Previous Message | Andy Fan | 2024-01-22 17:10:17 | Re: the s_lock_stuck on perform_spin_delay |