Re: Cleaning up historical portability baggage

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> Yeah, that's not true anymore, and QueryPerformanceCounter() is faster
> than Get­System­Time­Precise­As­File­Time()[1], but there doesn't
> really seem to be any point in mentioning that or gettimeofday() at
> all here. I propose to cut it down to just:

> * This file provides an abstraction layer to hide portability issues in
> - * interval timing. On Unix we use clock_gettime() if available, else
> - * gettimeofday(). On Windows, gettimeofday() gives a low-precision result
> - * so we must use QueryPerformanceCounter() instead. These macros also give
> - * some breathing room to use other high-precision-timing APIs.
> + * interval timing. On Unix we use clock_gettime(), and on Windows we use
> + * QueryPerformanceCounter(). These macros also give some breathing room to
> + * use other high-precision-timing APIs.

WFM.

> FWIW I expect this stuff to get whacked around some more for v16[2].
> [2] https://commitfest.postgresql.org/39/3751/

Meh. I think trying to use rdtsc is a fool's errand; you'll be fighting
CPU quirks forever.

regards, tom lane