While it's true column stores perform better on single-column aggregates, they perform worse on multi-column operations, thresholding queries, and other types of complex analytics that one often sees on time-series workloads. We have published benchmarks on some common column stores that show these tradeoffs.
This is slightly outside the scope of what TimescaleDB handles, but conceptually is it possible to create both row and column indices, and have the query engine hit one or the other depending on the query?
SQL Server sort of does this with traditional indices and columnstore indices. Indices are derived data structures that represent a view of the original dataset, so in theory it shouldn't matter if the original data is stored in rows or columns.
Comments
While it's true column stores perform better on single-column aggregates, they perform worse on multi-column operations, thresholding queries, and other types of complex analytics that one often sees on time-series workloads. We have published benchmarks on some common column stores that show these tradeoffs.
This is slightly outside the scope of what TimescaleDB handles, but conceptually is it possible to create both row and column indices, and have the query engine hit one or the other depending on the query?
SQL Server sort of does this with traditional indices and columnstore indices. Indices are derived data structures that represent a view of the original dataset, so in theory it shouldn't matter if the original data is stored in rows or columns.
Would be interesting to see benchmarks vs performant options e.g Vertica and ClickHouse