From f28db7d3892dbee8e36d15fc9b15220f16ca0804 Mon Sep 17 00:00:00 2001 From: Rich Loveland Date: Fri, 13 Feb 2026 12:32:01 -0500 Subject: [PATCH] Update Row-level TTL docs re: inbound foreign keys Fixes DOC-7473 --- .../v23.2/known-limitations/row-level-ttl-limitations.md | 1 + .../v24.1/known-limitations/row-level-ttl-limitations.md | 1 + .../v24.3/known-limitations/row-level-ttl-limitations.md | 1 + .../v25.2/known-limitations/row-level-ttl-limitations.md | 1 + .../v25.4/known-limitations/row-level-ttl-limitations.md | 1 + .../v26.1/known-limitations/row-level-ttl-limitations.md | 1 + 6 files changed, 6 insertions(+) diff --git a/src/current/_includes/v23.2/known-limitations/row-level-ttl-limitations.md b/src/current/_includes/v23.2/known-limitations/row-level-ttl-limitations.md index 34898d8473a..ea61345f901 100644 --- a/src/current/_includes/v23.2/known-limitations/row-level-ttl-limitations.md +++ b/src/current/_includes/v23.2/known-limitations/row-level-ttl-limitations.md @@ -1,4 +1,5 @@ - Any queries you run against tables with Row-Level TTL enabled do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query). +- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372) - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes. - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index. - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions. diff --git a/src/current/_includes/v24.1/known-limitations/row-level-ttl-limitations.md b/src/current/_includes/v24.1/known-limitations/row-level-ttl-limitations.md index 54b1e3ee66e..c386ba576d7 100644 --- a/src/current/_includes/v24.1/known-limitations/row-level-ttl-limitations.md +++ b/src/current/_includes/v24.1/known-limitations/row-level-ttl-limitations.md @@ -1,4 +1,5 @@ - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query). +- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372) - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes. - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index. - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions. diff --git a/src/current/_includes/v24.3/known-limitations/row-level-ttl-limitations.md b/src/current/_includes/v24.3/known-limitations/row-level-ttl-limitations.md index 54b1e3ee66e..c386ba576d7 100644 --- a/src/current/_includes/v24.3/known-limitations/row-level-ttl-limitations.md +++ b/src/current/_includes/v24.3/known-limitations/row-level-ttl-limitations.md @@ -1,4 +1,5 @@ - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query). +- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372) - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes. - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index. - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions. diff --git a/src/current/_includes/v25.2/known-limitations/row-level-ttl-limitations.md b/src/current/_includes/v25.2/known-limitations/row-level-ttl-limitations.md index 54b1e3ee66e..c386ba576d7 100644 --- a/src/current/_includes/v25.2/known-limitations/row-level-ttl-limitations.md +++ b/src/current/_includes/v25.2/known-limitations/row-level-ttl-limitations.md @@ -1,4 +1,5 @@ - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query). +- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372) - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes. - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index. - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions. diff --git a/src/current/_includes/v25.4/known-limitations/row-level-ttl-limitations.md b/src/current/_includes/v25.4/known-limitations/row-level-ttl-limitations.md index 54b1e3ee66e..c386ba576d7 100644 --- a/src/current/_includes/v25.4/known-limitations/row-level-ttl-limitations.md +++ b/src/current/_includes/v25.4/known-limitations/row-level-ttl-limitations.md @@ -1,4 +1,5 @@ - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query). +- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372) - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes. - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index. - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions. diff --git a/src/current/_includes/v26.1/known-limitations/row-level-ttl-limitations.md b/src/current/_includes/v26.1/known-limitations/row-level-ttl-limitations.md index 54b1e3ee66e..c386ba576d7 100644 --- a/src/current/_includes/v26.1/known-limitations/row-level-ttl-limitations.md +++ b/src/current/_includes/v26.1/known-limitations/row-level-ttl-limitations.md @@ -1,4 +1,5 @@ - Any queries you run against tables with Row-Level TTL enabled (or against tables that have [foreign keys]({% link {{page.version.version}}/foreign-key.md %}) that reference TTL-enabled tables) do not filter out expired rows from the result set (this includes [`UPDATE`s]({% link {{ page.version.version }}/update.md %}) and [`DELETE`s]({% link {{ page.version.version }}/delete.md %})). This feature may be added in a future release. For now, follow the instructions in [Filter out expired rows from a selection query]({% link {{ page.version.version }}/row-level-ttl.md %}#filter-out-expired-rows-from-a-selection-query). +- Tables with Row-Level TTL can be referenced by [foreign keys]({% link {{page.version.version}}/foreign-key.md %}). TTL deletes are issued as regular [`DELETE`]({% link {{ page.version.version }}/delete.md %}) statements, so inbound foreign keys apply. If an inbound foreign key uses `ON DELETE RESTRICT` and referencing rows exist, the TTL job fails with a foreign key violation. [#101372](https://github.com/cockroachdb/cockroach/issues/101372) - Enabling Row-Level TTL on a table with multiple [secondary indexes]({% link {{ page.version.version }}/indexes.md %}) can have negative performance impacts on a cluster, including increased [latency]({% link {{ page.version.version }}/common-issues-to-monitor.md %}#service-latency) and [contention]({% link {{ page.version.version }}/performance-best-practices-overview.md %}#transaction-contention). This is particularly true for large tables with terabytes of data and billions of rows that are split up into multiple ranges across separate nodes. - Increased latency may occur because secondary indexes aren't necessarily stored on the same underlying [ranges]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-range) as a table's [primary indexes]({% link {{ page.version.version }}/indexes.md %}). Further, the secondary indexes' ranges may have [leaseholders]({% link {{ page.version.version }}/architecture/overview.md %}#architecture-leaseholder) located on different nodes than the primary index. - Increased contention may occur because [intents]({% link {{ page.version.version }}/architecture/transaction-layer.md %}#write-intents) must be written as part of performing the deletions.