|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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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
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?).
|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"|