Re: BUG #17975: Nested Loop Index Scan returning wrong result - Mailing list pgsql-bugs

From David Rowley
Subject Re: BUG #17975: Nested Loop Index Scan returning wrong result
Date
Msg-id CAApHDvovtq_G-R+++37xHW0LMhmMGkow7cjY6xwxZ8CLUS=HJg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17975: Nested Loop Index Scan returning wrong result  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #17975: Nested Loop Index Scan returning wrong result  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Thu, 15 Jun 2023 at 12:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I concur that we'd better just not use partial indexes in
> relation_has_unique_index_for.

I wonder if that's ok for a backpatch.  This affects both left join
removals and unique joins.  Seems like suddenly making a left join
removal not work might cause someone some pain.

Is it worth trying to jam in a new boolean field into IndexOptInfo
into some spare padding to that we run predicate_implied_by() just
using baserestrictinfo and use those in
relation_has_unique_index_for()?

One problem might be that I don't see anywhere we could jam another
boolean into IndexOptInfo on 32-bit builds. Maybe we could put it at
the end given that we should only be making these structs in core?

David



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17975: Nested Loop Index Scan returning wrong result
Next
From: Tom Lane
Date:
Subject: Re: BUG #17975: Nested Loop Index Scan returning wrong result