| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Michael Banck <mbanck(at)gmx(dot)net> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Cleaning up historical portability baggage |
| Date: | 2025-06-10 21:26:46 |
| Message-ID: | 804572.1749590806@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Michael Banck <mbanck(at)gmx(dot)net> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2025-06-10 21:28:15 | Re: add function for creating/attaching hash table in DSM registry |
| Previous Message | Michael Banck | 2025-06-10 21:09:31 | Re: Safeguards against incorrect fd flags for fsync() |