| From: | David Geier <geidav(dot)pg(at)gmail(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)kurilemu(dot)de> |
| Cc: | Lukas Fittl <lukas(at)fittl(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, 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>, Tomas Vondra <tomas(at)vondra(dot)me> |
| Subject: | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Date: | 2025-12-03 09:50:15 |
| Message-ID: | 5310b6e1-357b-4de0-9167-569dd7bb5807@gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 19.11.2025 08:20, David Geier wrote:
>
> On 20.10.2025 21:59, Robert Haas wrote:
>> On Sun, Oct 19, 2025 at 2:16 PM Álvaro Herrera <alvherre(at)kurilemu(dot)de> wrote:
>>> If I were
>>> a consultant trying to understand a customer's system, I would have to
>>> ask them to run it twice just in case 'fast' is supported, and I don't
>>> think that's very helpful.
>>
>> Big +1 from me.
>>
>
> That makes sense. I'm planning to rebase the patch the next days. Then
> I'll also take care of that.
The attached patched is rebased on latest master and pg_test_timing now
always tests the normal and the fast timing code. If no fast clock
source is available the fast timing code is skipped.
--
David Geier
| Attachment | Content-Type | Size |
|---|---|---|
| v12-0002-pg_test_timing-Also-test-fast-timing-and-report-time.patch | text/x-patch | 7.4 KB |
| v12-0001-Use-time-stamp-counter-to-measure-time-on-Linux-x86.patch | text/x-patch | 17.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | vignesh C | 2025-12-03 09:50:31 | Fix START_REPLICATION failure with publication names containing backslashes |
| Previous Message | Heikki Linnakangas | 2025-12-03 09:38:02 | Re: Using MyDatabaseId in SET_LOCKTAG_APPLY_TRANSACTION |