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 | 49766DD8.7080300@obviously.com обсуждение исходный текст |
Ответ на | Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
Josh Berkus wrote: > I'd argue that it is generally desired (or some convenient workaround) > but not urgently so. I'd also argue that if we're going to have a > --no-stats flag, it should exist for the other client ultilites as > well; if I don't want pg_dump showing up, I probably don't want Vacuum > showing up, or various other already-debugged maintenance routines. > > I'd suggest putting this into the first patch review for 8.5. > > --Josh As pg_dumpall calls pg_dump, I think this is covered or at least coverable. For vaccum, I've never seen that activity in stats? Can you supply a more specific scenario where routine maintenance is harmfully cluttering the stats table? A specific utility that needs attention? For this feature I'm not so sure about "generally desired" -- I'll bet most people don't even think about this. The question is among those who DO think about it, what's the best behavior? Can it be argued that excluding pg_dump is "generally desirable", for the average use case? If there is not enough demand for a dedicated flag, I may submit a man page patch documenting the Do-It-Yourself solution proposed by Greg Smith, or the one proposed by Tom Lane. G'day -Bryce PS: Note that no respondent on the psql user's lists thought excluding pg_dump was even possible -- so that at least argues for desirability of instructional material :-).
В списке pgsql-hackers по дате отправления: