Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Teaching planner to short-circuit empty UNION/EXCEPT/INTERSECT inputs
Date: 2025-11-05 05:26:53
Message-ID: CAApHDvpAKN9aQ3Ytcrze+BzA6ZTk6O61zz1YZmewNhvcNfBELA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 5 Nov 2025 at 17:00, Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> But while playing around, I've just discovered another interesting error:
>
> SET enable_seqscan = 'off';
> SELECT * FROM t EXCEPT SELECT * FROM t
> UNION SELECT * FROM pt;
>
> leads to:
> ERROR: XX000: no relation entry for relid 0
> LOCATION: find_base_rel, relnode.c:541

:-(

This happens because of the code I added to try to give better
estimates to the number of groups when only a single child remains in
the UNION. Because the only surviving Path is for the EXCEPT set-op,
there are Vars with varno==0, which estimate_num_groups() does not
like. I'm considering restricting that code Path to where the
path->parent->reloptkind != RELOPT_UPPER_REL. It doesn't feel great
adding the special case, but likely having better row estimates is
worthwhile, when it's possible. I'll sit on that for a bit and see if
I can think of a better way.

(Yet another reason we should probably fix the varno==0 issue.)

Thanks for the report and reproducer, again!

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2025-11-05 05:44:39 Re: [BUG] temporary file usage report with extended protocol and unnamed portals
Previous Message Robert Treat 2025-11-05 05:10:47 Re: Adding REPACK [concurrently]