Re: Incorrect result of bitmap heap scan.
От | Core Studios Inc. |
---|---|
Тема | Re: Incorrect result of bitmap heap scan. |
Дата | |
Msg-id | bd8b9bd6-d51f-466b-b578-47dedb2a0687@gmail.com обсуждение исходный текст |
Ответ на | Re: Incorrect result of bitmap heap scan. (Matthias van de Meent <boekewurm+postgres@gmail.com>) |
Ответы |
Re: Incorrect result of bitmap heap scan.
Re: Incorrect result of bitmap heap scan. |
Список | pgsql-hackers |
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? Thanks On 3/5/25 1:12 PM, Matthias van de Meent wrote: > On Sun, 2 Mar 2025 at 01:35, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Peter Geoghegan <pg@bowt.ie> writes: >>> Is everybody in agreement about committing and back patching this fix, >>> which simply disables the optimization altogether? >>> I myself don't see a better way, but thought I'd ask before proceeding >>> with review and commit. >> If you don't see a clear path forward, then "disable" is the only >> reasonable choice for the back branches. Maybe we'll find a fix >> in future, but it seems unlikely that it'd be back-patchable. > Agreed. > > Here's patch v5 for the master branch (now up to f4694e0f), with no > interesting changes other than fixing apply conflicts caused by > bfe56cdf. > > Kind regards, > > Matthias van de Meent > Neon (https://neon.tech)
В списке pgsql-hackers по дате отправления: