Re: Adding and filling new column on big table - Mailing list pgsql-performance

From Michael Fuhr
Subject Re: Adding and filling new column on big table
Date
Msg-id 20060517023130.GA60671@winnie.fuhr.org
Whole thread Raw
In response to Adding and filling new column on big table  ("Jonathan Blitz" <jb@anykey.co.il>)
List pgsql-performance
On Wed, May 17, 2006 at 03:19:26AM +0200, Jonathan Blitz wrote:
> I have a table of about 500,000 rows.
>
> I need to add a new column and populate it.
>
> So, I have tried to run the following command. The command never finishes (I
> gave up after about and hour and a half!).

If you install contrib/pgstattuple you can figure out how fast the
update is running.  Run "SELECT * FROM pgstattuple('mytable')" a
few times and note the rate at which dead_tuple_count is increasing.
If it's not increasing at all then query pg_locks and look for locks
where "granted" is false.

I created a test table, populated it with 500,000 rows of random
data, and ran the update you posted.  On a 500MHz Pentium III with
512M RAM and a SCSI drive from the mid-to-late 90s, running PostgreSQL
8.1.3 on FreeBSD 6.1, the update finished in just over two minutes.
The table had one index (the primary key).

> Note that none of the columns have indexes.

Do you mean that no columns in the table have indexes?  Or that the
columns referenced in the update don't have indexes but that other
columns do?  What does "\d mytable" show?  Do other tables have
foreign key references to this table?  What non-default settings
do you have in postgresql.conf?  What version of PostgreSQL are you
running and on what platform?  How busy is the system?  What's the
output of "EXPLAIN UPDATE mytable ..."?

--
Michael Fuhr

pgsql-performance by date:

Previous
From: "Craig A. James"
Date:
Subject: Re: Speed Up Offset and Limit Clause
Next
From: kah_hang_ang@toray.com.my
Date:
Subject: Performance incorporate with JReport