> the QP can ask storage to do work like filtering, aggregation, projection, and other common tasks on its behalf. Unlike SQL designs that build on K/V stores, this allows to DSQL to do much of the heavy lifting of filtering and finding data right next to the data itself, on the storage replicas, without sacrificing scalability of storage or compute.
I don't know much about DB internals, but to me this sounds like lot of the compute is getting aggregated to the storage layer. I would think that "filtering, aggregation, projection" is fairly big chunk of the computation that typical DB does?
> the QP can ask storage to do work like filtering, aggregation, projection, and other common tasks on its behalf. Unlike SQL designs that build on K/V stores, this allows to DSQL to do much of the heavy lifting of filtering and finding data right next to the data itself, on the storage replicas, without sacrificing scalability of storage or compute.
I don't know much about DB internals, but to me this sounds like lot of the compute is getting aggregated to the storage layer. I would think that "filtering, aggregation, projection" is fairly big chunk of the computation that typical DB does?