Re: Optimizer failure on update w/integer column

> 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.

I created the index, ran the update, ran it again, etc.  No other changes
are being made to the data in between consecutive update runs, but every
row is being updated on each pass.

I'm thinking this is related to how the index tracks updated rows
for concurrency, because even though disk space for the table grows
with each update run, the execution times remain similar without an
index on the table.

The performance tips in the docs seem to indicate that performance problems
can occur when indexed columns are updated, but in this case I'm not
updating an indexed column.

> > 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?

I'll see if I can transfer the data over to my prototyping system and
if it exhibits the same behavior then I can try profiling.  I'll try
playing around with it later this week, and also will see if doing a
vacuum in betwen runs has any impact.
--
Mike Nolan