Re: MultiXact\SLRU buffers configuration

> 7 апр. 2021 г., в 08:59, Thomas Munro <thomas.munro@gmail.com> написал(а):
>
> The remaining thing that bothers me about this patch set is that there is still a linear search in the replacement
algorithm,and it runs with an exclusive lock.  That creates a serious problem for large caches that still aren't large
enough. I wonder if we can do something to improve that situation in the time we have.  I considered a bunch of ideas
butcould only find one that fits with slru.c's simplistic locking while tracking recency.  What do you think about a
hybridof SLRU and random replacement, that retains some characteristics of both?  You could think of it as being a bit
likethe tournament selection of the genetic algorithm, with a tournament size of (say) 8 or 16.  Any ideas on how to
evaluatethis and choose the number?  See attached. 
>
<v15-0001-Add-a-buffer-mapping-table-for-SLRUs.patch><v15-0002-Make-all-SLRU-buffer-sizes-configurable.patch><v15-0003-Use-hybrid-random-SLRU-replacement-for-SLRUs.patch>

Maybe instead of fully associative cache with random replacement we could use 1-associative cache?
i.e. each page can reside only in one spcific buffer slot. If there's something else - evict it.
I think this would be as efficient as RR cache. And it's soooo fast.

Best regards, Andrey Borodin.