Re: Yet Another COUNT(*)...WHERE...question
От | Scott Marlowe |
---|---|
Тема | Re: Yet Another COUNT(*)...WHERE...question |
Дата | |
Msg-id | dcc563d10708150755u8015412s110a4259a5cebc3c@mail.gmail.com обсуждение исходный текст |
Ответ на | Yet Another COUNT(*)...WHERE...question ("Phoenix Kiula" <phoenix.kiula@gmail.com>) |
Ответы |
Re: Yet Another COUNT(*)...WHERE...question
|
Список | pgsql-general |
On 8/15/07, Phoenix Kiula <phoenix.kiula@gmail.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.
В списке pgsql-general по дате отправления: