On Wed, 2006-03-22 at 21:59 -0500, Tom Lane wrote:
I'm betting that a
big part of your issue is that the EXPLAIN ANALYZE instrumentation
overhead is (1) significant
I would like to implement an additional mode for EXPLAIN ANALYZE that
does no timing instrumentation at all. Most of the time
Simon Riggs [EMAIL PROTECTED] writes:
I would like to implement an additional mode for EXPLAIN ANALYZE that
does no timing instrumentation at all. Most of the time just looking for
differences between estimated and actual row counts is all you need.
I don't really agree with that premise ...
On Sat, Mar 25, 2006 at 10:00:51AM -0500, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I would like to implement an additional mode for EXPLAIN ANALYZE that
does no timing instrumentation at all. Most of the time just looking for
differences between estimated and actual row counts
On Sat, Mar 25, 2006 at 04:24:05PM +0100, Martijn van Oosterhout wrote:
I agree. However, if it's the overhead of calling gettimeofday() that
slows everything down, perhaps we should tackle that end. For example,
have a sampling mode that only times say 5% of the executed nodes.
EXPLAIN
On Sat, 2006-03-25 at 16:24 +0100, Martijn van Oosterhout wrote:
I agree. However, if it's the overhead of calling gettimeofday() that
slows everything down, perhaps we should tackle that end. For example,
have a sampling mode that only times say 5% of the executed nodes.
EXPLAIN ANALYZE
On Sat, Mar 25, 2006 at 05:38:26PM +, Simon Riggs wrote:
On Sat, 2006-03-25 at 16:24 +0100, Martijn van Oosterhout wrote:
I agree. However, if it's the overhead of calling gettimeofday() that
slows everything down, perhaps we should tackle that end. For example,
have a sampling mode
On Wed, Mar 22, 2006 at 8:59 pm, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Kevin Grittner [EMAIL PROTECTED] writes:
You didn't show us the explain analyze results,
The below is cut paste directly from a psql run without editing.
bigbird= UPDATE User SET isActive =
Kevin Grittner [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
You didn't show us the explain analyze results,
The below is cut paste directly from a psql run without editing.
OK, so the two plans do indeed have much different node execution
counts. The EXPLAIN ANALYZE
On Thu, Mar 23, 2006 at 11:27 am, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
The run time of the NOT IN query, as measured by elapsed time
between
SELECT CURRENT_TIMESTAMP executions, increased by 31 ms.
Works out to about 30 microsec per node execution, which seems a
On Thu, Mar 23, 2006 at 11:27 am, in message
[EMAIL PROTECTED],
Tom Lane [EMAIL PROTECTED] wrote:
Profiling with gprof or some such tool might be educational.
I've never used gprof before, and from a quick scan of the info, it
appears that I need to compile and link a special version of the
On Thu, Mar 23, 2006 at 12:29:27PM -0600, Kevin Grittner wrote:
Works out to about 30 microsec per node execution, which seems a
bit high for modern machines ... and the coarse quantization of the
CURRENT_TIMESTAMP results is odd too. What platform is this on
exactly?
This is a smaller
Kevin Grittner [EMAIL PROTECTED] writes:
I've never used gprof before, and from a quick scan of the info, it
appears that I need to compile and link a special version of the
software to generate the file that gprof needs. Is this correct? Does
it work on a Windows build, or will I need to
I have some odd results from timing two versions of an update query, and
was hoping to get a better handle on how to interpret this. The query
does an update of one table. One version does three NOT IN tests
against three related tables. The other version does the logically
equivalent NOT
Kevin Grittner [EMAIL PROTECTED] writes:
I have some odd results from timing two versions of an update query, and
was hoping to get a better handle on how to interpret this.
You didn't show us the explain analyze results, but I'm betting that a
big part of your issue is that the EXPLAIN ANALYZE
14 matches
Mail list logo
