pg.ddx.io pgsql-hackers@postgresql.org mailing list archive help / color / mirror / Atom feed From: David Geier <geidav.pg@gmail.com>
To: Pavel Stehule <pavel.stehule@gmail.com>
To: Tomas Vondra <tomas.vondra@enterprisedb.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Lukas Fittl <lukas@fittl.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: Ibrar Ahmed <ibrar.ahmad@gmail.com>
Cc: Maciek Sakrejda <m.sakrejda@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date: Wed, 18 Jan 2023 13:52:05 +0100
Message-ID: <b929cab3-c07f-6d89-5a5f-35d5e5e9ba8a@gmail.com> (raw )
In-Reply-To: <CAFj8pRBTZ+TrWpigGERq_7ANom1prCucO6qg3jxXssaLMAh2BA@mail.gmail.com >
References: <20200612232810.f46nbqkdhbutzqdg@alap3.anarazel.de >
<CAP53Pky+4MJfdC-R3HQFPRauy2N+5_7ExpEhCFUo8EU3bCPjEg@mail.gmail.com >
<20220701172639.ty4iu5almspueriu@alap3.anarazel.de >
<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 >
<c0c253a0-4825-f295-1583-50f9bbab7d5f@enterprisedb.com >
<CAFj8pRBTZ+TrWpigGERq_7ANom1prCucO6qg3jxXssaLMAh2BA@mail.gmail.com >
On 1/16/23 21:39, Pavel Stehule wrote:
>
> po 16. 1. 2023 v 21:34 odesílatel Tomas Vondra
> <tomas.vondra@enterprisedb.com> napsal:
>
> Hi,
>
> there's minor bitrot in the Mkvcbuild.pm change, making cfbot unhappy.
>
> As for the patch, I don't have much comments. I'm wondering if it'd be
> useful to indicate which timing source was actually used for EXPLAIN
> ANALYZE, say something like:
>
> Planning time: 0.197 ms
> Execution time: 0.225 ms
> Timing source: clock_gettime (or tsc)
>
> There has been a proposal to expose this as a GUC (or perhaps as
> explain
> option), to allow users to pick what timing source to use. I
> wouldn't go
> that far - AFAICS is this is meant to be universally better when
> available. But knowing which source was used seems useful.
>
>
> +1
Thanks for looking at the patch.
I'll fix the merge conflict.
I like the idea of exposing the timing source in the EXPLAIN ANALYZE output.
It's a good tradeoff between inspectability and effort, given that RDTSC
should always be better to use.
If there are no objections I go this way.
--
David Geier
(ServiceNow)
view thread (172+ messages) latest in thread
Message-ID: <b929cab3-c07f-6d89-5a5f-35d5e5e9ba8a@gmail.com>
Permalink: ../b929cab3-c07f-6d89-5a5f-35d5e5e9ba8a@gmail.com/
Also on: postgresql.org/message-id/b929cab3-c07f-6d89-5a5f-35d5e5e9ba8a@gmail.com
copy link · copy postgr.es
reply Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: geidav.pg@gmail.com, pavel.stehule@gmail.com, tomas.vondra@enterprisedb.com, vignesh21@gmail.com, lukas@fittl.com, michael@paquier.xyz, ibrar.ahmad@gmail.com, m.sakrejda@gmail.com, andres@anarazel.de
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
In-Reply-To: <b929cab3-c07f-6d89-5a5f-35d5e5e9ba8a@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox