Re: temporary statistics option at initdb time
От | Euler Taveira de Oliveira |
---|---|
Тема | Re: temporary statistics option at initdb time |
Дата | |
Msg-id | 48A1E39A.7090101@timbira.com обсуждение исходный текст |
Ответ на | Re: temporary statistics option at initdb time (Robert Treat <xzilla@users.sourceforge.net>) |
Список | pgsql-hackers |
Robert Treat escreveu: > On Saturday 09 August 2008 21:31:28 Euler Taveira de Oliveira wrote: >> Hi, >> >> After the Magnus patch [1], that make it possible store statistics files >> at another (RAM-based) disk, I was thinking that would be useful to add >> an option at initdb time to do the symlink as we already do with xlog. >> Maybe it could be documented in monitoring.sgml too. Comments? >> >> [1] http://archives.postgresql.org/pgsql-hackers/2008-08/msg00176.php > > I find Magnus's approach to be admin un-friendly, and your patch a > re-enforcement of that feeling. Forcing people to fall back on the OS tools > (which may not be terribly good on systems like win32) when we could provide > a consistent way for postgres to handle this itself seems backwards. I > believe this would be much simpler for DBA's if we simply give them a GUC for > stat file location, and allow them to set the location that way. Ideally this > could be done as PGC_SIGHUP, and a change to the location would move the > file "on-the-fly" as they say. (There might be practical limitation to making > that work, but it would certainly be simpler for admins, imho) > How many times will you change the pg_stat_tmp directory? IMHO it is something that we don't frequently change. I agree that GUC is a DBA-friendly-option but we have to deal with (i) stop stats collector (ii) remove the old contents? (iii) start it at another location. I'm not saying that is _so_ difficult to do but I could live with pg_stat_tmp symlink option. -- Euler Taveira de Oliveira http://www.timbira.com/
В списке pgsql-hackers по дате отправления: