Re: [EXTERNAL]Re: BUG #19094: select statement on postgres 17 vs postgres 18 is returning different/duplicate results

Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> On Tue, Oct 28, 2025 at 11:04 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Right. I agree that #3 is the most attractive stopgap answer.
>> We can look into #2 later, but it doesn't sound like something
>> to back-patch.

> Agreed. Here's a patch that follows along the lines of option #3.

Code changes look good, and I confirm that I can't reproduce the
failure anymore with this patch.

I'm not convinced that the new regression test case is worth the
cycles, at least not in this form. The main thing that's annoying me
about it is creating/populating/analyzing its own large one-use table;
that approach soon leads to regression suites that take forever.
You could answer that objection by making use of some existing
regression table, for instance this seems to work as well:

explain select * from tenk1 t1
where exists(select 1 from tenk1 t2 where tenthous = t1.tenthous);

However, I feel like it may still not be a great test, because it only
shows that the planner *didn't* pick PRSJ, not that it *couldn't*.
The cost differential between PRSJ with these settings and the Hash
Semi Join plan that you get after applying the patch is not very
great; so it's easy to imagine future changes that'd mean we'd not
prefer PRSJ here anyway. But I'm not sure what we could do about
that, so operationally this may be as good a test as we can get
anyway.

Another thought is that rather than having to remember to reset all
those planner options, you could make the test a bit shorter and
more maintainable by writing something like

begin;
set local parallel_setup_cost=0;
set local ...

explain ...

rollback;

regards, tom lane