Re: Optimizer failure on update w/integer column

> This is a unique index, right?  Seems like the cost must be related to
> checking for uniqueness violations --- the index code has to plow
> through all the index entries with the same key, visit their associated
> heap tuples, confirm those tuples are dead (or being deleted by the
> current transaction).  You could check this by seeing what the cost
> profile looks like with a nonunique index in place.

No, when I rebuilt the index it was NOT as a unique index.

> I'm not quite sure *why* it's happening though.  7.3 is supposed to have
> code in it to forestall indefinite growth of the number of heap visits
> that have to be made.  Hmm ... were you doing the repeated passes all in
> a single transaction block, or were you allowing the previous updates to
> commit before you tried again?

I was not in a transaction block.

I tried it again, this time exiting psql between runs.

72 seconds the first time, 351 seconds the 2nd time, 420 the 3rd time,
351 the 4th time.

Can I do anything further to help track this down?
--
Mike Nolan