You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today only the one time dimension is supported by the Continuous Aggregates.
While hyper-tables have support for secondary partitioning dimension.
It would be great if Continuous Aggregates could inherit on top of such tables support for the secondary dimmenssion.
Implementation challenges
No response
The text was updated successfully, but these errors were encountered:
Would it make sense to make a bunch of continuous aggregates, one for each partition key value? cagg_0, ..., cagg_f (for example, partition key = first letter of some uuid).
My use-case is that I want to add compression to the materialized hypertable. To avoid slow compression jobs causing timeouts, I would like a reasonable size per chunk. But simultaneously, I do not want too short chunk durations, since the querying a single entity throughout all chunks would require a massive UNION.
What type of enhancement is this?
API improvement
What subsystems and features will be improved?
Continuous aggregate
What does the enhancement do?
Today only the one time dimension is supported by the Continuous Aggregates.
While hyper-tables have support for secondary partitioning dimension.
It would be great if Continuous Aggregates could inherit on top of such tables support for the secondary dimmenssion.
Implementation challenges
No response
The text was updated successfully, but these errors were encountered: