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
-
Avoid NullTest deduction for clone clauses
- bc5a08af3c44 17.5 landed
- 716a051aaccd 18.0 landed
-
Add better handling of redundant IS [NOT] NULL quals
- b262ad440ede 17.0 cited