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