Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 94D8D632A8B for ; Mon, 29 Mar 2010 13:54:41 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 13828-02-2 for ; Mon, 29 Mar 2010 16:54:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mail.postgresql.org (Postfix) with ESMTP id 2BBCA632D74 for ; Mon, 29 Mar 2010 13:53:37 -0300 (ADT) Received: from [192.168.0.105] (pool-96-244-14-10.bltmmd.fios.verizon.net [96.244.14.10]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0Lnlol-1NMesz36lz-00hoSr; Mon, 29 Mar 2010 18:53:36 +0200 Message-ID: <4BB0DB0D.80208@2ndquadrant.com> Date: Mon, 29 Mar 2010 12:53:33 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: "Campbell, Lance" CC: pgsql-performance@postgresql.org Subject: Re: How much memory is PostgreSQL using References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V01U2FsdGVkX18Xa35b95c2rIFQMV4yHQzBFImJblw2n6UoaJ2 QcYt5bJ9RvgMCmSRKR+ZNPfnIsSkl/qQ+ggA1NtyvaPZRLGZZv gg96El8UFIal0eRYC0VShzgEreEVyrL X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.074 tagged_above=-10 required=5 tests=AWL=-1.075, BAYES_50=0.001 X-Spam-Level: X-Archive-Number: 201003/372 X-Sequence-Number: 38197 Campbell, Lance wrote: > > Or is there some way to ask PostgreSQL how much memory are you using > to cache disk blocks currently? > You can install contrib/pg_buffercache into each database and count how many used blocks are there. Note that running queries using that diagnostic tool is really intensive due to the locks it takes, so be careful not to do that often on a production system. > When you do a PG_DUMP does PostgreSQL put the disk blocks into shared > buffers as it runs? > To some extent. Most pg_dump activity involves sequential scans that are reading an entire table. Those are no different from any other process that will put disk blocks into shared_buffers. However, that usage pattern makes pg_dump particularly likely to run into an optimization in 8.3 and later that limits how much of shared_buffers is used when sequentially scanning a large table. See P10 of http://www.westnet.com/~gsmith/content/postgresql/InsideBufferCache.pdf for the exact implementation. Basically, anything bigger than shared_buffers / 4 uses a 256K ring to limit its cache use, but it's a little more complicated than that. -- Greg Smith 2ndQuadrant US Baltimore, MD PostgreSQL Training, Services and Support greg@2ndQuadrant.com www.2ndQuadrant.us