| From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Lukas Fittl <lukas(at)fittl(dot)com>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, 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:06:50 |
| Message-ID: | 5d2465dd-f1b8-4b54-aac5-becec72dad9a@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> I do think its reasonable for us to check this directly, since we're
> already working with cpuid information anyway, and we also need the
> TSC frequency data in the Hypervisor specific leafs (i.e. its not just
> about getting the VM vendor name itself). For example, I don't think
> HyperV provides TSC frequency in 0x40000010 - it was something VMware
> added initially, that KVM subsequently added.
And then we have a hard dependency on systemd, where at the moment the
user can try to use RDTSC also on systems without.
>> Also it would be cool if the patch would provide some way of reporting back
>> what clock_source was really used in case of FAST_CLOCK_SOURCE_AUTO.
>> Something like huge_pages_status or some elog(DEBUG).
>
> Agreed, I think that would be useful.
+1
--
David Geier
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Geier | 2026-02-04 10:09:32 | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Previous Message | Álvaro Herrera | 2026-02-04 10:04:16 | Re: [V2] Adding new CRC32C implementation for IBM S390X |