| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Incorrect result of bitmap heap scan. |
| Date: | 2024-12-02 21:16:19 |
| Message-ID: | CAH2-Wzmit-OxVZ4aaqAuOpX2NqSX4iayV_37bpdKRZybwOHPcg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Dec 2, 2024 at 3:55 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I suspect one contributor to this avoiding attention till now was that the
> 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 bit 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 = (node->ss.ps.plan->qual != NIL ||
> node->ss.ps.plan->targetlist != 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.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2024-12-02 21:17:14 | [18] Unintentional behavior change in commit e9931bfb75 |
| Previous Message | Darek Ślusarczyk | 2024-12-02 21:12:01 | add support for the old naming libs convention on windows (ssleay32.lib and libeay32.lib) |