Release 2.13.0

timescale · Nov 22, 2023 · 0bcca2f · 0bcca2f
1 parent 7c9099f
commit 0bcca2f
Show file tree

Hide file tree

Showing 30 changed files with 570 additions and 479 deletions.
diff --git a/.unreleased/PR_6222 b/.unreleased/PR_6222
diff --git a/.unreleased/enhancement_6049 b/.unreleased/enhancement_6049
diff --git a/.unreleased/feature_5575 b/.unreleased/feature_5575
diff --git a/.unreleased/feature_5761 b/.unreleased/feature_5761
diff --git a/.unreleased/feature_5890 b/.unreleased/feature_5890
diff --git a/.unreleased/feature_6050 b/.unreleased/feature_6050
diff --git a/.unreleased/feature_6062 b/.unreleased/feature_6062
diff --git a/.unreleased/feature_6077 b/.unreleased/feature_6077
diff --git a/.unreleased/feature_6177 b/.unreleased/feature_6177
diff --git a/.unreleased/feature_6227 b/.unreleased/feature_6227
diff --git a/.unreleased/feature_6307 b/.unreleased/feature_6307
diff --git a/.unreleased/fix_6188 b/.unreleased/fix_6188
diff --git a/.unreleased/fix_6240 b/.unreleased/fix_6240
diff --git a/.unreleased/fix_6289 b/.unreleased/fix_6289
diff --git a/.unreleased/fix_6290 b/.unreleased/fix_6290
diff --git a/.unreleased/fix_6305 b/.unreleased/fix_6305
diff --git a/.unreleased/fix_partial_index b/.unreleased/fix_partial_index
diff --git a/.unreleased/pr_6178 b/.unreleased/pr_6178
diff --git a/.unreleased/pr_6185 b/.unreleased/pr_6185
diff --git a/.unreleased/pr_6254 b/.unreleased/pr_6254
diff --git a/.unreleased/pr_6264 b/.unreleased/pr_6264
diff --git a/.unreleased/pr_6275 b/.unreleased/pr_6275
diff --git a/.unreleased/pr_6297 b/.unreleased/pr_6297
diff --git a/.unreleased/pr_6332 b/.unreleased/pr_6332
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -4,6 +4,68 @@
 `psql` with the `-X` flag to prevent any `.psqlrc` commands from
 accidentally triggering the load of a previous DB version.**
 
