Re: Indexes not always used after inserts/updates/vacuum

Hi,

On Thu, 28 Feb 2002 at 16:10, Tom Lane wrote:

> >         ->  Index Scan using foo2_pkey on foo2
> >                   (cost=0.00..10387.79 rows=352072 width=4)
> >                   (actual time=0.26..174.32 rows=38432 loops=1)
>
> The actual rows read from this indexscan seem to be many fewer than
> the number of rows in the table.  What are the ranges of the id
> values in tables foo and bar?  I'm wondering if the merge could have
> stopped far short of the end of the foo table; if so, *that* is the
> effect that we are failing to model accurately.

Good guess :)

max=# SELECT 'bar' AS tablename, min(ref2foo), max(ref2foo),
      count(ref2foo) FROM bar
      UNION SELECT 'foo', min(id), max(id), count(id) from foo;

 tablename |   min    |   max    | count
-----------+----------+----------+--------
 bar       | 10000010 | 10049999 |  38431
 foo       | 10000010 | 10423442 | 352072
(2 rows)

I'll tell my colleague (it's his test database, after all) that he
should take more realistic test data before complaining about bad
performance...

cu
	Reinhard