From: Steve Peterson <stevep-hv@zpfe.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: UPDATE becomes mired / win32
Date: Wed, 04 Oct 2006 23:56:11 -0500
Message-ID: <6.2.3.4.0.20061004235308.04af2248@localhost> (raw)
In-Reply-To: <21179.1159993723@sss.pgh.pa.us>
References: <6.2.3.4.0.20061004094635.03c114a8@localhost>
<21179.1159993723@sss.pgh.pa.us>
Both commands seem to be saturating the disk. There's nothing else
running in the database, and all of the locks have 't' in the granted
column, which I'm assuming means they're not blocked.
According to the statistics, the original table has 889 mb and
indexes of 911mb, whereas the copy has 1021 mb and no space for indexes.
Steve
At 03:28 PM 10/4/2006, Tom Lane wrote:
>Steve Peterson <stevep-hv@zpfe.com> writes:
> > If I run the statement:
> > (1): UPDATE voter SET gender = 'U';
> > on the table in this condition, the query effectively never ends --
> > I've allowed it to run for 12-14 hours before giving up.
> > ...
> > When (1) is running, the machine is very nearly idle, with no
> > postmaster taking more than 1 or 2 % of the CPU.
>
>Is the disk busy? If neither CPU nor I/O are saturated, then it's a
>good bet that the UPDATE isn't actually running at all, but is waiting
>for a lock somewhere. Have you looked into pg_locks to check for a
>conflicting lock?
>
> regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: stevep-hv@zpfe.com, tgl@sss.pgh.pa.us
Subject: Re: UPDATE becomes mired / win32
In-Reply-To: <6.2.3.4.0.20061004235308.04af2248@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox