Re: Improving EXPLAIN's display of SubPlan nodes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, 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-03-15 14:58:25
Message-ID: 2506269.1710514705@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
> One thing that concerns me about making even greater use of "$n" is
> the potential for confusion with generic plan parameters.

True.

> 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:

> Output: (($3 = (InitPlan 1).$0) AND ($4 = (InitPlan 1).$1) AND
> ((($1 = (SubPlan 2).$3) AND ($2 = (SubPlan 2).$4))))

Hmm. I guess what bothers me about that is that it could be read to
suggest that the initplan or subplan is evaluated again for each
output parameter. Perhaps it'll be sufficiently clear as long as
we keep the labeling

> InitPlan 1 (returns $0,$1)
> SubPlan 2 (returns $3,$4)

but I'm not sure. Anybody else have an opinion?

(I didn't read your changes to the code yet --- I think at this
point we can just debate proposed output without worrying about
how to implement it.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2024-03-15 15:06:11 Re: Popcount optimization using AVX512
Previous Message Bertrand Drouvot 2024-03-15 14:44:43 Re: Synchronizing slots from primary to standby