On 09/12/13 18:26, Greg Stark wrote:
On Sat, Dec 7, 2013 at 3:28 AM, Álvaro Hernández Tortosa <a...@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.



Álvaro Hernández Tortosa

Networked Open SYStems

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to