From 610cdebb86deac85b251906f5d0a1b4ac3d2685d Mon Sep 17 00:00:00 2001 From: atovpeko Date: Thu, 31 Jul 2025 14:23:36 +0300 Subject: [PATCH 1/6] update to clarify --- api/hypercore/add_columnstore_policy.md | 6 ++++-- api/hypercore/alter_table.md | 2 +- api/hypertable/create_table.md | 5 ++++- 3 files changed, 9 insertions(+), 4 deletions(-) diff --git a/api/hypercore/add_columnstore_policy.md b/api/hypercore/add_columnstore_policy.md index db04613274..9cb6e20249 100644 --- a/api/hypercore/add_columnstore_policy.md +++ b/api/hypercore/add_columnstore_policy.md @@ -21,7 +21,7 @@ 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 @@ -29,7 +29,9 @@ indexes present. Please check out the PR description for more in-depth explanati 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 new chunks. The existing chunks in the $COLUMNSTORE remain unchanged. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE. diff --git a/api/hypercore/alter_table.md b/api/hypercore/alter_table.md index 5667192f2b..4348719738 100644 --- a/api/hypercore/alter_table.md +++ b/api/hypercore/alter_table.md @@ -15,7 +15,7 @@ import EarlyAccess from "versionContent/_partials/_early_access_2_18_0.mdx"; # ALTER TABLE ($HYPERCORE) -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 don't need to convert the entire $HYPERTABLE back to the $ROWSTORE before changing the settings. The new settings apply only to the new chunks, 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 diff --git a/api/hypertable/create_table.md b/api/hypertable/create_table.md index bf7f356c92..27d04a31d4 100644 --- a/api/hypertable/create_table.md +++ b/api/hypertable/create_table.md @@ -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 them by calling [ALTER TABLE][alter_table_hypercore] without converting the entire $HYPERTABLE back to the [$ROWSTORE][hypercore] first. The new settings apply only to the new chunks, 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 new 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. @@ -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/ \ No newline at end of file From c08997d7e20db5e64b9f90fd120eb1e4371d8efe Mon Sep 17 00:00:00 2001 From: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> Date: Mon, 4 Aug 2025 11:35:48 +0300 Subject: [PATCH 2/6] Update api/hypercore/add_columnstore_policy.md Co-authored-by: Ante Kresic Signed-off-by: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> --- api/hypercore/add_columnstore_policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api/hypercore/add_columnstore_policy.md b/api/hypercore/add_columnstore_policy.md index 9cb6e20249..23c8f3ce40 100644 --- a/api/hypercore/add_columnstore_policy.md +++ b/api/hypercore/add_columnstore_policy.md @@ -31,7 +31,7 @@ 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]. -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 new chunks. The existing chunks in the $COLUMNSTORE remain unchanged. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE. +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 which have not 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. From 3298eb9b8136d7f1f4038f97a5724b201e8cab35 Mon Sep 17 00:00:00 2001 From: atovpeko Date: Mon, 4 Aug 2025 11:40:18 +0300 Subject: [PATCH 3/6] clarify upon review --- api/hypercore/add_columnstore_policy.md | 2 +- api/hypercore/alter_table.md | 2 +- api/hypertable/create_table.md | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/api/hypercore/add_columnstore_policy.md b/api/hypercore/add_columnstore_policy.md index 9cb6e20249..fbc99de955 100644 --- a/api/hypercore/add_columnstore_policy.md +++ b/api/hypercore/add_columnstore_policy.md @@ -31,7 +31,7 @@ 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]. -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 new chunks. The existing chunks in the $COLUMNSTORE remain unchanged. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE. +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 been converted to $COLUMNSTORE yet. The existing chunks in the $COLUMNSTORE remain unchanged. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE. diff --git a/api/hypercore/alter_table.md b/api/hypercore/alter_table.md index 4348719738..58a3961752 100644 --- a/api/hypercore/alter_table.md +++ b/api/hypercore/alter_table.md @@ -15,7 +15,7 @@ import EarlyAccess from "versionContent/_partials/_early_access_2_18_0.mdx"; # ALTER TABLE ($HYPERCORE) -Enable the $COLUMNSTORE or change the $COLUMNSTORE settings for a hypertable. The settings are applied on a per-chunk basis. You don't need to convert the entire $HYPERTABLE back to the $ROWSTORE before changing the settings. The new settings apply only to the new chunks, the existing chunks in the $COLUMNSTORE do not change. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE. +Enable the $COLUMNSTORE or change the $COLUMNSTORE settings for a hypertable. The settings are applied on a per-chunk basis. You don't need to convert the entire $HYPERTABLE back to the $ROWSTORE before changing the settings. The new settings apply only to the chunks that haven't been converted to $COLUMNSTORE yet, 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 diff --git a/api/hypertable/create_table.md b/api/hypertable/create_table.md index 27d04a31d4..bd2d552fa9 100644 --- a/api/hypertable/create_table.md +++ b/api/hypertable/create_table.md @@ -32,7 +32,7 @@ workloads. You can also manually [convert chunks][convert_to_columnstore] in a $ $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 them by calling [ALTER TABLE][alter_table_hypercore] without converting the entire $HYPERTABLE back to the [$ROWSTORE][hypercore] first. The new settings apply only to the new chunks, 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 new chunks. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE. +The [$COLUMNSTORE][hypercore] settings are applied on a per-chunk basis. You can change them by calling [ALTER TABLE][alter_table_hypercore] without converting the entire $HYPERTABLE back to the [$ROWSTORE][hypercore] first. The new settings apply only to the chunks that have not been converted to $COLUMNSTORE yet, 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. From 8c59e4e36f94cdb4a81fdb8045da3fecb3e0fbd8 Mon Sep 17 00:00:00 2001 From: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> Date: Tue, 5 Aug 2025 11:07:08 +0300 Subject: [PATCH 4/6] Update api/hypercore/add_columnstore_policy.md Co-authored-by: Iain Cox Signed-off-by: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> --- api/hypercore/add_columnstore_policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api/hypercore/add_columnstore_policy.md b/api/hypercore/add_columnstore_policy.md index fbc99de955..08dea634b3 100644 --- a/api/hypercore/add_columnstore_policy.md +++ b/api/hypercore/add_columnstore_policy.md @@ -31,7 +31,7 @@ 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]. -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 been converted to $COLUMNSTORE yet. The existing chunks in the $COLUMNSTORE remain unchanged. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $HYPERTABLE. +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. From 9e6453765dafaecc99c8e5ef86e01ec727a35bdd Mon Sep 17 00:00:00 2001 From: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> Date: Tue, 5 Aug 2025 11:07:16 +0300 Subject: [PATCH 5/6] Update api/hypercore/alter_table.md Co-authored-by: Iain Cox Signed-off-by: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> --- api/hypercore/alter_table.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api/hypercore/alter_table.md b/api/hypercore/alter_table.md index 58a3961752..554c661273 100644 --- a/api/hypercore/alter_table.md +++ b/api/hypercore/alter_table.md @@ -15,7 +15,7 @@ import EarlyAccess from "versionContent/_partials/_early_access_2_18_0.mdx"; # ALTER TABLE ($HYPERCORE) -Enable the $COLUMNSTORE or change the $COLUMNSTORE settings for a hypertable. The settings are applied on a per-chunk basis. You don't need to convert the entire $HYPERTABLE back to the $ROWSTORE before changing the settings. The new settings apply only to the chunks that haven't been converted to $COLUMNSTORE yet, the existing chunks in the $COLUMNSTORE do not change. This means that chunks with different $COLUMNSTORE settings can co-exist in the same $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 From 01fb490b5731a661bcd8473cd2e4184fde75da17 Mon Sep 17 00:00:00 2001 From: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> Date: Tue, 5 Aug 2025 13:49:50 +0300 Subject: [PATCH 6/6] Update api/hypertable/create_table.md Co-authored-by: Iain Cox Signed-off-by: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> --- api/hypertable/create_table.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/api/hypertable/create_table.md b/api/hypertable/create_table.md index bd2d552fa9..1b620ce4d7 100644 --- a/api/hypertable/create_table.md +++ b/api/hypertable/create_table.md @@ -32,7 +32,7 @@ workloads. You can also manually [convert chunks][convert_to_columnstore] in a $ $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 them by calling [ALTER TABLE][alter_table_hypercore] without converting the entire $HYPERTABLE back to the [$ROWSTORE][hypercore] first. The new settings apply only to the chunks that have not been converted to $COLUMNSTORE yet, 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. +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.