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
TimescaleDB's access patterns for uncompressed and compressed chunks differ due to the inherent differences between row-based and column-based storage. Currently, there is no way to optimize storage strategies independently for these two types of chunks. Allowing compressed and uncompressed chunks to be stored in separate tablespaces would enable users to tailor the underlying storage configurations (e.g., differing ZFS filesystem record sizes) to the specific access patterns of each chunk type. This optimization could significantly enhance overall performance.
What does the feature do?
This feature introduces the ability to specify a distinct tablespace for the compressed chunks of a hypertable. This configuration is independent of the tablespace used for the uncompressed chunks, providing finer-grained control over storage allocation and performance optimization.
Implementation challenges
The proposed implementation involves adding an optional if_compressed parameter to the existing attach_tablespace function. This parameter would flag the association between the hypertable and the tablespace for use exclusively with compressed chunks. Additional research is needed to assess feasibility and edge cases, such as compatibility with existing hypertables, but this proposal serves as a starting point for community feedback before proceeding with a pull request (PR).
The text was updated successfully, but these errors were encountered:
What problem does the new feature solve?
TimescaleDB's access patterns for uncompressed and compressed chunks differ due to the inherent differences between row-based and column-based storage. Currently, there is no way to optimize storage strategies independently for these two types of chunks. Allowing compressed and uncompressed chunks to be stored in separate tablespaces would enable users to tailor the underlying storage configurations (e.g., differing ZFS filesystem record sizes) to the specific access patterns of each chunk type. This optimization could significantly enhance overall performance.
What does the feature do?
This feature introduces the ability to specify a distinct tablespace for the compressed chunks of a hypertable. This configuration is independent of the tablespace used for the uncompressed chunks, providing finer-grained control over storage allocation and performance optimization.
Implementation challenges
The proposed implementation involves adding an optional
if_compressed
parameter to the existingattach_tablespace
function. This parameter would flag the association between the hypertable and the tablespace for use exclusively with compressed chunks. Additional research is needed to assess feasibility and edge cases, such as compatibility with existing hypertables, but this proposal serves as a starting point for community feedback before proceeding with a pull request (PR).The text was updated successfully, but these errors were encountered: