An additional thought to clarify the distinction I wanted to make.

Parallel Query and Compression allow you to handle the same data volume and data distribtion faster – but the correct structural approach allows you to get the results by handling a smaller volume of data and/or a better distribution of data.

Remember that my comment was that your performance should be related to the size of the data you’re interested in. In your example your problem arises when you’re interested in (almost) all of the data.

Your idea of range partitioning by amount would be a relevant suggestion if someone made this a requirement of their system.

One refinement might be summary tables on (amount, month, sum(amount by month)) range-list partitioned by month; another approach would obviously be to explain the workload associated with the requirement as stated and propose an alternative that used a small set of “amount ranges” rather than one row per amount per month.

But how would you “structurally” approach the following: “give me the summary amount, aggregated by month, of all transactions with amount bigger than X” where X can be supplied ad hoc.

– you need to access every single transaction to check the amount – hence a summary table would not help

– you could think of range partitioning by amount – but if X is small enough you still would need to access most of the data

A different view point, though, for many systems where the “interesting” data volumes are growing is – what about materialized views, or simple summary tables, or even summary rows ?

Many of the performance problems I see start on day one, because no-one says: “how will this design respond to this query in five years time”. Yet there are many ways in which simple structural feature can ensure that the work the database has to do in five years time is no more than the work it has to do after the first few weeks.

If your query really needs to access lots of data and that data gets more with the time, then compressing the data and reading it parallel might be your way to scale.

>>”The performance of a query should be related to the size of the data set you’re
interested in, not to the size of the database.”

Just a thought: and what about the distribution/demographics?

Cheers.

Carlos.