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

Bug #790: Optimizer does not want to use an index for large table

From: pgsql-bugs(at)postgresql(dot)org
To: pgsql-bugs(at)postgresql(dot)org
Subject: Bug #790: Optimizer does not want to use an index for large table
Date: 2002-09-29 10:25:27
Message-ID: 20020929102527.BFDEA475FDD@postgresql.org (view raw or flat)
Thread:
Lists: pgsql-bugs
Jekabs Andrushaitis (jeecha(at)one(dot)lv) reports a bug with a severity of 2
The lower the number the more severe it is.

Short Description
Optimizer does not want to use an index for large table

Long Description
I have a table with large number of records (100000). Data from this table is mostly selected using one field, on which there is an index.
Explain plan does not show that query engine will use this index, however, which is odd, since statistics clearly show that index fits in a single page, while whole table is about 600 pages. The most common select on the table would retrieve about 10 rows of data, and using the index would be way more efficient. I read the documentation describing indexes, explain plans and how the statistics affects queries, and according to docs, the index should have been used...but Explain shows that it's not. I tried dropping and re-creating the index, but still it's not used!
I am usine PostgreSQL 7.2 on Linux Mandrake.

Sample Code
CREATE TABLE obj_props(obj_id int8,name text,value text);

for i:=0 to 10000
  for j:=0 to 10
    INSERT INTO obj_props(i,'some name','some value');

CREATE INDEX obj_props_ind1 ON obj_props(obj_id);

VACUUM ANALYZE;

EXPLAIN SELECT name,value FROM obj_props WHERE obj_id=100;

... this shows that sequential scan is used, however using index obj_props_ind1 would have been VERY efficient!

No file was uploaded with this report


Responses

pgsql-bugs by date

Next:From: Rod TaylorDate: 2002-09-29 13:46:43
Subject: Re: Bug #790: Optimizer does not want to use an index for
Previous:From: Bruce MomjianDate: 2002-09-29 05:19:28
Subject: Re: Bug #789: Transaction Archival Logging -- Hot Backups

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