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
