Re: Query result differences between PostgreSQL 17 vs 16
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
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-02-22T02:32:39Z
Lists: pgsql-bugs
Richard Guo <guofenglinux@gmail.com> writes: > On Sat, Feb 22, 2025 at 8:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I've not looked at the code, but I suspect that it is failing >> to check varnullingrels before believing that it can trust >> the applicability of table constraints. > Hmm, we do check varnullingrels in expr_is_nonnullable(). My best > guess is that we have generated two versions of the qual 'customer.cid > IS NOT NULL': one with customer.cid marked as nullable by the left > join to customer, and one without. The latter is dropped because of > the not null constraint on customer.cid, while the former fails to be > applied on the left join to int4_tbl j. If the check against table not-null constraints is applied after we clone outer-join quals, that's probably bad. I think there are assumptions in there that every clone qual will have doppelgangers, so filtering NOT NULLs later would break that. Maybe not applying the filter to quals marked has_clone or is_clone would help? regards, tom lane
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