Received: from localhost (unknown [200.46.204.183]) by developer.postgresql.org (Postfix) with ESMTP id DDFA22E0050 for ; Fri, 6 Jun 2008 17:25:32 -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 56584-02-4 for ; Fri, 6 Jun 2008 17:25:20 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by developer.postgresql.org (Postfix) with ESMTP id 910D52E0091 for ; Fri, 6 Jun 2008 17:24:48 -0300 (ADT) Received: from ridley.home ([71.179.5.175]) by vms173003.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K2200DFE60TXPWK@vms173003.mailsrvcs.net> for pgsql-hackers@postgresql.org; Fri, 06 Jun 2008 15:24:30 -0500 (CDT) Date: Fri, 06 Jun 2008 16:24:28 -0400 From: Robert Treat Subject: Re: Overhauling GUCS In-reply-to: <200806061435.01196.peter_e@gmx.net> To: pgsql-hackers@postgresql.org Cc: Peter Eisentraut , Tom Lane , Greg Smith , Andreas Pflug , Decibel! , Josh Berkus Message-id: <200806061624.29105.xzilla@users.sourceforge.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <48409D1E.3070208@agliodbs.com> <29525.1212613052@sss.pgh.pa.us> <200806061435.01196.peter_e@gmx.net> User-Agent: KMail/1.9.9 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200806/319 X-Sequence-Number: 119432 On Friday 06 June 2008 08:35:00 Peter Eisentraut wrote: > Am Mittwoch, 4. Juni 2008 schrieb Tom Lane: > > * Can we present the config options in a more helpful way (this is 99% > > a documentation problem, not a code problem)? > > ack > > > * Can we build a "configuration wizard" to tell newbies what settings > > they need to tweak? > > Some questions to clarify this: > > - What settings do "newbies" (or anyone else) typically need to change? > Please post a list. > i do have a defined set (sort of a "top ten you need to know") that i tell people about in my postgres 101 tutorials... off the top of my head it looks like this: shared_buffers effective_cache_size default_stats_target work_mem maintainance_work_mem listen_address max_connections the fsm parameters checkpoint_segements random_page_cost i think others close to the list are constraint_exclusion (unless it defaults to on now), max_prepared_transactions (set it to 0 unless you use it... i may stop recommending this after noticing its effects on max # system locks allowed), and then the logging parameters (which is to say, you need to set up logging that works, however you want to do it). There are a couple more that might go on the list, like synchronous_commit, but its on the fence for now. > - What values would you set those settings to? Please provide a > description for arriving at a value, which can later be transformed into > code. Note that in some cases, not even the documentation provides more > than handwaving help. > I can provide this if you want, will need to look over my notes. one issue we've faced in the past with this is something like shared_buffers, where the settings is based on 1) dedicated server?, 2) available ram, 3) amount of red/write traffic, 4) disk subsystem. Those types of input are hard to quantify in code. > - If we know better values, why don't we set them by default? > There is a saying, something like "The accumulation of annecdotes is not data". Well, we seem to have a high bar on what proof we need to actually change a default GUC settings. default_statistics_target is a prime example, where almost no one i know has ever recommended 10 as a default, or suggests setting it to 10 as an way to improve performance, but the effort to get it changed to something more reasonable has been monumental. > Another orthogonal stumbling block on the way to making all of this > automatic is that the surely criticial shared_buffers setting will in any > useful configuration require messing around with kernel settings that no > PostgreSQL tool can really help with. yep. seems it might be possible to just compare the shared_buffer setting with the kernel parameters before making the change though... not sure in which way you would slant the output though. -- Robert Treat Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL