Re: postgresql.conf (Proposed settings)
От | Peter Eisentraut |
---|---|
Тема | Re: postgresql.conf (Proposed settings) |
Дата | |
Msg-id | Pine.LNX.4.30.0111221701230.766-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: postgresql.conf (Proposed settings) (Horst Herb <hherb@malleenet.net.au>) |
Список | pgsql-hackers |
Horst Herb writes: > I am the other kind of newbie, the one that reads documentation. > However, I fail to find much regarding tuning within the documentation > delivered with the original version 7.1.2 tarball. Yes, there is clearly a deficit in this area. But it's obviously not going to get better with more buffers by default. > The other thing I am thinking abouty is that tuning can't be any "magic". > If I can tune it, why shouldn't a configuration script be able to do the > same? Theoretically, you're right of course. In practice this could be quite complicated to set up. Let's say, the optimal configuration depends primarily on four groups of parameters: 1. hardware setup 2. load/desired load on the server ("dedicated" vs something else) 3. nature of the data 4. nature of the clients/query workload #1 is easy to figure out by asking a few questions or perhaps a few nonportable peeks into /proc. #2 is more difficult, it's not simply yes or no or loadavg = X, because it depends on the nature of the other applications. #3 is also not quite that easy. It'd require a hypersmart version of ANALYZE, but in reality you would want to configure your server before the data starts arriving. So it's not really feasible to run a an automatic "benchmark" or something. The same with #4, the queries really arrive only after the tuning is done. You'd hardly want to tune while the application is live and ask the users "how fast was it?". So what would be required is to parametrize these four factors (and others we come up with) accurately into questions the user can answer easily. This would be an enormous task, but I'm not saying it can't be done. -- Peter Eisentraut peter_e@gmx.net
В списке pgsql-hackers по дате отправления: