From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: PostgreSQL Configuration Tool for Dummies |
Date: | 2007-06-27 18:02:35 |
Message-ID: | 200706271102.35965.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2007-06-27 23:19:45 | Re: Volunteer to build a configuration tool |
Previous Message | Dolafi, Tom | 2007-06-27 15:17:48 | rtree/gist index taking enormous amount of space in 8.2.3 |