From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | Rocco Altier <RoccoA(at)Routescape(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: [PATCH] Improve EXPLAIN ANALYZE overhead by sampling |
Date: | 2006-05-09 21:38:54 |
Message-ID: | 20060509213854.GK29652@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
On Tue, May 09, 2006 at 05:16:57PM -0400, Rocco Altier wrote:
> > - To get this close it needs to get an estimate of the sampling
> > overhead. It does this by a little calibration loop that is run
> > once per backend. If you don't do this, you end up assuming all
> > tuples take the same time as tuples with the overhead, resulting in
> > nodes apparently taking longer than their parent nodes. Incidently,
> > I measured the overhead to be about 3.6us per tuple per node on my
> > (admittedly slightly old) machine.
>
> Could this be deferred until the first explain analyze? So that we
> aren't paying the overhead of the calibration in all backends, even the
> ones that won't be explaining?
If you look it's only done on the first call to InstrAlloc() which
should be when you run EXPLAIN ANALYZE for the first time.
In any case, the calibration is limited to half a millisecond (that's
500 microseconds), and it'll be a less on fast machines.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Bjorklund | 2006-05-10 04:19:35 | BEGIN inside transaction should be an error |
Previous Message | Rocco Altier | 2006-05-09 21:16:57 | Re: [PATCH] Improve EXPLAIN ANALYZE overhead by sampling |