Re: Sampling-based timing for EXPLAIN ANALYZE

Nice idea.

On 1/6/23 10:19, Jelte Fennema wrote:
> Do you have some performance comparison between TIMING ON and TIMING
> SAMPLING?

+1 to see some numbers compared to TIMING ON.

Mostly I'm wondering if the sampling based approach gains us enough to
be worth it, once the patch to use RDTSC hopefully landed (see [1]). I
believe that with the RDTSC patch the overhead of TIMING ON is lower
than the overhead of using ANALYZE with TIMING OFF in the first place.
Hence, to be really useful, it would be great if we could on top of
TIMING SAMPLING also lower the overhead of ANALYZE itself further (e.g.
by using a fast path for the default EXPLAIN (ANALYZE, TIMING ON /
SAMPLING)). Currently, InstrStartNode() and InstrStopNode() have a ton
of branches and without all the typically deactivated code the
implementation would be very small and could be placed in an inlinable
function.

[1]
https://www.postgresql.org/message-id/flat/20200612232810.f46nbqkdhbutzqdg%40alap3.anarazel.de

--
David Geier
(ServiceNow)