Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 3E3442E32E1 for ; Thu, 29 Nov 2007 07:18:07 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 61503-06 for ; Thu, 29 Nov 2007 07:17:59 -0400 (AST) Received: from news.hub.org (news.hub.org [200.46.204.72]) by postgresql.org (Postfix) with ESMTP id ABC472E324A for ; Thu, 29 Nov 2007 07:18:05 -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 lATBI0Rk080992 for ; Thu, 29 Nov 2007 07:18:01 -0400 (AST) (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.14.1/8.14.1/Submit) id lATB7aDi076398 for pgsql-performance@postgresql.org; Thu, 29 Nov 2007 07:07:36 -0400 (AST) (envelope-from news) From: cluster X-Newsgroups: pgsql.performance Subject: Re: Query only slow on first run Date: Thu, 29 Nov 2007 12:07:37 +0100 Organization: Hub.Org Networking Services Lines: 8 Message-ID: <474E9D79.6000407@amossen.dk> 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> <20071128203442.GB30600@uio.no> <474DDA8F.3070801@amossen.dk> <24967.1196288664@sss.pgh.pa.us> 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 To: Tom Lane User-Agent: Thunderbird 2.0.0.6 (X11/20071022) In-Reply-To: <24967.1196288664@sss.pgh.pa.us> To: pgsql-performance@postgresql.org X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200711/369 X-Sequence-Number: 27784 > 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? (Therefore, as the relevant fraction becomes smaller over time, the "Filter: status = 1" operation becomes slower.)