Re: Overhauling GUCS
От | Gregory Stark |
---|---|
Тема | Re: Overhauling GUCS |
Дата | |
Msg-id | 87y72u178j.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: Overhauling GUCS (Greg Smith <gsmith@gregsmith.com>) |
Ответы |
Re: Overhauling GUCS
(Josh Berkus <josh@agliodbs.com>)
Re: Overhauling GUCS (Tom Lane <tgl@sss.pgh.pa.us>) Re: Overhauling GUCS (Greg Smith <gsmith@gregsmith.com>) |
Список | pgsql-hackers |
"Greg Smith" <gsmith@gregsmith.com> writes: > On Mon, 18 Aug 2008, Michael Nacos wrote: > >> Having done a SELECT * FROM pg_settings, all the information you need seems >> to be there... > > See http://archives.postgresql.org/pgsql-hackers/2008-06/msg00209.php You sound > like you're at rung 2 on the tool author ladder I describe there, still > thinking about the fun part of tuning but not yet aware of the annoying > postgresql.conf management issues that show up in the field that motivate many > of the GUCS changes suggested. Coping with user and system-generated comments > is one difficult part that people normally don't consider, Because coping with free-form user-edited text is a losing game. People don't consider it because it's a dead-end. Instead you have one file for user-edited configuration and a separate file for computer generated configuration. You never try to automatically edit a user-edited file -- that way lies madness. > dealing with bad settings the server won't start with is another. A tuning interface can't be turing complete and detect all possible misconfigurations. To do that it would have to be as complex as the server. In any case worrying about things like this before you have a tuning interface that can do the basics is putting the cart before the horse. >> As soon as there is a tuning strategy published, a number of tools will >> certainly follow. > > Josh Berkus published one in 2005 and zero such tools have been produced since > then, even though it looked to him then (like it does to you now and like it > did to me once) that such a tool would easily follow: > http://pgfoundry.org/docman/?group_id=1000106 The entire target market for such a thing is DBAs stuck on hosted databases which don't have shell access to their machines. Perhaps the overlap between that and the people who can write a server-side module which dumps out a config file according to some rules is just too small? I do think you and others make it less likely every time you throw up big insoluble problems like above though. As a consequence every proposal has started with big overly-complex solutions trying to solve all these incidental issues which never go anywhere instead of simple solutions which directly tackle the main problem. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning
В списке pgsql-hackers по дате отправления: