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 Yk6POWRCpk+jcBqS@jrouhaud
Whole thread Raw
In response to Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN  (gkokolatos@pm.me)
Responses Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Thu, Apr 07, 2022 at 03:58:46PM +0900, Michael Paquier wrote:
> On Tue, Apr 05, 2022 at 11:57:14AM +0800, Julien Rouhaud wrote:
> > 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!
> 
> @@ -440,10 +442,14 @@ BufFileLoadBuffer(BufFile *file)
> +   if (track_io_timing)
> +       INSTR_TIME_SET_CURRENT(io_start);
> 
> In places where we don't have clock_gettime(), this means using
> gettimeofday().  I would not underestimate the performance impact of
> such a change, even if track_io_timing is already known to have a
> certain overhead on some platforms.

Sure, but gettimeofday() has been implemented in vDSO for quite some time on
most platforms, so it shouldn't hurt that much on mainstream platforms
especially compared to the cost of whatever operation is actually using that
temporary file.

I don't think that having an extra GUC for temp IO is sensible, if that's why
you're suggesting?  Or are you just asking to do some benchmarking on some
platform where getting the time is known to be slow (Windows?).



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Window Function "Run Conditions"
Next
From: Peter Eisentraut
Date:
Subject: Remove error message hints mentioning configure options