Re: Sampling-based timing for EXPLAIN ANALYZE

On Tue, 17 Jan 2023 at 14:52, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
> On 1/17/23 19:46, Andres Freund wrote:
>
> > I think a "hybrid" explain mode might be worth thinking about. Use the
> > "current" sampling method for the first execution of a node, and for the first
> > few milliseconds of a query (or perhaps the first few timestamp
> > acquisitions). That provides an accurate explain analyze for short queries,
> > without a significant slowdown. Then switch to sampling, which provides decent
> > attribution for a bit longer running queries.
> >
>
> Yeah, this is essentially the sampling I imagined when I first read the
> subject of this thread. It samples which node executions to measure (and
> then measures those accurately), while these patches sample timestamps.

That sounds interesting. Fwiw my first thought would be to implement
it a bit differently. Always have a timer running sampling right
from the start, but also if there are less than, say, 1000 samples for
a node then measure the actual start/finish time.

So for any given node once you've hit enough samples to get a decent
estimate you stop checking the time. That way any fast or rarely
called nodes still have accurate measurements even if they get few
samples and any long or frequently called nodes stop getting
timestamps and just use timer counts.

--
greg