Received: from localhost (unknown [200.46.204.182])
	by postgresql.org (Postfix) with ESMTP id 21A022E2FA5
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 30 Nov 2007 06:29:57 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024)
	with ESMTP id 52896-03 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Fri, 30 Nov 2007 06:29:42 -0400 (AST)
Received: from mail.ecircle.de (mail.ecircle.de [195.140.186.200])
	by postgresql.org (Postfix) with ESMTP id 65A462E003A
	for <pgsql-performance@postgresql.org>;
	Fri, 30 Nov 2007 06:29:45 -0400 (AST)
Received: from einstein.muc.ecircle.de (einstein.muc.ecircle.de [192.168.1.7])
	by mail.ecircle.de (READY) with ESMTP id E1CA711C09F;
	Fri, 30 Nov 2007 11:29:43 +0100 (CET)
Received: from [192.168.1.91] ([192.168.1.91]) by einstein.muc.ecircle.de with
	Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Nov 2007 11:29:43 +0100
Subject: Re: TB-sized databases
From: Csaba Nagy <nagy@ecircle-ag.com>
To: Trevor Talbot <quension@gmail.com>
Cc: pgsql-performance@postgresql.org
In-Reply-To: <90bce5730711300215x3ff6c68ekf1c55ce799e48578@mail.gmail.com>
References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com>
	<474B1B8C.1030505@gmail.com>
	<4544e0330711271218h56ce4cc3p280a9fefff24583d@mail.gmail.com>
	<1196197045.4246.1154.camel@ebony.site>
	<474CA2FA.2020201@laotraesquina.com.ar>
	<Pine.LNX.4.58.0711281248290.3731@aragorn.flymine.org>
	<20071128082716.91bbad9c.wmoran@collaborativefusion.com>
	<1196257702.31315.6.camel@PCD12478>
	<1196270576.4246.1246.camel@ebony.site>
	<878x4hmfd4.fsf@oxford.xeocode.com>
	<90bce5730711300215x3ff6c68ekf1c55ce799e48578@mail.gmail.com>
Content-Type: text/plain
Date: Fri, 30 Nov 2007 11:29:43 +0100
Message-Id: <1196418583.31315.47.camel@PCD12478>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.1 
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 30 Nov 2007 10:29:43.0700 (UTC)
	FILETIME=[EC15D540:01C8333B]
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200711/395
X-Sequence-Number: 27810

> Isn't that what statement_timeout is for? Since this is entirely based
> on estimates, using arbitrary fuzzy numbers for this seems fine to me;
> precision isn't really the goal.

There's an important difference to statement_timeout: this proposal
would avoid completely taking any resources if it estimates it can't be
executed in proper time, but statement_timeout will allow a bad query to
run at least statement_timeout long...

Cheers,
Csaba.