Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOhe2-000eYL-CV for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jul 2024 17:50:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sOhdz-003Ooy-TU for pgsql-hackers@arkaria.postgresql.org; Tue, 02 Jul 2024 17:50:20 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOhdz-003Oop-Jj for pgsql-hackers@lists.postgresql.org; Tue, 02 Jul 2024 17:50:20 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sOhdx-0005cV-Pa for pgsql-hackers@postgresql.org; Tue, 02 Jul 2024 17:50:19 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 462HoDsA3115673; Tue, 2 Jul 2024 13:50:13 -0400 From: Tom Lane To: Hannu Krosing cc: Peter Eisentraut , "Andrey M. Borodin" , pgsql-hackers Subject: Re: What is a typical precision of gettimeofday()? In-reply-to: References: <47AEACEE-E5CC-40E4-8611-01F3A465AF16@yandex-team.ru> <9e7b21e7-4c63-4299-87f4-780a0699a7d8@eisentraut.org> <130996.1718814994@sss.pgh.pa.us> <647660.1719003075@sss.pgh.pa.us> <3110108.1719939353@sss.pgh.pa.us> <3112460.1719940814@sss.pgh.pa.us> Comments: In-reply-to Hannu Krosing message dated "Tue, 02 Jul 2024 19:31:21 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3115671.1719942613.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Tue, 02 Jul 2024 13:50:13 -0400 Message-ID: <3115672.1719942613@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hannu Krosing writes: > Also, reading directly in ticks on M1 gave "loop time including > overhead: 2.13 ns" (attached code works on Clang, not sure about GCC) I don't think we should mess with that, given the portability problems you mentioned upthread. > I'll also take a look at the docs and try to propose something OK. > Do we also need tests for this one ? Yeah, it was annoying me that we are eating the overhead of a TAP test for pg_test_timing and yet it covers barely a third of the code [1]. We obviously can't expect any specific numbers out of a test, but I was contemplating running "pg_test_timing -d 1" and just checking for (a) zero exit code and (b) the expected header lines in the output. regards, tom lane [1] https://coverage.postgresql.org/src/bin/pg_test_timing/pg_test_timing.= c.gcov.html