Received: from localhost (unknown [200.46.204.183])
	by postgresql.org (Postfix) with ESMTP id 0F7622E0041
	for <pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 29 Nov 2007 11:32:35 -0400 (AST)
Received: from postgresql.org ([200.46.204.71])
	by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024)
	with ESMTP id 81314-02 for
	<pgsql-performance-postgresql.org@postgresql.org>;
	Thu, 29 Nov 2007 11:32:27 -0400 (AST)
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by postgresql.org (Postfix) with ESMTP id CED872E003E
	for <pgsql-performance@postgresql.org>;
	Thu, 29 Nov 2007 11:32:26 -0400 (AST)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id lATFWOqA013659;
	Thu, 29 Nov 2007 10:32:24 -0500 (EST)
To: cluster <skrald@amossen.dk>
cc: pgsql-performance@postgresql.org
Subject: Re: Query only slow on first run 
In-reply-to: <474E9D79.6000407@amossen.dk> 
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> <20071128203442.GB30600@uio.no>
	<474DDA8F.3070801@amossen.dk> <24967.1196288664@sss.pgh.pa.us>
	<474E9D79.6000407@amossen.dk>
Comments: In-reply-to cluster <skrald@amossen.dk>
	message dated "Thu, 29 Nov 2007 12:07:37 +0100"
Date: Thu, 29 Nov 2007 10:32:23 -0500
Message-ID: <13658.1196350343@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Archive-Number: 200711/372
X-Sequence-Number: 27787

cluster <skrald@amossen.dk> writes:
>> You're essentially asking for a random sample of data that is not
>> currently in memory.  You're not going to get that without some I/O.

> No, that sounds reasonable enough. But do you agree with the statement 
> that my query will just get slower and slower over time as the number of 
> posts increases while the part having status = 1 is constant?

No, not as long as it sticks to that plan.  The time's basically
determined by the number of aggregate rows the LIMIT asks for,
times the average number of "post" rows per aggregate group.
And as far as you said the latter number is not going to increase.

			regards, tom lane