Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id E4F821337B83 for ; Tue, 1 Feb 2011 19:03:53 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 63737-09 for ; Tue, 1 Feb 2011 23:03:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by mail.postgresql.org (Postfix) with ESMTP id 8F86913364DE for ; Tue, 1 Feb 2011 19:03:45 -0400 (AST) X-Authority-Analysis: v=1.1 cv=pepdxKapwHuwCZNFD5uob2wvham6E+RljB0uXw08FdQ= c=1 sm=0 a=zW9YFhm3rZwA:10 a=8nJEP1OIZ-IA:10 a=qCTYjJJ2g1SgQhsHZAUATw==:17 a=YGEdDfWJHX4oFvlsVPQA:9 a=H1F6V5H4lwPUZX5XxuHpEVbHWycA:4 a=wPNLvfGTeEIA:10 a=qCTYjJJ2g1SgQhsHZAUATw==:117 X-Cloudmark-Score: 0 X-Originating-IP: 98.27.48.207 Received: from [98.27.48.207] ([98.27.48.207:33565] helo=[192.168.10.104]) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id C3/C6-19545-051984D4; Tue, 01 Feb 2011 23:03:45 +0000 Message-ID: <4D48914B.4050403@dunslane.net> Date: Tue, 01 Feb 2011 18:03:39 -0500 From: Andrew Dunstan User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc13 Lightning/1.0b3pre Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Momjian CC: Tom Lane , Mladen Gogala , "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.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201102/77 X-Sequence-Number: 180866 On 02/01/2011 05:47 PM, Bruce Momjian wrote: > Tom Lane wrote: >> At this point what we've got is 25% of the runtime in nodeAgg.c overhead, >> and it's difficult to see how to get any real improvement without tackling >> that. Rather than apply the patch shown above, I'm tempted to think about >> hard-wiring COUNT(*) as a special case in nodeAgg.c such that we don't go >> through advance_aggregates/advance_transition_function at all, but just >> increment a counter directly. However, that would very clearly be >> optimizing COUNT(*) and nothing else. Given the opinions expressed >> elsewhere in this thread that heavy reliance on COUNT(*) represents >> bad application design, I'm not sure that such a patch would meet with >> general approval. >> >> Actually the patch shown above is optimizing COUNT(*) and nothing else, >> too, since it's hard to conceive of any other zero-argument aggregate. >> >> Anyway, if anyone is hot to make COUNT(*) faster, that's where to look. >> I don't think any of the previous discussion in this thread is on-point >> at all, except for the parts where people suggested avoiding it. > Do we want a TODO about optimizing COUNT(*) to avoid aggregate > processing overhead? Whether or not it's bad application design, it's ubiquitous, and we should make it work as best we can, IMNSHO. This often generates complaints about Postgres, and if we really plan for world domination this needs to be part of it. cheers andrew