Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: David Geier <geidav(dot)pg(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>
Cc: Lukas Fittl <lukas(at)fittl(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Ibrar Ahmed <ibrar(dot)ahmad(at)gmail(dot)com>, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Date: 2023-01-16 20:34:42
Message-ID: c0c253a0-4825-f295-1583-50f9bbab7d5f@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2023-01-16 20:39:04 Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Previous Message Pavel Stehule 2023-01-16 20:27:28 Re: Schema variables - new implementation for Postgres 15 (typo)