Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control - Mailing list pgsql-performance

From Sabin Coanda
Subject Re: PostgreSQL Configuration Tool for Dummies - feedback adjustable control
Date
Msg-id f5oa0f$1aoa$1@news.hub.org
Whole thread Raw
In response to PostgreSQL Configuration Tool for Dummies  ("Campbell, Lance" <lance@uiuc.edu>)
List pgsql-performance
<david@lang.hm> wrote in message
news:Pine.LNX.4.64.0706221144290.14942@asgard.lang.hm...
> On Fri, 22 Jun 2007, Sabin Coanda wrote:
>
>> Instead of (or in addition to) configure dozens of settings, what do you
>> say about a feedback adjustable control based on the existing system
>> statistics and parsing logs (e.g
>> http://pgfouine.projects.postgresql.org/index.html ) ?
>
> something like this would be useful for advanced tuneing, but the biggest
> problem is that it's so difficult to fingoure out a starting point. bad
> choices at the starting point can cause several orders of magnatude
> difference in the database performsnce. In addition we know that the
> current defaults are bad for just about everyone (we just can't decide
> what better defaults would be)
>

You are right. But an automatic tool beeing able to take decisions by
different inputs, would be able to set a startup configuration too, based on
the hw/sw environment, and interactive user requirements.

> this horrible starting point gives people a bad first impression that a
> simple tool like what's being discussed can go a long way towards solving.
>

Well, I think to an automatic tool, not an utopian application good for
everything. For instance the existing automatic daemon have some abilities,
bat not all of the VACUUM command. I'm realistic that good things may be
done in steps, not once.

I would be super happy if an available automatic configuration tool would be
able to set for the beginning just the shared_buffers or  max_fsm_pages
based on the available memory. Adjustments can be done later.

Regards,
Sabin



pgsql-performance by date:

Previous
From: Michael Stone
Date:
Subject: Re: Performance query about large tables, lots of concurrent access
Next
From: Jean-David Beyer
Date:
Subject: Re: Performance query about large tables, lots of concurrent access