>>> On Mon, Sep 3, 2007 at 11:15 AM, in message
<20070903091558(dot)0780b963(at)boffin(dot)xmtservices(dot)net>, Shawn
<postgres(at)xmtservices(dot)net> wrote:
> On Sun, 02 Sep 2007 10:49:09 -0500 "Kevin Grittner"
> <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>
>> >>> On Sat, Sep 1, 2007 at 12:29 PM, in message
>> <20070901102947(dot)0c0a50a3(at)boffin(dot)xmtservices(dot)net>, Shawn
>> <postgres(at)xmtservices(dot)net> wrote:
>> > update shawns_data set alias = null;
>> > Even after VACUUM this simple line takes 35 sec to complete.
>>
>> Would any rows already have a null alias when you run this?
>> If so, try adding 'where alias is not null' to the query.
>
> This one initially added about 10sec to the run but I added a HASH
> index on the alias field and its now about 5 sec average runtime, a net
> improvement.
Testing for null on 15,700 rows took five seconds more than the time saved
from not updating some portion of the rows????? I've never seen anything
remotely like that.
Did you ever capture the output of VACUUM VERBOSE against this table (as
Tom requested)?
What happens if you run CLUSTER against this table before running one of
these updates? (Be sure to do that VACUUM VERBOSE first, to see what the
"old" state of the table was, and run it again after.)
What is the row count from the second update of the table in your script?
(An overly loose join there could bloat the table.)
-Kevin