| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | tel(at)jklm(dot)no, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #17975: Nested Loop Index Scan returning wrong result |
| Date: | 2023-06-14 21:10:02 |
| Message-ID: | CAH2-WzkqMAQYNj_jn=6WDU4x=dX84cj3XpEQnyX=e4oh7=aM-g@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Jun 14, 2023 at 1:37 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> Something seems to be off with the relevant param - it's NULL. Haven't dug
> deeper.
I see that the bad plan has _bt_first() return false early during a
btgettuple() call for one of the a_pkey index scans. That is,
_bt_first() returns false early in the "Quit now if
_bt_preprocess_keys() discovered that the scan keys can never be
satisfied (eg, x == 1 AND x > 2)" path.
It's possible that this is a red herring -- this is not the only
difference between the "bad" index scan heavy plan and the "good" plan
that uses bitmap scans. But right now my suspicion falls on
_bt_preprocess_keys().
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-06-14 21:12:31 | Re: BUG #17975: Nested Loop Index Scan returning wrong result |
| Previous Message | Andres Freund | 2023-06-14 20:36:51 | Re: BUG #17975: Nested Loop Index Scan returning wrong result |