Re: PoC: history of recent vacuum/checkpoint runs (using new hooks) - Mailing list pgsql-hackers

From wenhui qiu
Subject Re: PoC: history of recent vacuum/checkpoint runs (using new hooks)
Date
Msg-id CAGjGUAJUV=TngFFjOYRQCj2V-YvGOHsU0oL2vQvAysLmT_zZog@mail.gmail.com
Whole thread Raw
In response to Re: PoC: history of recent vacuum/checkpoint runs (using new hooks)  (Tomas Vondra <tomas@vondra.me>)
List pgsql-hackers
Hi Tomas 

> If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
> make a fundamental difference ...
agree 
> Anyway, the 128MB value is rather arbitrary. I don't mind increasing the
> limit, or possibly removing it entirely (and accepting anything the
> system can handle).
yes,   I mean by this is that the maximum value is not friendly to large instances if the setting is small ,In the real production  instance , many sub-tables with the same table structure are often encountered 


On Fri, Dec 27, 2024 at 1:58 AM Tomas Vondra <tomas@vondra.me> wrote:
On 12/26/24 17:00, wenhui qiu wrote:
> Hi 
>    
> As far as I know, more than 10,000 tables  of instances  are often
> encountered,
> So I insist that the maximum can be appropriately increased to 256MB,
> Can be more adaptable to many table situations
>

If 128MB is insufficient, why would 256MB be OK? A factor of 2x does not
make a fundamental difference ...

Anyway, the 128MB value is rather arbitrary. I don't mind increasing the
limit, or possibly removing it entirely (and accepting anything the
system can handle).


regards

--
Tomas Vondra

pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Support for unsigned integer types
Next
From: vignesh C
Date:
Subject: Re: Introduce XID age and inactive timeout based replication slot invalidation