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

From Andrey Borodin
Subject Re: MultiXact\SLRU buffers configuration
Date
Msg-id B7D61584-6CAC-4CF9-B3D4-7CC52D6C4C5C@yandex-team.ru
Whole thread Raw
In response to Re: MultiXact\SLRU buffers configuration  (Thomas Munro <thomas.munro@gmail.com>)
Responses Re: MultiXact\SLRU buffers configuration
List pgsql-hackers

> 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.


pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Set access strategy for parallel vacuum workers
Next
From: David Rowley
Date:
Subject: Re: Wired if-statement in gen_partprune_steps_internal