From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Remove wal_[sync|write][_time] from pg_stat_wal and track_wal_io_timing |
Date: | 2025-02-24 09:41:36 |
Message-ID: | 3opf2wh2oljco6ldyqf7ukabw3jijnnhno6fjb4mlu6civ5h24@fcwmhsgmlmzu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2025-02-20 14:37:18 +0900, Michael Paquier wrote:
> a051e71e28a added this information into pg_stat_io (with more details and
> granularity), so there is no need to keep it in pg_stat_wal. This also
> allows to remove PendingWalStats and simplifies up coming commits related
> to per backend WAL statistics. Once done, track_wal_io_timing becomes useless
> so it is also removed.
>
> In passing remove the pgstat_prepare_io_time() parameter now that
> track_wal_io_timing is gone.
I don't think this is a good idea - there was a good reason for
track_wal_io_timing to exist, namely that it happens while holding one of the
two most contended locks in postgres. On many systems it'll be an ok constant
overhead to enable track_io_timing, but enabling track_wal_io_timing will
cause scalability issues. Now you made it impossible to separate those two
situations, forcing disabling of all IO timing.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2025-02-24 09:49:49 | Re: long-standing data loss bug in initial sync of logical replication |
Previous Message | Shubham Khanna | 2025-02-24 09:21:05 | Re: Adding a '--two-phase' option to 'pg_createsubscriber' utility. |