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

From: Reinhard Max <max(at)suse(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Michael G(dot) Martin" <michael(at)vpmonline(dot)com>,<pgsql-bugs(at)postgresql(dot)org>
Subject: Re: Indexes not always used after inserts/updates/vacuum
Date: 2002-03-01 07:06:18
Message-ID: Pine.LNX.4.44.0203010733570.16110-100000@Wotan.suse.de
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message cnliou 2002-03-01 07:57:54 Encoding Problem?
Previous Message Tom Lane 2002-02-28 21:10:21 Re: Indexes not always used after inserts/updates/vacuum analyze