| 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: | Whole Thread | Raw Message | 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 |