Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id CCFE41337B83 for ; Tue, 1 Feb 2011 19:38:00 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 68295-01-6 for ; Tue, 1 Feb 2011 23:37:54 +0000 (UTC) X-Greylist: delayed 00:09:43.590642 by SQLgrey-1.7.6 Received: from lpo-relay-05.vmsinfo.com (lpo-relay-05.vmsinfo.com [216.169.137.116]) by mail.postgresql.org (Postfix) with ESMTP id B9E581337B7E for ; Tue, 1 Feb 2011 19:30:48 -0400 (AST) X-IronPort-AV: E=Sophos;i="4.60,412,1291611600"; d="scan'208";a="31583256" Received: from unknown (HELO lpo-mailbox-02.vmsinfo.com) ([216.169.137.252]) by lpo-relay-05.vmsinfo.com with ESMTP; 01 Feb 2011 18:21:05 -0500 Received: from [10.101.43.35] (lpo-autonomy-p03.vmsinfo.com [216.169.135.234]) by lpo-mailbox-02.vmsinfo.com (Postfix) with ESMTP id 111B456272; Tue, 1 Feb 2011 18:21:05 -0500 (EST) Message-ID: <4D489560.2040107@vmsinfo.com> Date: Tue, 01 Feb 2011 18:21:04 -0500 From: Mladen Gogala User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Momjian CC: Tom Lane , "david@lang.hm" , Craig Ringer , Vitalii Tymchyshyn , PostgreSQL-development Subject: Re: [PERFORM] Slow count(*) again... References: <201102012247.p11Ml6u02682@momjian.us> In-Reply-To: <201102012247.p11Ml6u02682@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=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201102/79 X-Sequence-Number: 180868 On 2/1/2011 5:47 PM, Bruce Momjian wrote: > Do we want a TODO about optimizing COUNT(*) to avoid aggregate > processing overhead? > Definitely not. In my opinion, and I've seen more than a few database designs, having count(*) is almost always an error. If I am counting a large table like the one below, waiting for 30 seconds more is not going to make much of a difference. To paraphrase Kenny Rogers, it will be time enough for counting when the application is done. Timing is on. news=> select count(*) from moreover_documents_y2011m01; count ---------- 20350907 (1 row) Time: 124142.437 ms news=> -- Mladen Gogala Sr. Oracle DBA 1500 Broadway New York, NY 10036 (212) 329-5251 http://www.vmsinfo.com The Leader in Integrated Media Intelligence Solutions