Re: ReadRecentBuffer() doesn't scale well - Mailing list pgsql-hackers

From Andres Freund
Subject Re: ReadRecentBuffer() doesn't scale well
Date
Msg-id wbmtz3b4cm3zwcsfunymbaauu7dlwbimzma7tsyjtg3npqy546@tj6oqcktgjvh
Whole thread Raw
In response to RE: ReadRecentBuffer() doesn't scale well  (Ilyasov Ian <ianilyasov@outlook.com>)
Responses RE: ReadRecentBuffer() doesn't scale well
List pgsql-hackers
Hi,

On 2026-01-22 08:37:56 +0000, Ilyasov Ian wrote:
> Speaking of this patch, I've done a benchmark test on a master branch on 34740b90bc123d645a3a71231b765b778bdcf049
commitwith a patch by Thomas Munro:
https://www.postgresql.org/message-id/attachment/148040/0002-Use-ReadRecentBuffer-for-btree-root-page.patchand without
it.The configuration of the server was 96 cores and 1.5 TB of RAM.
 

Which patch specifically do you mean?

An evolved version of 0001 from
https://postgr.es/m/CA%2BhUKGJ8N_DRSB0YioinWjS2ycMpmOLy32mbBqVVztwBvXgyJA%40mail.gmail.com
has already been applied (see 819dc118c0f).

So I guess you were testing 0002 from that email?

Or were you testing 0002 from
https://postgr.es/m/CA%2BhUKGLMFtNqei9nfcJy2SQMLWyYuO9E8NLYrb%3D4Gs1HgkAS7Q%40mail.gmail.com
which is a completely different patch?


> My conclusion is that this patch looks excellent on multicore systems and it would be great if it is committed.
> Also I have a question if committed whether this patch would be backported to 18th version?

We don't backpatch performance improvements unless they are addressing
performance issues that are so severe that they basically amount to a bug.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: Flush some statistics within running transactions
Next
From: Andres Freund
Date:
Subject: Re: Likely undefined behavior with some flexible arrays