Hi Andres,
On Sat, Jan 21, 2023 at 05:25:19AM +0000, Andres Freund wrote:
> instr_time: Represent time as an int64 on all platforms
>
> Until now we used struct timespec for instr_time on all platforms but
> windows. Using struct timespec causes a fair bit of memory (struct timeval is
> 16 bytes) and runtime overhead (much more complicated additions). Instead we
> can convert the time to nanoseconds in INSTR_TIME_SET_CURRENT(), making the
> remaining operations cheaper.
>
> Representing time as int64 nanoseconds provides sufficient range, ~292 years
> relative to a starting point (depending on clock source, relative to the unix
> epoch or the system's boot time). That'd not be sufficient for calendar time
> stored on disk, but is plenty for runtime interval time measurement.
>
> On windows instr_time already is represented as cycles. It might make sense to
> represent time as cycles on other platforms as well, as using cycle
> acquisition instructions like rdtsc directly can reduce the overhead of time
> acquisition substantially. This could be done in a fairly localized manner as
> the code stands after this commit.
>
> Because the windows and non-windows paths are now more similar, use a common
> set of macros. To make that possible, most of the use of LARGE_INTEGER had to
> be removed, which looks nicer anyway.
>
> To avoid users of the API relying on the integer representation, we wrap the
> 64bit integer inside struct struct instr_time.
>
> Author: Andres Freund <andres@anarazel.de>
> Author: Lukas Fittl <lukas@fittl.com>
hoverfly is unhappy since this went in:
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hoverfly&dt=2023-01-23%2005%3A01%3A44
"../../../src/include/portability/instr_time.h", line 116.9: 1506-304 (I) No function prototype given for
"clock_gettime".
"../../../src/include/portability/instr_time.h", line 116.23: 1506-045 (S) Undeclared identifier CLOCK_REALTIME.
<builtin>: recipe for target 'plpy_cursorobject.o' failed
Thanks,
--
Michael
