Skip to content

Update to clarify per-chunk columnstore settings #4325

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 4 additions & 2 deletions api/hypercore/add_columnstore_policy.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,15 +21,17 @@ specific time interval.
You enable the $COLUMNSTORE a hypertable or continuous aggregate before you create a $COLUMNSTORE policy.
You do this by calling `CREATE TABLE` for hypertables and `ALTER MATERIALIZED VIEW` for continuous aggregates. When
$COLUMNSTORE is enabled, [bloom filters][bloom-filters] are enabled by default, and every new chunk has a bloom index.
If you moved chunks to $COLUMNSTORE using $TIMESCALE_DB v2.19.3 or below, to enable bloom filters on that data you have
If you converted chunks to $COLUMNSTORE using $TIMESCALE_DB v2.19.3 or below, to enable bloom filters on that data you have
to convert those chunks to the $ROWSTORE, then convert them back to the $COLUMNSTORE.

Bloom indexes are not retrofitted, meaning that the existing chunks need to be fully recompressed to have the bloom
indexes present. Please check out the PR description for more in-depth explanations of how bloom filters in
TimescaleDB work.

To view the policies that you set or the policies that already exist,
see [informational views][informational-views], to remove a policy, see [remove_columnstore_policy][remove_columnstore_policy].
see [informational views][informational-views], to remove a policy, see [remove_columnstore_policy][remove_columnstore_policy].

A $COLUMNSTORE policy is applied on a per-chunk basis. If you remove an existing policy and then add a new one, the new policy applies only to the chunks that have not yet been converted to $COLUMNSTORE. The existing chunks in the $COLUMNSTORE remain unchanged. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE.

<Since2180 />

Expand Down
2 changes: 1 addition & 1 deletion api/hypercore/alter_table.md
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,7 @@ import EarlyAccess from "versionContent/_partials/_early_access_2_18_0.mdx";

# ALTER TABLE ($HYPERCORE)<Tag type="community" content="community" />

Enable the $COLUMNSTORE for a hypertable.
Enable the $COLUMNSTORE or change the $COLUMNSTORE settings for a $HYPERTABLE. The settings are applied on a per-chunk basis. You do not need to convert the entire $HYPERTABLE back to the $ROWSTORE before changing the settings. The new settings apply only to the chunks that have not yet been converted to $COLUMNSTORE, the existing chunks in the $COLUMNSTORE do not change. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE.

After you have enabled the $COLUMNSTORE, either:
- [add_columnstore_policy][add_columnstore_policy]: create a [job][job] that automatically moves chunks in a hypertable to the $COLUMNSTORE at a
Expand Down
5 changes: 4 additions & 1 deletion api/hypertable/create_table.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,9 @@ In the $COLUMNSTORE conversion, $HYPERTABLE chunks are compressed by more than 9
large-scale queries. This columnar format enables fast scanning and aggregation, optimizing performance for analytical
workloads. You can also manually [convert chunks][convert_to_columnstore] in a $HYPERTABLE to the $COLUMNSTORE.

$HYPERTABLE to $HYPERTABLE foreign keys are not allowed, all other combinations are permitted.
$HYPERTABLE_CAP to $HYPERTABLE foreign keys are not allowed, all other combinations are permitted.

The [$COLUMNSTORE][hypercore] settings are applied on a per-chunk basis. You can change the settings by calling [ALTER TABLE][alter_table_hypercore] without first converting the entire $HYPERTABLE back to the [$ROWSTORE][hypercore]. The new settings apply only to the chunks that have not yet been converted to $COLUMNSTORE, the existing chunks in the $COLUMNSTORE do not change. Similarly, if you [remove an existing columnstore policy][remove_columnstore_policy] and then [add a new one][add_columnstore_policy], the new policy applies only to the unconverted chunks. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE.

`CREATE TABLE` extends the standard $PG [CREATE TABLE][pg-create-table]. This page explains the features and
arguments specific to $TIMESCALE_DB.
Expand Down Expand Up @@ -172,3 +174,4 @@ $TIMESCALE_DB returns a simple message indicating success or failure.
[convert_to_columnstore]: /api/:currentVersion:/hypercore/convert_to_columnstore/
[bloom-filters]: https://en.wikipedia.org/wiki/Bloom_filter
[add_columnstore_policy]: /api/:currentVersion:/hypercore/add_columnstore_policy/
[remove_columnstore_policy]: /api/:currentVersion:/hypercore/remove_columnstore_policy/