DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta;
	h=received:subject:from:reply-to:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding;
	b=YpGLDsnxs5vrz40vKojvcsNZjQJiBknHfd6KkfBv5CSWk0gADTt3xhxA3xuPii61CpO0ohuZpeg45FJJ5teS4KY7Ra/Yg+p/416TDjxczsFu45p4btmyPuphNbf5y+Sy4+3li70prWOPRGpFgbQ20PSLguq5xZZzeArjXm8+k8Q=
Subject: Re: Simple select hangs while CPU close to 100%
From: Adam Tauno Williams <adamtaunowilliams@gmail.com>
Reply-To: adamtaunowilliams@gmail.com
To: pgsql-performance@postgresql.org
In-Reply-To: <E387E2E9622FDD408359F98BF183879EE02634@dc1.storediq.com>
References: <E387E2E9622FDD408359F98BF183879EE02634@dc1.storediq.com>
Content-Type: text/plain; charset=UTF-8
Date: Sun, 22 Jul 2007 14:32:45 -0400
Message-Id: <1185129165.4159.1.camel@aleph.whitemice.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit


> I’m having this very disturbing problem. I got a table with about
> 100,000 rows in it. Our software deletes the majority of these rows
> and then bulk loads another 100,000 rows into the same table. All this
> is happening within a single transaction. I then perform a simple
> “select count(*) from …” statement that never returns. In the mean

COUNT(*) is always slow;  but either way if the process is deleting and
then adding records, can't you just keep track of how may records you
loaded [aka count++] rather than turning around and asking the database
before any statistics have had a chance to be updated.

>  time, the backend Postgres process is taking close to 100% of the
> CPU. The hang-up does not always happen on the same statement but
> eventually it happens 2 out of 3 times. If I dump and then restore the
> schema where this table resides the problem is gone until the next
> time we run through the whole process of deleting, loading and
> querying the table.
> There is no other activity in the database. All requested locks are
> granted.