Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL Configuration Tool for Dummies

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-26 15:26:28
Message-ID: 200706260826.28935.josh@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-performance
Greg,

> We've hashed through this area before, but for Lance's benefit I'll
> reiterate my dissenting position on this subject.  If you're building a
> "tool for dummies", my opinion is that you shouldn't ask any of this
> information.  I think there's an enormous benefit to providing something
> that takes basic sizing information and gives conservative guidelines
> based on that--as you say, "safe, middle-of-the-road values"--that are
> still way, way more useful than the default values.  The risk in trying to
> make a complicated tool that satisfies all the users Josh is aiming his
> more sophisticated effort at is that you'll lose the newbies.

The problem is that there are no "safe, middle-of-the-road" values for some 
things, particularly max_connections and work_mem.  Particularly, there are 
very different conf profiles between reporting applications and OLTP/Web.  
We're talking about order-of-magnitude differences here, not just a few 
points.  e.g.:

Web app, typical machine:
max_connections = 200
work_mem = 256kb
default_statistics_target=100
autovacuum=on

Reporting app, same machine:
max_connections = 20
work_mem = 32mb
default_statistics_target=500
autovacuum=off

Possibly we could make the language of the "application type" selection less 
technical, but I don't see it as dispensible even for a basic tool.

> I wouldn't even bother asking how many CPUs somebody has for what Lance is
> building.  The kind of optimizations you'd do based on that are just too
> complicated to expect a tool to get them right and still be accessible to
> a novice.

CPUs affects the various cpu_cost parameters, but I can but the idea that this 
should only be part of the "advanced" tool.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

In response to

Responses

pgsql-performance by date

Next:From: Steven FlattDate: 2007-06-26 17:25:44
Subject: Re: Database-wide VACUUM ANALYZE
Previous:From: Gregory StarkDate: 2007-06-26 08:01:59
Subject: Re: Volunteer to build a configuration tool

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group