On Thu, Mar 30, 2006 at 02:23:53PM +0200, Peter Eisentraut wrote: >>> EXPLAIN ANALYZE select activity_id from activity where state in (10000, >>> 10001) order by activity_id limit 100; >>> >>> QUERY PLAN >>> >>> Limit (cost=0.00..622.72 rows=100 width=8) (actual >>> time=207356.054..207356.876 rows=100 loops=1) >>> -> Index Scan using activity_pk on activity (cost=0.00..40717259.91 >>> rows=6538650 width=8) (actual time=207356.050..207356.722 rows=100 >>> loops=1) Filter: ((state = 10000) OR (state = 10001)) >>> Total runtime: 207357.000 ms >>> >>> The table has seen VACUUM FULL and REINDEX before this. >> The index scan is by activity_id, not by state. Do you have an index on >> state at all? > There is an index on state as well but the column is not selective enough. Well, it's logical enough; it scans along activity_id until it finds one with state=10000 or state=10001. You obviously have a _lot_ of records with low activity_id and state none of these two, so Postgres needs to scan all those records before it founds 100 it can output. This is the “startup cost” you're seeing. /* Steinar */ -- Homepage: http://www.sesse.net/
