@RobAtticus the current show_chunks logic uses the hypertable_id and table_id numbering values to do the sorting of the returned chunks. Typically, if we consider append only data insertions then that should be in sync with the time ranges.

We could return the chunks in dimension slice order though

Is show_chunks used as part of the compression policy job? Basically what I've found is that sometimes the compression job will skip around in the set of chunks to be compressed, which leads to inefficient rollups. So this issue was about that, although I also think show_chunks should enforce dimension slice order rather than rely on the IDs (given backfills, untiering a chunk, etc)

@RobAtticus yeah, show_chunks is used in the compression policy logic.

yeah, maybe dimension_slice based sorting is the way to go. We will need documentation changes also if we go this route.

We migrated some data to our Timescale instance, and maybe due to the way that we did the ingestion the chunk naming was not ordered. When we enabled the rollup functionality (which by the way is incredible useful in our use case) the compression job was not able to achieve the full compress chunk interval. We setted it to 7 days, but most chunks were between 1 to 2 days only.

We had to decompress the table, and create a script to compress one by one, ordered by range_start. It would be easier if somehow the compression job would be able to do it by itself.