Re: Incorrect result of bitmap heap scan. - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: Incorrect result of bitmap heap scan.
Date
Msg-id CAEze2WgFT2zeuAHeNQ=yrdCvgjCEo96DcJY+5UC5WqPC_Wva_A@mail.gmail.com
Whole thread Raw
In response to Re: Incorrect result of bitmap heap scan.  ("Core Studios Inc." <corestudiosinc@gmail.com>)
List pgsql-hackers
On Tue, 16 Sept 2025 at 13:57, Core Studios Inc.
<corestudiosinc@gmail.com> wrote:
>
> Hello,
>
> We noticed a sustained increased in IO Wait of read queries after
> upgrading from 13.13 to 13.21. Eventually, we narrowed it down to a
> spike in index_blocks_read of a certain table where Bitmap Heap Scans do
> happen.
>
> Do you think that this change (i.e. removing the optimization) could be
> what caused this regression?

I'm quite sure that the IOs for a Bitmap Heap Scan (which is the node
that now may see increased IO) count towards the table's IO statistics
(e.g. pg_stat_all_tables, heap_blks_read), not the index (e.g.
pg_stat_all_indexes, idx_blcks_read). Only "Index Scan" (and Bitmap
IS, and IOS) nodes can count their IO toward their relative indexes,
and the executor code for those nodes was not modified in this bugfix.

Note that before the removal of the VM-only option, these "bitmap
only" nodes could return incorrect results, and thus that "bitmap-only
scan" wasn't really a valid optimization.

Also note that neither the "optimization" nor the fix modified any
part or dependency of the planner, so any changes in plans must have
been caused by other changes in the system as a whole (such as updated
table statistics, and (unlikely) other backported bugfixes).


Kind regards,

Matthias van de Meent
Databricks



pgsql-hackers by date:

Previous
From: Greg Burd
Date:
Subject: Re: [PATCH] Add tests for Bitmapset
Next
From: Mircea Cadariu
Date:
Subject: Re: vacuumdb --analyze-only does not need to issue VACUUM (ONLY_DATABASE_STATS) ?