> Something like what you describe might be more efficient on certain queries but only because it’s giving up a lot of flexibility - consider what happens if yo

> Something like what you describe might be more efficient on certain queries but only because it’s giving up a lot of flexibility - consider what happens if you add any filtering or grouping changes and those partial sums can no longer be used. If you're doing a query that is not backed by an index, it's not scalable, so you could also do it in Excel. > This preference for general systems rather than optimizing for a single query shows through in the tools used for this kind of task: materialized views and indexes using expressions. Materialized views totally suck (at least in postgresql), because you cannot update them incrementally (yet). A better option most of the time are triggers and aggregate columns, but it requires a lot of micromanagement. > It sounds like you don’t want a general purpose database I don't think I want a special feature, map-reduce indexes seem pretty general "mathematically" sound thing. > Another way of looking at this is to ask why a field with billions in R&D hasn’t already done it, and especially why various big data tools have been significantly less impactful than promised. Well that's what's exiting about research, that some things haven't been done yet. Even though they may seem fairly obvious.