Date: Thu, 30 Mar 2006 07:42:53 -0500
From: Michael Stone <mstone+postgres@mathom.us>
Subject: Re: Index scan startup time
In-reply-to: <20060330123134.GA13408@uio.no>
To: pgsql-performance@postgresql.org
Cc: Peter Eisentraut <peter_e@gmx.net>
Mail-followup-to: pgsql-performance@postgresql.org,
	Peter Eisentraut <peter_e@gmx.net>
Message-id: <20060330124251.GK6811@mathom.us>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8; format=flowed
Content-transfer-encoding: 8BIT
Content-disposition: inline
References: <200603301359.11038.peter_e@gmx.net>
	<20060330120206.GA13075@uio.no> <200603301423.54510.peter_e@gmx.net>
	<20060330123134.GA13408@uio.no>
User-Agent: Mutt/1.5.11+cvs20060126

On Thu, Mar 30, 2006 at 02:31:34PM +0200, Steinar H. Gunderson wrote:
>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.

Yes. And the estimates are bad enough (orders of magnitude) that I can't 
help but wonder whether pg could come up with a better plan with better 
statistics:

>>>>   ->  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))

Mike Stone