Received: from localhost (unknown [200.46.204.183])
	by mail.postgresql.org (Postfix) with ESMTP id 5BD0F64FE43
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 22 Dec 2008 09:28:06 -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 14579-06
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Mon, 22 Dec 2008 09:28:04 -0400 (AST)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from viefep18-int.chello.at (viefep12-int.chello.at [62.179.121.32])
	by mail.postgresql.org (Postfix) with ESMTP id 8675D64FD4B
	for <pgsql-performance@postgresql.org>;
	Mon, 22 Dec 2008 09:28:03 -0400 (AST)
Received: from edge05.upc.biz ([192.168.13.212]) by viefep12-int.chello.at
	(InterMail vM.7.09.01.00 201-2219-108-20080618) with ESMTP
	id <20081222132800.VNWN1315.viefep12-int.chello.at@edge05.upc.biz>;
	Mon, 22 Dec 2008 14:28:00 +0100
Received: from [192.168.1.104] ([89.134.230.11]) by edge05.upc.biz with edge
	id uDTy1a02p0FQLHV05DTz4n; Mon, 22 Dec 2008 14:28:00 +0100
X-SourceIP: 89.134.230.11
Message-ID: <494F95DE.1060605@shopzeus.com>
Date: Mon, 22 Dec 2008 14:27:58 +0100
From: Laszlo Nagy <gandalf@shopzeus.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: Gregory Williamson <Gregory.Williamson@digitalglobe.com>
CC: pgsql-performance@postgresql.org
Subject: Re: Slow table update
References: <494F749A.5090603@shopzeus.com> <494F7B48.6070204@shopzeus.com>
	<8B319E5A30FF4A48BE7EEAAF609DB233021F389A@COMAIL01.digitalglobe.com>
In-Reply-To: 
 <8B319E5A30FF4A48BE7EEAAF609DB233021F389A@COMAIL01.digitalglobe.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=2.125 tagged_above=0 required=5
	tests=DNS_FROM_RFC_BOGUSMX=2.125
X-Spam-Level: **
X-Archive-Number: 200812/189
X-Sequence-Number: 32225

I just tested the same on a test machine. It only has one processor 1GB 
memory, and one SATA disk. The same "select count(*)" was 58 seconds. I 
started the same UPDATE with EXPLAIN ANALYZE. It is running since 1000 
seconds. I'm now 100% sure that the problem is with the database, 
because this machine has nothing but a postgresql server running on it. 
I'll post the output of explain analyze later.