Message-ID: <43A2F011.9050809@modgraph-usa.com>
Date: Fri, 16 Dec 2005 08:49:21 -0800
From: "Craig A. James" <cjames@modgraph-usa.com>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
MIME-Version: 1.0
To: Jaime Casanova <systemguards@gmail.com>, 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>
	<c2d9e70e0512160645q20ca27b7ja2f1235bed797747@mail.gmail.com>
In-Reply-To: <c2d9e70e0512160645q20ca27b7ja2f1235bed797747@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jaime Casanova wrote:
>>The context is this - in a busy OLTP system, sometimes a query comes
>>through that, for whatever reason (foolishness on my part as a
>>developer, unexpected use by a user, imperfection of the optimizer,
>>etc.), takes a really long time to run, usually because it table-scans
>>one or more large tables.  If several of these happen at once, it can
>>grind an important production system effectively to a halt.  I'd like to
>>have a few users/operations get a "sorry, I couldn't find a good way to
>>do that" message, rather than all the users find that their system has
>>effectively stopped working.
> ... 
> set statement_timeout in postgresql.conf

I found it's better to use "set statement_timeout" in the code, rather than setting it globally.  Someone else pointed out to me that setting it in postgresql.conf makes it apply to ALL transactions, including VACUUM, ANALYZE and so forth.  I put it in my code just around the queries that are "user generated" -- queries that are from users' input.  I expect any SQL that I write to finish in a reasonable time ;-).

Craig