| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, David Geier <geidav(dot)pg(at)gmail(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 14:22:54 |
| Message-ID: | xzh4cohdstkdquvuc62ilvolpp4kxuvnfqt5l5hvgdgvifdfdz@kwfwx65q2ka6 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2026-02-03 12:44:21 -0500, Andres Freund wrote:
> 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?
I forgot another important one we really should use the fast timing for:
track_io_timing/track_wal_io_timing. The overhead of IO timing can be
noticeable on busy systems and it's hard to believe that the inaccuracy
matters. This is probably particularly relevant when measuring IO intensive
workloads where the data resides in the kernel page cache, but doesn't fit
into s_b.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | KAZAR Ayoub | 2026-02-04 14:28:56 | Re: Speed up COPY FROM text/CSV parsing using SIMD |
| Previous Message | Andrey Silitskiy | 2026-02-04 14:03:58 | Re: Exit walsender before confirming remote flush in logical replication |