> On 17 Aug 2022, at 00:36, i.lazarev@postgrespro.ru wrote:
>
>> Andrey Borodin wrote 2022-07-23 11:39:
>> Yura, thank you for your benchmarks!
>> We already knew that patch can save the day on pathological workloads,
>> now we have a proof of this.
>> Also there's the evidence that user can blindly increase size of SLRU
>> if they want (with the second patch). So there's no need for hard
>> explanations on how to tune the buffers size.
>
> Hi @Andrey.Borodin, With some considerations and performance checks from @Yura.Sokolov we simplified your approach by
thefollowing:
>
> 1. Preamble. We feel free to increase any SLRU's, since there's no performance degradation on large Buffers count
usingyour SLRU buckets solution.
> 2. `slru_buffers_size_scale` is only one config param introduced for all SLRUs. It scales SLRUs upper cap by power 2.
> 3. All SLRU buffers count are capped by both `MBuffers (shared_buffers)` and `slru_buffers_size_scale`. see
> 4. Magic initial constants `NUM_*_BUFFERS << slru_buffers_size_scale` are applied for every SLRU.
> 5. All SLRU buffers are always sized as power of 2, their hash bucket size is always 8.
>
> There's attached patch for your consideration. It does gather and simplify both
`v21-0001-Make-all-SLRU-buffer-sizes-configurable.patch`and
`v21-0002-Divide-SLRU-buffers-into-8-associative-banks.patch`to much simpler approach.
I like the idea of one knob instead of one per each SLRU. Maybe we even could deduce sane value from NBuffers? That
wouldeffectively lead to 0 knobs :)
Your patch have a prefix "v22-0006", does it mean there are 5 previous steps of the patchset?
Thank you!
Best regards, Andrey Borodin.
