From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Banck <mbanck@gmx.net>
cc: Thomas Munro <thomas.munro@gmail.com>, Andres Freund <andres@anarazel.de>,
        Andrew Dunstan <andrew@dunslane.net>,
        Robert Haas <robertmhaas@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Cleaning up historical portability baggage
In-reply-to: <68489e08.df0a0220.3c14af.fdc6@mx.google.com>
References: <3322724.1659586159@sss.pgh.pa.us>
 <CA+hUKGJ5ej33AJL19sQph7Z8SFZ6+aUSKxFTS6pvk2Y8J9Tcwg@mail.gmail.com>
 <295419.1659918447@sss.pgh.pa.us>
 <CA+hUKGK=N8W2uFPdJr07Rs4dgRtbzKaYvCaPQasX3S8=aTO5PQ@mail.gmail.com>
 <747620.1660002360@sss.pgh.pa.us>
 <CA+hUKG+L_3brvh=8e0BW_VfX9h7MtwgN=nFHP5o7X2oZucY9dg@mail.gmail.com>
 <6846e0c3.df0a0220.39ef9b.c60e@mx.google.com>
 <n5hjl2cvnfr3oitguk5qmyep3ffb6ii5pfzcyezg4mjfb3ocqp@lt7iej77xiqw>
 <CA+hUKG+tqFVY7Fi=WBvZ6-UsATjcPNBDtphDm7YLjevm2kxSvw@mail.gmail.com>
 <68481005.df0a0220.23c1b8.78ca@mx.google.com>
 <68489e08.df0a0220.3c14af.fdc6@mx.google.com>
Comments: In-reply-to Michael Banck <mbanck@gmx.net>
	message dated "Tue, 10 Jun 2025 23:05:11 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <804571.1749590806.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Tue, 10 Jun 2025 17:26:46 -0400
Message-ID: <804572.1749590806@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/804572.1749590806%40sss.pgh.pa.us>
Precedence: bulk

Michael Banck <mbanck@gmx.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

[1] https://www.postgresql.org/message-id/flat/be0339cc-1ae1-4892-9445-8e6=
d8995a44d@eisentraut.org