Re: MultiXact\SLRU buffers configuration

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Gilles Darold <gilles(at)darold(dot)net>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: MultiXact\SLRU buffers configuration
Date: 2021-04-11 18:37:21
Message-ID: 494C5E7F-E410-48FA-A93E-F7723D859561@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 8 апр. 2021 г., в 15:22, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> написал(а):
>
> On Thu, Apr 8, 2021 at 7:24 PM Andrey Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>> I agree that this version of eviction seems much more effective and less intrusive than RR. And it's still LRU, which is important 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! I chickened out of committing a buffer replacement algorithm
> patch written 11 hours before the feature freeze, but I also didn't
> really want to commit the GUC patch without that. Ahh, if only we'd
> latched onto the real problems here just a little sooner, but there is
> always PostgreSQL 15, I heard it's going to be amazing. Moved to next
> CF.

I have one more idea inspired by CPU caches.
Let's make SLRU n-associative, where n ~ 8.
We can divide buffers into "banks", number of banks must be power of 2.
All banks are of equal size. We choose bank size to approximately satisfy user's configured buffer size.
Each page can live only within one bank. We use same search and eviction algorithms as we used in SLRU, but we only need to search\evict over 8 elements.
All SLRU data of a single bank will be colocated within at most 2 cache line.

I did not come up with idea how to avoid multiplication of bank_number * bank_size in case when user configured 31337 buffers (any number that is radically not a power of 2).

PFA patch implementing this idea.

Best regards, Andrey Borodin.

Attachment Content-Type Size
v17-0002-Divide-SLRU-buffers-into-n-associative-banks.patch application/octet-stream 4.2 KB
v17-0001-Make-all-SLRU-buffer-sizes-configurable.patch application/octet-stream 25.7 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ranier Vilela 2021-04-11 18:38:10 Uninitialized scalar variable (UNINIT) (src/backend/statistics/extended_stats.c)
Previous Message Peter Geoghegan 2021-04-11 18:28:22 Re: PANIC: wrong buffer passed to visibilitymap_clear