Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 93927633A6D for ; Thu, 26 Feb 2009 08:24:32 -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 85140-09 for ; Thu, 26 Feb 2009 08:24:29 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.pommesbude.org (mail.pommesbude.org [88.198.164.122]) by mail.postgresql.org (Postfix) with ESMTP id 8E045633707 for ; Thu, 26 Feb 2009 08:24:29 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by mail.pommesbude.org (Postfix) with ESMTP id 2A80BD5CF33; Thu, 26 Feb 2009 13:24:26 +0100 (CET) X-Virus-Scanned: amavisd-new 2.6.1 (20080629) at pommesbude.org Received: from mail.pommesbude.org ([88.198.164.122]) by localhost (mail.pommesbude.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qI+mNKj1-H7f; Thu, 26 Feb 2009 13:24:26 +0100 (CET) Received: from MacBook.local (p57A5E52D.dip.t-dialin.net [87.165.229.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pommesbude.org (Postfix) with ESMTPSA id AB4CFD330B6; Thu, 26 Feb 2009 13:24:25 +0100 (CET) Message-ID: <49A689F8.2070607@d0pefish.de> Date: Thu, 26 Feb 2009 13:24:24 +0100 From: Peter Hinse User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Tom Lane CC: pgsql-admin@postgresql.org Subject: Re: lseek References: <499B2423.3000809@d0pefish.de> <9125.1234906484@sss.pgh.pa.us> In-Reply-To: <9125.1234906484@sss.pgh.pa.us> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit 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/234 X-Sequence-Number: 31455 Tom Lane schrieb: > Peter Hinse 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 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. After downgrading to 8.3.5, the massive problems we had with our system are gone. With 8.3.6, we had these hanging jobs in 100% of all runs (this is a DWH, the job calculates the ranking for users). We tried several settings for GEQO, that made it even worse - some jobs, that never had any problems, started to act weird (did not terminate) with the same lseek in strace. We will investigate this issue with some more test machines. Regards, Peter