| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, tender wang <tndrwang(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
| Date: | 2024-02-23 11:48:11 |
| Message-ID: | 202402231148.lqruleoappvd@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2024-Feb-23, Andrey M. Borodin wrote:
> I'm sure anyone with multiple CPUs should increase, not decrease
> previous default of 128 buffers (with 512MB shared buffers). Having
> more CPUs (the only way to benefit from more locks) implies bigger
> transaction buffers.
Sure.
> IMO making bank size variable adds unneeded computation overhead, bank
> search loops should be unrollable by compiler etc.
Makes sense.
> Originally there was a patch set step, that packed bank's page
> addresses together in one array. It was done to make bank search a
> SIMD instruction.
Ants Aasma had proposed a rework of the LRU code for better performance.
He told me it depended on bank size being 16, so you're right that it's
probably not a good idea to make it variable.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nazir Bilal Yavuz | 2024-02-23 12:09:26 | Re: Add missing error codes to PANIC/FATAL error reports in xlog.c and relcache.c |
| Previous Message | Bertrand Drouvot | 2024-02-23 11:15:51 | Re: Synchronizing slots from primary to standby |