Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector - Mailing list pgsql-hackers

From Bryce Nesbitt
Subject Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector
Date
Msg-id 49764D10.4000009@obviously.com
Whole thread Raw
In response to Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector  (Bruce Momjian <bruce@momjian.us>)
List 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 by date:

Previous
From: Greg Smith
Date:
Subject: Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector
Next
From: James Mansion
Date:
Subject: Re: libpq WSACleanup is not needed