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

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

From: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>
To: Ryszard Lach <siaco(at)autograf(dot)pl>
Cc: pgsql-performance(at)postgresql(dot)org, Ryszard Lach <rla(at)debian(dot)org>
Subject: Re: "select max/count(id)" not using index
Date: 2003-12-22 11:03:05
Message-ID: Pine.LNX.4.44.0312221201260.27697-100000@kix.fsv.cvut.cz (view raw or flat)
Thread:
Lists: 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.
> 
> 


In response to

pgsql-performance by date

Next:From: Tomasz MyrtaDate: 2003-12-22 11:03:45
Subject: Re: "select max/count(id)" not using index
Previous:From: Evil AzraelDate: 2003-12-22 10:59:58
Subject: Re: "select max/count(id)" not using index

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