| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| 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:28:20 |
| Message-ID: | 2029337.1686788900@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> On Thu, 15 Jun 2023 at 11:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> But how did it decide that the partial index is predOK, if there's not
>> a qual forcing a_id to not be null?
> In this case a.id = b.a_id AND c.id = b.c_id are used as proofs. I
> didn't debug all the way, but I assume we deduce that the NOT NULL
> index is ok due to the strict join quals.
Ah. So the index is okay to use as far as the final result is
concerned, but it's not okay for the purpose to which it's being put.
I concur that we'd better just not use partial indexes in
relation_has_unique_index_for.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2023-06-15 00:38:23 | Re: BUG #17975: Nested Loop Index Scan returning wrong result |
| Previous Message | David Rowley | 2023-06-15 00:23:59 | Re: BUG #17975: Nested Loop Index Scan returning wrong result |