DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns;
	h=dkim-signature:message-id:date:from:user-agent:
	mime-version:to:subject:content-type:
	content-transfer-encoding:x-system-of-record;
	b=T8fYjf00bmkYz3vlh8B1Kb0OvLI0tG8cPD+3qkU6QK6DJaDKT41F1SsPpL0+FPRwm
	4Cm7/y6YJabM6K7X3zXuw==
Message-ID: <4EA82B7C.1040008@google.com>
Date: Wed, 26 Oct 2011 17:47:08 +0200
From: =?ISO-8859-1?Q?S=F6ren_Meyer-Eppler?= <soerenme@google.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: PostgreSQL 9.0.4 blocking in lseek?
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

We are running into a significant performance issue with
"PostgreSQL 9.0.4 on x86_64-pc-linux-gnu, compiled by GCC gcc-4.4.real 
(Debian 4.4.5-8) 4.4.5, 64-bit"
(the version string pqAdmin displays).

A fairly complex insert query on an empty destination table will run for 
an indefinite amount of time (we waited literally days for the query to 
complete). This does not happen every time we run the query but often. 
Now ordinarily I'd assume we did something wrong with our indices or 
query, but the execution plan looks sane and, more tellingly, we have:
- no CPU load
- no network traffic
- no disk I/O
- no other load on the server except this single query
and strace displaying a seemingly endless list of lseek calls.

So my assumption is that we are not running into bad Big-O() runtime 
behavior but rather into some locking problem.

Any ideas what might cause this? Workarounds we could try?

thank you,

     Sören