select is not using index?

From: Mark Harrison <mh(at)pixar(dot)com>
To: pgsql-performance(at)postgresql(dot)org
Subject: select is not using index?
Date: 2004-02-04 22:55:15
Message-ID: 40217853.20309@pixar.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

We are suddenly getting slow queries on a particular table.
Explain shows a sequential scan. We have "vacuum analyze" ed
the table.

Any hints?

Many TIA!
Mark

testdb=# \d bigtable
Table "public.bigtable"
Column | Type | Modifiers
---------+---------+-----------
id | bigint | not null
typeid | integer | not null
reposid | integer | not null
Indexes: bigtable_id_key unique btree (id)
Foreign Key constraints: type FOREIGN KEY (typeid) REFERENCES types(typeid) ON UPDATE NO ACTION ON DELETE NO ACTION,
repository FOREIGN KEY (reposid) REFERENCES repositories(reposid) ON UPDATE NO ACTION ON DELETE NO ACTION

testdb=# select count(1) from bigtable;
count
---------
3056831
(1 row)

testdb=# explain select * from bigtable where id = 123;
QUERY PLAN
-----------------------------------------------------------
Seq Scan on bigtable (cost=0.00..60000.00 rows=1 width=16)
Filter: (id = 123)
(2 rows)

testdb=# vacuum verbose analyze bigtable;
INFO: --Relation public.bigtable--
INFO: Pages 19200: Changed 0, Empty 0; Tup 3056831: Vac 0, Keep 0, UnUsed 207009.
Total CPU 1.03s/0.24u sec elapsed 9.32 sec.
INFO: Analyzing public.bigtable
VACUUM
testdb=# explain select * from bigtable where id = 123;
QUERY PLAN
-----------------------------------------------------------
Seq Scan on bigtable (cost=0.00..57410.39 rows=1 width=16)
Filter: (id = 123)
(2 rows)

--
Mark Harrison
Pixar Animation Studios

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Corey Edwards 2004-02-04 23:22:23 Re: select is not using index?
Previous Message William Yu 2004-02-04 22:44:42 Re: cache whole data in RAM