Message-ID: <506AA1BC.1070305@vmware.com>
Date: Tue, 02 Oct 2012 11:11:40 +0300
From: Heikki Linnakangas <hlinnakangas@vmware.com>
Organization: VMware
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:10.0.6esrpre) Gecko/20120817 Icedove/10.0.6
MIME-Version: 1.0
To: pg noob <pgnube@gmail.com>
CC: pgsql-performance@postgresql.org
Subject: Re: deadlock_timeout affect on performance
References: 
 <CAPNY-2ULvbcLE9uuTG2=-Zhda+ghW63mPyrBirJ2VQRj=_2TVQ@mail.gmail.com>
In-Reply-To: 
 <CAPNY-2ULvbcLE9uuTG2=-Zhda+ghW63mPyrBirJ2VQRj=_2TVQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 01.10.2012 19:49, pg noob wrote:
> Hi all,
>
> I have a question about the deadlock_timeout in regards to performance.
> Right now we have this timeout set at its default of 1s.
> My understanding of it is that this means that every 1 second the server
> will check for deadlocks.

Not quite. It means that when a backend gets blocked, waiting on a lock, 
it will check for deadlocks after waiting for 1 second. When no backend 
is waiting for a lock, there are no deadlock checks regardless of 
deadlock_timeout.

> What I am wondering is how much of a performance improvement we would
> expect to get if this was raised to 30 seconds?
> Is it negligible or could it be a substantial performance improvement on a
> busy system?
> We very rarely have deadlocks and waiting 30 seconds to discover one
> doesn't seem too bad.

It's almost certainly negligible. If you regularly have deadlocks, it 
might even better for performance to make the timeout shorter than 1 s, 
so that deadlocks are detected earlier, and backends will spend less 
time deadlocked, and more time doing real work. Although I doubt it will 
make any meaningful difference either way.

- Heikki