TimescaleDB automatically creates chunks based on time. Every hypertable has a setting that determines the earliest and latest timestamp stored in each chunk: chunk_time_interval. This is set to 7 days unless you configure it otherwise.
This default setting is helpful, as it allows you to get started quickly and it will give you generally good performance—but, if you want to fine-tune TimescaleDB to perform well for your application, you may want to adjust your chunk_time_interval to what works best for your use case. For example:
-
TimescaleDB uses chunks to write and read data quickly. If your chunks are too big (i.e., you store too much data per partition), the benefit of partitioning diminishes because you have more data in the partition than the PostgreSQL cache available to manage it, similar to having one large regular PostgreSQL table. But if you have too many chunks (i.e., you store only a little data per partition), you may overwhelm the query planner or create extra overhead in other management areas.
-
Many TimescaleDB features are affected by the chunk size, including some of our top features: compression, continuous aggregates, and data retention policies. For instance, data is compressed by chunks, not entire hypertables or individual rows. Retention policies delete chunks while continuous aggregates (which store their data in special hypertables as well) automatically set their chunk size based on the parent hypertable setting. Therefore, these features are affected by how you configure your chunk size within the context of your hypertable.
The chunk_time_interval that’s best for you will ultimately depend on your use case and on what matters most to you. If you’re looking for advice on how to determine your optimal chunk_size_interval,
Check out this blog post, where you’ll find a comprehensive walk-through.
You can also review our previous Forum post on the topic.
And if you have any other questions, please ask us! 