On Tue, 4 Nov 2025 at 23:00, David Rowley <dgrowleyml@gmail.com> wrote:
>
> On Tue, 4 Nov 2025 at 22:54, David Rowley <dgrowleyml@gmail.com> wrote:
> > The reason we end up with the same result_rel is that we're not
> > passing all the relids in fetch_upper_rel(root, UPPERREL_SETOP,
> > relids) due to having removed dummy rels. I guess the fix might be
> > something like record the relids even when skipping dummy relations.
> > I'll go and explore that as an option.
>
> This seems to fix it. I'll study it more in the morning (it's late in
> my time zone).
I went over this again this morning. I considered adding the following test:
-- Try a more complex case with multiple chained UNIONs
EXPLAIN (COSTS OFF)
SELECT two FROM tenk1
UNION
SELECT four FROM tenk1
UNION ALL
SELECT ten FROM tenk1 WHERE 1=2;
but it seems that enable_seqscan does also need to be disabled as
otherwise add_path() just finds the new and old path to cost the same
and rejects the new path. With enable_seqscan = off,
compare_path_costs_fuzzily() will find the old path to have
disabled_node = 2 and the new one to have disabled_nodes = 0, so
accepts the new and pfree's the old.
I finally decided that it was a bit too obscure a scenario to test to
verify that the same silly mistake didn't reappear.
Thanks again for the report and the simple recreation steps.
David
