Re: PoC: history of recent vacuum/checkpoint runs (using new hooks)
| От | wenhui qiu |
|---|---|
| Тема | Re: PoC: history of recent vacuum/checkpoint runs (using new hooks) |
| Дата | |
| Msg-id | CAGjGUAJUV=TngFFjOYRQCj2V-YvGOHsU0oL2vQvAysLmT_zZog@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: PoC: history of recent vacuum/checkpoint runs (using new hooks) (Tomas Vondra <tomas@vondra.me>) |
| Список | 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).
> 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 по дате отправления: