Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id E8C8B2E003F for ; Thu, 5 Jun 2008 16:50:36 -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 71715-04 for ; Thu, 5 Jun 2008 16:50:24 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from smtp107.biz.mail.mud.yahoo.com (smtp107.biz.mail.mud.yahoo.com [68.142.200.255]) by developer.postgresql.org (Postfix) with SMTP id BD1462E0086 for ; Thu, 5 Jun 2008 16:50:26 -0300 (ADT) Received: (qmail 53102 invoked from network); 5 Jun 2008 19:50:25 -0000 Received: from unknown (HELO ?192.168.5.105?) (ramayer@forensiclogic.com@76.202.62.108 with plain) by smtp107.biz.mail.mud.yahoo.com with SMTP; 5 Jun 2008 19:50:25 -0000 X-YMail-OSG: 7_sTP2oVM1loByz0JDPCZgZfxM4kubpty3uGIvpVSGv7XhI38vTLovtRzGOZwFFZdsKi.MLHQS2ZX.kkEwAbGa0dPFHpilD2SyGZ.PUZiA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <48484380.1010504@cheapcomplexdevices.com> Date: Thu, 05 Jun 2008 12:50:24 -0700 From: Ron Mayer User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Tom Lane CC: Andrew Dunstan , Greg Smith , Andreas Pflug , "Decibel!" , Peter Eisentraut , pgsql-hackers@postgresql.org, Josh Berkus Subject: Re: Overhauling GUCS References: <48409D1E.3070208@agliodbs.com> <200806010032.53337.peter_e@gmx.net> <17932.1212415926@sss.pgh.pa.us> <20080604131810.GH65238@decibel.org> <4846A483.8000001@pse-consulting.de> <29525.1212613052@sss.pgh.pa.us> <48472E47.7030701@dunslane.net> <7473.1212625397@sss.pgh.pa.us> In-Reply-To: <7473.1212625397@sss.pgh.pa.us> 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: 200806/254 X-Sequence-Number: 119367 Tom Lane wrote: > How far could we get with the answers to just three questions: > > * How many concurrent queries do you expect to have? > * How much RAM space are you willing to let Postgres use? > * How much "overhead" disk space are you willing to let Postgres use? +1 to this approach - these are the kinds of questions that make sense to me when first setting up a new installation. They sound useful for both large servers and tiny (salesguy laptop for demos) installations. > If those aren't enough questions, what else must we ask? * Perhaps something to guess FSM settings? I think FSM is tunable I most often get wrong with more painful consequences (bloat) than other tunables. My approach is to have cron run database-wide vacuums even on systems with autovacuum just to see the log messages about FSM. * Something to tune vacuum delay? Perhaps: How much I/O bandwidth can be dedicated to Postgres background activities?