MIME-Version: 1.0
References: <873c33c5-ef9e-41f6-80b2-2f5e11869f1c@garret.ru>
 <CAEze2Wg1Q4gWzm9RZ0yXydm23Mj3iScu8LA__Zz3JJEgpnoGPQ@mail.gmail.com>
 <CAH2-Wzn9ZGt8mYMrbDMSRSps3t-ro4JNFXbAvk_jwUoKi=gANQ@mail.gmail.com>
 <1643257.1733157822@sss.pgh.pa.us> <fw54ktry2576xqvztx642ee6352rwc57y5hs6arcfjeowq6yon@3njdaxumsidi>
 <1646644.1733158959@sss.pgh.pa.us> <CAH2-WzmNuB-xmQ29=GfL0g9nXrdYoPZo3Zeqm0UTncCWJQmMvw@mail.gmail.com>
 <1647379.1733159462@sss.pgh.pa.us> <CAH2-WzmiOd9-tvqRV-8oyXNkvaiAK_=LYT-gX8GkinZqeXEneQ@mail.gmail.com>
 <6nev7zfx57h5pkqpgdp4q37xjcj2dxqilsgbb5ac5lhub4whsb@ap7ptu6yqyj6>
In-Reply-To: <6nev7zfx57h5pkqpgdp4q37xjcj2dxqilsgbb5ac5lhub4whsb@ap7ptu6yqyj6>
From: Peter Geoghegan <pg@bowt.ie>
Date: Mon, 2 Dec 2024 16:16:19 -0500
Message-ID: <CAH2-Wzmit-OxVZ4aaqAuOpX2NqSX4iayV_37bpdKRZybwOHPcg@mail.gmail.com>
Subject: Re: Incorrect result of bitmap heap scan.
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Matthias van de Meent <boekewurm+postgres@gmail.com>, 
	Konstantin Knizhnik <knizhnik@garret.ru>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAH2-Wzmit-OxVZ4aaqAuOpX2NqSX4iayV_37bpdKRZybwOHPcg%40mail.gmail.com>
Precedence: bulk

On Mon, Dec 2, 2024 at 3:55=E2=80=AFPM Andres Freund <andres@anarazel.de> w=
rote:
> I suspect one contributor to this avoiding attention till now was that th=
e
> optimization is fairly narrow:
>
>                         /*
>                          * We can potentially skip fetching heap pages if=
 we do not need
>                          * any columns of the table, either for checking =
non-indexable
>                          * quals or for returning data.  This test is a b=
it simplistic, as
>                          * it checks the stronger condition that there's =
no qual or return
>                          * tlist at all. But in most cases it's probably =
not worth working
>                          * harder than that.
>                          */
>                         need_tuples =3D (node->ss.ps.plan->qual !=3D NIL =
||
>                                                    node->ss.ps.plan->targ=
etlist !=3D NIL);
>
> Even an entry in the targetlist that that does not depend on the current =
row
> disables the optimization.

Good point. I agree that that factor is likely to have masked the
problem over the past 6 years.

--=20
Peter Geoghegan