| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, tel(at)jklm(dot)no, pgsql-bugs(at)lists(dot)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: BUG #17975: Nested Loop Index Scan returning wrong result |
| Date: | 2023-06-15 00:38:23 |
| Message-ID: | CAApHDvovtq_G-R+++37xHW0LMhmMGkow7cjY6xwxZ8CLUS=HJg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Thu, 15 Jun 2023 at 12:28, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2023-06-15 00:50:53 | Re: BUG #17975: Nested Loop Index Scan returning wrong result |
| Previous Message | Tom Lane | 2023-06-15 00:28:20 | Re: BUG #17975: Nested Loop Index Scan returning wrong result |