Re: Indexes not always used after inserts/updates/vacuum - Mailing list pgsql-bugs

From Reinhard Max
Subject Re: Indexes not always used after inserts/updates/vacuum
Date
Msg-id Pine.LNX.4.44.0203010733570.16110-100000@Wotan.suse.de
Whole thread Raw
In response to Re: Indexes not always used after inserts/updates/vacuum analyze  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Indexes not always used after inserts/updates/vacuum analyze  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
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

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: Indexes not always used after inserts/updates/vacuum analyze
Next
From: pgsql-bugs@postgresql.org
Date:
Subject: Bug #605: timestamp(timestamp('a timestamp)) no longer works