Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 8E3AC63251B for ; Tue, 20 Jan 2009 20:35:56 -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 21015-06 for ; Tue, 20 Jan 2009 20:35:52 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mail.postgresql.org (Postfix) with ESMTP id 21CF9632512 for ; Tue, 20 Jan 2009 20:35:51 -0400 (AST) Received: (qmail 19693 invoked from network); 21 Jan 2009 00:35:37 -0000 Received: from dsl081-048-173.sfo1.dsl.speakeasy.net (HELO xena.bepress.com) ([64.81.48.173]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 21 Jan 2009 00:35:37 -0000 Received: from [192.168.1.146] (unknown [192.168.1.146]) by xena.bepress.com (Postfix) with ESMTP id 3C5C97427B for ; Tue, 20 Jan 2009 16:35:37 -0800 (PST) Message-ID: <49766DD8.7080300@obviously.com> Date: Tue, 20 Jan 2009 16:35:36 -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 Subject: Re: New pg_dump patch, --no-stats flag, disables sending to statistics collector References: <200901202154.n0KLsmL11525@momjian.us> <497652E2.4030902@agliodbs.com> In-Reply-To: <497652E2.4030902@agliodbs.com> Content-Type: text/plain; charset=UTF-8; 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/1489 X-Sequence-Number: 132133 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 :-).