Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 81D869FB6AA for ; Sun, 18 Mar 2007 12:55:09 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-new, port 10024) with ESMTP id 71195-01 for ; Sun, 18 Mar 2007 12:54:59 -0300 (ADT) X-Greylist: delayed 00:28:16.130915 by SQLgrey-1.7.4 Received: from skunk.mtbrook.bozemanpass.com (skunk.mtbrook.bozemanpass.com [69.145.82.195]) by postgresql.org (Postfix) with ESMTP id 26EE69FB686 for ; Sun, 18 Mar 2007 12:55:00 -0300 (ADT) Received: from [69.145.82.254] (unknown [69.145.82.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by skunk.mtbrook.bozemanpass.com (Postfix) with ESMTP id 9B65D5582C0; Sun, 18 Mar 2007 08:26:39 -0700 (PDT) Message-ID: <45FD5A2D.2090307@boreham.org> Date: Sun, 18 Mar 2007 09:26:37 -0600 From: David Boreham User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barry Moore CC: pgsql-performance@postgresql.org Subject: Re: Performance Tuning and Disk Cache References: <1862C4AD-EB83-4D58-B1F2-45BDC47E5608@genetics.utah.edu> In-Reply-To: <1862C4AD-EB83-4D58-B1F2-45BDC47E5608@genetics.utah.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200703/269 X-Sequence-Number: 23674 Barry Moore wrote: > I have a very slow query that I'm trying to tune. I think my > performance tuning is being complicated by the system's page cache. > > If a run the query after the system has been busy with other tasks > for quite a long time then the query can take up to 8-10 minutes to > complete. If I then rerun the same query it will complete in a > couple of seconds. > > Does anyone know how I can repeatedly run the same query in the > "worst case scenario" of no postgres data in the disk cache (e.g., > clear the page cache or force it to be ignored)? In my experience the only 100% reliable way to do this is to reboot the machine.