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 CDBFB9DC9F0 for ; Fri, 16 Dec 2005 21:41:24 -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 92136-07 for ; Fri, 16 Dec 2005 21:41:27 -0400 (AST) X-Greylist: delayed 11:22:54.842655 by SQLgrey- Received: from filch.dreamhost.com (filch.dreamhost.com [66.33.217.6]) by postgresql.org (Postfix) with ESMTP id AB82B9DC883 for ; Fri, 16 Dec 2005 21:41:21 -0400 (AST) Received: from [127.0.0.1] (shemp.dreamhost.com [66.33.213.12]) by filch.dreamhost.com (Postfix) with ESMTP id 3BB9D5F8CD for ; Fri, 16 Dec 2005 17:41:25 -0800 (PST) Message-ID: <43A36D06.3090804@kylecordes.com> Date: Fri, 16 Dec 2005 19:42:30 -0600 From: Kyle Cordes User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Overriding the optimizer References: <200512141603.52583.blargity@gmail.com> <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> <43A2CCEF.9030605@kylecordes.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.12 required=5 tests=[AWL=0.120] X-Spam-Score: 0.12 X-Spam-Level: X-Archive-Number: 200512/417 X-Sequence-Number: 16238 Jaime Casanova wrote: >>What I would >>really like is for my DBMS to give me a little more pushback - I'd like >>to ask it to run a query, and have it either find a "good" way to run >>the query, or politely refuse to run it at all. >> >> >set statement_timeout in postgresql.conf > > That is what I am doing now, and it is much better than nothing. But it's not really sufficient, in that it is still quite possible for users repeatedly trying an operation that unexpectedly causes excessive DB usage, to load down the system to the point of failure. In other words, I'd ideally like it to give up right away, not after N seconds of table scanning my 100-million-row tables... and not with a timeout, but with an explicit throwing up of its hands, exasperated, that it could not come up with an efficient way to run my query. Kyle Cordes www.kylecordes.com