From: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> |
Subject: | Re: per backend WAL statistics |
Date: | 2025-02-18 10:45:29 |
Message-ID: | Z7RkyRCvK2fG7VXc@ip-10-97-1-34.eu-west-3.compute.internal |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On Tue, Feb 18, 2025 at 08:34:32AM +0900, Michael Paquier wrote:
> On Mon, Feb 17, 2025 at 03:14:59PM +0000, Bertrand Drouvot wrote:
> > PFA the whole picture. 0001 is implementing the fields removal in pg_stat_wal
> > (and also PendingWalStats). I think that's ok given the backend's type for which
> > pgstat_tracks_io_bktype() returns false. But now you make me doubt about 0001.
>
> Double-checking the code now and my doubts are wrong.
Thanks for double checking.
> I think that I would vote for a removal of the fields from pg_stat_wal
> rather than a replacement in pg_stat_wal, for the following reasons:
> - pg_stat_stat.wal_write is the same value as "select sum(writes)
> from pg_stat_io where object = 'wal' and context = 'normal'" as these
> are incremented in XLogWrite().
> - Same argument about pg_stat_wal.wal_write_time with
> pg_stat_io.write_time.
> - issue_xlog_fsync() tells that pg_stat_wal.wal_sync_time and
> sum(pg_stat_io.fsync_time) under object=wal and context=normal are the
> same values.
> - Same argument with the fsync counters pg_stat_wal.wal_sync and
> pg_stat_io.fsyncs.
> - Encourage monitoring pull to move to pg_stat_io, where there is much
> more context and granularity of the stats data.
Agree with all of the above + pgstat_tracks_io_bktype() returns false for backend's
that do not generate WAL (so that we don't lose WAL information in pg_stat_io).
> Regarding the GUC track_wal_io_timing, my take is that we'll live
> better if we just let it go. It loses its meaning once pg_stat_wal
> does not track the write and sync timings.
Yeah, done that way in the dedicated thread ([1]).
> > Anyway, it's probably better to move the 0001 discussion to a dedicated thread,
> > thoughts?
>
> Yes. And we cannot really move forward with what we have here without
> deciding about this part. The simplifications I can read from
> v7-0002~v7-0004 are really nice. These make the implementation of WAL
> stats at backend-level really simpler to think about.
yup.
> The doc additions of v7-0001 about the description of what the 'wal'
> object does in pg_stat_io are actually worth a change of their own?
> We already track them in pg_stat_io.
Agree, done that way in the dedicated thread ([1]).
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ashutosh Sharma | 2025-02-18 10:46:02 | Orphaned Files in PostgreSQL |
Previous Message | Bertrand Drouvot | 2025-02-18 10:43:15 | Remove wal_[sync|write][_time] from pg_stat_wal and track_wal_io_timing |