Represent set operation outputs with RTE_SETOP range table entries

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, David Rowley <dgrowleyml(at)gmail(dot)com>
Subject: Represent set operation outputs with RTE_SETOP range table entries
Date: 2026-11-04 05:48:38
Message-ID: CAGRkXqT+wGCitH9V0xf1asBu=azcHHocbFtVAgFxmcy_cm+PQQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi hackers,

Set operation output Vars use varno 0 today, and the planner has
special cases for that in many places. In the bug #19742 thread, Tom
suggested giving each set operation its own range table entry [1].

Here is a first patch set for v20.

0001 adds an RTE_SETOP entry for each set operation and points the
output Vars at it. Plans and results stay the same in my tests.

Nested set operations used to match sort orders for free, since they
all shared varno 0. 0001 keeps that by putting the output columns of
all levels into shared EquivalenceClasses. 0002 converts the child's
pathkeys instead, like convert_subquery_pathkeys() does. It is
cleaner but plans slower. With 10 columns and 5 levels the plan time is 65%
slower than master, and 0001 is 10-18% slower. So I would take 0001 for
now. What do people think?

I want to propose the following plan:

1. Build a RelOptInfo for each set operation, for the better width
estimates Tom mentioned. Its relids become the set operation's own
index.
2. Point the top level output columns at the top set operation entry.
3. Look up EquivalenceClasses per rel. That makes 0002 cheap.

Please let me know if you have any concerns or anything I can explain better

[1] https://postgr.es/m/1087303.1791221946@sss.pgh.pa.us

Thanks,
Shihao

Attachment Content-Type Size
v1-0002-Convert-pathkeys-of-nested-set-operations-instead.patch application/octet-stream 21.4 KB
v1-0001-Represent-set-operation-outputs-with-RTE_SETOP-ra.patch application/octet-stream 53.6 KB

Browse pgsql-hackers by date

  From Date Subject
Previous Message RekGRpth 2026-11-04 05:28:20 Re: Assertion with aborted UPDATE in subtransaction