Re: UPDATE becomes mired / win32 - Mailing list pgsql-performance

From Steve Peterson
Subject Re: UPDATE becomes mired / win32
Date
Msg-id 6.2.3.4.0.20061004235308.04af2248@localhost
Whole thread Raw
In response to Re: UPDATE becomes mired / win32  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
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



pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_trgm indexes giving bad estimations?
Next
From: Steve Peterson
Date:
Subject: Re: UPDATE becomes mired / win32