Re: BUG #17975: Nested Loop Index Scan returning wrong result - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: BUG #17975: Nested Loop Index Scan returning wrong result
Date
Msg-id CAH2-Wz=XerOp1sG6PG3dLFJF5z3fsMdzaZnGujB=+sq4OCBSKw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17975: Nested Loop Index Scan returning wrong result  (Andres Freund <andres@anarazel.de>)
List pgsql-bugs
On Wed, Jun 14, 2023 at 2:21 PM Andres Freund <andres@anarazel.de> wrote:
> 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 :).

It certainly looks that way now.

On further examination the only substantive difference is that the
indexes themselves differ in one leaf of the plan. The good plan and
the bad plan match everywhere else (except that the good plan uses
bitmap index scans rather than index scans everywhere).

--
Peter Geoghegan



pgsql-bugs by date:

Previous
From: Andres Freund
Date:
Subject: Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon
Next
From: Andres Freund
Date:
Subject: Re: BUG #17973: Reinit of pgstats entry for dropped DB can break autovacuum daemon