On 09/12/13 18:26, Greg Stark wrote:
> On Sat, Dec 7, 2013 at 3:28 AM, Álvaro Hernández Tortosa <aht@nosys.es> wrote:
>>>> "Right now, writing such a tool in a generic way gets so bogged down
>>>> just in parsing/manipulating the postgresql.conf file that it's hard to
>>>> focus on actually doing the tuning part."
>>>
>>> That was in 2008. I don't think that stance is accurate anymore.
>>
>> Just for me to learn about this: why is it not accurate anymore?
>
> This topic has been under active discussion for the last five years. I
> strongly recommend going back and skimming over the past discussions
> before trying to pick it up again. In particular go look up the
> discussion of SET PERSISTENT
Thanks, Greg. I've been going through those threads, they are quite
interesting. I didn't find an answer, though, about my question: why
parsing the postgresql.conf (and for instance preserving the comments
while writing it back) is no longer a problem. I read about ways of
mitigating this (such as the include facility and so on) but I still
find parsing the file as hard as before. Nonetheless, I think this adds
nothing to what we're talking about, so I'll skip this :)
>
> Since we have include files now you can just generate an
> auto-tune.conf and not try to parse or write the main config file.
>
> The reason previous efforts got bogged down in parsing/manipulating
> the postgresql.conf file was purely because they were trying to allow
> you to edit the file by hand and mix that with auto generated config.
>
Just IMO, it is great if a config file would allow for both use cases:
that both tools and users could seamlessly edit them at will. But of
course YMMV.
Regards,
aht
--
Álvaro Hernández Tortosa
-----------
NOSYS
Networked Open SYStems