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

"select max/count(id)" not using index

From: Ryszard Lach <siaco(at)autograf(dot)pl>
To: pgsql-performance(at)postgresql(dot)org
Subject: "select max/count(id)" not using index
Date: 2003-12-22 10:39:18
Message-ID: 20031222103918.GA23673@siaco.id.pl (view raw or flat)
Thread:
Lists: 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.

Responses

pgsql-performance by date

Next:From: Christopher Kings-LynneDate: 2003-12-22 10:56:50
Subject: Re: "select max/count(id)" not using index
Previous:From: William YuDate: 2003-12-19 17:44:17
Subject: Re: why do optimizer parameters have to be set manually?

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