Re: plan shape work

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>, 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:53:30
Message-ID: 3972379.1758851610@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

I'm kind of down on that last idea, because relation names/aliases
are user-supplied or at least user-suppliable, whereas what
choose_plan_name() generates is not under user control. So if we
try to make this match, it should be in the direction of using
the parent query's subquery alias whenever possible. But I fear
that it'll be hard to make this match up exactly unless we choose
to take the selection of unique relation aliases out of EXPLAIN
altogether and make the planner do it. Which seems like a bad
idea, because then we're paying that cost all the time, and
it's not small for big queries.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2025-09-26 02:05:15 Re: [BUG] temporary file usage report with extended protocol and unnamed portals
Previous Message Robert Haas 2025-09-26 01:40:56 Re: plan shape work