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

From Andrey Borodin
Subject Re: MultiXact\SLRU buffers configuration
Date
Msg-id D330C01E-789A-4DDD-B2B1-4561B8B7F41D@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  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
Hi Thomas, Gilles, all!

Thanks for reviewing this!

> 25 марта 2021 г., в 02:31, Thomas Munro <thomas.munro@gmail.com> написал(а):
>
> I don't think we should put "slru" (the name of the buffer replacement
> algorithm, implementation detail) in the GUC names.
+1


> +        It defaults to 0, in this case CLOG size is taken as
> <varname>shared_buffers</varname> / 512.
>
> We already know that increasing the number of CLOG buffers above the
> current number hurts as the linear search begins to dominate
Uh, my intent was to copy original approach of CLOG SLRU size, I just missed that Min(,) thing in shared_buffers logic.


> 26 марта 2021 г., в 08:46, Thomas Munro <thomas.munro@gmail.com> написал(а):
>
> Hi Andrey, all,
>
> I propose some changes, and I'm attaching a new version:
>
> I renamed the GUCs as clog_buffers etc (no "_slru_").  I fixed some
> copy/paste mistakes where the different GUCs were mixed up.  I made
> some changes to the .conf.sample.  I rewrote the documentation so that
> it states the correct unit and defaults, and refers to the
> subdirectories that are cached by these buffers instead of trying to
> give a new definition of each of the SLRUs.
>
> Do you like those changes?
Yes!

> Some things I thought about but didn't change:
>
> I'm not entirely sure if we should use the internal and historical
> names well known to hackers (CLOG), or the visible directory names (I
> mean, we could use pg_xact_buffers instead of clog_buffers).
While it is good idea to make notes about directory name, I think the real naming criteria is to help find this GUC
whenuser encounters wait events in pg_stat_activity. I think there is no CLOG mentions in docs [0], only XactBuffer,
XactSLRUet c. 

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

Best regards, Andrey Borodin.

[0] https://www.postgresql.org/docs/current/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEW


pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: "Joel Jacobson"
Date:
Subject: Re: [PATCH] pg_permissions