Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN
Date
Msg-id Yku+GopF86WjF26r@jrouhaud
Whole thread Raw
In response to Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN
List pgsql-hackers
On Tue, Apr 05, 2022 at 10:40:04AM +0900, Masahiko Sawada wrote:
> On Tue, Apr 5, 2022 at 1:31 AM Julien Rouhaud <rjuju123@gmail.com> wrote:
> >
> > Yes.  In normal circumstances it shouldn't need a lot of time to do that, but
> > I'm not so sure with e.g. network filesystems.  I'm not strongly in favor of
> > counting it, especially since smgrextend doesn't either.
> 
> Good point. I think that adding a new place to track I/O timing can be
> a separate patch so probably we can work on it for PG16 or later.

Agreed.

> I've attached updated patches, please review it.

It looks good to me, just one minor thing in 002:

@@ -183,8 +184,10 @@ typedef struct Counters
     int64        local_blks_written; /* # of local disk blocks written */
     int64        temp_blks_read; /* # of temp blocks read */
     int64        temp_blks_written;    /* # of temp blocks written */
-    double        blk_read_time;    /* time spent reading, in msec */
-    double        blk_write_time; /* time spent writing, in msec */
+    double        blk_read_time;    /* time spent reading blocks, in msec */
+    double        blk_write_time; /* time spent writing blocks, in msec */
+    double        temp_blk_read_time;    /* time spent reading temp blocks, in msec */
+    double        temp_blk_write_time; /* time spent writing temp blocks, in msec */

maybe the comments should respectively be data file blocks and temp file
blocks.

This is a minor detail and the rest of the patch looks good to me, so I'm
marking the patch as Ready for Committer!



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Skipping logical replication transactions on subscriber side
Next
From: Peter Smith
Date:
Subject: Re: Tablesync early exit