Received: from localhost (maia-3.hub.org [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id EEE779FB536 for ; Wed, 27 Jun 2007 15:01:58 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 01983-02 for ; Wed, 27 Jun 2007 15:01:50 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from davinci.ethosmedia.com (server227.ethosmedia.com [209.128.84.227]) by postgresql.org (Postfix) with ESMTP id 1C9A69FB4B5 for ; Wed, 27 Jun 2007 15:01:51 -0300 (ADT) X-EthosMedia-Virus-Scanned: no infections found Received: from [63.195.55.98] (account josh@agliodbs.com HELO [192.168.2.3]) by davinci.ethosmedia.com (CommuniGate Pro SMTP 4.1.8) with ESMTP id 12509887 for pgsql-performance@postgresql.org; Wed, 27 Jun 2007 11:05:57 -0700 From: Josh Berkus Organization: PostgreSQL @ Sun To: pgsql-performance@postgresql.org Subject: Re: PostgreSQL Configuration Tool for Dummies Date: Wed, 27 Jun 2007 11:02:35 -0700 User-Agent: KMail/1.8.2 References: <200706261226.06024.josh@agliodbs.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200706271102.35965.josh@agliodbs.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200706/606 X-Sequence-Number: 25639 Greg, > I'd like to see people have a really simple set of questions to get them > past the completely undersized initial configuration phase, then ship them > toward resources to help educate about the parts that could be problematic > for them based on what they do or don't know. I don't see an > inconsistancy that I'd expect people to have a reasonable guess for > max_connections, while also telling them that setting sort_mem is > important, a middle value has been assigned, but a really correct setting > isn't something they can expect the simple config tool to figure out for > them; here's a pointer to the appropriate documentation to learn more. I disagree that this is acceptable, especially when we could set a better value using an easy-to-understand question. It's also been my experience (in 3 years of professional performance tuning) that most users *don't* have an accurate guess for max_connections. I'm really not clear on why you think "what flavor of application do you have?" is a difficult question. It's certainly one that my clients were able to answer easily. Overall, it seems like you're shooting for a conf tool which only really works for web apps, which isn't my personal goal or I think a good use of our time. > I'm still of the opinion that recommendations for settings like > max_fsm_pages and maintenance_work_mem should come out of a different type > of tool that connects to the database. Well, there's several steps to this: 1) Run conf tool when installing PG; 2) Run conf tool++ after application is first up and running; 3) Run conf tool++ after application has been in production The (1) tool should at least provide a configuration which isn't going to lead to long term issues. For example, dramatically underallocating fsm_pages can result in having to run VACUUM FULL and the associated downtime, so it's something we want to avoid at the outset. -- Josh Berkus PostgreSQL @ Sun San Francisco