Re: PoC: history of recent vacuum/checkpoint runs (using new hooks)

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
>
>

In response to

Browse pgsql-hackers by date

  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