Re: Cleaning up historical portability baggage - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Cleaning up historical portability baggage
Date
Msg-id [email protected]
Whole thread Raw
In response to Re: Cleaning up historical portability baggage  (Michael Banck <[email protected]>)
List pgsql-hackers
Michael Banck <[email protected]> writes:
> 2. The fact that nobody else complained about those new(er) timestamp-
> comparison additions appears to imply that there are no 100ms resolution
> machines we support anymore. So did we consider switching those
> pg_sleep(0.1) calls in stats.sql to pg_sleep(0.01) to save a bit of
> time?

Yeah, we realized last year that no supported platform has worse than
1usec gettimeofday resolution anymore [1].  So I think you're right
that we could shave some milliseconds off stats.sql, as well as some
other test scripts.  I doubt this'd make for a meaningful time
savings, but perhaps it's worth doing just for consistency: grepping
for pg_sleep in our tests, I see anywhere from 0.1 to 0.001 sec.

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/[email protected]



pgsql-hackers by date:

Previous
From: Michael Banck
Date:
Subject: Re: Safeguards against incorrect fd flags for fsync()
Next
From: Sami Imseih
Date:
Subject: Re: add function for creating/attaching hash table in DSM registry