From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Ants Aasma <ants(at)cybertec(dot)at>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Date: | 2023-11-10 04:47:49 |
Message-ID: | CAFiTN-v7bQHfZqgt7Wk9PzUVXJkG-wh8ws1a=WjKjjGjP5uewg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 9, 2023 at 4:55 PM Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> IMO the whole area of SLRU buffering is in horrible shape and many users
> are struggling with overall PG performance because of it. An
> improvement doesn't have to be perfect -- it just has to be much better
> than the current situation, which should be easy enough. We can
> continue to improve later, using more scalable algorithms or ones that
> allow us to raise the limits higher.
I agree with this.
> The only point on which we do not have full consensus yet is the need to
> have one GUC per SLRU, and a lot of effort seems focused on trying to
> fix the problem without adding so many GUCs (for example, using shared
> buffers instead, or use a single "scaling" GUC). I think that hinders
> progress. Let's just add multiple GUCs, and users can leave most of
> them alone and only adjust the one with which they have a performance
> problems; it's not going to be the same one for everybody.
+1
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2023-11-10 05:41:24 | Re: Synchronizing slots from primary to standby |
Previous Message | Dilip Kumar | 2023-11-10 04:46:29 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |