Re: Optimizer failure on update w/integer column

nolan@celery.tssi.com writes:
> No, when I rebuilt the index it was NOT as a unique index.

Hmm, so much for that theory.

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

What exactly are you defining as "the first time" --- the first time
after creating a fresh index?  What percentage of table tuples actually
get updated in each command?  I'm wondering if maybe it's just a matter
of the first time not incurring very many btree page splits while the
later runs incur lots.  But that theory seems weak as well.

> Can I do anything further to help track this down?

Perhaps rebuild the backend with profiling enabled and get a runtime
profile in both the faster and slower cases?

            regards, tom lane