| From: | Ants Aasma <ants(dot)aasma(at)cybertec(dot)at> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, 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-05 09:23:15 |
| Message-ID: | CANwKhkPcQ9fNNJff24kqpMDoD4GuHfdmP9yzkOO=LUOHqZsO+Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, 4 Feb 2026 at 16:23, Andres Freund <andres(at)anarazel(dot)de> wrote:
> 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.
I have been wanting for those two to be turned on by default with a
"fast enough" clock source. But determining this seemed complicated. I
think if the clock source for them is rdtsc we know that it is
definitely fast enough to be on by default.
--
Ants Aasma
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nitin Motiani | 2026-02-05 09:56:02 | [PATCH] Support reading large objects with pg_read_all_data |
| Previous Message | Jim Jones | 2026-02-05 09:08:22 | Re: Truncate logs by max_log_size |