| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | tel(at)jklm(dot)no, pgsql-bugs(at)lists(dot)postgresql(dot)org, David Rowley <dgrowleyml(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie> |
| Subject: | Re: BUG #17975: Nested Loop Index Scan returning wrong result |
| Date: | 2023-06-14 23:59:26 |
| Message-ID: | 2026451.1686787166@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2023-06-14 19:02:48 -0400, Tom Lane wrote:
>> I did not study this example yet, but generally we ignore predicate
>> indexes unless their predicates can be proven from base restrictions
>> of their table (that's what predOK means).
> It doesn't really hold at lower join levels with partial unique indexes, at
> least as far as inner_unique goes. In this case we have one partial unique
> index on b(c_id) WHERE a_id IS NOT NULL, and we have a plain index on b(c_id).
> inner_unique is set to true based on the partial index - but then we decide
> use the non-partial index for the index scan. That ends up returning a row
> which with a_is = NULL, which won't find a match in the upper join
> levels.
But how did it decide that the partial index is predOK, if there's not
a qual forcing a_id to not be null?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Guissine | 2023-06-15 00:04:53 | Re: BUG #17974: Walsenders memory usage suddenly spike to 80G+ causing OOM and server reboot |
| Previous Message | Andres Freund | 2023-06-14 23:57:11 | Re: BUG #17975: Nested Loop Index Scan returning wrong result |