Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 2CD8D2E004E for ; Wed, 28 Nov 2007 09:57:37 -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 33763-06 for ; Wed, 28 Nov 2007 09:57:28 -0400 (AST) Received: from bifrost.lang.hm (dsl081-033-126.lax1.dsl.speakeasy.net [64.81.33.126]) by postgresql.org (Postfix) with ESMTP id 8FE862E0044 for ; Wed, 28 Nov 2007 09:57:33 -0400 (AST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id lASDv6ur001236; Wed, 28 Nov 2007 05:57:06 -0800 Date: Wed, 28 Nov 2007 07:03:26 -0800 (PST) From: david@lang.hm X-X-Sender: dlang@asgard To: Csaba Nagy cc: Bill Moran , pgsql-performance@postgresql.org Subject: Re: TB-sized databases In-Reply-To: <1196257702.31315.6.camel@PCD12478> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/344 X-Sequence-Number: 27759 On Wed, 28 Nov 2007, Csaba Nagy wrote: > 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... and even better if the option can be overridden for a specific transaction or connection. that way it can be set relativly low for normal operations, but when you need to do an expensive query you can change it for that query. David Lang