Yet Another COUNT(*)...WHERE...question - Mailing list pgsql-general

From Phoenix Kiula
Subject Yet Another COUNT(*)...WHERE...question
Date
Msg-id e373d31e0708150736u3b49fb1eq1fe79f40aff826f8@mail.gmail.com
Whole thread Raw
Responses Re: Yet Another COUNT(*)...WHERE...question  (Gregory Stark <stark@enterprisedb.com>)
Re: Yet Another COUNT(*)...WHERE...question  ("Scott Marlowe" <scott.marlowe@gmail.com>)
Re: Yet Another COUNT(*)...WHERE...question  (Erik Jones <erik@myemma.com>)
List pgsql-general
I'm grappling with a lot of reporting code for our app that relies on
queries such as:

     SELECT COUNT(*) FROM TABLE WHERE ....(conditions)...

And I still do not find, from the discussions on this thread, any
truly viable solution for this. The one suggestion is to have a
separate counts table, which is fine for total aggregates related to,
say, an ID. E.g., a table with:

    trader_id, trade_count

But this is an overall count for the trader (in my example). What if I
need a count of all his trades in the last one week. Then I need a
timestamp condition in there as well. The number of such possibilities
for multiple WHERE conditions is infinite...how should we account for
all these avenues?

Would love to hear experiences of others and what compromises they
have made. From a reporting perspective, waiting for 10 minutes for a
simple count to return seems untenable.

TIA!

pgsql-general by date:

Previous
From: "Scott Marlowe"
Date:
Subject: Re: Insert or Replace or \copy (bulkload)
Next
From: Gregory Stark
Date:
Subject: Re: Yet Another COUNT(*)...WHERE...question