| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| Cc: | Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "bharath(dot)rupireddyforpostgres(at)gmail(dot)com" <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
| Subject: | Re: Show WAL write and fsync stats in pg_stat_io |
| Date: | 2023-11-07 23:30:48 |
| Message-ID: | 20231107233048.b46ygiw37jzvitn6@awork3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2023-10-26 15:28:32 +0900, Michael Paquier wrote:
> On top of that pg_stat_io is now for block-based I/O operations, so
> that does not fit entirely in the picture, though I guess that Melanie
> has thought more on the matter than me. That may be also a matter of
> taste.
I strongly disagree. A significant part of the design of pg_stat_io was to
make it possible to collect multiple sources of IO in a single view, so that
sysadmins don't have to look in dozens of places to figure out what is causing
what kind of IO.
We should over time collect all sources of IO in pg_stat_io. For some things
we might want to also have more detailed information in other views (e.g. it
doesn't make sense to track FPIs in pg_stat_io, but does make sense in
pg_stat_wal) - but that should be in addition, not instead of.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dean Rasheed | 2023-11-07 23:42:13 | Re: Infinite Interval |
| Previous Message | Michael Paquier | 2023-11-07 23:12:50 | Re: speed up a logical replica setup |