Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] Slow count(*) again...

From: Mladen Gogala <mladen(dot)gogala(at)vmsinfo(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "david(at)lang(dot)hm" <david(at)lang(dot)hm>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Vitalii Tymchyshyn <tivv00(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: [PERFORM] Slow count(*) again...
Date: 2011-02-01 23:21:04
Message-ID: 4D489560.2040107@vmsinfo.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
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




In response to

pgsql-performance by date

Next:From: Mark KirkwoodDate: 2011-02-01 23:37:30
Subject: Re: Bloat issue on 8.3; autovac ignores HOT new pages?
Previous:From: Tom LaneDate: 2011-02-01 23:12:44
Subject: Re: [PERFORM] Slow count(*) again...

pgsql-hackers by date

Next:From: Mladen GogalaDate: 2011-02-01 23:44:17
Subject: Re: [HACKERS] Slow count(*) again...
Previous:From: Tom LaneDate: 2011-02-01 23:12:44
Subject: Re: [PERFORM] Slow count(*) again...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group