Re: MultiXact\SLRU buffers configuration - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: MultiXact\SLRU buffers configuration
Date
Msg-id 75B95FDD-2BE0-4525-8BDD-FC67C8BCBD53@yandex-team.ru
Whole thread Raw
In response to Re: MultiXact\SLRU buffers configuration  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: MultiXact\SLRU buffers configuration  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers

> 26 марта 2021 г., в 11:00, Andrey Borodin <x4mmm@yandex-team.ru> написал(а):
>
>> I'm not saying the 0002 patch is bug-free yet though, it's a bit finickity.
> I think the idea of speeding up linear search is really really good for scaling SLRUs. It's not even about improving
normalperformance of the cluster, but it's important from preventing pathological degradation under certain
circumstances.Bigger cache really saves SLAs :) I'll look into the patch more closely this weekend. Thank you! 


Some thoughts on HashTable patch:
1. Can we allocate bigger hashtable to reduce probability of collisions?
2. Can we use specialised hashtable for this case? I'm afraid hash_search() does comparable number of CPU cycles as
simplecycle from 0 to 128. We could inline everything and avoid hashp->hash(keyPtr, hashp->keysize) call. I'm not
insistingon special hash though, just an idea. 
3. pageno in SlruMappingTableEntry seems to be unused.

Thanks!

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: "蔡梦娟(玊于)"
Date:
Subject: Bug on update timing of walrcv->flushedUpto variable
Next
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes