Re: Query result differences between PostgreSQL 17 vs 16

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>, David Rowley <dgrowleyml@gmail.com>, Ronald Cruz <cruz@rentec.com>, pgsql-bugs@lists.postgresql.org, Peter Ford <pford@rentec.com>, "Aaron J. Garcia" <agarcia@rentec.com>
Date: 2025-03-03T06:50:38Z
Lists: pgsql-bugs
On Sat, Mar 1, 2025 at 7:16 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So in the case at hand, we generate a clone of the "rc3.id IS NOT
> NULL" clause that doesn't have a nullingrel bit for the left join to
> rc3, but nonetheless is expected to be applied after that join is
> performed.  There is also a clone that does have a nullingrel bit, but
> that doesn't save us in this example because it will only be applied
> in join orders other than the one that gets chosen.

Exactly!

> It'd certainly be nice to make that cleaner, but I'm not sure how,
> and we wouldn't risk back-patching the nontrivial changes that would
> be needed.  So I think rejecting has_clone/is_clone clauses is the
> only path forward for now.

Yeah, a better fix might be to find a way to perform this NullTest
deduction during eval_const_expressions, as you mentioned in the other
thread.  However, that would also require some nontrivial changes.

> Also, I found a test case proving that restriction_is_always_false
> needs it too.

Thanks.  I've included this test case in v3 patch.

Thanks
Richard



Commits

  1. Avoid NullTest deduction for clone clauses

  2. Add better handling of redundant IS [NOT] NULL quals