Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? - Mailing list pgsql-hackers

From Jakub Wartak
Subject Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date
Msg-id CAKZiRmwWKBzLmCjiENVOS8FijDsoOyCh29YwSiZcak61oM77DA@mail.gmail.com
Whole thread Raw
In response to Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?  (Lukas Fittl <lukas@fittl.com>)
List pgsql-hackers
On Wed, Feb 25, 2026 at 11:01 AM Lukas Fittl <lukas@fittl.com> wrote:
[..]
> See attached v9, rebased, with feedback addressed, unless otherwise noted.

FWIW, I've tried this on FreeBSD and I couldn't understand why I
couldn't enable TSC
(atlought) the cpuid tools reported RDTSCP being available. I have found out
that set_tsc_frequency_khz() returns false and tsc_frequency_khz==0 before even
inquiry for is_rdtscp_available() is done. As this was on virtualbox VM (so not
suppoprted by current code), I think this is pretty clear we'll need some way of
informing users why he cannot SET timing_clock_source to TSC. Possibly errhint()
could differentiate the reason? E.g.
  "failed to auto-detect TSC frequency (potential hypervisor issue)" or
  "CPU RDTSCP instructions are not available"

-J.



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: [PATCH] Add pg_get_database_ddl() function to reconstruct CREATE DATABASE statement
Next
From: "Joel Jacobson"
Date:
Subject: Re: [BUG?] estimate_hash_bucket_stats uses wrong ndistinct for avgfreq