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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-performance by date

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