<br /><br /> Peter Eisentraut wrote:<br /><blockquote
cite="midPine.LNX.4.44.0301161950540.789-100000@localhost.localdomain"type="cite"><pre wrap="">Adrian
'Dagurashibanipal'von Bidder writes:
</pre><blockquote type="cite"><pre wrap=""> - postgres should auto-tune itself - the *cost could perhaps be
adjusted after some statistics have been collected, and there should be
some sensible way to determine an optimal setting for the famous
shared_buffers (and the default should be something that gets reasonable
performance on common cases) </pre></blockquote><pre wrap="">
Over the last couple of years PostgreSQL has transformed from hardly
configurable to fully configurable. Currently we're in a mode where we
add new configuration parameters whenever there's a degree of uncertainty.
Sooner rather than later we need to shift to the next phase, which is as
you say autoconfiguration, because ease of administration is one of the
great advantages of PostgreSQL</pre></blockquote><br /> I think the idea of adding a parameter when ever you are not
sure,is a great idea. That does preclude, however, the ability for a process within PostgreSQL from analyzing the
metricsand updating the parameter file or table.<br /><br /><br />
