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

From: Evil Azrael <evilazrael(at)evilazrael(dot)de>
To: Ryszard Lach <siaco(at)autograf(dot)pl>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: "select max/count(id)" not using index
Date: 2003-12-22 10:59:58
Message-ID: 110164283326.20031222115958@evilazrael.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Guten Tag Ryszard Lach,

Am Montag, 22. Dezember 2003 um 11:39 schrieben Sie:

RL> Hi.

RL> I have a table with 24k records and btree index on column 'id'. Is this
RL> normal, that 'select max(id)' or 'select count(id)' causes a sequential
RL> scan? It takes over 24 seconds (on a pretty fast machine):

Yes, that was occasionally discussed on the mailinglists. For the
max(id) you can use instead "SELECT id FROM table ORDER BY id DESC
LIMIT 1"

Christoph Nelles

=>> explain ANALYZE select max(id) from ogloszenia;
RL> QUERY PLAN
RL> ----------------------------------------------------------------------
RL> Aggregate (cost=3511.05..3511.05 rows=1 width=4) (actual
RL> time=24834.629..24834.629 rows=1 loops=1)
RL> -> Seq Scan on ogloszenia (cost=0.00..3473.04 rows=15204 width=4)
RL> (actual time=0.013..24808.377 rows=16873 loops=1)
RL> Total runtime: 24897.897 ms

RL> Maybe it's caused by a number of varchar fields in this table? However,
RL> 'id' column is 'integer' and is primary key.

RL> Clustering table on index created on 'id' makes such a queries
RL> many faster, but they still use a sequential scan.

RL> Richard.

--
Mit freundlichen Grüssen
Evil Azrael mailto:evilazrael(at)evilazrael(dot)de

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Pavel Stehule 2003-12-22 11:03:05 Re: "select max/count(id)" not using index
Previous Message Christopher Kings-Lynne 2003-12-22 10:56:50 Re: "select max/count(id)" not using index