>>Hilmar-
>>
>>One other thing. I mentioned this before but didn't get a reply. Have you experienced the same results when using an index to speed up a group by?
>
>I don't have much practical experience here. The optimization tips I gave refer mainly to retrieving a relatively SMALL subset of a LARGE table. The problem with GROUP BY summaries is that you may need to access a large number of records. This may require accessing thousands of records, even if the final result returns only a few (summary) records.
>
>One way to speed this up, if you use a network, is to have the data on a database server, and do the calculations on the server. That way, the server returns only a small result set. But the calculations still have to be done, one way or another! Reducing network traffic, I understand, is not your current problem, however.
>
>Another possible solution is to have summary records in a separate table. If your tables don't change frequently, or you don't necessarily need the most upd-to-date information, you might even have a completely separate structure for reporting purposes. This, I understand, is called having a "data warehouse". The data warehouse might be updated, for instance, once a day. Or, when data changes, your stored procedures may update the summary table(s) automatically.
>
>Examples of summary records may include having totals per day, or totals per client, in separate tables.
>
>
>HTH, Hilmar.

In some cases, I do a pre-digest which summarizes as you suggest. In other cases I do not. I was just curious if you had experienced the same results. Try creating an index and doing a group by with and without the index to see the performance. Also the number of records can make a difference.