Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id D16B82E3087 for ; Wed, 28 Nov 2007 09:48:57 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.187]) (amavisd-maia, port 10024) with ESMTP id 20271-05 for ; Wed, 28 Nov 2007 09:48:47 -0400 (AST) Received: from mail.ecircle.de (mail.ecircle.de [195.140.186.200]) by postgresql.org (Postfix) with ESMTP id D33942E0041 for ; Wed, 28 Nov 2007 09:48:52 -0400 (AST) Received: from einstein.muc.ecircle.de (einstein.muc.ecircle.de [192.168.1.7]) by mail.ecircle.de (READY) with ESMTP id A227611C1AB; Wed, 28 Nov 2007 14:48:50 +0100 (CET) Received: from [192.168.1.91] ([192.168.1.91]) by einstein.muc.ecircle.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Nov 2007 14:48:22 +0100 Subject: Re: TB-sized databases From: Csaba Nagy To: Bill Moran Cc: pgsql-performance@postgresql.org In-Reply-To: <20071128082716.91bbad9c.wmoran@collaborativefusion.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> Content-Type: text/plain Date: Wed, 28 Nov 2007 14:48:22 +0100 Message-Id: <1196257702.31315.6.camel@PCD12478> Mime-Version: 1.0 X-Mailer: Evolution 2.10.1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2007 13:48:22.0980 (UTC) FILETIME=[57B42040:01C831C5] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/341 X-Sequence-Number: 27756 On Wed, 2007-11-28 at 08:27 -0500, Bill Moran wrote: > Is there something wrong with: > set enable_seqscan = off > ? Nothing wrong with enable_seqscan = off except it is all or nothing type of thing... if you want the big table to never use seqscan, but a medium table which is joined in should use it, then what you do ? And setting enable_seqscan = off will actually not mean the planner can't use a sequential scan for the query if no other alternative exist. In any case it doesn't mean "please throw an error if you can't do this without a sequential scan". In fact an even more useful option would be to ask the planner to throw error if the expected cost exceeds a certain threshold... Cheers, Csaba.