| From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, Hannu Krosing <hannuk(at)google(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(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>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Date: | 2026-02-04 10:09:32 |
| Message-ID: | 1e0462f0-8274-4d57-aa39-9b6ebeb954da@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 03.02.2026 18:44, Andres Freund wrote:
> Yea, I doubt this is the right path... Particularly because I really think we
> ought to eventually use this not just on linux but other OSs as well.
+1
>> BTW, -1 to fast_clock_source, +1 to clock_source or maybe
>> explain_clock_source(?)
>
> Hm. I think it'd make sense to use eventually use this clock source for other
> timing tasks too, not just explain. E.g. pg_stat_statements could benefit
> quite a bit from reducing the timing overhead.
>
> Whereas it'll not make sense for anything that needs wall clock times - which
> imo makes a "clock_source" GUC misnamed. Maybe "clock_source_timing" or such?
Makes sense. clock_source_timing works for me, or maybe easier to read
would be timing_clock_source. But doesn't matter much.
--
David Geier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | jian he | 2026-02-04 10:22:16 | Re: ON CONFLICT DO SELECT (take 3) |
| Previous Message | David Geier | 2026-02-04 10:06:50 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |