Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN
Julien Rouhaud <rjuju123@gmail.com>
From: Julien Rouhaud <rjuju123@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, gkokolatos@pm.me, Ranier Vilela <ranier.vf@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>, depesz@depesz.com
Date: 2022-04-07T07:14:01Z
Lists: 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?).
Commits
-
pg_stat_statements: Track I/O timing for temporary file blocks
- 76cbf7edb638 15.0 landed
-
Track I/O timing for temporary file blocks in EXPLAIN (BUFFERS)
- efb0ef909f60 15.0 landed
-
Force track_io_timing off in explain.sql to avoid failures when enabled.
- 7e12256b478b 15.0 cited