Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id 467342E0074 for ; Wed, 11 Jun 2008 22:12:37 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 49543-01-9 for ; Wed, 11 Jun 2008 22:11:58 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from oxford.xeocode.com (87-127-95-198.no-dns-yet.enta.net [87.127.95.198]) by developer.postgresql.org (Postfix) with ESMTP id 698522E00C3 for ; Wed, 11 Jun 2008 22:02:02 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=oxford.xeocode.com) by oxford.xeocode.com with esmtp (Exim 4.69) (envelope-from ) id 1K6bCI-0001NU-Df; Thu, 12 Jun 2008 02:01:50 +0100 To: "Josh Berkus" Cc: "Tom Lane" , "Alvaro Herrera" , "Heikki Linnakangas" , , "Robert Treat" , "Peter Eisentraut" , "Greg Smith" , "Andreas Pflug" , "Decibel!" Subject: Re: Overhauling GUCS In-Reply-To: <48506FD4.7020804@agliodbs.com> (Josh Berkus's message of "Wed\, 11 Jun 2008 17\:37\:40 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+mail01.enterprisedb.com:INBOX" 87499) References: <48409D1E.3070208@agliodbs.com> <200806061624.29105.xzilla@users.sourceforge.net> <200806100937.38124.josh@agliodbs.com> <200806100949.17918.josh@agliodbs.com> <21875.1213122184@sss.pgh.pa.us> <484F7613.5070202@enterprisedb.com> <484FFF06.9010307@agliodbs.com> <20080611163847.GN5352@alvh.no-ip.org> <11913.1213218315@sss.pgh.pa.us> <87od674hy6.fsf@oxford.xeocode.com> <48506FD4.7020804@agliodbs.com> From: Gregory Stark Organization: EnterpriseDB Date: Thu, 12 Jun 2008 02:01:49 +0100 Message-ID: <87k5gv4gaq.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/539 X-Sequence-Number: 119652 "Josh Berkus" writes: > Greg, > >> At least that way we could always steal more if we want or return some, as >> long as we're careful about when we do it. That would open the door to having >> these parameters be dynamically adjustable. That alone would be worthwhile >> even if we bypass all bells and whistles of the buffer manager. >> > > One hitch, though, is that asynchronous commit could consume big chunks of > shared_buffers. So we might still need a limit for people who are using async. Well currently we use a fixed number of fixed-sized buffers, no? I doubt we'll change that even if we take this tact of making wal_buffers resizable by stealing buffers from the buffer manager for precisely the reasons Tom was describing. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!