Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] EXPLAIN ANALYZE on 8.2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: "Peter Eisentraut" <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org, "Kelly Burkhart" <kelly(dot)burkhart(at)gmail(dot)com>, "Evgeny Gridasov" <eugrid(at)fpm(dot)kubsu(dot)ru>, pgsql-performance(at)postgresql(dot)org
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2
Date: 2006-12-19 04:43:00
Message-ID: 10651.1166503380@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Fri, 2006-12-15 at 09:56 -0500, Tom Lane wrote:
>> The fundamental problem with it was the assumption that different
>> executions of a plan node will have the same timing.  That's not true,
>> in fact not even approximately true. 

> It doesn't make sense to me to claim that the timing is so important
> that we cannot do without it, at the same time as saying it isn't even
> approximately true that is highly variable.

Huh?  What I said was that successive executions of the same plan node
may take considerably different amounts of time, and the proposed
sampling patch failed to handle that situation with acceptable accuracy.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2006-12-19 08:08:56
Subject: Re: Insertion to temp table deteriorating over time
Previous:From: Steven FlattDate: 2006-12-18 23:06:04
Subject: Re: Insertion to temp table deteriorating over time

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-12-19 04:46:55
Subject: Re: effective_cache_size vs units
Previous:From: Bruce MomjianDate: 2006-12-19 03:23:59
Subject: Re: pg_restore fails with a custom backup file

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group