Re: Make pg_stat_io view count IOs as bytes instead of blocks

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Cc: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Make pg_stat_io view count IOs as bytes instead of blocks
Date: 2025-01-10 01:46:46
Message-ID: Z4B8Blfjn9lnZOYF@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 09, 2025 at 03:30:37PM +0000, Bertrand Drouvot wrote:
> We first use an Assert in is_ioop_tracked_in_bytes() and then we return
> a value "just" to check another Assert. I wonder if it wouldn't make more sense
> to get rid of this function and use a macro instead, something like?
>
> #define is_ioop_tracked_in_bytes(io_op) \
> ((io_op) < IOOP_NUM_TYPES && (io_op) >= IOOP_EXTEND)

Indeed. Your suggestion to use a macro makes more sense to me because
is_ioop_tracked_in_bytes() itself has an Assert(), while being itself
only used in an assertion, as you say. Better to document the
dependency on the ordering of IOOp, even if that's kind of hard to
miss.

> v7-0002:
>
> I wonder if it wouldn't make more sense to remove pgstat_count_io_op() first
> and then implement what currently is in v7-0001. What v7-0002 is removing is
> not produced by v7-0001.

This kind of cleanup should happen first, and it simplifies a bit the
reading of v7-0001 as we would just append a new argument to the
count_io_op() routine for the number of bytes. I was looking at that
and chose to stick with count_io_op() rather than count_io_op_n() as
we would have only one routine.

pgstat_count_io_op_time(IOOBJECT_RELATION, io_context, IOOP_EXTEND,
- io_start, extend_by);
+ io_start, 1, extend_by * BLCKSZ);
[...]
pgstat_count_io_op_time(IOOBJECT_TEMP_RELATION, IOCONTEXT_NORMAL, IOOP_EXTEND,
- io_start, extend_by);
+ io_start, 1, extend_by * BLCKSZ);

Something worth mentioning. I had a small doubt about this one for
temp and persistent relations, as it changes the extend count.
Anyway, I think that this is better: we are only doing one extend
batch, worth (extend_by * BLCKSZ).

Two times my fault today that the main patch does not apply anymore
(three times at least in total), so I have rebased it myself, and did
an extra review while on it, switching the code to use a macro. That
seems OK here. Please let me know if you have more comments.

(Still need to spend more time on the commit message, will do that
later).
--
Michael

Attachment Content-Type Size
v8-0001-Make-pg_stat_io-count-IOs-as-bytes-instead-of-blo.patch text/x-diff 23.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tatsuo Ishii 2025-01-10 02:31:34 Re: Proposal: add new API to stringinfo
Previous Message wenhui qiu 2025-01-10 01:45:42 Re: New GUC autovacuum_max_threshold ?