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
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 ANALYZ
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, 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
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 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
"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 nee
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
>>> 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
>>> 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, whi
"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 ANALYZ
>>> 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" S
"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 AN
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 EXISTS
14 matches
Mail list logo