agora inbox for pgsql-hackers@postgresql.org
help / color / mirror / Atom feedFrom: David Geier <geidav.pg@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.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: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date: Tue, 24 Jan 2023 14:35:45 +0100
Message-ID: <6a3f41fd-7103-28e2-dfa0-a7f1e6b89329@gmail.com> (raw)
In-Reply-To: <20230123202619.yckkxn56iavoq2rn@awork3.anarazel.de>
References: <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>
<CA+TgmoYOvh=k-H9m21Lh-SWbn7TNurm3JoOVxW+kOO=Gn1_8Xw@mail.gmail.com>
<20230117164758.gx4uuzhk5grw7zea@awork3.anarazel.de>
<50c9f291-fc60-1d2e-e286-0fb888586e7e@gmail.com>
<20230121041200.225hljezqtpijvq4@awork3.anarazel.de>
<5a09bfe1-8a6c-de2e-d2b0-62abc5a8fe7a@gmail.com>
<20230123202619.yckkxn56iavoq2rn@awork3.anarazel.de>
Hi
>
> I think at least some should be converted to just accumulate in an
> instr_time...
I think that's for a later patch though?
> Yep, at least quite similar.
OK. I coded it up in the latest version of the patch.
> Depending on how low we want to keep the error, I don't think we can:
>
> If I set the allowed deviation to 10**-9, we end up requiring a shift by 29
> for common ghz ranges. Clearly 33bits isn't an interesting range.
>
> But even if you accept a higher error - we don't have *that* much range
> available. Assuming an uint64, the range is ~584 years. If we want 10 years
> range, we end up
>
> math.log(((2**64)-1) / (10 * 365 * 60 * 60 * 24 * 10**9), 2)
> ~= 5.87
>
> So 5 bits available that we could "use" for multiply/shift. For something like
> 2.5ghz, that'd be ~2% error, clearly not acceptable. And even just a year of
> range, ends up allowing a failure of 30796s = 8min over a year, still too
> high.
Thanks for doing the math. Agreed. The latest patch detects overflow and
correctly handles it.
> But I don't think it's really an issue - normally that branch will never be
> taken (at least within the memory of the branch predictor), which on modern
> CPUs means it'll just be predicted as not taken. So as long as we tell the
> compiler what's the likely branch, it should be fine. At least as long as the
> branch compares with a hardcoded number.
Yeah. The overflow detection just compares two int64. The "overflow
threshold" is pre-computed.
> - the restriction just to linux, that'll make testing harder for some, and
> ends up encoding too much OS dependency
> - I think we need both the barrier and non-barrier variant, otherwise I
> suspect we'll end up with inccuracies we don't want
> - needs lots more documentation about why certain cpuid registers are used
> - cpu microarch dependencies - isn't there, e.g., the case that the scale on
> nehalem has to be different than on later architectures?
> - lack of facility to evaluate how well the different time sources work
Makes sense. I carried that list over to my latest e-mail which also
includes the patch to have some sort of summary of where we are in a
single place.
--
David Geier
(ServiceNow)
view thread (172+ messages) latest in thread
Message-ID: <6a3f41fd-7103-28e2-dfa0-a7f1e6b89329@gmail.com>
Permalink: ../6a3f41fd-7103-28e2-dfa0-a7f1e6b89329@gmail.com/
Also on: postgresql.org/message-id/6a3f41fd-7103-28e2-dfa0-a7f1e6b89329@gmail.com
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, andres@anarazel.de, robertmhaas@gmail.com, vignesh21@gmail.com, lukas@fittl.com, michael@paquier.xyz, ibrar.ahmad@gmail.com, m.sakrejda@gmail.com
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
In-Reply-To: <6a3f41fd-7103-28e2-dfa0-a7f1e6b89329@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 agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox