Re: postgresql.conf
От | Peter Eisentraut |
---|---|
Тема | Re: postgresql.conf |
Дата | |
Msg-id | Pine.LNX.4.30.0111191711140.612-100000@peter.localdomain обсуждение исходный текст |
Ответ на | postgresql.conf (mlw <markw@mohawksoft.com>) |
Ответы |
Re: postgresql.conf
|
Список | pgsql-hackers |
mlw writes: > I have been thinking about postgresql.conf and I have made a few posts already > about it. My concern is that Postgres, as default, is not very well tuned. One > can even say the default is pretty much a bad configuration. The default configuration is mainly guided by three sometimes contradictory aspects: It should be reasonably secure, "unusual" or non-standard features are turned off, and resources are regulated so that it is easy to "try out" PostgreSQL without having to do major kernel tuning first or bringing other applications down to their knees. I think the default settings for most parameters are not really disputed, it's only the performance and resource-related settings that you want to work on. > How about this: we have just just two or three default configuration files? > Compact, Workstation, and server. Trying to elimate the one-size-does-not-fit-all problem with N-sizes-fit-all cannot be an optimal idea considering the dimensionality of the space of possible configurations. If all you're concerned about is buffers and sort memory it's much easier to say "configure buffers to use 1/4 of available memory" than to make arbitrary guesses about the available memory and attach arbitrary labels to them. Theoretically, it should be possible to determine optimal values for all performance-related settings from a combination of benchmarks, a few questions asked of the user about the system configuration and the expected work load, and a dynamic analysis of the nature of the data. But a system of formulas describing these relationsships is incredibly difficult to figure out and solve. If it weren't, we could get rid of all these settings and allocate resources dynamically at run time. What we ought to do, however, is to collect and document empirical methods for tuning, such as the above "1/4 of available memory" rule (which does not claim to be correct, btw.). -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: