Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)

From: Melanie Plageman <melanieplageman(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, Lukas Fittl <lukas(at)fittl(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Date: 2022-12-06 01:49:20
Message-ID: CAAKRu_YjRaBqhcfzcyr4pqE=6yJrugnikw-ab=BF-f9Wf0K-EQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Attached is v40.

I have addressed the feedback from Justin [1] and Maciek [2] as well.
I took all of the suggestions regarding the docs that Maciek made,
including the following:

> + default. Future values could include those derived from
> + <symbol>XLOG_BLCKSZ</symbol>, once WAL IO is tracked in this view, and
> + constant multipliers once non-block-oriented IO (e.g. temporary file IO)
> + is tracked here.
>
>
> I know Lukas had commented that we should communicate that the goal is
> to eventually provide relatively comprehensive I/O stats in this view
> (you do that in the view description and I think that works), and this
> is sort of along those lines, but I think speculative documentation
> like this is not all that helpful. I'd drop this last sentence. Just
> my two cents.

I have removed this and added the relevant part of this as a comment to
the view generating function pg_stat_get_io().

On Mon, Dec 5, 2022 at 2:32 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> - I think it might be worth to rename IOCONTEXT_BUFFER_POOL to
> IOCONTEXT_{NORMAL, PLAIN, DEFAULT}. I'd like at some point to track WAL IO ,
> temporary file IO etc, and it doesn't seem useful to define a version of
> BUFFER_POOL for each of them. And it'd make it less confusing, because all
> the other existing contexts are also in the buffer pool (for now, can't wait
> for "bypass" or whatever to be tracked as well).

In attached v40, I've renamed IOCONTEXT_BUFFER_POOL to IOCONTEXT_NORMAL.

> - given that IOContextForStrategy() is defined in freelist.c, and that
> declaring it in pgstat.h requires including buf.h, I think it's probably
> better to move IOContextForStrategy()'s declaration to freelist.h (doesn't
> exist, but whatever the right one is)

I have moved it to buf_internals.h.

> - pgstat_backend_io_stats_assert_well_formed() doesn't seem to belong in
> pgstat.c. Why not pgstat_io_ops.c?

I put it in pgstat.c because it is only used there -- so I made it
static. I've moved it to pg_stat_io_ops.c and declared it in
pgstat_internal.h

> - Do pgstat_io_context_ops_assert_zero(), pgstat_io_op_assert_zero() have to
> be in pgstat.h?

They are used in pgstatfuncs.c, which I presume should not include
pgstat_internal.h. Or did you mean that I should not put them in a
header file at all?

- Melanie

[1] https://www.postgresql.org/message-id/20221130025113.GD24131%40telsasoft.com
[2] https://www.postgresql.org/message-id/CAOtHd0BfFdMqO7-zDOk%3DiJTatzSDgVcgYcaR1_wk0GS4NN%2BRUQ%40mail.gmail.com

Attachment Content-Type Size
v40-0002-Track-IO-operation-statistics-locally.patch application/octet-stream 29.4 KB
v40-0003-Aggregate-IO-operation-stats-per-BackendType.patch application/octet-stream 21.6 KB
v40-0001-Remove-BufferAccessStrategyData-current_was_in_r.patch application/octet-stream 5.4 KB
v40-0004-Add-system-view-tracking-IO-ops-per-backend-type.patch application/octet-stream 58.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Richard Guo 2022-12-06 01:58:01 Re: MemoizePath fails to work for partitionwise join
Previous Message Tom Lane 2022-12-06 01:19:26 Re: Error-safe user functions