Re: plan shape work

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Richard Guo <guofenglinux@gmail.com>, Alexandra Wang <alexandra.wang.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "bruce@momjian.us" <bruce@momjian.us>, lepihov@gmail.com
Date: 2025-09-16T14:17:42Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Assign each subquery a unique name prior to planning it.

  2. Keep track of what RTIs a Result node is scanning.

Attachments

On Mon, Sep 15, 2025 at 3:43 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> anything to the RTE's eref.  While that makes your argument
> nominally true, I'd be inclined to argue that this was an oversight
> and it should have changed the alias/eref fields to look like other
> RTE_RESULTs.  (I've not investigated, but I wonder what your
> patch prints for such cases.)

It just prints "-> Result" and that's it, as in this example:

robert.haas=# create or replace function absolutely_not() returns bool
return false;
CREATE FUNCTION
robert.haas=# explain (costs off) select * from generate_series(1,3) g
full join absolutely_not() n on true;
                QUERY PLAN
------------------------------------------
 Merge Full Join
   ->  Function Scan on generate_series g
   ->  Materialize
         ->  Result
(4 rows)

robert.haas=# explain (costs off, range_table) select * from
generate_series(1,3) g full join absolutely_not() n on true;
                QUERY PLAN
------------------------------------------
 Merge Full Join
   ->  Function Scan on generate_series g
         Scan RTI: 1
   ->  Materialize
         ->  Result
               RTIs: 2
 RTI 1 (function, in-from-clause):
   Alias: g ()
   Eref: g (g)
   WITH ORDINALITY: false
 RTI 2 (result, in-from-clause):
   Alias: n ()
   Eref: n (n)
 RTI 3 (join, in-from-clause):
   Eref: unnamed_join (g, n)
   Join Type: Full
(16 rows)

Here's a new patch set. My main questions are:

1. Did I miss anything you wanted fixed in 0001?

2. Should 0001 be combined with 0002 or kept separate?

3. Do you have a preference between this version of 0003 and the older
revision that just ignored outer-join relids?

--
Robert Haas
EDB: http://www.enterprisedb.com