> 29 марта 2021 г., в 11:26, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
>
> My TODO list:
> 1. Try to break patch set v13-[0001-0004]
> 2. Think how to measure performance of linear search versus hash search in SLRU buffer mapping.
Hi Thomas!
I'm still doing my homework. And to this moment all my catch is that "utils/dynahash.h" is not necessary.
I'm thinking about hashtables and measuring performance near optimum of linear search does not seem a good idea now.
It's impossible to prove that difference is statistically significant on all platforms. But even on one platform
measurementsare just too noisy.
Shared buffers lookup table is indeed very similar to this SLRU lookup table. And it does not try to use more memory
thanneeded. I could not find pgbench-visible impact of growing shared buffer lookup table. Obviously, because it's not
abottleneck on regular workload. And it's hard to guess representative pathological workload.
In fact, this thread started with proposal to use reader-writer lock for multis (instead of exclusive lock), and this
proposalencountered same problem. It's very hard to create stable reproduction of pathological workload when this lock
isheavily contented. Many people observed the problem, but still there is no open repro.
I bet it will be hard to prove that simplehash is any better then HTAB. But if it is really better, shared buffers
couldbenefit from the same technique.
I think its just fine to use HTAB with normal size, as long as shared buffers do so. But there we allocate slightly
morespace InitBufTable(NBuffers + NUM_BUFFER_PARTITIONS). Don't we need to allocate nslots + 1 ? It seems that we
alwaysdo SlruMappingRemove() before SlruMappingAdd() and it is not necessary.
Thanks!
Best regards, Andrey Borodin.