From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de>, 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-25 03:10:07 |
Message-ID: | 3419998a-0e47-9445-9a71-1cf7bca300d4@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2021/07/25 7:50, Andres Freund wrote:
> Hi,
>
> I've been repeatedly confused by the the number of WAL files supposedly
> added. Even when 100s of new WAL files are created the relevant portion
> of log_checkpoints will only ever list zero or one added WAL file.
>
> The reason for that is that CheckpointStats.ckpt_segs_added is only
> incremented in PreallocXlogFiles(). Which has the following comment:
> * XXX this is currently extremely conservative, since it forces only one
> * future log segment to exist, and even that only if we are 75% done with
> * the current one. This is only appropriate for very low-WAL-volume systems.
>
> Whereas in real workloads WAL files are almost exclusively created via
> XLogWrite()->XLogFileInit().
>
> I think we should consider just removing that field. Or, even better, show
> something accurate instead.
+1 to show something accurate instead.
It's also worth showing them in monitoring stats view like pg_stat_wal?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2021-07-25 03:34:22 | pgsql: Deduplicate choice of horizon for a relation procarray.c. |
Previous Message | Bruce Momjian | 2021-07-25 01:39:34 | Re: Removing "long int"-related limit on hash table sizes |