From: Mladen Gogala <mladen.gogala@vmsinfo.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: david@lang.hm <david@lang.hm>
Cc: Craig Ringer <craig@postnewspapers.com.au>
Cc: Vitalii Tymchyshyn <tivv00@gmail.com>
Cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [PERFORM] Slow count(*) again...
Date: Tue, 01 Feb 2011 18:21:04 -0500
Message-ID: <4D489560.2040107@vmsinfo.com> (raw)
In-Reply-To: <201102012247.p11Ml6u02682@momjian.us>
References: <201102012247.p11Ml6u02682@momjian.us>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: mladen.gogala@vmsinfo.com, bruce@momjian.us, tgl@sss.pgh.pa.us, david@lang.hm, craig@postnewspapers.com.au, tivv00@gmail.com, pgsql-hackers@postgreSQL.org
Subject: Re: [PERFORM] Slow count(*) again...
In-Reply-To: <4D489560.2040107@vmsinfo.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox