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

Re: Index scan startup time

From: "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Index scan startup time
Date: 2006-03-30 12:31:34
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
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;
>>> 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

/* Steinar */

In response to


pgsql-performance by date

Next:From: Markus SchaberDate: 2006-03-30 12:35:53
Subject: Re: Index scan startup time
Previous:From: Peter EisentrautDate: 2006-03-30 12:24:27
Subject: Re: Index scan startup time

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