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:[EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
