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 <and...@anarazel.de> > Author: Lukas Fittl <lu...@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
signature.asc
Description: PGP signature
