Re: "select max/count(id)" not using index
От | Pavel Stehule |
---|---|
Тема | Re: "select max/count(id)" not using index |
Дата | |
Msg-id | Pine.LNX.4.44.0312221201260.27697-100000@kix.fsv.cvut.cz обсуждение исходный текст |
Ответ на | "select max/count(id)" not using index (Ryszard Lach <siaco@autograf.pl>) |
Список | pgsql-performance |
Hello It is normal behavior PostgreSQL. Use SELECT id FROM tabulka ORDER BY id DESC LIMIT 1; regards Pavel On Mon, 22 Dec 2003, Ryszard Lach wrote: > 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. > >
В списке pgsql-performance по дате отправления: