Re: Optimizer failure on update w/integer column - Mailing list pgsql-general

From nolan@celery.tssi.com
Subject Re: Optimizer failure on update w/integer column
Date
Msg-id 20030616002633.25539.qmail@celery.tssi.com
Whole thread Raw
In response to Re: Optimizer failure on update w/integer column  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Optimizer failure on update w/integer column  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-general
> 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



pgsql-general by date:

Previous
From: Markus Bertheau
Date:
Subject: Re: [HACKERS] UTF8 and KOI8 mini-howto
Next
From: Tom Lane
Date:
Subject: Re: Optimizer failure on update w/integer column