diff --git a/src/current/_data/redirects.yml b/src/current/_data/redirects.yml
index b98d2e398da..abbc661cc46 100644
--- a/src/current/_data/redirects.yml
+++ b/src/current/_data/redirects.yml
@@ -81,7 +81,7 @@
- destination: admin-ui-overview.md
sources: ['explore-the-admin-ui.md']
- versions: ['v1.1', 'v2.0', 'v2.1', 'v19.1', 'v19.2', 'v20.1']
+ versions: ['v1.1', 'v2.0', 'v2.1', 'v19.1', 'v20.1']
- destination: architecture/distribution-layer.md#range-merges
sources: ['range-merges.md']
@@ -89,11 +89,11 @@
- destination: architecture/overview.md
sources: ['architecture/index.md']
- versions: ['v1.1', 'v2.0', 'v2.1', 'v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v1.1', 'v2.0', 'v2.1', 'v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: authorization.md
sources: ['create-and-manage-users.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: authorization.md
sources: ['roles.md']
@@ -103,7 +103,7 @@
sources:
- backup-data.md
- restore-data.md
- versions: ['v2.1', 'v19.1', 'v19.2', 'v20.1']
+ versions: ['v2.1', 'v19.1', 'v20.1']
- destination: cdc-queries.md
sources: ['cdc-transformations.md']
@@ -119,59 +119,59 @@
- destination: cockroach-cert.md
sources: ['create-security-certificates.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-debug-ballast.md
sources: ['debug-ballast.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-debug-encryption-active-key.md
sources: ['debug-encryption-active-key.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-debug-merge-logs.md
sources: ['debug-merge-logs.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-debug-zip.md
sources: ['debug-zip.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-dump.md
sources: ['sql-dump.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-gen.md
sources: ['generate-cockroachdb-resources.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-init.md
sources: ['initialize-a-cluster.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-node.md
sources: ['view-node-details.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-quit.md
sources: ['stop-a-node.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-sql.md
sources: ['use-the-built-in-sql-client.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1', 'v21.2', 'v21.2', 'v22.2', 'v23.1', 'v23.2']
+ versions: ['v20.1', 'v20.2', 'v21.1', 'v21.2', 'v21.2', 'v22.2', 'v23.1', 'v23.2']
- destination: cockroach-sqlfmt.md
sources: ['use-the-query-formatter.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-start.md
sources: ['start-a-node.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroach-version.md
sources: ['view-version-details.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: cockroachdb-feature-availability.md
sources:
@@ -205,13 +205,13 @@
- destination: demo-low-latency-multi-region-deployment.md
sources: ['demo-geo-partitioning.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: demo-replication-and-rebalancing.md
sources:
- demo-automatic-rebalancing.md
- demo-data-replication.md
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: v23.2/disaster-recovery-planning.md
sources: ['v23.2/disaster-recovery.md']
@@ -275,7 +275,7 @@
- destination: manual-deployment.md
sources: ['cloud-deployment.md']
- versions: ['v1.1', 'v2.0', 'v2.1', 'v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v1.1', 'v2.0', 'v2.1', 'v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: plan-your-cluster-serverless.md
sources:
@@ -307,7 +307,7 @@
- destination: molt/migration-overview.md
sources: ['import-data.md']
- versions: ['v2.1', 'v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v2.1', 'v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: molt/migration-overview.md
sources:
@@ -330,11 +330,11 @@
- destination: orchestrate-cockroachdb-with-kubernetes-multi-cluster.md
sources: ['orchetrate-cockroachdb-with-kubernetes-multi-region.md']
- versions: ['v2.0', 'v2.1', 'v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v2.0', 'v2.1', 'v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: performance-benchmarking-with-tpc-c-1k-warehouses.md
sources: ['performance-benchmarking-with-tpc-c.md']
- versions: ['v19.2', 'v20.1']
+ versions: ['v20.1']
- destination: performance-benchmarking-with-tpcc-large.md
sources: ['performance-benchmarking-with-tpc-c-100k-warehouses.md']
@@ -355,7 +355,7 @@
- destination: postgresql-compatibility.md
sources: ['porting-postgres.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: regional-tables.md
sources:
@@ -369,15 +369,15 @@
- destination: scalar-expressions.md
sources: ['sql-expressions.md']
- versions: ['v2.0', 'v2.1', 'v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v2.0', 'v2.1', 'v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: select-clause.md
sources: ['select.md']
- versions: ['v2.0', 'v2.1', 'v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v2.0', 'v2.1', 'v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: selection-queries.md
sources: ['selection-clauses.md']
- versions: ['v2.0', 'v2.1', 'v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v2.0', 'v2.1', 'v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: serverless-faqs.md
sources: ['free-faqs.md']
@@ -395,7 +395,7 @@
- show-create-sequence.md
- show-create-table.md
- show-create-view.md
- versions: ['v2.1', 'v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v2.1', 'v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: show-experimental-ranges.md
sources: ['show-testing-ranges.md']
@@ -403,7 +403,7 @@
- destination: show-ranges.md
sources: ['show-experimental-ranges.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: show-statements.md
sources: ['show-queries.md']
@@ -429,7 +429,7 @@
- destination: start-a-local-cluster-in-docker-mac.md
sources: ['start-a-local-cluster-in-docker.md']
- versions: ['v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v20.1', 'v20.2', 'v21.1']
- destination: stream-data-out-of-cockroachdb-using-changefeeds.md
sources: ['change-data-capture.md']
@@ -453,7 +453,7 @@
- destination: topology-patterns.md
sources: ['cluster-topology-patterns.md']
- versions: ['v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: ui-cdc-dashboard.md
sources: ['admin-ui-cdc-dashboard.md']
@@ -766,7 +766,7 @@
- simplified-deployment.md
- sql.md
- strong-consistency.md
- versions: ['v19.1', 'v19.2', 'v20.1', 'v20.2', 'v21.1']
+ versions: ['v19.1', 'v20.1', 'v20.2', 'v21.1']
- destination: https://docs.peewee-orm.com/en/latest/peewee/playhouse.html
sources: [':version/build-a-python-app-with-cockroachdb-peewee.md']
diff --git a/src/current/_data/releases.yml b/src/current/_data/releases.yml
index 427a26fb0dd..b1b6a0eba79 100644
--- a/src/current/_data/releases.yml
+++ b/src/current/_data/releases.yml
@@ -1458,16 +1458,6 @@
previous_release: v19.1.0
-- release_name: v19.2.0-alpha.20190606
- major_version: v19.2
- release_date: '2019-06-06'
- release_type: Testing
- go_version: go1.12.12
- sha: 53fada85741a2a096c240b2e8a2347b523c4a463
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
-
- release_name: v19.1.2
major_version: v19.1
@@ -1481,17 +1471,6 @@
previous_release: v19.1.1
-- release_name: v19.2.0-alpha.20190701
- major_version: v19.2
- release_date: '2019-07-01'
- release_type: Testing
- go_version: go1.12.12
- sha: 2c865eeb3e3b244468ffc509a62778bd1f46740f
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
- previous_release: v19.2.0-alpha.20190606
-
- release_name: v2.1.8
major_version: v2.1
@@ -1517,17 +1496,6 @@
previous_release: v19.1.2
-- release_name: v19.2.0-alpha.20190805
- major_version: v19.2
- release_date: '2019-08-05'
- release_type: Testing
- go_version: go1.12.12
- sha: 5bd37e8eb58ca66b9293c234bc572411057fec3a
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
- previous_release: v19.2.0-alpha.20190701
-
- release_name: v19.1.4
major_version: v19.1
@@ -1565,90 +1533,12 @@
previous_release: v19.1.4
-- release_name: v19.2.0-beta.20190930
- major_version: v19.2
- release_date: '2019-09-30'
- release_type: Testing
- go_version: go1.12.12
- sha: 250f4c36de2b88eff443cf9be9cd5d2759312c88
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
- previous_release: v19.2.0-alpha.20190805
-
-- release_name: v19.2.0-beta.20191014
- major_version: v19.2
- release_date: '2019-10-14'
- release_type: Testing
- go_version: go1.12.12
- sha: 27ea46b456d6b3dabac2c0f6c5c120ed316fffce
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
- previous_release: v19.2.0-beta.20190930
-
-- release_name: v19.2.0-rc.1
- major_version: v19.2
- release_date: '2019-10-21'
- release_type: Testing
- go_version: go1.12.12
- sha: 239513342a2d23f683bbc1d386f87ff59cc78d10
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
- previous_release: v19.2.0-beta.20191014
-
-- release_name: v19.2.0-rc.2
- major_version: v19.2
- release_date: '2019-10-28'
- release_type: Testing
- go_version: go1.12.12
- sha: 918d925bcb7d3b42e3f201d2e0f534a9d0d26684
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
- previous_release: v19.2.0-rc.1
-
-- release_name: v19.2.0-rc.3
- major_version: v19.2
- release_date: '2019-11-04'
- release_type: Testing
- go_version: go1.12.12
- sha: 62801ce77d9055c00b0e30010f5998ea2cd86686
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
- previous_release: v19.2.0-rc.2
-
-- release_name: v19.2.0-rc.4
- major_version: v19.2
- release_date: '2019-11-07'
- release_type: Testing
- go_version: go1.12.12
- sha: 2535f0363b5d9b1e466ca3144fe5bcf7ff17e63c
- docker:
- docker_image: cockroachdb/cockroach-unstable
- source: true
- previous_release: v19.2.0-rc.3
-
-- release_name: v19.2.0
- major_version: v19.2
- release_date: '2019-11-12'
- release_type: Production
- go_version: go1.12.12
- sha: 338deb20a6e34750635d6be5385498d5871ff68c
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.0-rc.4
-
- release_name: v20.1.0-alpha.20191118
major_version: v20.1
@@ -1660,18 +1550,6 @@
docker:
docker_image: cockroachdb/cockroach-unstable
source: true
-- release_name: v19.2.1
- major_version: v19.2
- release_date: '2019-11-25'
- release_type: Production
- go_version: go1.12.12
- sha: 53eef0857d14cc3af720e136ddaff4eeab026fd0
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.0
-
- release_name: v2.1.10
major_version: v2.1
@@ -1697,18 +1575,6 @@
previous_release: v19.1.5
-- release_name: v19.2.2
- major_version: v19.2
- release_date: '2019-12-16'
- release_type: Production
- go_version: go1.12.12
- sha: 3cbd05602d4aeaebbccea18d66ad0fdf8db482a5
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.1
-
- release_name: v20.1.0-alpha20191216
major_version: v20.1
@@ -1756,18 +1622,6 @@
docker_image: cockroachdb/cockroach-unstable
source: true
previous_release: v20.1.0-alpha20191216
-- release_name: v19.2.3
- major_version: v19.2
- release_date: '2020-02-03'
- release_type: Production
- go_version: go1.12.12
- sha: 2353f82b598b216a594ed7e6fc2eca66fe9d75e7
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.2
-
- release_name: v19.1.8
major_version: v19.1
@@ -1781,18 +1635,6 @@
previous_release: v19.1.7
-- release_name: v19.2.4
- major_version: v19.2
- release_date: '2020-02-11'
- release_type: Production
- go_version: go1.12.12
- sha: eb883734bcdafd85d98eb0e49126749bc2cc1284
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.3
-
- release_name: v20.1.0-beta.1
major_version: v20.1
@@ -1816,18 +1658,6 @@
docker_image: cockroachdb/cockroach-unstable
source: true
previous_release: v20.1.0-beta.1
-- release_name: v19.2.5
- major_version: v19.2
- release_date: '2020-03-23'
- release_type: Production
- go_version: go1.12.12
- sha: 4f36d0c62435596ca103454e113ebe8e55f005de
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.4
-
- release_name: v20.1.0-beta.3
major_version: v20.1
@@ -1851,18 +1681,6 @@
docker_image: cockroachdb/cockroach-unstable
source: true
previous_release: v20.1.0-beta.3
-- release_name: v19.2.6
- major_version: v19.2
- release_date: '2020-04-13'
- release_type: Production
- go_version: go1.12.12
- sha: ee759892738f7f203ff95ec7627b90d7c47b4350
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.5
-
- release_name: v20.1.0-rc.1
major_version: v20.1
@@ -1909,18 +1727,6 @@
docker_image: cockroachdb/cockroach
source: true
previous_release: v20.1.0-rc.2
-- release_name: v19.2.7
- major_version: v19.2
- release_date: '2020-05-20'
- release_type: Production
- go_version: go1.12.12
- sha: 2e19ff0576ff21e243f00f2e2acdaeea57aee6f3
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.6
-
- release_name: v20.1.1
major_version: v20.1
@@ -1967,18 +1773,6 @@
previous_release: v19.1.9
-- release_name: v19.2.8
- major_version: v19.2
- release_date: '2020-06-29'
- release_type: Production
- go_version: go1.12.12
- sha: 04216787bfef5c0a577d93b16c9e91fd44637ecf
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.7
-
- release_name: v20.1.3
major_version: v20.1
@@ -1991,18 +1785,6 @@
docker_image: cockroachdb/cockroach
source: true
previous_release: v20.1.2
-- release_name: v19.2.9
- major_version: v19.2
- release_date: '2020-07-06'
- release_type: Production
- go_version: go1.12.12
- sha: 5930d185b895e7deae41833af8fcce49babd23a1
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.8
-
- release_name: v19.1.11
major_version: v19.1
@@ -2040,18 +1822,6 @@
docker_image: cockroachdb/cockroach
source: true
previous_release: v20.1.3
-- release_name: v19.2.10
- major_version: v19.2
- release_date: '2020-08-24'
- release_type: Production
- go_version: go1.12.12
- sha: 5a1eb98cf9e0139f58b138f2743a3e0f55408b2f
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.9
-
- release_name: v20.2.0-alpha.3
major_version: v20.2
@@ -2131,18 +1901,6 @@
docker_image: cockroachdb/cockroach-unstable
source: true
previous_release: v20.2.0-beta.3
-- release_name: v19.2.11
- major_version: v19.2
- release_date: '2020-10-12'
- release_type: Production
- go_version: go1.12.12
- sha: e450c34dbf33745d889f41e1b1ea65197c1506fc
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.10
-
- release_name: v20.1.7
major_version: v20.1
@@ -2286,18 +2044,6 @@
docker_image: cockroachdb/cockroach
source: true
previous_release: v20.1.9
-- release_name: v19.2.12
- major_version: v19.2
- release_date: '2021-01-19'
- release_type: Production
- go_version: go1.12.12
- sha: eaae94a719759b74ed9f7bb150ee7e4bdd7c6ff1
- windows: true
- docker:
- docker_image: cockroachdb/cockroach
- source: true
- previous_release: v19.2.11
-
- release_name: v20.2.4
major_version: v20.2
diff --git a/src/current/_data/versions.csv b/src/current/_data/versions.csv
index f66caa56fbd..4f03234569a 100644
--- a/src/current/_data/versions.csv
+++ b/src/current/_data/versions.csv
@@ -1,21 +1,21 @@
-major_version,release_date,maint_supp_exp_date,asst_supp_exp_date,last_ga_patch,initial_lts_patch,initial_lts_release_date,lts_maint_supp_exp_date,lts_asst_supp_exp_date,previous_version,crdb_branch_name,binary_removal_date
-v1.0,2017-05-10,2018-05-10,2018-11-10,N/A,N/A,N/A,N/A,N/A,N/A,release-1.0,2024-01-01
-v1.1,2017-10-12,2018-10-12,2019-04-12,N/A,N/A,N/A,N/A,N/A,v1.0,release-1.1,2024-01-01
-v2.0,2018-04-04,2019-04-04,2019-10-04,N/A,N/A,N/A,N/A,N/A,v1.1,release-2.0,2024-01-01
-v2.1,2018-10-30,2019-10-30,2020-04-30,N/A,N/A,N/A,N/A,N/A,v2.0,release-2.1,2024-01-01
-v19.1,2019-04-30,2020-04-30,2020-10-30,N/A,N/A,N/A,N/A,N/A,v2.1,release-19.1,2024-01-01
-v19.2,2019-11-12,2020-11-12,2021-05-12,N/A,N/A,N/A,N/A,N/A,v19.1,release-19.2,2024-01-01
-v20.1,2020-05-12,2021-05-12,2021-11-12,N/A,N/A,N/A,N/A,N/A,v19.2,release-20.1,2025-05-12
-v20.2,2020-11-10,2021-11-10,2022-05-10,N/A,N/A,N/A,N/A,N/A,v20.1,release-20.2,2025-05-12
-v21.1,2021-05-18,2022-05-18,2022-11-18,N/A,N/A,N/A,N/A,N/A,v20.2,release-21.1,2025-05-18
-v21.2,2021-11-16,2022-11-16,2023-05-16,N/A,N/A,N/A,N/A,N/A,v21.1,release-21.2,2025-11-16
-v22.1,2022-05-24,2023-05-24,2023-11-24,N/A,N/A,N/A,N/A,N/A,v21.2,release-22.1,2026-05-24
-v22.2,2022-12-05,2023-12-05,2024-06-05,N/A,N/A,N/A,N/A,N/A,v22.1,release-22.2,2026-12-05
-v23.1,2023-05-15,2024-05-15,2024-11-15,23.1.11,23.1.12,2023-11-13,2024-11-13,2025-11-13,v22.2,release-23.1,2027-05-15
-v23.2,2024-02-05,2025-02-05,2025-08-05,23.2.6,23.2.7,2024-07-08,2025-07-08,2026-07-08,v23.1,release-23.2,2028-02-05
-v24.1,2024-05-20,2025-05-20,2025-11-20,24.1.5,24.1.6,2024-10-21,2025-10-21,2026-10-21,v23.2,release-24.1,2028-05-20
-v24.2,2024-08-12,2025-02-12,N/A,N/A,N/A,N/A,N/A,N/A,v24.1,release-24.2,2028-08-12
-v24.3,2024-11-18,2025-11-18,2026-05-18,24.3.11,24.3.12,2025-05-05,2026-05-05,2027-05-05,v24.2,release-24.3,2028-11-18
-v25.1,2025-02-18,2025-08-18,N/A,N/A,N/A,N/A,N/A,N/A,v24.3,release-25.1,2029-02-18
-v25.2,2025-05-09,2026-05-12,2026-11-12,N/A,N/A,N/A,N/A,N/A,v25.1,release-25.2,2029-05-09
-v25.3,2025-08-04,2026-02-04,N/A,N/A,N/A,N/A,N/A,N/A,v25.2,release-25.3,2029-08-04
+major_version,release_date,maint_supp_exp_date,asst_supp_exp_date,last_ga_patch,initial_lts_patch,initial_lts_release_date,lts_maint_supp_exp_date,lts_asst_supp_exp_date,previous_version,crdb_branch_name,binary_removal_date
+v1.0,2017-05-10,2018-05-10,2018-11-10,N/A,N/A,N/A,N/A,N/A,N/A,release-1.0,2024-01-01
+v1.1,2017-10-12,2018-10-12,2019-04-12,N/A,N/A,N/A,N/A,N/A,v1.0,release-1.1,2024-01-01
+v2.0,2018-04-04,2019-04-04,2019-10-04,N/A,N/A,N/A,N/A,N/A,v1.1,release-2.0,2024-01-01
+v2.1,2018-10-30,2019-10-30,2020-04-30,N/A,N/A,N/A,N/A,N/A,v2.0,release-2.1,2024-01-01
+v19.1,2019-04-30,2020-04-30,2020-10-30,N/A,N/A,N/A,N/A,N/A,v2.1,release-19.1,2024-01-01
+v20.1,2020-05-12,2021-05-12,2021-11-12,N/A,N/A,N/A,N/A,N/A,v19.2,release-20.1,2025-05-12
+v20.2,2020-11-10,2021-11-10,2022-05-10,N/A,N/A,N/A,N/A,N/A,v20.1,release-20.2,2025-05-12
+v21.1,2021-05-18,2022-05-18,2022-11-18,N/A,N/A,N/A,N/A,N/A,v20.2,release-21.1,2025-05-18
+v21.2,2021-11-16,2022-11-16,2023-05-16,N/A,N/A,N/A,N/A,N/A,v21.1,release-21.2,2025-11-16
+v22.1,2022-05-24,2023-05-24,2023-11-24,N/A,N/A,N/A,N/A,N/A,v21.2,release-22.1,2026-05-24
+v22.2,2022-12-05,2023-12-05,2024-06-05,N/A,N/A,N/A,N/A,N/A,v22.1,release-22.2,2026-12-05
+v23.1,2023-05-15,2024-05-15,2024-11-15,23.1.11,23.1.12,2023-11-13,2024-11-13,2025-11-13,v22.2,release-23.1,2027-05-15
+v23.2,2024-02-05,2025-02-05,2025-08-05,23.2.6,23.2.7,2024-07-08,2025-07-08,2026-07-08,v23.1,release-23.2,2028-02-05
+v24.1,2024-05-20,2025-05-20,2025-11-20,24.1.5,24.1.6,2024-10-21,2025-10-21,2026-10-21,v23.2,release-24.1,2028-05-20
+v24.2,2024-08-12,2025-02-12,N/A,N/A,N/A,N/A,N/A,N/A,v24.1,release-24.2,2028-08-12
+v24.3,2024-11-18,2025-11-18,2026-05-18,24.3.11,24.3.12,2025-05-05,2026-05-05,2027-05-05,v24.2,release-24.3,2028-11-18
+v25.1,2025-02-18,2025-08-18,N/A,N/A,N/A,N/A,N/A,N/A,v24.3,release-25.1,2029-02-18
+v25.2,2025-05-09,2026-05-12,2026-11-12,N/A,N/A,N/A,N/A,N/A,v25.1,release-25.2,2029-05-09
+v25.3,2025-08-04,2026-02-04,N/A,N/A,N/A,N/A,N/A,N/A,v25.2,release-25.3,2029-08-04
+
diff --git a/src/current/_includes/releases/whats-new-intro.md b/src/current/_includes/releases/whats-new-intro.md
index 706bde7ba5a..74355c546ea 100644
--- a/src/current/_includes/releases/whats-new-intro.md
+++ b/src/current/_includes/releases/whats-new-intro.md
@@ -102,7 +102,7 @@ On this page, you can read about changes and find downloads for all production a
{% comment %}Only show these bullet points if the version has been released{% endcomment %}
{% if released == true %}
{% comment %}v1.0 has no #v1-0-0 anchor, and before GA other releases also do not.{% endcomment %}
-- For key feature enhancements in {{ page.major_version }} and other upgrade considerations, refer to the notes for {% if include.major_version.release_date != 'N/A' and page.major_version != 'v1.0' %}[{{ page.major_version }}.0](#{{ page.major_version | replace: '.', '-' }}-0){% else %}{{ page.major_version }} on this page{% endif %}.
+- For key feature enhancements in {{ page.major_version }} and other upgrade considerations, refer to the notes for {% if include.major_version.release_date != 'N/A' and page.major_version != 'v1.0' and page.major_version != 'v19.2' %}[{{ page.major_version }}.0](#{{ page.major_version | replace: '.', '-' }}-0){% else %}{{ page.major_version }} on this page{% endif %}.
{% endif %}
{% endif %}{% comment %}End GA-only content{% endcomment %}
- For details about release types, naming, and licensing, refer to the [Releases]({% link releases/index.md %}) page.
diff --git a/src/current/releases/cloud.md b/src/current/releases/cloud.md
index d51b9b85dde..548bf19ea57 100644
--- a/src/current/releases/cloud.md
+++ b/src/current/releases/cloud.md
@@ -1257,7 +1257,7 @@ CockroachDB {{ site.data.products.cloud }} now requires a user to have a Cockroa
General changes
- CockroachDB {{ site.data.products.cloud }} pricing is now available on the [pricing page](https://www.cockroachlabs.com/pricing/).
-- CockroachDB {{ site.data.products.cloud }} clusters running CockroachDB v19.2 have been upgraded to [v19.2.4]({% link releases/v19.2.md %}#v19-2-4). All new clusters will now be created with CockroachDB v19.2.4.
+- CockroachDB {{ site.data.products.cloud }} clusters running CockroachDB v19.2 have been upgraded to v19.2.4. All new clusters will now be created with CockroachDB v19.2.4.
- CockroachDB {{ site.data.products.cloud }} now offers two options for per-node hardware configuration instead of three options. The hardware configuration [pricing]({% link cockroachcloud/create-your-cluster.md %}#step-2-select-the-cloud-provider) has been updated accordingly.
- Added a **Sign up** link to the [CockroachDB {{ site.data.products.cloud }} **Log In** page](https://cockroachlabs.cloud/).
- While [creating a new cluster]({% link cockroachcloud/create-your-cluster.md %}), you can now type in the number of nodes you want in the cluster instead of having to click the `+` sign repeatedly.
diff --git a/src/current/v19.1/cockroachdb-in-comparison.md b/src/current/v19.1/cockroachdb-in-comparison.md
index abe3d29214d..d519261094a 100644
--- a/src/current/v19.1/cockroachdb-in-comparison.md
+++ b/src/current/v19.1/cockroachdb-in-comparison.md
@@ -40,7 +40,7 @@ This page shows you how the key features of CockroachDB stack up against other d
Database horizontal scale
- 
+ 
|
@@ -62,7 +62,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Database load balancing (internal)
-
+
|
@@ -82,7 +82,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Failover
-
+
|
@@ -104,7 +104,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Automated repair and RPO(Recovery Point Objective)
-
+
|
@@ -126,7 +126,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Distributed reads
-
+
|
@@ -144,7 +144,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Distributed transactions
-
+
|
@@ -164,7 +164,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Database isolation levels
-
+
|
@@ -186,7 +186,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Potential data issues (default)
-
+
|
@@ -210,7 +210,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
SQL
-
+
|
@@ -230,7 +230,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Database schema change
-
+
|
@@ -250,7 +250,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Cost based optimization
-
+
|
@@ -272,7 +272,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Data Geo-partitioning
-
+
|
@@ -294,7 +294,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Upgrade method
-
+
|
@@ -312,7 +312,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Multi-region
-
+
|
@@ -332,7 +332,7 @@ This page shows you how the key features of CockroachDB stack up against other d
|
Multi-cloud
-
+
|
diff --git a/src/current/v19.2/404.md b/src/current/v19.2/404.md
deleted file mode 100644
index 13a69ddde5c..00000000000
--- a/src/current/v19.2/404.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Page Not Found
-description: "Page not found."
-sitemap: false
-search: exclude
-related_pages: none
-toc: false
----
-
-
-{%comment%}
-
-
-{%endcomment%}
\ No newline at end of file
diff --git a/src/current/v19.2/add-column.md b/src/current/v19.2/add-column.md
deleted file mode 100644
index 5584ce60376..00000000000
--- a/src/current/v19.2/add-column.md
+++ /dev/null
@@ -1,152 +0,0 @@
----
-title: ADD COLUMN
-summary: Use the ADD COLUMN statement to add columns to tables.
-toc: true
----
-
-The `ADD COLUMN` [statement](sql-statements.html) is part of `ALTER TABLE` and adds columns to tables.
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-
-{% include {{ page.version.version }}/sql/diagrams/add_column.html %}
-
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the table.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table to which you want to add the column.
- `column_name` | The name of the column you want to add. The column name must follow these [identifier rules](keywords-and-identifiers.html#identifiers) and must be unique within the table but can have the same name as indexes or constraints.
- `typename` | The [data type](data-types.html) of the new column.
- `col_qualification` | An optional list of column definitions, which may include [column-level constraints](constraints.html), [collation](collate.html), or [column family assignments](column-families.html).
If the column family is not specified, the column will be added to the first column family. For more information about how column families are assigned, see [Column Families](column-families.html#assign-column-families-when-adding-columns).
Note that it is not possible to add a column with the [foreign key](foreign-key.html) constraint. As a workaround, you can add the column without the constraint, then use [`CREATE INDEX`](create-index.html) to index the column, and then use [`ADD CONSTRAINT`](add-constraint.html) to add the foreign key constraint to the column.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-### Add a single column
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE accounts ADD COLUMN names STRING;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM accounts;
-~~~
-
-~~~
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-| column_name | data_type | is_nullable | column_default | generation_expression | indices |
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-| id | INT | false | NULL | | {"primary"} |
-| balance | DECIMAL | true | NULL | | {} |
-| names | STRING | true | NULL | | {} |
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-(3 rows)
-~~~
-
-### Add multiple columns
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE accounts ADD COLUMN location STRING, ADD COLUMN amount DECIMAL;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM accounts;
-~~~
-
-~~~
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-| column_name | data_type | is_nullable | column_default | generation_expression | indices |
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-| id | INT | false | NULL | | {"primary"} |
-| balance | DECIMAL | true | NULL | | {} |
-| names | STRING | true | NULL | | {} |
-| location | STRING | true | NULL | | {} |
-| amount | DECIMAL | true | NULL | | {} |
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-(5 rows)
-~~~
-
-### Add a column with a `NOT NULL` constraint and a `DEFAULT` value
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE accounts ADD COLUMN interest DECIMAL NOT NULL DEFAULT (DECIMAL '1.3');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM accounts;
-~~~
-~~~
-+-------------+-----------+-------------+------------------------+-----------------------+-------------+
-| column_name | data_type | is_nullable | column_default | generation_expression | indices |
-+-------------+-----------+-------------+------------------------+-----------------------+-------------+
-| id | INT | false | NULL | | {"primary"} |
-| balance | DECIMAL | true | NULL | | {} |
-| names | STRING | true | NULL | | {} |
-| location | STRING | true | NULL | | {} |
-| amount | DECIMAL | true | NULL | | {} |
-| interest | DECIMAL | false | 1.3:::DECIMAL::DECIMAL | | {} |
-+-------------+-----------+-------------+------------------------+-----------------------+-------------+
-(6 rows)
-~~~
-
-### Add a column with `NOT NULL` and `UNIQUE` constraints
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE accounts ADD COLUMN cust_number DECIMAL UNIQUE NOT NULL;
-~~~
-
-### Add a column with collation
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE accounts ADD COLUMN more_names STRING COLLATE en;
-~~~
-
-### Add a column and assign it to a column family
-
-#### Add a column and assign it to a new column family
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE accounts ADD COLUMN location1 STRING CREATE FAMILY new_family;
-~~~
-
-#### Add a column and assign it to an existing column family
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE accounts ADD COLUMN location2 STRING FAMILY existing_family;
-~~~
-
-#### Add a column and create a new column family if column family does not exist
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE accounts ADD COLUMN new_name STRING CREATE IF NOT EXISTS FAMILY f1;
-~~~
-
-## See also
-
-- [`ALTER TABLE`](alter-table.html)
-- [Column-level Constraints](constraints.html)
-- [Collation](collate.html)
-- [Column Families](column-families.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v19.2/add-constraint.md b/src/current/v19.2/add-constraint.md
deleted file mode 100644
index a0b34ebee84..00000000000
--- a/src/current/v19.2/add-constraint.md
+++ /dev/null
@@ -1,172 +0,0 @@
----
-title: ADD CONSTRAINT
-summary: Use the ADD CONSTRAINT statement to add constraints to columns.
-toc: true
----
-
-The `ADD CONSTRAINT` [statement](sql-statements.html) is part of `ALTER TABLE` and can add the following [constraints](constraints.html) to columns:
-
-- [`UNIQUE`](#add-the-unique-constraint)
-- [`CHECK`](#add-the-check-constraint)
-- [Foreign key](#add-the-foreign-key-constraint-with-cascade)
-
-{{site.data.alerts.callout_info}}
-The [`PRIMARY KEY`](primary-key.html) can only be applied through [`CREATE TABLE`](create-table.html). The [`DEFAULT`](default-value.html) and [`NOT NULL`](not-null.html) constraints are managed through [`ALTER COLUMN`](alter-column.html).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-
-{% include {{ page.version.version }}/sql/diagrams/add_constraint.html %}
-
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the table.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table containing the column you want to constrain.
- `constraint_name` | The name of the constraint, which must be unique to its table and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
- `constraint_elem` | The [`CHECK`](check.html), [foreign key](foreign-key.html), [`UNIQUE`](unique.html) constraint you want to add.
Adding/changing a `DEFAULT` constraint is done through [`ALTER COLUMN`](alter-column.html).
Adding/changing the table's `PRIMARY KEY` is not supported through `ALTER TABLE`; it can only be specified during [table creation](create-table.html).
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-### Add the `UNIQUE` constraint
-
-Adding the [`UNIQUE` constraint](unique.html) requires that all of a column's values be distinct from one another (except for *NULL* values).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE orders ADD CONSTRAINT id_customer_unique UNIQUE (id, customer);
-~~~
-
-### Add the `CHECK` constraint
-
-Adding the [`CHECK` constraint](check.html) requires that all of a column's values evaluate to `TRUE` for a Boolean expression.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE orders ADD CONSTRAINT check_id_non_zero CHECK (id > 0);
-~~~
-
-Check constraints can be added to columns that were created earlier in the transaction. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-> ALTER TABLE customers ADD COLUMN gdpr_status STRING;
-> ALTER TABLE customers ADD CONSTRAINT check_gdpr_status CHECK (gdpr_status IN ('yes', 'no', 'unknown'));
-> COMMIT;
-~~~
-
-~~~
-BEGIN
-ALTER TABLE
-ALTER TABLE
-COMMIT
-~~~
-
-{{site.data.alerts.callout_info}}
-The entire transaction will be rolled back, including any new columns that were added, in the following cases:
-
-- If an existing column is found containing values that violate the new constraint.
-- If a new column has a default value or is a [computed column](computed-columns.html) that would have contained values that violate the new constraint.
-{{site.data.alerts.end}}
-
-### Add the foreign key constraint with `CASCADE`
-
-To add a foreign key constraint, use the steps shown below.
-
-Given two tables, `customers` and `orders`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE customers;
-~~~
-
-~~~
- table_name | create_statement
-------------+----------------------------------------------------
- customers | CREATE TABLE customers ( +
- | id INT8 NOT NULL, +
- | name STRING NOT NULL, +
- | address STRING NULL, +
- | CONSTRAINT "primary" PRIMARY KEY (id ASC),+
- | FAMILY "primary" (id, name, address) +
- | )
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE orders;
-~~~
-
-~~~
- table_name | create_statement
-------------+----------------------------------------------------------------------------------------------------------------
- orders | CREATE TABLE orders ( +
- | id INT8 NOT NULL, +
- | customer_id INT8 NULL, +
- | status STRING NOT NULL, +
- | CONSTRAINT "primary" PRIMARY KEY (id ASC), +
- | FAMILY "primary" (id, customer_id, status), +
- | CONSTRAINT check_status CHECK (status IN ('open':::STRING, 'complete':::STRING, 'cancelled':::STRING))+
- | )
-(1 row)
-~~~
-
-You can include a [foreign key action](foreign-key.html#foreign-key-actions) to specify what happens when a foreign key is updated or deleted.
-
-Using `ON DELETE CASCADE` will ensure that when the referenced row is deleted, all dependent objects are also deleted.
-
-{{site.data.alerts.callout_danger}}
-`CASCADE` does not list the objects it drops or updates, so it should be used with caution.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE orders ADD CONSTRAINT customer_fk FOREIGN KEY (customer_id) REFERENCES customers (id) ON DELETE CASCADE;
-~~~
-
-An index on the referencing columns is automatically created for you when you add a foreign key constraint to an empty table, if an appropriate index does not already exist. You can see it using [`SHOW INDEXES`](show-index.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM orders;
-~~~
-
-~~~
- table_name | index_name | non_unique | seq_in_index | column_name | direction | storing | implicit
-------------+-------------------------------+------------+--------------+-------------+-----------+---------+----------
- orders | primary | f | 1 | id | ASC | f | f
- orders | orders_auto_index_customer_fk | t | 1 | customer_id | ASC | f | f
- orders | orders_auto_index_customer_fk | t | 2 | id | ASC | f | t
-(3 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-Adding a foreign key for a non-empty table without an appropriate index will fail, since foreign key columns must be indexed. For more information about the requirements for creating foreign keys, see [Rules for creating foreign keys](foreign-key.html#rules-for-creating-foreign-keys).
-{{site.data.alerts.end}}
-
-## See also
-
-- [Constraints](constraints.html)
-- [Foreign Key Constraint](foreign-key.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`RENAME CONSTRAINT`](rename-constraint.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`VALIDATE CONSTRAINT`](validate-constraint.html)
-- [`ALTER COLUMN`](alter-column.html)
-- [`CREATE TABLE`](create-table.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v19.2/admin-ui-access-and-navigate.md b/src/current/v19.2/admin-ui-access-and-navigate.md
deleted file mode 100644
index a94bb495499..00000000000
--- a/src/current/v19.2/admin-ui-access-and-navigate.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: Use the CockroachDB Admin UI
-summary: Learn how to access and navigate the Admin UI.
-toc: true
----
-
-The built-in Admin UI helps you monitor and troubleshoot CockroachDB by providing information about the cluster's health, configuration, and operations.
-
-## Access the Admin UI
-
-For insecure clusters, anyone can access and view the Admin UI. For secure clusters, only authorized users can [access and view the Admin UI](#accessing-the-admin-ui-for-a-secure-cluster). In addition, certain areas of the Admin UI can only be [accessed by `admin` users](admin-ui-overview.html#admin-ui-access).
-
-You can access the Admin UI from any node in the cluster.
-
-The Admin UI is reachable at the IP address/hostname and port set via the `--http-addr` flag when [starting each node](cockroach-start.html), for example, `http://:` for an insecure cluster or `https://:` for a secure cluster.
-
-If `--http-addr` is not specified when starting a node, the Admin UI is reachable at the IP address/hostname set via the `--listen-addr` flag and port `8080`.
-
-For additional guidance on accessing the Admin UI in the context of cluster deployment, see [Start a Local Cluster](start-a-local-cluster.html) and [Manual Deployment](manual-deployment.html).
-
-### Accessing the Admin UI for a secure cluster
-
-Note that on secure clusters, certain areas of the Admin UI can only be accessed by `admin` users. For details on providing access to users, see [this page](admin-ui-overview.html#admin-ui-access).
-
-On [accessing the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui), your browser will consider the CockroachDB-created certificate invalid, so you’ll need to click through a warning message to get to the UI. For secure clusters, you can avoid getting the warning message by using a certificate issued by a public CA. For more information, refer to [Use a UI certificate and key to access the Admin UI](create-security-certificates-custom-ca.html#accessing-the-admin-ui-for-a-secure-cluster).
-
-For each user who should have access to the Admin UI for a secure cluster, [create a user with a password](create-user.html). On accessing the Admin UI, the users will see a Login screen, where they will need to enter their usernames and passwords.
-
-{{site.data.alerts.callout_info}}
-This login information is stored in a system table that is replicated like other data in the cluster. If a majority of the nodes with the replicas of the system table data go down, users will be locked out of the Admin UI.
-{{site.data.alerts.end}}
-
-To log out of the Admin UI, click the **Log Out** link at the bottom of the left-hand navigation bar.
-
-## Navigate the Admin UI
-
-The left-hand navigation bar allows you to navigate to the [Cluster Overview page](admin-ui-access-and-navigate.html), [cluster metrics dashboards](admin-ui-overview.html), the [Databases page](admin-ui-databases-page.html), the [Statements page](admin-ui-statements-page.html), the [Jobs page](admin-ui-jobs-page.html), and the [Advanced Debugging page](admin-ui-debug-pages.html).
-
-The main panel display changes for each page:
-
-Page | Main Panel Component
------------|------------
-Cluster Overview | - [Cluster Overview panel](admin-ui-cluster-overview-page.html)
- [Node List](admin-ui-cluster-overview-page.html#node-list)
- [Enterprise users](enterprise-licensing.html) can enable and switch to the [Node Map](admin-ui-cluster-overview-page.html#node-map-enterprise) view.
-Cluster Metrics | - [Time Series graphs](admin-ui-access-and-navigate.html#cluster-metrics)
- [Summary Panel](admin-ui-access-and-navigate.html#summary-panel)
- [Events List](admin-ui-access-and-navigate.html#events-panel)
-Databases | Information about the tables and grants in your [databases](admin-ui-databases-page.html).
-Statements | Information about the SQL [statements](admin-ui-statements-page.html) running in the cluster.
-Jobs | Information about all currently active schema changes and backup/restore [jobs](admin-ui-jobs-page.html).
-Advanced Debugging | Advanced monitoring and troubleshooting [reports](admin-ui-debug-pages.html). These pages are experimental. If you find an issue, let us know through [these channels](https://www.cockroachlabs.com/community/).
-
-### Cluster Metrics
-
-The **Cluster Metrics** dashboards display the time series graphs that are useful to visualize and monitor data trends. To access the time series graphs, click **Metrics** on the left.
-
-You can hover over each graph to see actual point-in-time values.
-
-
-
-{{site.data.alerts.callout_info}}
-By default, CockroachDB stores time series metrics for the last 30 days, but you can reduce the interval for timeseries storage. Alternatively, if you are exclusively using a third-party tool such as [Prometheus](monitor-cockroachdb-with-prometheus.html) for time series monitoring, you can disable time series storage entirely. For more details, see this [FAQ](operational-faqs.html#can-i-reduce-or-disable-the-storage-of-timeseries-data).
-{{site.data.alerts.end}}
-
-#### Change time range
-
-You can change the time range by clicking on the time window.
-
-
-{{site.data.alerts.callout_info}}The Admin UI shows time in UTC, even if you set a different time zone for your cluster. {{site.data.alerts.end}}
-
-#### View metrics for a single node
-
-By default, the time series panel displays the metrics for the entire cluster. To view the metrics for an individual node, select the node from the **Graph** drop-down list.
-
-
-### Summary panel
-
-The **Cluster Metrics** dashboards display the **Summary** panel of key metrics. To view the **Summary** panel, click **Metrics** on the left.
-
-
-
-The **Summary** panel provides the following metrics:
-
-Metric | Description
---------|----
-Total Nodes | The total number of nodes in the cluster. Decommissioned nodes are not included in the Total Nodes count.
You can further drill down into the nodes details by clicking on [**View nodes list**](admin-ui-cluster-overview-page.html#node-list).
-Dead Nodes | The number of [dead nodes](admin-ui-cluster-overview-page.html#dead-nodes) in the cluster.
-Capacity Used | The storage capacity used as a percentage of total storage capacity allocated across all nodes.
-Unavailable Ranges | The number of unavailable ranges in the cluster. A non-zero number indicates an unstable cluster.
-Queries per second | The total number of `SELECT`, `UPDATE`, `INSERT`, and `DELETE` queries executed per second across the cluster.
-P50 Latency | The 50th percentile of service latency. Service latency is calculated as the time between when the cluster receives a query and finishes executing the query. This time does not include returning results to the client.
-P99 Latency | The 99th percentile of service latency.
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-{{site.data.alerts.end}}
-
-### Events panel
-
-The **Cluster Metrics** dashboards display the **Events** panel that lists the 10 most recent events logged for the all nodes across the cluster. To view the **Events** panel, click **Metrics** on the left-hand navigation bar. To see the list of all events, click **View all events** in the **Events** panel.
-
-
-
-The following types of events are listed:
-
-- Database created
-- Database dropped
-- Table created
-- Table dropped
-- Table altered
-- Index created
-- Index dropped
-- View created
-- View dropped
-- Schema change reversed
-- Schema change finished
-- Node joined
-- Node decommissioned
-- Node restarted
-- Cluster setting changed
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-cdc-dashboard.md b/src/current/v19.2/admin-ui-cdc-dashboard.md
deleted file mode 100644
index f54dd270da0..00000000000
--- a/src/current/v19.2/admin-ui-cdc-dashboard.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Changefeeds Dashboard
-summary: The Changefeeds dashboard lets you monitor the changefeeds created across your cluster.
-toc: true
----
-
-The **Changefeeds** dashboard in the CockroachDB Admin UI lets you monitor the [changefeeds](change-data-capture.html) created across your cluster. To view this dashboard, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui), click **Metrics** on the left-hand navigation bar, and then select **Dashboard** > **Changefeeds**.
-
-
-The **Changefeeds** dashboard displays the following time series graphs:
-
-## Max Changefeed Latency
-
-
-
-- In the node view, the graph shows the maximum latency for resolved timestamps of any running changefeed for the node.
-
-- In the cluster view, the graph shows the maximum latency for resolved timestamps of any running changefeed across all nodes.
-
-{{site.data.alerts.callout_info}}
-The maximum latency for resolved timestamps is distinct from and slower than the commit-to-emit latency for individual change messages. For more information about resolved timestamps, see [Ordering guarantees](change-data-capture.html#ordering-guarantees).
-{{site.data.alerts.end}}
-
-## Sink Byte Traffic
-
-
-
-- In the node view, the graph shows the number of bytes emitted by CockroachDB into the sink across all changefeeds for the selected node.
-
-- In the cluster view, the graph shows the number of bytes emitted by CockroachDB into the sink across all changefeeds and across all nodes in the cluster.
-
-On hovering over the graph, the values for the following metrics are displayed:
-
-Metric | Description
---------|----
-**Emitted Bytes** | The number of bytes emitted by CockroachDB into the sink for all changefeeds.
-
-## Sink Counts
-
-
-
-- In the node view, the graph shows the number of messages that CockroachDB sent to the sink as well as the number of flushes that the sink performed for all changefeeds.
-
-- In the cluster view, the graph shows the number of messages that CockroachDB sent to the sink as well as the number of flushes that the sink performed for all changefeeds across the cluster.
-
-On hovering over the graph, the values for the following metrics are displayed:
-
-Metric | Description
---------|----
-**Messages** | The number of messages that CockroachDB sent to the sink for all changefeeds.
-**Flushes** | The the number of flushes that the sink performed for all changefeeds.
-
-## Sink Timings
-
-
-
-- In the node view, the graph shows the time in milliseconds per second required by CockroachDB to send messages to the sink as well as the time CockroachDB spent waiting for the sink to flush the messages for all changefeeds.
-
-- In the cluster view, the graph shows the time in milliseconds per second required by CockroachDB to send messages to the sink as the time CockroachDB spent waiting for the sink to flush the messages for all changefeeds across the cluster.
-
-On hovering over the graph, the values for the following metrics are displayed:
-
-Metric | Description
---------|----
-**Message Emit Time** | The time in milliseconds per second required by CockroachDB to send messages to the sink for all changefeeds.
-**Flush Time** | The time in milliseconds per second that CockroachDB spent waiting for the sink to flush the messages for all changefeeds.
-
-## See also
-
-- [Change Data Capture](change-data-capture.html)
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-cluster-overview-page.md b/src/current/v19.2/admin-ui-cluster-overview-page.md
deleted file mode 100644
index 2112cfaa8ee..00000000000
--- a/src/current/v19.2/admin-ui-cluster-overview-page.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: Cluster Overview Page
-toc: true
----
-
-The **Cluster Overview** page of the Admin UI provides details of the cluster nodes and their liveness status, replication status, uptime, and key hardware metrics. [Enterprise users](enterprise-licensing.html) can enable and switch to the [Node Map](admin-ui-cluster-overview-page.html#node-map-enterprise) view.
-
-## Cluster Overview Panel
-
-
-
-The **Cluster Overview** panel provides the following metrics:
-
-Metric | Description
---------|----
-Capacity Usage | - Used capacity: The storage capacity used by CockroachDB (represented as a percentage of total storage capacity allocated across all nodes).
- Usable capacity: The space available for CockroachDB data storage (i.e., the storage capacity of the machine excluding the capacity used by the Cockroach binary, operating system, and other system files).
-Node Status | | 
-
-### Live Nodes
-Live nodes are nodes that are online and responding. They are marked with a green dot. If a node is removed or dies, the dot turns yellow to indicate that it is not responding. If the node remains unresponsive for a certain amount of time (5 minutes by default), the node turns red and is moved to the [**Dead Nodes**](#dead-nodes) section, indicating that it is no longer expected to come back.
-
-The following details are shown for each live node:
-
-Column | Description
--------|------------
-ID | The ID of the node.
-Address | The address of the node. You can click on the address to view further details about the node.
-Uptime | How long the node has been running.
-Replicas | The number of replicas on the node.
-CPUs | The number of CPU cores on the machine.
-Capacity Usage | The storage capacity used by CockroachDB as a percentage of the total usable capacity on the node. The value is represented numerically and as a bar graph.
-Mem Usage | The memory used by CockroachDB as a percentage of the total memory on the node. The value is represented numerically and as a bar graph.
-Version | The build tag of the CockroachDB version installed on the node.
-Logs | Click **Logs** to see detailed logs for the node. [Requires `admin` privileges](admin-ui-overview.html#admin-ui-access) on secure clusters.
-
-### Dead Nodes
-
-Nodes are considered dead once they have not responded for a certain amount of time (5 minutes by default). At this point, the automated repair process starts, wherein CockroachDB automatically rebalances replicas from the dead node, using the unaffected replicas as sources. See [Stop a Node](cockroach-quit.html#how-it-works) for more information.
-
-The following details are shown for each dead node:
-
-Column | Description
--------|------------
-ID | The ID of the node.
-Address | The address of the node. You can click on the address to view further details about the node.
-Down Since | How long the node has been down.
-
-### Decommissioned Nodes
-
-Nodes that have been decommissioned for removal from the cluster are listed in the **Decommissioned Nodes** table.
-
-When you initiate the [decommissioning process](remove-nodes.html#how-it-works) on a node, CockroachDB transfers all range replicas and range leases off the node so that it can be safely shut down.
-
-## Node Map (Enterprise)
-
-The **Node Map** is an [enterprise-only](enterprise-licensing.html) feature that gives you a visual representation of the geographical configuration of your cluster.
-
-
-
-The Node Map consists of the following components:
-
-### Region component
-
-
-
-{{site.data.alerts.callout_info}}
-For multi-core systems, the user CPU percent can be greater than 100%. Full utilization of one core is considered as 100% CPU usage. If you have n cores, then the user CPU percent can range from 0% (indicating an idle system) to (n*100)% (indicating full utilization).
-{{site.data.alerts.end}}
-
-### Node component
-
-
-
-{{site.data.alerts.callout_info}}
-For multi-core systems, the user CPU percent can be greater than 100%. Full utilization of one core is considered as 100% CPU usage. If you have n cores, then the user CPU percent can range from 0% (indicating an idle system) to (n*100)% (indicating full utilization).
-{{site.data.alerts.end}}
-
-For guidance on enabling and using the node map, see [Enable Node Map](enable-node-map.html).
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-custom-chart-debug-page.md b/src/current/v19.2/admin-ui-custom-chart-debug-page.md
deleted file mode 100644
index 751a9a4ee67..00000000000
--- a/src/current/v19.2/admin-ui-custom-chart-debug-page.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: Custom Chart Debug Page
-toc: true
----
-
-The **Custom Chart** debug page in the Admin UI can be used to create one or multiple custom charts showing any combination of over [200 available metrics](#available-metrics).
-
-The definition of the customized dashboard is encoded in the URL. To share the dashboard with someone, send them the URL. Like any other URL, it can be bookmarked, sit in a pinned tab in your browser, etc.
-
-
-## Accessing the **Custom Chart** page
-
-To access the **Custom Chart** debug page, [access the Admin UI](admin-ui-access-and-navigate.html), and either:
-
-- Open http://localhost:8080/#/debug/chart in your browser (replacing `localhost` and `8080` with your node's host and port).
-
-- Click the gear icon on the left to access the **Advanced Debugging Page**. In the **Reports** section, click **Custom TimeSeries Chart**.
-
-## Using the **Custom Chart** page
-
-
-
-On the **Custom Chart** page, you can set the time span for all charts, add new custom charts, and customize each chart:
-
-- To set the time span for the page, use the dropdown menu above the charts and select the desired time span.
-
-- To add a chart, click **Add Chart** and customize the new chart.
-
-- To customize each chart, use the **Units** dropdown menu to set the units to display. Then use the table below the chart to select the metrics being queried, and how they'll be combined and displayed. Options include:
-{% include {{page.version.version}}/admin-ui-custom-chart-debug-page-00.html %}
-
-## Examples
-
-### Query user and system CPU usage
-
-
-
-To compare system vs. userspace CPU usage, select the following values under **Metric Name**:
-
-- `sys.cpu.sys.percent`
-- `sys.cpu.user.percent`
-
-The Y-axis label is the **Count**. A count of 1 represents 100% utilization. The **Aggregator** of **Sum** can show the count to be above 1, which would mean CPU utilization is greater than 100%.
-
-Checking **Per Node** displays statistics for each node, which could show whether an individual node's CPU usage was higher or lower than the average.
-
-## Available metrics
-
-{{site.data.alerts.callout_info}}
-This list is taken directly from the source code and is subject to change. Some of the metrics listed below are already visible in other areas of the [Admin UI](admin-ui-overview.html).
-{{site.data.alerts.end}}
-
-{% include {{page.version.version}}/metric-names.md %}
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-databases-page.md b/src/current/v19.2/admin-ui-databases-page.md
deleted file mode 100644
index b706ead0835..00000000000
--- a/src/current/v19.2/admin-ui-databases-page.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: Database Page
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-On a secure cluster, this area of the Admin UI can only be accessed by an `admin` user. See [Admin UI access](admin-ui-overview.html#admin-ui-access).
-{{site.data.alerts.end}}
-
-The **Databases** page of the Admin UI provides details of the databases configured, the tables in each database, and the grants assigned to each user. To view these details, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui) and then click **Databases** on the left-hand navigation bar.
-
-
-## Tables view
-
-The **Tables** view shows details of the system table as well as the tables in your databases. To view these details, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui) and then select **Databases** from the left-hand navigation bar.
-
-
-
-The following details are displayed for each table:
-
-Metric | Description
---------|----
-Table Name | The name of the table.
-Size | Approximate total disk size of the table across all replicas.
-Ranges | The number of ranges in the table.
-\# of Columns | The number of columns in the table.
-\# of Indices | The number of indices for the table.
-
-## Grants view
-
-The **Grants** view shows the [privileges](authorization.html#assign-privileges) granted to users for each database. To view these details, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui) and then select **Databases** from the left-hand navigation bar, select **Databases** from the left-hand navigation bar, and then select **Grants** from the **View** menu.
-
-For more details about grants and privileges, see [Grants](grant.html).
-
-
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-debug-pages.md b/src/current/v19.2/admin-ui-debug-pages.md
deleted file mode 100644
index 72a19461140..00000000000
--- a/src/current/v19.2/admin-ui-debug-pages.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-title: Advanced Debugging Page
-toc: true
----
-
-The **Advanced Debugging** page of the Admin UI provides links to advanced monitoring and troubleshooting reports and cluster configuration details. To view the **Advanced Debugging** page, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui) and then click the gear icon on the left-hand navigation bar.
-
-{{site.data.alerts.callout_info}}
-These pages are experimental and undocumented. If you find an issue, let us know through [these channels](https://www.cockroachlabs.com/community/).
- {{site.data.alerts.end}}
-
-## License and node information
-
-On the right-side of the page, the following information is displayed:
-
-- CockroachDB license type: Helps determine if you have access to Enterprise features.
-- Current node ID: Helps identify the current node when viewing the Admin UI through a load balancer.
-
-## Reports and Configuration
-
-The following debug reports and configuration views are useful for monitoring and troubleshooting CockroachDB:
-
-Report | Description | Access level
---------|-----|--------
-[Custom Time Series Chart](admin-ui-custom-chart-debug-page.html) | Create a custom chart of time series data. | All users
-Problem Ranges | View ranges in your cluster that are unavailable, underreplicated, slow, or have other problems. | [`admin` users only on secure clusters](admin-ui-overview.html#admin-ui-access)
-Network Latency | Check latencies between all nodes in your cluster. | All users
-Data Distribution and Zone Configs | View the distribution of table data across nodes and verify zone configuration. | [`admin` users only on secure clusters](admin-ui-overview.html#admin-ui-access)
-Cluster Settings | View cluster settings and their configured values. | All users can view data according to their privileges
-Localities | Check node localities for your cluster. | [`admin` users only on secure clusters](admin-ui-overview.html#admin-ui-access)
-
-## Even More Advanced Debugging
-
-The **Even More Advanced Debugging** section of the page lists additional reports that are largely internal and intended for use by CockroachDB developers. You can ignore this section while monitoring and troubleshooting CockroachDB. Alternatively, if you want to learn how to use these pages, feel free to contact us through [these channels](https://www.cockroachlabs.com/community/).
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-hardware-dashboard.md b/src/current/v19.2/admin-ui-hardware-dashboard.md
deleted file mode 100644
index 6aa0a526cc2..00000000000
--- a/src/current/v19.2/admin-ui-hardware-dashboard.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: Hardware Dashboard
-summary: The Hardware dashboard lets you monitor CPU usage, disk throughput, network traffic, storage capacity, and memory.
-toc: true
----
-
-The **Hardware** dashboard lets you monitor CPU usage, disk throughput, network traffic, storage capacity, and memory. To view this dashboard, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui), click **Metrics** on the left, and then select **Dashboard** > **Hardware**.
-
-The **Hardware** dashboard displays the following time series graphs:
-
-## CPU Percent
-
-
-
-{{site.data.alerts.callout_info}}
-This graph shows the CPU consumption by the CockroachDB process only and is useful as long as there are no other processes consuming significant CPU on the node. In case you have other processes running on the node, use a separate monitoring tool to measure the total CPU consumption across all processes.
-{{site.data.alerts.end}}
-
-- In the node view, the graph shows the percentage of CPU in use by the CockroachDB process for the selected node.
-
-- In the cluster view, the graph shows the percentage of CPU in use by the CockroachDB process across all nodes.
-
-{{site.data.alerts.callout_info}}
-For multi-core systems, the percentage of CPU usage is calculated by normalizing the CPU usage across all cores, whereby 100% utilization indicates that all cores are fully utilized.
-{{site.data.alerts.end}}
-
-## Memory Usage
-
-
-
-{{site.data.alerts.callout_info}}
-This graph shows the memory consumption by the CockroachDB process only and is useful as long as there are no other processes consuming significant memory on the node. In case you have other processes running on the node, use a separate monitoring tool to measure the total memory consumption across all processes.
-{{site.data.alerts.end}}
-
-- In the node view, the graph shows the memory in use by CockroachDB for the selected node.
-
-- In the cluster view, the graph shows the memory in use by CockroachDB across all nodes in the cluster.
-
-## Disk Read Bytes
-
-
-
-- In the node view, the graph shows the 10-second average of the number of bytes read per second by all processes, including CockroachDB, for the selected node.
-
-- In the cluster view, the graph shows the 10-second average of the number of bytes read per second by all processes, including CockroachDB, across all nodes.
-
-## Disk Write Bytes
-
-
-
-- In the node view, the graph shows the 10-second average of the number of bytes written per second by all processes, including CockroachDB, for the node.
-
-- In the cluster view, the graph shows the 10-second average of the number of bytes written per second by all processes, including CockroachDB, across all nodes.
-
-## Disk Read Ops
-
-
-
-- In the node view, the graph shows the 10-second average of the number of disk read ops per second for all processes, including CockroachDB, for the selected node.
-
-- In the cluster view, the graph shows the 10-second average of the number of disk read ops per second for all processes, including CockroachDB, across all nodes.
-
-## Disk Write Ops
-
-
-
-- In the node view, the graph shows the 10-second average of the number of disk write ops per second for all processes, including CockroachDB, for the node.
-
-- In the cluster view, the graph shows the 10-second average of the number of disk write ops per second for all processes, including CockroachDB, across all nodes.
-
-## Disk IOPS in Progress
-
-
-
-- In the node view, the graph shows the number of disk reads and writes in queue for all processes, including CockroachDB, for the selected node.
-
-- In the cluster view, the graph shows the number of disk reads and writes in queue for all processes, including CockroachDB, across all nodes in the cluster.
-
-{{site.data.alerts.callout_info}}
-For Mac OS, this graph is not populated and shows zero disk IOPS in progress. This is a [known limitation](https://github.com/cockroachdb/cockroach/issues/27927) that may be lifted in the future.
-{{site.data.alerts.end}}
-
-## Available Disk Capacity
-
-
-
-- In the node view, the graph shows the available storage capacity for the selected node.
-
-- In the cluster view, the graph shows the available storage capacity across all nodes in the cluster.
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-{{site.data.alerts.end}}
-
-## Network Bytes Received
-
-
-
-- In the node view, the graph shows the 10-second average of the number of network bytes received per second for all processes, including CockroachDB, for the node.
-
-- In the cluster view, the graph shows the 10-second average of the number of network bytes received for all processes, including CockroachDB, per second across all nodes.
-
-## Network Bytes Sent
-
-
-
-- In the node view, the graph shows the 10-second average of the number of network bytes sent per second by all processes, including CockroachDB, for the node.
-
-- In the cluster view, the graph shows the 10-second average of the number of network bytes sent per second by all processes, including CockroachDB, across all nodes.
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-jobs-page.md b/src/current/v19.2/admin-ui-jobs-page.md
deleted file mode 100644
index 96d2f3b7b57..00000000000
--- a/src/current/v19.2/admin-ui-jobs-page.md
+++ /dev/null
@@ -1,37 +0,0 @@
----
-title: Jobs Page
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-On a secure cluster, this area of the Admin UI can only be accessed by an `admin` user. See [Admin UI access](admin-ui-overview.html#admin-ui-access).
-{{site.data.alerts.end}}
-
-The **Jobs** page of the Admin UI provides details about the backup/restore jobs, schema changes, [user-created table statistics](create-statistics.html) and [automatic table statistics](cost-based-optimizer.html#table-statistics) jobs, and changefeeds performed across all nodes in the cluster. To view these details, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui) and then click **Jobs** on the left-hand navigation bar.
-
-
-## Job details
-
-The **Jobs** table displays the ID, description, user, creation time, and status of each backup and restore job, schema changes, user-created table statistics and automatic table statistics jobs, and changefeeds performed across all nodes in the cluster. To view the job's full description, click the drop-down arrow in the first column.
-
-
-
-For changefeeds, the table displays a [high-water timestamp that advances as the changefeed progresses](change-data-capture.html#monitor-a-changefeed). This is a guarantee that all changes before or at the timestamp have been emitted. Hover over the high-water timestamp to view the [system time](as-of-system-time.html).
-
-The automatic table statistics jobs are not displayed even when the **TYPE** drop-down is set to **All**. To view the automatic statistics creation jobs, filter the results to **Automatic-Statistics Creation** as described in the [Filtering results](#filtering-results) section.
-
-## Filtering results
-
-You can filter the results based on the status of the jobs or the type of jobs (backups, restores, schema changes, changefeeds, user-created table statistics, and automatic table statistics). You can also choose to view either the latest 50 jobs or all the jobs across all nodes.
-
-Filter By | Description
-----------|------------
-Job Status | From the **Status** menu, select the required status filter.
-Job Type | From the **Type** menu, select **Backups**, **Restores**, **Imports**, **Schema Changes**, **Changefeed**, **Statistics Creation**, or **Auto-Statistics Creation**.
-Jobs Shown | From the **Show** menu, select **First 50** or **All**.
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-overview-dashboard.md b/src/current/v19.2/admin-ui-overview-dashboard.md
deleted file mode 100644
index 9bd758fd814..00000000000
--- a/src/current/v19.2/admin-ui-overview-dashboard.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Overview Dashboard
-summary: The Overview dashboard lets you monitor important SQL performance, replication, and storage metrics.
-toc: true
----
-
-The **Overview** dashboard lets you monitor important SQL performance, replication, and storage metrics. To view this dashboard, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui) and click **Metrics** on the left-hand navigation bar. The **Overview** dashboard is displayed by default.
-
-
-The **Overview** dashboard displays the following time series graphs:
-
-## SQL Queries
-
-
-
-- In the node view, the graph shows the 10-second average of the number of `SELECT`/`INSERT`/`UPDATE`/`DELETE` queries per second issued by SQL clients on the node.
-
-- In the cluster view, the graph shows the sum of the per-node averages, that is, an aggregate estimation of the current query load over the cluster, assuming the last 10 seconds of activity per node are representative of this load.
-
-## Service Latency: SQL, 99th percentile
-
-
-
-Service latency is calculated as the time between when the cluster receives a query and finishes executing the query. This time does not include returning results to the client.
-
-- In the node view, the graph shows the 99th [percentile](https://en.wikipedia.org/wiki/Percentile#The_normal_distribution_and_percentiles) of service latency for the node.
-
-- In the cluster view, the graph shows the 99th [percentile](https://en.wikipedia.org/wiki/Percentile#The_normal_distribution_and_percentiles) of service latency across all nodes in the cluster.
-
-## Replicas per Node
-
-
-
-Ranges are subsets of your data, which are replicated to ensure survivability. Ranges are replicated to a configurable number of CockroachDB nodes.
-
-- In the node view, the graph shows the number of range replicas on the selected node.
-
-- In the cluster view, the graph shows the number of range replicas on each node in the cluster.
-
-For details about how to control the number and location of replicas, see [Configure Replication Zones](configure-replication-zones.html).
-
-{{site.data.alerts.callout_info}}
-The timeseries data used to power the graphs in the Admin UI is stored within the cluster and accumulates for 30 days before it starts getting truncated. As a result, for the first 30 days or so of a cluster's life, you will see a steady increase in disk usage and the number of ranges even if you aren't writing data to the cluster yourself. For more details, see this [FAQ](operational-faqs.html#why-is-disk-usage-increasing-despite-lack-of-writes).
-{{site.data.alerts.end}}
-
-## Capacity
-
-
-
-You can monitor the **Capacity** graph to determine when additional storage is needed.
-
-- In the node view, the graph shows the maximum allocated capacity, available storage capacity, and capacity used by CockroachDB for the selected node.
-
-- In the cluster view, the graph shows the maximum allocated capacity, available storage capacity, and capacity used by CockroachDB across all nodes in the cluster.
-
-On hovering over the graph, the values for the following metrics are displayed:
-
-Metric | Description
---------|----
-**Capacity** | The maximum storage capacity allocated to CockroachDB. You can configure the maximum storage capacity for a given node using the `--store` flag. For more information, see [Start a Node](cockroach-start.html#store).
-**Available** | The free storage capacity available to CockroachDB.
-**Used** | Disk space used by the data in the CockroachDB store. Note that this value is less than (**Capacity** - **Available**) because **Capacity** and **Available** metrics consider the entire disk and all applications on the disk, including CockroachDB, whereas **Used** metric tracks only the store's disk usage.
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-{{site.data.alerts.end}}
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-overview.md b/src/current/v19.2/admin-ui-overview.md
deleted file mode 100644
index d0b3e52dcec..00000000000
--- a/src/current/v19.2/admin-ui-overview.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Admin UI Overview
-summary: Use the Admin UI to monitor and optimize cluster performance.
-toc: true
-key: explore-the-admin-ui.html
----
-
-The CockroachDB Admin UI provides details about your cluster and database configuration, and helps you optimize cluster performance.
-
-## Admin UI areas
-
-Area | Description
---------|----
-[Node Map](enable-node-map.html) | View and monitor the metrics and geographical configuration of your cluster.
-[Cluster Health](admin-ui-access-and-navigate.html#summary-panel) | View essential metrics about the cluster's health, such as the number of live, dead, and suspect nodes, the number of unavailable ranges, and the queries per second and service latency across the cluster.
-[Overview Metrics](admin-ui-overview-dashboard.html) | View important SQL performance, replication, and storage metrics.
-[Hardware Metrics](admin-ui-hardware-dashboard.html) | View metrics about CPU usage, disk throughput, network traffic, storage capacity, and memory.
-[Runtime Metrics](admin-ui-runtime-dashboard.html) | View metrics about node count, CPU time, and memory usage.
-[SQL Performance](admin-ui-sql-dashboard.html) | View metrics about SQL connections, byte traffic, queries, transactions, and service latency.
-[Storage Utilization](admin-ui-storage-dashboard.html) | View metrics about storage capacity and file descriptors.
-[Replication Details](admin-ui-replication-dashboard.html) | View metrics about how data is replicated across the cluster, such as range status, replicas per store, and replica quiescence.
-[Changefeed Details](admin-ui-cdc-dashboard.html) | View metrics about the [changefeeds](change-data-capture.html) created across your cluster.
-[Nodes Details](admin-ui-access-and-navigate.html#summary-panel) | View details of live, dead, and decommissioned nodes.
-[Events](admin-ui-access-and-navigate.html#events-panel) | View a list of recent cluster events.
-[Database Details](admin-ui-databases-page.html) | View details about the system and user databases in the cluster.
-[Statements Details](admin-ui-statements-page.html) | Identify frequently executed or high latency [SQL statements](sql-statements.html)
-[Jobs Details](admin-ui-jobs-page.html) | View details of the jobs running in the cluster.
-[Advanced Debugging Pages](admin-ui-debug-pages.html) | View advanced monitoring and troubleshooting reports. These include details about data distribution, the state of specific queues, and slow query metrics. These details are largely intended for use by CockroachDB developers.
-
-## Admin UI access
-
-On insecure clusters, all areas of the Admin UI are accessible to all users.
-
-On secure clusters, certain areas of the Admin UI can only be accessed by [`admin` users](authorization.html#admin-role). These areas display information from privileged HTTP endpoints that operate with `admin` privilege.
-
-For security reasons, non-admin users access only the data over which they have privileges (e.g., their tables and list of sessions), and data that does not require privileges (e.g., cluster health, node status, metrics).
-
-{{site.data.alerts.callout_info}}
-The default `root` user is a member of the `admin` role, but on CockroachDB clusters prior to v20.1, the Admin UI cannot be accessed by `root`. To access the secure Admin UI areas, [grant a user membership to the `admin` role](grant-roles.html):
-
-
-
-The **Ranges** graph shows you various details about the status of ranges.
-
-- In the node view, the graph shows details about ranges on the node.
-
-- In the cluster view, the graph shows details about ranges across all nodes in the cluster.
-
-On hovering over the graph, the values for the following metrics are displayed:
-
-Metric | Description
---------|----
-Ranges | The number of ranges.
-Leaders | The number of ranges with leaders. If the number does not match the number of ranges for a long time, troubleshoot your cluster.
-Lease Holders | The number of ranges that have leases.
-Leaders w/o Leases | The number of Raft leaders without leases. If the number if non-zero for a long time, troubleshoot your cluster.
-Unavailable | The number of unavailable ranges. If the number if non-zero for a long time, troubleshoot your cluster.
-Under-replicated | The number of under-replicated ranges.
-
-### Replicas Per Store
-
-
-
-- In the node view, the graph shows the number of range replicas on the store.
-
-- In the cluster view, the graph shows the number of range replicas on each store.
-
-You can [Configure replication zones](configure-replication-zones.html) to set the number and location of replicas. You can monitor the configuration changes using the Admin UI, as described in [Fault tolerance and recovery](demo-fault-tolerance-and-recovery.html).
-
-### Replica Quiescence
-
-
-
-- In the node view, the graph shows the number of replicas on the node.
-
-- In the cluster view, the graph shows the number of replicas across all nodes.
-
-On hovering over the graph, the values for the following metrics are displayed:
-
-Metric | Description
---------|----
-Replicas | The number of replicas.
-Quiescent | The number of replicas that haven't been accessed for a while.
-
-### Snapshots
-
-
-
-Usually the nodes in a [Raft group](architecture/replication-layer.html#raft) stay synchronized by following along the log message by message. However, if a node is far enough behind the log (e.g., if it was offline or is a new node getting up to speed), rather than send all the individual messages that changed the range, the cluster can send it a snapshot of the range and it can start following along from there. Commonly this is done preemptively, when the cluster can predict that a node will need to catch up, but occasionally the Raft protocol itself will request the snapshot.
-
-Metric | Description
--------|------------
-Generated | The number of snapshots created per second.
-Applied (Raft-initiated) | The number of snapshots applied to nodes per second that were initiated within Raft.
-Applied (Learner) | New in v19.2: The number of snapshots applied to nodes per second that were anticipated ahead of time (e.g., because a node was about to be added to a Raft group). This metric replaces the `Applied (Preemptive)` metric in 19.2 and onwards.
-Applied (Preemptive) | The number of snapshots applied to nodes per second that were anticipated ahead of time (e.g., because a node was about to be added to a Raft group). This metric was used in pre-v19.2 releases and will be removed in future releases.
-Reserved | The number of slots reserved per second for incoming snapshots that will be sent to a node.
-
-### Other graphs
-
-The **Replication** dashboard shows other time series graphs that are important for CockroachDB developers:
-
-- Leaseholders per Store
-- Average Queries per Store
-- Logical Bytes per Store
-- Range Operations
-
-For monitoring CockroachDB, it is sufficient to use the [**Ranges**](#ranges), [**Replicas per Store**](#replicas-per-store), and [**Replica Quiescence**](#replica-quiescence) graphs.
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-runtime-dashboard.md b/src/current/v19.2/admin-ui-runtime-dashboard.md
deleted file mode 100644
index 8dcfa60ff24..00000000000
--- a/src/current/v19.2/admin-ui-runtime-dashboard.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Runtime Dashboard
-toc: true
----
-
-The **Runtime** dashboard in the CockroachDB Admin UI lets you monitor runtime metrics for you cluster, such as node count, memory usage, and CPU time. To view this dashboard, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui), click **Metrics** on the left-hand navigation bar, and then select **Dashboard** > **Runtime**.
-
-
-The **Runtime** dashboard displays the following time series graphs:
-
-## Live Node Count
-
-
-
-In the node view as well as the cluster view, the graph shows the number of live nodes in the cluster.
-
-A dip in the graph indicates decommissioned nodes, dead nodes, or nodes that are not responding. To troubleshoot the dip in the graph, refer to the [Summary panel](admin-ui-access-and-navigate.html#summary-panel).
-
-## Memory Usage
-
-
-
-- In the node view, the graph shows the memory in use for the selected node.
-
-- In the cluster view, the graph shows the memory in use across all nodes in the cluster.
-
-On hovering over the graph, the values for the following metrics are displayed:
-
-Metric | Description
---------|----
-RSS | Total memory in use by CockroachDB.
-Go Allocated | Memory allocated by the Go layer.
-Go Total | Total memory managed by the Go layer.
-CGo Allocated | Memory allocated by the C layer.
-CGo Total | Total memory managed by the C layer.
-
-{{site.data.alerts.callout_info}}If Go Total or CGO Total fluctuates or grows steadily over time, contact us.{{site.data.alerts.end}}
-
-## CPU Time
-
-
-
-
-- In the node view, the graph shows the [CPU time](https://en.wikipedia.org/wiki/CPU_time) used by CockroachDB user and system-level operations for the selected node.
-- In the cluster view, the graph shows the [CPU time](https://en.wikipedia.org/wiki/CPU_time) used by CockroachDB user and system-level operations across all nodes in the cluster.
-
-On hovering over the CPU Time graph, the values for the following metrics are displayed:
-
-Metric | Description
---------|----
-User CPU Time | Total CPU seconds per second used by the CockroachDB process across all nodes.
-Sys CPU Time | Total CPU seconds per second used for CockroachDB system-level operations across all nodes.
-
-## Clock Offset
-
-
-
-- In the node view, the graph shows the mean clock offset of the node against the rest of the cluster.
-- In the cluster view, the graph shows the mean clock offset of each node against the rest of the cluster.
-
-## Other graphs
-
-The **Runtime** dashboard shows other time series graphs that are important for CockroachDB developers:
-
-- Goroutine Count
-- GC Runs
-- GC Pause Time
-
-For monitoring CockroachDB, it is sufficient to use the [**Live Node Count**](#live-node-count), [**Memory Usage**](#memory-usage), [**CPU Time**](#cpu-time), and [**Clock Offset**](#clock-offset) graphs.
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-sql-dashboard.md b/src/current/v19.2/admin-ui-sql-dashboard.md
deleted file mode 100644
index e576c3052ed..00000000000
--- a/src/current/v19.2/admin-ui-sql-dashboard.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: SQL Dashboard
-summary: The SQL dashboard lets you monitor the performance of your SQL queries.
-toc: true
----
-
-The **SQL** dashboard in the CockroachDB Admin UI lets you monitor the performance of your SQL queries. To view this dashboard, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui), click **Metrics** on the left-hand navigation bar, and then select **Dashboard** > **SQL**.
-
-
-The **SQL** dashboard displays the following time series graphs:
-
-## SQL Connections
-
-
-
-- In the node view, the graph shows the number of connections currently open between the client and the selected node.
-
-- In the cluster view, the graph shows the total number of SQL client connections to all nodes combined.
-
-## SQL Byte Traffic
-
-
-
-The **SQL Byte Traffic** graph helps you correlate SQL query count to byte traffic, especially in bulk data inserts or analytic queries that return data in bulk.
-
-- In the node view, the graph shows the current byte throughput (bytes/second) between all the currently connected SQL clients and the node.
-
-- In the cluster view, the graph shows the aggregate client throughput across all nodes.
-
-## SQL Queries
-
-
-
-- In the node view, the graph shows the 10-second average of the number of SQL statements issued to the node that returned a [planning](architecture/sql-layer.html#sql-parser-planner-executor), [runtime](architecture/sql-layer.html#sql-parser-planner-executor), or [retry error](transactions.html#error-handling).
-
-- In the cluster view, the graph shows the 10-second average of the number of SQL statements that returned a [planning](architecture/sql-layer.html#sql-parser-planner-executor), [runtime](architecture/sql-layer.html#sql-parser-planner-executor), or [retry error](transactions.html#error-handling) across all nodes.
-
-## Service Latency: SQL, 99th percentile
-
-
-
-- In the node view, the graph shows the 10-second average of the number of opened, committed, aborted, and rolled back [transactions](transactions.html) per second issued by SQL clients on the node.
-
-- In the cluster view, the graph shows the sum of the per-node averages, that is, an aggregate estimation of the current [transactions](transactions.html) load over the cluster, assuming the last 10 seconds of activity per node are representative of this load.
-
-If the graph shows excessive aborts or rollbacks, it might indicate issues with the SQL queries. In that case, re-examine queries to lower contention.
-
-Additionally, per-application average transaction times are displayed for each node, at the 90th and 99th percentiles.
-
-
-
-## Other graphs
-
-The **SQL** dashboard shows other time series graphs that are important for CockroachDB developers:
-
-- KV Execution Latency
-- Active Distributed SQL Queries
-- Active Flows for Distributed SQL Queries
-- Service Latency: DistSQL
-- Schema Changes
-
-For monitoring CockroachDB, it is sufficient to use the [**SQL Connections**](#sql-connections), [**SQL Byte Traffic**](#sql-byte-traffic), [**SQL Queries**](#sql-queries), [**Service Latency**](#service-latency-sql-99th-percentile), and [**Transactions**](#transactions) graphs.
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/admin-ui-statements-page.md b/src/current/v19.2/admin-ui-statements-page.md
deleted file mode 100644
index fbb6e3d34d9..00000000000
--- a/src/current/v19.2/admin-ui-statements-page.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Statements Page
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-On a secure cluster, this area of the Admin UI can only be accessed by an `admin` user. See [Admin UI access](admin-ui-overview.html#admin-ui-access).
-{{site.data.alerts.end}}
-
-The **Statements** page helps you identify frequently executed or high latency [SQL statements](sql-statements.html). The **Statements** page also allows you to view the details of an individual SQL statement by clicking on the statement to view the **Statement Details** page.
-
-To view the **Statements** page, [access the Admin UI](admin-ui-access-and-navigate.html#access-the-admin-ui) and then click **Statements** on the left.
-
-
-
-## Limitation
-
-The **Statements** page displays the details of the SQL statements executed within a specified time interval. At the end of the interval, the display is wiped clean, and you'll not see any statements on the page until the next set of statements is executed. By default, the time interval is set to one hour; however, you can customize the interval using the [`diagnostics.reporting.interval`](cluster-settings.html#settings) cluster setting.
-
-## Filtering by application
-
-If you have multiple applications running on the cluster, the **Statements** page shows the statements from all of the applications by default. To view the statements pertaining to a particular application, select the [application name](connection-parameters.html#additional-connection-parameters) from the **App** dropdown menu. If you haven't set the application name in the connection string, it appears as `unset` in the dropdown menu.
-
-## Understanding the Statements page
-
-### SQL statement fingerprint
-
-The **Statements** page displays the details of SQL statement fingerprints instead of individual SQL statements.
-
-A statement fingerprint is a grouping of similar SQL statements in their abstracted form by replacing the literal values with underscores (`_`). Grouping similar SQL statements as fingerprints helps you quickly identify frequently executed SQL statements and their latencies.
-
-A statement fingerprint is generated when two or more statements are the same after any literal values in them (e.g.,numbers and strings) are replaced with underscores. For example, the following statements have the same once their numbers have been replaced with underscores:
-
-- `INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)`
-- `INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (192, 891, 20)`
-- `INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (784, 452, 78)`
-
-Thus, they can have the same fingerprint:
-
-`INSERT INTO new_order(product_id, customer_id, no_w_id) VALUES (_, _, _)`
-
-The following statements are different enough to not have the same fingerprint:
-
-- `INSERT INTO orders(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)`
-- `INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)`
-- `INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, 11, 11098)`
-- `INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, $2, 11098)`
-- `INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, $2, $3)`
-
-### Parameters
-
-The **Statements** page displays the time, execution count, number of [retries](transactions.html#transaction-retries), number of rows affected, and latency for each statement fingerprint. By default, the statement fingerprints are sorted by time; however, you can sort the table by execution count, retries, rows affected, and latency.
-
-The following details are provided for each statement fingerprint:
-
-Parameter | Description
------|------------
-Statement | The SQL statement or the fingerprint of similar SQL statements.
-
-### Logical plan
-
-The **Logical Plan** section displays CockroachDB's query plan for an [explainable statement](sql-grammar.html#preparable_stmt). You can then use this information to optimize the query. For more information about logical plans, see [`EXPLAIN`](explain.html).
-
-By default, the logical plan for each fingerprint is sampled every 5 minutes. You can use the `sql.metrics.statement_details.plan_collection.period` [cluster setting](cluster-settings.html) to change this time interval. For example, to change the interval to 2 minutes, run the following [`SET CLUSTER SETTING`](set-cluster-setting.html) command:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.metrics.statement_details.plan_collection.period = '2m0s';
-~~~
-
-### Latency by Phase
-
-The **Latency by Phase** table provides the mean value and one standard deviation of the mean value of the overall service latency as well as latency for each execution phase (parse, plan, run) for the SQL statement (or multiple statements having the same fingerprint). The table provides the service latency details in numerical values as well as color-coded bar graphs: blue indicates the mean value and yellow indicates one standard deviation of the mean value of latency.
-
-### Statistics by Gateway Node
-
-The **Statistics by Gateway Node** table provides a breakdown of the number of statements of the selected fingerprint per gateway node. For each gateway node, the table also provides the following details:
-
-Parameter | Description
------|------------
-Node | The ID of the gateway node.
-Time | The cumulative time taken to execute the statement within the last hour or the [specified time interval](#limitation).
-Execution Count | The total number of times the SQL statement (or multiple statements having the same fingerprint) is executed.
-Retries | The cumulative number of retries to execute the SQL statement (or multiple statements having the same fingerprint) within the last hour or the [specified time interval](#limitation).
-Rows Affected | The average number of rows returned while executing the SQL statement (or multiple statements having the same fingerprint) within the last hour or the [specified time interval](#limitation). 
-
-- In the node view, the graph shows the number of open file descriptors for that node, compared with the file descriptor limit.
-
-- In the cluster view, the graph shows the number of open file descriptors across all nodes, compared with the file descriptor limit.
-
-If the Open count is almost equal to the Limit count, increase [File Descriptors](recommended-production-settings.html#file-descriptors-limit).
-
-{{site.data.alerts.callout_info}}
-If you are running multiple nodes on a single machine (not recommended), the actual number of open file descriptors are considered open on each node. Thus the limit count value displayed on the Admin UI is the actual value of open file descriptors multiplied by the number of nodes, compared with the file descriptor limit.
-{{site.data.alerts.end}}
-
-For Windows systems, you can ignore the File Descriptors graph because the concept of file descriptors is not applicable to Windows.
-
-## Other graphs
-
-The **Storage** dashboard shows other time series graphs that are important for CockroachDB developers:
-
-- Live Bytes
-- Log Commit Latency
-- Command Commit Latency
-- Read Amplification
-- SSTables
-- Compactions/Flushes
-- Time Series Writes
-- Time Series Bytes Written
-
-For monitoring CockroachDB, it is sufficient to use the [**Capacity**](#capacity) and [**File Descriptors**](#file-descriptors) graphs.
-
-## See also
-
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v19.2/advanced-client-side-transaction-retries.md b/src/current/v19.2/advanced-client-side-transaction-retries.md
deleted file mode 100644
index 6657a4c0385..00000000000
--- a/src/current/v19.2/advanced-client-side-transaction-retries.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: Advanced Client-side Transaction Retries
-summary: Advanced client-side transaction retry features for library authors
-toc: true
----
-
-This page has instructions for authors of [database drivers and ORMs](install-client-drivers.html) who would like to implement client-side retries in their database driver or ORM for maximum efficiency and ease of use by application developers.
-
-{{site.data.alerts.callout_info}}
-If you are an application developer who needs to implement an application-level retry loop, see the [Client-side intervention example](transactions.html#client-side-intervention-example).
-{{site.data.alerts.end}}
-
-## Overview
-
-To improve the performance of transactions that fail due to contention, CockroachDB includes a set of statements (listed below) that let you retry those transactions. Retrying transactions using these statements has the following benefits:
-
-1. When you use savepoints, you "hold your place in line" between attempts. Without savepoints, you're starting from scratch every time.
-2. Transactions increase their priority each time they're retried, increasing the likelihood they will succeed. This has a lesser effect than #1.
-
-## How transaction retries work
-
-A retryable transaction goes through the process described below, which maps to the following SQL statements:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN; -- #1
-> SAVEPOINT cockroach_restart; -- #2
--- ... various transaction statements ... -- #3
-> RELEASE SAVEPOINT cockroach_restart; -- #5 (Or #4, ROLLBACK, in case of retry error)
-> COMMIT;
-~~~
-
-1. The transaction starts with the [`BEGIN`](begin-transaction.html) statement.
-
-2. The [`SAVEPOINT`](savepoint.html) statement declares the intention to retry the transaction in the case of contention errors. Note that CockroachDB's savepoint implementation does not support all savepoint functionality, such as nested transactions. It must be executed after [`BEGIN`](begin-transaction.html) but before the first statement that manipulates a database.
-
-3. The statements in the transaction are executed.
-
-4. If a statement returns a retry error (identified via the `40001` error code or `"retry transaction"` string at the start of the error message), you can issue the [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html) statement to restart the transaction and increase the transaction's priority. Alternately, the original [`SAVEPOINT`](savepoint.html) statement can be reissued to restart the transaction.
-
- You must now issue the statements in the transaction again.
-
- In cases where you do not want the application to retry the transaction, you can simply issue [`ROLLBACK`](rollback-transaction.html) at this point. Any other statements will be rejected by the server, as is generally the case after an error has been encountered and the transaction has not been closed.
-
-5. Once the transaction executes all statements without encountering contention errors, execute [`RELEASE SAVEPOINT`](release-savepoint.html) to commit the changes. If this succeeds, all changes made by the transaction become visible to subsequent transactions and are guaranteed to be durable if a crash occurs.
-
- In some cases, the [`RELEASE SAVEPOINT`](release-savepoint.html) statement itself can fail with a retry error, mainly because transactions in CockroachDB only realize that they need to be restarted when they attempt to commit. If this happens, the retry error is handled as described in step 4.
-
-## Customizing the savepoint name
-
-{% include {{ page.version.version }}/misc/customizing-the-savepoint-name.md %}
-
-## Examples
-
-For examples showing how to use [`SAVEPOINT`](savepoint.html) and the other statements described on this page to implement library support for a programming language, see the following:
-
-- [Build a Java app with CockroachDB](build-a-java-app-with-cockroachdb.html), in particular the logic in the `runSQL` method.
-- The source code of the [sqlalchemy-cockroachdb](https://github.com/cockroachdb/sqlalchemy-cockroachdb) adapter for SQLAlchemy.
-
-## See also
-
-- [Transactions](transactions.html)
-- [`BEGIN`](begin-transaction.html)
-- [`COMMIT`](commit-transaction.html)
-- [`ROLLBACK`](rollback-transaction.html)
-- [`SAVEPOINT`](savepoint.html)
-- [`RELEASE SAVEPOINT`](release-savepoint.html)
-- [`SHOW`](show-vars.html)
-- [CockroachDB Architecture: Transaction Layer](architecture/transaction-layer.html)
diff --git a/src/current/v19.2/alter-column.md b/src/current/v19.2/alter-column.md
deleted file mode 100644
index 549cdf59f30..00000000000
--- a/src/current/v19.2/alter-column.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: ALTER COLUMN
-summary: Use the ALTER COLUMN statement to set, change, or drop a column's DEFAULT constraint or to drop the NOT NULL constraint.
-toc: true
----
-
-The `ALTER COLUMN` [statement](sql-statements.html) is part of `ALTER TABLE` and can be used to:
-
-- Set, change, or drop a column's [`DEFAULT` constraint](default-value.html)
-- Set or drop a column's [`NOT NULL` constraint](not-null.html)
-- Increase the precision of the column's [data type](data-types.html)
-
-{{site.data.alerts.callout_info}}
-To manage other constraints, see [`ADD CONSTRAINT`](add-constraint.html) and [`DROP CONSTRAINT`](drop-constraint.html).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-
-
-In this case:
-
-1. Node 2 (the gateway node) receives the request to read from table 3.
-2. The leaseholder for table 3 is on node 3, so the request is routed there.
-3. Node 3 returns the data to node 2.
-4. Node 2 responds to the client.
-
-If the query is received by the node that has the leaseholder for the relevant range, there are fewer network hops:
-
-
-
-## Write scenario
-
-Now imagine a simple write scenario where a query is executed against node 3 to write to table 1:
-
-
-
-In this case:
-
-1. Node 3 (the gateway node) receives the request to write to table 1.
-2. The leaseholder for table 1 is on node 1, so the request is routed there.
-3. The leaseholder is the same replica as the Raft leader (as is typical), so it simultaneously appends the write to its own Raft log and notifies its follower replicas on nodes 2 and 3.
-4. As soon as one follower has appended the write to its Raft log (and thus a majority of replicas agree based on identical Raft logs), it notifies the leader and the write is committed to the key-values on the agreeing replicas. In this diagram, the follower on node 2 acknowledged the write, but it could just as well have been the follower on node 3. Also note that the follower not involved in the consensus agreement usually commits the write very soon after the others.
-5. Node 1 returns acknowledgement of the commit to node 3.
-6. Node 3 responds to the client.
-
-Just as in the read scenario, if the write request is received by the node that has the leaseholder and Raft leader for the relevant range, there are fewer network hops:
-
-
-
-## Network and I/O bottlenecks
-
-With the above examples in mind, it's always important to consider network latency and disk I/O as potential performance bottlenecks. In summary:
-
-- For reads, hops between the gateway node and the leaseholder add latency.
-- For writes, hops between the gateway node and the leaseholder/Raft leader, and hops between the leaseholder/Raft leader and Raft followers, add latency. In addition, since Raft log entries are persisted to disk before a write is committed, disk I/O is important.
diff --git a/src/current/v19.2/architecture/replication-layer.md b/src/current/v19.2/architecture/replication-layer.md
deleted file mode 100644
index 5bf02f973db..00000000000
--- a/src/current/v19.2/architecture/replication-layer.md
+++ /dev/null
@@ -1,154 +0,0 @@
----
-title: Replication Layer
-summary: The replication layer of CockroachDB's architecture copies data between nodes and ensures consistency between copies.
-toc: true
----
-
-The replication layer of CockroachDB's architecture copies data between nodes and ensures consistency between these copies by implementing our consensus algorithm.
-
-{{site.data.alerts.callout_info}}
-If you haven't already, we recommend reading the [Architecture Overview](overview.html).
-{{site.data.alerts.end}}
-
-## Overview
-
-High availability requires that your database can tolerate nodes going offline without interrupting service to your application. This means replicating data between nodes to ensure the data remains accessible.
-
-Ensuring consistency with nodes offline, though, is a challenge many databases fail. To solve this problem, CockroachDB uses a consensus algorithm to require that a quorum of replicas agrees on any changes to a range before those changes are committed. Because 3 is the smallest number that can achieve quorum (i.e., 2 out of 3), CockroachDB's high availability (known as multi-active availability) requires 3 nodes.
-
-The number of failures that can be tolerated is equal to *(Replication factor - 1)/2*. For example, with 3x replication, one failure can be tolerated; with 5x replication, two failures, and so on. You can control the replication factor at the cluster, database, and table level using [replication zones](../configure-replication-zones.html).
-
-When failures happen, though, CockroachDB automatically realizes nodes have stopped responding and works to redistribute your data to continue maximizing survivability. This process also works the other way around: when new nodes join your cluster, data automatically rebalances onto it, ensuring your load is evenly distributed.
-
-### Interactions with other layers
-
-In relationship to other layers in CockroachDB, the replication layer:
-
-- Receives requests from and sends responses to the distribution layer.
-- Writes accepted requests to the storage layer.
-
-## Components
-
-### Raft
-
-Raft is a consensus protocol––an algorithm which makes sure that your data is safely stored on multiple machines, and that those machines agree on the current state even if some of them are temporarily disconnected.
-
-Raft organizes all nodes that contain a replica of a range into a group--unsurprisingly called a Raft group. Each replica in a Raft group is either a "leader" or a "follower". The leader, which is elected by Raft and long-lived, coordinates all writes to the Raft group. It heartbeats followers periodically and keeps their logs replicated. In the absence of heartbeats, followers become candidates after randomized election timeouts and proceed to hold new leader elections.
-
-Once a node receives a `BatchRequest` for a range it contains, it converts those KV operations into Raft commands. Those commands are proposed to the Raft group leader––which is what makes it ideal for the [leaseholder](#leases) and the Raft leader to be one in the same––and written to the Raft log.
-
-For a great overview of Raft, we recommend [The Secret Lives of Data](http://thesecretlivesofdata.com/raft/).
-
-#### Raft logs
-
-When writes receive a quorum, and are committed by the Raft group leader, they're appended to the Raft log. This provides an ordered set of commands that the replicas agreed on and is essentially the source of truth for consistent replication.
-
-Because this log is treated as serializable, it can be replayed to bring a node from a past state to its current state. This log also lets nodes that temporarily went offline to be "caught up" to the current state without needing to receive a copy of the existing data in the form of a snapshot.
-
-### Snapshots
-
-Each replica can be "snapshotted", which copies all of its data as of a specific timestamp (available because of [MVCC](storage-layer.html#mvcc)). This snapshot can be sent to other nodes during a rebalance event to expedite replication.
-
-After loading the snapshot, the node gets up to date by replaying all actions from the Raft group's log that have occurred since the snapshot was taken.
-
-### Leases
-
-A single node in the Raft group acts as the leaseholder, which is the only node that can serve reads or propose writes to the Raft group leader (both actions are received as `BatchRequests` from [`DistSender`](distribution-layer.html#distsender)).
-
-When serving reads, leaseholders bypass Raft; for the leaseholder's writes to have been committed in the first place, they must have already achieved consensus, so a second consensus on the same data is unnecessary. This has the benefit of not incurring networking round trips required by Raft and greatly increases the speed of reads (without sacrificing consistency).
-
-CockroachDB attempts to elect a leaseholder who is also the Raft group leader, which can also optimize the speed of writes.
-
-If there is no leaseholder, any node receiving a request will attempt to become the leaseholder for the range. To prevent two nodes from acquiring the lease, the requester includes a copy of the last valid lease it had; if another node became the leaseholder, its request is ignored.
-
-#### Co-location with Raft leadership
-
-The range lease is completely separate from Raft leadership, and so without further efforts, Raft leadership and the Range lease might not be held by the same replica. However, we can optimize query performance by making the same node both Raft leader and the leaseholder; it reduces network round trips if the leaseholder receiving the requests can simply propose the Raft commands to itself, rather than communicating them to another node.
-
-To achieve this, each lease renewal or transfer also attempts to collocate them. In practice, that means that the mismatch is rare and self-corrects quickly.
-
-#### Epoch-based leases (table data)
-
-To manage leases for table data, CockroachDB implements a notion of "epochs," which are defined as the period between a node joining a cluster and a node disconnecting from a cluster. To extend its leases, each node must periodically update its liveness record, which is stored on a system range key. When a node disconnects, it stops updating the liveness record, and the epoch is considered changed. This causes the node to immediately lose all of its leases.
-
-Because leases do not expire until a node disconnects from a cluster, leaseholders do not have to individually renew their own leases. Tying lease lifetimes to node liveness in this way lets us eliminate a substantial amount of traffic and Raft processing we would otherwise incur, while still tracking leases for every range.
-
-#### Expiration-based leases (meta and system ranges)
-
-A table's meta and system ranges (detailed in the [distribution layer](distribution-layer.html#meta-ranges)) are treated as normal key-value data, and therefore have leases just like table data.
-
-However, unlike table data, system ranges cannot use epoch-based leases because that would create a circular dependency: system ranges are already being used to implement epoch-based leases for table data. Therefore, system ranges use expiration-based leases instead. Expiration-based leases expire at a particular timestamp (typically after a few seconds). However, as long as a node continues proposing Raft commands, it continues to extend the expiration of its leases. If it doesn't, the next node containing a replica of the range that tries to read from or write to the range will become the leaseholder.
-
-#### Leaseholder rebalancing
-
-Because CockroachDB serves reads from a range's leaseholder, it benefits your cluster's performance if the replica closest to the primary geographic source of traffic holds the lease. However, as traffic to your cluster shifts throughout the course of the day, you might want to dynamically shift which nodes hold leases.
-
-{{site.data.alerts.callout_info}}
-
-This feature is also called [Follow-the-Workload](../demo-follow-the-workload.html) in our documentation.
-
-{{site.data.alerts.end}}
-
-Periodically (every 10 minutes by default in large clusters, but more frequently in small clusters), each leaseholder considers whether it should transfer the lease to another replica by considering the following inputs:
-
-- Number of requests from each locality
-- Number of leases on each node
-- Latency between localities
-
-##### Intra-locality
-
-If all the replicas are in the same locality, the decision is made entirely on the basis of the number of leases on each node that contains a replica, trying to achieve a roughly equitable distribution of leases across all of them. This means the distribution isn't perfectly equal; it intentionally tolerates small deviations between nodes to prevent thrashing (i.e., excessive adjustments trying to reach an equilibrium).
-
-##### Inter-locality
-
-If replicas are in different localities, CockroachDB attempts to calculate which replica would make the best leaseholder, i.e., provide the lowest latency.
-
-To enable dynamic leaseholder rebalancing, a range's current leaseholder tracks how many requests it receives from each locality as an exponentially weighted moving average. This calculation results in the locality that has recently requested the range most often being assigned the greatest weight. If another locality then begins requesting the range very frequently, this calculation would shift to assign the second region the greatest weight.
-
-When checking for leaseholder rebalancing opportunities, the leaseholder correlates each requesting locality's weight (i.e., the proportion of recent requests) to the locality of each replica by checking how similar the localities are. For example, if the leaseholder received requests from gateway nodes in locality `country=us,region=central`, CockroachDB would assign the following weights to replicas in the following localities:
-
-Replica locality | Replica rebalancing weight
------------------|-------------------
-`country=us,region=central` | 100% because it is an exact match
-`country=us,region=east` | 50% because only the first locality matches
-`country=aus,region=central` | 0% because the first locality does not match
-
-The leaseholder then evaluates its own weight and latency versus the other replicas to determine an adjustment factor. The greater the disparity between weights and the larger the latency between localities, the more CockroachDB favors the node from the locality with the larger weight.
-
-When checking for leaseholder rebalancing opportunities, the current leaseholder evaluates each replica's rebalancing weight and adjustment factor for the localities with the greatest weights. If moving the leaseholder is both beneficial and viable, the current leaseholder will transfer the lease to the best replica.
-
-##### Controlling leaseholder rebalancing
-
-You can control leaseholder rebalancing through the `kv.allocator.load_based_lease_rebalancing.enabled` and `kv.allocator.lease_rebalancing_aggressiveness` [cluster settings](../cluster-settings.html). Note that depending on the needs of your deployment, you can exercise additional control over the location of leases and replicas by [configuring replication zones](../configure-replication-zones.html).
-
-### Membership changes: rebalance/repair
-
-Whenever there are changes to a cluster's number of nodes, the members of Raft groups change and, to ensure optimal survivability and performance, replicas need to be rebalanced. What that looks like varies depending on whether the membership change is nodes being added or going offline.
-
-- **Nodes added**: The new node communicates information about itself to other nodes, indicating that it has space available. The cluster then rebalances some replicas onto the new node.
-
-- **Nodes going offline**: If a member of a Raft group ceases to respond, after 5 minutes, the cluster begins to rebalance by replicating the data the downed node held onto other nodes.
-
-Rebalancing is achieved by using a snapshot of a replica from the leaseholder, and then sending the data to another node over [gRPC](distribution-layer.html#grpc). After the transfer has been completed, the node with the new replica joins that range's Raft group; it then detects that its latest timestamp is behind the most recent entries in the Raft log and it replays all of the actions in the Raft log on itself.
-
-#### Load-based replica rebalancing
-
-In addition to the rebalancing that occurs when nodes join or leave a cluster, replicas are also rebalanced automatically based on the relative load across the nodes within a cluster. For more information, see the `kv.allocator.load_based_rebalancing` and `kv.allocator.qps_rebalance_threshold` [cluster settings](../cluster-settings.html). Note that depending on the needs of your deployment, you can exercise additional control over the location of leases and replicas by [configuring replication zones](../configure-replication-zones.html).
-
-## Interactions with other layers
-
-### Replication and distribution layers
-
-The replication layer receives requests from its and other nodes' `DistSender`. If this node is the leaseholder for the range, it accepts the requests; if it isn't, it returns an error with a pointer to which node it believes *is* the leaseholder. These KV requests are then turned into Raft commands.
-
-The replication layer sends `BatchResponses` back to the distribution layer's `DistSender`.
-
-### Replication and storage layers
-
-Committed Raft commands are written to the Raft log and ultimately stored on disk through the storage layer.
-
-The leaseholder serves reads from its RocksDB instance, which is in the storage layer.
-
-## What's next?
-
-Learn how CockroachDB reads and writes data from disk in the [storage layer](storage-layer.html).
diff --git a/src/current/v19.2/architecture/sql-layer.md b/src/current/v19.2/architecture/sql-layer.md
deleted file mode 100644
index a700074aa29..00000000000
--- a/src/current/v19.2/architecture/sql-layer.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: SQL Layer
-summary: The SQL layer of CockroachDB's architecture exposes its SQL API to developers and converts SQL statements into key-value operations.
-toc: true
----
-
-The SQL layer of CockroachDB's architecture exposes its SQL API to developers and converts SQL statements into key-value operations used by the rest of the database.
-
-{{site.data.alerts.callout_info}}
-If you haven't already, we recommend reading the [Architecture Overview](overview.html).
-{{site.data.alerts.end}}
-
-## Overview
-
-Once CockroachDB has been deployed, developers need nothing more than a connection string to the cluster and SQL statements to start working.
-
-Because CockroachDB's nodes all behave symmetrically, developers can send requests to any node (which means CockroachDB works well with load balancers). Whichever node receives the request acts as the "gateway node," as other layers process the request.
-
-When developers send requests to the cluster, they arrive as SQL statements, but data is ultimately written to and read from the storage layer as key-value (KV) pairs. To handle this, the SQL layer converts SQL statements into a plan of KV operations, which it passes along to the transaction layer.
-
-### Interactions with other layers
-
-In relationship to other layers in CockroachDB, the SQL layer:
-
-- Sends requests to the transaction layer.
-
-## Components
-
-### Relational structure
-
-Developers experience data stored in CockroachDB in a relational structure, i.e., rows and columns. Sets of rows and columns are organized into tables. Collections of tables are organized into databases. Your cluster can contain many databases.
-
-Because of this structure, CockroachDB provides typical relational features like constraints (e.g., foreign keys). This lets application developers trust that the database will ensure consistent structuring of the application's data; data validation doesn't need to be built into the application logic separately.
-
-### SQL API
-
-CockroachDB implements a large portion of the ANSI SQL standard to manifest its relational structure. You can view [all of the SQL features CockroachDB supports here](../sql-feature-support.html).
-
-Importantly, through the SQL API, we also let developers use ACID-semantic transactions like they would through any SQL database (`BEGIN`, `END`, `COMMIT`, etc.)
-
-### PostgreSQL wire protocol
-
-SQL queries reach your cluster through the PostgreSQL wire protocol. This makes connecting your application to the cluster simple by supporting most PostgreSQL-compatible drivers, as well as many PostgreSQL ORMs, such as GORM (Go) and Hibernate (Java).
-
-### SQL parser, planner, executor
-
-After your node ultimately receives a SQL request from a client, CockroachDB parses the statement, [creates a query plan](../cost-based-optimizer.html), and then executes the plan.
-
-#### Parsing
-
-Received queries are parsed against our `yacc` file (which describes our supported syntax), and converts the string version of each query into [abstract syntax trees](https://en.wikipedia.org/wiki/Abstract_syntax_tree) (AST).
-
-#### Logical planning
-
-The AST is subsequently transformed into a query plan in three phases:
-
-1. The AST is transformed into a high-level logical query plan. During this transformation, CockroachDB also performs [semantic analysis](https://en.wikipedia.org/wiki/Semantic_analysis_(compilers)), which includes checking whether the query is valid, resolving names, eliminating unneeded intermediate computations, and finalizing which data types to use for intermediate results.
-
-2. The logical plan is *simplified* using transformation optimizations that are always valid.
-
-3. The logical plan is *optimized* using a [search algorithm](../cost-based-optimizer.html) that evaluates many possible ways to execute a query and selects an execution plan with the least costs.
-
-The result of the optimization phase is an optimized logical plan. This can be observed with [`EXPLAIN`](../explain.html).
-
-#### Physical planning
-
-The physical planning phase decides which nodes will participate in
-the execution of the query, based on range locality information. This
-is where CockroachDB decides to distribute a query to perform some
-computations close to where the data is stored.
-
-The result of physical planning is a physical plan and can be observed
-with [`EXPLAIN(DISTSQL)`](../explain.html).
-
-#### Query execution
-
-Components of the physical plan are sent to one or more nodes for execution. On each node, CockroachDB spawns a *logical processor* to compute a part of the query. Logical processors inside or across nodes communicate with each other over a *logical flow* of data. The combined results of the query are sent back to the first node where the query was received, to be sent further to the SQL client.
-
-Each processor uses an encoded form for the scalar values manipulated by the query. This is a binary form which is different from that used in SQL. So the values listed in the SQL query must be encoded, and the data communicated between logical processors, and read from disk, must be decoded before it is sent back to the SQL client.
-
-#### Vectorized query execution
-
-