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
