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  (Peter Geoghegan <pg@bowt.ie>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: BUG #17975: Nested Loop Index Scan returning wrong result
Следующее
От: Andres Freund
Дата:
Сообщение: Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon