Hi,
On 2025-02-28 23:45:58 -0800, Lukas Fittl wrote:
> From what I can gather, it appears this was an oversight when David first
> reapplied the work on the instr_time changes that were committed.
Heh, glad that that's now fixed. Unfortunately the patch needs an update,
primarily because of the recent pg_test_timing changes.
Applying just patch 2 results in a performance *regression* in pg_test_timing
on my machine, which is due to always hitting the unlikely() path in
INSTR_TIME_GET_NANOSEC() when INSTR_TIME_GET_NANOSEC() is used for an
"absolute" timestamp, rather than a differential timestamp. Which in turn
means hitting a division instruction every time, which on my slightly older
hardware is slower. That may be because my workstation has been up for 40
days, but clearly that can't lead us down to the slow-path
> On a c5.xlarge (Skylake-SP or Cascade Lake) on AWS, with the same test as
> done initially in this thread:
>
> SELECT COUNT(*) FROM lotsarows;
> Time: 974.423 ms
>
> EXPLAIN (ANALYZE, TIMING OFF) SELECT COUNT(*) FROM lotsarows;
> Time: 1336.196 ms (00:01.336)
>
> Without patch:
> EXPLAIN (ANALYZE) SELECT COUNT(*) FROM lotsarows;
> Time: 2165.069 ms (00:02.165)
>
> Per loop time including overhead: 22.15 ns
>
> With patch:
> EXPLAIN (ANALYZE, TIMING ON) SELECT COUNT(*) FROM lotsarows;
> Time: 1654.289 ms (00:01.654)
>
> Per loop time including overhead: 9.81 ns
I still think this would be a rather awesome improvement.
> Open questions I have:
> - Could we rely on checking whether the TSC timesource is invariant (via
> CPUID), instead of relying on Linux choosing it as a clocksource?
I don't see why not?
Greetings,
Andres Freund
