Chunk performance degrades until decompression/recompression in TimescaleDB

[arsalaniut]

Hello TimescaleDB team,

I am using TimescaleDB on PostgreSQL with hypertables. Normally, my queries across chunks work very well. However, I noticed that sometimes a specific chunk suddenly becomes very slow to query (taking much longer than other chunks, sometimes even locking).

If I manually decompress the chunk and then compress it again, the performance goes back to normal, and queries run as fast as on other chunks.

This behavior does not depend on the chunk age (it can happen to recent or older chunks). I usually have multiple chunks per day, and only one or two may suddenly start showing this problem.

My questions are:

Why would a chunk suddenly degrade in performance compared to others?
What is the recommended permanent solution so I don’t have to manually decompress/recompress chunks?
my postgres version --> 17.6
and timescaledb --> 2.20.2

[svenklemm]

DML operation on chunks can lead to chunks being partially compressed. The compression policy should turn them into fully compressed chunks again. To further investigate you could generate EXPLAIN output for the queries and compare slow vs fast version.

[habibax]

@arsalaniut @svenklemm Thank you so much. I have this problem, too. Is there a way to find those partially compressed chunks and fix them on schedule, or some kind of lock functionality so we can prevent this issue?

[svenklemm]

The compression policy will recompress partially compressed chunks.

[arsalaniut]

Thank you for the clarification regarding partially compressed chunks and the compression policy. I have a follow-up question:

I’ve configured a compression policy on my hypertable (e.g., compress after N days), and it generally works as expected. However, I noticed that when a chunk is being updated — for example, when new DML operations occur that cause the original chunk remains partially uncompressed afterward and does not get automatically recompressed by the policy.

It seems that once the chunk has been modified and the policy interval has already passed, it won’t be picked up again by the compression policy, even though it’s now partially decompressed.

My questions are:

Is this the expected behavior — i.e., chunks that are partially decompressed due to DML operations are skipped by the compression policy afterward?

What’s the recommended approach or best practice to ensure such chunks are automatically re-compressed without manual intervention?

Should I schedule a separate periodic job to re-compress chunks that are partially uncompressed?

Or is there a setting or function in TimescaleDB that can automatically detect and re-compress these chunks?