Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 0823BB5DBE3 for ; Sat, 28 May 2011 18:47:24 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 01537-01 for ; Sat, 28 May 2011 21:47:15 +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 5D157B5DBD7 for ; Sat, 28 May 2011 18:47:14 -0300 (ADT) Received: from [192.168.1.6] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mrbap4) with ESMTP (Nemesis) id 0Lc82v-1PjMl20smj-00jdqd; Sat, 28 May 2011 23:47:13 +0200 Message-ID: <4DE16D60.9070804@2ndQuadrant.com> Date: Sat, 28 May 2011 17:47:12 -0400 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110505 Icedove/3.0.11 MIME-Version: 1.0 To: Mark Kirkwood CC: Merlin Moncure , postgres performance list Subject: Re: The shared buffers challenge References: <4DDEDDDB.6000607@2ndquadrant.com> <4DE03413.5050001@catalyst.net.nz> In-Reply-To: <4DE03413.5050001@catalyst.net.nz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:IGbP+6rVG5M0vxVNgjTLTHBq3XlWeb+t9LN25mAXMBV TN4THdMmKNcAnoayZ2Tdxzjc3NVqth21eDhP+EYvLK0QdWLSRv e4YitebONmcVraT4qvUPtvZgWJLO1JuYbNACFPvgSv0rb6i0QI MOFrkVzrk4ZqdZCUKdgkIobs7ZJ8Te43mY+PHmRY9az2nGkYSc 8aMTTRrr/IZsCsYW4Novh70Je+ozR6f/HI8pkzYhHY= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201105/412 X-Sequence-Number: 43921 On 05/27/2011 07:30 PM, Mark Kirkwood wrote: > Greg, having an example with some discussion like this in the docs > would probably be helpful. If we put that example into the docs, two years from now there will be people showing up here saying "I used the recommended configuration from the docs" that cut and paste it into their postgresql.conf, turning autovacuum off and everything. Periodically people used to publish "recommended postgresql.conf" settings on random web pages, sometimes with poor suggestions, and those things kept showing up in people's configurations posted to the lists here for long after they were no longer applicable. I've resisted publishing specific configuration examples in favor of working on pgtune specifically because of having observed that. There's several new small features in 9.1 that make it a easier to instrument checkpoint behavior and how it overlaps with shared_buffers increases: summary of sync times, ability to reset pg_stat_bgwriter, and a timestamp on when it was last reset. It's not obvious at all how those all stitch together into some new tuning approaches, but they do. Best example I've given so far is at http://archives.postgresql.org/pgsql-hackers/2011-02/msg00209.php ; look at how I can turn the mysterious buffers_backend field into something measured in MB/s using these new features. That's the direction all this is moving toward. If it's easy for people to turn the various buffer statistics into human-readable form, the way tuning changes impact the server operation becomes much easier to see. Documenting the much harder to execute methodology you can apply to earlier versions isn't real exciting to me at this point. I've done that enough that people who want the info can find it, even if it's not all in the manual. The ways you can do it in 9.1 are so much easier, and more accurate in regards to the sync issues, that I'm more interested in beefing up the manual in regards to using them at this point. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books