"select max/count(id)" not using index
От | Ryszard Lach |
---|---|
Тема | "select max/count(id)" not using index |
Дата | |
Msg-id | 20031222103918.GA23673@siaco.id.pl обсуждение исходный текст |
Ответы |
Re: "select max/count(id)" not using index
Re: "select max/count(id)" not using index Re: "select max/count(id)" not using index Re: "select max/count(id)" not using index |
Список | pgsql-performance |
Hi. I have a table with 24k records and btree index on column 'id'. Is this normal, that 'select max(id)' or 'select count(id)' causes a sequential scan? It takes over 24 seconds (on a pretty fast machine): => explain ANALYZE select max(id) from ogloszenia; QUERY PLAN ---------------------------------------------------------------------- Aggregate (cost=3511.05..3511.05 rows=1 width=4) (actual time=24834.629..24834.629 rows=1 loops=1) -> Seq Scan on ogloszenia (cost=0.00..3473.04 rows=15204 width=4) (actual time=0.013..24808.377 rows=16873 loops=1) Total runtime: 24897.897 ms Maybe it's caused by a number of varchar fields in this table? However, 'id' column is 'integer' and is primary key. Clustering table on index created on 'id' makes such a queries many faster, but they still use a sequential scan. Richard. -- "First they ignore you. Then they laugh at you. Then they fight you. Then you win." - Mohandas Gandhi.
В списке pgsql-performance по дате отправления: