Received: from localhost (unknown [200.46.204.187]) by postgresql.org (Postfix) with ESMTP id 057352E337E for ; Wed, 28 Nov 2007 09:54:50 -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 21460-06 for ; Wed, 28 Nov 2007 09:54:37 -0400 (AST) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id A5FC82E0055 for ; Wed, 28 Nov 2007 09:54:42 -0400 (AST) Received: from vanquish.pitbpa0.priv.collaborativefusion.com (vanquish.pitbpa0.priv.collaborativefusion.com [192.168.2.61]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Wed, 28 Nov 2007 08:54:41 -0500 id 00056403.474D7321.00002DDC Date: Wed, 28 Nov 2007 08:54:41 -0500 From: Bill Moran To: Csaba Nagy Cc: pgsql-performance@postgresql.org Subject: Re: TB-sized databases Message-Id: <20071128085441.51705627.wmoran@collaborativefusion.com> In-Reply-To: <1196257702.31315.6.camel@PCD12478> 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> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.4.7 (GTK+ 2.12.1; i386-portbld-freebsd6.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/342 X-Sequence-Number: 27757 In response to Csaba Nagy : > 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 that's true, then I have a bug report to file: test=# set enable_seqscan=off; SET test=# show enable_seqscan; enable_seqscan ---------------- off (1 row) test=# set enable_seqscan=on; SET test=# show enable_seqscan; enable_seqscan ---------------- on (1 row) It looks to me to be session-alterable. > 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". True. It would still choose some other plan. > In fact an even more useful option would be to ask the planner to throw > error if the expected cost exceeds a certain threshold... Interesting concept. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023