Re: strange perf regression with data checksums

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: strange perf regression with data checksums
Date: 2025-05-19 18:44:16
Message-ID: CAH2-Wzku139FB465_tukpi1gjHzsddEr0ZNA8zf1TexoFU1k6A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 19, 2025 at 2:19 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> On Mon, May 19, 2025 at 2:01 PM Tomas Vondra <tomas(at)vondra(dot)me> wrote:
> > The regular index scan however still have this issue, although it's not
> > as visible as for IOS.
>
> We can do somewhat better with plain index scans than my initial v1
> prototype, without any major difficulties. There's more low-hanging
> fruit.
>
> We could also move the call to BufferGetLSNAtomic (that currently
> takes place inside _bt_readpage) over to _bt_drop_lock_and_maybe_pin.
> That way we'd only need to call BufferGetLSNAtomic for those leaf
> pages that will actually need to have some index tuples returned to
> the scan (through the btgettuple interface).

Attached is v2, which does things this way. What do you think?

v2 also manages to avoid calling BufferGetLSNAtomic during all bitmap
index scans. You didn't complain about any regressions in bitmap index
scans, but I see no reason to take any chances (it's easy to just not
call BufferGetLSNAtomic there).

--
Peter Geoghegan

Attachment Content-Type Size
v2-0001-Avoid-BufferGetLSNAtomic-calls-during-nbtree-scan.patch application/octet-stream 8.8 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Vik Fearing 2025-05-19 19:01:39 Re: Should we optimize the `ORDER BY random() LIMIT x` case?
Previous Message Peter Geoghegan 2025-05-19 18:19:30 Re: strange perf regression with data checksums