Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 87E9B633107
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Tue, 17 Feb 2009 17:34:54 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 66483-03 for
	<pgsql-admin-postgresql.org@mail.postgresql.org>;
	Tue, 17 Feb 2009 17:34:49 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id 52B3F6330F5
	for <pgsql-admin@postgresql.org>; Tue, 17 Feb 2009 17:34:48 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id n1HLYiCY009126;
	Tue, 17 Feb 2009 16:34:44 -0500 (EST)
To: Peter Hinse <loco@d0pefish.de>
cc: pgsql-admin@postgresql.org
Subject: Re: lseek 
In-reply-to: <499B2423.3000809@d0pefish.de> 
References: <499B2423.3000809@d0pefish.de>
Comments: In-reply-to Peter Hinse <loco@d0pefish.de>
	message dated "Tue, 17 Feb 2009 21:54:59 +0100"
Date: Tue, 17 Feb 2009 16:34:44 -0500
Message-ID: <9125.1234906484@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none
X-Spam-Level: 
X-Archive-Number: 200902/133
X-Sequence-Number: 31354

Peter Hinse <loco@d0pefish.de> writes:
> More info: the statement is an INSERT with some huge subselects, running
> every night on a PGSQL 8.3.6 on CentOS 4.7 x86_64. In 97% of all
> occasions, the job terminates in about 1-2 minutes - however, sometimes
> it just hangs. If terminated with kill <pid> and restarted, it always
> terminates.

Define "huge" --- you mean a lot of relations in the query?  If you have
enough to trigger GEQO optimization, it could be that it's sometimes
picking a bad plan.  You might try raising the geqo threshold to more
relations than that; or if this results in unacceptably long planning
time, increase geqo_effort instead.

			regards, tom lane