| From: | Lukas Fittl <lukas(at)fittl(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, David Geier <geidav(dot)pg(at)gmail(dot)com> |
| Subject: | Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc? |
| Date: | 2026-04-08 06:33:52 |
| Message-ID: | CAP53Pkx0xS7sdF05YkOsWmD-7CMtuEoqRT2oJipHDv7Yhy1ssA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 7, 2026 at 11:09 PM Lukas Fittl <lukas(at)fittl(dot)com> wrote:
>
> Hi,
>
> It looks like this recent failure on buildfarm member drongo might be
> related to the timing changes - mainly suspecting it because the
> commits are in the (slightly larger) set that changed, and the error
> is in a timing related module that uses INSTR_TIME_SET_CURRENT.
>
> From https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=drongo&dt=2026-04-08%2001%3A57%3A00
>
> # diff --strip-trailing-cr -U3
> C:/prog/bf/root/HEAD/pgsql/contrib/tsm_system_time/expected/tsm_system_time.out
> C:/prog/bf/root/HEAD/pgsql.build/testrun/tsm_system_time/regress/results/tsm_system_time.out
> # --- C:/prog/bf/root/HEAD/pgsql/contrib/tsm_system_time/expected/tsm_system_time.out
> 2023-01-23 04:39:00.533642000 +0000
> # +++ C:/prog/bf/root/HEAD/pgsql.build/testrun/tsm_system_time/regress/results/tsm_system_time.out
> 2026-04-08 04:03:15.248127800 +0000
> # @@ -15,7 +15,7 @@
> # SELECT count(*) FROM test_tablesample TABLESAMPLE system_time (100000);
> # count
> # -------
> # - 31
> # + 16
> # (1 row)
> #
> # -- bad parameters should get through planning, but not execution:
> # 1 of 1 tests failed.
> # The differences that caused some tests to fail can be viewed in the
> file "C:/prog/bf/root/HEAD/pgsql.build/testrun/tsm_system_time/regress/regression.diffs".
> # A copy of the test summary that you see above is saved in the file
> "C:/prog/bf/root/HEAD/pgsql.build/testrun/tsm_system_time/regress/regression.out".
>
> Haven't had a chance to dig through it yet, just noting it to start.
>
I wonder a bit if the problem here could be that
INSTR_TIME_GET_MILLISEC got slightly more computationally expensive
with 0022622c93d9 (due to the logic in pg_ticks_to_ns), and that
module effectively does that in a tight loop. And if I understood
drongo's configuration correctly, it runs under valgrind. Attached a
quick idea how we could rework that to avoid it.
Thoughts?
Thanks,
Lukas
--
Lukas Fittl
| Attachment | Content-Type | Size |
|---|---|---|
| v23-0001-tsm_system_time-Avoid-repeated-calling-of-INSTR_.patch | application/octet-stream | 2.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Bapat | 2026-04-08 06:36:32 | Re: pg_buffercache: Add per-relation summary stats |
| Previous Message | Peter Smith | 2026-04-08 06:27:49 | Re: Logical Replication - revisit `is_table_publication` function implementation |