X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 65B0D9FA612 for ; Sat, 22 Jul 2006 20:15:52 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 69996-03 for ; Sat, 22 Jul 2006 20:15:47 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by postgresql.org (Postfix) with ESMTP id EAAA19F9F73 for ; Sat, 22 Jul 2006 20:15:48 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1G4Qh2-0005cM-00; Sat, 22 Jul 2006 19:15:32 -0400 To: "Craig A. James" Cc: Tom Lane , robin.c.smith@bt.com, pgsql-performance@postgresql.org Subject: Re: Forcing using index instead of sequential scan? References: <26827.1153585341@sss.pgh.pa.us> <44C25FDD.8070003@modgraph-usa.com> In-Reply-To: <44C25FDD.8070003@modgraph-usa.com> From: Gregory Stark Organization: EnterpriseDB Date: 22 Jul 2006 19:15:31 -0400 Message-ID: <87slktteng.fsf@stark.xeocode.com> Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.384 tagged_above=0 required=5 tests=SPF_SOFTFAIL X-Spam-Level: * X-Archive-Number: 200607/222 X-Sequence-Number: 20082 "Craig A. James" writes: > This causes massive file-system activity and flushes all files that the > kernel has cached. If you run this between each Postgres test (let it run > for a couple minutes), it gives you an apples-to-apples comparison between > successive benchmarks, and eliminates the effects of caching. On Linux at least the best way to flush the cache is to unmount and then mount the filesystem. This requires putting the data files on partition that you aren't otherwise using and shutting down postgres. Note that "nothing cached" isn't necessarily any more accurate a model as "everything cached". In reality many databases *do* in fact run the same queries over and over again, though often with some parameters different each time. But the upper pages of most indexes and many of the common leaf pages and heap pages will in fact be cached. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com