Re: Sampling-based timing for EXPLAIN ANALYZE - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Sampling-based timing for EXPLAIN ANALYZE
Date
Msg-id CAM-w4HPiLhOUaTRef5HqVm+GBKq_QTSBRZ14oxqjJw1uQ7bAEg@mail.gmail.com
Whole thread Raw
In response to Re: Sampling-based timing for EXPLAIN ANALYZE  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: Sampling-based timing for EXPLAIN ANALYZE
List pgsql-hackers
On Tue, 17 Jan 2023 at 14:52, Tomas Vondra
<tomas.vondra@enterprisedb.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



pgsql-hackers by date:

Previous
From: "Gregory Stark (as CFM)"
Date:
Subject: Re: Privileges on PUBLICATION
Next
From: Nathan Bossart
Date:
Subject: Re: Sub-millisecond [autovacuum_]vacuum_cost_delay broken