Date: Wed, 28 Nov 2007 21:34:42 +0100
From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
To: cluster <skrald@amossen.dk>
Cc: pgsql-performance@postgresql.org
Subject: Re: Query only slow on first run
Message-ID: <20071128203442.GB30600@uio.no>
Mail-Followup-To: cluster <skrald@amossen.dk>,
 pgsql-performance@postgresql.org
References: <fihgt1$1mmh$1@news.hub.org>
	<20071127165543.GY11978@crankycanuck.ca>
	<23999.1196184368@sss.pgh.pa.us> <fihn7h$2jrn$1@news.hub.org>
	<056501c83128$55d58a90$8e00a8c0@tridecap.com>
	<fii71p$oc1$1@news.hub.org> <20071127233833.GA24031@uio.no>
	<15029.1196209554@sss.pgh.pa.us> <474CBF98.6070508@amossen.dk>
	<fikia6$26ql$1@news.hub.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <fikia6$26ql$1@news.hub.org>
User-Agent: Mutt/1.5.17 (2007-11-01)

On Wed, Nov 28, 2007 at 09:16:08PM +0100, cluster wrote:
> Hmm, actually I still don't understand why it takes 6400 ms to fetch the 
> rows. As far as I can see the index used is "covering" so that real row 
> lookups shouldn't be necessary.

The indexes don't contain visibility information, so Postgres has to look up
the row on disk to verify it isn't dead.

> Also, only the the random_numbers induces by questions with status = 1
> should be considered - and this part is a relatively small subset.

Again, you'll need to have a combined index if you want this to help you any.

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