Re: BUG #17975: Nested Loop Index Scan returning wrong result
От | Andres Freund |
---|---|
Тема | Re: BUG #17975: Nested Loop Index Scan returning wrong result |
Дата | |
Msg-id | 20230614212127.l2dpbowfjmttqpkv@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: BUG #17975: Nested Loop Index Scan returning wrong result (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: BUG #17975: Nested Loop Index Scan returning wrong result
|
Список | pgsql-bugs |
Hi, On 2023-06-14 14:10:02 -0700, Peter Geoghegan wrote: > On Wed, Jun 14, 2023 at 1:37 PM Andres Freund <andres@anarazel.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. I think that's a consequence of the planner bug (see subsequent email) - the bad plan wrongly uses an index that first returns a null a_id, which then quite legitimately makes _bt_preprocess_keys() exit early. That bit of smartness did confuse me for a moment, I was expecting the index scan to actually scan the index at first :). I haven't figured out where we're dropping the implied index qual on the floor yet... Greetings, Andres Freund
В списке pgsql-bugs по дате отправления: