Describe the bug
The documentation mentions for the invalidate_using parameter the option that it can be set to WAL-based invalidation, which uses lower resources. It is introduced since version 2.22.0 and makes it sound like the better option, compared to the default value of the parameter. There are no downsides mentioned, so as a user I assumed I should migrate our CAGGs to this setting to lower resource usage.
I later saw in the release notes on v2.25.0 (https://github.com/timescale/timescaledb/releases/tag/2.25.0) this sunsetting announcement: "This release removes the WAL-based invalidation of continuous aggregates. This feature was introduced in 2.22.0 as tech preview to use logical decoding for building the invalidation logs. The feature was designed for high ingest workloads, reducing the write amplification. With the upcoming stream of improvements to continuous aggregates, this feature was deprioritized and removed."
So based on the release notes, using the WAL invalidation is no longer what should be advertised as the better option, so I think it would be better to update the docs; either remove it completely or do not phrase it as the preferred option.
What do the docs say now?
Since TimescaleDB v2.22.0Set to wal to read changes from the WAL using logical decoding, then update the materialization invalidations for continuous aggregates using this information. This reduces the I/O and CPU needed to manage the hypertable invalidation log. Set to trigger to collect invalidations whenever there are inserts, updates, or deletes to a hypertable. This default behaviour uses more resources than wal.
What should the docs say?
Don't mention this parameter anymore as it is being removed (or has already been removed?)
Page affected
https://www.tigerdata.com/docs/api/latest/continuous-aggregates/create_materialized_view#parameters
Subject matter expert (SME)
/
Screenshots
Current docs:
Release notes:
Any further info
/
Contributing to documentation
We welcome documentation contributions! For guidelines, see the contributing guide.
Describe the bug
The documentation mentions for the
invalidate_usingparameter the option that it can be set to WAL-based invalidation, which uses lower resources. It is introduced since version 2.22.0 and makes it sound like the better option, compared to the default value of the parameter. There are no downsides mentioned, so as a user I assumed I should migrate our CAGGs to this setting to lower resource usage.I later saw in the release notes on v2.25.0 (https://github.com/timescale/timescaledb/releases/tag/2.25.0) this sunsetting announcement: "This release removes the WAL-based invalidation of continuous aggregates. This feature was introduced in 2.22.0 as tech preview to use logical decoding for building the invalidation logs. The feature was designed for high ingest workloads, reducing the write amplification. With the upcoming stream of improvements to continuous aggregates, this feature was deprioritized and removed."
So based on the release notes, using the WAL invalidation is no longer what should be advertised as the better option, so I think it would be better to update the docs; either remove it completely or do not phrase it as the preferred option.
What do the docs say now?
Since TimescaleDB v2.22.0Set to wal to read changes from the WAL using logical decoding, then update the materialization invalidations for continuous aggregates using this information. This reduces the I/O and CPU needed to manage the hypertable invalidation log. Set to trigger to collect invalidations whenever there are inserts, updates, or deletes to a hypertable. This default behaviour uses more resources than wal.
What should the docs say?
Don't mention this parameter anymore as it is being removed (or has already been removed?)
Page affected
https://www.tigerdata.com/docs/api/latest/continuous-aggregates/create_materialized_view#parameters
Subject matter expert (SME)
/
Screenshots
Current docs:
Release notes:
Any further info
/
Contributing to documentation
We welcome documentation contributions! For guidelines, see the contributing guide.