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
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 |