> The real problem we need to solve is how to allow newbies to have the
> system auto-configured to something that more or less solves their
> problems. Putting the config settings in XML does not accomplish that,
> and neither does putting them inside the database.
The subtle issue here is that what makes sense for the database
configuration changes over time; there's not just one initial generation
and you're done. postgresql.conf files can end up moving from one machine
to another for example. I think something that doesn't recognize that
reality and move toward a "tune-up" capability as well as initial
generation wouldn't be as useful, and that's where putting the settings
inside the database helps so much.
Also, there's a certain elegance to having a optimization tool that works
again either a new installation or an existing one. I personally have
zero interest in a one-shot config generator. It just doesn't solve the
problems I see in the field. Performance starts out just fine even with
the default settings when people first start, and then goes to hell after
the system has been running for a while (and possibly moved to another
machine). By that point nobody wants to mess with their configuration
file unless it's one simple change at a time.
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment