Re: Incorrect result of bitmap heap scan.
От | Matthias van de Meent |
---|---|
Тема | Re: Incorrect result of bitmap heap scan. |
Дата | |
Msg-id | CAEze2WgFT2zeuAHeNQ=yrdCvgjCEo96DcJY+5UC5WqPC_Wva_A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Incorrect result of bitmap heap scan. ("Core Studios Inc." <corestudiosinc@gmail.com>) |
Список | 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 по дате отправления: