From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: David Geier <geidav.pg@gmail.com>, vignesh C <vignesh21@gmail.com>,
        Lukas Fittl <lukas@fittl.com>, Michael Paquier <michael@paquier.xyz>,
        Ibrar Ahmed <ibrar.ahmad@gmail.com>,
        Maciek Sakrejda <m.sakrejda@gmail.com>,
        pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
In-reply-to: <20230113195547.k4nlrmawpijqwlsa@awork3.anarazel.de>
References: 
 <CAOtHd0BK98KE9_AjcX0ju-zihKAJwKAHabLpATauX3RgF5TwhA@mail.gmail.com>
 <CALtqXTc1MjgjNU0hTh471wCvaxFaD2yby-TZ4a4DYpHO_tKLPA@mail.gmail.com>
 <Y0Z75kh0WNcb5u3j@paquier.xyz>
 <d7f94549-9179-b63c-878a-002a7cb586a6@gmail.com>
 <d6e84dc8-75d1-4c3b-4b32-c4fcb7852275@gmail.com>
 <3eaeaa3a-b78e-ef0d-7319-5d713bbc09a0@gmail.com>
 <CAP53PkwtWtY-hkSwV7E6g_n657RnFcK0asSp0foSk5Qz_CCJXQ@mail.gmail.com>
 <cc72a411-aa07-834c-85c0-489a5924f8bc@gmail.com>
 <CALDaNm080KHmRHo8OPcAEj+vNzXejwHgmddji5hkAdCwNsuqKA@mail.gmail.com>
 <b201ac3c-1bff-2414-be8e-fc287f78be1a@gmail.com>
 <20230113195547.k4nlrmawpijqwlsa@awork3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Fri, 13 Jan 2023 11:55:47 -0800"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <294642.1673641516.1@sss.pgh.pa.us>
Date: Fri, 13 Jan 2023 15:25:16 -0500
Message-ID: <294643.1673641516@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/294643.1673641516%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> On 2023-01-04 13:02:05 +0100, David Geier wrote:
>> Subject: [PATCH 1/3] Change instr_time to just store nanoseconds, that's
>> cheaper.

> Does anybody see a reason to not move forward with this aspect? We do a fair
> amount of INSTR_TIME_ACCUM_DIFF() etc, and that gets a good bit cheaper by
> just using nanoseconds.

Cheaper, and perhaps more accurate too?  Don't recall if we have any code
paths where the input timestamps are likely to be better-than-microsecond,
but surely that's coming someday.

I'm unsure that we want to deal with rdtsc's vagaries in general, but
no objection to changing instr_time.

			regards, tom lane