Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-bugs by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group