Index scan startup time

From: Peter Eisentraut
Subject: Index scan startup time
Date: ,
Msg-id: 200603301359.11038.peter_e@gmx.net
(view: Whole thread, Raw)
Responses: Re: Index scan startup time  ("Steinar H. Gunderson")
Re: Index scan startup time  (Michael Stone)
Re: Index scan startup time  (Simon Riggs)
List: pgsql-performance

Tree view

Index scan startup time  (Peter Eisentraut, )
 Re: Index scan startup time  ("Steinar H. Gunderson", )
  Re: Index scan startup time  (Peter Eisentraut, )
   Re: Index scan startup time  ("Steinar H. Gunderson", )
    Re: Index scan startup time  (Michael Stone, )
     Re: Index scan startup time  ("Steinar H. Gunderson", )
      Re: Index scan startup time  (Michael Stone, )
       Re: Index scan startup time  (Tom Lane, )
        Re: Index scan startup time  (Peter Eisentraut, )
         Re: Index scan startup time  (Tom Lane, )
    Re: Index scan startup time  (Peter Eisentraut, )
     Re: Index scan startup time  ("Steinar H. Gunderson", )
 Re: Index scan startup time  (Michael Stone, )
  Re: Index scan startup time  (Peter Eisentraut, )
   Re: Index scan startup time  (Markus Schaber, )
 Re: Index scan startup time  (Simon Riggs, )

[Apologies if this already went through.  I don't see it in the archives.]

Normally one expects that an index scan would have a startup time of nearly
zero.  Can anyone explain this:

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 plan choice and the statistics look right, but why does it take 3 minutes
before doing anything?  Or is the measurement of the actual start time
inaccurate?  This is quite reproducible, so it's not just a case of a
temporary I/O bottleneck, say.

(PostgreSQL 8.0.3)

--
Peter Eisentraut
http://developer.postgresql.org/~petere/


pgsql-performance by date:

From: Simon Riggs
Date:
Subject: Re: Index scan startup time
From: Chris Browne
Date:
Subject: Re: Decide between Postgresql and Mysql (help of