From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Guo <guofenglinux(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "bruce(at)momjian(dot)us" <bruce(at)momjian(dot)us>, lepihov(at)gmail(dot)com |
Subject: | Re: plan shape work |
Date: | 2025-09-26 01:40:56 |
Message-ID: | CA+TgmobAaH83J5keNXXb6+1SJqNUJBbb2BMKjUYpQyGiH6_pRA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 25, 2025 at 9:21 PM Alexandra Wang
<alexandra(dot)wang(dot)oss(at)gmail(dot)com> wrote:
> I've tried v10-000{1,2}+v9-0002 and v9-000{1,2}. I was curious whether
> the names choose_plan_name() chose for subqueries match the Subquery
> Scan names in the EXPLAIN plan. My guess is that since the former is
> chosen before planning and the latter after planning, they might
> differ. I think it's probably ok to have different naming mechanisms
> as long as the names are unique within themselves. But in case anyone
> else cares about the naming inconsistency, here's an example that
> shows it.
Yeah. Technically, these are not the same names: one set of names is
the names assigned to the subqueries, and the other is the set of
names assigned to the relations that get scanned by subquery scans.
This may seem like a technicality, but that's not entirely the case,
because in each case the chosen names are unique. If, for example,
there were a table named unnamed_subquery that we were
subquery-scanning, then you couldn't also have a subquery scan of that
table, but you could still have a subquery with that name.
But maybe there's still some way to improve this. It would probably be
hard to make it perfect because of the fact that EXPLAIN names are
unique across all relations in the query, as noted above. However, we
might be able to make it so the names match in the absence of name
conflicts with user specified aliases or table names. Or maybe we
should consider some larger change to the EXPLAIN format so that we
display subquery names instead of relation names.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-09-26 01:53:30 | Re: plan shape work |
Previous Message | Yugo Nagata | 2025-09-26 01:29:32 | Re: Suggestion to add --continue-client-on-abort option to pgbench |