instr_time: Represent time as an int64 on all platforms
authorAndres Freund <[email protected]>
Sat, 21 Jan 2023 05:16:47 +0000 (21:16 -0800)
committerAndres Freund <[email protected]>
Sat, 21 Jan 2023 05:16:47 +0000 (21:16 -0800)
commit03023a2664f8950ad522385ff75ce004bc932a7c
tree952298391848ae154968f37f726a5734cc47d543
parent25b2aba0c3a501e2af9579f1b629f155544935db
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 <[email protected]>
Author: Lukas Fittl <[email protected]>
Author: David Geier <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/20230113195547[email protected]
src/include/portability/instr_time.h