From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "Phoenix Kiula" <phoenix(dot)kiula(at)gmail(dot)com> |
Cc: | "Postgres General" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Yet Another COUNT(*)...WHERE...question |
Date: | 2007-08-15 14:55:01 |
Message-ID: | dcc563d10708150755u8015412s110a4259a5cebc3c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 8/15/07, Phoenix Kiula <phoenix(dot)kiula(at)gmail(dot)com> wrote:
> 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.
Generally, for these kinds of things it's often best to use
materialized views / rollup tables so that you aren't re-aggregating
the same data over and over.
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Huxton | 2007-08-15 14:56:18 | Re: Yet Another COUNT(*)...WHERE...question |
Previous Message | Phoenix Kiula | 2007-08-15 14:48:55 | Re: Yet Another COUNT(*)...WHERE...question |