Received: from localhost (maia-1.hub.org [200.46.204.191])
	by postgresql.org (Postfix) with ESMTP id 299FE9FA4A0
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 15 Dec 2006 10:57:19 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024)
	with ESMTP id 43946-05 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 15 Dec 2006 10:57:13 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.4
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id 8910C9FA2EC
	for <pgsql-performance@postgresql.org>;
	Fri, 15 Dec 2006 10:57:13 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id kBFEuwL1005823;
	Fri, 15 Dec 2006 09:56:58 -0500 (EST)
To: Martijn van Oosterhout <kleptog@svana.org>
cc: Simon Riggs <simon@2ndquadrant.com>,
	Kelly Burkhart <kelly.burkhart@gmail.com>,
	Evgeny Gridasov <eugrid@fpm.kubsu.ru>,
	pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] EXPLAIN ANALYZE on 8.2 
In-reply-to: <20061215123052.GJ958@svana.org> 
References: <20061214163230.d46f0138.eugrid@fpm.kubsu.ru>
	<21146.1166112702@sss.pgh.pa.us>
	<20061214192920.c75385d6.eugrid@fpm.kubsu.ru>
	<21516.1166114475@sss.pgh.pa.us>
	<fa1e4ce70612141543o8866d7fg417eca88ce9b1344@mail.gmail.com>
	<29450.1166141131@sss.pgh.pa.us>
	<1166178488.3882.56.camel@silverbirch.site>
	<20061215105008.GD958@svana.org>
	<1166185247.3882.69.camel@silverbirch.site>
	<20061215123052.GJ958@svana.org>
Comments: In-reply-to Martijn van Oosterhout <kleptog@svana.org>
	message dated "Fri, 15 Dec 2006 13:30:52 +0100"
Date: Fri, 15 Dec 2006 09:56:57 -0500
Message-ID: <5822.1166194617@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200612/409
X-Sequence-Number: 22465

Martijn van Oosterhout <kleptog@svana.org> writes:
> On Fri, Dec 15, 2006 at 12:20:46PM +0000, Simon Riggs wrote:
>> Maybe sampling every 10 rows will bring things down to an acceptable
>> level (after the first N). You tried less than 10 didn't you?

> Yeah, it reduced the number of calls as the count got larger. It broke
> somewhere, though I don't quite remember why.

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.  IIRC the patch did realize
that first-time-through is not a predictor for the rest, but some of
our plan nodes have enormous variance even after the first time.
I think the worst case is batched hash joins.

			regards, tom lane