Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?) - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Date
Msg-id CAAKRu_YLnLB6fQjqs50wo-K3rt9KoufzXCrJqkz45nd7AvJOug@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)  (Andres Freund <andres@anarazel.de>)
Responses Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
List pgsql-hackers
On Wed, Dec 28, 2022 at 6:56 PM Andres Freund <andres@anarazel.de> wrote:
>
> FWIW, I've been hacking on this code a bunch, mostly around renaming things
> and changing the 'stacking' of the patches. My current state is at
> https://github.com/anarazel/postgres/tree/pg_stat_io
> A bit more to do before posting the edited version...

Here is the bit more done.
I've attached a new version 42 which incorporates all of Andres' changes
on his branch (which I am considering version 41).
I have fixed various issues with counting fsyncs and added more comments
and done cosmetic cleanup.

The docs have substantial changes but still require more work:

- The comparisons between columns in pg_stat_io and pg_stat_statements
  have been removed, since the granularity and lifetime are so
  different, comparing them isn't quite correct.

- The lists of backend types still take up a lot of visual space in the
  definitions, which doesn't look great. I'm not sure what to do about
  that.

- Andres has pointed out that it is difficult to read the definitions of
  the columns because of the added clutter of the interpretations and
  the comparisons to other stats views. I'm not sure if I should cut
  these. He and I tried adding that information as a note and in other
  various table types, however none of the alternatives were an
  improvement.

Besides docs, there is one large change to the code which I am currently
working on, which is to change PgStat_IOOpCounters into an array of
PgStatCounters instead of having individual members for each IOOp type.
I hadn't done this previously because the additional level of nesting
seemed confusing. However, it seems it would simplify the code quite a
bit and is probably worth doing.

- Melanie

Attachment

pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: TAP tests for psql \g piped into program
Next
From: Andres Freund
Date:
Subject: Re: perl 5.36, C99, -Wdeclaration-after-statement -Wshadow=compatible-local