Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector
От | Bryce Nesbitt |
---|---|
Тема | Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector |
Дата | |
Msg-id | 49764D10.4000009@obviously.com обсуждение исходный текст |
Ответ на | Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector (Bruce Momjian <bruce@momjian.us>) |
Список | pgsql-hackers |
Bruce Momjian wrote: > Jaime Casanova wrote: > >> i haven't looked at the patch nor it's functional use... but from the >> top of my head jumps a question: is there a reason to not make this >> the default behaviour? >> > If this is a generally desired feature (and I question that), I think we > need a more general solution. > I'm not a big fan of flags, preferring good defaults. But I was not bold enough to suggest this as a new default, as someone would probably want the opposite flag. If you're measuring total server load (rather than analyzing an application), you may want to see pg_dump activity. As for a "general" solution: one could add the ability to inject arbitrary sql just prior to a dump run. That would let someone roll their own by injecting "SET stats_block_level = false", or make any other arbitrary settings changes. Or one might slice the statistics collector by role or user (so your 'backup' role would keep a separate tally). On the other hand, the flag's advantage is simplicity and directness.
В списке pgsql-hackers по дате отправления: