Received: from localhost (unknown [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id D98902E029A for ; Thu, 29 Nov 2007 11:46:18 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-maia, port 10024) with ESMTP id 35568-07 for ; Thu, 29 Nov 2007 11:46:15 -0400 (AST) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 8AEF02E0146 for ; Thu, 29 Nov 2007 11:46:15 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lATFjVcT013852; Thu, 29 Nov 2007 10:45:31 -0500 (EST) To: Gregory Stark cc: "Simon Riggs" , "Csaba Nagy" , "Bill Moran" , pgsql-performance@postgresql.org Subject: Re: TB-sized databases In-reply-to: <878x4hmfd4.fsf@oxford.xeocode.com> References: <4544e0330711260904g45d893a8ub1731e245aa8fc84@mail.gmail.com> <474B1407.3090607@laotraesquina.com.ar> <474B1B8C.1030505@gmail.com> <4544e0330711271218h56ce4cc3p280a9fefff24583d@mail.gmail.com> <1196197045.4246.1154.camel@ebony.site> <474CA2FA.2020201@laotraesquina.com.ar> <20071128082716.91bbad9c.wmoran@collaborativefusion.com> <1196257702.31315.6.camel@PCD12478> <1196270576.4246.1246.camel@ebony.site> <878x4hmfd4.fsf@oxford.xeocode.com> Comments: In-reply-to Gregory Stark message dated "Thu, 29 Nov 2007 11:59:51 +0000" Date: Thu, 29 Nov 2007 10:45:31 -0500 Message-ID: <13851.1196351131@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/373 X-Sequence-Number: 27788 Gregory Stark writes: > "Simon Riggs" writes: >> Tom's previous concerns were along the lines of "How would know what to >> set it to?", given that the planner costs are mostly arbitrary numbers. > Hm, that's only kind of true. The units are not the problem. The problem is that you are staking non-failure of your application on the planner's estimates being pretty well in line with reality. Not merely in line enough that it picks a reasonably cheap plan, but in line enough that if it thinks plan A is 10x more expensive than plan B, then the actual ratio is indeed somewhere near 10. Given that this list spends all day every day discussing cases where the planner is wrong, I'd have to think that that's a bet I wouldn't take. You could probably avoid this risk by setting the cutoff at something like 100 or 1000 times what you really want to tolerate, but how useful is it then? regards, tom lane