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

From Andrey Borodin
Subject Re: MultiXact\SLRU buffers configuration
Date
Msg-id B8FACD14-E3AB-4EB3-8CCC-E93697C54F72@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

> 8 апр. 2021 г., в 03:30, Thomas Munro <thomas.munro@gmail.com> написал(а):
>
> Here's another approach that is a little less exciting than
> "tournament RR" (or whatever that should be called; I couldn't find an
> established name for it).  This version is just our traditional linear
> search, except that it stops at 128, and remembers where to start from
> next time (like a sort of Fisher-Price GCLOCK hand).  This feels more
> committable to me.  You can argue that all buffers above 128 are bonus
> buffers that PostgreSQL 13 didn't have, so the fact that we can no
> longer find the globally least recently used page when you set
> xact_buffers > 128 doesn't seem too bad to me, as an incremental step
> (but to be clear, of course we can do better than this with more work
> in later releases).
I agree that this version of eviction seems much more effective and less intrusive than RR. And it's still LRU, which
isimportant for subsystem that is called SLRU. 
shared->search_slotno is initialized implicitly with memset(). But this seems like a common practice.
Also comment above "max_search = Min(shared->num_slots, MAX_REPLACEMENT_SEARCH);" does not reflect changes.

Besides this patch looks good to me.

Thanks!

Best regards, Andrey Borodin.


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Support tab completion for upper character inputs in psql
Next
From: Ajin Cherian
Date:
Subject: Re: missing documentation for streaming in-progress transactions