Received: from localhost (unknown [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 42EF69F9B4B for ; Fri, 21 Sep 2007 07:35:51 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 28400-08 for ; Fri, 21 Sep 2007 07:35:42 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from mail01.enterprisedb.com (mail01.enterprisedb.com [63.246.7.168]) by postgresql.org (Postfix) with ESMTP id AAA919F9AC5 for ; Fri, 21 Sep 2007 07:35:46 -0300 (ADT) thread-index: Acf8OzP7RYCGGz7lSGu2QyCEguWO2Q== Received: from [192.168.1.34] ([82.27.245.44]) by mail01.enterprisedb.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 21 Sep 2007 06:35:55 -0400 Content-Class: urn:content-classes:message Message-ID: <46F39E4D.1080401@enterprisedb.com> Importance: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4073 Date: Fri, 21 Sep 2007 11:34:53 +0100 From: "Heikki Linnakangas" User-Agent: Icedove 1.5.0.12 (X11/20070730) MIME-Version: 1.0 To: "Csaba Nagy" Cc: "Gregory Stark" , "Decibel!" , Subject: Re: Linux mis-reporting memory References: <20070920230400.GM95343@decibel.org> <16213.1190329934@sss.pgh.pa.us> <87r6ksa1jb.fsf@oxford.xeocode.com> <1190363401.4661.116.camel@PCD12478> <87r6ksuzf8.fsf@oxford.xeocode.com> <1190369325.4661.178.camel@PCD12478> In-Reply-To: <1190369325.4661.178.camel@PCD12478> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Sep 2007 10:35:55.0640 (UTC) FILETIME=[30DCDF80:01C7FC3B] X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200709/354 X-Sequence-Number: 26899 Csaba Nagy wrote: > On Fri, 2007-09-21 at 10:43 +0100, Gregory Stark wrote: >> The other possibility is that Postgres just hasn't even touched a large part >> of its shared buffers. > > But then how do you explain the example I gave, with a 5.5GB table > seq-scanned 3 times, shared buffers set to 12 GB, and top still showing > almost 100% memory as cached and no SWAP "used" ? In this case you can't > say postgres didn't touch it's shared buffers - or a sequential scan > won't use the shared buffers ? Which version of Postgres is this? In 8.3, a scan like that really won't suck it all into the shared buffer cache. For seq scans on tables larger than shared_buffers/4, it switches to the bulk read strategy, using only a few buffers, and choosing the starting point with the scan synchronization facility. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com