DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=beta;
	h=received:message-id:date:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:from;
	b=IsPDJOY+ryzPHRAIoyOWzS3ADPGu2QNYRRlIYhKyNB1xiGmg6LNc/WBrYR0nGHDEa7JSeyEdJdIijgQGzvKZpPxsmWQJYLOgYrHCsV5EVMA3iazBSwSd/pwf+MTPz+wNyPsRtdVvDDVJIBOYoXcPpR06A4cdXV5HJ850MKIpU0A=
Message-ID: <466814B7.6000606@gmail.com>
Date: Thu, 07 Jun 2007 16:22:47 +0200
User-Agent: Thunderbird 1.5.0.12 (X11/20070604)
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: VERY slow queries at random
References: <46670916.9090505@gmail.com>
	<20070606195649.GG11545@phlogiston.dyndns.org>
In-Reply-To: <20070606195649.GG11545@phlogiston.dyndns.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Gunther Mayer <gunther.mayer@googlemail.com>

Andrew Sullivan wrote:
> On Wed, Jun 06, 2007 at 09:20:54PM +0200, Gunther Mayer wrote:
>   
>> What the heck could cause such erratic behaviour? I suspect some type of
>> resource problem but what and how could I dig deeper?
>>     
>
> Is something (perhaps implicitly) locking the table?  That will cause
> this.
>   
There are a whole bunch of update queries that fire all the time but 
afaik none of them ever lock the entire table. To the best of my 
knowledge UPDATE ... WHERE ... only locks those rows that it actually 
operates on, in my case this is always a single row. No explicit locking 
is done anywhere, but perhaps you're right and it is a locking issue. 
Question is, how do I find out about locks at the time when I only get 
told about the slow query *after* it has completed and postgres has told 
me so by logging a slow query entry in my logs?

Gunther