From: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: log_checkpoint's "WAL file(s) added" is misleading to the point of uselessness |
Date: | 2021-07-27 03:39:38 |
Message-ID: | 50180873-DAD9-483C-8FD8-48F62FD32A4A@amazon.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 7/26/21, 5:48 PM, "Andres Freund" <andres(at)anarazel(dot)de> wrote:
> On 2021-07-26 20:27:21 +0000, Bossart, Nathan wrote:
>> +1. I was confused by this when working on a WAL pre-allocation
>> patch [0]. Perhaps it could be replaced by a new parameter and a new
>> field in pg_stat_wal. How about something like log_wal_init_interval,
>> where the value is the minimum amount of time between reporting the
>> number of WAL segments created since the last report?
>
> Why not just make the number in log_checkpoints accurate? There's no
> point in the current number, so we don't need to preserve it...
My understanding is that the statistics logged for log_checkpoints are
just for that specific checkpoint. From that angle, the value for the
number of WAL files added is technically correct. Checkpoints will
only ever create zero or one new files via PreallocXlogFiles(). If we
also added all the segments created outside of the checkpoint, the
value for "added" would go from meaning "WAL files created by this
checkpoint" to "WAL files creates since the last checkpoint." That's
probably less confusing than what's there today, but it's still
slightly different than all the other log_checkpoints stats.
Nathan
From | Date | Subject | |
---|---|---|---|
Next Message | Masahiko Sawada | 2021-07-27 04:06:56 | Re: [PoC] Improve dead tuple storage for lazy vacuum |
Previous Message | Greg Nancarrow | 2021-07-27 03:08:26 | Re: Slim down integer formatting |