Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 08E7B6324E0 for ; Tue, 20 Jan 2009 18:15:51 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 87082-03 for ; Tue, 20 Jan 2009 18:15:48 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.10]) by mail.postgresql.org (Postfix) with ESMTP id 1D068632457 for ; Tue, 20 Jan 2009 18:15:47 -0400 (AST) Received: (qmail 16119 invoked from network); 20 Jan 2009 22:15:45 -0000 Received: from digital-subscriber-line.bepress.com (HELO xena.bepress.com) ([216.27.183.41]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Jan 2009 22:15:45 -0000 Received: from [192.168.1.146] (unknown [192.168.1.146]) by xena.bepress.com (Postfix) with ESMTP id 83CEC73CC9; Tue, 20 Jan 2009 14:15:44 -0800 (PST) Message-ID: <49764D10.4000009@obviously.com> Date: Tue, 20 Jan 2009 14:15:44 -0800 From: Bryce Nesbitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 (Ubuntu-1.1.12+nobinonly-0ubuntu0.8.04.1) MIME-Version: 1.0 To: Pgsql Hackers CC: Bruce Momjian , Jaime Casanova Subject: Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector References: <200901202154.n0KLsmL11525@momjian.us> In-Reply-To: <200901202154.n0KLsmL11525@momjian.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200901/1482 X-Sequence-Number: 132126 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.