From: | Steve Horn <steve(at)stevehorn(dot)cc> |
---|---|
To: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
Cc: | pgsql-novice(at)postgresql(dot)org |
Subject: | Re: count() in 9.2 |
Date: | 2012-10-17 18:41:58 |
Message-ID: | CAFLkBaWxAactu7vw8Crs4h=nXFy22-wZ6UL4tA8bCfpxt6pA9A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-novice |
If our application could not do a count quickly there is no reason to show
up for work. Our application provides counts of lists to customers who then
use that information to purchase records of data from our lists. There are
on average 80 columns that the user can apply "WHERE, AND, or OR" to narrow
their count (list).
We are using Microsoft Sql Server currently. It provides counts in an
acceptable amount of time with 160 million+ rowcount tables with dozens of
AND clauses applied.
On Wed, Oct 17, 2012 at 1:48 PM, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
> Steve Horn wrote on 17.10.2012 17:00:
>
> One of the reasons that my team could not take advantage of
>> PostgreSQL was due to the poor performance of count(*) aggregate
>> function.
>>
>
> I wonder what kind of application makes a slow count(*) on a table a show
> stopper.
>
> I have been developing DB centric applications for over 20 years now and
> that never has been any issue.
>
> And which DBMS are you currently using?
> I don't know any transactional DBMS that will do count all the rows in a
> table *really* fast...
>
>
>
> --
> Sent via pgsql-novice mailing list (pgsql-novice(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/**mailpref/pgsql-novice<http://www.postgresql.org/mailpref/pgsql-novice>
>
--
Steve Horn
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Kellerer | 2012-10-17 18:56:40 | Re: count() in 9.2 |
Previous Message | Simon Riggs | 2012-10-17 18:38:04 | Re: count() in 9.2 |