From: | wenhui qiu <qiuwenhuifx(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | Robert Treat <rob(at)xzilla(dot)net>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PoC: history of recent vacuum/checkpoint runs (using new hooks) |
Date: | 2024-12-27 02:04:48 |
Message-ID: | CAGjGUAJUV=TngFFjOYRQCj2V-YvGOHsU0oL2vQvAysLmT_zZog@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)vondra(dot)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
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2024-12-27 03:32:25 | WAL-logging facility for pgstats kinds |
Previous Message | Bruce Momjian | 2024-12-27 01:47:19 | Re: Support for unsigned integer types |