Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, gkokolatos(at)pm(dot)me, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, depesz(at)depesz(dot)com
Subject: Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN
Date: 2022-04-07 07:14:01
Message-ID: Yk6POWRCpk+jcBqS@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
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)
> 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?).

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2022-04-07 07:19:14 Remove error message hints mentioning configure options
Previous Message David Rowley 2022-04-07 07:01:13 Re: Window Function "Run Conditions"