+## 2.13.0 (2023-11-27)
+
+This release contains performance improvements, an improved hypertable DDL API
+and bug fixes since the 2.12.2 release. We recommend that you upgrade at the next
+available opportunity.
+
+In addition, it includes these noteworthy features:
+
+* Full PostgreSQL 16 support for all existing features
+* Vectorized aggregation execution for sum()
+* Track chunk creation time used in retention/compression policies
+
+**Deprecation notice: Multi-node support**
+
+TimescaleDB 2.13 is the last version that will include multi-node support. Multi-node
+support in 2.13 is available for PostgreSQL 13, 14 and 15.  Learn more about it
+[here](docs/MultiNodeDeprecation.md).
+
+If you want to migrate from multi-node TimescaleDB to single-node TimescaleDB read the
+[migration documentation](https://docs.timescale.com/migrate/latest/multi-node-to-timescale-service/).
+
+**Starting from TimescaleDB 2.13.0:**
+
+* No Amazon Machine Images (AMI) are published. If you previously used AMI, please 
+use another [installation method](https://docs.timescale.com/self-hosted/latest/install/).
+* Continuous Aggregates are materialized only (non-realtime) by default.
+
+**Features**
+* #5575 Add chunk-wise sorted paths for compressed chunks
+* #5761 Simplify hypertable DDL API
+* #5890 Reduce WAL activity by freezing compressed tuples immediately
+* #6050 Vectorized aggregation execution for sum() 
+* #6062 Add metadata for chunk creation time
+* #6077 Make Continous Aggregates materialized only (non-realtime) by default
+* #6177 Change show_chunks/drop_chunks using chunk creation time
+* #6178 Show batches/tuples decompressed during DML operations in EXPLAIN output
+* #6185 Keep track of catalog version
+* #6227 Use creation time in retention/compression policy
+* #6307 Add SQL function cagg_validate_query
+
+**Bugfixes**
+* #6188 Add GUC for setting background worker log level
+* #6222 Allow enabling compression on hypertable with unique expression index
+* #6240 Check if worker registration succeeded
+* #6254 Fix exception detail passing in compression_policy_execute
+* #6264 Fix missing bms_del_member result assignment
+* #6275 Fix negative bitmapset member not allowed in compression
+* #6280 Potential data loss when compressing a table with a partial index that matches compression order.
+* #6289 Add support for startup chunk exclusion with aggs 
+* #6290 Repair relacl on upgrade
+* #6297 Fix segfault when creating a cagg using a NULL width in time bucket function
+* #6305 Make timescaledb_functions.makeaclitem strict
+* #6332 Fix typmod and collation for segmentby columns
+
+**Thanks**
+* @fetchezar for reporting an issue with compression policy error messages
+* @jflambert for reporting the background worker log level issue
+* @torazem for reporting an issue with compression and large oids
+* @pdipesh02 for contributing to the implementation of the metadata for chunk creation time, 
+             the generalized hypertable API, and show_chunks/drop_chunks using chunk creation time
+* @lkshminarayanan for all his work on PG16 support
+
 ## 2.12.2 (2023-10-19)
 
 This release contains bug fixes since the 2.12.1 release.
@@ -24,6 +86,7 @@ We recommend that you upgrade at the next available opportunity.
 * #6117 Avoid decompressing batches using an empty slot
 * #6123 Fix concurrency errors in OSM API
 * #6142 do not throw an error when deprecation GUC cannot be read
+
 **Thanks**
 * @symbx for reporting a crash when selecting from empty hypertables
 

diff --git a/docs/MultiNodeDeprecation.md b/docs/MultiNodeDeprecation.md
@@ -0,0 +1,59 @@
+## Multi-node Deprecation
+
+Multi-node support has been deprecated.
+TimescaleDB 2.13 is the last version that will include multi-node support.
+Multi-node support in 2.13 is available for PostgreSQL 13, 14 and 15.
+
+If you want to migrate from multi-node TimescaleDB to single-node TimescaleDB
+read the [migration documentation](https://docs.timescale.com/migrate/latest/multi-node-to-timescale-service/).
+
+### Why we have deprecated multi-node support
+
+We began to work on multi-node support in 2018 and released the first version in 2020 to provide higher scalability
+for TimescaleDB deployments. Since then and as we’ve continued to evolve our community and cloud products,
+we’ve come to the realization that multi-node was not the most forward-looking approach,
+and we have instead turned our focus to more cloud-native designs that inherently leverage compute/storage separation for higher scalability.
+
+These are the challenges we encountered with our multi-node architecture:
+- <b>Lower development speed</b>
+
+  Multi-node was hard to maintain and evolve and added a very high tax on any new feature we developed,
+  significantly slowing down our development speed.
+  Additionally, only ~1% of TimescaleDB deployments use multi-node.
+
+- <b>Inconsistent developer experience</b>
+
+  Multi-node imposed a key initial decision on developers adopting TimescaleDB: start with single-node or start with multi-node.
+  Moving from one to the other required a migration.
+  On top of that there were a number of features supported on single-node that were not available on multi-node making
+  the experience inconsistent and the choice even more complicated.
+
+- <b>Expensive price / performance ratio</b>
+
+  We were very far from linear scalability, not least due to the natural “performance hit” when scaling from a single-node to distributed transactions.
+  For example, handling 2x the load a single node could handle required 8 servers.
+  At the same time we’ve been able to dramatically improve the performance of single-node to handle 2 million inserts
+  per second as well as improve query performance dramatically with a
+  number of [query optimizations](https://www.timescale.com/blog/8-performance-improvements-in-recent-timescaledb-releases-for-faster-query-analytics/)
+  and [vectorized query execution](https://www.timescale.com/blog/teaching-postgres-new-tricks-simd-vectorization-for-faster-analytical-queries/). 
+
+- <b>Not designed to leverage new cloud architectures</b>
+
+  As we’ve gained experience developing and scaling cloud solutions we’ve realized that we can solve
+  the same problems more easily through new more modern approaches that leverage cloud technologies,
+  which often separate compute and storage to scale them independently.
+  For example, we’re now leveraging object storage in our cloud offering to deliver virtually infinite
+  storage capacity at a very low cost with [Tiered Storage](https://www.timescale.com/blog/scaling-postgresql-for-cheap-introducing-tiered-storage-in-timescale/),
+  and our [columnar compression](https://www.timescale.com/blog/building-columnar-compression-in-a-row-oriented-database/) (built concurrently to multi-node)
+  offers effective per-disk capacity that’s 10-20x that of traditional Postgres.
+  Similarly, users can scale compute both vertically and horizontally by either dynamically resizing compute
+  allocated to cloud databases, or adding additional server replicas (each of which can use the same tiered storage).
+
+Given all those reasons, we’ve made the difficult decision to deprecate multi-node so we can accelerate feature development
+and performance improvements, and deliver a better developer experience for the 99% of our community that is not using multi-node.
+
+### Questions and feedback
+
+We understand the news will be disappointing to users of multi-node. We’d like to help and provide advice on the best path forward for you.
+
+If you have any questions or feedback, you can share them in the #multi-node channel in our [community Slack](https://slack.timescale.com/).
diff --git a/sql/CMakeLists.txt b/sql/CMakeLists.txt
@@ -40,7 +40,8 @@ set(MOD_FILES
     updates/2.11.1--2.11.2.sql
     updates/2.11.2--2.12.0.sql
     updates/2.12.0--2.12.1.sql
-    updates/2.12.1--2.12.2.sql)
+    updates/2.12.1--2.12.2.sql
+    updates/2.12.2--2.13.0.sql)
 
 # The downgrade file to generate a downgrade script for the current version, as
 # specified in version.config