Date: Thu, 30 Mar 2006 15:00:41 +0200
From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: Index scan startup time
Message-ID: <20060330130041.GA13732@uio.no>
Mail-Followup-To: pgsql-performance@postgresql.org
References: <200603301359.11038.peter_e@gmx.net>
	<200603301423.54510.peter_e@gmx.net>
	<20060330123134.GA13408@uio.no>
	<200603301459.03011.peter_e@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <200603301459.03011.peter_e@gmx.net>
User-Agent: Mutt/1.5.11+cvs20060126

On Thu, Mar 30, 2006 at 02:59:02PM +0200, Peter Eisentraut 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.
> The startup cost is the cost until the plan is set up to start outputting 
> rows.  It is not the time until the first row is found.

Well, point, my terminology was wrong. Still, what you're seeing is endless
scanning for the first row. I don't know your distribution, but are you
really sure state wouldn't have better selectivity?

/* Steinar */
-- 
Homepage: http://www.sesse.net/