X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id E924E9DCC9D for ; Fri, 16 Dec 2005 01:48:58 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 21472-02 for ; Fri, 16 Dec 2005 01:48:57 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by postgresql.org (Postfix) with ESMTP id 721359DC9D3 for ; Fri, 16 Dec 2005 01:48:56 -0400 (AST) Received: from sysexperts.com (c-67-170-228-241.hsd1.ca.comcast.net[67.170.228.241]) by comcast.net (rwcrmhc11) with ESMTP id <2005121605485601300c8opke>; Fri, 16 Dec 2005 05:48:56 +0000 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by filer with local; Thu, 15 Dec 2005 21:48:55 -0800 id 18325A61.43A25547.00001244 Date: Thu, 15 Dec 2005 21:48:55 -0800 From: Kevin Brown To: pgsql-performance@postgresql.org Subject: Re: Overriding the optimizer Message-ID: <20051216054855.GD691@filer> Mail-Followup-To: Kevin Brown , pgsql-performance@postgresql.org References: <7484.1134600423@sss.pgh.pa.us> <1134629567.14248.27.camel@firebolt> <200512150148.16125.blargity@gmail.com> <1134644526.14248.60.camel@firebolt> <43A1C40D.8040006@paradise.net.nz> <43A1F6DB.3080805@modgraph-usa.com> <43A226E7.7040508@paradise.net.nz> <43A22BE3.6020103@modgraph-usa.com> <20051216052025.GB691@filer> <43A25372.8090706@modgraph-usa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: <43A25372.8090706@modgraph-usa.com> Organization: Frobozzco International User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200512/389 X-Sequence-Number: 16210 Craig A. James wrote: > Kevin Brown wrote: > >>Hints are dangerous, and I consider them a last resort. > > > >If you consider them a last resort, then why do you consider them to > >be a better alternative than a workaround such as turning off > >enable_seqscan, when all the other tradeoffs are considered? > > If I understand enable_seqscan, it's an all-or-nothing affair. Turning it > off turns it off for the whole database, right? The same is true of all > of the planner-tuning parameters in the postgres conf file. Nope. What's in the conf file are the defaults. You can change them on a per-connection basis, via the SET command. Thus, before doing your problematic query: SET enable_seqscan = off; and then, after your query is done, SET enable_seqscan = on; > >If your argument is that planner hints would give you finer grained > >control, then the question is whether you'd rather the developers > >spend their time implementing planner hints or improving the planner. > > I agree 100% -- I'd much prefer a better planner. But when it comes down > to a do-or-die situation, you need a hack, some sort of workaround, to get > you working *today*. And that's why I was asking about workarounds versus planner hints. I expect that the situations in which the planner gets things wrong *and* where there's no workaround are very rare indeed. -- Kevin Brown kevin@sysexperts.com