Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id D93F72E0330 for ; Wed, 28 Nov 2007 16:17:55 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 71854-07 for ; Wed, 28 Nov 2007 16:17:52 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by postgresql.org (Postfix) with ESMTP id 117B22E0309 for ; Wed, 28 Nov 2007 16:17:55 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.14.1/8.14.1) with ESMTP id lASKHqWw072688 for ; Wed, 28 Nov 2007 16:17:52 -0400 (AST) (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.14.1/8.14.1/Submit) id lASKG662072535 for pgsql-performance@postgresql.org; Wed, 28 Nov 2007 16:16:06 -0400 (AST) (envelope-from news) From: cluster X-Newsgroups: pgsql.performance Subject: Re: Query only slow on first run Date: Wed, 28 Nov 2007 21:16:08 +0100 Organization: Hub.Org Networking Services Lines: 12 Message-ID: References: <20071127165543.GY11978@crankycanuck.ca> <23999.1196184368@sss.pgh.pa.us> <056501c83128$55d58a90$8e00a8c0@tridecap.com> <20071127233833.GA24031@uio.no> <15029.1196209554@sss.pgh.pa.us> <474CBF98.6070508@amossen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@news.hub.org User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: <474CBF98.6070508@amossen.dk> To: pgsql-performance@postgresql.org X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/362 X-Sequence-Number: 27777 >> I'm wondering why --- doesn't seem like it should take 6400msec to fetch >> 646 rows, unless perhaps the data is just horribly misordered relative >> to the index. Which may in fact be the case ... 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. Also, only the the random_numbers induces by questions with status = 1 should be considered - and this part is a relatively small subset. In general, I don't understand why the query is so I/O dependant as it apparently is.