Re: Sampling-based timing for EXPLAIN ANALYZE
От | Greg Stark |
---|---|
Тема | Re: Sampling-based timing for EXPLAIN ANALYZE |
Дата | |
Msg-id | CAM-w4HPiLhOUaTRef5HqVm+GBKq_QTSBRZ14oxqjJw1uQ7bAEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Sampling-based timing for EXPLAIN ANALYZE (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Sampling-based timing for EXPLAIN ANALYZE
|
Список | 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 по дате отправления: