diff --git a/src/current/Gemfile b/src/current/Gemfile
index de20eb2bc1d..f8d0601daa8 100644
--- a/src/current/Gemfile
+++ b/src/current/Gemfile
@@ -13,7 +13,9 @@ gem "redcarpet", "~> 3.6"
 gem "rss"
 gem "webrick"
 gem "jekyll-minifier"
-
+gem "csv"
+gem "base64"
+gem "bigdecimal"
 group :jekyll_plugins do
     gem "jekyll-include-cache"
     gem 'jekyll-algolia', "~> 1.0", path: "./jekyll-algolia-dev"
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-alpha.1.md b/src/current/_includes/releases/v20.2/v20.2.0-alpha.1.md
deleted file mode 100644
index 3c5ddaefaca..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-alpha.1.md
+++ /dev/null
@@ -1,774 +0,0 @@
-## v20.2.0-alpha.1
-
-Release Date: June 17, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-alpha-1-backward-incompatible-changes">Backward-incompatible changes</h3>
-
-- The textual error and warning messages displayed by [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) under various circumstances have been updated. Meanwhile, the message "`ok`" remains as an indicator that the operation has likely succeeded. [#45149][#45149]
-- [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) now prints out progress details on its standard error stream, even when `--logtostderr` is not specified. Previously, nothing was printed on standard error. Scripts that wish to ignore this output can redirect the stderr stream. [#45149][#45149]
-- The copy of system and `crdb_internal` tables extracted by [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) is now written using the TSV format (inside the zip file), instead of an ASCII-art table as previously. [#48096][#48096]
-- CockroachDB v20.1 introduced a new rule for the `--join` flag to [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start), causing it to prefer SRV records, if present in DNS, to look up the peer nodes to join. This feature is experimental, and has been found to cause disruption in certain deployments. To reduce this disruption and the resulting UX surprise, the feature is now gated behind a new command-line flag `--experimental-dns-srv` which must now be explicitly passed to [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) to enable it. [#49077][#49077]
-- Prior to this patch, the phase of server shutdown responsible for range lease transfers to other nodes would give up after 10000 attempts of transferring replica leases away, regardless of the value of `server.shutdown.lease_transfer_wait`. The limit of 10000 attempts has been removed, so that now only the maximum duration `server.shutdown.lease_transfer_wait` applies. [#45149][#45149]
-
-<h3 id="v20-2-0-alpha-1-general-changes">General changes</h3>
-
-- Transactions reading a lot of data behave better when exceeding the memory limit set by `kv.transaction.max_refresh_spans_bytes`. Such transactions now attempt to resolve the conflicts they run into instead of being forced to always retry. Increasing `kv.transaction.max_refresh_spans_bytes` should no longer be necessary for most workloads. [#46275][#46275]
-- Schema changes started in 19.2 will now be automatically migrated in the background in 20.1 after upgrade finalization so that they can run to completion. [#46504][#46504]
-- Prior to this patch, the phase of server shutdown responsible for range lease transfers to other nodes had a hard timeout of 5 seconds. This patch makes this timeout configurable via the new [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `server.shutdown.lease_transfer_wait`. [#45149][#45149]
-- [Statement diagnostics zip bundles](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page) now contain a representation of the statement trace that can be imported into [Jaeger](https://www.jaegertracing.io) for visualization. [#47303][#47303]
-- The `system.replication_constraint_stats` report now treats conjunctions of [replication constraints](https://www.cockroachlabs.com/docs/v20.2/configure-replication-zones) as a single unit of reporting, whereas before there was a report entry for each constraint in the conjunction. For example, given a zone with a replication constraint like `{"+region=us,+az=az1":1}` (meaning, one replica in a node with locality `region=us,az=az1`), now there will be a report entry for `"+region=us,+az=az1"` where before there was a separate entry for `"+region=us"` and another one for `"+az=az1"`. [#47389][#47389]
-- The Kubernetes manifests now generate node certificates with additional addresses `'cockroachdb-public.<namespace>'` and `'cockroachdb-public.<namespace>.svc'`. [#47610][#47610]
-- Changed the default engine type for new storage directories from RocksDB to Pebble. Existing stores will continue to use the previously specified storage engine, and an explicit specification (via `--storage-engine=...`) will override the default. [#48145][#48145]
-- Removed the publication of [musl libc](https://www.musl-libc.org) CockroachDB builds. [#49685][#49685]
-- Improved error reporting when trying to access non-existent Google Cloud storage blobs. [#49089][#49089]
-- Improved reliability by handling interrupted downloads from Google Cloud external storage more gracefully. [#48229][#48229]
-- Treat errors due to draining nodes as retryable when starting CDC. [#49743][#49743]
-
-<h3 id="v20-2-0-alpha-1-enterprise-edition-changes">Enterprise edition changes</h3>
-
-- [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) and [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) now collect some anonymous telemetry on throughput and feature usage. [#46716][#46716]
-- [`SHOW BACKUP`](https://www.cockroachlabs.com/docs/v20.2/show-backup) now shows whether a [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) is a full cluster backup or not. [#45860][#45860]
-- The privileges assigned to a given table/database are now visible through [`SHOW BACKUP`](https://www.cockroachlabs.com/docs/v20.2/show-backup). `SHOW BACKUP` will list which users and roles had which privileges on each table/database in the backup if the `WITH privileges` option is specified. [#45862][#45862]
-- The new appended [incremental backup](https://www.cockroachlabs.com/docs/v20.2/backup#incremental-backups) syntax does not allow converting a full cluster backup to a specific table or database backup. [#46864][#46864]
-- [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) and [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) to HTTP storage locations now require explicitly specifying incremental storage locations (i.e., cannot use the new automatically appended incremental syntax). [#46887][#46887]
-- Fixed a bug where the job ID of a lagging changefeed would be omitted and instead it would be reported as sinkless. [#48493][#48493]
-- Changefeeds now retry after encountering transient errors contacting the Confluent Schema Registry. [#48759][#48759]
-
-<h3 id="v20-2-0-alpha-1-sql-language-changes">SQL language changes</h3>
-
-<h4 id="v20-2-0-alpha-1-geospatial-sql-updates">Geospatial SQL updates</h4>
-
-- Introduced the ability to parse, store, and display PostGIS style `GEOGRAPHY` and `GEOMETRY` types. [#47171][#47171]
-- When doing name resolution via search path, the `pg_extension` schema (containing tables such as `geometry_columns`, `geography_columns` and `spatial_ref_sys`) will now have an attempted resolution before the `public` schema. This mimics PostGIS behavior where the aforementioned tables are in the public schema, and so by default are discoverable tables with a new CLI session. [#49611][#49611]
-- Added support for the `AddGeometryColumn` function, which adds a new `GEOMETRY` column to an existing table and returns metadata about the column created. This improves compatibility with PostGIS. [#49456][#49456]
-- Added support for `ST_Covers`, `ST_CoveredBy`, `ST_Contains`, `ST_Crosses`, `ST_Equals`, `ST_Intersects`, `ST_Overlaps`, `ST_Touches` and `ST_Within` for `GEOMETRY` geospatial types. [#47584][#47584]
-- Added the following geospatial functions: `ST_GeomFromText`, `ST_GeometryFromText`, `ST_GeogFromText`, `ST_GeographyFromText`, `ST_GeomFromWKB`, `ST_GeomFromEWKB`, `ST_GeomFromEWKT`, `ST_GeomFromGeoJSON`, `ST_GeogFromWKB`, `ST_GeogFromEWKB`, `ST_GeogFromEWKT`, `ST_GeogFromGeoJSON`, `ST_AsText`, `ST_AsBinary`, `ST_AsEWKB`, `ST_AsEWKT`, `ST_AsKML`, `ST_AsGeoJSON`. [#48015][#48015]
-- Added geospatial functions `ST_Area`, `ST_Length`, `ST_Distance`, and `ST_Perimeter`, which operate on `GEOMETRY` data types. [#48074][#48074]
-- Added built-ins allowing parsing text and WKB for all supported shapes, e.g., `ST_PointFromWKB` and `ST_PointFromText`, which return _NULL_ if the WKT/EWKT/WKB do not match the shape provided. [#48441][#48441]
-- Implemented the `GEOMETRY` based built-ins `ST_Relate` and `ST_ContainsProperly`. [#48552][#48552]
-- Introduced the following functions that work on `GEOGRAPHY` types: `ST_Covers`, `ST_CoveredBy`, `ST_Intersects`, `ST_Distance`, `ST_DWithin`, `ST_Perimeter`, `ST_Area`, and `ST_Length`. [#48529][#48529]
-- Implemented the `GEOMETRY` based built-in `ST_SRID`. [#49169][#49169]
-- Implemented the `ST_Point` and `ST_MakePoint` functions. [#49194][#49194]
-- Implemented the `ST_SetSRID` function on `GEOMETRY` and `GEOGRAPHY` types. [#49222][#49222]
-- Implemented the `ST_MaxDistance` and `ST_DFullyWithin` functions for geometries. [#49094][#49094]
-- Implemented the `ST_WKBToSQL` and `ST_WKTToSQL` geospatial functions. [#49237][#49237]
-- Implemented the `GEOMETRY` based built-in `ST_AsBinary` with encoding. [#49481][#49481]
-- Implemented the following geospatial built-ins: `ST_X` (resolves #49069), `ST_Y` (resolves #49070), `ST_NDims` (resolves #48992), `ST_NumPoints` (resolves #49001), `ST_NPoints` (resolves #48995), `ST_StartPoint` (resolves #49047), `ST_EndPoint` (resolves #48924), `ST_NumInteriorRings` (resolves #48999), `ST_NumInteriorRing` (resolves #48998), `ST_InteriorRingN` (resolves #48949), `ST_ExteriorRing` (resolves #48930), `ST_NumGeometries` (resolves #48997), `ST_GeometryN` (resolves #48945). [#49341][#49341]
-- Implemented the `ST_Centroid` built-in function which works for `GEOMETRY` and [`STRING`](https://www.cockroachlabs.com/docs/v20.2/string) arguments. [#49613][#49613]
-- Implemented the `GEOMETRY` built-in `ST_AsHexEWKB` with encoding. [#49644][#49644]
-- Implemented the following built-ins available on `GEOMETRY` types: `ST_Area2D` (resolves #48869), `ST_NRings` (resolves #48996), `ST_PointN` (resolves #49008), and `ST_GeometryType` (resolves #48946). [#49649][#49649]
-- Implemented the `GEOMETRY` based built-in `ST_Summary`. [#49738][#49738]
-- Implemented `ST_Buffer` for `GEOMETRY` and [`STRING`](https://www.cockroachlabs.com/docs/v20.2/string) variants. [#49722][#49722]
-- Implemented the following built-in functions: `ST_LineInterpolatePoint`, `ST_LineInterpolatePoints`. [#49742][#49742]
-- Implemented `DWithin` for `GEOMETRY` types. [#49085][#49085]
-- Populated the `pg_extension.geometry_columns` and `pg_extension.geography_columns` virtual table with metadata for tables which store have columns relevant to `GEOMETRY` or `GEOGRAPHY` data types. [#49424][#49424]
-
-<h4 id="v20-2-0-alpha-1-general-sql-updates">General SQL updates</h4>
-
-- Updated the type checking code to prefer aggregate overloads with string inputs if there are multiple possible candidates due to arguments of unknown type. [#46649][#46649]
-- Added syntax for `DECLARE` and `CLOSE`. `CLOSE ALL` is a no-op, as there are no cursors to close. `CLOSE <cursor>` and `DECLARE` raise unimplemented errors. [#45662][#45662]
-- Modified the `substring()` function to allow it support bit and byte arrays. [#46710][#46710]
-- Added support for `CREATE INDEX CONCURRENTLY` and `DROP INDEX CONCURRENTLY` syntax. These statements are no-ops, as all indexes are created concurrently. [#46695][#46695]
-- Previously, we implemented the timezone built-in as `timezone(<time type>, <timezone>)`. However, this is the opposite from the Postgres implementation (which allowed `timezone(<timezone>, <time type>`). In 20.1, we supported both permutations to aid with this migration, but with this change we will only support the timezone first. You can also use `AT TIME ZONE`, which is compatible with the `timezone` function in all versions. [#46748][#46748]
-- The [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/backup) statement now records some additional anonymous telemetry about its performance and reliability. [#46731][#46731]
-- Removed the output showing the number of rows reported as affected by the [`CREATE`/`ALTER`/`DROP ROLE`](https://www.cockroachlabs.com/docs/v20.2/authorization) statements. The number doesn't make sense to include. Since the rows affected include some rows in system tables such as `system.role_options` rows, this number can be misleading (e.g., `CREATE ROLE` returning `3`). This behavior matches Postgres, where no number is returned for these commands. [#46795][#46795]
-- Added a hint to use [`ALTER ROLE`](https://www.cockroachlabs.com/docs/v20.2/alter-role) when trying to "grant" a role option directly to a user (using the `GRANT ROLE` syntax). [#46795][#46795]
-- Added a new unimplemented error that is signalled when attempting to [`ADD CONSTRAINT`](https://www.cockroachlabs.com/docs/v20.2/add-constraint) with the `EXCLUDE USING` syntax. [#46787][#46787]
-- Added support for using `CREATE INDEX .... INCLUDE (col1, col2, ...)`, which is an alias that PostgreSQL uses that is analogous to our `STORING (col1, col2, ...)` syntax. [#46785][#46785]
-- Added support for parsing the `REINDEX` syntax, which results in an unimplemented error that explains that `REINDEX`ing is not required in CockroachDB. [#46850][#46850]
-- The [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) engine will only run queries with streaming operators. Issue `SET vectorize=on` to enable the vectorized execution engine for buffering operators. [#46845][#46845]
-- Added support for compressing output files using gzip. [#46932][#46932]
-- If setting an invalid [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings), the invalid values are now returned. [#46932][#46932]
-- CockroachDB will now be more verbose about full scans when executing [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain). Previously, we would output `SPANS | ALL`, now it will be `SPANS | FULL SCAN` or (if there is a limit) `SPANS | LIMITED SCAN`. [#46708][#46708]
-- The `bit_and()` [aggregate function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#aggregate-functions) now supports [`BIT`](https://www.cockroachlabs.com/docs/v20.2/bit) and `VARBIT` data types. [#46954][#46954]
-- The `bit_or()` [aggregate function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#aggregate-functions) now supports [`BIT`](https://www.cockroachlabs.com/docs/v20.2/bit) and `VARBIT` data types. [#47023][#47023]
-- The error messages for duplicate columns in `NATURAL` and `USING` joins now match the error messages used by Postgres. [#47099][#47099]
-- Modified the `strpos()` function to allow it to support [`BIT`](https://www.cockroachlabs.com/docs/v20.2/bit) and [`BYTES`](https://www.cockroachlabs.com/docs/v20.2/bytes) arrays. [#46875][#46875]
-- Improved the error message for [`ALTER COLUMN ... SET DATA TYPE ...`](https://www.cockroachlabs.com/docs/v20.2/alter-column) for data type conversions that involve overwriting existing values. [#47155][#47155]
-- Modified [`SHOW TABLES`](https://www.cockroachlabs.com/docs/v20.2/show-tables) to return schema and table type. Furthermore, sequences will now appear in `SHOW TABLES`. Any user who relies on `SHOW TABLES` to return one column can use `SELECT table_name FROM [SHOW TABLES]` to get compatible behavior between previous versions of CockroachDB. [#46756][#46756]
-- Made small UX improvements to [hash sharded index](https://www.cockroachlabs.com/docs/v20.2/hash-sharded-indexes) creation. [#47017][#47017]
-- Added `CREATE TABLE LIKE` specifiers. [#47017][#47017]
-- Added support for the `CREATE OR REPLACE VIEW` command. [#47051][#47051]
-- We previously allowed mixed type 20.1/19.2 upgrades to add precision types. However, the 19.2 nodes would disrespect the precision component and we documented that. To make this cleaner, we instead only allow precision to be specified in time-related types when the version upgrade is complete. [#47425][#47425]
-- Histogram collection with `CREATE STATISTICS` is no longer supported on columns with type [`ARRAY`](https://www.cockroachlabs.com/docs/v20.2/array). Only row count, distinct count, and _NULL_ count are collected for array-type columns. [#47281][#47281]
-- A new `default_transaction_priority` [session variable](https://www.cockroachlabs.com/docs/v20.2/show-vars) is now supported, which configures the priority that SQL transactions use by default. The accepted options for the setting are `LOW`, `NORMAL`, and `HIGH`. [#47641][#47641]
-- Removed two public [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `sql.distsql.temp_storage.joins` and `sql.distsql.temp_storage.sorts` that can disable usage of temporary on disk storage of intermediate results of query execution. [#47357][#47357]
-- Added support for collection of multi-column statistics. By default, statistics are now collected on all prefixes of each index, in addition to 100 other individual columns. This feature can be disabled by setting the [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `sql.stats.multi_column_collection.enabled` to false. [#47729][#47729]
-- Added square root and cube root unary operators `|/` and `||/`. [#47680][#47680]
-- We previously supported any [`TIMESTAMP(TZ)`](https://www.cockroachlabs.com/docs/v20.2/timestamp) representable in Go. However, this is incompatible with the Postgres protocol format, as well as resulting in sorting errors when using values such as `(-9223372036854775808)::TIMESTAMP`. We have changed our bounds for timestamps to be the same as Postgres - between `4714-11-24 00:00:00+00 BC` and `294276-12-31 23:59:59.999999` inclusive. Users who have previously stored these values will be able to access them, but the `WHERE` clause must use `< '4714-11-24 00:00:00+00 BC'` or `> 294276-12-31 23:59:59.999999`. [#47077][#47077]
-- Users now have the ability to control the level of `NOTICE` outputs with the [session variable](https://www.cockroachlabs.com/docs/v20.2/show-vars) `client_min_messages`. [#46650][#46650]
-- [`ROLLBACK TO SAVEPOINT`](https://www.cockroachlabs.com/docs/v20.2/rollback-transaction) is no longer permitted after miscellaneous internal errors. [#47724][#47724]
-- [Common table expressions](https://www.cockroachlabs.com/docs/v20.2/common-table-expressions) (CTEs) were extended to support the `MATERIALIZED`/`NOT MATERIALIZED` syntax added in PostgreSQL 12. [#47341][#47341]
-- The `pg_collation`, `pg_proc`, and `pg_type` tables in `pg_catalog` no longer require privileges on any database in order for the data to be visible. [#47996][#47996]
-- Added two new [session variables](https://www.cockroachlabs.com/docs/v20.2/show-vars) and corresponding [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) to control whether the optimizer uses histograms and multi-column statistics for cardinality estimation. The [session variables](https://www.cockroachlabs.com/docs/v20.2/show-vars) are `optimizer_use_histograms` and `optimizer_use_multicol_stats`, with corresponding [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `sql.defaults.optimizer_use_histograms.enabled` and `sql.defaults.optimizer_use_multicol_stats.enabled`. Both settings are enabled by default. [#48105][#48105]
-- Reduced virtual table memory use. [#48066][#48066]
-- Added virtual schema and populated the `pg_catalog.pg_aggregate` table. [#48126][#48126]
-- The default [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) mode is now "on", which means that all queries that can use vectorized execution will do so. To revert to previous behavior `SET CLUSTER SETTING sql.defaults.vectorize='201auto'`. [#48059][#48059]
-- Added support for the `ALTER TABLE ... ADD COLUMN ... REFERENCES ...` syntax for tables that are empty. [#47082][#47082]
-- Caused [primary key changes](https://www.cockroachlabs.com/docs/v20.2/alter-primary-key) to not create a copy of the old primary key if the primary key change only changes the bucket count of a [hash sharded index](https://www.cockroachlabs.com/docs/v20.2/hash-sharded-indexes). [#45894][#45894]
-- Populated the `pg_proc` table's `provolatile` field based on the internal built-in volatility definition. This value used to always be _NULL_. [#48491][#48491]
-- The `RowDescription` message of the pgwire protocol now contains the table OID and column ID for each column in the result set. These values correspond to `pg_attribute.attrelid` and `pg_attribute.attnum`. If a result column does not refer to a simple table or view, these values will be zero, as they were before. [#48417][#48417]
-- Added support for indexing and ordering of arrays of indexable and orderable inner types. [#48045][#48045]
-- Correctly report type length for the [`CHAR`](https://www.cockroachlabs.com/docs/v20.2/string) data type. [#48602][#48602]
-- Changed the statistics collection logic to only include a row in the _NULL_ count for a column statistic if all columns in the statistic are _NULL_. Previously, the row was included if any of the columns were _NULL_. This change makes it easier to use multi-column statistics for accurate cardinality estimation in the optimizer. [#48528][#48528]
-- Fixed an issue with optimizing subqueries involving set operations that could prevent queries from executing. [#48658][#48658]
-- The `pg_database` table in `pg_catalog` no longer require privileges on any database in order for the data to be visible. [#48744][#48744]
-- Improved the optimizer's ability to inline constant values in filter conditions. [#48629][#48629]
-- Improved compatibility of the `pg_typeof` built-in function. [#48614][#48614]
-- Introduced the `pg_extension` virtual schema, which contains tables which are on the public schema when using Postgres style extensions. [#48754][#48754]
-- Renamed the `experimental_serial_normalization` [session variable](https://www.cockroachlabs.com/docs/v20.2/show-vars) to `serial_normalization` since the setting is no longer experimental. [#48796][#48796]
-- The `RowDescription` message of the pgwire protocol now contains the type modifier for each column in the result set. This corresponds to `pg_attribute.atttypmod`. If it is not available, the value is `-1`, as it was before. [#48762][#48762]
-- Added support for the `percentile_disc` and `percentile_cont` ordered-set aggregation functions. [#47668][#47668]
-- Added support for Postgres `ENUM` types to be used in queries and stored in tables. [#48556][#48556]
-- Added the Postgres supported `ENUM` built-ins `enum_first`, `enum_last`, and `enum_range`. [#49086][#49086]
-- The catalog table `pg_type` is now populated with rows for user defined types (like `ENUM`s). [#48693][#48693]
-- Populated the catalog table `pg_catalog.pg_enum`. [#49213][#49213]
-- 24:00 time now displays correctly in the CLI, returning `0001-01-02 00:00:00`. Furthermore, backups correctly emit and read in 24:00 time properly. [#49330][#49330]
-- Vectorized execution engine now supports (although not "natively" - meaning we do not have optimized representations for the newly-supported types) [all data types that CockroachDB supports](https://www.cockroachlabs.com/docs/v20.2/data-types). [#48422][#48422]
-- Vectorized execution engine now supports set operation joins (queries with `INTERSECT ALL` and `EXCEPT ALL`). [#49159][#49159]
-- Added the Postgres syntax `GENERATED ALWAYS` alias for computed column construction. [#49525][#49525]
-- Correctly populated the `rolcanlogin` value for roles in `pg_roles` and `pg_catalog`. [#49389][#49389]
-- Added support for the `max`/`min` aggregation functions on collated strings. [#49530][#49530]
-- Added support for referencing static data types under the `pg_catalog` qualification like `pg_catalog.int`. [#49307][#49307]
-- Added support for the `max`/`min` aggregation functions on `ENUM` types. [#49558][#49558]
-- Added experimental support for the `ALTER COLUMN TYPE` online schema change for changing a column type's data. [#46933][#46933]
-- Previously, using _NULL_ (or tuples containing _NULL_s) as the left-hand-side of an `IN` operator would not typecheck unless the _NULL_s were explicitly casted. Now, the casting is not required. [#49723][#49723]
-- The optimizer can now fold two grouping operators together when they are aggregating over functions like `sum`. [#49627][#49627]
-- The optimizer can now eliminate an unnecessary join that is the input to a `GroupBy` operator. [#49683][#49683]
-- Added the `crdb_internal.create_type_statements` virtual table. It holds create statements for user defined types. [#49771][#49771]
-- The [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) engine now supports the "Concat" ("||") operator. [#49758][#49758]
-
-<h3 id="v20-2-0-alpha-1-command-line-changes">Command-line changes</h3>
-
-- The [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo) command now displays a connection URL to the demo cluster, and in a multi-node cluster it displays connection strings for all of the nodes in the cluster. [#46913][#46913]
-- It is now possible to pre-configure the secure mode of [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo) using the environment variable `COCKROACH_INSECURE` like other client commands. [#46922][#46922]
-- The client-side commands specific to [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo), starting with `\demo`, are now advertised in the output of `\?`. Note that this feature is currently experimental. [#46962][#46962]
-- The `cockroach` CLI commands that internally use SQL, including [`cockroach sql`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql), now can connect to a server using a unix datagram socket. The syntax for this is `--url 'postgres://user@?host=/path/to/directory?port=NNNN'`. [#46968][#46968]
-- The [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo) command now displays a connection URL using a unix datagram socket before the TCP-based URL, as this may deliver better performance in clients running on the same system. [#46979][#46979]
-- The SQL URL generated by [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo), when running in the secure mode, now embeds the password. This way, a command ran by copy-pasting the URL is able to run without asking for a password first. [#46979][#46979]
-- The SQL URL generated by [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo) is simplified to no longer require TLS client certificates in particular directory locations. [#46979][#46979]
-- The new client-side command `\demo ls` (experimental) can now (re-)display the connection parameters for every node in the simulated cluster. [#46979][#46979]
-- Added a new [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) option `--clock-device` that allows CockroachDB's hybrid logical clock (HLC) to use an IEEE 1588 PTP clock device for the HLC current time. [#46942][#46942]
-- The time that [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) waits client-side for the node to drain (i.e., remove existing clients and push range leases away) is now configurable via the command-line flag `--drain-wait`. Note that separate server-side timeouts also apply separately, check the `server.shutdown.*` [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) for details. [#45149][#45149]
-- It is now possible to drain a node without shutting down the process, using [`cockroach node drain`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node). This makes it easier to integrate with service managers and orchestration: it now becomes safe to issue [`cockroach node drain`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node) and then separately stop the service via a process manager or orchestrator. Previously, there was a risk to misconfigure the service manager to auto-restart the node after it had shut down via `quit`, in a way that was surprising or unwanted. The new command `node drain` also recognizes the new `--drain-wait` flag. [#45149][#45149]
-- The commands [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) and [`cockroach node drain`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node) now report a "work remaining" metric on their standard error stream. The value reduces until it reaches 0 to indicate that a graceful shutdown has completed server-side. An operator can now rely on [`cockroach node drain`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node) to obtain confidence of a graceful shutdown prior to terminating the server process. [#45149][#45149]
-- The default value of the parameter `--drain-wait` for [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) has been increased from 1 minute to 10 minutes, to give more time for nodes with thousands of ranges to migrate their leases away. [#46396][#46396]
-- The error message displayed upon [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) / [`cockroach start-single-node`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start-single-node) when manual intervention is needed in the store directory is now clearer. [#47756][#47756]
-- Client commands such as [`cockroach init`](https://www.cockroachlabs.com/docs/v20.2/cockroach-init) and [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) now support the `--cluster-name` and `--disable-cluster-name-verification` flags in order to support running them on clusters that have been configured to use a cluster name. Previously, it was impossible to run such commands against nodes configured with the `--cluster-name` flag. [#48000][#48000]
-- Added support to [`cockroach cert list`](https://www.cockroachlabs.com/docs/v20.2/cockroach-cert) for certificates which require `--cert-principal-map` to pass validation. [#48013][#48013]
-- [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) now properly skips over fully decommissioned nodes. [#48073][#48073]
-- [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) now tries multiple times to retrieve data using SQL if it encounters retry errors. [#48099][#48099]
-- Enabled [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) to dump all databases with a single command using the new `--all` flag. [#47387][#47387]
-- [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) now supports two command-line parameters: `--nodes` and `--exclude-nodes`. When specified, they control which nodes are inspected when gathering the data. This makes it possible to focus on a group of nodes of interest in a large cluster, or to exclude nodes that `debug zip` would have trouble reaching otherwise. Both flags accept a list of individual node IDs or ranges of node IDs, e.g., `--nodes=1,10,13-15`. [#48150][#48150]
-- Added support for the `--cert-principal-map` flag in the [`cockroach cert`](https://www.cockroachlabs.com/docs/v20.2/cockroach-cert) command, and various "client" commands such as [`cockroach sql`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql), [`cockroach init`](https://www.cockroachlabs.com/docs/v20.2/cockroach-init), and [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit). [#47449][#47449]
-- CockroachDB's own SQL shell ([`cockroach sql`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql) and/or [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo)) no longer prompts for more lines of input after the user enters `BEGIN` before sending the input to the server. Instead, full lines of input are always sent to the server immediately.  The corresponding client-side option `smart_prompt` thus becomes ineffective and is deprecated. It will be removed in a later version. [#48433][#48433]
-- Made the `--storage-engine` flag to [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) sticky (i.e., resolve to the last used engine type when unspecified), even when specified stores are encrypted at rest. [#48721][#48721]
-- The `--decommission` flag for [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) is now removed. It was previously deprecated in CockroachDB v20.1. Users should be using [`cockroach node decommission`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node) instead. [#49350][#49350]
-
-<h3 id="v20-2-0-alpha-1-db-console-changes">DB Console changes</h3>
-
-- Dismissing the Release note signup form is now permanent (per user). For insecure mode, it is now dismissed globally. [#46522][#46522]
-- Added a vertical scroll bar on the Cluster Overview main panel to allow: scroll down to Node Map section, and scroll down Node list table. [#46741][#46741]
-- Changed the default sorting column on the Statements page to Execution Count. [#46780][#46780]
-- Tooltips showing statements and jobs are now limited in size for very long statements. [#46557][#46557]
-- The default timescale on the metrics page is now always 10m. Previously, it defaulted to the age of the longest running node. [#46190][#46190]
-- Added a tracking call to Analytics, sending tracking data for Table sorts. [#45920][#45920]
-- Added Analytics tracking for searches on the Statements page. [#45920][#45920]
-- Added Analytics tracking for pagination on the Statements page. [#45920][#45920]
-- Added a tracking call for diagnostics activation on the Statements page. [#45920][#45920]
-- Changed a statement parameter type back to string from AggregateStatics. [#45920][#45920]
-- Moved the diagnostics activation tracking call to a more accurate place. [#45920][#45920]
-- Fixed a bug where sort columns were only being applied per-page instead of for the entire multi-page list of statements. [#46416][#46416]
-- Added analytics tracking for the statement details sub-navigation. [#46789][#46789]
-- Changed the download link for statement diagnostics to point to the diagnostics bundle zip file. [#46790][#46790]
-- Improved tooltips for existing capacity and storage metrics. [#46801][#46801]
-- Removed the Statements tab from the Databases > Table Details page. [#47089][#47089]
-- Fixed and cleaned up bar charts code on the Statements page. [#46574][#46574]
-- Fixed a bug on the Statements page that would not reset pagination state to page 1 after the app selection was changed. [#46972][#46972]
-- Updated layout sizes. [#46627][#46627]
-- Updated colors according to new designs. [#45979][#45979]
-- Use new `SourceSansPro` font across all of the DB Console. [#45979][#45979]
-- Updated font styles for monospaced text (SQL statements, etc.). [#45979][#45979]
-- Added links to statement details from the Statement Diagnostics history page. [#46923][#46923]
-- Added tooltips with full length statements on the Statement Diagnostics history page. [#46923][#46923]
-- Updated the Database loading state design. [#46857][#46857]
-- Updated the design of empty state on the Jobs, Diagnostics, Statements, and Statements Details pages. [#45981][#45981]
-- Fixed a bug where "Raft log too large" was reported incorrectly for replicas for which the raft log size is not to be trusted. [#48032][#48032]
-- Fixed a bug where a multi-node cluster without localities defined wouldn't be able to render the Network Latency page. [#49138][#49138]
-- Fixed a bug where the link to specific problem ranges had an incorrect path. Problem ranges are now linked correctly again. [#49122][#49122]
-- Fixed a bug where the metrics timepicker was always defaulting to the "Custom" date pane. Access to time window presets has been restored and is always shown first. The "Custom" pane is accessed by selecting "Custom" in the dropdown as before. [#49133][#49133]
-- Fixed the incorrect display of the table replica count on the Table Details page. [#49185][#49185]
-- Fixed the Jobs page header overlapping with scrollbars. [#49552][#49552]
-- Updated the tooltip design on the Statements page. [#46626][#46626]
-- Removed Capacity and Logical Bytes per Store graph names from storage tooltips to avoid redundancy. [#47475][#47475]
-- The Databases page now shows a default error message about restricted permissions for non-admin users. [#49592][#49592]
-
-<h3 id="v20-2-0-alpha-1-bug-fixes">Bug fixes</h3>
-
-- Index and table GCs happen closer to their GC deadline. [#46715][#46715]
-- A rare bug causing an assertion failure was fixed. The assertion error message was "caller violated contract: discovered non-conflicting lock".  The bug could have theoretically allowed isolation violations between transactions without hitting the assertion, though this was never observed in practice. [#46625][#46625]
-- Fixed an incorrect query result that could occur when a scalar aggregate was called with a _NULL_ input. [#46649][#46649]
-- Benign "Outbox Next" errors from the vectorized runtime are now only logged when log verbosity is set to 1 or greater. [#46724][#46724]
-- Statement diagnostics created through [`EXPLAIN ANALYZE (DEBUG)`](https://www.cockroachlabs.com/docs/v20.2/explain-analyze) now show up in the Statement Diagnostics page of the DB Console. [#46759][#46759]
-- [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) will now properly clean up partially imported data after having failed or being cancelled. [#46766][#46766]
-- Fixed a bug where failed or cancelled IMPORTs may not have cleaned up partially imported data. [#46727][#46727]
-- Fixed a rare bug causing errors to be returned for successfully committed transactions. The most common error message was `TransactionStatusError: already committed`. [#46596][#46596]
-- Fixed a bug for statement diagnostics that led to tooltips always showing, instead of only on hover. [#46854][#46854]
-- The "insecure cluster" indicator is now displayed again for insecure clusters in the DB Console, at the top right of the screen. [#46844][#46844]
-- A rare assertion failure that contained the text "existing lock cannot be acquired by different transaction" was fixed. This assertion was only present in earlier v20.1 releases and not in any earlier releases.  This bug created a risk of servers crashing unexpectedly due to improper synchronization of KV requests. [#46830][#46830]
-- Fixed incorrect result with `count(*)` when grouping on constant columns. [#46879][#46879]
-- Fixed a bug where CockroachDB could hit an internal error when queries with projections only of `INT2` and/or `INT4` columns were executed via the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). [#46712][#46712]
-- [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo) now properly cleans up its temporary files if the background license acquisition fails. [#46991][#46991]
-- Fixed a bug where, when using the [`TIME`](https://www.cockroachlabs.com/docs/v20.2/time) data type as an index, comparisons using the `!=` operator would return incorrect results if `'24:00:00'` was located in the index. [#46993][#46993]
-- Fixed a bug where CockroachDB was using an existing table name 100% of the time when creating a new table, which resulted in no tables being created. [#47056][#47056]
-- Fixed a bug where CockroachDB could incorrectly consider a non-_NULL_ value from an interleaved parent table to be _NULL_ when the interleaved child had a _NULL_ value in the row with the corresponding index key. [#47035][#47035]
-- Fixed an error that could incorrectly occur when planning queries with `NATURAL` and `USING` joins containing multiple aliases for the same column. [#47099][#47099]
-- CockroachDB now returns a proper error for index creation statements using a column which does not exist. [#47090][#47090]
-- CDC no longer combines with long running transactions to trigger an assertion with the text "lock timestamp regression".  This bug could crash a server if the right sequence of events occurred. This was typically rare, but was much more common when CDC was in use. [#47101][#47101]
-- Fixed a bug where in some cases where system tables have changed, incremental, full-cluster [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup)s with revision history were sometimes incorrectly disallowed. [#47092][#47092]
-- As part of migrating to the new schema change job implementation in 20.1, failed [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/backup) and [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) jobs which left behind table data in 19.2 that had not been completely garbage collected by the time the cluster was upgraded to 20.1 will now have GC jobs automatically created for them. [#47136][#47136]
-- Fixed a data race on AST nodes for [`SELECT` statements](https://www.cockroachlabs.com/docs/v20.2/selection-queries) that include a `WINDOW` clause. It is unclear whether this could have resulted in incorrect results being returned for these queries. [#47146][#47146]
-- Fixed a bug preventing clusters from creating [`TIMETZ`](https://www.cockroachlabs.com/docs/v20.2/time) columns before they accept an upgrade to 20.1 without downgrading. [#47156][#47156]
-- Fixed an infinite loop when adding a self-referencing [foreign key constraint](https://www.cockroachlabs.com/docs/v20.2/foreign-key) in the same transaction which creates a table. [#47113][#47113]
-- Fixed a bug where it was possible to drop a column that was referenced in a computed column expression. [#47085][#47085]
-- Fixed a bug where a mechanism to detect stalled disks was erroneously left disabled. It is now enabled: nodes will verify that they can write to their engines before each attempt to announce themselves as live to the cluster. [#46975][#46975]
-- Fixed the behavior of `crdb_internal.zones` in mixed-version clusters. [#47173][#47173]
-- Fixed reads from `system.namespace` and `crdb_internal.zones` in 19.2 nodes in mixed [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings). [#47173][#47173]
-- Fixed a bug where restoring a backup from 2.1 to 20.1 with a [`TIMESTAMP`](https://www.cockroachlabs.com/docs/v20.2/timestamp) column would result in incomplete type data. This would crash commands such as `SHOW COLUMNS FROM <new_table>`. [#47234][#47234]
-- Fixed an incompatibility with 19.2 nodes for tables with computed columns. [#47269][#47269]
-- Fixed an internal "no output column equivalent to X" error that could occur in some very rare cases. [#47159][#47159]
-- Fixed a bug that could cause CockroachDB processes to crash due to an assertion failure with the text "expected latches held, found none".  The bug became louder (and crashed servers) due to recent changes that added new assertions to the code. [#47247][#47247]
-- Fixed an incorrect error that occurred when executing `UNION` statements with hidden and non-hidden columns. [#47094][#47094]
-- Fixed a bug where in some cases limits were applied incorrectly when pushed down into scans (resulting in some queries returning more results than they should). [#47287][#47287]
-- Fixed a bug in the new schema change GC job implementation causing unnecessary table descriptor lookups whenever any table was updated. [#47313][#47313]
-- Fixed a critical bug that would otherwise cause "invalid truncation decision" panics. [#47143][#47143]
-- Fixed a bug preventing _NULL_ index members from being added to [hash sharded indexes](https://www.cockroachlabs.com/docs/v20.2/hash-sharded-indexes). [#47311][#47311]
-- Fixed a backwards incompatibility between RocksDB and Pebble that prevented RocksDB from opening a Pebble-created WAL file under certain conditions. [#47350][#47350]
-- Fixed a mishandling of truncated WAL records in Pebble which could prevent Pebble from opening a DB after a crash. [#47350][#47350]
-- Fixed a short (3s) period of unavailability that could occur on a range after removing a replica. [#41122][#41122]
-- Fixed an error that occurred when statistics collection was explicitly requested on a column with type [`ARRAY`](https://www.cockroachlabs.com/docs/v20.2/array). [#47281][#47281]
-- Avoid a condition during rapid version upgrades where a node would refuse to start, claiming "a store is too old for running version". Before this bug fix, the workaround was to decommission the node, delete the store directory, and re-add it to the cluster as a new node. [#47358][#47358]
-- [`TRUNCATE`](https://www.cockroachlabs.com/docs/v20.2/truncate) can now run on [temporary tables](https://www.cockroachlabs.com/docs/v20.2/temporary-tables), fixing a bug in 20.1.0 where temporary tables could not be truncated, resulting in an error `unexpected value: nil`. [#47482][#47482]
-- Fixed a bug where instead of returning a parsing error in queries with `count(*)`, CockroachDB could incorrectly return no output (when the query was executed via the row-by-row engine). [#47036][#47036]
-- Fixed a bug that could cause a workload to stall under heavy load. This stall was due to a deadlock that was introduced in an earlier v20.1 release. [#47465][#47465]
-- Fixed a bug where columns which were members of [hash sharded indexes](https://www.cockroachlabs.com/docs/v20.2/hash-sharded-indexes) could not be renamed. Indexes created in prior releases will need to be dropped and recreated to resolve this limitation. [#47431][#47431]
-- Fixed a bug that could trigger an assertion with the text "received X results, limit was Y". The underlying bug was only performance related and could not cause user-visible correctness violations. The bug could result in an assertion failure and a node crashing. Even though this was an old bug (present in many releases before v20.1), it became a lot easier to hit in v20.1 because we started performing ranged intent resolution more often due to implicit [`SELECT FOR UPDATE`](https://www.cockroachlabs.com/docs/v20.2/select-for-update). [#47492][#47492]
-- Fixed incorrect results that could occur when casting negative [`INTERVAL`](https://www.cockroachlabs.com/docs/v20.2/interval)s or [`TIMESTAMP`](https://www.cockroachlabs.com/docs/v20.2/timestamp)s to type [`DECIMAL`](https://www.cockroachlabs.com/docs/v20.2/decimal). [#47483][#47483]
-- Fixed a bug introduced with the new schema change job implementation that caused errors when rolling back a schema change to be swallowed. [#47446][#47446]
-- Fixed a panic that could occur when [`SHOW RANGES`](https://www.cockroachlabs.com/docs/v20.2/show-ranges) or [`SHOW RANGE FOR ROW`](https://www.cockroachlabs.com/docs/v20.2/show-range-for-row) was called with a virtual table. [#47500][#47500]
-- Setting `kv.closed_timestamp.target_duration` to `0` now disables the closed timestamp as was previously documented. [#47480][#47480]
-- Fixed a bug where CockroachDB could not dump tables that have no visible columns. [#46406][#46406]
-- Fixed a bug causing some schema change rollbacks to fail permanently even on transient errors. [#47553][#47553]
-- Fixed a bug introduced in 20.1 that could cause multiple index GC jobs to be created for the same schema change in rare cases. [#46929][#46929]
-- Fixed an issue in RocksDB that could result in missing data in some very specific instances that are very unlikely to be encountered in practice. [#47448][#47448]
-- Fixed an incompatibility between Pebble and RocksDB bloom filters that could result in keys disappearing or reappearing when switching storage engines. [#47612][#47612]
-- Fixed a bug where concurrent schema change interactions could lead to schema changes being blocked for minutes. [#47462][#47462]
-- Fixed a bug where [`PARTITION BY`](https://www.cockroachlabs.com/docs/v20.2/partition-by) and [`ORDER BY`](https://www.cockroachlabs.com/docs/v20.2/order-by) columns in window specifications were losing qualifications when used inside views. [#47709][#47709]
-- Removed redundant metadata information for subqueries and postqueries in [`EXPLAIN (VERBOSE)`](https://www.cockroachlabs.com/docs/v20.2/explain) output. [#47951][#47951]
-- Return a proper Postgres error code from [`DROP INDEX`](https://www.cockroachlabs.com/docs/v20.2/drop-index) statements when dropping [`UNIQUE`](https://www.cockroachlabs.com/docs/v20.2/unique) indices. [#47585][#47585]
-- Fix a rare bug where stats were not automatically generated for a new table. [#47718][#47718]
-- Fixed a planning error that could happen in rare cases when a histogram was used for a descending indexed column. [#48033][#48033]
-- Fixed a bug where CockroachDB could return an internal error when performing a query with `CASE`, `AND`, `OR` operators in some cases when it was executed via the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). [#47938][#47938]
-- [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) can now successfully avoid out-of-memory errors when extracting very large `system` or `crdb_internal` tables. [#48096][#48096]
-- Return a proper `SQLSTATE` error for index creation statements using an existing index name. [#48035][#48035]
-- [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) will now properly report an error if some error is encountered while writing the end of the output zip file. [#48109][#48109]
-- Fix [`cockroach debug encryption-status`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-encryption-active-key) and the DB Console display of encryption status when using Pebble. [#48151][#48151]
-- Fixed "non-values node passed as fixed value to zigzag join" internal error. [#48128][#48128]
-- Return a proper CockroachDB-specific Postgres error code for trying to modify a table without a primary key instead of the generic `XXUUU` error code. [#48125][#48125]
-- Fixed a bug where a read operation in a transaction would error out for exceeding the maximum count of results returned. [#48160][#48160]
-- Fixed a bug in which `(tuple).*` was only expanded to the first column in the tuple and the remaining elements were dropped. [#48225][#48225]
-- CockroachDB will now avoid producing a severe "internal error" upon certain privilege check failures via `pg_catalog` built-in functions. [#48216][#48216]
-- Fixed a bug where more than 1 job was created from a [`DROP COLUMN`](https://www.cockroachlabs.com/docs/v20.2/drop-column) statement, which was confusing clients.  Now, we better distinguish between the delete jobs for columns and dependent jobs for deleting indices, views and sequences. [#48163][#48163]
-- Fixed a bug where vectorized queries on composite data types could sometimes return invalid data. [#48052][#48052]
-- Fixed a rare bug causing a range to deadlock and all the writes to the respective range to timeout. [#48082][#48082]
-- Fixed a bug that could lead to data corruption or data loss if a replica was both the source of a snapshot and was being concurrently removed from the range, and certain specific conditions existed inside RocksDB. This scenario is rare, but possible. [#48320][#48320]
-- Made SRV resolution non-fatal for join list records, to align with the standard and improve reliability of node startup. [#47735][#47735]
-- Fixed a long-standing bug where HTTP requests would start to fail with error 503 "`transport: authentication handshake failed: io: read/write on closed pipe`" and never become possible again until the node is restarted. This bug existed since v2.1 or some time prior. [#48369][#48369]
-- When processing the `--join` flag to [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start), invalid SRV records with port number 0 are now properly ignored. [#48325][#48325]
-- Fixed a bug where [`SHOW STATISTICS USING JSON`](https://www.cockroachlabs.com/docs/v20.2/show-statistics) contained incorrect single quotes for strings with spaces inside histograms. [#48514][#48514]
-- Return a proper SQLSTATE error when trying to [`ADD`](https://www.cockroachlabs.com/docs/v20.2/add-column)or [`RENAME`](https://www.cockroachlabs.com/docs/v20.2/rename-column) a column with an existing name. [#48120][#48120]
-- Prevent dropping of databases which contain tables which are currently offline due to [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/backup) or [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore). Previously, dropping a database in this state could lead to a corrupted schema which prevented running backups. [#48596][#48596]
-- The two settings `kv.range_split.by_load_enabled` and `kv.range_split.load_qps_threshold` are documented but were incorrectly marked as non-public in the output of `SHOW CLUSTER SETTINGS`. This has been corrected. This bug was introduced in v20.1. [#48582][#48582]
-- Fixed a bug preventing timestamps from being closed, which could result in failed follower reads or failure to observe resolved timestamps in changefeeds. [#48561][#48561]
-- Fixed a bug which falsely indicated that `kv.closed_timestamp.max_behind_nanos` was almost always growing. [#48521][#48521]
-- Previously, when an [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/backup) failed, it created a GC job which would behave as a no-op. Now the partially imported data after an [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/backup) fails or is cancelled should be deleted. [#48593][#48593]
-- Fixed a bug where CockroachDB could encounter an internal error when a query with `LEFT SEMI` or `LEFT ANTI` join was performed via the [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) engine in some cases. This was likely to occur only with the `vectorize=on` setting. [#48659][#48659]
-- Fixed a bug where the [`SHOW CREATE`](https://www.cockroachlabs.com/docs/v20.2/show-create) statement would sometimes show a partitioning step for an index that had been dropped. [#48624][#48624]
-- Fixed a bug where [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) on tables with interleaved primary keys would erroneously include an extra `CREATE UNIQUE INDEX "primary" ... INTERLEAVE IN PARENT` statement in the dump output. This made it impossible to re-import the dumped data without manual editing. [#48688][#48688]
-- Re-allow `diagnostics.forced_sql_stat_reset.interval`, `diagnostics.sql_stat_reset.interval` and `external.graphite.interval` to set to their maximum values (24hr, 24hr and 15min respectively). This previously only excluded these values to be allowed. [#48758][#48758]
-- Fixed a bug where changing the primary key of a table that had partitioned indexes could cause indexes to lose their zone configurations. In particular, the indexes that got rebuilt as part of a [primary key change](https://www.cockroachlabs.com/docs/v20.2/alter-primary-key) would keep their partitions, but lose the zone configurations attached to those partitions. [#48510][#48510]
-- Fixed a bug where [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) on a table with collated strings would omit the collation clause for the data insertion statements. [#48687][#48687]
-- Manually writing a _NULL_ value into the `system.users` table for the "hashedPassword" column will no longer cause a server crash during user authentication. [#48773][#48773]
-- Fixed a bug introduced in v20.1.0 where the migration for ongoing schema change jobs would cause the node to panic with an index out of bounds error upon encountering a malformed table descriptor with no schema change mutation corresponding to the job to be migrated. [#48823][#48823]
-- Properly support restoring tables that were backed up while they were in the middle of a schema change. [#47588][#47588]
-- Fixed a bug where columns of a table could not be dropped after a [primary key change](https://www.cockroachlabs.com/docs/v20.2/alter-primary-key). [#49081][#49081]
-- Fixed an error that could occur when using _NULL_ in some array indirections. [#48830][#48830]
-- Fixed incorrect logic for `IS NULL` and `IS NOT NULL` operators with tuples, correctly differentiating them from `IS NOT DISTINCT FROM NULL` and `IS DISTINCT FROM NULL`, respectively. [#48299][#48299]
-- Fixed costing of [lookup join](https://www.cockroachlabs.com/docs/v20.2/joins#lookup-joins) with a limit on top, resulting in better plans (that utilize lookup join) in some cases. [#48862][#48862]
-- [`SHOW BACKUP SCHEMAS`](https://www.cockroachlabs.com/docs/v20.2/show-backup) no longer shows table comments, as they may be inaccurate. [#48167][#48167]
-- Fixed a bug where when a database was dropped, it would not drop the entry for its public schema in the `system.namespace` table. [#49125][#49125]
-- Fixed a possible deadlock during vectorized query execution. [#49106][#49106]
-- Fixed a memory leak which could affect `CHANGEFEED`s performing scans of large tables. [#49101][#49101]
-- Improved accuracy of column types returned from queries to improve PostgreSQL compatibility. [#48619][#48619]
-- Fixed a bug where use of arrays combined with window functions was causing a query failure. [#49234][#49234]
-- Fixed a small race in the [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) engine. [#49202][#49202]
-- Fixed a bug where contended [`DROP INDEX`](https://www.cockroachlabs.com/docs/v20.2/drop-index) queries returned an assertion failure error rather than a retryable error. [#49221][#49221]
-- Some benign errors were previously reported as unexpected internal errors by the [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) engine; this is now fixed. [#49260][#49260]
-- Prevent namespace orphans (manifesting as `database "" not found` errors) when migrating from 19.2. [#49099][#49099]
-- Removed duplicate SQL memory metrics. [#47750][#47750]
-- When the value passed to `--drain-wait` is very small, but non-zero, [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) in certain cases would not proceed to perform a hard shutdown. This has been corrected. This bug existed since v19.1.9, v19.2.7 and v20.1.1. [#49362][#49362]
-- Fixed a bug where in some cases an internal error could occur when queries that have columns of [`BYTES`](https://www.cockroachlabs.com/docs/v20.2/bytes) type in the output were executed via the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). [#49223][#49223]
-- CockroachDB now correctly reports engine type in bug reports when using [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo). [#49372][#49372]
-- Fixed a bug where `\demo node restart` would not work due to an invalid certificate directory. [#49382][#49382]
-- Abandoned intents due to failed transaction coordinators are now cleaned up much faster. This resolves a regression in v20.1.0 compared to prior releases. [#49218][#49218]
-- Fixed a bug where if one attempted to perform a full cluster [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) on a backup that did not contain any user data, it would fail. [#49591][#49591]
-- CockroachDB no longer leaks file descriptors during GSS authentication. [#49572][#49572]
-- Fixed a bug where CockroachDB could return an internal error or incorrect results on queries when they were run via the [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) engine and had a hash router in the DistSQL plan. This could only occur with the `vectorize=on` setting. [#49333][#49333]
-- Fixed a bug where executing a large number of statements in a transaction without committing could previously crash a CockroachDB server. [#48859][#48859]
-- The schema change workload is meant for testing the behavior of schema changes on clusters with nodes with minimum version 19.2. It will deadlock on earlier versions. [#49662][#49662]
-- Fixed a panic observed as "unexpected arg type tree.DOidWrapper". [#49601][#49601]
-- Fixed a bug where if `ctx.err()` is `nil`, the CLI will panic when a workload returns an error. [#48338][#48338]
-
-<h3 id="v20-2-0-alpha-1-performance-improvements">Performance improvements</h3>
-
-- Some queries which contain a division by a constant have improved execution plans. [#46809][#46809]
-- The query planner can now decorrelate correlated exists subqueries with `LIMIT` expressions, leading to better query plans. [#46540][#46540]
-- Make virtual tables that access all table descriptors make fewer round trips. [#46872][#46872]
-- Reduce time needed to run a [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) command when it is built on a lot of previous incremental backups. [#47158][#47158]
-- The [query optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) now produces faster query plans for some disjunctions (`OR` expressions) by utilizing multiple indexes. [#47094][#47094]
-- The [query optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) is now more selective in splitting disjunctions into unions, avoiding the overhead of unnecessary memo expansion. [#47161][#47161]
-- Improve performance of [`UPDATE`](https://www.cockroachlabs.com/docs/v20.2/update) on tables with GIN indexed columns. [#47354][#47354]
-- Query optimization for disjunctions was extended to support queries which do not select strict keys. [#47342][#47342]
-- The [query optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) is now smarter when splitting disjunctions into unions by grouping disjunctions based on the columns referenced. [#47361][#47361]
-- The [query optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) now uses a more efficient plan when splitting disjunctions into multiple sub-queries. [#47454][#47454]
-- Query optimization for disjunctions was extended to support scans over GIN indexes. [#47542][#47542]
-- Histograms are now used by the optimizer to estimate the cost of index scans with multiple constrained columns or descending columns. This enables better query plan selection in some cases. [#47565][#47565]
-- Improved execution plans by removing unnecessary remaining filters in some cases where the filters are reflected by an index constraint. [#47623][#47623]
-- The cleanup job which runs after a [primary key change](https://www.cockroachlabs.com/docs/v20.2/alter-primary-key) to remove old indexes, which blocks other schema changes from running, now starts immediately after the primary key swap is complete. This reduces the amount of waiting time before subsequent schema changes can run. [#47624][#47624]
-- The [query optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) now uses a more efficient plan when splitting disjunctions into multiple sub-queries. [#47617][#47617]
-- The [query optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) is now more efficient when generating plans for queries with many OR expressions. [#48025][#48025]
-- Filtered scans over virtual tables have improved performance in common cases. [#47316][#47316]
-- [`SHOW CREATE`](https://www.cockroachlabs.com/docs/v20.2/show-create) is much more efficient. [#47316][#47316]
-- The [query optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) can now split disjunctions in more complex expressions into a union over two index scans. [#48036][#48036]
-- Disabled the Go runtime block profile by default, resulting in a small but measurable reduction in CPU usage. The block profile has diminished in utility with the advent of mutex contention profiles and is almost never used during performance investigations. [#48133][#48133]
-- The optimizer can now detect when an `EXISTS` subquery can be eliminated because the input has zero rows. This leads to better plans in some cases. [#48162][#48162]
-- Before this change, a simple schema change could take 30s+. The reason was that if the schema change is not first in line in the table mutation queue it would return a retryable error and the jobs framework would re-adopt and run it later. The problem is that the job adoption loop timer is 30s. Instead of returning on retryable errors, we retry with an exponential backoff in the schema change code. This pattern of dealing with retryable errors in client job code is encouraged vs. relying on the registry, because the latter leads to slowness and additionally to more complicated test fixtures that rely on hacking with the internals of the job registry. [#48608][#48608]
-- Fixed a bug in the histogram filtering logic in the optimizer which was causing inaccurate cardinality estimates for queries with equality predicates on UUIDs and strings, as well as some other types. This bug has existed since histograms were first introduced into the optimizer in the 19.2.0 release. Fixing it improves the optimizer's cardinality estimates and results in better query plans in some cases. [#48580][#48580]
-- Histograms used by the optimizer for query planning now have more accurate row counts per histogram bucket, particularly for columns that have many _NULL_ values. This results in better plans in some cases. [#48528][#48528]
-- [`DROP TABLE`](https://www.cockroachlabs.com/docs/v20.2/drop-table) performance is improved due to doing fewer roundtrips for object comment maintenance. [#48265][#48265]
-- The optimizer and execution engine can now plan [lookup joins](https://www.cockroachlabs.com/docs/v20.2/joins#lookup-joins) into virtual indexes, avoiding full scans against virtual tables. [#48226][#48226]
-- [Lookup joins](https://www.cockroachlabs.com/docs/v20.2/joins#lookup-joins) with no required ordering are now more efficient. [#48439][#48439]
-- A performance inefficiency has been fixed in the [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) engine which results in speed ups on all queries when run via the vectorized engine, with most noticeable gains on the queries that output many rows. [#48669][#48669]
-- The optimizer now normalizes a comparison operator (`=`, `>=`, `<=`, `<`, `>`) with a nested "timezone" function applied to a variable. This results in the generation of constrained index scans in more cases, and therefore, better query plans. [#48724][#48724]
-- Reduce memory allocations and improve performance of low-level KV scan operations on Pebble. [#49121][#49121]
-- `COUNT` is now converted to `COUNT(*)` (aka `COUNT_ROWS`) in more cases. [#49126][#49126]
-- [Lookup join](https://www.cockroachlabs.com/docs/v20.2/joins#lookup-joins) performance has been improved. [#48058][#48058]
-- The optimizer can now determine more accurate costs for query plans with a combination of disjunctions and contradictions. [#49462][#49462]
-- Default [replication configurations](https://www.cockroachlabs.com/docs/v20.2/configure-replication-zones) have been tuned to support higher replication throughput in high-latency replication quorums. [#49619][#49619]
-- Fixed a bug in the histogram logic in the optimizer which was causing an over-estimate for the cardinality of constrained index scans in some cases when multiple columns of the index were constrained. This problem was introduced early in the development for the 20.2 release, so should not have ever been part of a release. The fix improves the optimizer's cardinality estimates and may result in better query plan selection. [#49134][#49134]
-- Fixed the optimizer's distinct count estimate for columns constrained by an index constraint, which was too low in some cases. The fix improves the optimizer's cardinality estimates, which can lead to better query plan selection. [#49134][#49134]
-- Fixed the optimizer's estimated distinct count for a multi-column statistic when all of the columns in the statistic are constrained by a filter predicate. The fix can lead to improved cardinality estimates, leading to better query plan selection in some cases. [#49134][#49134]
-- Added support for calculating the selectivity of filter predicates in the optimizer using multi-column statistics. This improves the cardinality estimates of the optimizer when a query has filter predicates constraining multiple columns. As a result, the optimizer may choose a better query plan in some cases. [#49134][#49134]
-- Remove compaction-debt based SSTable ingestion backpressure which was artificially slowing down [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/backup)s and [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore)s on Pebble and not providing any utility on RocksDB. Removed the private `rocksdb.ingest_backpressure.pending_compaction_threshold` [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings). [#49726][#49726]
-
-<h3 id="v20-2-0-alpha-1-build-changes">Build changes</h3>
-
-- It's now possible to build CockroachDB with the Clang++ v10 compiler. [#46859][#46859]
-- Release Docker images are now built on Debian 9.12. [#49593][#49593]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-0-alpha-1-contributors">Contributors</h3>
-
-This release includes 899 merged PRs by 68 authors. We would like to thank the following contributors from the CockroachDB community:
-
-- Amit Sadaphule
-- Andrii Vorobiov
-- Anthony Huang (first-time contributor)
-- Artem Barger
-- BurtonQin (first-time contributor)
-- Girish Ramnani (first-time contributor)
-- Helen He (first-time contributor)
-- Jaewan Park
-- Jaime Soriano Pastor (first-time contributor)
-- Petr Jediný (first-time contributor)
-- Richard Tweed (first-time contributor)
-- Yongyang Lai (first-time contributor)
-- abhishek20123g
-- lancerutkin (first-time contributor)
-
-</div>
-
-[#41122]: https://github.com/cockroachdb/cockroach/pull/41122
-[#43744]: https://github.com/cockroachdb/cockroach/pull/43744
-[#45149]: https://github.com/cockroachdb/cockroach/pull/45149
-[#45638]: https://github.com/cockroachdb/cockroach/pull/45638
-[#45644]: https://github.com/cockroachdb/cockroach/pull/45644
-[#45662]: https://github.com/cockroachdb/cockroach/pull/45662
-[#45665]: https://github.com/cockroachdb/cockroach/pull/45665
-[#45802]: https://github.com/cockroachdb/cockroach/pull/45802
-[#45860]: https://github.com/cockroachdb/cockroach/pull/45860
-[#45862]: https://github.com/cockroachdb/cockroach/pull/45862
-[#45894]: https://github.com/cockroachdb/cockroach/pull/45894
-[#45920]: https://github.com/cockroachdb/cockroach/pull/45920
-[#45978]: https://github.com/cockroachdb/cockroach/pull/45978
-[#45979]: https://github.com/cockroachdb/cockroach/pull/45979
-[#45981]: https://github.com/cockroachdb/cockroach/pull/45981
-[#46190]: https://github.com/cockroachdb/cockroach/pull/46190
-[#46275]: https://github.com/cockroachdb/cockroach/pull/46275
-[#46396]: https://github.com/cockroachdb/cockroach/pull/46396
-[#46406]: https://github.com/cockroachdb/cockroach/pull/46406
-[#46416]: https://github.com/cockroachdb/cockroach/pull/46416
-[#46504]: https://github.com/cockroachdb/cockroach/pull/46504
-[#46522]: https://github.com/cockroachdb/cockroach/pull/46522
-[#46540]: https://github.com/cockroachdb/cockroach/pull/46540
-[#46557]: https://github.com/cockroachdb/cockroach/pull/46557
-[#46574]: https://github.com/cockroachdb/cockroach/pull/46574
-[#46596]: https://github.com/cockroachdb/cockroach/pull/46596
-[#46625]: https://github.com/cockroachdb/cockroach/pull/46625
-[#46626]: https://github.com/cockroachdb/cockroach/pull/46626
-[#46627]: https://github.com/cockroachdb/cockroach/pull/46627
-[#46649]: https://github.com/cockroachdb/cockroach/pull/46649
-[#46650]: https://github.com/cockroachdb/cockroach/pull/46650
-[#46695]: https://github.com/cockroachdb/cockroach/pull/46695
-[#46708]: https://github.com/cockroachdb/cockroach/pull/46708
-[#46710]: https://github.com/cockroachdb/cockroach/pull/46710
-[#46712]: https://github.com/cockroachdb/cockroach/pull/46712
-[#46715]: https://github.com/cockroachdb/cockroach/pull/46715
-[#46716]: https://github.com/cockroachdb/cockroach/pull/46716
-[#46724]: https://github.com/cockroachdb/cockroach/pull/46724
-[#46727]: https://github.com/cockroachdb/cockroach/pull/46727
-[#46731]: https://github.com/cockroachdb/cockroach/pull/46731
-[#46741]: https://github.com/cockroachdb/cockroach/pull/46741
-[#46748]: https://github.com/cockroachdb/cockroach/pull/46748
-[#46756]: https://github.com/cockroachdb/cockroach/pull/46756
-[#46759]: https://github.com/cockroachdb/cockroach/pull/46759
-[#46766]: https://github.com/cockroachdb/cockroach/pull/46766
-[#46780]: https://github.com/cockroachdb/cockroach/pull/46780
-[#46785]: https://github.com/cockroachdb/cockroach/pull/46785
-[#46787]: https://github.com/cockroachdb/cockroach/pull/46787
-[#46789]: https://github.com/cockroachdb/cockroach/pull/46789
-[#46790]: https://github.com/cockroachdb/cockroach/pull/46790
-[#46795]: https://github.com/cockroachdb/cockroach/pull/46795
-[#46798]: https://github.com/cockroachdb/cockroach/pull/46798
-[#46801]: https://github.com/cockroachdb/cockroach/pull/46801
-[#46809]: https://github.com/cockroachdb/cockroach/pull/46809
-[#46830]: https://github.com/cockroachdb/cockroach/pull/46830
-[#46844]: https://github.com/cockroachdb/cockroach/pull/46844
-[#46845]: https://github.com/cockroachdb/cockroach/pull/46845
-[#46850]: https://github.com/cockroachdb/cockroach/pull/46850
-[#46854]: https://github.com/cockroachdb/cockroach/pull/46854
-[#46857]: https://github.com/cockroachdb/cockroach/pull/46857
-[#46859]: https://github.com/cockroachdb/cockroach/pull/46859
-[#46864]: https://github.com/cockroachdb/cockroach/pull/46864
-[#46872]: https://github.com/cockroachdb/cockroach/pull/46872
-[#46875]: https://github.com/cockroachdb/cockroach/pull/46875
-[#46879]: https://github.com/cockroachdb/cockroach/pull/46879
-[#46887]: https://github.com/cockroachdb/cockroach/pull/46887
-[#46911]: https://github.com/cockroachdb/cockroach/pull/46911
-[#46913]: https://github.com/cockroachdb/cockroach/pull/46913
-[#46922]: https://github.com/cockroachdb/cockroach/pull/46922
-[#46923]: https://github.com/cockroachdb/cockroach/pull/46923
-[#46929]: https://github.com/cockroachdb/cockroach/pull/46929
-[#46932]: https://github.com/cockroachdb/cockroach/pull/46932
-[#46933]: https://github.com/cockroachdb/cockroach/pull/46933
-[#46936]: https://github.com/cockroachdb/cockroach/pull/46936
-[#46942]: https://github.com/cockroachdb/cockroach/pull/46942
-[#46952]: https://github.com/cockroachdb/cockroach/pull/46952
-[#46954]: https://github.com/cockroachdb/cockroach/pull/46954
-[#46962]: https://github.com/cockroachdb/cockroach/pull/46962
-[#46968]: https://github.com/cockroachdb/cockroach/pull/46968
-[#46972]: https://github.com/cockroachdb/cockroach/pull/46972
-[#46975]: https://github.com/cockroachdb/cockroach/pull/46975
-[#46979]: https://github.com/cockroachdb/cockroach/pull/46979
-[#46991]: https://github.com/cockroachdb/cockroach/pull/46991
-[#46993]: https://github.com/cockroachdb/cockroach/pull/46993
-[#47017]: https://github.com/cockroachdb/cockroach/pull/47017
-[#47023]: https://github.com/cockroachdb/cockroach/pull/47023
-[#47035]: https://github.com/cockroachdb/cockroach/pull/47035
-[#47036]: https://github.com/cockroachdb/cockroach/pull/47036
-[#47051]: https://github.com/cockroachdb/cockroach/pull/47051
-[#47056]: https://github.com/cockroachdb/cockroach/pull/47056
-[#47077]: https://github.com/cockroachdb/cockroach/pull/47077
-[#47082]: https://github.com/cockroachdb/cockroach/pull/47082
-[#47085]: https://github.com/cockroachdb/cockroach/pull/47085
-[#47089]: https://github.com/cockroachdb/cockroach/pull/47089
-[#47090]: https://github.com/cockroachdb/cockroach/pull/47090
-[#47092]: https://github.com/cockroachdb/cockroach/pull/47092
-[#47093]: https://github.com/cockroachdb/cockroach/pull/47093
-[#47094]: https://github.com/cockroachdb/cockroach/pull/47094
-[#47099]: https://github.com/cockroachdb/cockroach/pull/47099
-[#47101]: https://github.com/cockroachdb/cockroach/pull/47101
-[#47113]: https://github.com/cockroachdb/cockroach/pull/47113
-[#47136]: https://github.com/cockroachdb/cockroach/pull/47136
-[#47143]: https://github.com/cockroachdb/cockroach/pull/47143
-[#47145]: https://github.com/cockroachdb/cockroach/pull/47145
-[#47146]: https://github.com/cockroachdb/cockroach/pull/47146
-[#47155]: https://github.com/cockroachdb/cockroach/pull/47155
-[#47156]: https://github.com/cockroachdb/cockroach/pull/47156
-[#47158]: https://github.com/cockroachdb/cockroach/pull/47158
-[#47159]: https://github.com/cockroachdb/cockroach/pull/47159
-[#47161]: https://github.com/cockroachdb/cockroach/pull/47161
-[#47171]: https://github.com/cockroachdb/cockroach/pull/47171
-[#47173]: https://github.com/cockroachdb/cockroach/pull/47173
-[#47200]: https://github.com/cockroachdb/cockroach/pull/47200
-[#47234]: https://github.com/cockroachdb/cockroach/pull/47234
-[#47247]: https://github.com/cockroachdb/cockroach/pull/47247
-[#47269]: https://github.com/cockroachdb/cockroach/pull/47269
-[#47281]: https://github.com/cockroachdb/cockroach/pull/47281
-[#47284]: https://github.com/cockroachdb/cockroach/pull/47284
-[#47287]: https://github.com/cockroachdb/cockroach/pull/47287
-[#47303]: https://github.com/cockroachdb/cockroach/pull/47303
-[#47311]: https://github.com/cockroachdb/cockroach/pull/47311
-[#47313]: https://github.com/cockroachdb/cockroach/pull/47313
-[#47316]: https://github.com/cockroachdb/cockroach/pull/47316
-[#47341]: https://github.com/cockroachdb/cockroach/pull/47341
-[#47342]: https://github.com/cockroachdb/cockroach/pull/47342
-[#47350]: https://github.com/cockroachdb/cockroach/pull/47350
-[#47354]: https://github.com/cockroachdb/cockroach/pull/47354
-[#47357]: https://github.com/cockroachdb/cockroach/pull/47357
-[#47358]: https://github.com/cockroachdb/cockroach/pull/47358
-[#47361]: https://github.com/cockroachdb/cockroach/pull/47361
-[#47387]: https://github.com/cockroachdb/cockroach/pull/47387
-[#47389]: https://github.com/cockroachdb/cockroach/pull/47389
-[#47425]: https://github.com/cockroachdb/cockroach/pull/47425
-[#47431]: https://github.com/cockroachdb/cockroach/pull/47431
-[#47446]: https://github.com/cockroachdb/cockroach/pull/47446
-[#47448]: https://github.com/cockroachdb/cockroach/pull/47448
-[#47449]: https://github.com/cockroachdb/cockroach/pull/47449
-[#47454]: https://github.com/cockroachdb/cockroach/pull/47454
-[#47462]: https://github.com/cockroachdb/cockroach/pull/47462
-[#47465]: https://github.com/cockroachdb/cockroach/pull/47465
-[#47475]: https://github.com/cockroachdb/cockroach/pull/47475
-[#47480]: https://github.com/cockroachdb/cockroach/pull/47480
-[#47482]: https://github.com/cockroachdb/cockroach/pull/47482
-[#47483]: https://github.com/cockroachdb/cockroach/pull/47483
-[#47492]: https://github.com/cockroachdb/cockroach/pull/47492
-[#47496]: https://github.com/cockroachdb/cockroach/pull/47496
-[#47500]: https://github.com/cockroachdb/cockroach/pull/47500
-[#47542]: https://github.com/cockroachdb/cockroach/pull/47542
-[#47553]: https://github.com/cockroachdb/cockroach/pull/47553
-[#47565]: https://github.com/cockroachdb/cockroach/pull/47565
-[#47584]: https://github.com/cockroachdb/cockroach/pull/47584
-[#47585]: https://github.com/cockroachdb/cockroach/pull/47585
-[#47588]: https://github.com/cockroachdb/cockroach/pull/47588
-[#47610]: https://github.com/cockroachdb/cockroach/pull/47610
-[#47612]: https://github.com/cockroachdb/cockroach/pull/47612
-[#47616]: https://github.com/cockroachdb/cockroach/pull/47616
-[#47617]: https://github.com/cockroachdb/cockroach/pull/47617
-[#47623]: https://github.com/cockroachdb/cockroach/pull/47623
-[#47624]: https://github.com/cockroachdb/cockroach/pull/47624
-[#47625]: https://github.com/cockroachdb/cockroach/pull/47625
-[#47629]: https://github.com/cockroachdb/cockroach/pull/47629
-[#47635]: https://github.com/cockroachdb/cockroach/pull/47635
-[#47641]: https://github.com/cockroachdb/cockroach/pull/47641
-[#47668]: https://github.com/cockroachdb/cockroach/pull/47668
-[#47680]: https://github.com/cockroachdb/cockroach/pull/47680
-[#47685]: https://github.com/cockroachdb/cockroach/pull/47685
-[#47709]: https://github.com/cockroachdb/cockroach/pull/47709
-[#47718]: https://github.com/cockroachdb/cockroach/pull/47718
-[#47724]: https://github.com/cockroachdb/cockroach/pull/47724
-[#47727]: https://github.com/cockroachdb/cockroach/pull/47727
-[#47729]: https://github.com/cockroachdb/cockroach/pull/47729
-[#47735]: https://github.com/cockroachdb/cockroach/pull/47735
-[#47750]: https://github.com/cockroachdb/cockroach/pull/47750
-[#47756]: https://github.com/cockroachdb/cockroach/pull/47756
-[#47766]: https://github.com/cockroachdb/cockroach/pull/47766
-[#47783]: https://github.com/cockroachdb/cockroach/pull/47783
-[#47936]: https://github.com/cockroachdb/cockroach/pull/47936
-[#47937]: https://github.com/cockroachdb/cockroach/pull/47937
-[#47938]: https://github.com/cockroachdb/cockroach/pull/47938
-[#47951]: https://github.com/cockroachdb/cockroach/pull/47951
-[#47996]: https://github.com/cockroachdb/cockroach/pull/47996
-[#47999]: https://github.com/cockroachdb/cockroach/pull/47999
-[#48000]: https://github.com/cockroachdb/cockroach/pull/48000
-[#48013]: https://github.com/cockroachdb/cockroach/pull/48013
-[#48015]: https://github.com/cockroachdb/cockroach/pull/48015
-[#48025]: https://github.com/cockroachdb/cockroach/pull/48025
-[#48032]: https://github.com/cockroachdb/cockroach/pull/48032
-[#48033]: https://github.com/cockroachdb/cockroach/pull/48033
-[#48035]: https://github.com/cockroachdb/cockroach/pull/48035
-[#48036]: https://github.com/cockroachdb/cockroach/pull/48036
-[#48045]: https://github.com/cockroachdb/cockroach/pull/48045
-[#48052]: https://github.com/cockroachdb/cockroach/pull/48052
-[#48058]: https://github.com/cockroachdb/cockroach/pull/48058
-[#48059]: https://github.com/cockroachdb/cockroach/pull/48059
-[#48066]: https://github.com/cockroachdb/cockroach/pull/48066
-[#48073]: https://github.com/cockroachdb/cockroach/pull/48073
-[#48074]: https://github.com/cockroachdb/cockroach/pull/48074
-[#48077]: https://github.com/cockroachdb/cockroach/pull/48077
-[#48082]: https://github.com/cockroachdb/cockroach/pull/48082
-[#48096]: https://github.com/cockroachdb/cockroach/pull/48096
-[#48099]: https://github.com/cockroachdb/cockroach/pull/48099
-[#48105]: https://github.com/cockroachdb/cockroach/pull/48105
-[#48109]: https://github.com/cockroachdb/cockroach/pull/48109
-[#48120]: https://github.com/cockroachdb/cockroach/pull/48120
-[#48125]: https://github.com/cockroachdb/cockroach/pull/48125
-[#48126]: https://github.com/cockroachdb/cockroach/pull/48126
-[#48128]: https://github.com/cockroachdb/cockroach/pull/48128
-[#48133]: https://github.com/cockroachdb/cockroach/pull/48133
-[#48138]: https://github.com/cockroachdb/cockroach/pull/48138
-[#48145]: https://github.com/cockroachdb/cockroach/pull/48145
-[#48150]: https://github.com/cockroachdb/cockroach/pull/48150
-[#48151]: https://github.com/cockroachdb/cockroach/pull/48151
-[#48160]: https://github.com/cockroachdb/cockroach/pull/48160
-[#48162]: https://github.com/cockroachdb/cockroach/pull/48162
-[#48163]: https://github.com/cockroachdb/cockroach/pull/48163
-[#48167]: https://github.com/cockroachdb/cockroach/pull/48167
-[#48190]: https://github.com/cockroachdb/cockroach/pull/48190
-[#48216]: https://github.com/cockroachdb/cockroach/pull/48216
-[#48225]: https://github.com/cockroachdb/cockroach/pull/48225
-[#48226]: https://github.com/cockroachdb/cockroach/pull/48226
-[#48229]: https://github.com/cockroachdb/cockroach/pull/48229
-[#48236]: https://github.com/cockroachdb/cockroach/pull/48236
-[#48245]: https://github.com/cockroachdb/cockroach/pull/48245
-[#48265]: https://github.com/cockroachdb/cockroach/pull/48265
-[#48295]: https://github.com/cockroachdb/cockroach/pull/48295
-[#48299]: https://github.com/cockroachdb/cockroach/pull/48299
-[#48320]: https://github.com/cockroachdb/cockroach/pull/48320
-[#48325]: https://github.com/cockroachdb/cockroach/pull/48325
-[#48338]: https://github.com/cockroachdb/cockroach/pull/48338
-[#48354]: https://github.com/cockroachdb/cockroach/pull/48354
-[#48364]: https://github.com/cockroachdb/cockroach/pull/48364
-[#48369]: https://github.com/cockroachdb/cockroach/pull/48369
-[#48376]: https://github.com/cockroachdb/cockroach/pull/48376
-[#48417]: https://github.com/cockroachdb/cockroach/pull/48417
-[#48422]: https://github.com/cockroachdb/cockroach/pull/48422
-[#48433]: https://github.com/cockroachdb/cockroach/pull/48433
-[#48439]: https://github.com/cockroachdb/cockroach/pull/48439
-[#48440]: https://github.com/cockroachdb/cockroach/pull/48440
-[#48441]: https://github.com/cockroachdb/cockroach/pull/48441
-[#48449]: https://github.com/cockroachdb/cockroach/pull/48449
-[#48450]: https://github.com/cockroachdb/cockroach/pull/48450
-[#48451]: https://github.com/cockroachdb/cockroach/pull/48451
-[#48452]: https://github.com/cockroachdb/cockroach/pull/48452
-[#48471]: https://github.com/cockroachdb/cockroach/pull/48471
-[#48491]: https://github.com/cockroachdb/cockroach/pull/48491
-[#48493]: https://github.com/cockroachdb/cockroach/pull/48493
-[#48504]: https://github.com/cockroachdb/cockroach/pull/48504
-[#48510]: https://github.com/cockroachdb/cockroach/pull/48510
-[#48514]: https://github.com/cockroachdb/cockroach/pull/48514
-[#48521]: https://github.com/cockroachdb/cockroach/pull/48521
-[#48528]: https://github.com/cockroachdb/cockroach/pull/48528
-[#48529]: https://github.com/cockroachdb/cockroach/pull/48529
-[#48552]: https://github.com/cockroachdb/cockroach/pull/48552
-[#48556]: https://github.com/cockroachdb/cockroach/pull/48556
-[#48561]: https://github.com/cockroachdb/cockroach/pull/48561
-[#48580]: https://github.com/cockroachdb/cockroach/pull/48580
-[#48582]: https://github.com/cockroachdb/cockroach/pull/48582
-[#48593]: https://github.com/cockroachdb/cockroach/pull/48593
-[#48596]: https://github.com/cockroachdb/cockroach/pull/48596
-[#48602]: https://github.com/cockroachdb/cockroach/pull/48602
-[#48608]: https://github.com/cockroachdb/cockroach/pull/48608
-[#48614]: https://github.com/cockroachdb/cockroach/pull/48614
-[#48619]: https://github.com/cockroachdb/cockroach/pull/48619
-[#48624]: https://github.com/cockroachdb/cockroach/pull/48624
-[#48629]: https://github.com/cockroachdb/cockroach/pull/48629
-[#48658]: https://github.com/cockroachdb/cockroach/pull/48658
-[#48659]: https://github.com/cockroachdb/cockroach/pull/48659
-[#48666]: https://github.com/cockroachdb/cockroach/pull/48666
-[#48667]: https://github.com/cockroachdb/cockroach/pull/48667
-[#48669]: https://github.com/cockroachdb/cockroach/pull/48669
-[#48687]: https://github.com/cockroachdb/cockroach/pull/48687
-[#48688]: https://github.com/cockroachdb/cockroach/pull/48688
-[#48693]: https://github.com/cockroachdb/cockroach/pull/48693
-[#48721]: https://github.com/cockroachdb/cockroach/pull/48721
-[#48724]: https://github.com/cockroachdb/cockroach/pull/48724
-[#48744]: https://github.com/cockroachdb/cockroach/pull/48744
-[#48754]: https://github.com/cockroachdb/cockroach/pull/48754
-[#48758]: https://github.com/cockroachdb/cockroach/pull/48758
-[#48759]: https://github.com/cockroachdb/cockroach/pull/48759
-[#48762]: https://github.com/cockroachdb/cockroach/pull/48762
-[#48773]: https://github.com/cockroachdb/cockroach/pull/48773
-[#48778]: https://github.com/cockroachdb/cockroach/pull/48778
-[#48796]: https://github.com/cockroachdb/cockroach/pull/48796
-[#48823]: https://github.com/cockroachdb/cockroach/pull/48823
-[#48830]: https://github.com/cockroachdb/cockroach/pull/48830
-[#48859]: https://github.com/cockroachdb/cockroach/pull/48859
-[#48862]: https://github.com/cockroachdb/cockroach/pull/48862
-[#49077]: https://github.com/cockroachdb/cockroach/pull/49077
-[#49081]: https://github.com/cockroachdb/cockroach/pull/49081
-[#49082]: https://github.com/cockroachdb/cockroach/pull/49082
-[#49085]: https://github.com/cockroachdb/cockroach/pull/49085
-[#49086]: https://github.com/cockroachdb/cockroach/pull/49086
-[#49089]: https://github.com/cockroachdb/cockroach/pull/49089
-[#49094]: https://github.com/cockroachdb/cockroach/pull/49094
-[#49099]: https://github.com/cockroachdb/cockroach/pull/49099
-[#49101]: https://github.com/cockroachdb/cockroach/pull/49101
-[#49106]: https://github.com/cockroachdb/cockroach/pull/49106
-[#49121]: https://github.com/cockroachdb/cockroach/pull/49121
-[#49122]: https://github.com/cockroachdb/cockroach/pull/49122
-[#49125]: https://github.com/cockroachdb/cockroach/pull/49125
-[#49126]: https://github.com/cockroachdb/cockroach/pull/49126
-[#49133]: https://github.com/cockroachdb/cockroach/pull/49133
-[#49134]: https://github.com/cockroachdb/cockroach/pull/49134
-[#49138]: https://github.com/cockroachdb/cockroach/pull/49138
-[#49159]: https://github.com/cockroachdb/cockroach/pull/49159
-[#49169]: https://github.com/cockroachdb/cockroach/pull/49169
-[#49185]: https://github.com/cockroachdb/cockroach/pull/49185
-[#49194]: https://github.com/cockroachdb/cockroach/pull/49194
-[#49199]: https://github.com/cockroachdb/cockroach/pull/49199
-[#49202]: https://github.com/cockroachdb/cockroach/pull/49202
-[#49211]: https://github.com/cockroachdb/cockroach/pull/49211
-[#49213]: https://github.com/cockroachdb/cockroach/pull/49213
-[#49218]: https://github.com/cockroachdb/cockroach/pull/49218
-[#49221]: https://github.com/cockroachdb/cockroach/pull/49221
-[#49222]: https://github.com/cockroachdb/cockroach/pull/49222
-[#49223]: https://github.com/cockroachdb/cockroach/pull/49223
-[#49224]: https://github.com/cockroachdb/cockroach/pull/49224
-[#49227]: https://github.com/cockroachdb/cockroach/pull/49227
-[#49234]: https://github.com/cockroachdb/cockroach/pull/49234
-[#49237]: https://github.com/cockroachdb/cockroach/pull/49237
-[#49260]: https://github.com/cockroachdb/cockroach/pull/49260
-[#49307]: https://github.com/cockroachdb/cockroach/pull/49307
-[#49330]: https://github.com/cockroachdb/cockroach/pull/49330
-[#49333]: https://github.com/cockroachdb/cockroach/pull/49333
-[#49341]: https://github.com/cockroachdb/cockroach/pull/49341
-[#49350]: https://github.com/cockroachdb/cockroach/pull/49350
-[#49362]: https://github.com/cockroachdb/cockroach/pull/49362
-[#49372]: https://github.com/cockroachdb/cockroach/pull/49372
-[#49382]: https://github.com/cockroachdb/cockroach/pull/49382
-[#49389]: https://github.com/cockroachdb/cockroach/pull/49389
-[#49398]: https://github.com/cockroachdb/cockroach/pull/49398
-[#49422]: https://github.com/cockroachdb/cockroach/pull/49422
-[#49424]: https://github.com/cockroachdb/cockroach/pull/49424
-[#49456]: https://github.com/cockroachdb/cockroach/pull/49456
-[#49457]: https://github.com/cockroachdb/cockroach/pull/49457
-[#49462]: https://github.com/cockroachdb/cockroach/pull/49462
-[#49474]: https://github.com/cockroachdb/cockroach/pull/49474
-[#49481]: https://github.com/cockroachdb/cockroach/pull/49481
-[#49525]: https://github.com/cockroachdb/cockroach/pull/49525
-[#49530]: https://github.com/cockroachdb/cockroach/pull/49530
-[#49552]: https://github.com/cockroachdb/cockroach/pull/49552
-[#49558]: https://github.com/cockroachdb/cockroach/pull/49558
-[#49572]: https://github.com/cockroachdb/cockroach/pull/49572
-[#49591]: https://github.com/cockroachdb/cockroach/pull/49591
-[#49592]: https://github.com/cockroachdb/cockroach/pull/49592
-[#49593]: https://github.com/cockroachdb/cockroach/pull/49593
-[#49601]: https://github.com/cockroachdb/cockroach/pull/49601
-[#49611]: https://github.com/cockroachdb/cockroach/pull/49611
-[#49613]: https://github.com/cockroachdb/cockroach/pull/49613
-[#49619]: https://github.com/cockroachdb/cockroach/pull/49619
-[#49627]: https://github.com/cockroachdb/cockroach/pull/49627
-[#49644]: https://github.com/cockroachdb/cockroach/pull/49644
-[#49649]: https://github.com/cockroachdb/cockroach/pull/49649
-[#49662]: https://github.com/cockroachdb/cockroach/pull/49662
-[#49667]: https://github.com/cockroachdb/cockroach/pull/49667
-[#49683]: https://github.com/cockroachdb/cockroach/pull/49683
-[#49685]: https://github.com/cockroachdb/cockroach/pull/49685
-[#49699]: https://github.com/cockroachdb/cockroach/pull/49699
-[#49722]: https://github.com/cockroachdb/cockroach/pull/49722
-[#49723]: https://github.com/cockroachdb/cockroach/pull/49723
-[#49726]: https://github.com/cockroachdb/cockroach/pull/49726
-[#49738]: https://github.com/cockroachdb/cockroach/pull/49738
-[#49742]: https://github.com/cockroachdb/cockroach/pull/49742
-[#49743]: https://github.com/cockroachdb/cockroach/pull/49743
-[#49758]: https://github.com/cockroachdb/cockroach/pull/49758
-[#49771]: https://github.com/cockroachdb/cockroach/pull/49771
-[#49793]: https://github.com/cockroachdb/cockroach/pull/49793
-[#49800]: https://github.com/cockroachdb/cockroach/pull/49800
-[#49807]: https://github.com/cockroachdb/cockroach/pull/49807
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-alpha.2.md b/src/current/_includes/releases/v20.2/v20.2.0-alpha.2.md
deleted file mode 100644
index 88e70676fee..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-alpha.2.md
+++ /dev/null
@@ -1,328 +0,0 @@
-## v20.2.0-alpha.2
-
-Release Date: July 27, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-alpha-2-backward-incompatible-changes">Backward-incompatible changes</h3>
-
-- The [`SHOW RANGE FOR ROW`](https://www.cockroachlabs.com/docs/v20.2/show-range-for-row) statement now takes a tuple of the row's index columns instead of the full column set of the row. [#50479][#50479] {% comment %}doc{% endcomment %}
-- Previously, issuing a `SIGTERM` signal twice or after another signal initiated a hard shutdown for a node. Now the first `SIGTERM` signal initiates a graceful shutdown and further occurrences of `SIGTERM` are ignored. To initiate a hard shutdown, issue `SIGINT` two times (or issue a `SIGINT` signal once after a `SIGTERM` signal). [#50539][#50539] {% comment %}doc{% endcomment %}
-- Specifying the same option multiple times in the `WITH` clause of the [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) statement now results in an error message. Additionally, quoted option names are not allowed anymore. [#50723][#50723] {% comment %}doc{% endcomment %}
-- For expression typing involving only operations on constant literals, each constant literal is now assigned a [`type`](https://www.cockroachlabs.com/docs/v20.2/data-types) before calculation. Previously, a `type` was assigned only to the result. [#50254][#50254] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-alpha-2-security-updates">Security updates</h3>
-
-- HTTP endpoints beginning with `/debug/` now require a valid [admin](https://www.cockroachlabs.com/docs/v20.2/authorization) login session. [#50483][#50483] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-alpha-2-general-changes">General changes</h3>
-
-- Go 1.14 is now the minimum required version necessary to build CockroachDB. [#50671][#50671] {% comment %}doc{% endcomment %}
-- The docker image available with CockroachDB now includes the GEOS files required to work with [Geospatial types](https://www.cockroachlabs.com/docs/v20.2/spatial-data) in CockroachDB. [#50362][#50362] {% comment %}doc{% endcomment %}
-- Schema changes are now logged in greater detail. [#50372][#50372] {% comment %}doc{% endcomment %}
-- Added new options to YCSB to mirror OpenSource YCSB options. [#50546][#50546] {% comment %}doc{% endcomment %}
-- Links returned in error messages that point to unimplemented issues now use the CockroachLabs redirect/short-link server. [#49836][#49836]
-
-<h3 id="v20-2-0-alpha-2-enterprise-edition-changes">Enterprise edition changes</h3>
-
-- The default flush interval for [changefeeds](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) that do not specify a `RESOLVED` option is now 5s instead of 200ms to more gracefully handle higher-latency sinks. [#49770][#49770] {% comment %}doc{% endcomment %}
-- [Full cluster restore](https://www.cockroachlabs.com/docs/v20.2/restore#full-cluster) is now more resilient to transient transaction retry errors while it restores. [#49950][#49950]
-- [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) now remaps user-defined types within the backup to existing types in the cluster. [#50349][#50349] {% comment %}doc{% endcomment %}
-- `BACKUP` can now run in a new `detached` mode, which means the Job ID is now returned immediately without waiting for the `BACKUP` job to finish. [#50775][#50775] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-alpha-2-sql-language-changes">SQL language changes</h3>
-
-<h4 id="v20-2-0-alpha-2-geospatial-changes">Geospatial changes</h4>
-
-- Implemented the following built-ins: `ST_Transform`, `ST_Intersection`, `ST_PointOnSurface`, and `ST_Union`, `ST_Segmentize({geometry, float8})`, `ST_Project({geography,float8,float8})`, `ST_LongestLine({geometry, geometry})`, `ST_Azimuth({geometry,geometry})`, `ST_ShortestLine({geometry, geometry})`, `ST_Centroid ({geometry,bool})` functions.  [#49783][#49783], [#49833][#49833], [#49827][#49827], [#49949][#49949], [#50018][#50018], [#50188][#50188], [#50292][#50292], [#50484][#50484] {% comment %}doc{% endcomment %}
-- Implemented the following built-ins: `GeometryType`, `PostGIS_AddBBox`, `PostGIS_DropBBox`,  `PostGIS_Extensions_Upgrade`, `PostGIS_Full_Version`, `PostGIS_GEOS_Version`, `PostGIS_HasBBox`, `PostGIS_LibXML_Version`, `PostGIS_Lib_Build_Date`, `PostGIS_Lib_Version`, `PostGIS_Liblwgeom_Version`, `PostGIS_PROJ_Version`, `PostGIS_Scripts_Build_Date`, `PostGIS_Scripts_Installed`, `PostGIS_Scripts_Released`, `PostGIS_Version`, `PostGIS_Wagyu_Version`. [#50589][#50589] {% comment %}doc{% endcomment %}
-- Added support for casting `GEOGRAPHY` and `GEOMETRY` types to and from `Bytes`/`JSONB`. [#50577][#50577] {% comment %}doc{% endcomment %}
-- Implemented `ST_AsGeoJSON` with options to show `bbox` and `CRS` information. [#49888][#49888] {% comment %}doc{% endcomment %}
-- Introduced `maxDecimalDigits` arguments for `ST_AsText` and `ST_AsEWKT`, which allow rounding of the decimal digits output in the `WKT` representation. [#49875][#49875] {% comment %}doc{% endcomment %}
-- Populated the `spatial_ref_sys` table with support SRID entries for geospatial data types. [#49887][#49887] {% comment %}doc{% endcomment %}
-- Implemented the `ST_Azimuth` functionality for the geography operator. [#50708][#50708] {% comment %}doc{% endcomment %}
-- `GEOMETRY` now coerce invalid geography coordinates into correct geometry. [#50457][#50457] {% comment %}doc{% endcomment %}
-- Added support for `AddGeometryColumn` and other functions that mutate schema in `IMPORT PGDUMP`. [#50850][#50850] {% comment %}doc{% endcomment %}
-
-<h4 id="v20-2-0-alpha-2-general-sql-updates">General SQL updates</h4>
-
-- For Postgres compatibility, CockroachDB now supports the `ANALYZE <tablename>` statement that collects statistics on the given table for use by the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer). The statement is functionally equivalent to the existing [`CREATE STATISTICS`](https://www.cockroachlabs.com/docs/v20.2/create-statistics) statement. [#49816][#49816] {% comment %}doc{% endcomment %}
-- The [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) now supports the `JSONFetchVal(->)` operator, the `Pow` operator, the `Bitand` (`&`), `Bitor` (`|`), `Bitxor` (`^`), `FloorDiv` (`//`), and `Mod` (`%`) binary operators, and the binary shift (`>>` and `<<`) operators. [#49818][#49818], [#49761][#49761], [#50143][#50143], [#50417][#50417] {% comment %}doc{% endcomment %}
-- The [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) now supports `AVG` and `SUM` aggregate functions on `Int`s and `Interval`s. [#49900][#49900] {% comment %}doc{% endcomment %}
-- The [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) now fully supports the `SUM` aggregate function (previously, the summation of integers was incomplete). [#49900][#49900] {% comment %}doc{% endcomment %}
-- The [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) now supports the `MIN` and `MAX` aggregate functions on columns of `INT2` and `INT4` [`types`](https://www.cockroachlabs.com/docs/v20.2/data-types). [#49900][#49900] {% comment %}doc{% endcomment %}
-- The [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) can now remove an unnecessary [join](https://www.cockroachlabs.com/docs/v20.2/joins) from the input of a `Project` operator. [#49788][#49788] {% comment %}doc{% endcomment %}
-- The [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) can now fold two `Limit` operators together. [#49931][#49931] {% comment %}doc{% endcomment %}
-- Improved performance for queries with a limit on a [join](https://www.cockroachlabs.com/docs/v20.2/joins) that is guaranteed to preserve input rows. [#49802][#49802]
-- Added the `crdb_internal.databases` virtual table. [#49522][#49522]
-- Referencing types across databases has been disabled. [#49841][#49841] {% comment %}doc{% endcomment %}
-- Views now only create a dependency on a table's column if the column is referenced in the view definition. Previously, all columns in a table referenced in a view were added to the view's dependencies. [#49872][#49872] {% comment %}doc{% endcomment %}
-- The `pgdate` util can now parse `db2` formatted timestamps. This can be used to import `db2` dumps. [#50011][#50011] {% comment %}doc{% endcomment %}
-- For some [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) variants, the property `distributed` for the output variable `Field` has been renamed as `distribution` and can have `local`, `partial`, or `full` values. The `partial` state is currently only possible with the experimental setting. [#49857][#49857] {% comment %}doc{% endcomment %}
-- Added support for the `ALTER COLUMN TYPE ... USING EXPRESSION` statement to allow users to optionally provide an expression to convert a column to a new [`type`](https://www.cockroachlabs.com/docs/v20.2/data-types). [#49452][#49452] {% comment %}doc{% endcomment %}
-- Enhanced the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer)'s ability to reorder joins. [#49948][#49948]
-- Enabled aggregate queries which collect key/value pairs into a JSON object. [#48306][#48306] {% comment %}doc{% endcomment %}
-- Removed the `optimizer_foreign_keys` and `experimental_optimizer_foreign_key_cascades` session settings (and their corresponding cluster settings). [#50185][#50185] {% comment %}doc{% endcomment %}
-- `RegClass` expressions are now tracked as dependencies in views. For example, `CREATE VIEW v AS SELECT 't'::regclass;` will now add a dependency on table `t` for view `v`. [#50213][#50213] {% comment %}doc{% endcomment %}
-- Sequences passed as a string argument into views are now tracked as a dependency. For example, `CREATE VIEW v AS SELECT nextval('s')` will now add a dependency on sequence `s`. [#50103][#50103] {% comment %}doc{% endcomment %}
-- Fixed an error for the `ALTER COLUMN TYPE` statement for situations where the data matches byte for byte but CockroachDB needs to validate the `INT8` -> `INT4` conversion. [#50278][#50278]
-- Previously, `infinity` evaluated to a negative value, `-292277022365-05-08T08:17:07Z`. Now `infinity` is the maximum supported timestamp in Postgres that is not infinity. Likewise, `-infinity` is the smallest supported value. Note that this work-in-progress feature currently does not behave exactly like `infinity` in Postgres. [#50311][#50311] {% comment %}doc{% endcomment %}
-- The `CHAR` column [`type`](https://www.cockroachlabs.com/docs/v20.2/data-types) will now truncate the trailing space characters in line with Postgres. Existing stored `CHAR` entries with spaces at the end of the `CHAR` column [`type`](https://www.cockroachlabs.com/docs/v20.2/data-types) will no longer return rows with trailing space characters. Use the `LIKE` query to find and modify these rows. [#50492][#50492] {% comment %}doc{% endcomment %}
-- Disabled arrays in non-GIN indexes. [#50662][#50662] {% comment %}doc{% endcomment %}
-- Enabled dropping indexes used in outbound foreign key relationships. [#50769][#50769] {% comment %}doc{% endcomment %}
-- CockroachDB no longer writes to the slow query log unless explicitly enabled. [#50898][#50898] {% comment %}doc{% endcomment %}
-- [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into) now supports columns with constant default expressions, and non-targeted columns with constant default expressions are no longer required to be nullable. [#50295][#50295] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-alpha-2-command-line-changes">Command-line changes</h3>
-
-- Advanced troubleshooting information (such as internal details from the Go runtime) is now saved in a separate log file named `<program>-stderr.xxx.log` in the configured log directory.  [#48051][#48051] {% comment %}doc{% endcomment %}
-- The server CLI commands ([`start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start), [`start-single-node`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start-single-node), [`demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo)) now support a new flag named `--redactable-logs`, which introduces markers in generated log entries to facilitate redaction of sensitive information by [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) and other CockroachDB APIs. This is an experimental feature currently not enabled by default, but is recommended for all deployments and will be enabled by default in a later version.  Note: the flag is *advertised* (in `--help`) by `cockroach start` and `cockroach start-single-node`, where log files are expected as a matter of course; it is also supported, yet *hidden* (from `--help`), by every other CLI command because every command can also produce log entries when passed `--log-dir` or `--logtostderr`. [#48051][#48051] {% comment %}doc{% endcomment %}
-- The commands [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) and [`cockroach debug merge-logs`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-merge-logs) support a new flag `--redact-logs`. When specified, it causes log messages that potentially contain confidential data or PII to be redacted away.  This feature is experimental.  Note: Currently, this redaction is extremely aggressive and may hinder the ability of Cockroach Labs to investigate issues from log files, especially if `--redactable-logs` is not enabled server-side.  Other potentially-confidential data may still be retrieved by `cockroach debug zip`; the new flag only applies to retrieved log files inside the output zip file. [#48051][#48051] {% comment %}doc{% endcomment %}
-- `cockroach node decommission --wait=live` is no longer supported. It was deprecated in an earlier release. [#49666][#49666] {% comment %}doc{% endcomment %}
-- `cockroach quit` is now deprecated. Use the subcommands for [`cockroach node`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node) instead, and use termination signals to quit the `cockroach` process. [#49668][#49668] {% comment %}doc{% endcomment %}
-- Allowed [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) to dump tables and databases that contain user-defined types. [#49808][#49808] {% comment %}doc{% endcomment %}
-- The commands [`cockroach node decommission`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node#node-decommission) and [`cockroach node recommission`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node#node-recommission) now recognize a new flag named `--self`. This can be passed *instead* of an explicit list of node IDs, and indicates that the operation targets the node the command is connected to (either via `--host` if specified, or `localhost`). [#50532][#50532] {% comment %}doc{% endcomment %}
-- The command-line flag `--log-dir-max-size` is now deprecated and has been replaced with a new flag named `--log-group-max-size`. The flags limit the combined size of all files generated by one *logging group* inside CockroachDB. [#50599][#50599] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-alpha-2-db-console-changes">DB Console changes</h3>
-
-- CockroachDB now preserves the selected tab on the [`Statements` page](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page) after reload. [#48090][#48090]
-- Fixed [`Statements` page](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page) crash on database names with `/`. [#47423][#47423]
-- The `Statements` page now shows if the vectorized execution engine is used or not. [#50255][#50255] {% comment %}doc{% endcomment %}
-- Updated the empty state design for the `Statement diagnostics history` page. [#46921][#46921]
-- Updated the tooltip designs on the [`Overview`](https://www.cockroachlabs.com/docs/v20.2/ui-overview). [#46919][#46919] {% comment %}doc{% endcomment %}
-- Updated the [`Storage Dashboard`](https://www.cockroachlabs.com/docs/v20.2/ui-storage-dashboard). [#47523][#47523] {% comment %}doc{% endcomment %}
-- Fixed icon alignments for the Timeframe navigation buttons. [#50010][#50010] {% comment %}doc{% endcomment %}
-- The `Queues` dashboard in the DB Console no longer shows a `Compaction Queue` graph, and the `Queue Processing Failures` and `Queue Processing Times` graphs no longer include the `Compaction` queue metrics. [#50245][#50245] {% comment %}doc{% endcomment %}
-- Updated the Login page design. [#46783][#46783] {% comment %}doc{% endcomment %}
-- Added a tooltip for the `Stats by Node` metric. [#50348][#50348]
-- Changed the label for `std deviation` from `<` to `>` for positive values. [#50275][#50275] {% comment %}doc{% endcomment %}
-- Updated the message for the `Node logs` page when remote debugging is restricted for users by using the `server.remote_debugging.mode` cluster setting. [#49553][#49553] {% comment %}doc{% endcomment %}
-- The sidebar navigation panel no longer displays the `Network Latency` menu for a single-node cluster. [#50269][#50269] {% comment %}doc{% endcomment %}
-- Aligned the `Units` selector and `Remove Chart` buttons on the same line. Search input for metric name now properly shows the search term. [#50334][#50334] {% comment %}doc{% endcomment %}
-- Added a collection of new metrics to track the method of requests sent as RPCs between cluster nodes. These metrics are named `distsender.rpc.<method>.sent`, with examples of `<method>` being `scan` and `conditionalput`. [#46747][#46747] {% comment %}doc{% endcomment %}
-- The time range selector has been extended with a 30 minutes option for all `Metrics`. [#50810][#50810] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-alpha-2-bug-fixes">Bug fixes</h3>
-
-- Previously, when doing a series of table creations and drops, subsequent [incremental backups](https://www.cockroachlabs.com/docs/v20.2/take-full-and-incremental-backups) ran into an error. This is now fixed. [#49776][#49776]
-- The description provided with `--help` on the CLI for `--socket-dir` and `--socket` has been fixed. They were invalid since v20.1.0. [#49905][#49905]
-- Previously, in some cases, CockroachDB didn't check whether the right argument of the `Div` (`/`), `FloorDiv` (`//`), or `Mod` (`%`) operations was zero, so instead of correctly returning a `division by zero` error, CockroachDB returned `NaN`, and this is now fixed. Additionally, the error message of `modulus by zero` has been changed to `division by zero` to be inline with Postgres. [#49761][#49761]
-- Fixed an internal planning error that occurred for recursive CTEs (`WITH RECURSIVE` expressions) in which the left side of the [`UNION ALL`](https://www.cockroachlabs.com/docs/v20.2/selection-queries#union-combine-two-queries) query used in the CTE definition produced zero rows. [#49961][#49961]
-- CockroachDB now correctly handles import cancellation and errors. [#49979][#49979]
-- CockroachDB now correctly links producer/consumer during data import in order to handle errors correctly. [#49995][#49995]
-- `extract(epoch from timestamptz)` from a session time zone not in UTC would previously return a value incorrectly offset by the session time zone. This has now been rectified. [#50071][#50071]
-- Previously, when streaming values from a column declared of [`type`](https://www.cockroachlabs.com/docs/v20.2/data-types) `char(n)`, the length of the value could be `<= n`. Now all values streamed have length exactly `n` by padding spaces to the right if necessary. [#49886][#49886]
-- Casting to width-limited strings now works correctly for strings containing Unicode characters. [#50156][#50156]
-- Fixed some cases where casting a string to a width-limited string array was not truncating the string. [#50153][#50153]
-- Previously, if a full cluster restore failed while restoring the system table data, it would not clean up properly and leave some temporary tables public and not dropped. This is now fixed. [#50003][#50003]
-- The [`Statements` page](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page) of the DB Console previously displayed incorrect information about whether or not the statement execution was distributed. [#50256][#50256]
-- Fixed a bug where an `unexpected EOF` error would be returned at startup with the Pebble storage engine, if the last instance of `cockroach` crashed in a rare case of the write-ahead log being written to. [#50280][#50280]
-- Fixed a recently introduced `no volatility for cast unknown::tuple` error. [#50436][#50436]
-- CockroachDB now correctly populates the `rolvaliduntil` value for roles in `pg_roles` and `pg_authid`. [#50307][#50307]
-- Fixed a bug affecting some [`DROP DATABASE`](https://www.cockroachlabs.com/docs/v20.2/drop-database) schema changes where multiple GC jobs are created, causing the GC job for the database to fail. GC jobs will no longer fail upon failing to find a table descriptor already deleted by a different GC job. [#50411][#50411]
-- Fixed an internal error when referencing a [`type`](https://www.cockroachlabs.com/docs/v20.2/data-types) that does not exist by ID. [#50286][#50286]
-- [Lookup join](https://www.cockroachlabs.com/docs/v20.2/joins#lookup-joins) predicate now shows proper column names in [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain). [#50441][#50441]
-- The result of interpreting relative timestamps (like `now`, `today`) is no longer stored in cached plans. [#50320][#50320]
-- Renaming a temporary table no longer converts it to a persistent table. The table continues to remain temporary after a rename. Moreover, users can no longer move a temp table into the `public` schema by providing a fully qualified name while renaming the table. [#50500][#50500]
-- A server node now properly dumps Go stacks to its log file for troubleshooting upon receiving `SIGQUIT` during node shutdown. Previously, `SIGQUIT` was only recognized for this purpose while the node had not started shutting down already. [#50539][#50539]
-- Previously performing [`ALTER TABLE..ADD COLUMN`](https://www.cockroachlabs.com/docs/v20.2/alter-table) with a computed expression allowed users to provide a column in a different table or database if the column name was the same. Similarly, users could provide an expression referring to another table's column when executing `ALTER COLUMN TYPE USING EXPRESSION`. This is no longer the case and all columns must refer to the column in the table being altered. [#50582][#50582]
-- Fixed a bug where creating a sequence owned by a table's column and dropping the sequence would make it impossible to drop the table after. [#50665][#50665]
-- Fixed a bug where Pebble iteration would skip over blocks that failed checksum verification rather than propagating the error to the caller. [#50697][#50697]
-- Some `pg_catalog` queries that previously returned an error like `crdb_internal_vtable_pk column not allowed` now work again. [#50682][#50682]
-- Fixed internal errors in some queries involving `CASE` expressions with `NULL` branches. [#50626][#50626]
-- Fixed a rare bug where a multi-Range [`SELECT FOR UPDATE`](https://www.cockroachlabs.com/docs/v20.2/select-for-update) statement containing an `IN` clause could fail to observe a consistent snapshot and violate serializability. [#50633][#50633]
-- Fixed a bug where a cluster restore would fail when the largest descriptor in the backup was a database. This was typically seen when the last action in backing up cluster was a database creation. [#50759][#50759]
-- Fixed an internal error during planning for some queries with aggregate functions embedded in complex scalar expressions. [#50815][#50815]
-- Fixed a bug where a badly timed power outage or system crash could result in an error upon process restart. [#50831][#50831]
-- Fixed a bug where a cluster backup would appear as `BACKUP TABLE TO` rather than `BACKUP TO` in the jobs table. [#50760][#50760]
-- Fixed the `column not in input` internal error for some corner cases. [#50845][#50845]
-- [`DROP DATABASE CASCADE`](https://www.cockroachlabs.com/docs/v20.2/drop-database#drop-a-database-and-its-objects-cascade) now works as expected even when the database has a sequence with an owner in it. [#50744][#50744]
-
-<h3 id="v20-2-0-alpha-2-performance-improvements">Performance improvements</h3>
-
-- Introduced a new flag named `server.consistency_check.max_rate` expressed in bytes/second to throttle the rate at which CockroachDB scans through the disk to perform a consistency check. This control is necessary to ensure smooth performance on a cluster with large node sizes (i.e., in the 10TB+ range) [#49763][#49763] {% comment %}doc{% endcomment %}
-- Fixed a performance regression in the [`SHOW DATABASES`](https://www.cockroachlabs.com/docs/v20.2/show-databases) command introduced in 20.1. [#49522][#49522]
-- Limited [`SELECT`](https://www.cockroachlabs.com/docs/v20.2/select-clause) statements now do a better job avoiding unnecessary contention with [`UPDATE`](https://www.cockroachlabs.com/docs/v20.2/update) and [`SELECT FOR UPDATE`](https://www.cockroachlabs.com/docs/v20.2/select-for-update) statements. [#49980][#49980]
-- `PGCOPY` import is now ~3.5x faster by parallelizing the conversion of raw input data to Datums. [#50016][#50016]
-- Allowed the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) to use `enum` information to generate better query plans. [#49284][#49284]
-- Range merges are now delayed for a short time after load-based splitting to prevent load-based split points from being merged away immediately after load is removed. [#50151][#50151]
-- Transaction liveness pushes are now delayed by 50ms, up from 10ms. This allows high contention workloads to sustain high throughput up to much larger concurrency levels. [#50161][#50161] {% comment %}doc{% endcomment %}
-- Improved `sstable` files organization in the Pebble storage engine, which should significantly improve import performance. [#50371][#50371]
-- Improved the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer)'s estimation of the selectivity of some filters involving a disjunction (OR) of predicates over multiple columns. This results in more accurate cardinality estimation and enables the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) to choose better query plans in some cases. [#50456][#50456]
-- Many queries that involve [`now()`](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#date-and-time-functions) are executed more efficiently; in particular, the result of `now()` can be used with an index. [#50320][#50320]
-- Better execution plans in some cases involving [`EXISTS`](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#conditional-and-function-like-operators). [#50846][#50846]
-- Smoothed out disk writes when transferring Range snapshots to avoid latency spikes for other concurrent operations. [#50866][#50866]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-0-alpha-2-contributors">Contributors</h3>
-
-This release includes 446 merged PRs by 53 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Andrii Vorobiov
-- Artem Barger
-- Arun Ranganathan (first-time contributor)
-- George Papadrosou
-- Jaewan Park
-- John Kendall (first-time contributor, CockroachDB team member)
-- Jordan Ryan Reuter (first-time contributor, CockroachDB team member)
-- Madeline Liao (first-time contributor, CockroachDB team member)
-- Robert S Lee (first-time contributor)
-- Ryan Min (first-time contributor, CockroachDB team member)
-- Tancredo Souza (first-time contributor)
-- Yongyang Lai
-- abhishek20123g
-- gorjunov (first-time contributor)
-- jieniu$ (first-time contributor)
-
-</div>
-
-[#46747]: https://github.com/cockroachdb/cockroach/pull/46747
-[#46783]: https://github.com/cockroachdb/cockroach/pull/46783
-[#46919]: https://github.com/cockroachdb/cockroach/pull/46919
-[#46921]: https://github.com/cockroachdb/cockroach/pull/46921
-[#47423]: https://github.com/cockroachdb/cockroach/pull/47423
-[#47523]: https://github.com/cockroachdb/cockroach/pull/47523
-[#48051]: https://github.com/cockroachdb/cockroach/pull/48051
-[#48090]: https://github.com/cockroachdb/cockroach/pull/48090
-[#48306]: https://github.com/cockroachdb/cockroach/pull/48306
-[#49284]: https://github.com/cockroachdb/cockroach/pull/49284
-[#49452]: https://github.com/cockroachdb/cockroach/pull/49452
-[#49522]: https://github.com/cockroachdb/cockroach/pull/49522
-[#49553]: https://github.com/cockroachdb/cockroach/pull/49553
-[#49666]: https://github.com/cockroachdb/cockroach/pull/49666
-[#49668]: https://github.com/cockroachdb/cockroach/pull/49668
-[#49761]: https://github.com/cockroachdb/cockroach/pull/49761
-[#49763]: https://github.com/cockroachdb/cockroach/pull/49763
-[#49770]: https://github.com/cockroachdb/cockroach/pull/49770
-[#49776]: https://github.com/cockroachdb/cockroach/pull/49776
-[#49783]: https://github.com/cockroachdb/cockroach/pull/49783
-[#49784]: https://github.com/cockroachdb/cockroach/pull/49784
-[#49788]: https://github.com/cockroachdb/cockroach/pull/49788
-[#49802]: https://github.com/cockroachdb/cockroach/pull/49802
-[#49808]: https://github.com/cockroachdb/cockroach/pull/49808
-[#49816]: https://github.com/cockroachdb/cockroach/pull/49816
-[#49818]: https://github.com/cockroachdb/cockroach/pull/49818
-[#49823]: https://github.com/cockroachdb/cockroach/pull/49823
-[#49827]: https://github.com/cockroachdb/cockroach/pull/49827
-[#49833]: https://github.com/cockroachdb/cockroach/pull/49833
-[#49836]: https://github.com/cockroachdb/cockroach/pull/49836
-[#49841]: https://github.com/cockroachdb/cockroach/pull/49841
-[#49857]: https://github.com/cockroachdb/cockroach/pull/49857
-[#49872]: https://github.com/cockroachdb/cockroach/pull/49872
-[#49875]: https://github.com/cockroachdb/cockroach/pull/49875
-[#49886]: https://github.com/cockroachdb/cockroach/pull/49886
-[#49887]: https://github.com/cockroachdb/cockroach/pull/49887
-[#49888]: https://github.com/cockroachdb/cockroach/pull/49888
-[#49892]: https://github.com/cockroachdb/cockroach/pull/49892
-[#49900]: https://github.com/cockroachdb/cockroach/pull/49900
-[#49905]: https://github.com/cockroachdb/cockroach/pull/49905
-[#49931]: https://github.com/cockroachdb/cockroach/pull/49931
-[#49948]: https://github.com/cockroachdb/cockroach/pull/49948
-[#49949]: https://github.com/cockroachdb/cockroach/pull/49949
-[#49950]: https://github.com/cockroachdb/cockroach/pull/49950
-[#49961]: https://github.com/cockroachdb/cockroach/pull/49961
-[#49967]: https://github.com/cockroachdb/cockroach/pull/49967
-[#49979]: https://github.com/cockroachdb/cockroach/pull/49979
-[#49980]: https://github.com/cockroachdb/cockroach/pull/49980
-[#49995]: https://github.com/cockroachdb/cockroach/pull/49995
-[#50003]: https://github.com/cockroachdb/cockroach/pull/50003
-[#50010]: https://github.com/cockroachdb/cockroach/pull/50010
-[#50011]: https://github.com/cockroachdb/cockroach/pull/50011
-[#50016]: https://github.com/cockroachdb/cockroach/pull/50016
-[#50018]: https://github.com/cockroachdb/cockroach/pull/50018
-[#50071]: https://github.com/cockroachdb/cockroach/pull/50071
-[#50103]: https://github.com/cockroachdb/cockroach/pull/50103
-[#50110]: https://github.com/cockroachdb/cockroach/pull/50110
-[#50116]: https://github.com/cockroachdb/cockroach/pull/50116
-[#50143]: https://github.com/cockroachdb/cockroach/pull/50143
-[#50151]: https://github.com/cockroachdb/cockroach/pull/50151
-[#50153]: https://github.com/cockroachdb/cockroach/pull/50153
-[#50156]: https://github.com/cockroachdb/cockroach/pull/50156
-[#50161]: https://github.com/cockroachdb/cockroach/pull/50161
-[#50173]: https://github.com/cockroachdb/cockroach/pull/50173
-[#50185]: https://github.com/cockroachdb/cockroach/pull/50185
-[#50188]: https://github.com/cockroachdb/cockroach/pull/50188
-[#50192]: https://github.com/cockroachdb/cockroach/pull/50192
-[#50213]: https://github.com/cockroachdb/cockroach/pull/50213
-[#50245]: https://github.com/cockroachdb/cockroach/pull/50245
-[#50254]: https://github.com/cockroachdb/cockroach/pull/50254
-[#50255]: https://github.com/cockroachdb/cockroach/pull/50255
-[#50256]: https://github.com/cockroachdb/cockroach/pull/50256
-[#50257]: https://github.com/cockroachdb/cockroach/pull/50257
-[#50269]: https://github.com/cockroachdb/cockroach/pull/50269
-[#50275]: https://github.com/cockroachdb/cockroach/pull/50275
-[#50278]: https://github.com/cockroachdb/cockroach/pull/50278
-[#50280]: https://github.com/cockroachdb/cockroach/pull/50280
-[#50286]: https://github.com/cockroachdb/cockroach/pull/50286
-[#50292]: https://github.com/cockroachdb/cockroach/pull/50292
-[#50295]: https://github.com/cockroachdb/cockroach/pull/50295
-[#50297]: https://github.com/cockroachdb/cockroach/pull/50297
-[#50307]: https://github.com/cockroachdb/cockroach/pull/50307
-[#50311]: https://github.com/cockroachdb/cockroach/pull/50311
-[#50314]: https://github.com/cockroachdb/cockroach/pull/50314
-[#50320]: https://github.com/cockroachdb/cockroach/pull/50320
-[#50334]: https://github.com/cockroachdb/cockroach/pull/50334
-[#50348]: https://github.com/cockroachdb/cockroach/pull/50348
-[#50349]: https://github.com/cockroachdb/cockroach/pull/50349
-[#50351]: https://github.com/cockroachdb/cockroach/pull/50351
-[#50361]: https://github.com/cockroachdb/cockroach/pull/50361
-[#50362]: https://github.com/cockroachdb/cockroach/pull/50362
-[#50369]: https://github.com/cockroachdb/cockroach/pull/50369
-[#50371]: https://github.com/cockroachdb/cockroach/pull/50371
-[#50372]: https://github.com/cockroachdb/cockroach/pull/50372
-[#50402]: https://github.com/cockroachdb/cockroach/pull/50402
-[#50411]: https://github.com/cockroachdb/cockroach/pull/50411
-[#50417]: https://github.com/cockroachdb/cockroach/pull/50417
-[#50436]: https://github.com/cockroachdb/cockroach/pull/50436
-[#50441]: https://github.com/cockroachdb/cockroach/pull/50441
-[#50456]: https://github.com/cockroachdb/cockroach/pull/50456
-[#50457]: https://github.com/cockroachdb/cockroach/pull/50457
-[#50479]: https://github.com/cockroachdb/cockroach/pull/50479
-[#50483]: https://github.com/cockroachdb/cockroach/pull/50483
-[#50484]: https://github.com/cockroachdb/cockroach/pull/50484
-[#50492]: https://github.com/cockroachdb/cockroach/pull/50492
-[#50500]: https://github.com/cockroachdb/cockroach/pull/50500
-[#50532]: https://github.com/cockroachdb/cockroach/pull/50532
-[#50539]: https://github.com/cockroachdb/cockroach/pull/50539
-[#50546]: https://github.com/cockroachdb/cockroach/pull/50546
-[#50577]: https://github.com/cockroachdb/cockroach/pull/50577
-[#50582]: https://github.com/cockroachdb/cockroach/pull/50582
-[#50585]: https://github.com/cockroachdb/cockroach/pull/50585
-[#50589]: https://github.com/cockroachdb/cockroach/pull/50589
-[#50599]: https://github.com/cockroachdb/cockroach/pull/50599
-[#50626]: https://github.com/cockroachdb/cockroach/pull/50626
-[#50627]: https://github.com/cockroachdb/cockroach/pull/50627
-[#50633]: https://github.com/cockroachdb/cockroach/pull/50633
-[#50662]: https://github.com/cockroachdb/cockroach/pull/50662
-[#50665]: https://github.com/cockroachdb/cockroach/pull/50665
-[#50671]: https://github.com/cockroachdb/cockroach/pull/50671
-[#50674]: https://github.com/cockroachdb/cockroach/pull/50674
-[#50682]: https://github.com/cockroachdb/cockroach/pull/50682
-[#50697]: https://github.com/cockroachdb/cockroach/pull/50697
-[#50708]: https://github.com/cockroachdb/cockroach/pull/50708
-[#50722]: https://github.com/cockroachdb/cockroach/pull/50722
-[#50723]: https://github.com/cockroachdb/cockroach/pull/50723
-[#50727]: https://github.com/cockroachdb/cockroach/pull/50727
-[#50744]: https://github.com/cockroachdb/cockroach/pull/50744
-[#50759]: https://github.com/cockroachdb/cockroach/pull/50759
-[#50760]: https://github.com/cockroachdb/cockroach/pull/50760
-[#50769]: https://github.com/cockroachdb/cockroach/pull/50769
-[#50772]: https://github.com/cockroachdb/cockroach/pull/50772
-[#50773]: https://github.com/cockroachdb/cockroach/pull/50773
-[#50775]: https://github.com/cockroachdb/cockroach/pull/50775
-[#50791]: https://github.com/cockroachdb/cockroach/pull/50791
-[#50810]: https://github.com/cockroachdb/cockroach/pull/50810
-[#50815]: https://github.com/cockroachdb/cockroach/pull/50815
-[#50819]: https://github.com/cockroachdb/cockroach/pull/50819
-[#50831]: https://github.com/cockroachdb/cockroach/pull/50831
-[#50838]: https://github.com/cockroachdb/cockroach/pull/50838
-[#50845]: https://github.com/cockroachdb/cockroach/pull/50845
-[#50846]: https://github.com/cockroachdb/cockroach/pull/50846
-[#50850]: https://github.com/cockroachdb/cockroach/pull/50850
-[#50866]: https://github.com/cockroachdb/cockroach/pull/50866
-[#50898]: https://github.com/cockroachdb/cockroach/pull/50898
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-alpha.3.md b/src/current/_includes/releases/v20.2/v20.2.0-alpha.3.md
deleted file mode 100644
index fda62365424..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-alpha.3.md
+++ /dev/null
@@ -1,527 +0,0 @@
-## v20.2.0-alpha.3
-
-Release Date: August 25, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-alpha-3-backward-incompatible-changes">Backward-incompatible changes</h3>
-
-- A CockroachDB node started with [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) without the `--join` flag no longer automatically initializes the cluster. The `cockroach init` command is now mandatory. The auto-initialization behavior had been deprecated in version 19.2. [#51245][#51245]
-- Clusters running alphas of 20.2 that use `ENUM` types will not be able to upgrade to betas or major releases of 20.2 due to internal representation changes. [#52483][#52483]
-- Improved `WITH` option parsing for [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore). Does not allow the same option to be specified twice, and also prevents usage of quoted option names. [#52302][#52302]
-- The file names for heap profile dumps now use the naming scheme `memprof.<date-and-time>.<heapsize>`, where previously they were named `memprof.<heapsize>.<date-and-time>`. [#50446][#50446]
-
-<h3 id="v20-2-0-alpha-3-general-changes">General changes</h3>
-
-- [`cockroach node recommission`](https://www.cockroachlabs.com/docs/v20.2/remove-nodes#recommission-nodes) has new semantics. Previously it was able to recommission any decommissioning node, regardless of how long ago its was decommissioned, or removed from the cluster. Now `cockroach node recommission` serves to only cancel an accidental inflight decommissioning process that wasn't finalized. [#50329][#50329]
-- CPU profiles are now taken as part of the [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) command. [#50625][#50625]
-- CPU profiles taken from CockroachDB servers now contain more profiler labels related to ongoing SQL processing. [#50625][#50625]
-- The CockroachDB tarballs now include the `libgeos` and `libgeos_c` libraries, which are required to be copied to `/usr/local/lib/cockroach` for UNIX/MacOS systems to [perform certain geospatial operations](https://www.cockroachlabs.com/docs/v20.2/spatial-data). The Windows location will be finalized at a later date. This location is configurable with the `--geo-libs` flag to `cockroach start`. [#51108][#51108]
-- The Docker container that ships with CockroachDB now includes the [GEOS](https://www.cockroachlabs.com/docs/v20.2/spatial-glossary#geos) library needed for geospatial functionality in `/usr/local/lib/cockroach` (which is the default location where the `cockroach` binary looks for the GEOS libraries). [#51392][#51392]
-- [Timestamp](https://www.cockroachlabs.com/docs/v20.2/timestamp) functions are now supported by [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into). [#51390][#51390]
-- [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into) now supports `unique_rowid()` as a default expression. [#50922][#50922]
-- Previously, CockroachDB would spam its logs when undergoing network connectivity issues. This patch reduces the frequency of said spam. [#51937][#51937]
-- Reverted the Go version back to 1.13. [#52348][#52348]
-
-<h3 id="v20-2-0-alpha-3-enterprise-edition-changes">Enterprise edition changes</h3>
-
-- [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) has a new option `skip_missing_sequence_owners` that must be supplied when restoring only the table/sequence that was previously a sequence owner/owned by a table. Additionally, this fixes a bug where ownership relationships would not be remapped after a `RESTORE`. [#50949][#50949]
-- Disabled the use of [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import) with user defined types. Users should use [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into) instead. [#51149][#51149]
-- Added support for `BACKUP TENANT` and `RESTORE TENANT`. [#50967][#50967]
-- Implemented a `CREATE SCHEDULE FOR BACKUP` statement which allows the creation of periodic backup schedules. [#51308][#51308]
-- Implemented schedule control statements to pause, resume, or delete scheduled jobs. [#51896][#51896]
-- Added support for user-defined schemas in the `IMPORT` and `IMPORT INTO` statements. [#51936][#51936]
-- Added a `FOR SCHEDULES` clause to the job control statements to enable management of the jobs created by schedules. [#52038][#52038]
-- The `SHOW SCHEDULES` statement now displays information about the scheduled jobs. [#52230][#52230]
-- Added the ability to display jobs started by a specified schedule. [#52274][#52274]
-- Added a `BACKUP ... INTO` alternative to `BACKUP TO` which automatically picks a new path within the destination. [#52329][#52329]
-- The [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) statement now takes priority over other transactions if its initial attempts to export a range fail. [#51624][#51624]
-- Exported CSV files are now prepended with a long unique ID. This can help to mitigate situations where multiple export runs are written to the same directory, resulting in mixed data. This change does not prevent mixed data; rather, it makes it possible to identify files from distinct runs, so that an operator can clean up. [#52547][#52547]
-- Updated `IMPORT` so that it cannot be used to create tables in user-defined schemas. Users should instead create the table with `CREATE TABLE` and then use `IMPORT INTO`. [#52729][#52729]
-- The [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) statement can now run in "detached" mode. That is, instead of waiting for the `RESTORE` job to finish, the job ID is returned immediately, and the job itself runs in the background. [#52779][#52779]
-- Enabled [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) and [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) when user-defined schemas are in use. [#52588][#52588]
-
-<h3 id="v20-2-0-alpha-3-sql-language-changes">SQL language changes</h3>
-
-<h4 id="v20-2-0-alpha-3-general-sql-updates">General SQL updates</h4>
-
-- Added support for materialized views. [#52530][#52530]
-- Indexes are no longer required on the origin side of a [foreign key relationship](https://www.cockroachlabs.com/docs/v20.2/foreign-key), and are no longer automatically created. [#50771][#50771]
-- Added a `CREATE SCHEDULE FOR BACKUP` statement. This statement can be used to specify a recurring backup schedule. [#50631][#50631]
-- Removed the `SYMVAR` modifier to [`EXPLAIN (PLAN)`](https://www.cockroachlabs.com/docs/v20.2/explain). [#51349][#51349]
-- The [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) now supports the aggregate function `concat_agg`. [#51148][#51148]
-- Disallowed row-level locking in `READ-ONLY` transactions to be consistent with PostgreSQL behavior. [#51335][#51335]
-- Implemented the `datetime_precision` column in the `information_schema.columns` table for time-stored values. [#51352][#51352]
-- The `sql.log.slow_query.latency_threshold` cluster setting now requires an explicit unit when being set. (e.g., 500ms for  500 milliseconds, 5us for 5 nanoseconds, 5s for 5 seconds, etc.). An error with a hint pops up if the user fails to provide units. [#50632][#50632]
-- Added a deprecation notice for the use of [`ALTER TABLE .. RENAME`](https://www.cockroachlabs.com/docs/v20.2/alter-table) with a qualified name. [#51433][#51433]
-- Disabled using [`ALTER TABLE .. RENAME`](https://www.cockroachlabs.com/docs/v20.2/alter-table) to change the schema of a table. [#51433][#51433]
-- Unqualified names in the target of [`ALTER TABLE ... RENAME`](https://www.cockroachlabs.com/docs/v20.2/alter-table) are now treated as having the same database and schema as the table being renamed. [#51433][#51433]
-- Interleaved table joins now show up in [`EXPLAIN (PLAN)`](https://www.cockroachlabs.com/docs/v20.2/explain) output. [#51469][#51469]
-- The `pg_catalog.pg_attribute` table now contains the columns `attidentity` (unimplemented) and `attgenerated` (implemented, 's' for computed/generated columns). [#51466][#51466]
-- Made a minor change to remove the outdated CCL-only message from the [`GRANT`](https://www.cockroachlabs.com/docs/v20.2/grant-roles) and [`REVOKE ROLE`](https://www.cockroachlabs.com/docs/v20.2/revoke-roles) help messages. [#51465][#51465]
-- Added the `num_nulls` and `num_nonnulls` built-in functions, which count the number of arguments that are passed to them which are _NULL_ or non-_NULL_, respectively. [#51515][#51515]
-- `EXPLAIN (PLAN)` now shows any filter on a scan as a separate `filter` node. [#51493][#51493]
-- Added the `stddev_pop` and `var_pop` aggregate functions for population standard deviation and variance calculations. [#51447][#51447]
-- Added support for the `idle_in_session_timeout` variable to allow automatically terminating [sessions](https://www.cockroachlabs.com/docs/v20.2/show-sessions) that idle past a certain threshold. [#51223][#51223]
-- Added the cluster setting `sql.defaults.idle_in_session_timeout` for setting a default `idle_in_session_timeout` value for new sessions. This gives users the ability to set `idle_in_session_timeout` values for all newly created sessions. [#51223][#51223]
-- Added support for renaming a value of an `ENUM` using the `ALTER TYPE <type> RENAME VALUE <old> TO <new>` syntax. [#51490][#51490]
-- Exposed the MVCC timestamp of each row as a system column on the table. This column is named `crdb_internal_mvcc_timestamp` and is accessible only in a limited set of contexts. [#51494][#51494]
-- Transactions that have modified or created a type will execute queries on the local node, rather than distributing the queries to other nodes in the cluster. [#51784][#51784]
-- Casting [`TIMESTAMP`](https://www.cockroachlabs.com/docs/v20.2/timestamp) types to `TEXT`-related types now omits the timezone component. For example, `'2001-12-15 15:14:13'::TIMESTAMP` will now format as `'2001-12-15 15:14:13'` instead of `'2001-12-15 15:14:13+00:00'`. [#51692][#51692]
-- Added the built-in function `crdb_internal.approximate_timestamp` to convert the `DECIMAL` returned from the `crdb_internal_mvcc_timestamp` system column into a [`TIMESTAMP`](https://www.cockroachlabs.com/docs/v20.2/timestamp). [#51662][#51662]
-- [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) no longer shows the "hidden" annotation for columns. [#51837][#51837]
-- Previously, matching with `LIKE` supported the "prefix" notation `match(test%)` and "suffix" notation `match(%test)` This commit adds the "contains" notation `match(%test%)`. [#51636][#51636]
-- Dropping a column always drops all indexes that index the column. It is no longer necessary to provide the `CASCADE` option to [`DROP COLUMN`](https://www.cockroachlabs.com/docs/v20.2/drop-column). [#51661][#51661]
-- The [`SHOW CREATE`](https://www.cockroachlabs.com/docs/v20.2/show-create) statement now contains the schema of a table in the `CREATE` statement. [#50889][#50889]
-- The [`EXPORT`](https://www.cockroachlabs.com/docs/v20.2/export) statement no longer requires an enterprise license. [#52029][#52029]
-- `EXPLAIN (DISTSQL)` diagrams have been updated by switching table name with index name (previously, we had the syntax `index@table`, and now we have `table@index`). [#52085][#52085]
-- The 'bytes' and 'rows read' metrics are now tracked with mean and variance, similar to the other per-statement metrics. `crdb_internal.node_statement_statistics` has been updated to remove the `bytes_read` and `rows_read` columns, replacing them with `bytes_read_avg`, `bytes_read_var`, `rows_read_avg`, and `rows_read_var`. [#51630][#51630]
-- Added cosmetic improvements to [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) node naming. [#52195][#52195]
-- Added support for `ALTER TABLE/SEQUENCE/VIEW SET SCHEMA` to set the schema of the table to the target schema. One must have `DROP` privileges on the table and `CREATE` privileges on the schema to perform the operation. [#52090][#52090]
-- Added support for the setting and getting of the `synchronous_commit` and `enable_seqscan` variables, which do not affect any performance characteristics. These are no-ops enabled to allow certain tools to work. [#52168][#52168]
-- [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) no longer shows grouping columns as "aggregations" for the group operator. [#52232][#52232]
-- It's now possible to specify a KMS URI or a list of KMS URIs to encrypt [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) data/manifests with by passing the `kms` option to `BACKUP`. [#52091][#52091]
-- Query statistics now include the disk bytes and rows read from lookup and index [joins](https://www.cockroachlabs.com/docs/v20.2/joins), in addition to ordinary table scans. [#52237][#52237]
-- The value of `pg_class.atttypmod` and the TypeModifier in the RowDescription for array columns is now the same as the type modifier of the type of the array contents. This enhances compatibility with the PostgreSQL wire protocol. [#52428][#52428]
-- Added support for `ALTER TABLE ... ALTER COLUMN ... SET NULL` syntax for [`IMPORT PGDUMP`](https://www.cockroachlabs.com/docs/v20.2/import#import-a-postgres-database-dump) type backups. [#52442][#52442]
-- Added a hint for `"line too long"` errors when importing a backup with long lines. [#52432][#52432]
-- Added "ownership" concept objects. Objects must now have an owner; all objects that do not have owners currently will have `admin` set as the default owner except system objects. System objects without owners will have `node` as their owner. By default, owners are the creator of the object. Owners have all privileges to the objects they own. Similarly, any [roles](https://www.cockroachlabs.com/docs/v20.2/authorization#create-and-manage-roles) that are members of the owner role also have all privileges on the object. Roles cannot be dropped if they own objects. This PR does not add support for changing the ownership of objects; that will be added in a future PR to support dropping roles. [#51856][#51856]
-- When using [`IMPORT PGDUMP`](https://www.cockroachlabs.com/docs/v20.2/import#import-a-postgres-database-dump) with [`INSERT INTO`](https://www.cockroachlabs.com/docs/v20.2/insert) clauses, specifying a column name that is case sensitive (e.g., `"cApItAls"`)  would previously error specifying the column name was not found. This has been fixed. [#52485][#52485]
-- Added the `pg_get_serial_sequence` built-in function. [#52436][#52436]
-- Added support for the `ALTER TYPE SET SCHEMA` command to set the schema of a user-defined type. The user must have `CREATE` privileges on the schema and `DROP` privileges on the type to set the schema. [#52301][#52301]
-- Added a new statement `SHOW ENUMS` which displays information on existing enums. [#52538][#52538]
-- Added support for the `BINARY` format for `COPY FROM`. [#51890][#51890]
-- Previously, [`IMPORT PGDUMP`](https://www.cockroachlabs.com/docs/v20.2/import#import-a-postgres-database-dump) using `COPY` required all rows to be present in the same order as the table definition. This restriction has been removed. [#52488][#52488]
-- Added a notice that is displayed to the user when she tries to add a value which already exists in an `ENUM`. [#52534][#52534]
-- Modified [`SHOW TABLES`](https://www.cockroachlabs.com/docs/v20.2/show-tables) to return estimates of the number of rows in each table. The new column's name is `estimated_row_count`. The number of rows is taken from the `system.table_statistics` table (via `crdb_internal.table_row_statistics`, which shows only tables accessible to the current user). [#52203][#52203]
-- Implemented the `regexp_split_to_table` and `regexp_split_to_array` built-in functions. [#52479][#52479]
-- Added support for the `CREATE UNLOGGED TABLE` syntax to be parsed and recorded internally by CockroachDB. However, this syntax does not modify the behavior of the table. [#52596][#52596]
-- Added support for the use of `CREATE INDEX ... WITH ...` syntax. [#52640][#52640]
-- `"no inbound stream connection"` errors should happen less frequently due to the addition of connection retries. [#52624][#52624]
-- Extended the [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) statement to support the 'KMS' option. This can be used to decrypt encrypted [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup)(s). [#52434][#52434]
-- Added support for parsing the syntax `CREATE TABLE ... WITH (autovacuum_enabled = bool)`, which results in a no-op. [#52652][#52652]
-- Added various improvements to [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain). [#52730][#52730]
-- Implemented the `ALTER SCHEMA RENAME TO` command. [#52349][#52349]
-- The [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) now fully supports comparison operators (things like `ILIKE`, `IS NOT DISTINCT FROM`, `SIMILAR TO`, and several others). [#52313][#52313]
-- The `experimental_follower_read_timestamp()` function has been renamed to `follower_read_timestamp()`, signifying more confidence in CockroachDB's [follower read](https://www.cockroachlabs.com/docs/v20.2/follower-reads) implementation. The previous name remains a supported alias. [#52359][#52359]
-- The reserved, non-documented cluster settings `server.heap_profile.*` have been renamed to `server.mem_profile.*`. They now control collection of multiple types of memory profiles besides just Go heap allocations. [#50446][#50446]
-
-<h4 id="v20-2-0-alpha-3-spatial-support-updates">Spatial support updates</h4>
-
-{{site.data.alerts.callout_info}}
-For instructions showing how to get started with CockroachDB Spatial, see [Working with Spatial Data](https://www.cockroachlabs.com/docs/v20.2/spatial-data).
-{{site.data.alerts.end}}
-
-- Implemented the `ST_MakePolygon` function for `GEOMETRY` types. [#50979][#50979]
-- Added a variant of each index-backed geospatial function that is prefixed with a `_` (e.g., `ST_Covers` gets a non-index-accelerated variant called `_ST_Covers`). These prefixed variants avoid using the spatial index while providing the same functionality. [#51225][#51225]
-- Implemented the `ST_DistanceSphere` and `ST_DistanceSpheroid` operators for `GEOMETRY` types. [#51461][#51461]
-- Implemented the `ST_ConvexHull` function on `GEOMETRY` types. [#51446][#51446]
-- Implemented the `ST_Disjoint` built-in function for `GEOMETRY` types. [#51444][#51444]
-- Added support for the `USING GIST` syntax to create a [GIN index](https://www.cockroachlabs.com/docs/v20.2/inverted-indexes) on `GEOMETRY` and `GEOGRAPHY` columns. [#51516][#51516]
-- Implemented the `ST_IsValid`, `ST_IsValidReason` and `ST_MakeValid` operators for `GEOMETRY` types. [#51484][#51484]
-- Implemented the `ST_Force2D` functionality for `GEOMETRY` types. [#51514][#51514]
-- Updated geospatial functions that take in a string argument such that when an ambiguous function that could be referring to either `GEOMETRY` or `GEOGRAPHY` types is encountered, the `GEOMETRY` type is chosen. This is the case for the following functions: `st_area`, `st_asewkt`, `st_asgeojson`, `st_buffer`, `st_coveredby`, `st_covers`, `st_distance`, `st_dwithin`, `st_intersects`, and `st_length`. [#51563][#51563]
-- Implemented `ST_Length2D` and `ST_Perimeter2D` for `GEOMETRY` types. [#51556][#51556]
-- Implemented `ST_Envelope` for `GEOMETRY` types. [#51604][#51604]
-- Added the `ST_RelatePattern` built-in function, which checks whether a given [DE-9IM intersection matrix](https://wikipedia.org/wiki/DE-9IM) matches a given pattern. [#51858][#51858]
-- Implemented `ST_GeoHash` for `GEOMETRY` and `GEOGRAPHY` types. [#50611][#50611]
-- Implemented the `ST_Buffer` and `ST_Intersection` functions for `GEOGRAPHY` types. [#51537][#51537]
-- Implemented the `ST_Intersection` function for [`STRING`](https://www.cockroachlabs.com/docs/v20.2/string) types. [#51537][#51537]
-- When [ordering by](https://www.cockroachlabs.com/docs/v20.2/order-by) geospatial columns, they will now be ordered by the [Hilbert Space-filling Curve](https://wikipedia.org/wiki/Hilbert_curve) index so that points which are geographically similar are clustered together. [#51898][#51898]
-- Implemented the `GEOMETRY` built-in function `ST_Translate`. [#51483][#51483]
-- Implemented the `GEOMETRY` built-in function `ST_Scale`. [#52350][#52350]
-- Implemented the `ST_MakeLine` aggregate built-in function. [#52631][#52631]
-- Implemented the `GEOMETRY` built-in function `ST_SetPoint`. [#52655][#52655]
-- Added aliases for `GeomFromEWKT` to `ST_GeomFromEWKT` and `GeomFromEWKB` to `ST_GeomFromEWKB`. [#52789][#52789]
-- Added `ST_AsGeoJSON` for recordsets, putting row contents into the properties field of a [GeoJSON](https://geojson.org) object. [#52715][#52715]
-
-<h3 id="v20-2-0-alpha-3-command-line-changes">Command-line changes</h3>
-
-- Added a set of `statement-diag` CLI commands that can be used to manage statement diagnostics. [#50924][#50924]
-- Introduced a `membership` column to the output generated by `cockroach node status --decommission`. It should be used in favor of the `is_decommissioning` column going forward. [#50329][#50329]
-- The v20.2 CLI [`cockroach node`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node) family of subcommands will not work with servers running older versions of `cockroach`, but the v20.1 CLI `cockroach node` subcommands will work against v20.2 servers. [#50329][#50329]
-- The `is_decommissioning` column found in the output of [`cockroach node decommission`](https://www.cockroachlabs.com/docs/v20.2/remove-nodes) is slated for removal in v20.1. Operators should instead use the new `membership` column to determine node membership status. [#50329][#50329]
-- The `--wait` flag to [`cockroach node decommission`](https://www.cockroachlabs.com/docs/v20.2/remove-nodes) now takes any of the following values:
-    - `all` waits until all target nodes' replica counts have dropped to zero and marks the nodes as fully decommissioned. This is the default.
-    - `none` marks the targets as decommissioning, but does not wait for the replica counts to drop to zero before returning. If the replica counts are found to be zero, nodes are marked as fully decommissioned. Use when polling manually from an external system. [#50329][#50329]
-- The `statement-diag` CLI command will now show all times in UTC. [#51185][#51185]
-- Added a `userfile upload` command that can be used to upload a file to the user scoped blob storage: `userfile upload source/file /destination/of/file` [#50981][#50981]
-- `SIGQUIT` now causes a CockroachDB server to log its stack traces without shutting down. [#50774][#50774]
-- Added Kerberos (GSS) support to [`cockroach sql`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql) and other CLI commands that only use the SQL protocol (such as [`node ls`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node), or `node status`). Other `cockroach` CLI commands that also use the RPC protocol still cannot use Kerberos (such as `node decommission`, `debug zip`, etc.). [#51570][#51570]
-- Improved the user semantics for `userfile upload` by supporting different patterns of specifying the source and destination CLI arguments. The source argument is required, while the destination argument is now optional. [#51353][#51353]
-- Changed the Kerberos URL connection string parameters to the standard `krbsrvname` (previously `service`) and `krbspn` (previously `spn`). [#51947][#51947]
-- Updated the label used for the commit ID in the printed version info. [#52263][#52263]
-- [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) now supports dumping databases that contain user-defined schemas, as well as accepting schema-qualified table names as arguments. [#52079][#52079]
-- The `userfile` command now supports an `ls` command which allows users to list the files they have uploaded to the user-scoped FileTableStorage. `userfile ls` accepts a single, optional CLI argument which can either be a well-formed userfile URI or a glob pattern. The latter defaults to searching in the default FileTableStorage table `defaultdb.public.userfiles_$USERNAME`. [#51482][#51482]
-- The `userfile` command now supports a delete command, which allows users to delete the files they have uploaded to the user-scoped `FileTableStorage`. `userfile delete` accepts one CLI argument which can either be a well-formed userfile URI or a glob pattern. The latter defaults to searching in the default `FileTableStorage` table `defaultdb.public.userfiles_$USERNAME`. [#51610][#51610]
-- CockroachDB now better attempts to retain heap profile dumps after a crash due to an out-of-memory (OOM) error. [#50446][#50446]
-- CockroachDB now better attempts to retain memory statistics corresponding to increases in total memory usage, not just heap allocations. [#50446][#50446]
-- Crashes in [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo) sessions are now reported to telemetry, [if telemetry is enabled](https://www.cockroachlabs.com/docs/v20.2/diagnostics-reporting). [#52696][#52696]
-
-<h3 id="v20-2-0-alpha-3-db-console-changes">DB Console changes</h3>
-
-- Removed the **Now** button for the "From" timepicker in the custom time range on the **Metrics** page. [#51047][#51047]
-- Updated the node label in chart legends to make the node ID visible. [#50434][#50434]
-- Updated DB Console database page styles to match the Cockroach Labs design system. [#47753][#47753]
-- Updated link on login page for secure clusters to point to a moved documentation URL. [#51862][#51862]
-- The **Statement Details** page now contains statistics for rows and disk bytes read. [#51630][#51630]
-- The time range selector (on the **Metrics** page) now shows time in UTC instead of local time, with a "(UTC)" prefix after the time to highlight this in the UI. [#51056][#51056]
-
-<h3 id="v20-2-0-alpha-3-bug-fixes">Bug fixes</h3>
-
-- Fixed an internal error that occurred when `AddGeometryColumn` was called with _NULL_ arguments. This now results in a no-op and returns _NULL_. [#50992][#50992]
-- Previously, CockroachDB could crash when internal memory accounting hit a discrepancy. Now it will report an error instead. [#50962][#50962]
-- Fixed the "column not in input" internal error in cases involving lookup semi/anti joins. [#50993][#50993]
-- Added better support for large statement [diagnostic bundles](https://www.cockroachlabs.com/docs/v20.2/explain-analyze#debug-option). [#50974][#50974]
-- Previously, if there was a table `t(a int, b int)`, and a sequence `seq` that was first owned by `t.a` and then altered to be owned by `t.b`, it would make the table `t` impossible to drop. This is now fixed. [#50720][#50720]
-- The `age` function previously did not normalize the duration for large day or `H:M:S` values in the same way PostgreSQL does. This is now fixed. [#51054][#51054]
-- Fixed an internal error in some cases involving `COALESCE` with _NULL_ inputs. [#51022][#51022]
-- Fixed a bug where very long-running [incremental backups](https://www.cockroachlabs.com/docs/v20.2/backup#incremental-backups) could fail if the data they were backing up was garbage collected. [#51069][#51069]
-- Fixed a bug causing the raw trace file collected inside a statement [diagnostics bundle](https://www.cockroachlabs.com/docs/v20.2/explain-analyze#debug-option) to be sometimes empty when the cluster setting `sql.trace.txn.enable_threshold` was in use. [#50914][#50914]
-- Prevented spurious `"SimpleQuery not allowed while in extended protocol mode"` errors. [#51194][#51194]
-- Previously, CockroachDB could hit an internal error when executing the `regexp_replace` built-in function; this has been fixed. [#51303][#51303]
-- Fixed an internal error involving [`CASE` statements](https://www.cockroachlabs.com/docs/v20.2/scalar-expressions#simple-case-expressions) and boolean expressions with _NULL_ operands. [#51154][#51154]
-- [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import) no longer fails when run in a database which has a user with privileges on the database. [#51315][#51315]
-- [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) no longer fails with an error when dumping [temporary tables](https://www.cockroachlabs.com/docs/v20.2/temporary-tables), views, or sequences. It either ignores them or throws an informative error if the temporary object is explicitly requested to be dumped via the CLI. [#51185][#51185]
-- Fixed incorrect results in some cases involving [joins](https://www.cockroachlabs.com/docs/v20.2/joins) on [interleaved tables](https://www.cockroachlabs.com/docs/v20.2/interleave-in-parent) with [limits](https://www.cockroachlabs.com/docs/v20.2/limit-offset). [#51398][#51398]
-- Fixed a bug where [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) would not properly escape quotes within [table comments](https://www.cockroachlabs.com/docs/v20.2/comment-on). [#51463][#51463]
-- Fixed a bug where [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) would not emit a correct statement for comments on indexes. [#51463][#51463]
-- Fixed a bug in the pgwire protocol implementation where CockroachDB would not correctly populate the `TableOID` and `TableAttributeNumber` fields in the `RowDescription` message of a prepared statement correctly. [#51479][#51479]
-- Some queries in the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) could previously hang during cleanup. This is now fixed. [#51375][#51375]
-- Previously, users could not drop tables or sequences with invalid internal state due to circular ownership issues. This is now fixed. [#51253][#51253]
-- Updated the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) to show the same statistics for 'rows'/'bytes read' as the row-at-a-time engine. [#51591][#51591]
-- Previously, CockroachDB could throw a "command is too large" error when performing [`UPSERT`](https://www.cockroachlabs.com/docs/v20.2/upsert) operations with many values. Internally, we attempted to perform such operations by splitting them into "batches", but the batching mechanism was broken. This is now fixed. [#51608][#51608]
-- It is no longer possible for rapid range lease movement to trigger a rare assertion failure under contended workloads. The assertion contained the text: `"discovered lock by different transaction than existing lock"`. [#51615][#51615]
-- CockroachDB now tracks the location of follower replicas for all ranges much more effectively than before. This means that more queries will be successfully served as ["follower reads"](https://www.cockroachlabs.com/docs/v20.2/follower-reads). [#51437][#51437]
-- Before this change, we would leave orphaned `system.namespace`/`system.descriptor` entries if we ran a [`DROP DATABASE CASCADE`](https://www.cockroachlabs.com/docs/v20.2/drop-database) and the database contained "dependency" relations. For example, if the database included a view which depended on a table in the database, dropping the database would result in an orphaned entry for the view. Same thing for a sequence that was used by a table in the database. (See [#51782][#51782] for reproduction steps). This bug is now fixed, and cleanup of entries happens as expected. [#51813][#51813]
-- Fixed instances of slow plans for prepared queries involving [CTEs](https://www.cockroachlabs.com/docs/v20.2/common-table-expressions) or [foreign key checks](https://www.cockroachlabs.com/docs/v20.2/foreign-key). [#51788][#51788]
-- Fixed the `"unhandled op: json-object-agg"` internal error. [#51881][#51881]
-- CockroachDB would previously emit benign internal "context canceled" errors when queries were executed by the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). This is now fixed. [#51772][#51772]
-- Added better detection of invalid computed column or partial index predicates that contain context-dependent operators. [#51886][#51886]
-- Increased robustness of [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) against descriptors which may be in an unexpected state. [#51848][#51848]
-- Previously, CockroachDB could return incorrect results on query that encountered a [`ReadWithinUncertaintyInterval`](https://www.cockroachlabs.com/docs/v20.2/transaction-retry-error-reference#readwithinuncertaintyinterval) error, and this has been fixed. [#51518][#51518]
-- Previously, a [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) job would block once it had finished backing up the data. This is now fixed. [#51999][#51999]
-- Previously, [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) would sometimes block at the end of the job when sending its results back if the connection that started the job disconnected. This is now fixed. [#51999][#51999]
-- `COPY` previously did not allow a backslash of any character other than the special table set. CockroachDB would emit an error in these cases. This behavior is changed to allow any character after a backslash and interpret it to mean the character itself to match the behavior of PostgreSQL (e.g., now `\a` will be interpreted as `a`). Furthermore, non hex-digits following a `\x` are now interpreted without the backslash, (e.g., `\xH` will be interpreted as `xH`). Strings ending with a single backslash will use the backslash (e.g., `x\\` is interpreted as `x\`). [#52068][#52068]
-- Fixed an internal error that could occur when an aggregate function argument contained a [correlated subquery](https://www.cockroachlabs.com/docs/v20.2/subqueries#correlated-subqueries) with another aggregate function referencing the outer scope. This now returns an appropriate user-friendly error: `"aggregate function calls cannot be nested"`. [#52092][#52092]
-- CockroachDB could previously crash on some queries with [merge joins](https://www.cockroachlabs.com/docs/v20.2/joins#merge-joins); this has now been fixed. [#52042][#52042]
-- Resolved an internal error that occurred with 0-argument built-in functions in the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). [#52103][#52103]
-- Previously, subtracting months from a [`TIMESTAMP`](https://www.cockroachlabs.com/docs/v20.2/timestamp)/`DATE`/`TIMESTAMPTZ` whose date value was greater than 28 could subtract a further year off. This is now fixed. [#52138][#52138]
-- Fixed an issue where large write requests no longer have a chance of erroneously throwing a `"transaction with sequence has a different value"` error. [#52234][#52234]
-- Previously, shutting down a connection with an open transaction that had active [temporary tables](https://www.cockroachlabs.com/docs/v20.2/temporary-tables) caused deadlocks or general brokenness. This was because the table cleanup was done inside of the open transaction. This commit moves the table cleanup to be after the user transaction is shut down. [#52148][#52148]
-- Fixed a rare bug that could cause actionable [closed timestamps](https://www.cockroachlabs.com/docs/v20.2/follower-reads#how-follower-reads-work) to effectively regress over a given keyspan. This could in turn lead to a serializability violation when using follower reads. This was due to ill-defined interactions between [range merges](https://www.cockroachlabs.com/docs/v20.2/architecture/distribution-layer#range-merges) and the closed timestamp subsystem. [#50265][#50265]
-- Updated the functions `crdb_version()` and `version()` to return the same result. [#52032][#52032]
-- Fixed a bug with the temporary object cleaner where it was stuck trying to remove objects that it mistakenly thought were temporary. Note that no persistent data was deleted -- the temporary cleaner would throw an error out because it thought certain persistent data was temporary. [#51359][#51359]
-- Fixed a bug when using the `COPY` protocol which could prevent [schema changes](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes) for up to 5 minutes. [#52384][#52384]
-- Previously, CockroachDB would erroneously restart the execution of empty, unclosed portals after they had been fully exhausted. This has been fixed. [#48842][#48842]
-- Updated [`IMPORT PGDUMP`](https://www.cockroachlabs.com/docs/v20.2/import) and `IMPORT MYSQLDUMP` to reject specifying multiple files. [#52500][#52500]
-- Fixed an internal error involving string literals used as arrays. [#52416][#52416]
-- Fixed a bug where jobs could fail to run during version upgrades. [#52475][#52475]
-- Don't display a value for [`gc.ttlseconds`](https://www.cockroachlabs.com/docs/v20.2/configure-replication-zones) in the [DB Console](https://www.cockroachlabs.com/docs/v20.2/ui-overview) if it is not set. [#52721][#52721]
-- Updated CockroachDB's handling of an unknown condition that would previously crash a node with the message `"committed txn with writeTooOld err"`. This condition no longer crashes a node; instead, an error message is printed to [the logs](https://www.cockroachlabs.com/docs/v20.2/debug-and-error-logs) asking for help in the investigation. [#51619][#51619]
-
-<h3 id="v20-2-0-alpha-3-performance-improvements">Performance improvements</h3>
-
-- `SELECT IN` performance on longer filter rows was improved in the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) by replacing a linear scan with binary search. [#50337][#50337]
-- Improved the efficiency of garbage collection when there are a large number of versions of a single key, commonly found when utilizing sequences. [#51184][#51184]
-- Scans over the virtual table `pg_type` by the OID column have improved performance in common cases. [#51374][#51374]
-- Queries no longer block during planning if cached table statistics have become stale and the new statistics have not yet been loaded. Instead, the stale statistics are used for planning until the new statistics have been loaded. This improves performance because it prevents latency spikes that may occur if there is a delay in loading the new statistics. [#51616][#51616]
-- Modified the cardinality estimate for index-accelerated geospatial functions to make it more likely for the optimizer to choose a geospatial GIN index join during query planning. This results in more efficient plans in most cases. [#51963][#51963]
-- Added support for performing joins using geospatial GIN indexes in a wider variety of cases. Complex boolean predicates combining multiple index-accelerated geospatial functions are now supported as join conditions. [#52376][#52376]
-- Previously, histogram statistics were only collected for the first column of each index. Now they are collected for each indexed column, allowing the optimizer to more accurately estimate costs of query plans. [#52448][#52448]
-- Unnecessary mutex contention observed in heavy read workloads has been removed. [#51055][#51055]
-- Ranges recover moderately faster when their leaseholder is briefly down before becoming live again. [#51888][#51888]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-0-alpha-3-contributors">Contributors</h3>
-
-This release includes 634 merged PRs by 59 authors.
-
-We would like to thank the following contributors from the CockroachDB community:
-
-- Andrii Vorobiov
-- Eugene Kalinin (first-time contributor)
-- Juan Carlos (first-time contributor)
-- Vaibhav (first-time contributor)
-- Vincent Xiao (first-time contributor)
-- Yongyang Lai
-- dujin (first-time contributor)
-- himanshuchawla009 (first-time contributor)
-- manhhiep92 (first-time contributor)
-- xuhui-lu (first-time contributor)
-
-</div>
-
-[#46259]: https://github.com/cockroachdb/cockroach/pull/46259
-[#47753]: https://github.com/cockroachdb/cockroach/pull/47753
-[#48842]: https://github.com/cockroachdb/cockroach/pull/48842
-[#50265]: https://github.com/cockroachdb/cockroach/pull/50265
-[#50329]: https://github.com/cockroachdb/cockroach/pull/50329
-[#50337]: https://github.com/cockroachdb/cockroach/pull/50337
-[#50434]: https://github.com/cockroachdb/cockroach/pull/50434
-[#50446]: https://github.com/cockroachdb/cockroach/pull/50446
-[#50503]: https://github.com/cockroachdb/cockroach/pull/50503
-[#50520]: https://github.com/cockroachdb/cockroach/pull/50520
-[#50611]: https://github.com/cockroachdb/cockroach/pull/50611
-[#50625]: https://github.com/cockroachdb/cockroach/pull/50625
-[#50631]: https://github.com/cockroachdb/cockroach/pull/50631
-[#50632]: https://github.com/cockroachdb/cockroach/pull/50632
-[#50648]: https://github.com/cockroachdb/cockroach/pull/50648
-[#50720]: https://github.com/cockroachdb/cockroach/pull/50720
-[#50771]: https://github.com/cockroachdb/cockroach/pull/50771
-[#50774]: https://github.com/cockroachdb/cockroach/pull/50774
-[#50889]: https://github.com/cockroachdb/cockroach/pull/50889
-[#50913]: https://github.com/cockroachdb/cockroach/pull/50913
-[#50914]: https://github.com/cockroachdb/cockroach/pull/50914
-[#50921]: https://github.com/cockroachdb/cockroach/pull/50921
-[#50922]: https://github.com/cockroachdb/cockroach/pull/50922
-[#50924]: https://github.com/cockroachdb/cockroach/pull/50924
-[#50949]: https://github.com/cockroachdb/cockroach/pull/50949
-[#50962]: https://github.com/cockroachdb/cockroach/pull/50962
-[#50967]: https://github.com/cockroachdb/cockroach/pull/50967
-[#50974]: https://github.com/cockroachdb/cockroach/pull/50974
-[#50979]: https://github.com/cockroachdb/cockroach/pull/50979
-[#50981]: https://github.com/cockroachdb/cockroach/pull/50981
-[#50992]: https://github.com/cockroachdb/cockroach/pull/50992
-[#50993]: https://github.com/cockroachdb/cockroach/pull/50993
-[#50994]: https://github.com/cockroachdb/cockroach/pull/50994
-[#51022]: https://github.com/cockroachdb/cockroach/pull/51022
-[#51047]: https://github.com/cockroachdb/cockroach/pull/51047
-[#51054]: https://github.com/cockroachdb/cockroach/pull/51054
-[#51055]: https://github.com/cockroachdb/cockroach/pull/51055
-[#51056]: https://github.com/cockroachdb/cockroach/pull/51056
-[#51069]: https://github.com/cockroachdb/cockroach/pull/51069
-[#51079]: https://github.com/cockroachdb/cockroach/pull/51079
-[#51086]: https://github.com/cockroachdb/cockroach/pull/51086
-[#51108]: https://github.com/cockroachdb/cockroach/pull/51108
-[#51148]: https://github.com/cockroachdb/cockroach/pull/51148
-[#51149]: https://github.com/cockroachdb/cockroach/pull/51149
-[#51154]: https://github.com/cockroachdb/cockroach/pull/51154
-[#51184]: https://github.com/cockroachdb/cockroach/pull/51184
-[#51185]: https://github.com/cockroachdb/cockroach/pull/51185
-[#51194]: https://github.com/cockroachdb/cockroach/pull/51194
-[#51218]: https://github.com/cockroachdb/cockroach/pull/51218
-[#51223]: https://github.com/cockroachdb/cockroach/pull/51223
-[#51225]: https://github.com/cockroachdb/cockroach/pull/51225
-[#51226]: https://github.com/cockroachdb/cockroach/pull/51226
-[#51243]: https://github.com/cockroachdb/cockroach/pull/51243
-[#51245]: https://github.com/cockroachdb/cockroach/pull/51245
-[#51247]: https://github.com/cockroachdb/cockroach/pull/51247
-[#51253]: https://github.com/cockroachdb/cockroach/pull/51253
-[#51303]: https://github.com/cockroachdb/cockroach/pull/51303
-[#51308]: https://github.com/cockroachdb/cockroach/pull/51308
-[#51310]: https://github.com/cockroachdb/cockroach/pull/51310
-[#51315]: https://github.com/cockroachdb/cockroach/pull/51315
-[#51335]: https://github.com/cockroachdb/cockroach/pull/51335
-[#51349]: https://github.com/cockroachdb/cockroach/pull/51349
-[#51352]: https://github.com/cockroachdb/cockroach/pull/51352
-[#51353]: https://github.com/cockroachdb/cockroach/pull/51353
-[#51359]: https://github.com/cockroachdb/cockroach/pull/51359
-[#51374]: https://github.com/cockroachdb/cockroach/pull/51374
-[#51375]: https://github.com/cockroachdb/cockroach/pull/51375
-[#51390]: https://github.com/cockroachdb/cockroach/pull/51390
-[#51392]: https://github.com/cockroachdb/cockroach/pull/51392
-[#51398]: https://github.com/cockroachdb/cockroach/pull/51398
-[#51433]: https://github.com/cockroachdb/cockroach/pull/51433
-[#51437]: https://github.com/cockroachdb/cockroach/pull/51437
-[#51444]: https://github.com/cockroachdb/cockroach/pull/51444
-[#51446]: https://github.com/cockroachdb/cockroach/pull/51446
-[#51447]: https://github.com/cockroachdb/cockroach/pull/51447
-[#51461]: https://github.com/cockroachdb/cockroach/pull/51461
-[#51462]: https://github.com/cockroachdb/cockroach/pull/51462
-[#51463]: https://github.com/cockroachdb/cockroach/pull/51463
-[#51465]: https://github.com/cockroachdb/cockroach/pull/51465
-[#51466]: https://github.com/cockroachdb/cockroach/pull/51466
-[#51469]: https://github.com/cockroachdb/cockroach/pull/51469
-[#51479]: https://github.com/cockroachdb/cockroach/pull/51479
-[#51482]: https://github.com/cockroachdb/cockroach/pull/51482
-[#51483]: https://github.com/cockroachdb/cockroach/pull/51483
-[#51484]: https://github.com/cockroachdb/cockroach/pull/51484
-[#51490]: https://github.com/cockroachdb/cockroach/pull/51490
-[#51493]: https://github.com/cockroachdb/cockroach/pull/51493
-[#51494]: https://github.com/cockroachdb/cockroach/pull/51494
-[#51514]: https://github.com/cockroachdb/cockroach/pull/51514
-[#51515]: https://github.com/cockroachdb/cockroach/pull/51515
-[#51516]: https://github.com/cockroachdb/cockroach/pull/51516
-[#51518]: https://github.com/cockroachdb/cockroach/pull/51518
-[#51537]: https://github.com/cockroachdb/cockroach/pull/51537
-[#51556]: https://github.com/cockroachdb/cockroach/pull/51556
-[#51563]: https://github.com/cockroachdb/cockroach/pull/51563
-[#51570]: https://github.com/cockroachdb/cockroach/pull/51570
-[#51591]: https://github.com/cockroachdb/cockroach/pull/51591
-[#51604]: https://github.com/cockroachdb/cockroach/pull/51604
-[#51605]: https://github.com/cockroachdb/cockroach/pull/51605
-[#51608]: https://github.com/cockroachdb/cockroach/pull/51608
-[#51609]: https://github.com/cockroachdb/cockroach/pull/51609
-[#51610]: https://github.com/cockroachdb/cockroach/pull/51610
-[#51615]: https://github.com/cockroachdb/cockroach/pull/51615
-[#51616]: https://github.com/cockroachdb/cockroach/pull/51616
-[#51619]: https://github.com/cockroachdb/cockroach/pull/51619
-[#51624]: https://github.com/cockroachdb/cockroach/pull/51624
-[#51627]: https://github.com/cockroachdb/cockroach/pull/51627
-[#51630]: https://github.com/cockroachdb/cockroach/pull/51630
-[#51636]: https://github.com/cockroachdb/cockroach/pull/51636
-[#51645]: https://github.com/cockroachdb/cockroach/pull/51645
-[#51661]: https://github.com/cockroachdb/cockroach/pull/51661
-[#51662]: https://github.com/cockroachdb/cockroach/pull/51662
-[#51691]: https://github.com/cockroachdb/cockroach/pull/51691
-[#51692]: https://github.com/cockroachdb/cockroach/pull/51692
-[#51694]: https://github.com/cockroachdb/cockroach/pull/51694
-[#51704]: https://github.com/cockroachdb/cockroach/pull/51704
-[#51772]: https://github.com/cockroachdb/cockroach/pull/51772
-[#51777]: https://github.com/cockroachdb/cockroach/pull/51777
-[#51782]: https://github.com/cockroachdb/cockroach/pull/51782
-[#51784]: https://github.com/cockroachdb/cockroach/pull/51784
-[#51788]: https://github.com/cockroachdb/cockroach/pull/51788
-[#51807]: https://github.com/cockroachdb/cockroach/pull/51807
-[#51813]: https://github.com/cockroachdb/cockroach/pull/51813
-[#51816]: https://github.com/cockroachdb/cockroach/pull/51816
-[#51837]: https://github.com/cockroachdb/cockroach/pull/51837
-[#51848]: https://github.com/cockroachdb/cockroach/pull/51848
-[#51856]: https://github.com/cockroachdb/cockroach/pull/51856
-[#51858]: https://github.com/cockroachdb/cockroach/pull/51858
-[#51862]: https://github.com/cockroachdb/cockroach/pull/51862
-[#51870]: https://github.com/cockroachdb/cockroach/pull/51870
-[#51881]: https://github.com/cockroachdb/cockroach/pull/51881
-[#51886]: https://github.com/cockroachdb/cockroach/pull/51886
-[#51888]: https://github.com/cockroachdb/cockroach/pull/51888
-[#51890]: https://github.com/cockroachdb/cockroach/pull/51890
-[#51896]: https://github.com/cockroachdb/cockroach/pull/51896
-[#51898]: https://github.com/cockroachdb/cockroach/pull/51898
-[#51921]: https://github.com/cockroachdb/cockroach/pull/51921
-[#51936]: https://github.com/cockroachdb/cockroach/pull/51936
-[#51937]: https://github.com/cockroachdb/cockroach/pull/51937
-[#51939]: https://github.com/cockroachdb/cockroach/pull/51939
-[#51947]: https://github.com/cockroachdb/cockroach/pull/51947
-[#51963]: https://github.com/cockroachdb/cockroach/pull/51963
-[#51964]: https://github.com/cockroachdb/cockroach/pull/51964
-[#51999]: https://github.com/cockroachdb/cockroach/pull/51999
-[#52006]: https://github.com/cockroachdb/cockroach/pull/52006
-[#52029]: https://github.com/cockroachdb/cockroach/pull/52029
-[#52032]: https://github.com/cockroachdb/cockroach/pull/52032
-[#52034]: https://github.com/cockroachdb/cockroach/pull/52034
-[#52038]: https://github.com/cockroachdb/cockroach/pull/52038
-[#52041]: https://github.com/cockroachdb/cockroach/pull/52041
-[#52042]: https://github.com/cockroachdb/cockroach/pull/52042
-[#52068]: https://github.com/cockroachdb/cockroach/pull/52068
-[#52079]: https://github.com/cockroachdb/cockroach/pull/52079
-[#52085]: https://github.com/cockroachdb/cockroach/pull/52085
-[#52090]: https://github.com/cockroachdb/cockroach/pull/52090
-[#52091]: https://github.com/cockroachdb/cockroach/pull/52091
-[#52092]: https://github.com/cockroachdb/cockroach/pull/52092
-[#52094]: https://github.com/cockroachdb/cockroach/pull/52094
-[#52103]: https://github.com/cockroachdb/cockroach/pull/52103
-[#52138]: https://github.com/cockroachdb/cockroach/pull/52138
-[#52148]: https://github.com/cockroachdb/cockroach/pull/52148
-[#52168]: https://github.com/cockroachdb/cockroach/pull/52168
-[#52195]: https://github.com/cockroachdb/cockroach/pull/52195
-[#52203]: https://github.com/cockroachdb/cockroach/pull/52203
-[#52230]: https://github.com/cockroachdb/cockroach/pull/52230
-[#52232]: https://github.com/cockroachdb/cockroach/pull/52232
-[#52234]: https://github.com/cockroachdb/cockroach/pull/52234
-[#52237]: https://github.com/cockroachdb/cockroach/pull/52237
-[#52263]: https://github.com/cockroachdb/cockroach/pull/52263
-[#52274]: https://github.com/cockroachdb/cockroach/pull/52274
-[#52301]: https://github.com/cockroachdb/cockroach/pull/52301
-[#52302]: https://github.com/cockroachdb/cockroach/pull/52302
-[#52313]: https://github.com/cockroachdb/cockroach/pull/52313
-[#52329]: https://github.com/cockroachdb/cockroach/pull/52329
-[#52348]: https://github.com/cockroachdb/cockroach/pull/52348
-[#52349]: https://github.com/cockroachdb/cockroach/pull/52349
-[#52350]: https://github.com/cockroachdb/cockroach/pull/52350
-[#52359]: https://github.com/cockroachdb/cockroach/pull/52359
-[#52364]: https://github.com/cockroachdb/cockroach/pull/52364
-[#52365]: https://github.com/cockroachdb/cockroach/pull/52365
-[#52376]: https://github.com/cockroachdb/cockroach/pull/52376
-[#52384]: https://github.com/cockroachdb/cockroach/pull/52384
-[#52388]: https://github.com/cockroachdb/cockroach/pull/52388
-[#52416]: https://github.com/cockroachdb/cockroach/pull/52416
-[#52428]: https://github.com/cockroachdb/cockroach/pull/52428
-[#52432]: https://github.com/cockroachdb/cockroach/pull/52432
-[#52434]: https://github.com/cockroachdb/cockroach/pull/52434
-[#52436]: https://github.com/cockroachdb/cockroach/pull/52436
-[#52442]: https://github.com/cockroachdb/cockroach/pull/52442
-[#52448]: https://github.com/cockroachdb/cockroach/pull/52448
-[#52475]: https://github.com/cockroachdb/cockroach/pull/52475
-[#52479]: https://github.com/cockroachdb/cockroach/pull/52479
-[#52483]: https://github.com/cockroachdb/cockroach/pull/52483
-[#52485]: https://github.com/cockroachdb/cockroach/pull/52485
-[#52488]: https://github.com/cockroachdb/cockroach/pull/52488
-[#52500]: https://github.com/cockroachdb/cockroach/pull/52500
-[#52530]: https://github.com/cockroachdb/cockroach/pull/52530
-[#52534]: https://github.com/cockroachdb/cockroach/pull/52534
-[#52538]: https://github.com/cockroachdb/cockroach/pull/52538
-[#52547]: https://github.com/cockroachdb/cockroach/pull/52547
-[#52569]: https://github.com/cockroachdb/cockroach/pull/52569
-[#52588]: https://github.com/cockroachdb/cockroach/pull/52588
-[#52589]: https://github.com/cockroachdb/cockroach/pull/52589
-[#52592]: https://github.com/cockroachdb/cockroach/pull/52592
-[#52595]: https://github.com/cockroachdb/cockroach/pull/52595
-[#52596]: https://github.com/cockroachdb/cockroach/pull/52596
-[#52599]: https://github.com/cockroachdb/cockroach/pull/52599
-[#52624]: https://github.com/cockroachdb/cockroach/pull/52624
-[#52631]: https://github.com/cockroachdb/cockroach/pull/52631
-[#52640]: https://github.com/cockroachdb/cockroach/pull/52640
-[#52652]: https://github.com/cockroachdb/cockroach/pull/52652
-[#52655]: https://github.com/cockroachdb/cockroach/pull/52655
-[#52696]: https://github.com/cockroachdb/cockroach/pull/52696
-[#52715]: https://github.com/cockroachdb/cockroach/pull/52715
-[#52721]: https://github.com/cockroachdb/cockroach/pull/52721
-[#52729]: https://github.com/cockroachdb/cockroach/pull/52729
-[#52730]: https://github.com/cockroachdb/cockroach/pull/52730
-[#52779]: https://github.com/cockroachdb/cockroach/pull/52779
-[#52789]: https://github.com/cockroachdb/cockroach/pull/52789
-[09076fdd5]: https://github.com/cockroachdb/cockroach/commit/09076fdd5
-[0a1a7c2f0]: https://github.com/cockroachdb/cockroach/commit/0a1a7c2f0
-[14221e626]: https://github.com/cockroachdb/cockroach/commit/14221e626
-[1682c4018]: https://github.com/cockroachdb/cockroach/commit/1682c4018
-[301839722]: https://github.com/cockroachdb/cockroach/commit/301839722
-[33f86ff31]: https://github.com/cockroachdb/cockroach/commit/33f86ff31
-[3697ebe72]: https://github.com/cockroachdb/cockroach/commit/3697ebe72
-[39c00cb68]: https://github.com/cockroachdb/cockroach/commit/39c00cb68
-[3b604f641]: https://github.com/cockroachdb/cockroach/commit/3b604f641
-[3ce3d2b60]: https://github.com/cockroachdb/cockroach/commit/3ce3d2b60
-[421420d66]: https://github.com/cockroachdb/cockroach/commit/421420d66
-[44983c4ce]: https://github.com/cockroachdb/cockroach/commit/44983c4ce
-[4877173b5]: https://github.com/cockroachdb/cockroach/commit/4877173b5
-[4aaf4844b]: https://github.com/cockroachdb/cockroach/commit/4aaf4844b
-[4d8b019a9]: https://github.com/cockroachdb/cockroach/commit/4d8b019a9
-[4db62f745]: https://github.com/cockroachdb/cockroach/commit/4db62f745
-[5100508cb]: https://github.com/cockroachdb/cockroach/commit/5100508cb
-[529aa8297]: https://github.com/cockroachdb/cockroach/commit/529aa8297
-[5416c9c6b]: https://github.com/cockroachdb/cockroach/commit/5416c9c6b
-[5475e6269]: https://github.com/cockroachdb/cockroach/commit/5475e6269
-[54b30fd50]: https://github.com/cockroachdb/cockroach/commit/54b30fd50
-[5ffaf44ba]: https://github.com/cockroachdb/cockroach/commit/5ffaf44ba
-[66eb16da5]: https://github.com/cockroachdb/cockroach/commit/66eb16da5
-[67e319f3f]: https://github.com/cockroachdb/cockroach/commit/67e319f3f
-[6c1a90b22]: https://github.com/cockroachdb/cockroach/commit/6c1a90b22
-[6def410cb]: https://github.com/cockroachdb/cockroach/commit/6def410cb
-[70cce489e]: https://github.com/cockroachdb/cockroach/commit/70cce489e
-[797db1d9e]: https://github.com/cockroachdb/cockroach/commit/797db1d9e
-[83dfef8e8]: https://github.com/cockroachdb/cockroach/commit/83dfef8e8
-[84192f40c]: https://github.com/cockroachdb/cockroach/commit/84192f40c
-[8759499dc]: https://github.com/cockroachdb/cockroach/commit/8759499dc
-[87c6c12d7]: https://github.com/cockroachdb/cockroach/commit/87c6c12d7
-[89781ac5f]: https://github.com/cockroachdb/cockroach/commit/89781ac5f
-[acfa3d47d]: https://github.com/cockroachdb/cockroach/commit/acfa3d47d
-[b19794de2]: https://github.com/cockroachdb/cockroach/commit/b19794de2
-[b4af2b06d]: https://github.com/cockroachdb/cockroach/commit/b4af2b06d
-[b7430b5f7]: https://github.com/cockroachdb/cockroach/commit/b7430b5f7
-[c3951f31a]: https://github.com/cockroachdb/cockroach/commit/c3951f31a
-[c4e1643f9]: https://github.com/cockroachdb/cockroach/commit/c4e1643f9
-[cd84345a8]: https://github.com/cockroachdb/cockroach/commit/cd84345a8
-[d0fde99b4]: https://github.com/cockroachdb/cockroach/commit/d0fde99b4
-[d163557b4]: https://github.com/cockroachdb/cockroach/commit/d163557b4
-[d5497e315]: https://github.com/cockroachdb/cockroach/commit/d5497e315
-[d86d679ae]: https://github.com/cockroachdb/cockroach/commit/d86d679ae
-[dd76f4aa7]: https://github.com/cockroachdb/cockroach/commit/dd76f4aa7
-[e92b4d35a]: https://github.com/cockroachdb/cockroach/commit/e92b4d35a
-[eaa01fd67]: https://github.com/cockroachdb/cockroach/commit/eaa01fd67
-[ec3d431be]: https://github.com/cockroachdb/cockroach/commit/ec3d431be
-[f21b856d9]: https://github.com/cockroachdb/cockroach/commit/f21b856d9
-[f4c804a2b]: https://github.com/cockroachdb/cockroach/commit/f4c804a2b
-[fd89146ae]: https://github.com/cockroachdb/cockroach/commit/fd89146ae
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-beta.1.md b/src/current/_includes/releases/v20.2/v20.2.0-beta.1.md
deleted file mode 100644
index 4a35c42577c..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-beta.1.md
+++ /dev/null
@@ -1,494 +0,0 @@
-## v20.2.0-beta.1
-
-Release Date: September 14, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-In addition to various updates, enhancements, and bug fixes, this first v20.2 beta release includes the following major highlights:
-
-- **Backup schedules:** You can now set up a recurring schedule that lets CockroachDB handle scheduling, conflict resolution, and resilience for your backups. Previously, it was necessary to create your own scheduler service or cron job to kick off [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) jobs. To create a schedule for a cluster-level backup that runs a full backup every day with the first full backup taken "now", run `CREATE SCHEDULE test_backup_schedule FOR BACKUP INTO ‘<your-backup-storage-location’ RECURRING ‘@daily’ FULL BACKUP ALWAYS WITH SCHEDULE OPTIONS first_run=NOW`.
-- The following SQL features improve CockroachDB's PostgreSQL compatibility:
-  - **User-defined schemas:** Within a given database, you can now create schemas to organize your data and create finer-grained access controls. Previously, the recommendation was to create a database wherever you would normally create a schema. Now, an existing database can be converted to a schema under an existing database using [`ALTER DATABASE ... CONVERT TO SCHEMA WITH PARENT ...`](https://www.cockroachlabs.com/docs/v20.2/alter-database).
-  - **Enums:** `ENUM` [types](https://www.cockroachlabs.com/docs/v20.2/data-types) can now be created in CockroachDB using `CREATE TYPE ... AS ENUM`. A column type can be set to an `ENUM` type, which limits the column values to those defined in the `ENUM`.
-  - **Partial indexes:**  [Partial indexes](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) allow you to specify a subset of rows and columns to add to an [index](https://www.cockroachlabs.com/docs/v20.2/indexes), using a `WHERE` filter defined at index creation.
-
-<h3 id="v20-2-0-beta-1-backward-incompatible-changes">Backward-incompatible changes</h3>
-
-- A change to the on-disk representation for user-defined schemas, enums, and databases was made that is backward-incompatible with v20.2 alpha releases. Only schemas, enums, and databases in the middle of being dropped at the time of the upgrade are affected, and the upgrade may result in the drop never running to completion. If you are upgrading from a v20.2 alpha release to a v20.2 beta release, we advise that you avoid dropping schemas, enums, and databases. [#53387][#53387]
-- The command-line flag `--socket` has been removed. It was deprecated since v20.1. Use `--socket-dir` instead. [#53405][#53405] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-1-security-updates">Security updates</h3>
-
-- Certificate revocation is now supported via OSCP and the [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `security.ocsp.mode`. This makes a call to the OCSP server on every connection attempt and may wait for up to value specified with the setting `security.ocsp.timeout`. [#53218][#53218] {% comment %}doc{% endcomment %}
-- Defining or changing [authentication](https://www.cockroachlabs.com/docs/v20.2/authorization) principals or their credentials now requires the new `CREATELOGIN` option to be set for the requesting user or one of its roles. This includes setting/removing the `CREATELOGIN` option (whether the principal can log in), initializing or changing the password of a SQL user, and setting the expiration date for a password. Previously, only the `CREATEROLE` option could perform these changes. The pseudo-option `NOCREATELOGIN` can be used to revoke `CREATELOGIN`. The two predefined `root` and `admin` [roles](https://www.cockroachlabs.com/docs/v20.2/authorization#default-roles) have the option `CREATELOGIN` set by default. [#50601][#50601] {% comment %}doc{% endcomment %}
-- Only a user which already has the `CREATELOGIN` option (either itself or one of its roles) can grant this option or use `NOCREATELOGIN`. [#50601][#50601] {% comment %}doc{% endcomment %}
-- Roles that had the `CREATEROLE` privilege prior to upgrading to this version are also automatically granted `CREATELOGIN`. After the upgrade, `CREATELOGIN` is no longer granted automatically. [#50601][#50601] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-1-general-changes">General changes</h3>
-
-- `Random()` and `gen_random_uuid()` are now supported as default expressions for [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import). [#52247][#52247] {% comment %}doc{% endcomment %}
-- [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into) is now supported for `DELIMITED` and `PGCOPY` file formats. [#52628][#52628] {% comment %}doc{% endcomment %}
-- Computed columns are now supported in the [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into) operation. [#51321][#51321] {% comment %}doc{% endcomment %}
-- As part of the transition to v20.2, the migration to upgrade schema change jobs started prior to v20.1 is no longer run. [#52968][#52968] {% comment %}doc{% endcomment %}
-- In some cases where `AmbiguousResultErrors` were produced under high load, non-ambiguous, retryable errors are now returned. [#53156][#53156]
-
-<h3 id="v20-2-0-beta-1-enterprise-edition-changes">Enterprise edition changes</h3>
-
-- [`SHOW BACKUP`](https://www.cockroachlabs.com/docs/v20.2/show-backup) can be used to list backups in a backup collection created by `BACKUP ... INTO`. [#52758][#52758] {% comment %}doc{% endcomment %}
-- [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup)s with `revision_history` now support including UDTs. [#53160][#53160] {% comment %}doc{% endcomment %}
-- User-defined schemas now support being backed up with revision history and restored with `AS OF SYSTEM TIME`. [#53241][#53241] {% comment %}doc{% endcomment %}
-- Scheduled jobs are now included in [cluster backups](https://www.cockroachlabs.com/docs/v20.2/backup#backup-a-cluster). [#53203][#53203] {% comment %}doc{% endcomment %}
-- As part of making basic [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) and [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) free to use without an enterprise license, [`SHOW BACKUP`](https://www.cockroachlabs.com/docs/v20.2/show-backup) and `SHOW BACKUPS IN` no longer require a license. [#53356][#53356] {% comment %}doc{% endcomment %}
-- Backups run from v20.2 nodes are no longer run in an auto-appended backup location that was created by v20.1 nodes. [#53762][#53762]
-
-<h3 id="v20-2-0-beta-1-sql-language-changes">SQL language changes</h3>
-
-- Reduced memory used by scans of tables containing JSON data. [#52738][#52738]
-- Introduced the `box2d` [data type](https://www.cockroachlabs.com/docs/v20.2/data-types) to be used for geospatial comparators with [`GEOMETRY`/`GEOGRAPHY`](https://www.cockroachlabs.com/docs/v20.2/spatial-data). [#52771][#52771] {% comment %}doc{% endcomment %}
-- [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) now shows estimated row count for scans (when statistics are available). [`EXPLAIN (VERBOSE)`](https://www.cockroachlabs.com/docs/v20.2/explain) now shows the estimated row count for all operators. [#52798][#52798] {% comment %}doc{% endcomment %}
-- Added support for `ALTER TABLE <table> OWNER TO <owner>`. The command changes the owner of a table. To use the conditions, the following conditions must be met: The user executing the command must be the owner of the table, or the member of the owner role. The user executing the command must be a member of the new owner role. The new owner role must have `CREATE` on the schema the table belongs to. [#52659][#52659] {% comment %}doc{% endcomment %}
-- Added support for `SELECT ... FOR {UPDATE,SHARE} NOWAIT`. The option can be used to throw an error instead of blocking on contended row-level lock acquisition. [#52522][#52522] {% comment %}doc{% endcomment %}
-- Added privileges to user-defined types. Users can grant privileges on a type by using [`GRANT {USAGE/GRANT/ALL} ON TYPE <type> TO <users>`](https://www.cockroachlabs.com/docs/v20.2/grant). Users must have `CREATE` privilege in a database to create a type in that database. Users must have `USAGE` privilege to create an object that depends on a type. Users must have `GRANT` privilege to grant more privileges on the type. Owning a type implicitly gives `ALL` privileges on the type (`USAGE`,`GRANT`). Users must be the owner of the type to drop or alter the type. After creating a type, the creator can delegate privileges on that type by [`GRANT`](https://www.cockroachlabs.com/docs/v20.2/grant)ing any of the `USAGE`/`GRANT`/`ALL` privileges. To allow another user to grant privileges, they must have `GRANT` privilege and the privilege they want to [`GRANT`](https://www.cockroachlabs.com/docs/v20.2/grant). [#51622][#51622] {% comment %}doc{% endcomment %}
-- [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) now shows fewer "project" nodes. [#52865][#52865] {% comment %}doc{% endcomment %}
-- Improved display of spans in [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain). [#52865][#52865] {% comment %}doc{% endcomment %}
-- Added support for the `DROP SCHEMA` command. [#52726][#52726] {% comment %}doc{% endcomment %}
-- Added a new [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `sql.log.slow_query.internal` which, when turned on in conjunction with the [slow query log](https://www.cockroachlabs.com/docs/v20.2/query-behavior-troubleshooting#using-the-slow-query-log), causes slow internal queries to be logged to a slow internal query log at `cockroach-sql-slow-internal-only.log`. Internal queries are no longer logged to the slow query log. This new setting is opt-in. The default behavior is to not log slow internal queries. [#52377][#52377] {% comment %}doc{% endcomment %}
-- Removed some unnecessary [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) fields, and relegated others to the `VERBOSE` variant. [#53003][#53003] {% comment %}doc{% endcomment %}
-- Improved [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) output for join nodes. [#53003][#53003] {% comment %}doc{% endcomment %}
-- Improved [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) output for scalar groups. [#53003][#53003] {% comment %}doc{% endcomment %}
-- Improved [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) output for set operations. [#53003][#53003] {% comment %}doc{% endcomment %}
-- Box2d comparison operators are now gated by the [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `sql.spatial.experimental_box2d_comparison_operators.enabled`. [#52990][#52990] {% comment %}doc{% endcomment %}
-- Added the `CONTROLJOB` role option. When creating/altering roles, `CONTROLJOB` can be passed as a role option. For example, [`CREATE USER <user> CONTROLJOB CREATEROLE`](https://www.cockroachlabs.com/docs/v20.2/create-user). `NOCONTROLJOB` can be used to remove `CONTROLJOB` from the role when altering the role. `CONTROLJOB` allows the user to pause/resume and cancel jobs owned by non-admin users. `CONTROLJOB` also allows seeing all jobs owned by non-admin users, i.e., when running [`SHOW JOBS`](https://www.cockroachlabs.com/docs/v20.2/show-jobs). [#52804][#52804] {% comment %}doc{% endcomment %}
-- Added a new public [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `sql.defaults.disallow_full_table_scans.enabled` that defaults to false, which informs the session setting `disallow_full_table_scans`. If the session is configured to disallow full table/index scans, any user query that plans a full table/index scan is rejected. This does not apply to internal queries or queries over virtual schemas (e.g., `pg_catalog`). [#52278][#52278] {% comment %}doc{% endcomment %}
-- Renaming and dropping databases now satisfy the same transactional guarantees as online schema changes on tables: Changes will become visible if and only if the transaction commits, and a successful result indicates changes having propagated to the entire cluster. This fixes some long-standing problems with inconsistent database state being visible after renames and drops. (As a side effect of coherent caching for databases, database names can no longer be recycled in multiple schema changes in the same transaction.) [#52975][#52975] {% comment %}doc{% endcomment %}
-- The [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) now supports `DISTINCT` and `FILTER`ing hash aggregation. [#50721][#50721] {% comment %}doc{% endcomment %}
-- Added support for `ALTER DATABASE OWNER TO`. This command changes the owner of a database. The user must be an owner of the database to run the command. The user must also be a member of the new owner role directly or indirectly. [#52736][#52736] {% comment %}doc{% endcomment %}
-- [`UPSERT`](https://www.cockroachlabs.com/docs/v20.2/upsert) statements now acquire locks using the `FOR UPDATE` locking mode during their initial row scan, which improves performance for contended workloads. This behavior is configurable using the `enable_implicit_select_for_update` session variable and the `sql.defaults.implicit_select_for_update.enabled` [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings). [#53132][#53132] {% comment %}doc{% endcomment %}
-- Users can now convert existing databases into schemas under other databases through the `ALTER DATABASE ... CONVERT TO SCHEMA UNDER PARENT ...` command. This command can only be run by `admin` and is only valid for databases that do not already have any child schemas other than `public`. [#52997][#52997] {% comment %}doc{% endcomment %}
-- Implemented the `IdleInTransactionSessionTimeout` variable to allow terminating sessions that are idle in a transaction past the provided threshold. Set the variable by using `SET idle_in_transaction_session_timeout = 'time'`. Sessions that are idle in `OPEN`, `ABORTED`, and `DONE(COMMITWAIT)` transaction states will be terminated if the user idles longer than the threshold time. [#52938][#52938] {% comment %}doc{% endcomment %}
-- Non-admin users with `CREATEROLE` are no longer permitted to drop users with the admin role. [#52881][#52881] {% comment %}doc{% endcomment %}
-- Users can now specify which subdirectory they wish to write a [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) to, via `BACKUP INTO 'subdir' IN x`. This will write `BACKUP` data to `x/subdir/`. [#53139][#53139] {% comment %}doc{% endcomment %}
-- Added support for `ALTER SCHEMA <schema> OWNER TO <owner>`. The command changes the owner of a schema. To use the conditions, the following conditions must be met: The user executing the command must be the owner of the schema. The user executing the command must be a member of the new owner role. The new owner role must have `CREATE` on the database the schema belongs to. [#52781][#52781] {% comment %}doc{% endcomment %}
-- The [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) now supports ordered aggregation with the `DISTINCT` clause. [#53145][#53145] {% comment %}doc{% endcomment %}
-- Introduced a new `CONTROLCHANGEFEED` role option. This grants non-admin roles the ability to create new changefeeds, as long as they have `SELECT` privileges on the target table. It can be conferred via `ALTER ROLE <role> CONTROLCHANGEFEED` and revoked via `ALTER ROLE <role> NOCONTROLCHANGEFEED`. [#52869][#52869] {% comment %}doc{% endcomment %}
-- Added support for `ALTER TYPE <type> OWNER TO <owner>`. The command changes the owner of a type. To use the conditions, the following conditions must be met: The user executing the command must be the owner of the type. The user executing the command must be a member of the new owner role. The new owner role must have `CREATE` on the schema the type belongs to. [#52656][#52656] {% comment %}doc{% endcomment %}
-- Introduced a new `CREATEDB` role option. This grants non-admin roles the ability to create new databases. It can be conferred via `ALTER ROLE <role> CREATEDB` and revoked via `ALTER ROLE <role> NOCREATEDB`. [#52831][#52831] {% comment %}doc{% endcomment %}
-- Schema owners can drop tables inside the schema without explicit `DROP` privilege on the table. [#52740][#52740] {% comment %}doc{% endcomment %}
-- Queries logged in the [slow query log](https://www.cockroachlabs.com/docs/v20.2/query-behavior-troubleshooting#using-the-slow-query-log) come with a reason now, which can be any combination of `LATENCY_THRESHOLD`, `FULL_TABLE_SCAN`, and `FULL_SECONDARY_INDEX_SCAN`. There is also a new opt-in [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `sql.log.slow_query.experimental_full_table_scans.enabled` which, when enabled, logs full table/index scans regardless of the query execution being over the latency threshold. This setting only works if the slow query log has been turned on, i.e., a non-zero latency threshold must be specified. [#53164][#53164] {% comment %}doc{% endcomment %}
-- Introduced a new `VIEWACTIVITY` role option. This grants non-admin roles the ability to see other users' sessions and queries through [`SHOW SESSIONS`](https://www.cockroachlabs.com/docs/v20.2/show-sessions), [`SHOW QUERIES`](https://www.cockroachlabs.com/docs/v20.2/show-queries), and the [DB Console Statements page](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page). [#53291][#53291] {% comment %}doc{% endcomment %}
-- Introduced a new `CANCELQUERY` role option. This grants non-admin roles the ability to cancel other users' queries and sessions. Note that non-admins are not allowed to cancel the queries or sessions of admins. [#53291][#53291] {% comment %}doc{% endcomment %}
-- Previously, `selectivity` information would be included in [`EXPLAIN ANALYZE`](https://www.cockroachlabs.com/docs/v20.2/explain-analyze) diagrams if a query was executed via the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). This has been removed due to being confusing and probably unhelpful. [#53153][#53153] {% comment %}doc{% endcomment %}
-- `stall time` has been renamed to `IO time` in [`EXPLAIN ANALYZE`](https://www.cockroachlabs.com/docs/v20.2/explain-analyze) diagrams for queries executed via the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). [#53153][#53153] {% comment %}doc{% endcomment %}
-- An [`INSERT ... ON CONFLICT DO UPDATE`](https://www.cockroachlabs.com/docs/v20.2/insert#on-conflict-clause) statement without a list of column names after `ON CONFLICT` now results in a SQL syntax error with the error code `42601`. Previously, it errored with the message "there is no unique or exclusion constraint matching the ON CONFLICT specification" and the error code `42P10`. [#53067][#53067] {% comment %}doc{% endcomment %}
-- Added support for the `WITH DATA` and `WITH NO DATA` arguments for the `REFRESH MATERIALIZED VIEW` command. [#53052][#53052] {% comment %}doc{% endcomment %}
-- Added support for the `GRANT ... ON SCHEMA command`. [#53344][#53344] {% comment %}doc{% endcomment %}
-- Added the `SHOW TYPES` command to list all user-defined types. [#53386][#53386] {% comment %}doc{% endcomment %}
-- Added support for the `USAGE` privilege on schemas. [#53358][#53358] {% comment %}doc{% endcomment %}
-- Previously, `UNION ALL` queries could crash the server due to OOM in some extreme cases. This is now fixed, at the expense of possible minor reduction in performance, by reducing the concurrency of evaluation of such queries. [#53343][#53343]
-- CockroachDB now recognizes the `NOT DEFERRABLE` and `DEFERRABLE` arguments to [`SET TRANSACTION`](https://www.cockroachlabs.com/docs/v20.2/set-transaction). Note that the `DEFERRABLE` argument is still unimplemented. [#53435][#53435] {% comment %}doc{% endcomment %}
-- Added an invisible [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) `sql.conn.max_read_buffer_message_size`, which allows users to configure [SQL statement](https://www.cockroachlabs.com/docs/v20.2/sql-statements) maximum sizes across the cluster. This effect will take place upon connection restart. [#53445][#53445] {% comment %}doc{% endcomment %}
-- [`SHOW BACKUP`](https://www.cockroachlabs.com/docs/v20.2/show-backup) now shows all schemas in a backup. Previously, databases, types, and schemas were not shown. **Note:** This introduces a **breaking change** in that it changes the schema of `SHOW BACKUP` and will no longer return the column `table_name`. This column is replaced by the more general `object_name`. [#53321][#53321] {% comment %}doc{% endcomment %}
-- The memory used by disk scans is now accounted for, reducing the likelihood of out-of-memory conditions resulting in process crashes (as opposed to SQL out-of-memory error messages). [#52496][#52496]
-- Populated the catalog table `pg_catalog.pg_matviews` with materialized view information. [#53501][#53501]
-- A value of type `OID` can now be compared to a value of type `INT`. [#53523][#53523] {% comment %}doc{% endcomment %}
-- Fixed a bug where temporary tables could be included in `BACKUP` commands. [#53478][#53478]
-- Added 3 new columns to the `crdb_internal.node_transactions` and `cluster_transactions` tables: `num_stmts`, `num_retries`, and `num_auto_retries`. These keep track of the total number of statements executed on the transaction, the number of retries encountered, and the number of automatic retries encountered, respectively. [#51902][#51902]
-- Added the `SHOW TRANSACTIONS` statement, similar to [`SHOW SESSIONS`](https://www.cockroachlabs.com/docs/v20.2/show-sessions) and variants. It shows the currently active transactions in the node or cluster, and some information about them. [#51902][#51902] {% comment %}doc{% endcomment %}
-- The related `owner` columns are now populated in `pg_catalog` metadata tables. [#53495][#53495]
-- `ENUM` types are no longer experimental. [#53565][#53565] {% comment %}doc{% endcomment %}
-- Added the `tableoid` system column. [#53562][#53562]
-- User-defined schemas are no longer experimental. [#53674][#53674] {% comment %}doc{% endcomment %}
-- The [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) output for [`UPSERT`](https://www.cockroachlabs.com/docs/v20.2/upsert) and [`INSERT ON CONFLICT`](https://www.cockroachlabs.com/docs/v20.2/insert) statements now includes a list of arbiter indexes. These arbiters are the indexes used for detecting conflicts between the insert row and the existing rows in the table. [#53172][#53172] {% comment %}doc{% endcomment %}
-- Added support for the `CREATE SCHEMA ... AUTHORIZATION` command. [#53583][#53583] {% comment %}doc{% endcomment %}
-- [`EXPLAIN ANALYZE`](https://www.cockroachlabs.com/docs/v20.2/explain-analyze) diagrams now contain "bytes read" information for table readers and lookup joins when the queries are executed via the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). [#53371][#53371] {% comment %}doc{% endcomment %}
-- Disallowed the `CONVERT TO SCHEMA` command on the current database. [#53564][#53564] {% comment %}doc{% endcomment %}
-- The `TransactionStatistics` protobuf will only include the first 1000 statement IDs that comprise a transaction. Any statement IDs beyond 1000 will be omitted. [#53553][#53553]
-- Non-admin users are now permitted to execute [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) statements as long as the restore does not depend on implicit credentials and the user has the appropriate privileges to create all of the resulting database objects. For database restores, this means the user must have the `CREATEDB` role privilege. For table restores, the user must have `CREATE` privileges on the parent database. Full cluster restores still require admin privileges. [#53650][#53650] {% comment %}doc{% endcomment %}
-- Populated the `information_schema.column_udt_usage` catalog table. [#53699][#53699]
-- Previously, the `pg_get_constraintdef` function would return a result that included type annotations, which is a CockroachDB-specific syntax. Now it does not. [#53865][#53865]
-- [`EXPLAIN ANALYZE`](https://www.cockroachlabs.com/docs/v20.2/explain-analyze) diagrams now contain the information about the number of rows read by the vectorized table reader. [#53775][#53775] {% comment %}doc{% endcomment %}
-- The new `prefer_lookup_joins_for_fk` session setting (and corresponding [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings)) can be used to make foreign key checks use lookup joins if they incorrectly use hash or merge join. [#53838][#53838] {% comment %}doc{% endcomment %}
-- Previously, there was no way to query the transaction-level metrics collected by individual nodes. A new `crdb_internal` table called `node_transaction_statistics` allows users to query transaction metrics collected on a particular node. [#53759][#53759]
-- Introduced a new `MODIFYCLUSTERSETTING` role option. This grants non-admin roles the ability to modify certain [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings), currently limited to settings with the "sql.defaults" prefix. [#53930][#53930] {% comment %}doc{% endcomment %}
-- SQL expressions that are shown in `pg_catalog` columns and related functions now will be formatted with a typecast for non-numeric constants. [#53965][#53965]
-- Implemented geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Reverse` [#52834][#52834] {% comment %}doc{% endcomment %}
-- Implemented the `&&` and `~` operators for comparing bounding box objects and geometries. [#52913][#52913] {% comment %}doc{% endcomment %}
-- Implemented the `ST_CombineBBox` [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions). [#52903][#52903] {% comment %}doc{% endcomment %}
-- Introduced the `s2_max_level`, `s2_level_mod`, and `s2_max_cells` storage parameters for modifying the S2 parameters for indexing [`GEOMETRY` and `GEOGRAPHY`](https://www.cockroachlabs.com/docs/v20.2/spatial-data) data types in a GIN index. [#52800][#52800] {% comment %}doc{% endcomment %}
-- Introduced the `geometry_min_x`, `geometry_min_y`, `geometry_max_x`, `geometry_max_y` storage parameters for indexing GEOMETRY data types in a GIN index. [#52800][#52800] {% comment %}doc{% endcomment %}
-- Implemented the `ALTER MATERIALIZED VIEW` and `DROP MATERIALIZED VIEW` commands. [#52840][#52840] {% comment %}doc{% endcomment %}
-- Implemented the ability to cast between `box2d` and `GEOMETRY` types. [#52965][#52965] {% comment %}doc{% endcomment %}
-- Implemented the `PostGIS_GetBBox` [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions). [#52963][#52963] {% comment %}doc{% endcomment %}
-- Implemented the `ST_MakeBox2D` [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions). [#52961][#52961] {% comment %}doc{% endcomment %}
-- Implemented the `ST_ClipByBox2D` [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions). [#52955][#52955] {% comment %}doc{% endcomment %}
-- Added the ability to resolve the spatial-backed [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) in the public schema. For example, `public.st_x` works the same as `st_x`. [#52983][#52983] {% comment %}doc{% endcomment %}
-- Implemented `ST_Expand` for the `box2d` type. [#52957][#52957] {% comment %}doc{% endcomment %}
-- Implemented `ST_PointFromGeoHash`, which converts geohash to point. [#52892][#52892] {% comment %}doc{% endcomment %}
-- Implemented the `ST_Extent` [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) for `GEOMETRY` aggregations into box2d. [#53001][#53001] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Dimension`. [#53068][#53068] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_CoordDim` as an alias for `ST_NDims`. [#53193][#53193] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_IsEmpty` and `ST_IsCollection`. [#53217][#53217] {% comment %}doc{% endcomment %}
-- Implemented the `ST_GeomFromGeoHash` and `ST_Box2DFromGeoHash` [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions). [#53162][#53162] {% comment %}doc{% endcomment %}
-- Implemented the `ST_Union` [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) as an aggregate. The previous alpha-available `ST_Union` for two arguments is deprecated. [#53127][#53127] {% comment %}doc{% endcomment %}
-- Implemented `ST_Expand` for `GEOMETRY`-based types. [#53326][#53326] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Multi`, `ST_CollectionExtract`, and `ST_CollectionHomogenize`. [#53287][#53287] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_SharedPaths` [#53307][#53307] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_FlipCoordinates` [#53296][#53296] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_SymDifference`. [#53636][#53636] {% comment %}doc{% endcomment %}
-- Implemented the geometry aggregate [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Collect`. [#53645][#53645] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_ForceCollection`. [#53643][#53643] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_SymmetricDifference`. [#53688][#53688] {% comment %}doc{% endcomment %}
-- Implemented the geometry aggregate [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_MemCollect` and `ST_MemUnion`. [#53708][#53708] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Normalize`. [#53726][#53726] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Rotate`. [#53709][#53709] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_AddPoint`. [#53853][#53853] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Simplify` and `ST_SimplifyPreserveTopology`. [#53796][#53796] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Affine`. [#53856][#53856] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_LineFromMultiPoint` and `ST_LineMerge`. [#54013][#54013] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_RemoveRepeatedPoints`. [#53999][#53999] {% comment %}doc{% endcomment %}
-- Implemented geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_RemovePoint` [#53244][#53244] {% comment %}doc{% endcomment %}
-- Implemented the `ST_IsClosed`, `ST_IsSimple`, and `ST_IsRing` [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions). [#53240][#53240] {% comment %}doc{% endcomment %}
-- Implemented the geometry [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_Points`. [#53496][#53496] {% comment %}doc{% endcomment %}
-- Implemented the `ST_IsPolygonCW`, `ST_IsPolygonCCW`, `ST_ForcePolygonCW`, and `ST_ForcePolygonCCW` [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions). [#53243][#53243] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-1-command-line-changes">Command-line changes</h3>
-
-- The [`--storage-engine`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start#storage-engine) CLI flag no longer defaults to using the last-used storage engine when unspecified. Instead, Pebble is used by default unless otherwise specified using the `--storage-engine` flag. [#52944][#52944] {% comment %}doc{% endcomment %}
-- Added alias commands `ls` and `rm` for `userfile list` and `userfile delete`. [#53074][#53074] {% comment %}doc{% endcomment %}
-- The new debug command `decode-proto` reads descriptor from `stdin` in hex or Base64 format (auto-detected) and a flag `--schema=<fully qualified name to decode>` with default value `cockroach.sql.sqlbase.Descriptor` and outputs to stdout the deserialized protobuf in JSON format. If the input is not a hex/Base64-encoded protobuf, then it is outputted verbatim. [#52972][#52972] {% comment %}doc{% endcomment %}
-- The [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) and [`cockroach start-single-node`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start-single-node) commands now enable `--redactable-logs` by default. The flag is also enabled by default in [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo) if `--log-dir` is passed. This causes log files to become redactable, so that [`cockroach debug merge-log --redact`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-merge-logs) or [`cockroach debug zip --redact`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) can remove sensitive information from log files. (Reminder: `cockroach debug zip --redact` only affects *log files*; other items collected by the command can still contain sensitive information.) [#53263][#53263] {% comment %}doc{% endcomment %}
-- The command-line flag `--insecure` has been marked as deprecated. See [issue #53404](https://go.crdb.dev/issue/53404) for details. The flag will be removed in a later version in a staged fashion: first, additional security mechanisms will be added to enable more flexible deployments which were previously done using `--insecure`; then the flag will be removed from server commands; then finally, in a later version, also from client commands. [#53405][#53405] {% comment %}doc{% endcomment %}
-- CockroachDB now recognizes the `\dT` alias for listing user-defined [types](https://www.cockroachlabs.com/docs/v20.2/data-types). [#53386][#53386] {% comment %}doc{% endcomment %}
-- The `workload` sub-commands are no longer marked as experimental. [#53691][#53691] {% comment %}doc{% endcomment %}
-- The `--geo-libs` flag introduced in v20.2 alpha versions is now renamed to `--spatial-libs`. [#53721][#53721] {% comment %}doc{% endcomment %}
-- The CLI no longer prints a blanket `Time` for queries. Instead, if `show_times` is turned on and the server version is v20.2 or later, the CLI prints two separate times: the server execution time and the network latency. [#52233][#52233] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-1-db-console-changes">DB Console changes</h3>
-
-- Improved how [SQL statement plans](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page#logical-plan) in the DB Console are populated, using the new `EXPLAIN` infrastructure. [#52956][#52956] {% comment %}doc{% endcomment %}
-- Previously, in some cases, the [Execution Stats page](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page#execution-stats) would show a confusingly high **Overhead** latency for a statement. This could happen due to multiple statements being parsed together or due to statement execution being retried. To avoid this, we now stop considering the time between when parsing ends and execution begins when determining service latency. [#53846][#53846]
-- Added the **Session list** and **Session detail** pages. We now permit session and query termination from the UI. [#51903][#51903] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-1-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug for [`ALTER TABLE`](https://www.cockroachlabs.com/docs/v20.2/alter-table) statements with multiple actions. In certain cases if the last action had no effect, the entire statement would be treated as a no-op. [#52819][#52819]
-- Previously, unexpected context cancellation errors could sometimes be returned in the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). This is now fixed. [#52463][#52463]
-- Fixed a bug where tables would not be cleaned up after a failed creation through [`CREATE TABLE AS`](https://www.cockroachlabs.com/docs/v20.2/create-table-as). [#52832][#52832]
-- Fixed a bug whereby gc jobs for tables dropped as part of a [`DROP DATABASE CASCADE`](https://www.cockroachlabs.com/docs/v20.2/drop-database) might never complete. [#52818][#52818]
-- Fixed an internal error that could occur when using an index-accelerated geospatial function inside an `EXISTS` or `NOT EXISTS` correlated subquery. [#52942][#52942]
-- Fixed a bug where if a table with a check constraint was truncated while being backfilled, the check constraint could get lost. [#49399][#49399]
-- Fixed bug where non-committed `DETACHED BACKUPS` left files which falsely indicated that a [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) was in progress. [#52980][#52980]
-- Fixed a crash that could occur when referencing a database that did not exist when trying to create a type or sequence, or when renaming a table. [#53137][#53137]
-- Eliminated some rare `AmbiguousCommitErrors` happening when [CDC](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) was used. [#53146][#53146]
-- A change in v20.1 caused a certain class of bulk [`UPDATE`](https://www.cockroachlabs.com/docs/v20.2/update) and [`DELETE`](https://www.cockroachlabs.com/docs/v20.2/delete) statements to hang indefinitely if run in an implicit transaction. We now break up these statements to avoid starvation and prevent them from hanging indefinitely. [#52885][#52885]
-- Previously, cluster restores would appear in the [jobs table](https://www.cockroachlabs.com/docs/v20.2/show-jobs) and [DB Console Jobs page](https://www.cockroachlabs.com/docs/v20.2/ui-jobs-page) as `RESTORE TABLE FROM ...`, which was incorrect. They now appear as `RESTORE FROM ...`. [#53230][#53230]
-- Previously, CockroachDB could return incorrect results when performing `LEFT ANTI` hash joins when right equality columns would form a key when using the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). This has been fixed. [#53226][#53226]
-- Admin users are now permitted to cancel other users' queries and sessions. Previously only the root user was allowed to do so. [#53291][#53291]
-- Fixed a possible server panic when using the `nodelocal` and `userfile` subcommands. [#53359][#53359]
-- Fixed a bug where user-defined types could not be used with some ORMs due to an assertion failure within Cockroach. [#53385][#53385]
-- The [DB Console Node Map](https://www.cockroachlabs.com/docs/v20.2/ui-cluster-overview-page#node-map-enterprise) (enterprise feature) and the [Advanced Debug page](https://www.cockroachlabs.com/docs/v20.2/ui-debug-pages) to list cluster localities are now again available to non-admin users. This bug had been introduced in v19.2.3. [#53329][#53329]
-- Previously, if no table was referencing a schema, it would not be included. Now when backing up a database, all schemas will be included. [#53224][#53224]
-- Fixed an internal error related to casts between tuples. [#53682][#53682]
-- Virtual index scans now respect limits properly, as they did in v20.1 and prior. [#53529][#53529]
-- CockroachDB could previously crash when evaluating queries with window functions with `GROUPS` mode of framing when `OFFSET FOLLOWING` boundary was used and when the offset was a very large value such that it could result in an integer overflow. This is now fixed. [#53722][#53722]
-- Database creation/deletion was previously not correctly tracked by `revision_history` cluster backups. This is now fixed. [#53667][#53667]
-- Fixed a bug that caused a crash when using a `RANGE` mode window function with an offset in some cases, e.g., `OVER (PARTITION BY b ORDER BY a RANGE 1 PRECEDING)`. [#53717][#53717]
-- Fixed a panic in `ST_SetPoint` when given empty point. [#53857][#53857]
-- Fixed a rare internal error that could occur during planning of queries with many highly selective predicates. [#53802][#53802]
-- CockroachDB now properly checks that a user has `CREATE` privileges on the target database before allowing them to create a schema. [#53837][#53837]
-- CockroachDB could previously crash when performing an interleaved join in some cases. This is now fixed. The bug has only been present on v20.2 testing releases. [#53863][#53863]
-- Fixed "use of crdb_internal_vtable_pk column not allowed" for some queries involving virtual tables. [#53866][#53866]
-- Fixed a bug when running restore while [upgrading the cluster from v20.1 to v20.2](https://www.cockroachlabs.com/docs/v20.2/upgrade-cockroach-version). [#53848][#53848]
-- Fixed a bug where we allowed new types to be used in an array type during a version upgrade. [#53961][#53961]
-- Fixed a rare bug where the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) incorrectly classified some columns as not-null, possibly leading to invalid query plans and incorrect results. [#54024][#54024]
-
-<h3 id="v20-2-0-beta-1-performance-improvements">Performance improvements</h3>
-
-- Maximum and minimum values, represented as 2-bucket histograms, are now collected for all non-index columns (up to 100 columns per table) as part of automatic statistics collection. 200-bucket histograms are still collected for all index columns. This change enables the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) to make better cardinality estimates and may result in better query plans in some cases. [#52905][#52905]
-- A large heap allocation performed during [`INSERT`](https://www.cockroachlabs.com/docs/v20.2/insert) statements was removed, resulting in an increase to throughput for single-row `INSERT` statements. [#53076][#53076]
-- Transient node liveness blips no longer cause up-to-date ranges to unquiesce, which makes these events less destabilizing. [#51894][#51894]
-- The `~` and `&&` geospatial bounding box operations can now benefit from index acceleration if one of the operands is an indexed geometry column. [#53023][#53023]
-- Cleaning up after a failure during [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into) a table which was empty is now faster. [#52754][#52754]
-- The allocation algorithm now supports intra-node rebalances, which means CockroachDB can fully utilize the additional stores on the same node. This removes the last roadblock to running CockroachDB with multiple stores (i.e., disks) per node. [#51567][#51567]
-- Validation of optimistic reads is now performed earlier in transactions when doing so can save work. This eliminates certain types of [transaction retry errors](https://www.cockroachlabs.com/docs/v20.2/transaction-retry-error-reference) and avoids wasted RPC traffic. [#52884][#52884]
-- Fixes a performance regression introduced in v20.2 alpha releases where the use of 2-part names to specify tables or types would incur extra reads from the store on every transaction. [#53290][#53290]
-- The [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) can now convert semi joins to inner joins in more cases, which may allow the optimizer to produce more efficient query plans. [#53337][#53337]
-- The [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) is now aware that the inverted join operator can preserve the ordering of its input. This enables the optimizer to eliminate unnecessary sort operations and produce more efficient plans in some cases. [#53502][#53502]
-- The [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) reduces filters applied after partial index scans in more cases where the filters are implicitly applied by the partial index predicate. This could lead to more efficient query plans in some cases. [#53507][#53507]
-- Limited the frequency of an expensive operation due to schema changes. This makes workloads that perform schema changes at a high rate less resource-intensive. [#53605][#53605]
-- Joins between very small tables are now more likely to use lookup join. [#53849][#53849]
-
-<h3 id="v20-2-0-beta-1-doc-updates">Doc updates</h3>
-
-- Published a tutorial on orchestrating a secure [CockroachDB multi-region deployment on Amazon EKS](https://www.cockroachlabs.com/docs/v20.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster). [#7782][#7782]
-- Published [best practices for optimizing import performance](https://www.cockroachlabs.com/docs/v20.2/import-performance-best-practices) in CockroachDB. [#8035][#8035]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-0-beta-1-contributors">Contributors</h3>
-
-This release includes 283 merged PRs by 40 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Cyrus Javan (first-time contributor)
-- Deven Bhooshan (first-time contributor)
-- Erik Grinaker (first-time contributor)
-- Michael Meng (first-time contributor)
-- Themis Papavasileiou (first-time contributor)
-- Vincent Xiao
-- himanshuchawla009
-
-</div>
-
-[#49399]: https://github.com/cockroachdb/cockroach/pull/49399
-[#50601]: https://github.com/cockroachdb/cockroach/pull/50601
-[#50721]: https://github.com/cockroachdb/cockroach/pull/50721
-[#51321]: https://github.com/cockroachdb/cockroach/pull/51321
-[#51567]: https://github.com/cockroachdb/cockroach/pull/51567
-[#51622]: https://github.com/cockroachdb/cockroach/pull/51622
-[#51775]: https://github.com/cockroachdb/cockroach/pull/51775
-[#51894]: https://github.com/cockroachdb/cockroach/pull/51894
-[#51902]: https://github.com/cockroachdb/cockroach/pull/51902
-[#51903]: https://github.com/cockroachdb/cockroach/pull/51903
-[#52233]: https://github.com/cockroachdb/cockroach/pull/52233
-[#52247]: https://github.com/cockroachdb/cockroach/pull/52247
-[#52278]: https://github.com/cockroachdb/cockroach/pull/52278
-[#52312]: https://github.com/cockroachdb/cockroach/pull/52312
-[#52377]: https://github.com/cockroachdb/cockroach/pull/52377
-[#52463]: https://github.com/cockroachdb/cockroach/pull/52463
-[#52496]: https://github.com/cockroachdb/cockroach/pull/52496
-[#52522]: https://github.com/cockroachdb/cockroach/pull/52522
-[#52598]: https://github.com/cockroachdb/cockroach/pull/52598
-[#52628]: https://github.com/cockroachdb/cockroach/pull/52628
-[#52656]: https://github.com/cockroachdb/cockroach/pull/52656
-[#52659]: https://github.com/cockroachdb/cockroach/pull/52659
-[#52711]: https://github.com/cockroachdb/cockroach/pull/52711
-[#52717]: https://github.com/cockroachdb/cockroach/pull/52717
-[#52726]: https://github.com/cockroachdb/cockroach/pull/52726
-[#52736]: https://github.com/cockroachdb/cockroach/pull/52736
-[#52738]: https://github.com/cockroachdb/cockroach/pull/52738
-[#52740]: https://github.com/cockroachdb/cockroach/pull/52740
-[#52754]: https://github.com/cockroachdb/cockroach/pull/52754
-[#52758]: https://github.com/cockroachdb/cockroach/pull/52758
-[#52771]: https://github.com/cockroachdb/cockroach/pull/52771
-[#52781]: https://github.com/cockroachdb/cockroach/pull/52781
-[#52798]: https://github.com/cockroachdb/cockroach/pull/52798
-[#52800]: https://github.com/cockroachdb/cockroach/pull/52800
-[#52804]: https://github.com/cockroachdb/cockroach/pull/52804
-[#52818]: https://github.com/cockroachdb/cockroach/pull/52818
-[#52819]: https://github.com/cockroachdb/cockroach/pull/52819
-[#52831]: https://github.com/cockroachdb/cockroach/pull/52831
-[#52832]: https://github.com/cockroachdb/cockroach/pull/52832
-[#52834]: https://github.com/cockroachdb/cockroach/pull/52834
-[#52840]: https://github.com/cockroachdb/cockroach/pull/52840
-[#52865]: https://github.com/cockroachdb/cockroach/pull/52865
-[#52869]: https://github.com/cockroachdb/cockroach/pull/52869
-[#52881]: https://github.com/cockroachdb/cockroach/pull/52881
-[#52884]: https://github.com/cockroachdb/cockroach/pull/52884
-[#52885]: https://github.com/cockroachdb/cockroach/pull/52885
-[#52892]: https://github.com/cockroachdb/cockroach/pull/52892
-[#52903]: https://github.com/cockroachdb/cockroach/pull/52903
-[#52905]: https://github.com/cockroachdb/cockroach/pull/52905
-[#52913]: https://github.com/cockroachdb/cockroach/pull/52913
-[#52921]: https://github.com/cockroachdb/cockroach/pull/52921
-[#52923]: https://github.com/cockroachdb/cockroach/pull/52923
-[#52925]: https://github.com/cockroachdb/cockroach/pull/52925
-[#52928]: https://github.com/cockroachdb/cockroach/pull/52928
-[#52938]: https://github.com/cockroachdb/cockroach/pull/52938
-[#52942]: https://github.com/cockroachdb/cockroach/pull/52942
-[#52944]: https://github.com/cockroachdb/cockroach/pull/52944
-[#52950]: https://github.com/cockroachdb/cockroach/pull/52950
-[#52955]: https://github.com/cockroachdb/cockroach/pull/52955
-[#52956]: https://github.com/cockroachdb/cockroach/pull/52956
-[#52957]: https://github.com/cockroachdb/cockroach/pull/52957
-[#52961]: https://github.com/cockroachdb/cockroach/pull/52961
-[#52963]: https://github.com/cockroachdb/cockroach/pull/52963
-[#52965]: https://github.com/cockroachdb/cockroach/pull/52965
-[#52968]: https://github.com/cockroachdb/cockroach/pull/52968
-[#52972]: https://github.com/cockroachdb/cockroach/pull/52972
-[#52975]: https://github.com/cockroachdb/cockroach/pull/52975
-[#52980]: https://github.com/cockroachdb/cockroach/pull/52980
-[#52983]: https://github.com/cockroachdb/cockroach/pull/52983
-[#52990]: https://github.com/cockroachdb/cockroach/pull/52990
-[#52997]: https://github.com/cockroachdb/cockroach/pull/52997
-[#53001]: https://github.com/cockroachdb/cockroach/pull/53001
-[#53003]: https://github.com/cockroachdb/cockroach/pull/53003
-[#53023]: https://github.com/cockroachdb/cockroach/pull/53023
-[#53052]: https://github.com/cockroachdb/cockroach/pull/53052
-[#53067]: https://github.com/cockroachdb/cockroach/pull/53067
-[#53068]: https://github.com/cockroachdb/cockroach/pull/53068
-[#53074]: https://github.com/cockroachdb/cockroach/pull/53074
-[#53076]: https://github.com/cockroachdb/cockroach/pull/53076
-[#53127]: https://github.com/cockroachdb/cockroach/pull/53127
-[#53132]: https://github.com/cockroachdb/cockroach/pull/53132
-[#53137]: https://github.com/cockroachdb/cockroach/pull/53137
-[#53139]: https://github.com/cockroachdb/cockroach/pull/53139
-[#53145]: https://github.com/cockroachdb/cockroach/pull/53145
-[#53146]: https://github.com/cockroachdb/cockroach/pull/53146
-[#53153]: https://github.com/cockroachdb/cockroach/pull/53153
-[#53156]: https://github.com/cockroachdb/cockroach/pull/53156
-[#53160]: https://github.com/cockroachdb/cockroach/pull/53160
-[#53162]: https://github.com/cockroachdb/cockroach/pull/53162
-[#53164]: https://github.com/cockroachdb/cockroach/pull/53164
-[#53172]: https://github.com/cockroachdb/cockroach/pull/53172
-[#53181]: https://github.com/cockroachdb/cockroach/pull/53181
-[#53193]: https://github.com/cockroachdb/cockroach/pull/53193
-[#53203]: https://github.com/cockroachdb/cockroach/pull/53203
-[#53215]: https://github.com/cockroachdb/cockroach/pull/53215
-[#53217]: https://github.com/cockroachdb/cockroach/pull/53217
-[#53218]: https://github.com/cockroachdb/cockroach/pull/53218
-[#53220]: https://github.com/cockroachdb/cockroach/pull/53220
-[#53224]: https://github.com/cockroachdb/cockroach/pull/53224
-[#53226]: https://github.com/cockroachdb/cockroach/pull/53226
-[#53230]: https://github.com/cockroachdb/cockroach/pull/53230
-[#53237]: https://github.com/cockroachdb/cockroach/pull/53237
-[#53240]: https://github.com/cockroachdb/cockroach/pull/53240
-[#53241]: https://github.com/cockroachdb/cockroach/pull/53241
-[#53243]: https://github.com/cockroachdb/cockroach/pull/53243
-[#53244]: https://github.com/cockroachdb/cockroach/pull/53244
-[#53252]: https://github.com/cockroachdb/cockroach/pull/53252
-[#53263]: https://github.com/cockroachdb/cockroach/pull/53263
-[#53275]: https://github.com/cockroachdb/cockroach/pull/53275
-[#53287]: https://github.com/cockroachdb/cockroach/pull/53287
-[#53290]: https://github.com/cockroachdb/cockroach/pull/53290
-[#53291]: https://github.com/cockroachdb/cockroach/pull/53291
-[#53296]: https://github.com/cockroachdb/cockroach/pull/53296
-[#53304]: https://github.com/cockroachdb/cockroach/pull/53304
-[#53307]: https://github.com/cockroachdb/cockroach/pull/53307
-[#53321]: https://github.com/cockroachdb/cockroach/pull/53321
-[#53326]: https://github.com/cockroachdb/cockroach/pull/53326
-[#53329]: https://github.com/cockroachdb/cockroach/pull/53329
-[#53337]: https://github.com/cockroachdb/cockroach/pull/53337
-[#53343]: https://github.com/cockroachdb/cockroach/pull/53343
-[#53344]: https://github.com/cockroachdb/cockroach/pull/53344
-[#53356]: https://github.com/cockroachdb/cockroach/pull/53356
-[#53358]: https://github.com/cockroachdb/cockroach/pull/53358
-[#53359]: https://github.com/cockroachdb/cockroach/pull/53359
-[#53371]: https://github.com/cockroachdb/cockroach/pull/53371
-[#53385]: https://github.com/cockroachdb/cockroach/pull/53385
-[#53386]: https://github.com/cockroachdb/cockroach/pull/53386
-[#53387]: https://github.com/cockroachdb/cockroach/pull/53387
-[#53405]: https://github.com/cockroachdb/cockroach/pull/53405
-[#53435]: https://github.com/cockroachdb/cockroach/pull/53435
-[#53441]: https://github.com/cockroachdb/cockroach/pull/53441
-[#53445]: https://github.com/cockroachdb/cockroach/pull/53445
-[#53478]: https://github.com/cockroachdb/cockroach/pull/53478
-[#53495]: https://github.com/cockroachdb/cockroach/pull/53495
-[#53496]: https://github.com/cockroachdb/cockroach/pull/53496
-[#53501]: https://github.com/cockroachdb/cockroach/pull/53501
-[#53502]: https://github.com/cockroachdb/cockroach/pull/53502
-[#53507]: https://github.com/cockroachdb/cockroach/pull/53507
-[#53510]: https://github.com/cockroachdb/cockroach/pull/53510
-[#53523]: https://github.com/cockroachdb/cockroach/pull/53523
-[#53529]: https://github.com/cockroachdb/cockroach/pull/53529
-[#53551]: https://github.com/cockroachdb/cockroach/pull/53551
-[#53553]: https://github.com/cockroachdb/cockroach/pull/53553
-[#53562]: https://github.com/cockroachdb/cockroach/pull/53562
-[#53564]: https://github.com/cockroachdb/cockroach/pull/53564
-[#53565]: https://github.com/cockroachdb/cockroach/pull/53565
-[#53579]: https://github.com/cockroachdb/cockroach/pull/53579
-[#53583]: https://github.com/cockroachdb/cockroach/pull/53583
-[#53600]: https://github.com/cockroachdb/cockroach/pull/53600
-[#53605]: https://github.com/cockroachdb/cockroach/pull/53605
-[#53636]: https://github.com/cockroachdb/cockroach/pull/53636
-[#53643]: https://github.com/cockroachdb/cockroach/pull/53643
-[#53645]: https://github.com/cockroachdb/cockroach/pull/53645
-[#53650]: https://github.com/cockroachdb/cockroach/pull/53650
-[#53667]: https://github.com/cockroachdb/cockroach/pull/53667
-[#53674]: https://github.com/cockroachdb/cockroach/pull/53674
-[#53682]: https://github.com/cockroachdb/cockroach/pull/53682
-[#53688]: https://github.com/cockroachdb/cockroach/pull/53688
-[#53691]: https://github.com/cockroachdb/cockroach/pull/53691
-[#53697]: https://github.com/cockroachdb/cockroach/pull/53697
-[#53699]: https://github.com/cockroachdb/cockroach/pull/53699
-[#53708]: https://github.com/cockroachdb/cockroach/pull/53708
-[#53709]: https://github.com/cockroachdb/cockroach/pull/53709
-[#53717]: https://github.com/cockroachdb/cockroach/pull/53717
-[#53721]: https://github.com/cockroachdb/cockroach/pull/53721
-[#53722]: https://github.com/cockroachdb/cockroach/pull/53722
-[#53726]: https://github.com/cockroachdb/cockroach/pull/53726
-[#53759]: https://github.com/cockroachdb/cockroach/pull/53759
-[#53762]: https://github.com/cockroachdb/cockroach/pull/53762
-[#53766]: https://github.com/cockroachdb/cockroach/pull/53766
-[#53775]: https://github.com/cockroachdb/cockroach/pull/53775
-[#53778]: https://github.com/cockroachdb/cockroach/pull/53778
-[#53796]: https://github.com/cockroachdb/cockroach/pull/53796
-[#53801]: https://github.com/cockroachdb/cockroach/pull/53801
-[#53802]: https://github.com/cockroachdb/cockroach/pull/53802
-[#53837]: https://github.com/cockroachdb/cockroach/pull/53837
-[#53838]: https://github.com/cockroachdb/cockroach/pull/53838
-[#53844]: https://github.com/cockroachdb/cockroach/pull/53844
-[#53846]: https://github.com/cockroachdb/cockroach/pull/53846
-[#53848]: https://github.com/cockroachdb/cockroach/pull/53848
-[#53849]: https://github.com/cockroachdb/cockroach/pull/53849
-[#53853]: https://github.com/cockroachdb/cockroach/pull/53853
-[#53856]: https://github.com/cockroachdb/cockroach/pull/53856
-[#53857]: https://github.com/cockroachdb/cockroach/pull/53857
-[#53863]: https://github.com/cockroachdb/cockroach/pull/53863
-[#53865]: https://github.com/cockroachdb/cockroach/pull/53865
-[#53866]: https://github.com/cockroachdb/cockroach/pull/53866
-[#53868]: https://github.com/cockroachdb/cockroach/pull/53868
-[#53870]: https://github.com/cockroachdb/cockroach/pull/53870
-[#53902]: https://github.com/cockroachdb/cockroach/pull/53902
-[#53930]: https://github.com/cockroachdb/cockroach/pull/53930
-[#53961]: https://github.com/cockroachdb/cockroach/pull/53961
-[#53965]: https://github.com/cockroachdb/cockroach/pull/53965
-[#53999]: https://github.com/cockroachdb/cockroach/pull/53999
-[#54013]: https://github.com/cockroachdb/cockroach/pull/54013
-[#54024]: https://github.com/cockroachdb/cockroach/pull/54024
-[#unknown]: https://github.com/cockroachdb/cockroach/pull/unknown
-[05244b849]: https://github.com/cockroachdb/cockroach/commit/05244b849
-[05de90b83]: https://github.com/cockroachdb/cockroach/commit/05de90b83
-[069715cb6]: https://github.com/cockroachdb/cockroach/commit/069715cb6
-[169aad51e]: https://github.com/cockroachdb/cockroach/commit/169aad51e
-[1a876293e]: https://github.com/cockroachdb/cockroach/commit/1a876293e
-[2453954a5]: https://github.com/cockroachdb/cockroach/commit/2453954a5
-[26013632c]: https://github.com/cockroachdb/cockroach/commit/26013632c
-[282f22876]: https://github.com/cockroachdb/cockroach/commit/282f22876
-[29f88d836]: https://github.com/cockroachdb/cockroach/commit/29f88d836
-[2eb8e9185]: https://github.com/cockroachdb/cockroach/commit/2eb8e9185
-[41899384a]: https://github.com/cockroachdb/cockroach/commit/41899384a
-[43b10cec4]: https://github.com/cockroachdb/cockroach/commit/43b10cec4
-[4474d832b]: https://github.com/cockroachdb/cockroach/commit/4474d832b
-[44ab54282]: https://github.com/cockroachdb/cockroach/commit/44ab54282
-[4c9110f70]: https://github.com/cockroachdb/cockroach/commit/4c9110f70
-[5113f1b6e]: https://github.com/cockroachdb/cockroach/commit/5113f1b6e
-[543017094]: https://github.com/cockroachdb/cockroach/commit/543017094
-[5d0b98964]: https://github.com/cockroachdb/cockroach/commit/5d0b98964
-[5f9d6786c]: https://github.com/cockroachdb/cockroach/commit/5f9d6786c
-[6180d9475]: https://github.com/cockroachdb/cockroach/commit/6180d9475
-[6a071ce17]: https://github.com/cockroachdb/cockroach/commit/6a071ce17
-[6ae5c973d]: https://github.com/cockroachdb/cockroach/commit/6ae5c973d
-[78825b5bb]: https://github.com/cockroachdb/cockroach/commit/78825b5bb
-[78a9e17dd]: https://github.com/cockroachdb/cockroach/commit/78a9e17dd
-[8a25bd6ec]: https://github.com/cockroachdb/cockroach/commit/8a25bd6ec
-[8d3134010]: https://github.com/cockroachdb/cockroach/commit/8d3134010
-[9636b0cf6]: https://github.com/cockroachdb/cockroach/commit/9636b0cf6
-[9bb92efcc]: https://github.com/cockroachdb/cockroach/commit/9bb92efcc
-[9e3fcdedd]: https://github.com/cockroachdb/cockroach/commit/9e3fcdedd
-[a61da063b]: https://github.com/cockroachdb/cockroach/commit/a61da063b
-[ae67eaba0]: https://github.com/cockroachdb/cockroach/commit/ae67eaba0
-[b3566a06e]: https://github.com/cockroachdb/cockroach/commit/b3566a06e
-[b3a3d6037]: https://github.com/cockroachdb/cockroach/commit/b3a3d6037
-[b5f85a771]: https://github.com/cockroachdb/cockroach/commit/b5f85a771
-[b701c7666]: https://github.com/cockroachdb/cockroach/commit/b701c7666
-[b76b7da53]: https://github.com/cockroachdb/cockroach/commit/b76b7da53
-[bbdee2566]: https://github.com/cockroachdb/cockroach/commit/bbdee2566
-[bdddab4a0]: https://github.com/cockroachdb/cockroach/commit/bdddab4a0
-[c2427bd9d]: https://github.com/cockroachdb/cockroach/commit/c2427bd9d
-[d26479066]: https://github.com/cockroachdb/cockroach/commit/d26479066
-[dabbf57f9]: https://github.com/cockroachdb/cockroach/commit/dabbf57f9
-[dd1c98506]: https://github.com/cockroachdb/cockroach/commit/dd1c98506
-[e14ee8ef5]: https://github.com/cockroachdb/cockroach/commit/e14ee8ef5
-[e639c974f]: https://github.com/cockroachdb/cockroach/commit/e639c974f
-[e69f86017]: https://github.com/cockroachdb/cockroach/commit/e69f86017
-[ea20c1dff]: https://github.com/cockroachdb/cockroach/commit/ea20c1dff
-[eec2c1d4f]: https://github.com/cockroachdb/cockroach/commit/eec2c1d4f
-[f0a97790e]: https://github.com/cockroachdb/cockroach/commit/f0a97790e
-[fb7beac83]: https://github.com/cockroachdb/cockroach/commit/fb7beac83
-[fbb4338b8]: https://github.com/cockroachdb/cockroach/commit/fbb4338b8
-[ff3958f1e]: https://github.com/cockroachdb/cockroach/commit/ff3958f1e
-[#7782]: https://github.com/cockroachdb/docs/pull/7782
-[#8035]: https://github.com/cockroachdb/docs/pull/8035
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-beta.2.md b/src/current/_includes/releases/v20.2/v20.2.0-beta.2.md
deleted file mode 100644
index c6d143d66cb..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-beta.2.md
+++ /dev/null
@@ -1,72 +0,0 @@
-## v20.2.0-beta.2
-
-Release Date: September 25, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-beta-2-security-updates">Security updates</h3>
-
-- A new experimental flag `--accept-sql-without-tls` has been introduced for [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) and [`cockroach-start-single-node`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start-single-node). When specified, a secure node will also accept secure SQL connections without TLS. When this flag is enabled:
-
-  - Node-to-node connections still use TLS: the server must still be started with `--certs-dir` and valid [TLS cert configuration](https://www.cockroachlabs.com/docs/v20.2/authentication) for nodes.
-  - Client [authentication](https://www.cockroachlabs.com/docs/v20.2/authentication) (spoof protection) and [authorization](https://www.cockroachlabs.com/docs/v20.2/authorization) (access control and privilege escalation prevention) are performed by CockroachDB as usual, subject to the HBA configuration (for authentication) and SQL privileges (for authorization).
-  - Transport-level security (integrity and confidentiality) for client connections must then be provided by the operator outside of CockroachDB—for example, by using a private network or VPN dedicated to CockroachDB and its client app(s).
-  - The flag only applies to the SQL interface. TLS is still required for the HTTP endpoint (unless `--unencrypted-localhost-http` is passed) and for the RPC endpoint.
-
-		To introduce this feature into an existing cluster:
-
-		<ol><li>Ensure the cluster ugprade is finalized.</li>
-		<li>Set up the HBA configuration to reject `host` connections for any network other than the one that has been secured.</li>
-		<li>Add the command-line flag and restart the nodes. Note that even when the flag is supplied, clients can still negotiate TLS and present a valid TLS certificate to identify themselves (at least under the default HBA configuration).</li></ol>
-    Finally, this flag is experimental and its ergonomics will likely change in a later version. <a href="https://github.com/cockroachdb/cockroach/pull/54198">#54198</a>
-
-<h3 id="v20-2-0-beta-2-sql-language-changes">SQL language changes</h3>
-
-- Previously, certain SQL commands sent over the PostgreSQL FE/BE protocol that were too big would error opaquely. This is now resolved for non-`PREPARE` related statements, clearly error messaging instead. [#54067][#54067]
-- Databases being restored will now be in the offline state, invisible to users, until the data has been restored. This is the same as the existing behavior for restored tables. (This change is also applied to enums and user-defined schemas being restored, which is a change relative to only the v20.2 alpha releases.) [#54296][#54296]
-- Implemented the `ST_SnapToGrid` [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions). [#54054][#54054]
-
-<h3 id="v20-2-0-beta-2-command-line-changes">Command-line changes</h3>
-
-- It is now possible to use password authentication over non-TLS connections with `cockroach` client CLI commands that use only SQL, e.g., [`cockroach sql`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql) or [`cockroach node ls`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node). [#54198][#54198]
-
-<h3 id="v20-2-0-beta-2-bug-fixes">Bug fixes</h3>
-
-- Fixed a "no binding for WithID" internal error when using `WITH RECURSIVE` in queries with placeholders. [#54063][#54063]
-- Fixed a bug whereby a crash during WAL rotation could cause CockroachDB to error on restart reporting corruption. [#54185][#54185]
-- Previously, [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore)s that were cancelled could crash a node. This is now fixed. [#54289][#54289]
-- Fixed two bugs when attempting to [add constraints](https://www.cockroachlabs.com/docs/v20.2/constraints#add-constraints) in the same transaction in which the table was created: Adding a `NOT NULL` constraint no longer fails with the error `check ... does not exist`, and adding a `NOT VALID` foreign key constraint no longer fails with the internal error `table descriptor is not valid: duplicate constraint name`. [#54287][#54287]
-- Fixed a bug that could lead to out of memory errors when dropping large numbers of tables at high frequency. [#54286][#54286]
-- Fixed a bug introduced in a v20.2 alpha release where incorrect caching could incur extra writes to the store during [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) on user-defined schemas. [#54296][#54296]
-
-<h3 id="v20-2-0-beta-2-doc-updates">Doc updates</h3>
-
-- Added guidance on performing large deletes with [`DELETE`](https://www.cockroachlabs.com/docs/v20.2/delete). [#7999][#7999]
-
-<h3 id="v20-2-0-beta-2-contributors">Contributors</h3>
-
-This release includes 22 merged PRs by 14 authors.
-
-[#54054]: https://github.com/cockroachdb/cockroach/pull/54054
-[#54061]: https://github.com/cockroachdb/cockroach/pull/54061
-[#54063]: https://github.com/cockroachdb/cockroach/pull/54063
-[#54065]: https://github.com/cockroachdb/cockroach/pull/54065
-[#54067]: https://github.com/cockroachdb/cockroach/pull/54067
-[#54185]: https://github.com/cockroachdb/cockroach/pull/54185
-[#54198]: https://github.com/cockroachdb/cockroach/pull/54198
-[#54267]: https://github.com/cockroachdb/cockroach/pull/54267
-[#54286]: https://github.com/cockroachdb/cockroach/pull/54286
-[#54287]: https://github.com/cockroachdb/cockroach/pull/54287
-[#54289]: https://github.com/cockroachdb/cockroach/pull/54289
-[#54296]: https://github.com/cockroachdb/cockroach/pull/54296
-[#unknown]: https://github.com/cockroachdb/cockroach/pull/unknown
-[1a0ad39f7]: https://github.com/cockroachdb/cockroach/commit/1a0ad39f7
-[1c3b46c0e]: https://github.com/cockroachdb/cockroach/commit/1c3b46c0e
-[334b72d97]: https://github.com/cockroachdb/cockroach/commit/334b72d97
-[9d63a6348]: https://github.com/cockroachdb/cockroach/commit/9d63a6348
-[b17574537]: https://github.com/cockroachdb/cockroach/commit/b17574537
-[ceb88ac12]: https://github.com/cockroachdb/cockroach/commit/ceb88ac12
-[f6527759d]: https://github.com/cockroachdb/cockroach/commit/f6527759d
-[#7999]: https://github.com/cockroachdb/docs/pull/7999
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-beta.3.md b/src/current/_includes/releases/v20.2/v20.2.0-beta.3.md
deleted file mode 100644
index 9342b3eb4c4..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-beta.3.md
+++ /dev/null
@@ -1,136 +0,0 @@
-## v20.2.0-beta.3
-
-Release Date: September 30, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-beta-3-security-updates">Security updates</h3>
-
-- Added ability to login via [OIDC](https://openid.net/connect/) provider: Operators can now configure a single OIDC authentication provider using a collection of [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) that can provide authentication for users into **the DB Console only** (not for SQL). The user must exist as a SQL user in the database for the authentication to work. [#54659][#54659] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-3-general-changes">General changes</h3>
-
-- Reduced the memory overhead of rangefeeds (i.e., long-lived requests) which reduces the memory overhead for running [`CHANGEFEED`](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds)s over large tables. [#54631][#54631] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-3-sql-language-changes">SQL language changes</h3>
-
-<h4 id="v20-2-0-beta-3-general-sql-updates">General SQL updates</h4>
-
-- After renaming a database, schema, or type, the old names are now immediately inaccessible from other sessions when referred to in schema change statements as soon as the new name is committed. This matches the existing behavior for tables. **This is a change from earlier 20.2 beta releases.** [#54384][#54384] {% comment %}doc{% endcomment %}
-- Added the ability to parse the `ONLY` and `*` (descendant) clauses in [`UPDATE`](https://www.cockroachlabs.com/docs/v20.2/update). This is a no-op as we do not support table inheritance. [#54426][#54426] {% comment %}doc{% endcomment %}
-- Added the ability to parse the `CONNECTION LIMIT [=] iconst32` syntax for [`CREATE DATABASE`](https://www.cockroachlabs.com/docs/v20.2/create-database). This is currently a no-op for -1, and errors for any other value.  By default, the value is -1 (unlimited connections). [#54421][#54421] {% comment %}doc{% endcomment %}
-- Creating cross-database [foreign key references](https://www.cockroachlabs.com/docs/v20.2/foreign-key) is now disallowed (and can be re-enabled via the `sql.cross_db_fks.enabled` cluster setting). [#54520][#54520] {% comment %}doc{% endcomment %}
-- Creating [views](https://www.cockroachlabs.com/docs/v20.2/views) that refer to tables in other databases is now disallowed (and can be re-enabled via the `sql.cross_db_views.enabled` cluster setting). [#54520][#54520] {% comment %}doc{% endcomment %}
-- [Partial index](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) definitions in `pg_catalog` are now formatted with parentheses around the `WHERE` clause. [#54535][#54535]
-- [Interleaved joins](https://www.cockroachlabs.com/docs/v20.2/interleave-in-parent) are now disabled by default and will be entirely removed in the 21.1 release, because they are often slower than the [merge join](https://www.cockroachlabs.com/docs/v20.2/joins#merge-joins). [#54162][#54162] {% comment %}doc{% endcomment %}
-- [Foreign key](https://www.cockroachlabs.com/docs/v20.2/foreign-key) violation errors now fill in the "constraint name" error message field. [#54576][#54576]
-- [`CREATE SCHEDULE`](https://www.cockroachlabs.com/docs/v20.2/create-schedule-for-backup) output now has a column called `label` which was previously called `name`. [#54397][#54397] {% comment %}doc{% endcomment %}
-- If a user/role has ownership over a type or a schema, it is no longer possible to drop them using [`DROP ROLE`](https://www.cockroachlabs.com/docs/v20.2/drop-role). [#54511][#54511] {% comment %}doc{% endcomment %}
-- Implemented [`SHOW GRANTS ON SCHEMA <schema_list>`](https://www.cockroachlabs.com/docs/v20.2/show-grants) [#54596][#54596] {% comment %}doc{% endcomment %}
-- Added a custom `information_schema.type_privileges` table that displays type privileges for each supported type. [#54596][#54596] {% comment %}doc{% endcomment %}
-- Implemented the [`SHOW GRANTS ON TYPE`](https://www.cockroachlabs.com/docs/v20.2/show-grants) command, which shows grants for a specific type. [#54596][#54596] {% comment %}doc{% endcomment %}
-- The [`SHOW GRANTS`](https://www.cockroachlabs.com/docs/v20.2/show-grants) without any table/type/schema/database qualifier now also shows types. The `table_name` column is renamed to `type_name`. [#54596][#54596] {% comment %}doc{% endcomment %}
-- Added support for the Postgres `CREATE EXTENSION` syntax. This no-ops for the `postgis` extension, and gives unimplemented errors for extensions we do not yet support. [#54595][#54595]
-- Added unimplemented errors for using operator classes as parameters for creating an [index](https://www.cockroachlabs.com/docs/v20.2/indexes). [#54595][#54595]
-- [Creating sequences](https://www.cockroachlabs.com/docs/v20.2/create-sequence) that are `OWNED BY` columns in tables in other databases is now disallowed (and can be re-enabled via the `sql.cross_db_sequence_owners.enabled` cluster setting). [#54585][#54585] {% comment %}doc{% endcomment %}
-
-<h4 id="v20-2-0-beta-3-spatial-support-updates">Spatial support updates</h4>
-
-- Implemented the geometry [built-ins](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) `ST_Boundary`, `ST_Difference`, `ST_Relate` (BNR variant), `ST_MinimumClearance`, `ST_MinimumClearanceLine`, `ST_Polygon`, `ST_Angle`, `ST_FrechetDistance`, and `ST_HausdorffDistance`. [#54436][#54436] {% comment %}doc{% endcomment %}
-- Implemented `ST_S2Covering`, which returns the S2 coverings used for indexing for geometry and geography types. [#54433][#54433] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-3-command-line-changes">Command-line changes</h3>
-
-- The timing details for query execution in the SQL shell (e.g., [`cockroach sql`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql), [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql)) have been completed to also properly take query parsing and planning time into account. As previously, this timing display can be disabled with `\set show_times off`. [#54623][#54623] {% comment %}doc{% endcomment %}
-- The format used to display query execution times has been simplified. [#54623][#54623]
-
-<h3 id="v20-2-0-beta-3-db-console-changes">DB Console changes</h3>
-
-- Added ability to login via [OIDC](https://openid.net/connect/) provider. [#54659][#54659] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-3-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug introduced in earlier v20.2 versions where attempting to drop a column which is referenced by multiple indexes fails to drop all relevant indexes. [#54262][#54262]
-- Fixed a bug causing servers to crash with the message "committed txn with writeTooOld". Versions below 20.1.4 are susceptible to this bug. Versions 20.1.4+ will not crash, but instead print messages to the log files. [#54280][#54280]
-- Fixed a bug which would cause an internal error when writing to a table with a recently (concurrent or in the same transaction) `NOT NULL` [enum](https://www.cockroachlabs.com/docs/v20.2/enum) column. [#54432][#54432]
-- CockroachDB now properly returns an appropriate error when the user attempts to rename a [constraint](https://www.cockroachlabs.com/docs/v20.2/constraints) to a name which conflicts with an existing [index](https://www.cockroachlabs.com/docs/v20.2/indexes). [#54430][#54430]
-- Fixed a bug from earlier alphas where [dropping a database](https://www.cockroachlabs.com/docs/v20.2/drop-database) which contained tables using user-defined types could result in panics. [#54431][#54431]
-- Fixed an internal error and/or panic that could occur when the `ST_Distance` or `ST_MaxDistance` functions were compared against a constant or variable with any type other than [float](https://www.cockroachlabs.com/docs/v20.2/float). For example, previously a query with the predicate `WHERE ST_Distance(g1, g2) < 10::int` could cause an error. [#54395][#54395]
-- There was a bug in transaction statistics collection that could let the data structure grow unboundedly large. This is now fixed, and the resetting happens at the same cadence as statement statistics. [#54457][#54457]
-- Fixed an internal error in some cases when recursive [common table expressions](https://www.cockroachlabs.com/docs/v20.2/common-table-expressions) were used. [#54419][#54419]
-- Fixed a bug in our implementation of the Postgres wire protocol where using `CopyIn` with an extremely large message would close the TCP connection with no discernible error. This is changed to now display that the message is too big. [#54187][#54187]
-- Starting with v20.2.0-alpha.3, CockroachDB would crash when performing an [`UPSERT`](https://www.cockroachlabs.com/docs/v20.2/upsert) with a `RETURNING` clause of more than 10k rows. This is now fixed. [#54490][#54490]
-- Fixed a bug where queries that could be [automatically retried](https://www.cockroachlabs.com/docs/v20.2/transactions#automatic-retries) did not respect the `statement_timeout` [session setting](https://www.cockroachlabs.com/docs/v20.2/set-vars). [#54370][#54370]
-- Fixed a bug where a failure while [restoring data](https://www.cockroachlabs.com/docs/v20.2/restore) may have resulted in the restore job getting stuck. This bug was only present on 20.2 alphas and betas. [#54447][#54447]
-- CockroachDB could previously crash in very rare circumstances when there were many queries running in the cluster that were consuming a lot of memory and at least one query was running via the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). This is now fixed. [#54404][#54404]
-- In a previous beta, [backing up](https://www.cockroachlabs.com/docs/v20.2/backup) to an auto-appendable directory would not work if authentication parameters were specified in the URI. [#54621][#54621]
-- Fixed a bug from earlier alphas whereby jobs would not properly populate their `started` timestamp. [#54638][#54638]
-- The first timing column in the trace.txt file collected as part of a [statement diagnostics bundle](https://www.cockroachlabs.com/docs/v20.2/explain-analyze#debug-option) has been fixed. [#54559][#54559]
-
-<h3 id="v20-2-0-beta-3-performance-improvements">Performance improvements</h3>
-
-- The optimizer can now use [partial indexes](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) for [lookup join](https://www.cockroachlabs.com/docs/v20.2/joins#lookup-joins) operations. This results in potentially more efficient query plans for joins on tables with partial indexes. [#54362][#54362] {% comment %}doc{% endcomment %}
-- Lookup semi- and anti-joins are now explored by the optimizer in more cases when the `ON` filter implies a partial index predicate. This may lead to more efficient query plans in some cases. [#54362][#54362]
-- Left outer spatial joins can now be index-accelerated, which can lead to performance improvements in some cases. [#54110][#54110]
-- Spatial anti joins can now be index-accelerated, which can lead to performance improvements in some cases. [#54471][#54471]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-0-beta-3-contributors">Contributors</h3>
-
-This release includes 62 merged PRs by 24 authors.
-
-We would like to thank the following contributors from the CockroachDB community:
-
-- Erik Grinaker
-
-</div>
-
-[#54110]: https://github.com/cockroachdb/cockroach/pull/54110
-[#54162]: https://github.com/cockroachdb/cockroach/pull/54162
-[#54187]: https://github.com/cockroachdb/cockroach/pull/54187
-[#54257]: https://github.com/cockroachdb/cockroach/pull/54257
-[#54262]: https://github.com/cockroachdb/cockroach/pull/54262
-[#54280]: https://github.com/cockroachdb/cockroach/pull/54280
-[#54361]: https://github.com/cockroachdb/cockroach/pull/54361
-[#54362]: https://github.com/cockroachdb/cockroach/pull/54362
-[#54370]: https://github.com/cockroachdb/cockroach/pull/54370
-[#54379]: https://github.com/cockroachdb/cockroach/pull/54379
-[#54384]: https://github.com/cockroachdb/cockroach/pull/54384
-[#54395]: https://github.com/cockroachdb/cockroach/pull/54395
-[#54397]: https://github.com/cockroachdb/cockroach/pull/54397
-[#54404]: https://github.com/cockroachdb/cockroach/pull/54404
-[#54419]: https://github.com/cockroachdb/cockroach/pull/54419
-[#54421]: https://github.com/cockroachdb/cockroach/pull/54421
-[#54426]: https://github.com/cockroachdb/cockroach/pull/54426
-[#54430]: https://github.com/cockroachdb/cockroach/pull/54430
-[#54431]: https://github.com/cockroachdb/cockroach/pull/54431
-[#54432]: https://github.com/cockroachdb/cockroach/pull/54432
-[#54433]: https://github.com/cockroachdb/cockroach/pull/54433
-[#54436]: https://github.com/cockroachdb/cockroach/pull/54436
-[#54447]: https://github.com/cockroachdb/cockroach/pull/54447
-[#54457]: https://github.com/cockroachdb/cockroach/pull/54457
-[#54471]: https://github.com/cockroachdb/cockroach/pull/54471
-[#54490]: https://github.com/cockroachdb/cockroach/pull/54490
-[#54511]: https://github.com/cockroachdb/cockroach/pull/54511
-[#54520]: https://github.com/cockroachdb/cockroach/pull/54520
-[#54535]: https://github.com/cockroachdb/cockroach/pull/54535
-[#54559]: https://github.com/cockroachdb/cockroach/pull/54559
-[#54571]: https://github.com/cockroachdb/cockroach/pull/54571
-[#54576]: https://github.com/cockroachdb/cockroach/pull/54576
-[#54585]: https://github.com/cockroachdb/cockroach/pull/54585
-[#54595]: https://github.com/cockroachdb/cockroach/pull/54595
-[#54596]: https://github.com/cockroachdb/cockroach/pull/54596
-[#54621]: https://github.com/cockroachdb/cockroach/pull/54621
-[#54623]: https://github.com/cockroachdb/cockroach/pull/54623
-[#54631]: https://github.com/cockroachdb/cockroach/pull/54631
-[#54638]: https://github.com/cockroachdb/cockroach/pull/54638
-[#54659]: https://github.com/cockroachdb/cockroach/pull/54659
-[0331caff9]: https://github.com/cockroachdb/cockroach/commit/0331caff9
-[38a5474c7]: https://github.com/cockroachdb/cockroach/commit/38a5474c7
-[4b18d340a]: https://github.com/cockroachdb/cockroach/commit/4b18d340a
-[7509e36c4]: https://github.com/cockroachdb/cockroach/commit/7509e36c4
-[a663be0db]: https://github.com/cockroachdb/cockroach/commit/a663be0db
-[c99f5ff27]: https://github.com/cockroachdb/cockroach/commit/c99f5ff27
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-beta.4.md b/src/current/_includes/releases/v20.2/v20.2.0-beta.4.md
deleted file mode 100644
index b7c87d1761c..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-beta.4.md
+++ /dev/null
@@ -1,33 +0,0 @@
-## v20.2.0-beta.4
-
-Release Date: October 6, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-beta-4-sql-language-changes">SQL language changes</h3>
-
-- The default search path for all sessions is now `$user, public` (as opposed to just `public`). This affects our name resolution semantics; now, if a table is present in both the `public` schema and the schema named the current user's username, an unqualified object name will be searched/placed in the user's schema. This doesn't impact the search semantics of tables in `pg_catalog`/`information_schema`/`temp_schema` -- these continue to be searched before checking the `$user` schema and the `public` schema. [#54586][#54586] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-4-command-line-changes">Command-line changes</h3>
-
-- The display of statement timings in the SQL shell ([`cockroach sql`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql) and [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo)) has been simplified. [#54765][#54765] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-beta-4-bug-fixes">Bug fixes</h3>
-
-- Previously, CockroachDB would crash when `json_object_agg` and `jsonb_object_agg` aggregate functions were used as window functions. Those functions were added in a v20.2 testing release, so only testing v20.2 releases were affected. This is now fixed. [#54657][#54657]
-- Fixed a bug that could cause storage-level corruption under rare circumstances while using the Pebble storage engine. [#54800][#54800]
-
-<h3 id="v20-2-0-beta-4-performance-improvements">Performance improvements</h3>
-
-- Optimized compactions in Pebble to improve read/write performance in some write-heavy workloads. [#54800][#54800]
-
-<h3 id="v20-2-0-beta-4-contributors">Contributors</h3>
-
-This release includes 13 merged PRs by 9 authors.
-
-[#54586]: https://github.com/cockroachdb/cockroach/pull/54586
-[#54657]: https://github.com/cockroachdb/cockroach/pull/54657
-[#54765]: https://github.com/cockroachdb/cockroach/pull/54765
-[#54800]: https://github.com/cockroachdb/cockroach/pull/54800
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-rc.1.md b/src/current/_includes/releases/v20.2/v20.2.0-rc.1.md
deleted file mode 100644
index 28af24e928b..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-rc.1.md
+++ /dev/null
@@ -1,98 +0,0 @@
-## v20.2.0-rc.1
-
-Release Date: October 15, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-rc-1-known-limitations">Known limitations</h3>
-
-- The new Docker image (see [release note below](#new-docker-image)) does not work with the CockroachDB Kubernetes manifest, so customers using Kubernetes cannot upgrade to this testing release. This will be fixed in the next testing release (see [tracking issue][#55390]).
-
-<h3 id="v20-2-0-rc-1-backward-incompatible-changes">Backward-incompatible changes</h3>
-
-- <a name="new-docker-image"></a>CockroachDB Docker images are now based on the RedHat UBI 8 base image instead of Debian 9.12 slim. This will help on-premise customers from a security and compliance perspective. [#55130][#55130] {% comment %}doc{% endcomment %}
-- For PostgreSQL compatibility, the `CREATEROLE` privilege is no longer inherited by children of a [role](https://www.cockroachlabs.com/docs/v20.2/create-role) which has that privilege. For example, say we run these statements: `CREATE ROLE parent WITH CREATEROLE; CREATE ROLE child; GRANT parent TO child;` Previously, the child role would have the `CREATEROLE` privilege. Now it will not. In order to grant this privilege to the child role, it is necessary to run [`ALTER ROLE child WITH CREATEROLE`](https://www.cockroachlabs.com/docs/v20.2/alter-role). [#55305][#55305] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-rc-1-security-updates">Security updates</h3>
-
-- Fixed a case where connections to Google Cloud Storage would ignore the [`--external-io-disable-implicit-credentials` flag](https://www.cockroachlabs.com/docs/v20.2/cockroach-start#security). [#55090][#55090]
-
-<h3 id="v20-2-0-rc-1-general-changes">General changes</h3>
-
-- This change affects schema change jobs originally initiated on clusters running CockroachDB v19.2 or earlier which have not reached a terminal state (i.e., `succeeded`, `failed`, or `canceled`), and which have not finished undergoing an automatic internal migration to allow them to run in v20.1 clusters. These jobs will now be marked as `failed` upon upgrading to v20.2. Users who have ongoing schema changes initiated in v19.2 are advised to wait for them to finish running on v20.1 before upgrading to v20.2 (at the very least, wait until at least the v20.1 internal migration for the job has completed, which is indicated in the logs).  This may also affect users who have schema change jobs from prior to v20.1 which are stuck in a non-terminal state due to bugs despite making no progress. In this case, marking the job as failed has no real effect. [#54902][#54902] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-rc-1-sql-language-changes">SQL language changes</h3>
-
-- Implemented the geometry [built-in functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) `ST_SwapOrdinates` and `ST_OrderingEquals`. [#54564][#54564] {% comment %}doc{% endcomment %}
-- Setting and retrieving zone configurations on tables from non-public schemas is now permitted. [#54849][#54849]
-- A [string](https://www.cockroachlabs.com/docs/v20.2/string) literal like `'{X, Y, Z}'` is now automatically casted to an [`ARRAY`](https://www.cockroachlabs.com/docs/v20.2/array) when appropriate. Support is added for `UUID`, `DATE`, `BOOL`, `TIME`, `TIMETZ`, `TIMESTAMP`, `TIMESTAMPTZ`, `FLOAT`, `INET`, `VARBIT`, and `INTERVAL` arrays. Note that `INT` and `DECIMAL` arrays were already supported. [#54944][#54944] {% comment %}doc{% endcomment %}
-- The `sql.mem.root` timeseries is now available to track the accounted memory usage of all memory in the cluster. [#54904][#54904] {% comment %}doc{% endcomment %}
-- Populated the `datdba` field of `pg_catalog.pg_database`. This was previously `DNull`. [#55069][#55069]
-- [`SHOW SEQUENCES`](https://www.cockroachlabs.com/docs/v20.2/show-sequences) now displays sequences in user-defined schemas. The schema is now displayed in a newly added `sequence_schema` column. [#55175][#55175] {% comment %}doc{% endcomment %}
-- Added the `parent_schema_id` field to `crdb_internal.tables`. [#55264][#55264]
-
-<h3 id="v20-2-0-rc-1-command-line-changes">Command-line changes</h3>
-
-- The `--help` texts and informational messages upon [server start-up](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) have been modified to better inform the user about the nature and risks of the `--insecure` flag. [#55025][#55025]
-
-<h3 id="v20-2-0-rc-1-db-console-changes">DB Console changes</h3>
-
-- The [DB Console's Databases page](https://www.cockroachlabs.com/docs/v20.2/ui-databases-page) now includes tables that live within user-defined schemas. [#54901][#54901] {% comment %}doc{% endcomment %}
-- Added a SQL Memory graph to the [SQL Metrics dashboard](https://www.cockroachlabs.com/docs/v20.2/ui-sql-dashboard) that tracks the current number of bytes in all SQL memory accounts. This number is a current snapshot of the number whose maximum is set by `--max-sql-memory`. [#54904][#54904] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-0-rc-1-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug where previous testing releases of v20.2 would not properly clear grants and owners on non-cluster restores. [#54854][#54854]
-- Fixed a bug in v20.2 testing releases that under-accounted for scan memory. Note that the bug wasn't a regression from v20.1, which never had any scan memory accounting at all. [#54894][#54894]
-- Fixed issue when jobs duration could be negative value or increased periodically for finished jobs. [#54872][#54872]
-- Fixed a rare bug which could lead to index backfills failing in the face of transaction restarts. [#54858][#54858]
-- Fixed a bug which led to inscrutable errors being returned when creating a backup failed; for example, due to protected timestamp limits. [#54967][#54967]
-- Fixed a bug where a transaction restart at the wrong moment during a restore could leave descriptors offline after the restore completed successfully. [#54965][#54965]
-- Fixed a bug where the presence of types or schemas in a database to be restored would prevent the database from being cleaned up on restore failure. [#55060][#55060]
-- Previously, canceling schema changes when there were multiple queued schema changes could result in future schema changes being stuck. This has been fixed. [#55056][#55056]
-- Fixed an error that could occur during planning when attempting to create or use a partial index. The error implied that the partial index could not be used (e.g., "my_index is a partial index that does not contain all the rows needed to execute this query") when in fact the partial index could be used correctly. [#55080][#55080]
-- Cross-database temporary schemas are now properly resolved. [#55198][#55198]
-- Previously, restoring a cluster backup that contained user-defined schemas or user-defined types in `defaultdb` would fail. [#55249][#55249]
-- Options set on users (e.g., `ALTER USER u CREATEDB`) were not included in cluster backups and thus not restored. [Role options](https://www.cockroachlabs.com/docs/v20.2/alter-user) have been introduced in v20.2. [#55250][#55250]
-- Previously, all tables in any schema showed up as `public` in the `schema_name` column in the `crdb_internal` table. They now display the correct schema. [#55264][#55264]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-0-rc-1-contributors">Contributors</h3>
-
-This release includes 49 merged PRs by 24 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Azdim Zul Fahmi (first-time contributor)
-- Erik Grinaker
-
-</div>
-
-[#54564]: https://github.com/cockroachdb/cockroach/pull/54564
-[#54849]: https://github.com/cockroachdb/cockroach/pull/54849
-[#54854]: https://github.com/cockroachdb/cockroach/pull/54854
-[#54858]: https://github.com/cockroachdb/cockroach/pull/54858
-[#54872]: https://github.com/cockroachdb/cockroach/pull/54872
-[#54894]: https://github.com/cockroachdb/cockroach/pull/54894
-[#54901]: https://github.com/cockroachdb/cockroach/pull/54901
-[#54902]: https://github.com/cockroachdb/cockroach/pull/54902
-[#54904]: https://github.com/cockroachdb/cockroach/pull/54904
-[#54944]: https://github.com/cockroachdb/cockroach/pull/54944
-[#54965]: https://github.com/cockroachdb/cockroach/pull/54965
-[#54967]: https://github.com/cockroachdb/cockroach/pull/54967
-[#55025]: https://github.com/cockroachdb/cockroach/pull/55025
-[#55056]: https://github.com/cockroachdb/cockroach/pull/55056
-[#55060]: https://github.com/cockroachdb/cockroach/pull/55060
-[#55069]: https://github.com/cockroachdb/cockroach/pull/55069
-[#55080]: https://github.com/cockroachdb/cockroach/pull/55080
-[#55090]: https://github.com/cockroachdb/cockroach/pull/55090
-[#55130]: https://github.com/cockroachdb/cockroach/pull/55130
-[#55175]: https://github.com/cockroachdb/cockroach/pull/55175
-[#55198]: https://github.com/cockroachdb/cockroach/pull/55198
-[#55249]: https://github.com/cockroachdb/cockroach/pull/55249
-[#55250]: https://github.com/cockroachdb/cockroach/pull/55250
-[#55264]: https://github.com/cockroachdb/cockroach/pull/55264
-[#55305]: https://github.com/cockroachdb/cockroach/pull/55305
-[#55390]: https://github.com/cockroachdb/cockroach/pull/55390
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-rc.2.md b/src/current/_includes/releases/v20.2/v20.2.0-rc.2.md
deleted file mode 100644
index 32a5d0a476e..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-rc.2.md
+++ /dev/null
@@ -1,37 +0,0 @@
-## v20.2.0-rc.2
-
-Release Date: October 20, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-rc-2-backward-incompatible-changes">Backward-incompatible changes</h3>
-
-- The Docker image is now based on RedHat's ubi8/ubi-minimal image (instead of ubi8/ubi). This image is smaller. [#55519][#55519]
-
-<h3 id="v20-2-0-rc-2-bug-fixes">Bug fixes</h3>
-
-- Prevented a crash in pre-release v20.2 binaries in plans that use the new virtual table lookup join feature. [#55321][#55321]
-- CockroachDB now returns an appropriate error when attempting to partition by an [`ENUM`](https://www.cockroachlabs.com/docs/v20.2/enum) column instead of crashing. [#55357][#55357]
-- Fixed an issue where [DB Console](https://www.cockroachlabs.com/docs/v20.2/ui-overview) screens were not working properly when the user was logged in with a username containing uppercase or non-normalized unicode characters. [#55384][#55384]
-- The OIDC-based UI process now respects the [`LOGIN` role option](https://www.cockroachlabs.com/docs/v20.2/create-role). [#55384][#55384]
-- Added the `hostname` command to the Docker image so the image can be used with the CockroachDB Helm chart and `cockroach-operator`. [#55390][#55390]
-- Fixed a bug that caused incorrect query results on tables with partial indexes. This bug did not affect any queries involving tables without partial indexes. [#55394][#55394]
-- Previously, observer statements (e.g., `SHOW SYNTAX`) and `PREPARE` statements would display a negative execution time on the client. This is now fixed. [#55431][#55431]
-- The [`CREATE USER` statement](https://www.cockroachlabs.com/docs/v20.2/create-user) without explicit `NOLOGIN` option implicitly grants `LOGIN`, and so requires the `CREATELOGIN` privilege. This was not checked properly, and is now enforced. This bug was introduced earlier in the v20.2 development cycle. [#55369][#55369]
-- The `information_schema.tables` metadata table no longer ignores tables from other schemas when searching based on table name. [#55522][#55522]
-
-<h3 id="v20-2-0-rc-2-contributors">Contributors</h3>
-
-This release includes 11 merged PRs by 9 authors.
-
-[#55321]: https://github.com/cockroachdb/cockroach/pull/55321
-[#55357]: https://github.com/cockroachdb/cockroach/pull/55357
-[#55369]: https://github.com/cockroachdb/cockroach/pull/55369
-[#55384]: https://github.com/cockroachdb/cockroach/pull/55384
-[#55390]: https://github.com/cockroachdb/cockroach/pull/55390
-[#55394]: https://github.com/cockroachdb/cockroach/pull/55394
-[#55431]: https://github.com/cockroachdb/cockroach/pull/55431
-[#55519]: https://github.com/cockroachdb/cockroach/pull/55519
-[#55522]: https://github.com/cockroachdb/cockroach/pull/55522
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-rc.3.md b/src/current/_includes/releases/v20.2/v20.2.0-rc.3.md
deleted file mode 100644
index 8a59c4f5e13..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-rc.3.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## v20.2.0-rc.3
-
-Release Date: October 26, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-rc-3-db-console-changes">DB Console changes</h3>
-
-- Added the Transactions and Transactions Details pages. These pages allow for viewing stats at the transaction level. [#55717][#55717]
-
-<h3 id="v20-2-0-rc-3-bug-fixes">Bug fixes</h3>
-
-- Previously, we used the `HTTPS_PROXY` variable for the "join RPC" when adding a node to the cluster (the RPC prevents new clusters from starting or adding nodes to an existing cluster). The proxy needed to be configured to transparently pass HTTP/2+GRPC inter-node traffic. This was an unintentional addition, and this patch ignores the proxies for all intra-node traffic. They were already ignored in releases prior to v20.2 testing releases. [#55504][#55504]
-- Previously, the filenames for generated goroutine, CPU, and memory profiles were sometimes incorrect, which resulted in repeated warnings like `strconv.ParseUint: parsing "txt": invalid syntax` in log files. This has been corrected. [#55366][#55366]
-- Fixed a bug that could occur for [spatial](https://www.cockroachlabs.com/docs/v20.2/spatial-features) queries involving a join between two spatial columns, when there was an additional filter on one of the spatial columns, and that column also had a [GIN index](https://www.cockroachlabs.com/docs/v20.2/inverted-indexes) defined. This bug could cause incorrect results to be returned, in which some rows were omitted from the output when they should have been included. [#55673][#55673]
-- An [`INSERT`](https://www.cockroachlabs.com/docs/v20.2/insert) into a table with a [foreign key](https://www.cockroachlabs.com/docs/v20.2/foreign-key) reference to a table with a [partial index](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) no longer causes an error. [#55703][#55703]
-- [Foreign keys](https://www.cockroachlabs.com/docs/v20.2/foreign-key) can no longer reference columns that are only indexed by a partial unique index. A partial unique index does not guarantee uniqueness in the entire table; therefore, the column indexed is not guaranteed to be a unique key. [#55703][#55703]
-- Previously, cluster [backups](https://www.cockroachlabs.com/docs/v20.2/backup) taken from before v20.2 could not be restored in v20.2 clusters, and would result in an error message about failing to restore a system table. This is now fixed. [#55719][#55719]
-- Previously, changing the parent database and schema of a table using [`RENAME`](https://www.cockroachlabs.com/docs/v20.2/rename-table) was seemingly permitted but would lead to corruption of the table metadata. Now, an error is returned when attempting to rename a table to a different database&mdash; except in the case where both the source and target schemas are the `public` schema in each database, which continues to be supported. [#55723][#55723]
-- Fixed a crash that would occur when performing a [`SHOW BACKUP`](https://www.cockroachlabs.com/docs/v20.2/show-backup) against a backup that contains a table that references a type in another database. This state was only reachable in v20.2 testing releases. [#55786][#55786]
-- Tables can no longer be moved to a different database using the [`ALTER TABLE ... RENAME TO`](https://www.cockroachlabs.com/docs/v20.2/rename-table) statement if they have columns using user-defined types (i.e., [`ENUM`](https://www.cockroachlabs.com/docs/v20.2/enum)). [#55781][#55781]
-
-<h3 id="v20-2-0-rc-3-contributors">Contributors</h3>
-
-This release includes 14 merged PRs by 14 authors.
-
-[#55366]: https://github.com/cockroachdb/cockroach/pull/55366
-[#55504]: https://github.com/cockroachdb/cockroach/pull/55504
-[#55639]: https://github.com/cockroachdb/cockroach/pull/55639
-[#55673]: https://github.com/cockroachdb/cockroach/pull/55673
-[#55703]: https://github.com/cockroachdb/cockroach/pull/55703
-[#55717]: https://github.com/cockroachdb/cockroach/pull/55717
-[#55719]: https://github.com/cockroachdb/cockroach/pull/55719
-[#55723]: https://github.com/cockroachdb/cockroach/pull/55723
-[#55781]: https://github.com/cockroachdb/cockroach/pull/55781
-[#55786]: https://github.com/cockroachdb/cockroach/pull/55786
diff --git a/src/current/_includes/releases/v20.2/v20.2.0-rc.4.md b/src/current/_includes/releases/v20.2/v20.2.0-rc.4.md
deleted file mode 100644
index 8680974aa49..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0-rc.4.md
+++ /dev/null
@@ -1,15 +0,0 @@
-## v20.2.0-rc.4
-
-Release Date: November 3, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-rc-4-bug-fixes">Bug fixes</h3>
-
-- A bug in earlier v20.2 versions caused some [`GRANT`](https://www.cockroachlabs.com/docs/v20.2/grant) and [`REVOKE`](https://www.cockroachlabs.com/docs/v20.2/revoke) commands on [user-defined schemas](https://www.cockroachlabs.com/docs/v20.2/create-schema) to incorrectly fail with an "invalid privileges" error. This affected schemas that were created after granting privileges at the database level. This bug is now resolved.
-
-<h3 id="v20-2-0-rc-4-contributors">Contributors</h3>
-
-This release includes 1 merged PR by 1 author.
diff --git a/src/current/_includes/releases/v20.2/v20.2.0.md b/src/current/_includes/releases/v20.2/v20.2.0.md
deleted file mode 100644
index de849cd8dc0..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.0.md
+++ /dev/null
@@ -1,144 +0,0 @@
-## v20.2.0
-
-Release Date: November 10, 2020
-
-With the release of CockroachDB v20.2, we've made a variety of productivity, management, and performance improvements. Check out a [summary of the most significant user-facing changes](#v20-2-0-feature-summary) and then [upgrade to CockroachDB v20.2](https://www.cockroachlabs.com/docs/v20.2/upgrade-cockroach-version).
-
-To learn more, read the [v20.2 blog post](https://www.cockroachlabs.com/blog/cockroachdb-20-2-release/).
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a63162.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-0-cockroachcloud">CockroachCloud</h3>
-
-<a href="https://cockroachlabs.cloud/signup?referralId=docs_crdb_release_notes" rel="noopener" target="_blank">Get a free v20.2 cluster on CockroachCloud</a>
-
-Recent CockroachCloud improvements:
-
-- [Create a 30-day free CockroachCloud cluster](https://www.cockroachlabs.com/docs/cockroachcloud/quickstart).
-- [Add or remove nodes](https://www.cockroachlabs.com/docs/cockroachcloud/cluster-management#add-or-remove-nodes-from-a-cluster) through the CockroachDB {{ site.data.products.cloud }} Console.
-- [Set up VPC peering](https://www.cockroachlabs.com/docs/cockroachcloud/network-authorization) for clusters running on GCP.
-- [View backups](https://www.cockroachlabs.com/docs/cockroachcloud/use-managed-service-backups) that Cockroach Labs has taken for your CockroachCloud cluster.
-
-<h3 id="v20-2-0-feature-summary">Feature summary</h3>
-
-This section summarizes the most significant user-facing changes in v20.2.0. For a complete list of features and changes, including bug fixes and performance improvements, see the [release notes]({% link releases/index.md %}#testing-releases) for previous testing releases. You can also search for [what's new in v20.2 in our docs](https://www.cockroachlabs.com/docs/search?query=new+in+v20.2).
-
-{{site.data.alerts.callout_info}}
-"Core" features are freely available in the core version and do not require an enterprise license. "Enterprise" features require an [enterprise license](https://www.cockroachlabs.com/get-cockroachdb/enterprise/). [CockroachCloud clusters](https://cockroachlabs.cloud/) include all enterprise features.
-{{site.data.alerts.end}}
-
-- [SQL](#v20-2-0-sql)
-- [Recovery and I/O](#v20-2-0-recovery-and-i-o)
-- [Deployment and Operations](#v20-2-0-deployment-and-operations)
-- [Observability](#v20-2-0-observability)
-- [Backward-incompatible changes](#v20-2-0-backward-incompatible-changes)
-- [Deprecations](#v20-2-0-deprecations)
-- [Known limitations](#v20-2-0-known-limitations)
-- [Education](#v20-2-0-education)
-
-<style>
-    table td:first-child {
-        min-width: 100px !important;
-    }
-    table td:nth-child(2) {
-        min-width: 200px !important;
-    }
-</style>
-
-<h4 id="v20-2-0-sql">SQL</h4>
-
-Version | Feature | Description
---------|---------|------------
-Core | **Third-Party Tool Support** | CockroachDB now fully supports several additional [third-party database tools](https://www.cockroachlabs.com/docs/v20.2/third-party-database-tools), including Spring Boot, Hibernate, and ActiveRecord.
-Core | **Spatial Support** | CockroachDB now supports [spatial data types](https://www.cockroachlabs.com/docs/v20.2/spatial-data), [spatial indexes](https://www.cockroachlabs.com/docs/v20.2/spatial-indexes), and [spatial functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#spatial-functions), as well as the ability to migrate spatial data from various formats such as [Shapefiles](https://www.cockroachlabs.com/docs/v20.2/migrate-from-shapefiles), [GeoJSON](https://www.cockroachlabs.com/docs/v20.2/migrate-from-geojson), [GeoPackages](https://www.cockroachlabs.com/docs/v20.2/migrate-from-geopackage), and [OpenStreetMap](https://www.cockroachlabs.com/docs/v20.2/migrate-from-openstreetmap).
-Core | **User-Defined Schemas** | You can now [create user-defined logical schemas](https://www.cockroachlabs.com/docs/v20.2/create-schema), as well [alter user-defined schemas](https://www.cockroachlabs.com/docs/v20.2/alter-schema), [drop user-defined schemas](https://www.cockroachlabs.com/docs/v20.2/drop-schema), and [convert databases to user-defined schemas](https://www.cockroachlabs.com/docs/v20.2/convert-to-schema).
-Core | **Partial Indexes** | You can now use [partial indexes](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) to specify a subset of rows and columns in a table that evaluate to true on a `WHERE` filter defined at index creation.
-Core | **`ENUM` data types** | CockroachDB now supports the creation and management of [user-defined `ENUM` data types](https://www.cockroachlabs.com/docs/v20.2/enum) consisting of sets of enumerated, static values.
-Core | **Materialized Views** | CockroachDB now supports [materialized views](https://www.cockroachlabs.com/docs/v20.2/views#materialized-views), or views that store their selection query results on-disk.
-Core | **View Replacement** | CockroachDB now supports [replacing an existing view](https://www.cockroachlabs.com/docs/v20.2/create-view#replace-an-existing-view) with the `CREATE OR REPLACE VIEW` syntax.
-Core | **Foreign Key Performance and Compatibility** | When adding the [`FOREIGN KEY`](https://www.cockroachlabs.com/docs/v20.2/foreign-key) constraint, it is no longer required to have an index on the referencing columns.
-Core | **`EXPLAIN` Improvements** | The response of the [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) statement now includes the estimated number of rows scanned by the query as well as other usability improvements.
-Core | **Disallowing Full Table Scans** | You can use the new [`disallow_full_table_scans` session variable](https://www.cockroachlabs.com/docs/v20.2/set-vars) to disallow full table and secondary index scans.
-Core | **Altering Column Data Types** | You can now [alter the data type of table column](https://www.cockroachlabs.com/docs/v20.2/alter-column#altering-column-types). Note that this feature is [experimental](https://www.cockroachlabs.com/docs/v20.2/experimental-features) and is subject to change.
-
-<h4 id="v20-2-0-recovery-and-i-o">Recovery and I/O</h4>
-
-Version | Feature | Description
---------|---------|------------
-Core | **Backup/Restore in Core Version** | The core version of CockroachDB now lets you perform [full cluster backups](https://www.cockroachlabs.com/docs/v20.2/take-full-and-incremental-backups#full-backups), all [restore](https://www.cockroachlabs.com/docs/v20.2/restore) options, as well as bulk [exports](https://www.cockroachlabs.com/docs/v20.2/export). Incremental backups, locality-aware backups, and other advanced backup functionality continue to require an enterprise license.
-Core | **Backup Scheduling** | You can now [create schedules for CockroachDB backups](https://www.cockroachlabs.com/docs/v20.2/manage-a-backup-schedule#create-a-new-backup-schedule), as well as [view, pause, resume, and drop backup schedules](https://www.cockroachlabs.com/docs/v20.2/manage-a-backup-schedule#view-and-control-the-backup-schedule). Once a scheduled backup is created, you can use [`SHOW SCHEDULE`](https://www.cockroachlabs.com/docs/v20.2/show-schedules) to inspect the schedule status and any errors and then use [`SHOW BACKUPS IN` and `SHOW BACKUP`](https://www.cockroachlabs.com/docs/v20.2/manage-a-backup-schedule#view-scheduled-backup-details) to inspect the details of individual backups. Note that incremental backups, locality-aware backups, and other advanced backup functionality require an enterprise license.
-Core | **Import with User-Scoped Storage** | In addition to supporting bulk imports from cloud storage, CockroachDB now lets you [upload CSV files from your local machine to user-scoped file storage](https://www.cockroachlabs.com/docs/v20.2/use-userfile-for-bulk-operations) in your cluster. Once uploaded, a userfile can be reference by the `IMPORT` command to import data into a table. Userfiles can also be [listed](https://www.cockroachlabs.com/docs/v20.2/cockroach-userfile-list) and [deleted](https://www.cockroachlabs.com/docs/v20.2/cockroach-userfile-delete) via CLI commands.
-Core | **Import with Default Expressions** | You can now use [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into) to import supported [`DEFAULT` expressions](https://www.cockroachlabs.com/docs/v20.2/import-into#supported-default-expressions) as well as [computed columns](https://www.cockroachlabs.com/docs/v20.2/computed-columns).
-Enterprise | **KMS Support for Encrypted Backups** | You can now use [AWS Key Management Service (KMS)](https://www.cockroachlabs.com/docs/v20.2/take-and-restore-encrypted-backups#use-aws-key-management-service) to encrypt the files that full or incremental backups generate.
-
-<h4 id="v20-2-0-deployment-and-operations">Deployment and Operations</h4>
-
-Version | Feature | Description
---------|---------|------------
-Core | **Kubernetes Operator** | The CockroachDB Kubernetes Operator eases [deployment of secure CockroachDB clusters on Kubernetes](https://www.cockroachlabs.com/docs/v20.2/orchestrate-cockroachdb-with-kubernetes). The Operator can be used to create StatefulSets, authenticate pods, scale CockroachDB clusters, and perform rolling upgrades. The Operator is in beta and is not yet production-ready.
-Core | **Log Redaction** | When gathering log files via the [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) or [`cockroach debug merge-logs`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-merge-logs) command, you can use the new `--redact-logs` flag to redact sensitive data. Note that this flag removes sensitive information only from the log files; other items collected by the `debug zip` command may still contain sensitive information.
-Core | **Certificate Revocation with OCSP** | CockroachDB now supports [certificate revocation](https://www.cockroachlabs.com/docs/v20.2/create-security-certificates-custom-ca#certificate-revocation-with-ocsp) for custom CA certificate setups running an OCSP server.
-Enterprise | **SSO in the DB Console** | The DB Console now supports [single sign-on (SSO)](https://www.cockroachlabs.com/docs/v20.2/sso) via OpenID Connect (OIDC), an authentication layer built on top of OAuth 2.0. When SSO is configured and enabled, the DB Console login page displays an OAuth login button in addition to the password access option. Note that this feature is [experimental](https://www.cockroachlabs.com/docs/v20.2/experimental-features) and is subject to change.
-Core | **Permission-Based Object Ownership** | All database objects now have [owners](https://www.cockroachlabs.com/docs/v20.2/owner-to). By default, the user who created an object is the owner of the object and has all privileges on the object. Any roles that are members of the `owner` role have all privileges on the objects the role owns. The admin is the default owner for all non-system objects without owners. System objects without owners have `node` as their owner.
-Core | **Fine-Grained SQL Privileges** | CockroachDB now allows you to [grant users administrative abilities](https://www.cockroachlabs.com/docs/v20.2/create-role#parameters) without giving them full admin access.
-
-<h4 id="v20-2-0-observability">Observability</h4>
-
-Version | Feature | Description
---------|---------|------------
-Core | **Transaction Details** | The new [**Transactions** page](https://www.cockroachlabs.com/docs/v20.2/ui-transactions-page) of the DB Console shows you details about all client-initiated transactions in the cluster that help you identify and troubleshoot frequently retried and high-latency transactions.
-Core | **Sessions Details** | The new [**Sessions** page](https://www.cockroachlabs.com/docs/v20.2/ui-sessions-page) of the DB Console shows you details about all active and idle sessions in the cluster, with session age, memory usage, SQL statement, and other details available for active sessions.
-
-<h4 id="v20-2-0-backward-incompatible-changes">Backward-incompatible changes</h4>
-
-Before [upgrading to CockroachDB v20.2](https://www.cockroachlabs.com/docs/v20.2/upgrade-cockroach-version), be sure to review the following backward-incompatible changes and adjust your deployment as necessary.
-
-- A CockroachDB node started with [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) without the `--join` flag no longer automatically initializes the cluster. The `cockroach init` command is now mandatory. The auto-initialization behavior had been deprecated in version 19.2.
-- CockroachDB v20.1 introduced a new rule for the `--join` flag to [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start), causing it to prefer SRV records, if present in DNS, to look up the peer nodes to join. This feature is experimental, and has been found to cause disruption in certain deployments. To reduce this disruption and the resulting UX surprise, the feature is now gated behind a new command-line flag `--experimental-dns-srv` which must now be explicitly passed to [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) to enable it.
-- The `--socket` flag of [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start) was deprecated in v20.1 and has been removed in v20.2. Use `--socket-dir` instead.
-- The textual error and warning messages displayed by [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) under various circumstances have been updated. Meanwhile, the message "`ok`" remains as an indicator that the operation has likely succeeded.
-- [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) now prints out progress details on its standard error stream, even when `--logtostderr` is not specified. Previously, nothing was printed on standard error. Scripts that wish to ignore this output can redirect the stderr stream.
-- Previously, the phase of server shutdown responsible for range lease transfers to other nodes would give up after 10000 attempts of transferring replica leases away, regardless of the value of `server.shutdown.lease_transfer_wait`. The limit of 10000 attempts has been removed, so that now only the maximum duration `server.shutdown.lease_transfer_wait` applies.
-- Previously, issuing a `SIGTERM` signal twice or after another signal initiated a hard shutdown for a node. Now the first `SIGTERM` signal initiates a graceful shutdown and further occurrences of `SIGTERM` are ignored. To initiate a hard shutdown, issue `SIGINT` two times (or issue a `SIGINT` signal once after a `SIGTERM` signal).
-- Clusters running alphas of 20.2 that use `ENUM` types will not be able to upgrade to betas or major releases of 20.2 due to internal representation changes.
-- Specifying the same option multiple times in the `WITH` clause of the [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) or [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) statement now results in an error message. Additionally, quoted option names are no longer allowed.
-- The copy of system and `crdb_internal` tables extracted by [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) is now written using the TSV format (inside the zip file), instead of an ASCII-art table as previously.
-- The [`SHOW RANGE FOR ROW`](https://www.cockroachlabs.com/docs/v20.2/show-range-for-row) statement now takes a tuple of the row's index columns instead of the full column set of the row.
-- For expression typing involving only operations on constant literals, each constant literal is now assigned a [`type`](https://www.cockroachlabs.com/docs/v20.2/data-types) before calculation. Previously, a `type` was assigned only to the result.
-- The file names for heap profile dumps now use the naming scheme `memprof.<date-and-time>.<heapsize>`. Previously, they were named `memprof.<heapsize>.<date-and-time>`.
-- The Docker image is now based on RedHat's UBI instead of Debian.
-- `cockroach node decommission --wait=live` is no longer supported. It was deprecated in an earlier release.
-
-<h4 id="v20-2-0-deprecations">Deprecations</h4>
-
-- The [`cockroach quit`](https://www.cockroachlabs.com/docs/v20.2/cockroach-quit) command is now deprecated. For decommissioning, use the [`cockroach node decommission`](https://www.cockroachlabs.com/docs/v20.2/cockroach-node) command. To terminate the cockroach process, use signals.
-- The [`cockroach dump`](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) command is now deprecated. Instead, back up your data in a [full backup](https://www.cockroachlabs.com/docs/v20.2/take-full-and-incremental-backups), [export](https://www.cockroachlabs.com/docs/v20.2/export) your data in plain text format, or view table schema in plaintext with [`SHOW CREATE TABLE`](https://www.cockroachlabs.com/docs/v20.2/show-create).
-- The `--log-dir-max-size` command-line flag is now deprecated and has been replaced with a new flag named `--log-group-max-size`. The flags limit the combined size of all files generated by one *logging group* inside CockroachDB.
-- CockroachDB built-in SQL shell ([`cockroach sql`](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql) and/or [`cockroach demo`](https://www.cockroachlabs.com/docs/v20.2/cockroach-demo)) no longer prompts for more lines of input after the user enters `BEGIN` before sending the input to the server. Instead, full lines of input are always sent to the server immediately. The corresponding client-side option `smart_prompt` is thus ineffective and deprecated. It will be removed in a later version.
-- Cross-database references are deprecated in v20.2 (see [tracking issue](https://github.com/cockroachdb/cockroach/issues/55791)). In v20.2, creating cross-database references is disabled for [foreign keys](https://www.cockroachlabs.com/docs/v20.2/foreign-key), [views](https://www.cockroachlabs.com/docs/v20.2/views), and [sequence ownership](https://www.cockroachlabs.com/docs/v20.2/create-sequence) with the `sql.cross_db_fks.enabled`, `sql.cross_db_views.enabled`, and `sql.cross_db_sequence_owners.enabled` [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) set to `false` by default. Note that any cross-database references that were created prior to a v20.2 upgrade are still allowed and are unaffected by these cluster settings.
-
-    After upgrading to v20.2, we recommend removing all cross-database references, and, if necessary, creating object references across user-defined schemas instead. For details on migrating a cluster that does not use user-defined schemas in its naming hierarchy, see [Migrating namespaces from previous versions of CockroachDB](https://www.cockroachlabs.com/docs/v20.2/sql-name-resolution#migrating-namespaces-from-previous-versions-of-cockroachdb).
-- [Interleaved tables](https://www.cockroachlabs.com/docs/v20.2/interleave-in-parent) are deprecated in CockroachDB v20.2, and will be permanently disabled in a future release (see [tracking issue](https://github.com/cockroachdb/cockroach/issues/52009)).
-
-    After upgrading to v20.2, we recommend that you convert any existing interleaved tables to non-interleaved tables and replace any existing interleaved secondary indexes with non-interleaved indexes. For instructions, see [`INTERLEAVE IN PARENT` Deprecation](https://www.cockroachlabs.com/docs/v20.2/interleave-in-parent#deprecation).
-
-<h4 id="v20-2-0-known-limitations">Known limitations</h4>
-
-For information about new and unresolved limitations in CockroachDB v20.2, with suggested workarounds where applicable, see [Known Limitations](https://www.cockroachlabs.com/docs/v20.2/known-limitations).
-
-<h4 id="v20-2-0-education">Education</h4>
-
-Area | Topic | Description
------|-------|------------
-Training | **Online Course for Python Developers** | Launched a new self-paced course on Cockroach University, [CockroachDB for Python Developers](https://university.cockroachlabs.com). This course walks you through building a full-stack vehicle-sharing app in Python using the popular SQLAlchemy ORM and a free CockroachCloud cluster as the back-end.
-Docs | **Interactive In-Browser Tutorials** | Added tutorials that can be completed entirely in your browser, without downloads or installations, from [Learning CockroachDB SQL](https://www.cockroachlabs.com/docs/interactive-tutorials/learn-cockroachdb-sql-interactive) to [Storing and Querying JSON](https://www.cockroachlabs.com/docs/interactive-tutorials/demo-json-support-interactive).
-Docs | **Transaction Retry Error Reference** | Documented the various [errors that developers encounter around transaction retries](https://www.cockroachlabs.com/docs/v20.2/transaction-retry-error-reference) in CockroachDB, explaining why each error happens and what to do about it.
-Docs | **Disaster Recovery** | Documented how to plan for and recover from [various types of disasters](https://www.cockroachlabs.com/docs/v20.2/disaster-recovery), from hardware failure, to data failure, to compromised security keys.
-Docs | **Batch Deletes** | Added guidance on [performing large deletes](https://www.cockroachlabs.com/docs/v20.2/bulk-delete-data) across various scenarios.
-Docs | **Multi-Region Kubernetes on EKS** | Added a tutorial on orchestrating a secure [CockroachDB multi-region deployment on Amazon EKS](https://www.cockroachlabs.com/docs/v20.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster).
diff --git a/src/current/_includes/releases/v20.2/v20.2.1.md b/src/current/_includes/releases/v20.2/v20.2.1.md
deleted file mode 100644
index cbf2cf016a8..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.1.md
+++ /dev/null
@@ -1,23 +0,0 @@
-## v20.2.1
-
-Release Date: November 20, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a63162.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-1-bug-fixes">Bug fixes</h3>
-
-- Fixed a crash, introduced in the v20.2 series, caused by range scans over virtual tables with virtual indexes. [#56459][#56459]
-- Fixed a bug the occurred when the Pebble storage engine was used with encryption-at-rest that could result in data corruption in some fairly rare cases after a table drop, table truncate, or replica deletion. [#56678][#56678]
-
-<h3 id="v20-2-1-contributors">Contributors</h3>
-
-This release includes 3 merged PRs by 3 authors.
-
-[#56459]: https://github.com/cockroachdb/cockroach/pull/56459
-[#56678]: https://github.com/cockroachdb/cockroach/pull/56678
diff --git a/src/current/_includes/releases/v20.2/v20.2.10.md b/src/current/_includes/releases/v20.2/v20.2.10.md
deleted file mode 100644
index 5cd77e3ec2f..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.10.md
+++ /dev/null
@@ -1,48 +0,0 @@
-## v20.2.10
-
-Release Date: May 17, 2021
-
-<h3 id="v20-2-10-sql-language-changes">SQL language changes</h3>
-
-- Added the `INCLUDE_DEPRECATED_INTERLEAVES` option to [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup). In v21.1, this option must be specified when backing up a cluster, database, or table that includes [interleaved data](https://www.cockroachlabs.com/docs/v20.2/interleave-in-parent). [#64688][#64688]
-- Added the `chunk_size` option to [`EXPORT CSV`](https://www.cockroachlabs.com/docs/v20.2/export) to control the target CSV file size. [#65009][#65009]
-
-<h3 id="v20-2-10-command-line-changes">Command-line changes</h3>
-
-- The `--help` text for [`--max-disk-temp-storage`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start#flags) now properly reports the default value. [#55055][#55055]
-
-<h3 id="v20-2-10-db-console-changes">DB Console changes</h3>
-
-- Implemented a new library for line graphs that renders metrics more efficiently. Customers with large clusters (above ~30 nodes) can now load and interact with the [metrics dashboards](https://www.cockroachlabs.com/docs/v20.2/ui-overview-dashboard) much faster than before. [#64493][#64493]
-- A legend is now shown underneath a timeseries graph if more than 10 series are being displayed. [#64493][#64493]
-
-<h3 id="v20-2-10-bug-fixes">Bug fixes</h3>
-
-- Fixed a race condition where read-write requests during replica removal (for example, during range merges or rebalancing) could be evaluated on the removed replica. These cases would not result in data being written to persistent storage, but could result in errors that should not have been returned. [#64601][#64601]
-- Fixed a stack overflow that could happen in some corner cases involving partial indexes with predicates containing `(x IS NOT NULL)`. [#64739][#64739]
-- Building no longer depends on internet access. Only vendored modules are used. This bug was introduced in v20.2.0. [#64507][#64507]
-- Limit scans are no longer counted as full scans. [#64852][#64852]
-- Providing a constant value as an [`ORDER BY`](https://www.cockroachlabs.com/docs/v20.2/order-by) value in an ordered set aggregate, such as `percentile_dist` or `percentile_cont`, no longer errors. This bug has been present since order set aggregates were added in v20.2.0. [#64903][#64903]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-10-contributors">Contributors</h3>
-
-This release includes 13 merged PRs by 14 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Michał Łazowik (first-time contributor)
-
-</div>
-
-[#55055]: https://github.com/cockroachdb/cockroach/pull/55055
-[#64493]: https://github.com/cockroachdb/cockroach/pull/64493
-[#64507]: https://github.com/cockroachdb/cockroach/pull/64507
-[#64601]: https://github.com/cockroachdb/cockroach/pull/64601
-[#64688]: https://github.com/cockroachdb/cockroach/pull/64688
-[#64739]: https://github.com/cockroachdb/cockroach/pull/64739
-[#64751]: https://github.com/cockroachdb/cockroach/pull/64751
-[#64852]: https://github.com/cockroachdb/cockroach/pull/64852
-[#64903]: https://github.com/cockroachdb/cockroach/pull/64903
-[#65009]: https://github.com/cockroachdb/cockroach/pull/65009
-[861aba7b4]: https://github.com/cockroachdb/cockroach/commit/861aba7b4
diff --git a/src/current/_includes/releases/v20.2/v20.2.11.md b/src/current/_includes/releases/v20.2/v20.2.11.md
deleted file mode 100644
index 7f54788d040..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.11.md
+++ /dev/null
@@ -1,96 +0,0 @@
-## v20.2.11
-
-Release Date: June 14, 2021
-
-<h3 id="v20-2-11-sql-language-changes">SQL language changes</h3>
-
-- Floating point infinity values are now formatted as `Infinity` (or `-Infinity` if negative). This is for compatibility with PostgreSQL [#65105][#65105] {% comment %}doc{% endcomment %}
-- [`INSERT INTO ... ON CONFLICT ... DO UPDATE SET`](https://www.cockroachlabs.com/docs/v20.2/insert#on-conflict-clause) statements without predicates now acquire locks using the `FOR UPDATE` locking mode during their initial row scan, which improves performance for contended workloads. This behavior is configurable using the [`enable_implicit_select_for_update` session variable](https://www.cockroachlabs.com/docs/v20.2/set-vars) and the [`sql.defaults.implicit_select_for_update.enabled` cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) [#65364][#65364] {% comment %}doc{% endcomment %}
-- The [`ST_GeomFromGeoJSON(string)`](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#spatial-functions) spatial function is now marked as the preferred overload, meaning it will resolve correctly in more contexts. [#65441][#65441] {% comment %}doc{% endcomment %}
-- The cancellation behavior for [DistSQL](https://www.cockroachlabs.com/docs/v20.2/architecture/sql-layer) flows has been improved. [#65046][#65046]
-
-<h3 id="v20-2-11-db-console-changes">DB Console changes</h3>
-
-- Fixed a bug where empty series would show up in metrics graphs and legends, and when data was incorrectly attributed to the wrong nodes on graphs for clusters with decommissioned nodes. [#66034][#66034]
-- Removed shading on line graphs, which improves legibility when viewing more than a few series on the same plot. [#66034][#66034]
-- Drag to zoom on metrics graphs now supports time ranges under 10 minutes. [#66034][#66034] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-11-bug-fixes">Bug fixes</h3>
-
-- [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) no longer resolves intents one by one. This eliminates the need to run a high-priority query to clean up intents to unblock `BACKUP` in case of intent buildup. [#64931][#64931]
-- Fixed a bug that could cause backups to be slower. `LockTableWaiter` now checks the finalized transaction cache before pushing transactions to avoid duplicating work. [#64999][#64999]
-- Fixed a bug where interval math on a [`TIMESTAMPTZ`](https://www.cockroachlabs.com/docs/v20.2/timestamp) on a DST boundary would incorrectly add or subtract an extra hour. [#65097][#65097]
-- Fixed a bug where `date_trunc` on a [`TIME`](https://www.cockroachlabs.com/docs/v20.2/time) value on a DST boundary could switch timezones and produce the incorrect result. [#65097][#65097]
-- Fixed a bug causing the [`ZONECONFIG` privilege](https://www.cockroachlabs.com/docs/v20.2/authorization#privileges) on tables and databases to be incorrectly interpreted as `USAGE`, which could corrupt a table and/or database because `USAGE` is an invalid privilege for tables and databases. Also fixed the case when the `ZONECONFIG` privilege would be incorrectly restored as `USAGE` for tables and databases created and backed up in v20.1 and then restored through a full cluster `RESTORE` in v20.2 or later. [#65159][#65159]
-- Fixed a bug which could cause a panic when running an `EXECUTE` of a previously prepared statement with a `REGCLASS` or `REGTYPE` parameter or a [user-defined type](https://www.cockroachlabs.com/docs/v20.2/enum) argument after running [`BEGIN AS OF SYSTEM TIME`](https://www.cockroachlabs.com/docs/v20.2/as-of-system-time) with an invalid timestamp. [#65150][#65151]
-- Fixed a bug which could cause a panic when issuing a query referencing a [user-defined type](https://www.cockroachlabs.com/docs/v20.2/enum) as a placeholder. [#65151][#65151]
-- Fixed a bug introduced in v20.2 that caused rows to be incorrectly de-duplicated from a scan with a non-unique index. [#65288][#65288]
-- Fixed a bug causing `revision_history` cluster [backups](https://www.cockroachlabs.com/docs/v20.2/backup) to not include dropped databases. This means that, previously, dropped databases could not be restored from backups that were taken after the database was dropped. [#65317][#65317]
-- Fixed a bug where empty [zone configurations](https://www.cockroachlabs.com/docs/v20.2/configure-zone) get created for certain indexes during [`ALTER PRIMARY KEY`](https://www.cockroachlabs.com/docs/v20.2/alter-primary-key). [#65175][#65175]
-- Fixed a bug causing [`SHOW CREATE TABLE`](https://www.cockroachlabs.com/docs/v20.2/show-create) output to not display the [zone configurations](https://www.cockroachlabs.com/docs/v20.2/configure-zone) of a table or index if there were no partitions, even if there were zone configurations on the index or table. [#65175][#65175]
-- Fixed a bug where [`ALTER DATABASE ... SET OWNER ...`](https://www.cockroachlabs.com/docs/v20.2/alter-database) did not work if the database name was a keyword. [#65367][#65367]
-- Fixed a bug where [`SHOW CREATE TABLE`](https://www.cockroachlabs.com/docs/v20.2/show-create) would show the [zone configurations](https://www.cockroachlabs.com/docs/v20.2/configure-zone) of a table with the same name from a different schema. [#65369][#65369]
-- Previously, CockroachDB would crash when attempting to create a table using [`CREATE TABLE ... AS`](https://www.cockroachlabs.com/docs/v20.2/create-table-as) syntax where `AS` selects from `crdb_internal.node_statement_statistics`, `crdb_internal.node_transaction_statistics`, or `crdb_internal.node_txn_stats` virtual tables. [#65544][#65544]
-- Fixed a bug where binary [`TIMETZ`](https://www.cockroachlabs.com/docs/v20.2/time) values were not being decoded correctly when sent as a parameter in the wire protocol. [#65579][#65579]
-- A certain percentage of cases in which a node could have served a follower read were not handled correctly, resulting in the node routing the request to another nearby node for no reason. This has been fixed. [#65470][#65470]
-- Fixed a race condition during transaction cleanup that could leave old transaction records behind until MVCC garbage collection. [#65384][#65384]
-- Improved transaction cleanup for disconnected clients to reduce intent buildup. [#65384][#65384]
-- Fixed a bug where the [storage layer](https://www.cockroachlabs.com/docs/v20.2/architecture/storage-layer) would under some rare write-heavy workloads start off by writing `SSTable` files that were too small for CockroachDB to manage effectively. The storage layer now creates fewer, larger files under those workloads, in line with expected behavior. [#65481][#65481]
-- [Scheduled backups](https://www.cockroachlabs.com/docs/v20.2/manage-a-backup-schedule) with [interleaved tables](https://www.cockroachlabs.com/docs/v20.2/interleave-in-parent) can now be created with the `include_deprecated_interleaves` option. [#65730][#65730]
-- Calling [`get_bit` or `set_bit`](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#string-and-byte-functions) on a byte array argument now goes to the correct index of the underlying bitstring, which matches the Postgres behavior. [#65787][#65787]
-- Previously, [`ALTER DATABASE ... CONVERT TO SCHEMA`](https://www.cockroachlabs.com/docs/v20.2/alter-database) could potentially leave the schema with invalid privileges thus causing the privilege descriptor to be invalid. [#65813][#65813]
-- Fixed a scenario in which a rapid sequence of splits could trigger a storm of Raft snapshots. This would be accompanied by log messages of the form `would have dropped incoming MsgApp, but allowing due to ...`, which tended to occur as part of [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore)/[`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import) operations. [#65500][#65500]
-- Previously, a schema's privilege descriptor could become corrupted upon executing [`ALTER DATABASE ... CONVERT TO SCHEMA`](https://www.cockroachlabs.com/docs/v20.2/alter-database). This is due to privileges that are invalid on a schema being copied over to the schema, rendering the schema unusable due to invalid privileges. [#65999][#65999]
-- Previously, [`TRUNCATE`](https://www.cockroachlabs.com/docs/v20.2/truncate) transactionally scanned the meta range to find ranges to unsplit, creating contention with `TRUNCATE`'s new behavior of preserving splits. [#65942][#65942]
-- Fixed the error classification for duplicate index names where the later index was a [`UNIQUE`](https://www.cockroachlabs.com/docs/v20.2/unique) index. [#64002][#64002]
-- Fixed the error classification for [`ALTER TABLE ... ADD CONSTRAINT ... UNIQUE`](https://www.cockroachlabs.com/docs/v20.2/alter-table) with the same name as an existing index. [#64002][#64002]
-- Fixed a bug in [`SHOW RANGES`](https://www.cockroachlabs.com/docs/v20.2/show-ranges) that misattributed localities to nodes when using multiple stores. [#66038][#66038]
-- Fixed a bug where [incremental backups](https://www.cockroachlabs.com/docs/v20.2/take-full-and-incremental-backups) with [`revision_history`](https://www.cockroachlabs.com/docs/v20.2/backup#options) would sometimes fail if a view was altered between incremental backups. [#66072][#66072]
-
-<h3 id="v20-2-11-performance-improvements">Performance improvements</h3>
-
-- Fixed an issue in the optimizer that prevented spatial predicates of the form `(column && value) = true` from being index-accelerated. These queries can now use a [spatial index](https://www.cockroachlabs.com/docs/v20.2/spatial-indexes), if one is available. [#65988][#65988]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-11-contributors">Contributors</h3>
-
-This release includes 55 merged PRs by 32 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Max Neverov
-- Mohammad Aziz (first-time contributor)
-
-</div>
-
-[#64002]: https://github.com/cockroachdb/cockroach/pull/64002
-[#64931]: https://github.com/cockroachdb/cockroach/pull/64931
-[#64999]: https://github.com/cockroachdb/cockroach/pull/64999
-[#65046]: https://github.com/cockroachdb/cockroach/pull/65046
-[#65097]: https://github.com/cockroachdb/cockroach/pull/65097
-[#65105]: https://github.com/cockroachdb/cockroach/pull/65105
-[#65151]: https://github.com/cockroachdb/cockroach/pull/65151
-[#65159]: https://github.com/cockroachdb/cockroach/pull/65159
-[#65175]: https://github.com/cockroachdb/cockroach/pull/65175
-[#65288]: https://github.com/cockroachdb/cockroach/pull/65288
-[#65317]: https://github.com/cockroachdb/cockroach/pull/65317
-[#65364]: https://github.com/cockroachdb/cockroach/pull/65364
-[#65367]: https://github.com/cockroachdb/cockroach/pull/65367
-[#65369]: https://github.com/cockroachdb/cockroach/pull/65369
-[#65384]: https://github.com/cockroachdb/cockroach/pull/65384
-[#65441]: https://github.com/cockroachdb/cockroach/pull/65441
-[#65470]: https://github.com/cockroachdb/cockroach/pull/65470
-[#65481]: https://github.com/cockroachdb/cockroach/pull/65481
-[#65500]: https://github.com/cockroachdb/cockroach/pull/65500
-[#65544]: https://github.com/cockroachdb/cockroach/pull/65544
-[#65579]: https://github.com/cockroachdb/cockroach/pull/65579
-[#65730]: https://github.com/cockroachdb/cockroach/pull/65730
-[#65787]: https://github.com/cockroachdb/cockroach/pull/65787
-[#65813]: https://github.com/cockroachdb/cockroach/pull/65813
-[#65942]: https://github.com/cockroachdb/cockroach/pull/65942
-[#65988]: https://github.com/cockroachdb/cockroach/pull/65988
-[#65999]: https://github.com/cockroachdb/cockroach/pull/65999
-[#66021]: https://github.com/cockroachdb/cockroach/pull/66021
-[#66034]: https://github.com/cockroachdb/cockroach/pull/66034
-[#66038]: https://github.com/cockroachdb/cockroach/pull/66038
-[#66072]: https://github.com/cockroachdb/cockroach/pull/66072
diff --git a/src/current/_includes/releases/v20.2/v20.2.12.md b/src/current/_includes/releases/v20.2/v20.2.12.md
deleted file mode 100644
index 8f9f192cd26..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.12.md
+++ /dev/null
@@ -1,55 +0,0 @@
-## v20.2.12
-
-Release Date: June 28, 2021
-
-This page lists additions and changes in v20.2.12 since version v20.2.11.
-
-<h3 id="v20-2-12-docker-image">Docker image</h3>
-
-{% include copy-clipboard.html %}
-~~~shell
-$ docker pull cockroachdb/cockroach:v20.2.12
-~~~
-
-<h3 id="v20-2-12-enterprise-edition-changes">Enterprise edition changes</h3>
-
-- Added new [`CHANGEFEED` options](https://www.cockroachlabs.com/docs/v20.2/create-changefeed#options) that give you more control over topic naming: The `full_table_name` option lets you use a fully-qualified table name in topics, subjects, schemas, and record output instead of the default table name, and can prevent unintended behavior when the same table name is present in multiple databases. The `avro_schema_prefix` option lets you use a fully-qualified schema name for a table instead of the default table name, and makes it possible for multiple databases or clusters to share the same schema registry when the same table name is present in multiple databases. [#66091][#66091]
-- Changefeeds with custom Kafka client configurations (using the `kafka_sink_config` object) that could lead to long delays in flushing messages will now produce an error. [#66316][#66316]
-- The `kafka_sink_config` object now supports a `version` configuration item to specify Kafka server versions. This is likely only necessary for old (Kafka 0.11/Confluent 3.3 or earlier) Kafka servers. Additionally, settings not specified in `kafka_sink_config` now retain their default values. [#66316][#66316]
-
-<h3 id="v20-2-12-sql-language-changes">SQL language changes</h3>
-
-- Creating `STORED` [computed columns](https://www.cockroachlabs.com/docs/v20.2/computed-columns) with expressions that reference [foreign key](https://www.cockroachlabs.com/docs/v20.2/foreign-key) columns is now allowed. [#66169][#66169]
-
-<h3 id="v20-2-12-operational-changes">Operational changes</h3>
-
-- [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) now puts backup data files in a `data` sub-directory of the `BACKUP` path instead of directly in the backup path. [#66164][#66164]
-
-<h3 id="v20-2-12-bug-fixes">Bug fixes</h3>
-
-- CockroachDB now prevents intra-query leaks during disk spilling that could cause the database to run out of memory, especially during disk spilling operations on tables with wide rows. [#66170][#66170]
-- Queries now use up to 1MB less actual system memory per scan, lookup join, index join, zigzag join, or inverted join in their query plans. This will result in improved memory performance for workloads with concurrent OLAP-style queries. [#66170][#66170]
-- `BACKUP`s no longer risk the possibility of blocking conflicting writes while being rate limited by the `kv.bulk_io_write.concurrent_export_requests` concurrency limit. [#66409][#66409]
-- `BACKUP` and other operations can now reuse a previously created S3 client session when operating on the same bucket, which can avoid `NoCredentialProviders` errors on EC2 when iterating with large incremental backups. [#66260][#66260]
-- Fixed a crash when performing a cluster [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) with revision history of a cluster upgraded from 20.1 to 20.2 to 21.1 which contains tables that were truncated by 20.1. [#66638][#66638]
-- Fixed the style of the DB Console password field on Safari. [#66135][#66135]
-
-<h3 id="v20-2-12-performance-improvements">Performance improvements</h3>
-
-- The `COCKROACHDB_REGISTRY` file is no longer rewritten whenever a new unencrypted file is created. [#66424][#66424]
-
-<h3 id="v20-2-12-contributors">Contributors</h3>
-
-This release includes 19 merged PRs by 17 authors.
-
-[#66091]: https://github.com/cockroachdb/cockroach/pull/66091
-[#66135]: https://github.com/cockroachdb/cockroach/pull/66135
-[#66164]: https://github.com/cockroachdb/cockroach/pull/66164
-[#66169]: https://github.com/cockroachdb/cockroach/pull/66169
-[#66170]: https://github.com/cockroachdb/cockroach/pull/66170
-[#66260]: https://github.com/cockroachdb/cockroach/pull/66260
-[#66316]: https://github.com/cockroachdb/cockroach/pull/66316
-[#66409]: https://github.com/cockroachdb/cockroach/pull/66409
-[#66424]: https://github.com/cockroachdb/cockroach/pull/66424
-[#66638]: https://github.com/cockroachdb/cockroach/pull/66638
-[#66641]: https://github.com/cockroachdb/cockroach/pull/66641
diff --git a/src/current/_includes/releases/v20.2/v20.2.13.md b/src/current/_includes/releases/v20.2/v20.2.13.md
deleted file mode 100644
index 1ad131fa057..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.13.md
+++ /dev/null
@@ -1,54 +0,0 @@
-## v20.2.13
-
-Release Date: July 12, 2021
-
-<h3 id="v20-2-13-operational-changes">Operational changes</h3>
-
-- Added [logs](https://www.cockroachlabs.com/docs/v20.2/debug-and-error-logs) for important events during the [server draining/shutdown process](https://www.cockroachlabs.com/docs/v20.2/remove-nodes#overview). [#66882][#66882]  Specifically, the following:
-    - Log when the server closes an existing connection while draining
-    - Log when the server rejects a new connection while draining
-    - Log when the server cancels in-flight queries after waiting for the duration of the `server.shutdown.query_wait` [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) to elapse while draining.
-
-<h3 id="v20-2-13-db-console-changes">DB Console changes</h3>
-
-- Fixed an issue with displaying more than 100 hours of remaining time on the [Jobs page](https://www.cockroachlabs.com/docs/v20.2/ui-jobs-page). [#66704][#66704]
-- Removed width styling on the multi bar. [#66737][#66737] cockroachdb/cockroach#66737
-- Fixed the [Custom Chart debug page](https://www.cockroachlabs.com/docs/v20.2/ui-custom-chart-debug-page) layout. [#66623][#66623]
-- Added a drag-to-select timescale feature to the [Custom Chart debug page](https://www.cockroachlabs.com/docs/v20.2/ui-custom-chart-debug-page). [#66623][#66623]
-- Fixed a styling issue with a filter component on [Cloud Console](https://www.cockroachlabs.com/docs/cockroachcloud/managing-access). [#66566][#66566]
-- Removed an unnecessary call to `console log`. [#66566][#66566] cockroachdb/cockroach#66566
-- Bumped the `cluster-ui` version to v20.2.1. [#66566][#66566]
-- Fixed a bug where [metrics pages in the DB Console](https://www.cockroachlabs.com/docs/v20.2/ui-overview-dashboard) would lose their scroll position on chart data updates. [#67088][#67088]
-
-<h3 id="v20-2-13-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug which prevented the [optimizer](https://www.cockroachlabs.com/docs/v21.1/cost-based-optimizer) from producing plans with [partial indexes](https://www.cockroachlabs.com/docs/v21.1/partial-indexes) when executing some prepared statements that contained placeholders, stable functions, or casts. This bug was present since partial indexes were added in v20.2.0. [#66641][#66641]
-- Fixed a panic that could occur in the [optimizer](https://www.cockroachlabs.com/docs/v21.1/cost-based-optimizer) when executing a prepared plan with placeholders. This could happen when one of the tables used by the query had [computed columns](https://www.cockroachlabs.com/docs/v21.1/computed-columns) or a [partial index](https://www.cockroachlabs.com/docs/v21.1/partial-indexes). [#66832][#66832]
-- Fixed a bug that caused graceful drain to call `time.sleep` multiple times, which cut into the time needed for range [lease transfers](https://www.cockroachlabs.com/docs/v20.2/architecture/replication-layer#leases). [#66852][#66852]
-- CockroachDB now allows a node with [lease](https://www.cockroachlabs.com/docs/v20.2/architecture/replication-layer#leases) preferences to drain gracefully. [#66714][#66714]
-- CockroachDB now avoids interacting with [decommissioned nodes](https://www.cockroachlabs.com/docs/v20.2/remove-nodes) during [DistSQL](https://www.cockroachlabs.com/docs/v20.2/architecture/sql-layer#distsql) planning and consistency checking. [#66951][#66951]
-- [Changefeeds](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) no longer interact poorly with large, abandoned [transactions](https://www.cockroachlabs.com/docs/v20.2/transactions). It was previously possible for this combination to result in a cascade of work during transaction cleanup that could starve foreground traffic. [#66814][#66814]
-- [Changefeeds](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) now properly invalidate cached range descriptors and retry when encountering [decommissioned nodes](https://www.cockroachlabs.com/docs/v20.2/remove-nodes). [#67024][#67024]
-
-<h3 id="v20-2-13-performance-improvements">Performance improvements</h3>
-
-- Added the ability to continue generating histograms when [table statistics](https://www.cockroachlabs.com/docs/v20.2/create-statistics) collection reaches memory limits, instead of disabling histogram generation. [#67059][#67059]
-
-<h3 id="v20-2-13-contributors">Contributors</h3>
-
-This release includes 19 merged PRs by 16 authors.
-
-[#66566]: https://github.com/cockroachdb/cockroach/pull/66566
-[#66623]: https://github.com/cockroachdb/cockroach/pull/66623
-[#66641]: https://github.com/cockroachdb/cockroach/pull/66641
-[#66704]: https://github.com/cockroachdb/cockroach/pull/66704
-[#66714]: https://github.com/cockroachdb/cockroach/pull/66714
-[#66737]: https://github.com/cockroachdb/cockroach/pull/66737
-[#66814]: https://github.com/cockroachdb/cockroach/pull/66814
-[#66832]: https://github.com/cockroachdb/cockroach/pull/66832
-[#66852]: https://github.com/cockroachdb/cockroach/pull/66852
-[#66882]: https://github.com/cockroachdb/cockroach/pull/66882
-[#66951]: https://github.com/cockroachdb/cockroach/pull/66951
-[#67024]: https://github.com/cockroachdb/cockroach/pull/67024
-[#67059]: https://github.com/cockroachdb/cockroach/pull/67059
-[#67088]: https://github.com/cockroachdb/cockroach/pull/67088
diff --git a/src/current/_includes/releases/v20.2/v20.2.14.md b/src/current/_includes/releases/v20.2/v20.2.14.md
deleted file mode 100644
index 0f0fc765e75..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.14.md
+++ /dev/null
@@ -1,80 +0,0 @@
-## v20.2.14
-
-Release Date: August 16, 2021
-
-<h3 id="v20-2-14-security-updates">Security updates</h3>
-
-- The `cert-principal-map` flag passed to [`cockroach` commands](https://www.cockroachlabs.com/docs/v20.2/cockroach-commands) now allows the certificate principal name to contain colons. [#67811][#67811]
-- The [node status retrieval endpoints over HTTP](https://www.cockroachlabs.com/docs/v20.2/monitoring-and-alerting) [`/_status/nodes`, `/_status/nodes/<N>` and the [DB Console](https://www.cockroachlabs.com/docs/v20.2/ui-overview) `/#/reports/nodes`) now require the [`admin` role](https://www.cockroachlabs.com/docs/v20.2/authorization) from the requesting user. This ensures that operational details such as network addresses and command-line flags do not leak to unprivileged users. This change means that the [Overview page](https://www.cockroachlabs.com/docs/v20.2/ui-overview) and [Hardware dashboard](https://www.cockroachlabs.com/docs/v20.2/ui-hardware-dashboard) of the DB Console will not show all details for non-`admin` users. [#67069][#67069]
-
-<h3 id="v20-2-14-enterprise-edition-changes">Enterprise edition changes</h3>
-
-- [Incremental backups](https://www.cockroachlabs.com/docs/v20.2/take-full-and-incremental-backups) to a cloud storage location that already contains large existing backups now find their derived destination without listing as many remote files. [#67289][#67289]
-
-<h3 id="v20-2-14-sql-language-changes">SQL language changes</h3>
-
-- Added a new [`EXPLAIN` flag](https://www.cockroachlabs.com/docs/v20.2/explain), `MEMO`, to be used with `EXPLAIN (OPT)`. When the `MEMO` flag is passed, a representation of the optimizer memo will be printed along with the best plan. The `MEMO` flag can be used in combination with other flags such as `CATALOG` and `VERBOSE`. For example, `EXPLAIN (OPT, MEMO, VERBOSE)` will print the memo along with verbose output for the best plan. [#67778][#67778]
-
-<h3 id="v20-2-14-db-console-changes">DB Console changes</h3>
-
-- The DB Console will now redirect the user to the originally requested page after user login. [#67859][#67859]
-
-<h3 id="v20-2-14-bug-fixes">Bug fixes</h3>
-
-- Fixed a statement buffer memory leak when using suspended portals. [#67370][#67370]
-- Correlated subqueries that couldn't be decorrelated and that have their own subqueries are now executed correctly when supported. Note that this is a very rare edge case. [#67571][#67571]
-- Fixed a very rare unexpected error from the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) ("index out of bounds") when evaluating the `CASE` operator. [#67785][#67785]
-- Catching up [Raft](https://www.cockroachlabs.com/docs/v20.2/architecture/replication-layer#raft) followers on the Raft log is now more efficient in the presence of many large Raft log entries. This helps avoid situations where Raft leaders struggle to retain leadership while catching up their followers. [#67126][#67126]
-- Fixed a rare bug when a lease change occurred during a range merge. This bug allowed [`AS OF SYSTEM TIME`](https://www.cockroachlabs.com/docs/v20.2/as-of-system-time) queries to serve inconsistent results. [#65823][#65823]
-- The [v20.2 SQL shell](https://www.cockroachlabs.com/docs/v20.2/cockroach-sql) now properly reports detailed execution timings (using the client-side configuration setting `verbose_times`) when run against a v21.1+ server. [#67853][#67853]
-- Fixed a deadlock that could occur when many replicas were rapidly queued for removal. [#65861][#65861]
-- Fixed two bugs which affected [geospatial queries](https://www.cockroachlabs.com/docs/v20.2/spatial-features) with the [`st_distance` function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#spatial-functions). The first caused errors for filters of the form `st_distance(g1, g2, use_spheroid) = 0`. The second incorrectly transformed filters of the form `st_distance(g1, g2) = 0` when `g1` and `g2` are geographies to `st_instersects(g1, g2)`. This is not a valid transformation because `st_distance` makes spheroid-based calculations by default while `st_intersects` only makes sphere-based calculations. [#67412][#67412]
-- Fixed an issue with statistics estimation in the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) that could have caused it to over-estimate the number of rows for some expressions and thus choose a sub-optimal plan. This issue could happen when multi-column statistics were used in combination with histograms, the query contained a predicate on two or more columns where the columns were highly correlated, and the selected values were very common according to the histograms. [#68012][#68012]
-- Fixed an issue where CockroachDB could encounter an internal error or crash when performing a cast of a `NULL` [`JSON` value](https://www.cockroachlabs.com/docs/v20.2/jsonb) to [Geography or Geometry types](https://www.cockroachlabs.com/docs/v20.2/spatial-features). [#67903][#67903]
-- [`INSERT`](https://www.cockroachlabs.com/docs/v20.2/insert) and [`UPDATE`](https://www.cockroachlabs.com/docs/v20.2/update) statements which operate on larger rows are now split into batches using the `sql.mutations.mutation_batch_byte_size` setting. [#67963][#67963]
-- Fixed a rare bug that could result in a crash while creating a [`debug.zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip). The bug would only occur if a `debug.zip` was captured during a period of rapid lease movement. [#67727][#67727]
-- Fixed a rare crash when a [backup](https://www.cockroachlabs.com/docs/v20.2/take-full-and-incremental-backups) writing to Google Cloud Storage failed while writing a file. [#68258][#68258]
-- Fixed missing foreign key checks in some cases when there are multiple checks and the inserted data contains a `NULL` for one of the checks. [#68521][#68521]
-- Fixed a bug that prevented upreplication of an underreplicated range while in a joint quorum configuration. [#68576][#68576]
-
-<h3 id="v20-2-14-performance-improvements">Performance improvements</h3>
-
-- Improved the selectivity estimate for array containing predicates (for example, `arr @> ARRAY[1]`) in the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer). This improves the optimizer's cardinality estimation for queries containing these predicates, and may result in better query plans in some cases. [#67530][#67530]
-- Updated the cost model in the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) to make index joins more expensive and better reflect the reality of their cost. As a result, the optimizer will choose index joins less frequently, generally resulting in more efficient query plans. [#67530][#67530]
-- Improved the performance of the [`pg_table_is_visible` built-in function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators). [#68113][#68113]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-14-contributors">Contributors</h3>
-
-This release includes 35 merged PRs by 22 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- joesankey (first-time contributor)
-
-</div>
-
-[#65823]: https://github.com/cockroachdb/cockroach/pull/65823
-[#65861]: https://github.com/cockroachdb/cockroach/pull/65861
-[#67069]: https://github.com/cockroachdb/cockroach/pull/67069
-[#67126]: https://github.com/cockroachdb/cockroach/pull/67126
-[#67289]: https://github.com/cockroachdb/cockroach/pull/67289
-[#67357]: https://github.com/cockroachdb/cockroach/pull/67357
-[#67370]: https://github.com/cockroachdb/cockroach/pull/67370
-[#67412]: https://github.com/cockroachdb/cockroach/pull/67412
-[#67530]: https://github.com/cockroachdb/cockroach/pull/67530
-[#67571]: https://github.com/cockroachdb/cockroach/pull/67571
-[#67727]: https://github.com/cockroachdb/cockroach/pull/67727
-[#67778]: https://github.com/cockroachdb/cockroach/pull/67778
-[#67785]: https://github.com/cockroachdb/cockroach/pull/67785
-[#67811]: https://github.com/cockroachdb/cockroach/pull/67811
-[#67853]: https://github.com/cockroachdb/cockroach/pull/67853
-[#67859]: https://github.com/cockroachdb/cockroach/pull/67859
-[#67903]: https://github.com/cockroachdb/cockroach/pull/67903
-[#67963]: https://github.com/cockroachdb/cockroach/pull/67963
-[#68012]: https://github.com/cockroachdb/cockroach/pull/68012
-[#68113]: https://github.com/cockroachdb/cockroach/pull/68113
-[#68258]: https://github.com/cockroachdb/cockroach/pull/68258
-[#68521]: https://github.com/cockroachdb/cockroach/pull/68521
-[#68576]: https://github.com/cockroachdb/cockroach/pull/68576
-[97cfe05d6]: https://github.com/cockroachdb/cockroach/commit/97cfe05d6
diff --git a/src/current/_includes/releases/v20.2/v20.2.15.md b/src/current/_includes/releases/v20.2/v20.2.15.md
deleted file mode 100644
index 2f5efc6705a..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.15.md
+++ /dev/null
@@ -1,26 +0,0 @@
-## v20.2.15
-
-Release Date: August 23, 2021
-
-<h3 id="v20-2-15-enterprise-edition-changes">Enterprise edition changes</h3>
-
-- The `kafka_sink_config` [changefeed option](https://www.cockroachlabs.com/docs/v20.2/create-changefeed) can now include `RequiredAcks`. [#69016][#69016]
-
-<h3 id="v20-2-15-db-console-changes">DB Console changes</h3>
-
-- Fixed tooltip behavior on the [Sessions](https://www.cockroachlabs.com/docs/v20.2/ui-sessions-page), [Statements](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page), and [Transactions](https://www.cockroachlabs.com/docs/v20.2/ui-transactions-page) pages. [#68477][#68477]
-
-<h3 id="v20-2-15-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug that caused incorrect query results when querying tables with multiple column families and unique secondary indexes. The bug only occurred if 1) [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) was enabled for the query, 2) the query scanned a [unique secondary index](https://www.cockroachlabs.com/docs/v20.2/indexes) that contained columns from more than one column family, and 3) the rows fetched by the query contained `NULL` values for some of the indexed columns. This bug was present since version v20.1. [#68238][#68238]
-- Fixed a bug where CockroachDB could incorrectly evaluate [`LIKE` expressions](https://www.cockroachlabs.com/docs/v20.2/scalar-expressions#string-pattern-matching) when the pattern contained the escape characters `\` if the expressions were executed via the [vectorized execution](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). [#68354][#68354]
-
-
-<h3 id="v20-2-15-contributors">Contributors</h3>
-
-This release includes 5 merged PRs by 5 authors.
-
-[#68238]: https://github.com/cockroachdb/cockroach/pull/68238
-[#68354]: https://github.com/cockroachdb/cockroach/pull/68354
-[#68477]: https://github.com/cockroachdb/cockroach/pull/68477
-[#69016]: https://github.com/cockroachdb/cockroach/pull/69016
diff --git a/src/current/_includes/releases/v20.2/v20.2.16.md b/src/current/_includes/releases/v20.2/v20.2.16.md
deleted file mode 100644
index 88cfae607f4..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.16.md
+++ /dev/null
@@ -1,30 +0,0 @@
-## v20.2.16
-
-Release Date: September 13, 2021
-
-<h3 id="v20-2-16-db-console-changes">DB Console changes</h3>
-
-- Added a Customer Effort Score (CES) survey link component to support being able to get client feedback. [#68516][#68516]
-
-<h3 id="v20-2-16-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug causing [changefeeds](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) to sometimes get stuck. [#68009][#68009]
-- Fixed an error in which cascaded [drops of views](https://www.cockroachlabs.com/docs/v20.2/drop-view) could incorrectly run into `table ... is being dropped` errors. [#68617][#68617]
-- Fixed an oversight in the data generator for TPC-H which was causing a smaller number of distinct values to be generated for `p_type` and `p_container` in the part table than the spec calls for. [#68709][#68709]
-- Fixed a bug in [full cluster restores](https://www.cockroachlabs.com/docs/v20.2/restore#full-cluster) where dropped descriptor revisions would cause the restore to fail. [#69639][#69639]
-- Fixed a bug that created non-partial unique constraints when a user attempted to create a partial unique constraint in [`ALTER TABLE`](https://www.cockroachlabs.com/docs/v20.2/alter-table) statements. [#68747][#68747]
-- Fixed a bug where the `schedules.backup.succeeded` and `schedules.backup.failed` metrics would sometimes not be updated. [#69257][#69257]
-- Fixed a bug that could cause prolonged unavailability due to lease transfer to a replica that may be in need of a Raft snapshot. [#69801][#69801]
-
-<h3 id="v20-2-16-contributors">Contributors</h3>
-
-This release includes 10 merged PRs by 9 authors.
-
-[#68009]: https://github.com/cockroachdb/cockroach/pull/68009
-[#68516]: https://github.com/cockroachdb/cockroach/pull/68516
-[#68617]: https://github.com/cockroachdb/cockroach/pull/68617
-[#68709]: https://github.com/cockroachdb/cockroach/pull/68709
-[#68747]: https://github.com/cockroachdb/cockroach/pull/68747
-[#69257]: https://github.com/cockroachdb/cockroach/pull/69257
-[#69639]: https://github.com/cockroachdb/cockroach/pull/69639
-[#69801]: https://github.com/cockroachdb/cockroach/pull/69801
diff --git a/src/current/_includes/releases/v20.2/v20.2.17.md b/src/current/_includes/releases/v20.2/v20.2.17.md
deleted file mode 100644
index 06c1e6b66ba..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.17.md
+++ /dev/null
@@ -1,34 +0,0 @@
-## v20.2.17
-
-Release Date: October 11, 2021
-
-This page lists additions and changes in v20.2.17 since v20.2.16.
-
-<h3 id="v20-2-17-db-console-changes">DB Console changes</h3>
-
-- Changed references to the [UI console](https://www.cockroachlabs.com/docs/v20.2/ui-overview) from "Admin UI" to "DB Console". [#70882][#70882]
-
-<h3 id="v20-2-17-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug that caused internal errors with [set operations](https://www.cockroachlabs.com/docs/v20.2/selection-queries#set-operations) (e.g., `UNION`) and columns with tuple types that contained constant `NULL` values. This bug was introduced in version 20.2.0. [#69270][#69270]
-- Fixed a bug causing table stats collection issued via an [`EXPLAIN ANALYZE`](https://www.cockroachlabs.com/docs/v20.2/explain-analyze) statement or via a [`CREATE STATISTICS`](https://www.cockroachlabs.com/docs/v20.2/create-statistics) statement to run into a "`flow: memory budget exceeded`" error if the statement was executed without specifying the [`AS OF SYSTEM TIME`](https://www.cockroachlabs.com/docs/v20.2/as-of-system-time) option. [#69590][#69590]
-- Fixed a bug causing a prepared statement to incorrectly reuse the query plan of a different prepared statement that had similar, but not identical type hints. [#67687][#67687]
-- Fixed a bug causing other nodes in the cluster to fail to connect to a restarted node due to their circuit breakers not resetting after a temporary node outage. This would manifest in the logs in messages of the form "`unable to dial nXX: breaker open`", where `XX` is the ID of the restarted node. Note that such errors are expected for nodes that are truly unreachable, and could still occur around the time of the restart, but for no longer than a few seconds. [#70353][#70353]
-- [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) now correctly ignores [dropped databases](https://www.cockroachlabs.com/docs/v20.2/drop-database) that may have been included in cluster backups with revision history. [#69795][#69795]
-- DNS unavailability during range 1 leaseholder loss no longer causes significant latency increases for queries and other operations. [#70133][#70133]
-- Addressed a memory corruption issue in [Pebble](https://www.cockroachlabs.com/docs/v20.2/architecture/storage-layer#pebble) when running with `CGO_ENABLED=0`. [#70995][#70995]
-- Addressed an issue in Pebble where a key can be dropped from an LSM snapshot if the key was deleted by a range tombstone after the snapshot was acquired. [#70995][#70995]
-- Addressed an issue in Pebble where a crash between the creation of the WAL and the MANIFEST could leave the second most WAL with an unclean tail that would be considered corruption on a subsequent Open. [#70995][#70995]
-
-<h3 id="v20-2-17-contributors">Contributors</h3>
-
-This release includes 11 merged PRs by 11 authors.
-
-[#67687]: https://github.com/cockroachdb/cockroach/pull/67687
-[#69270]: https://github.com/cockroachdb/cockroach/pull/69270
-[#69590]: https://github.com/cockroachdb/cockroach/pull/69590
-[#69795]: https://github.com/cockroachdb/cockroach/pull/69795
-[#70133]: https://github.com/cockroachdb/cockroach/pull/70133
-[#70353]: https://github.com/cockroachdb/cockroach/pull/70353
-[#70882]: https://github.com/cockroachdb/cockroach/pull/70882
-[#70995]: https://github.com/cockroachdb/cockroach/pull/70995
diff --git a/src/current/_includes/releases/v20.2/v20.2.18.md b/src/current/_includes/releases/v20.2/v20.2.18.md
deleted file mode 100644
index fd2c73949be..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.18.md
+++ /dev/null
@@ -1,38 +0,0 @@
-## v20.2.18
-
-Release Date: November 8, 2021
-
-This page lists additions and changes in v20.2.18 since v20.2.17.
-
-<h3 id="v20-2-18-db-console-changes">DB Console changes</h3>
-
-- Non-`admin` users of the DB Console have regained the ability to view the [Cluster Overview page](https://www.cockroachlabs.com/docs/v20.2/ui-cluster-overview-page). Users without the [`admin` role](https://www.cockroachlabs.com/docs/v20.2/authorization#admin-role) will still see most data about their nodes, but information such as command-line arguments, environment variables, and IP addresses and DNS names of nodes will be hidden. [#71793][#71793]
-
-<h3 id="v20-2-18-bug-fixes">Bug fixes</h3>
-
-- Fixed an internal error with [joins](https://www.cockroachlabs.com/docs/v20.2/joins) that are both `LATERAL` and `NATURAL`/`USING`. [#70806][#70806]
-- Previously, in v21.1.x and earlier, CockroachDB could incorrectly read the data of a unique secondary index that used to be a primary index created via [`ALTER PRIMARY KEY`](https://www.cockroachlabs.com/docs/v20.2/alter-primary-key). This has been fixed. [#71589][#71589]
-- CockroachDB now avoids dialing nodes in performance-critical code paths, because doing so could cause substantial latency when encountering unresponsive nodes (e.g., when a VM or server was shut down). [#70487][#70487]
-- CockroachDB could crash if network connectivity was impaired. The stack trace (in `cockroach-stderr.log`) would contain `server.(*statusServer).NodesUI` in that case. This has been fixed. [#71793][#71793]
-- Fixed a panic that could occur with invalid GeoJSON input using `ST_GeomFromGeoJSON`/`ST_GeogFromGeoJSON`. [#71307][#71307]
-- Fixed a bug which caused [`ALTER COLUMN TYPE`](https://www.cockroachlabs.com/docs/v20.2/alter-column) statements to fail when they should not have. [#71167][#71167]
-- Connect timeout for grpc connections is now set to 20s to match the pre-v20.2 default value. [#71514][#71514]
-- Fixed a bug which caused incorrect results for some queries that utilized a zig-zag join. The bug could only reproduce on tables with at least two multi-column indexes with nullable columns. The bug was present since v19.2.0. [#71850][#71850]
-
-<h3 id="v20-2-18-performance-improvements">Performance improvements</h3>
-
-- Reduced memory usage slightly during [`ANALYZE`](https://www.cockroachlabs.com/docs/v20.2/create-statistics) or [`CREATE STATISTICS`](https://www.cockroachlabs.com/docs/v20.2/create-statistics) statements. [#71773][#71773]
-
-<h3 id="v20-2-18-contributors">Contributors</h3>
-
-This release includes 16 merged PRs by 16 authors.
-
-[#70487]: https://github.com/cockroachdb/cockroach/pull/70487
-[#70806]: https://github.com/cockroachdb/cockroach/pull/70806
-[#71167]: https://github.com/cockroachdb/cockroach/pull/71167
-[#71307]: https://github.com/cockroachdb/cockroach/pull/71307
-[#71514]: https://github.com/cockroachdb/cockroach/pull/71514
-[#71589]: https://github.com/cockroachdb/cockroach/pull/71589
-[#71773]: https://github.com/cockroachdb/cockroach/pull/71773
-[#71793]: https://github.com/cockroachdb/cockroach/pull/71793
-[#71850]: https://github.com/cockroachdb/cockroach/pull/71850
diff --git a/src/current/_includes/releases/v20.2/v20.2.19.md b/src/current/_includes/releases/v20.2/v20.2.19.md
deleted file mode 100644
index a40450e6c07..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.19.md
+++ /dev/null
@@ -1,24 +0,0 @@
-## v20.2.19
-
-Release Date: February 9, 2022
-
-<h3 id="v20-2-19-bug-fixes">Bug fixes</h3>
-
-- Previously, [schema changes](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes) running during node shutdown could sometimes fail permanently when they should not. This is now fixed. [#71557][#71557]
-- Fixed a bug which prevented the Data Distribution page from working on clusters which were upgraded from 19.2 or earlier. [#72506][#72506]
-- The `CancelSession` endpoint now correctly propagates gateway metadata when forwarding requests. [#75885][#75885]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-19-contributors">Contributors</h3>
-
-This release includes 4 merged PRs by 4 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Jane Xing
-
-</div>
-
-[#71557]: https://github.com/cockroachdb/cockroach/pull/71557
-[#72506]: https://github.com/cockroachdb/cockroach/pull/72506
-[#75885]: https://github.com/cockroachdb/cockroach/pull/75885
diff --git a/src/current/_includes/releases/v20.2/v20.2.2.md b/src/current/_includes/releases/v20.2/v20.2.2.md
deleted file mode 100644
index d07b559ea9b..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.2.md
+++ /dev/null
@@ -1,195 +0,0 @@
-## v20.2.2
-
-Release Date: November 25, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a63162.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-2-security-updates">Security updates</h3>
-
-- CockroachDB no longer reports the use of expired or invalid web auth cookies in the log file by default. [#55298][#55298]
-- Updated the state validation for the OIDC login flow and replaced it with a stateless hash validation of the state parameter with the browser cookie using HMAC. [#56502][#56502]
-
-<h3 id="v20-2-2-general-changes">General changes</h3>
-
-- Added metrics to track [job execution](https://www.cockroachlabs.com/docs/v20.2/show-jobs) for various job types. These metrics include:
-
-| Metric                                       | Description                                                                                                  |
-|----------------------------------------------+--------------------------------------------------------------------------------------------------------------|
-| `jobs.{job_type}.currently_running`          | Number of `{job_type}` jobs currently running in Resume or OnFailOrCancel state                              |
-| `jobs.{job_type}.fail_or_cancel_completed`   | Number of `{job_type}` jobs which successfully completed their failure or cancellation process               |
-| `jobs.{job_type}.fail_or_cancel_failed`      | Number of `{job_type}` jobs which failed with a non-retryable error on their failure or cancellation process |
-| `jobs.{job_type}.fail_or_cancel_retry_error` | Number of `{job_type}` jobs which failed with a retryable error on their failure or cancellation process     |
-| `jobs.{job_type}.resume_completed`           | Number of `{job_type}` jobs which successfully resumed to completion                                         |
-| `jobs.{job_type}.resume_failed`              | Number of `{job_type}` jobs which failed with a non-retryable error                                          |
-| `jobs.{job_type}.resume_retry_error`         | Number of `{job_type}` jobs which failed with a retryable error                                              |
-
-[#55500][#55500]
-
-<h3 id="v20-2-2-enterprise-edition-changes">Enterprise edition changes</h3>
-
-- The `insecure_tls_skip_verify` query string parameter may now be set on [changefeed](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) sinks. This disables client-side validation of responses and should be avoided if possible since it creates [MITM](https://wikipedia.org/wiki/Man-in-the-middle_attack) vulnerabilities unless combined with another method of authentication. [#56338][#56338]
-- Added metrics to track the current number of running [`CHANGEFEED`s](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) and the number of failed changefeed [jobs](https://www.cockroachlabs.com/docs/v20.2/show-jobs). [#56456][#56456]
-
-<h3 id="v20-2-2-sql-language-changes">SQL language changes</h3>
-
-- Updated the `TransactionRetryWithProtoRefreshError` to include a `HINT` field that links to [a web page containing useful information to resolve the error](https://www.cockroachlabs.com/docs/v20.2/transaction-retry-error-reference). [#56049][#56049]
-- Parsing [intervals](https://www.cockroachlabs.com/docs/v20.2/interval) with fractional years now produces intervals with no more precision than months, to match the behavior of Postgres. [#56158][#56158]
-- The `pg_attribute.atttypmod` column in the `pg_catalog` is now populated for [collated string types](https://www.cockroachlabs.com/docs/v20.2/collate). This also populates the value of the `TypeModifier` in the `RowDescription` message of the [pgwire protocol](https://www.postgresql.org/docs/current/static/protocol.html). [#55154][#55154]
-- Added an option to [scheduled backups](https://www.cockroachlabs.com/docs/v20.2/manage-a-backup-schedule) to maintain a timeseries metric for last backed up timestamp. [#54987][#54987]
-- Added an [`owner`](https://www.cockroachlabs.com/docs/v20.2/owner-to) column to the following statements: [`SHOW DATABASES`](https://www.cockroachlabs.com/docs/v20.2/show-databases), [`SHOW ENUMS`](https://www.cockroachlabs.com/docs/v20.2/show-enums),[`SHOW TABLES`](https://www.cockroachlabs.com/docs/v20.2/show-tables), and [`SHOW SCHEMAS`](https://www.cockroachlabs.com/docs/v20.2/show-schemas). [#56325][#56325]
-- A maximum of 65336 quadrant segments is allowed for the `ST_Buffer` [spatial function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#spatial-functions). This used to be unlimited. [#56676][#56676]
-- A maximum of 65336 points can be interpolated for `repeat=true` option to the `ST_InterpolatePoints` [spatial function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#spatial-functions). [#56676][#56676]
-- [`ALTER TABLE ... SET DATA TYPE ...`](https://www.cockroachlabs.com/docs/v20.2/alter-column) is no longer available for operations that involve conversion (e.g., [`STRING`](https://www.cockroachlabs.com/docs/v20.2/string) to [`TIMESTAMPTZ`](https://www.cockroachlabs.com/docs/v20.2/timestamp)) or precision/width truncation (e.g., [`INT(4)`](https://www.cockroachlabs.com/docs/v20.2/int) -> `INT(2)`) due to a bug in validation. These features are already gated by the [session variable](https://www.cockroachlabs.com/docs/v20.2/set-vars) `enable_experimental_alter_column_type_general` - setting this session variable is now a no-op. [#56629][#56629]
-- Previously, `timestamp/timestamptz - timestamp/timestamptz` operators would normalize the interval into months, days, `H:M:S` (in older versions, this may be just `H:M:S`). This can give an incorrect result:
-
-    ~~~sql
-    select '2020-01-01'::timestamptz - '2018-01-01';
-    ~~~
-
-    ~~~
-         ?column?
-    -------------------
-      2 years 10 days
-    (1 row)
-    ~~~
-
-    This has now been fixed to be more Postgres compatible such that it is only normalized into days/`H:M:S`. [#56751][#56751]
-
-- Previously, the `age` built-in would incorrectly normalize months and days based on 30 days a month (in older versions this may be just `H:M:S`). This can give an incorrect result:
-
-    ~~~sql
-    select age('2020-01-01'::timestamptz, '2018-01-01');
-    ~~~
-
-    ~~~
-            age
-    -------------------
-      2 years 10 days
-    (1 row)
-    ~~~
-
-    This is not as accurate as it could be, since `age` can use the given [`TIMESTAMPTZ`](https://www.cockroachlabs.com/docs/v20.2/timestamp) arguments to be more accurate. This has been updated to be more Postgres compatible. [#56751][#56751]
-
-<h3 id="v20-2-2-api-endpoint-changes">API endpoint changes</h3>
-
-- `AWS_SERVER_ENC_MODE` and `AWS_SERVER_KMS_ID` can now be specified as parameters in all S3 URIs that write to the store. This change affects both [changefeeds](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) and [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup)s. [#56132][#56132]
-
-<h3 id="v20-2-2-db-console-changes">DB Console changes</h3>
-
-- Fixes a bug where the "Other Execution Statistics" box in the [Statement Details page](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page#statement-details-page) would be empty in situations where the same fingerprint had been processed by multiple nodes. [#56774][#56774]
-- A link to the [Transactions Page](https://www.cockroachlabs.com/docs/v20.2/ui-transactions-page) is now shown between the **Sessions** and **Statements** links in the left hand navigation. This more clearly reflects the hierarchy between the 3 concepts. [#56652][#56652]
-- Rename **Active Sessions** to **Sessions** on the [Session Details page](https://www.cockroachlabs.com/docs/v20.2/ui-sessions-page). [#56652][#56652]
-- The [diagnostics column on the Statements Page](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page#diagnostics) has been changed and includes an `Activate` button and a dropdown list to download completed reports. Also, the diagnostics badge status is changed from `WAITING FOR QUERY` to `WAITING`. [#55890][#55890]
-- Fixed an issue where the [Statement Details page](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page#statement-details-page) didn't scroll on top when navigating from the Statements Page. [#55433][#55433]
-- Loading table-level statistics on the [Databases Page](https://www.cockroachlabs.com/docs/v20.2/ui-databases-page) now requires a button click per-database in order to prevent contention for clusters with many databases and/or tables. In addition, the loading of table data is staggered by table instead of triggered simultaneously for all tables. [#55777][#55777]
-- Added a new [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) called `server.oidc_authentication.autologin` which enables an automatic redirect to the OIDC login flow instead of showing a password login prompt. A query parameter can force disable this feature in the browser by appending `?oidc_auto_login=false` to the login path. [#56510][#56510]
-- Adjusted the styles for the [Session Details page](https://www.cockroachlabs.com/docs/v20.2/ui-sessions-page). [#55889][#55889]
-- [Transaction statistics](https://www.cockroachlabs.com/docs/v20.2/ui-sql-dashboard#transactions) are no longer recorded if the `sql.metrics.statement_details.threshold` [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) has been enabled. [#56380][#56380]
-- Fixed link colors for "Back" link on the [Node Overview](https://www.cockroachlabs.com/docs/v20.2/ui-cluster-overview-page), [Jobs](https://www.cockroachlabs.com/docs/v20.2/ui-jobs-page), [Sessions](https://www.cockroachlabs.com/docs/v20.2/ui-sessions-page), and [Statement Details](https://www.cockroachlabs.com/docs/v20.2/ui-statements-page#statement-details-page) pages. [#55889][#55889]
-
-<h3 id="v20-2-2-performance-improvements">Performance improvements</h3>
-
-- Adjusted the cost model in the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) so that the optimizer is less likely to plan a [lookup join](https://www.cockroachlabs.com/docs/v20.2/joins#lookup-joins) into a virtual table. Performing a lookup join into a virtual table is expensive, so this change will generally result in better performance for queries involving joins with virtual tables. [#56349][#56349]
-
-<h3 id="v20-2-2-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug introduced in v20.2 where we failed to upgrade [foreign keys](https://www.cockroachlabs.com/docs/v20.2/foreign-key) that used the pre-19.2-style internal representation when validating cross-references for tables.  This bug caused validation failures that made the referenced tables and metadata unavailable. The fix gets rid of the validation errors by accounting for the pre-19.2-style internal representation of foreign keys. [#57083][#57083]
-- Fixed a bug where CockroachDB would crash when executing a query via the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) when most of the SQL memory (determined via `--max-sql-memory` argument to [`cockroach start`](https://www.cockroachlabs.com/docs/v20.2/cockroach-start)) had already been reserved. [#55457][#55457]
-- Fixed a rare bug which could lead to possible write skew in distributed queries that have both zigzag joins and table readers with the zigzag joins reading keys not read by the table readers. [#55563][#55563]
-- The current implementation of [changefeeds](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) is incompatible with the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). Therefore, whenever the vectorized engine was being used to run changefeeds, the command could hang indefinitely. This bug is now fixed. On v20.2 releases this could happen if the user ran `SET vectorize_row_count_threshold=0;`, and on v20.1 releases it could happen if the user ran `SET vectorize=on`. [#55753][#55753]
-- Fixed a bug where CockroachDB could incorrectly evaluate the `sqrdiff` function when used as a [window function](https://www.cockroachlabs.com/docs/v20.2/window-functions) in some cases. [#55995][#55995]
-- Fixed a bug where CockroachDB could incorrectly compute some [aggregate functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#aggregate-functions) with `DISTINCT` clauses when the query projected other columns/functions and the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) was used. This bug was introduced in the `v20.2.0.alpha.3` release. [#55872][#55872]
-- Fixed a bug where CockroachDB could return incorrect results when computing the [aggregate functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#aggregate-functions) when some of the functions have `DISTINCT` clauses and some do not (the latter might not see all the necessary data). [#55872][#55872]
-- Fixed a bug where the [JSON fetch value operator `->`](https://www.cockroachlabs.com/docs/v20.2/jsonb#operators) would evaluate incorrectly in some cases. [#55447][#55447]
-- Scheduled [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) now supports [KMS encryption](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html). [#56099][#56099]
-- Fixed a bug where [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import)s of malformed [Avro](https://www.cockroachlabs.com/docs/v20.2/migrate-from-avro) records could hang forever. [#56094][#56094]
-- Updated CockroachDB to avoid crashing when [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) is unable to count the total nodes in the cluster. [#56050][#56050]
-- Fixed a bug where an [`IMPORT PGDUMP`](https://www.cockroachlabs.com/docs/v20.2/migrate-from-postgres) with [`INSERT`](https://www.cockroachlabs.com/docs/v20.2/insert)s not targeting all columns in the database would panic. [#56034][#56034]
-- Using the `min` or `max` [aggregate functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#aggregate-functions) in a prepared statement will now report the correct data type size. [#55622][#55622]
-- Fixed an error `"top-level relational expression cannot have outer columns"` that could occur in some queries that involve a [`WITH` expression](https://www.cockroachlabs.com/docs/v20.2/common-table-expressions). [#56084][#56084]
-- Fixed an internal error that could occur during query planning when the `use_spheroid` parameter was used in the `ST_Distance` [spatial function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#spatial-functions) as part of a filter predicate. For example, `SELECT ... WHERE ST_Distance(geog1, geog2, false) < 10` previously caused an error. [#55852][#55852]
-- Fixed a bug where CockroachDB previously didn't account for all the memory used by the vectorized hash aggregation which could lead to an OOM crash. [#55555][#55555]
-- Fixed a bug which allowed statements after a [schema change](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes) to fail to observe side-effects of that change on referenced tables. [#56327][#56327]
-- Fixed a bug where if a [cluster backup](https://www.cockroachlabs.com/docs/v20.2/backup#backup-a-cluster) was taken during a [schema change](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes), a cluster restore of that backup would create duplicates of the ongoing schema changes. [#56390][#56390]
-- Fixed a bug where [dumps](https://www.cockroachlabs.com/docs/v20.2/cockroach-dump) of tables with a [`BIT`](https://www.cockroachlabs.com/docs/v20.2/bit) type column would result in an error. This column type is now supported. [#56391][#56391]
-- Fixed a bug which would cause [transactions](https://www.cockroachlabs.com/docs/v20.2/transactions) that modified [roles](https://www.cockroachlabs.com/docs/v20.2/authorization#create-and-manage-roles) and then attempted to read or modify other roles to encounter blocking and stale data. [#55392][#55392]
-- Fixed a bug where CockroachDB did not respect disabling [protected timestamp settings `kv.protectedts.max_bytes` and `kv.protectedts.max_spans`](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) by setting them to zero values. [#56453][#56453]
-- Fixed a panic that could occur when running [`SHOW STATISTICS USING JSON`](https://www.cockroachlabs.com/docs/v20.2/show-statistics) for a table in which at least one of the columns contained all _NULL_ values. [#56516][#56516]
-- Fixed a hypothesized bug that could have allowed a [follower read](https://www.cockroachlabs.com/docs/v20.2/follower-reads) to miss data on a range in the middle of being [merged](https://www.cockroachlabs.com/docs/v20.2/architecture/distribution-layer#range-merges) away into its left-hand neighbor. [#55691][#55691]
-- Fixed a bug introduced in an alpha where [`IMPORT`s](https://www.cockroachlabs.com/docs/v20.2/import) of tables with [foreign keys](https://www.cockroachlabs.com/docs/v20.2/foreign-key) can fail in rare circumstances. [#56457][#56457]
-- Fixed a bug which would prevent the dropping of [hash sharded indexes](https://www.cockroachlabs.com/docs/v20.2/hash-sharded-indexes) if they were added prior to other columns. [#55822][#55822]
-- Fixed a bug which cause CockroachDB to crash when executing a query with an [`AS OF SYSTEM TIME`](https://www.cockroachlabs.com/docs/v20.2/as-of-system-time) clause that attempted to use an unspecified placeholder value on a non-prepared statement. [#56780][#56780]
-- Fixed an internal error when a [`DATE`](https://www.cockroachlabs.com/docs/v20.2/date)/[`TIMESTAMP`/`TIMESTAMPTZ`](https://www.cockroachlabs.com/docs/v20.2/timestamp) from the year 1 BC was sent between nodes for execution. Also, fixed a bug where it was not possible to specify the `DATE`/`TIMESTAMP`/`TIMESTAMPTZ` of the year 1 BC without using the AD/BC notation. [#56742][#56742]
-- Some boolean [session variables](https://www.cockroachlabs.com/docs/v20.2/set-vars) would only accept quoted string values `"true"` or `"false"`. Now they accept unquoted `true` or `false` values too. [#56813][#56813]
-- Fixed an internal error that could occur when collecting a [statement diagnostic bundle](https://www.cockroachlabs.com/docs/v20.2/explain-analyze#debug-option). [#56784][#56784]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-2-contributors">Contributors</h3>
-
-This release includes 88 merged PRs by 26 authors.
-
-We would like to thank the following contributors from the CockroachDB community:
-
-- Max Neverov (first-time contributor)
-
-</div>
-
-[#54987]: https://github.com/cockroachdb/cockroach/pull/54987
-[#55154]: https://github.com/cockroachdb/cockroach/pull/55154
-[#55298]: https://github.com/cockroachdb/cockroach/pull/55298
-[#55392]: https://github.com/cockroachdb/cockroach/pull/55392
-[#55433]: https://github.com/cockroachdb/cockroach/pull/55433
-[#55447]: https://github.com/cockroachdb/cockroach/pull/55447
-[#55457]: https://github.com/cockroachdb/cockroach/pull/55457
-[#55500]: https://github.com/cockroachdb/cockroach/pull/55500
-[#55555]: https://github.com/cockroachdb/cockroach/pull/55555
-[#55563]: https://github.com/cockroachdb/cockroach/pull/55563
-[#55622]: https://github.com/cockroachdb/cockroach/pull/55622
-[#55691]: https://github.com/cockroachdb/cockroach/pull/55691
-[#55753]: https://github.com/cockroachdb/cockroach/pull/55753
-[#55777]: https://github.com/cockroachdb/cockroach/pull/55777
-[#55822]: https://github.com/cockroachdb/cockroach/pull/55822
-[#55852]: https://github.com/cockroachdb/cockroach/pull/55852
-[#55872]: https://github.com/cockroachdb/cockroach/pull/55872
-[#55889]: https://github.com/cockroachdb/cockroach/pull/55889
-[#55890]: https://github.com/cockroachdb/cockroach/pull/55890
-[#55995]: https://github.com/cockroachdb/cockroach/pull/55995
-[#56034]: https://github.com/cockroachdb/cockroach/pull/56034
-[#56049]: https://github.com/cockroachdb/cockroach/pull/56049
-[#56050]: https://github.com/cockroachdb/cockroach/pull/56050
-[#56084]: https://github.com/cockroachdb/cockroach/pull/56084
-[#56094]: https://github.com/cockroachdb/cockroach/pull/56094
-[#56099]: https://github.com/cockroachdb/cockroach/pull/56099
-[#56132]: https://github.com/cockroachdb/cockroach/pull/56132
-[#56158]: https://github.com/cockroachdb/cockroach/pull/56158
-[#56325]: https://github.com/cockroachdb/cockroach/pull/56325
-[#56327]: https://github.com/cockroachdb/cockroach/pull/56327
-[#56338]: https://github.com/cockroachdb/cockroach/pull/56338
-[#56349]: https://github.com/cockroachdb/cockroach/pull/56349
-[#56380]: https://github.com/cockroachdb/cockroach/pull/56380
-[#56390]: https://github.com/cockroachdb/cockroach/pull/56390
-[#56391]: https://github.com/cockroachdb/cockroach/pull/56391
-[#56453]: https://github.com/cockroachdb/cockroach/pull/56453
-[#56456]: https://github.com/cockroachdb/cockroach/pull/56456
-[#56457]: https://github.com/cockroachdb/cockroach/pull/56457
-[#56502]: https://github.com/cockroachdb/cockroach/pull/56502
-[#56510]: https://github.com/cockroachdb/cockroach/pull/56510
-[#56516]: https://github.com/cockroachdb/cockroach/pull/56516
-[#56629]: https://github.com/cockroachdb/cockroach/pull/56629
-[#56638]: https://github.com/cockroachdb/cockroach/pull/56638
-[#56652]: https://github.com/cockroachdb/cockroach/pull/56652
-[#56676]: https://github.com/cockroachdb/cockroach/pull/56676
-[#56742]: https://github.com/cockroachdb/cockroach/pull/56742
-[#56751]: https://github.com/cockroachdb/cockroach/pull/56751
-[#56774]: https://github.com/cockroachdb/cockroach/pull/56774
-[#56780]: https://github.com/cockroachdb/cockroach/pull/56780
-[#56784]: https://github.com/cockroachdb/cockroach/pull/56784
-[#56813]: https://github.com/cockroachdb/cockroach/pull/56813
-[#57083]: https://github.com/cockroachdb/cockroach/pull/57083
diff --git a/src/current/_includes/releases/v20.2/v20.2.3.md b/src/current/_includes/releases/v20.2/v20.2.3.md
deleted file mode 100644
index bebc4401cf8..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.3.md
+++ /dev/null
@@ -1,96 +0,0 @@
-## v20.2.3
-
-Release Date: December 14, 2020
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a58932.md %}
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a63162.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-3-sql-language-changes">SQL language changes</h3>
-
-- Added admin-only `crdb_internal` [functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) to enable descriptor repair in dire circumstances. [#56937][#56937]
-- Introduced a hint when GEOS is improperly installed to read the documented [instructions on installing CockroachDB](https://www.cockroachlabs.com/docs/v20.2/install-cockroachdb) [#57033][#57033]
-- Added support for running [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import) in a mixed-version cluster. [#57599][#57599]
-
-<h3 id="v20-2-3-api-endpoint-changes">API endpoint changes</h3>
-
-- Added a new prometheus metric called `seconds_until_license_expiry` that reports on the number of seconds until the enterprise license on the cluster expires and 0 if there is no license. It will return a negative number if the expiration is in the past. [#56463][#56463]
-
-<h3 id="v20-2-3-db-console-changes">DB Console changes</h3>
-
-- Updated design for custom date range selector on the [Cluster > Node Map](https://www.cockroachlabs.com/docs/v20.2/ui-cluster-overview-page#node-map-enterprise) and [Metrics](https://www.cockroachlabs.com/docs/v20.2/ui-overview-dashboard) pages. [#57115][#57115]
-- [Job details page](https://www.cockroachlabs.com/docs/v20.2/ui-jobs-page) now shows description for failed job. [#57116][#57116]
-
-<h3 id="v20-2-3-bug-fixes">Bug fixes</h3>
-
-- Eliminated opportunity for live lock in jobs subsystem due to frequent updates to already-finished jobs. [#56864][#56864]
-- Fixed a bug causing the `LogFile` reserved API, which was used by [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip), to corrupt log entries. [#56902][#56902]
-- Fixed a bug introduced in the 20.2 series that could cause CockroachDB to crash due to range scans over virtual tables with virtual indexes. [#56924][#56924]
-- Fixed a race condition in the [`tpcc` workload](https://www.cockroachlabs.com/docs/v20.2/cockroach-workload) with the `--scatter` flag where tables could be scattered multiple times or not at all. [#56978][#56978]
-- Fixed a bug causing tables and metadata to be unavailable due to spurious `missing fk back reference` validation errors. [#57083][#57083]
-- Fixed a bug related to the validation of un-upgraded, pre-19.2 inbound [foreign keys](https://www.cockroachlabs.com/docs/v20.2/foreign-key). [#57133][#57133]
-- Creating a [materialized view](https://www.cockroachlabs.com/docs/v20.2/views) that references a column with a `NULL` value no longer results in an error. [#57193][#57193]
-- Fixed a bug that caused an "ambiguous column reference" error during foreign key cascading updates. This error was incorrectly produced when the child table's reference column name was equal to the concatenation of the parent's reference column name and "_new", and when the child table had a [`CHECK`](https://www.cockroachlabs.com/docs/v20.2/check) constraint, a [computed column](https://www.cockroachlabs.com/docs/v20.2/computed-columns), or a [partial index](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) predicate expression that referenced the column. This bug was introduced in version 20.2.0. [#57234][#57234]
-- Fixed a bug that could cause a crash loop in rare circumstances. [#57312][#57312]
-- `ST_GeomFromGeoJSON` now sets the SRID to 4326, matching PostGIS 3.0 / RFC7946 behavior. [#57245][#57245]
-- [`SELECT FOR UPDATE`](https://www.cockroachlabs.com/docs/v20.2/select-for-update) now requires both `SELECT` and `UPDATE` [privileges](https://www.cockroachlabs.com/docs/v20.2/authorization), instead of just `UPDATE` privileges. [#57350][#57350]
-- Fixed a bug that caused errors or corrupted partial indexes of child tables in foreign key relationships with cascading [`UPDATE`](https://www.cockroachlabs.com/docs/v20.2/update)s and [`DELETE`](https://www.cockroachlabs.com/docs/v20.2/delete)s. The corrupt partial indexes could result in incorrect query results. Any partial indexes on child tables of foreign key relationships with `ON DELETE CASCADE` or `ON UPDATE CASCADE` actions may be corrupt and should be dropped and re-created. This bug was introduced in version 20.2.0. [#57325][#57325]
-- Fixed a bug that could cause new nodes to fail to start up when [upgrading to 20.2](https://www.cockroachlabs.com/docs/v20.2/upgrade-cockroach-version), due to a startup migration which would fail to terminate due to incorrect pagination in the presence of at least 100 running jobs. [#57437][#57437]
-- Fixed a bug causing an internal error when executing `JSONB - String` operations via the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). This bug was introduced in version 20.2.0. [#57388][#57388]
-- Fixed an internal error that could occur when using aggregate and window functions in an [`ORDER BY`](https://www.cockroachlabs.com/docs/v20.2/order-by) for a `UNION` or `VALUES` clause. [#57521][#57521]
-- [`DROP TYPE`](https://www.cockroachlabs.com/docs/v20.2/drop-type) and certain other statements that work over SQL scalar types now properly support type names containing special characters. [#57558][#57558]
-- Fixed performance regression to reading virtual tables which introspect the schema. This regression was introduced in version 20.2.0. [#57574][#57574]
-- Removed the `system.jobs` full table scan, which can be expensive with many completed jobs. [#57591][#57591]
-- Users can now perform a [cluster restore](https://www.cockroachlabs.com/docs/v20.2/restore) from old backup chains (i.e., incremental backups on top of full backups), when using the `BACKUP INTO` syntax. [#57667][#57667]
-- Fixed a bug causing CockroachDB to crash when creating backup schedules writing to GCS buckets. [#57651][#57651]
-- Fixed a bug causing users of the OSS builds of CockroachDB to see "Page Not Found" when loading the [DB Console](https://www.cockroachlabs.com/docs/v20.2/ui-overview). [#56776][#56776]
-
-<h3 id="v20-2-3-performance-improvements">Performance improvements</h3>
-
-- Interactions between [Raft](https://www.cockroachlabs.com/docs/v20.2/architecture/replication-layer) heartbeats and the Raft goroutine pool scheduler are now more efficient and avoid excessive mutex contention. This was observed to prevent instability on large machines (32+ vCPU) in clusters with many ranges (50k+ per node). [#57008][#57008]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-3-contributors">Contributors</h3>
-
-This release includes 46 merged PRs by 20 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Joshua M. Clulow (first-time contributor)
-
-</div>
-
-[#56443]: https://github.com/cockroachdb/cockroach/pull/56443
-[#56463]: https://github.com/cockroachdb/cockroach/pull/56463
-[#56776]: https://github.com/cockroachdb/cockroach/pull/56776
-[#56864]: https://github.com/cockroachdb/cockroach/pull/56864
-[#56902]: https://github.com/cockroachdb/cockroach/pull/56902
-[#56924]: https://github.com/cockroachdb/cockroach/pull/56924
-[#56937]: https://github.com/cockroachdb/cockroach/pull/56937
-[#56978]: https://github.com/cockroachdb/cockroach/pull/56978
-[#57008]: https://github.com/cockroachdb/cockroach/pull/57008
-[#57033]: https://github.com/cockroachdb/cockroach/pull/57033
-[#57083]: https://github.com/cockroachdb/cockroach/pull/57083
-[#57115]: https://github.com/cockroachdb/cockroach/pull/57115
-[#57116]: https://github.com/cockroachdb/cockroach/pull/57116
-[#57133]: https://github.com/cockroachdb/cockroach/pull/57133
-[#57193]: https://github.com/cockroachdb/cockroach/pull/57193
-[#57234]: https://github.com/cockroachdb/cockroach/pull/57234
-[#57245]: https://github.com/cockroachdb/cockroach/pull/57245
-[#57312]: https://github.com/cockroachdb/cockroach/pull/57312
-[#57325]: https://github.com/cockroachdb/cockroach/pull/57325
-[#57350]: https://github.com/cockroachdb/cockroach/pull/57350
-[#57388]: https://github.com/cockroachdb/cockroach/pull/57388
-[#57437]: https://github.com/cockroachdb/cockroach/pull/57437
-[#57484]: https://github.com/cockroachdb/cockroach/pull/57484
-[#57521]: https://github.com/cockroachdb/cockroach/pull/57521
-[#57558]: https://github.com/cockroachdb/cockroach/pull/57558
-[#57574]: https://github.com/cockroachdb/cockroach/pull/57574
-[#57591]: https://github.com/cockroachdb/cockroach/pull/57591
-[#57599]: https://github.com/cockroachdb/cockroach/pull/57599
-[#57651]: https://github.com/cockroachdb/cockroach/pull/57651
-[#57667]: https://github.com/cockroachdb/cockroach/pull/57667
diff --git a/src/current/_includes/releases/v20.2/v20.2.4.md b/src/current/_includes/releases/v20.2/v20.2.4.md
deleted file mode 100644
index c4363784235..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.4.md
+++ /dev/null
@@ -1,133 +0,0 @@
-## v20.2.4
-
-Release Date: January 21, 2021
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a63162.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-4-security-updates">Security updates</h3>
-
-- When using a SQL proxy, in the default configuration CockroachDB only knows about the network address of the proxy. That *peer* address is then used for logging, authentication rules, etc. This is undesirable, as security logging and authentication rules need to operate on the actual (final) client address instead. CockroachDB can now be configured to solve this problem using the mechanism detailed below. When so configured, a SQL proxy can inform the CockroachDB server of the real address of the client via a server status parameter called `crdb:remote_addr`. The value must be the IP address of the client, followed by a colon, followed by the port number, using the standard Go syntax (e.g., `11.22.33.44:5566` for IPv4, `[11:22::33]:4455` for IPv6). When provided, this value overrides the SQL proxy's address for logging and authentication purposes. In any case, the original peer address is also logged alongside the client address (overridden or not), via the new logging tag `peer`. Security considerations:
-  - Enabling this feature allows the peer to spoof its address with respect to authentication and thus bypass authentication rules that would otherwise apply to its address, which can introduce a serious security vulnerability if the peer is not trusted. This is why this feature is not enabled by default, and must only be enabled when using a trusted SQL proxy.
-  - This feature should only be used with SQL proxies which actively scrub a `crdb:remote_addr` parameter received by a remote client, and replaces it by its own. If the proxy mistakenly forwards the parameter as provided by the client, it opens the door to the aforementioned security vulnerability.
-  - Care must be taken in host-based authentication (HBA) rules:
-      - TLS client cert validation, if requested by a rule, is still performed using the certificate presented by the proxy, not that presented by the client. This means that this new feature is not sufficient to forward TLS client cert authn through a proxy. (If TLS client cert authn is required, it must be performed by the proxy directly.)
-      - The `protocol` field (first column) continues to apply to the connection type between CockroachDB and the proxy, not between the proxy and the client. Only the 4th column (the CIDR pattern) is matched against the proxy-provided remote address override. Therefore, it is not possible to apply different rules to different client address when proxying TCP connections via a unix socket, because HBA rules for unix connections do not use the address column. Also when proxying client SSL connections via a non-SSL proxy connection, or proxying client non-SSL connections via a SSL proxy connection, care must be taken to configure address-based rule matching using the proper connection type. A reliable way to bypass this complexity is to only use the `host` connection type which applies equally to SSL and non-SSL connections. As of this implementation, the feature is enabled using the non-documented environment variable `COCKROACH_TRUST_CLIENT_PROVIDED_SQL_REMOTE_ADDR`. The use of an environment variable is a stop-gap so that this feature can be used in CockroachCloud SQL pods which do not have access to [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings). The environment variable will be eventually removed and replaced by another mechanism. [#58380][#58380]
-
-<h3 id="v20-2-4-sql-language-changes">SQL language changes</h3>
-
-- Added an overload to `crdb_internal.pb_to_json` to suppress populating default values in fields. [#58127][#58127]
-- A table can now be successfully dropped in a transaction following other [schema changes](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes) to the table in the same transaction. [#58255][#58255] {% comment %}doc{% endcomment %}
-- The `crdb_internal.cluster_id` [function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) now returns the ID of the underlying KV cluster in multi-tenant scenarios rather than the [Nil UUID](https://www.ietf.org/rfc/rfc4122.html#section-4.1.7). [#58441][#58441] {% comment %}doc{% endcomment %}
-- Multi-tenant clusters will now send anonymous usage information to the central CockroachDB registration server. [#58517][#58517] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-4-command-line-changes">Command-line changes</h3>
-
-- Added a flag to `cockroach debug decode-proto` to suppress populating default values in fields. [#58127][#58127] {% comment %}doc{% endcomment %}
-- Some specific CLI usage situations now have dedicated exit status codes. [#56724][#56724] The codes are defined as follows:
-  - 0: Process terminated without error.
-  - 1: An unspecified error was encountered. Explanation should be present in the stderr or logging output.
-  - 2: Go runtime error, or uncaught panic. Likely a bug in CockroachDB. Explanation may be present in logging output.
-  - 3: Server process interrupted gracefully with Ctrl+C / `SIGINT`.
-  - 4: Command-line flag error.
-  - 5: A logging operation to the process' stderr stream failed (e.g., stderr has been closed). Some details may be present in the file output, if enabled.
-  - 6: A logging operation to file has failed (e.g., log disk full, no inodes, permission issue, etc.). Some details may be present in the stderr stream.
-  - 7: Server detected an internal error and triggered an emergency shutdown.
-  - 8: Logging failed while processing an emergency shutdown.
-
-<h3 id="v20-2-4-db-console-changes">DB Console changes</h3>
-
-- Made minor style changes to represent the new branding palette. [#57978][#57978]
-- Changed the default per-page value on the [Transactions page](https://www.cockroachlabs.com/docs/v20.2/ui-transactions-page) to 20; made minor style updates. [#57978][#57978]
-
-<h3 id="v20-2-4-bug-fixes">Bug fixes</h3>
-
-- Fixed a bug where `cockroach demo --global` was crashing with "didn't get expected magic bytes header". [#58626][#58626]
-- Fixed a bug in [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) where some unusual range boundaries in interleaved tables caused an error. [#58259][#58259]
-- Fixed a bug that was introduced in the v20.2.0 release where we mistakenly permitted users with the admin role to drop tables in the system database. This commit revokes that privilege. [#57642][#57642]
-- Fix a bug where the `ST_MakeLine` and `ST_Collect` [functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) did not respect ordering when used over a [window](https://www.cockroachlabs.com/docs/v20.2/window-functions) clause. [#57750][#57750]
-- Fix a bug that could cause [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import) to incorrectly read files stored on Google Cloud if uploaded using its compression option (`gsutil -Z`). [#57748][#57748]
-- Fixed a bug where [schema change](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes) jobs to add [foreign keys](https://www.cockroachlabs.com/docs/v20.2/foreign-key)to existing tables, via [`ALTER TABLE`](https://www.cockroachlabs.com/docs/v20.2/alter-table), could sometimes not be successfully reverted (either due to being canceled or having failed). [#57809][#57809]
-- Fixes a bug where concurrent addition of a [foreign key](https://www.cockroachlabs.com/docs/v20.2/foreign-key) constraint and drop of a unique [index](https://www.cockroachlabs.com/docs/v20.2/indexes) could cause the foreign key constraint to be added with no [unique](https://www.cockroachlabs.com/docs/v20.2/unique) constraint on the referenced columns. [#57809][#57809]
-- Fixed an assertion error caused by some DDL statements used in conjunction with [common table expressions (`WITH`)](https://www.cockroachlabs.com/docs/v20.2/common-table-expressions). [#57951][#57951]
-- Fixed a bug where canceled queries reading from virtual tables could cause a crashing panic. [#57884][#57884]
-- Fixed a bug where tables in schemas other than "public" would not be displayed when running [`SHOW TABLES FROM <db>`](https://www.cockroachlabs.com/docs/v20.2/show-tables). [#57814][#57814]
-- Fixed a bug that caused [temp tables](https://www.cockroachlabs.com/docs/v20.2/temporary-tables) to not be cleaned up after the associated session was closed. [#57922][#57922]
-- Fixed a bug which caused type information to be omitted when decoding descriptors using either `crdb_internal.pb_to_json` or `cockroach debug decode-proto`. [#58127][#58127]
-- Fixed a bug where CockroachDB could return non-deterministic output when querying the `information_schema.statistics` virtual table (internally used by [`SHOW INDEXES`](https://www.cockroachlabs.com/docs/v20.2/show-index) command). Specifically, the implicit columns of the secondary [indexes](https://www.cockroachlabs.com/docs/v20.2/indexes) could be in arbitrary order. The columns will now be in the same order as they are in the primary [index](https://www.cockroachlabs.com/docs/v20.2/indexes). [#58214][#58214]
-- Fixed a crash with the message "column family 0 not found" caused by [`EXPLAIN`ing](https://www.cockroachlabs.com/docs/v20.2/explain) or gathering [statement diagnostics](https://www.cockroachlabs.com/docs/v20.2/explain-analyze#debug-option) on certain queries involving virtual tables. [#58243][#58243]
-- Fixed a potential "nil pointer dereference" panic when collecting diagnostics on certain queries. [#58210][#58210]
-- Added a safeguard against crashes while running [`SHOW STATISTICS USING JSON`](https://www.cockroachlabs.com/docs/v20.2/show-statistics), which is used internally for statement diagnostics and [`EXPLAIN ANALYZE (DEBUG)`](https://www.cockroachlabs.com/docs/v20.2/explain-analyze#debug-option). [#58263][#58263]
-- Fixed a bug where prior [schema changes](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes) on a table that failed and could not be fully reverted could prevent the table from being dropped. [#58255][#58255]
-- Fixed a bug introduced in 20.1 where CockroachDB could crash when performing a [`DELETE`](https://www.cockroachlabs.com/docs/v20.2/delete) operation after an alteration of the [primary key](https://www.cockroachlabs.com/docs/v20.2/primary-key) in some cases. [#58266][#58266]
-- Fixed a memory leak in the optimizer. The leak could have caused unbounded growth of memory usage for a session when planning queries on tables with [partial indexes](https://www.cockroachlabs.com/docs/v20.2/partial-indexes). [#58308][#58308]
-- Fixed a bug which could cause [incremental backups](https://www.cockroachlabs.com/docs/v20.2/take-full-and-incremental-backups#incremental-backups) to a backup in a collection (i.e., `BACKUP INTO ... IN ...`) on some cloud storage providers to ignore existing incremental backups previously appended to that destination, and instead backup incrementally from the base backup in that destination. [#58331][#58331]
-- Fixed a [storage layer](https://www.cockroachlabs.com/docs/v20.2/architecture/storage-layer) bug that could cause deleted `system.jobs` rows to remain on-disk indefinitely. The bloated `system.jobs` table could make [jobs](https://www.cockroachlabs.com/docs/v20.2/show-jobs) completely unavailable and prevent DDL statements from executing. This bug can be detected by examining the `system.jobs` table size from the [DB Console](https://www.cockroachlabs.com/docs/v20.2/ui-overview). This change fixes the bug for Pebble only and the bug still persists on RocksDB. [#58304][#58304]
-- Fixed a bug where prepared statements that included [enums](https://www.cockroachlabs.com/docs/v20.2/enum) and used the binary format could result in an error. [#58044][#58044]
-- Fixed a internal panic when using the [`SHOW STATISTICS USING JSON`](https://www.cockroachlabs.com/docs/v20.2/show-statistics) statement on a table containing [`ENUM`](https://www.cockroachlabs.com/docs/v20.2/enum) types. [#58413][#58413]
-- Fixed a bug where [`SHOW GRANTS ON DATABASE`](https://www.cockroachlabs.com/docs/v20.2/show-grants) did not include privileges that were granted on a database. The output includes `database_name`, `schema_name`, `grantee`, and `privilege_type`. The `schema_name` is always "public" since these grants are not per-schema. [#58096][#58096]
-- Fixed a bug where the `information_schema.schema_privileges` table did not includes the correct schema-level privileges for non-user-defined schemas. [#58096][#58096]
-- The `has_schema_privilege` built-in [function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) now works on user-defined schemas when checking for the `USAGE` privilege. [#58096][#58096]
-- Fixed a bug which caused errors when querying a table with a disjunctive filter (an `OR` expression) that is the same or similar to the predicate of one of the table's [partial indexes](https://www.cockroachlabs.com/docs/v20.2/partial-indexes). [#58437][#58437]
-- Fixed a bug where a [`CREATE TABLE`](https://www.cockroachlabs.com/docs/v20.2/create-table) statement with [indexes](https://www.cockroachlabs.com/docs/v20.2/indexes) with duplicate names resulted in an assertion failure. This bug was present since version 20.2. [#58447][#58447]
-- Fixed a bug where the `has_${OBJECT}_privilege` built-in [functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) such as `has_schema_privilege` did not check whether roles the user is a direct or indirect member of also have privileges on the object. Previously only one user was checked which was incorrect. This bug has been present since version 2.0 but became more prominent as of v20.2 when [role-based access control](https://www.cockroachlabs.com/docs/v20.2/authorization#roles) was included in CockroachDB Core. [#58512][#58512]
-- Fixed a bug where CockroachDB would return an internal error when attempting to execute a [hash join](https://www.cockroachlabs.com/docs/v20.2/joins#hash-joins) on a [`JSON`](https://www.cockroachlabs.com/docs/v20.2/jsonb) column via the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution). Now a more user-friendly error is returned. [#58709][#58709]
-- Fixed a panic in protobuf decoding. [#58720][#58720]
-
-<h3 id="v20-2-4-performance-improvements">Performance improvements</h3>
-
-- Fixed a performance regression where the user authentication flow was performing extraneous name lookups. This regression was present since v20.2. [#58739][#58739]
-- Previously, when performing an unordered `DISTINCT` operation via the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution), CockroachDB would buffer up all tuples from the input, which is a suboptimal behavior when the query has a `LIMIT` clause. This behavior was introduced in v20.1, and has now been fixed. Note that the old row-by-row engine doesn't have this issue. [#57643][#57643]
-- [Partial indexes](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) with `IS NOT NULL` predicates can be used in cases where `JOIN` filters implicitly imply the predicate. This results in more efficient query plans for [`JOIN`s](https://www.cockroachlabs.com/docs/v20.2/joins) and [foreign key](https://www.cockroachlabs.com/docs/v20.2/foreign-key) checks. [#58272][#58272]
-- SQL statistics collection has been made more efficient by avoiding an accidental heap allocation per row for some schemas. [#58197][#58197]
-
-<h3 id="v20-2-4-miscellaneous">Miscellaneous</h3>
-
-- Correctly export `schedules_BACKUP_*` metrics as well as a backup RPO metric. [#57512][#57512]
-
-<h3 id="v20-2-4-contributors">Contributors</h3>
-
-This release includes 58 merged PRs by 27 authors.
-
-[#56724]: https://github.com/cockroachdb/cockroach/pull/56724
-[#57512]: https://github.com/cockroachdb/cockroach/pull/57512
-[#57642]: https://github.com/cockroachdb/cockroach/pull/57642
-[#57643]: https://github.com/cockroachdb/cockroach/pull/57643
-[#57748]: https://github.com/cockroachdb/cockroach/pull/57748
-[#57750]: https://github.com/cockroachdb/cockroach/pull/57750
-[#57789]: https://github.com/cockroachdb/cockroach/pull/57789
-[#57809]: https://github.com/cockroachdb/cockroach/pull/57809
-[#57814]: https://github.com/cockroachdb/cockroach/pull/57814
-[#57884]: https://github.com/cockroachdb/cockroach/pull/57884
-[#57922]: https://github.com/cockroachdb/cockroach/pull/57922
-[#57951]: https://github.com/cockroachdb/cockroach/pull/57951
-[#57978]: https://github.com/cockroachdb/cockroach/pull/57978
-[#58044]: https://github.com/cockroachdb/cockroach/pull/58044
-[#58051]: https://github.com/cockroachdb/cockroach/pull/58051
-[#58096]: https://github.com/cockroachdb/cockroach/pull/58096
-[#58127]: https://github.com/cockroachdb/cockroach/pull/58127
-[#58197]: https://github.com/cockroachdb/cockroach/pull/58197
-[#58210]: https://github.com/cockroachdb/cockroach/pull/58210
-[#58214]: https://github.com/cockroachdb/cockroach/pull/58214
-[#58243]: https://github.com/cockroachdb/cockroach/pull/58243
-[#58255]: https://github.com/cockroachdb/cockroach/pull/58255
-[#58259]: https://github.com/cockroachdb/cockroach/pull/58259
-[#58263]: https://github.com/cockroachdb/cockroach/pull/58263
-[#58266]: https://github.com/cockroachdb/cockroach/pull/58266
-[#58272]: https://github.com/cockroachdb/cockroach/pull/58272
-[#58304]: https://github.com/cockroachdb/cockroach/pull/58304
-[#58308]: https://github.com/cockroachdb/cockroach/pull/58308
-[#58331]: https://github.com/cockroachdb/cockroach/pull/58331
-[#58380]: https://github.com/cockroachdb/cockroach/pull/58380
-[#58413]: https://github.com/cockroachdb/cockroach/pull/58413
-[#58437]: https://github.com/cockroachdb/cockroach/pull/58437
-[#58441]: https://github.com/cockroachdb/cockroach/pull/58441
-[#58447]: https://github.com/cockroachdb/cockroach/pull/58447
-[#58500]: https://github.com/cockroachdb/cockroach/pull/58500
-[#58512]: https://github.com/cockroachdb/cockroach/pull/58512
-[#58517]: https://github.com/cockroachdb/cockroach/pull/58517
-[#58626]: https://github.com/cockroachdb/cockroach/pull/58626
-[#58709]: https://github.com/cockroachdb/cockroach/pull/58709
-[#58720]: https://github.com/cockroachdb/cockroach/pull/58720
-[#58739]: https://github.com/cockroachdb/cockroach/pull/58739
diff --git a/src/current/_includes/releases/v20.2/v20.2.5.md b/src/current/_includes/releases/v20.2/v20.2.5.md
deleted file mode 100644
index f3a2b94cd02..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.5.md
+++ /dev/null
@@ -1,82 +0,0 @@
-## v20.2.5
-
-Release Date: February 16, 2021
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a63162.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-5-security-updates">Security updates</h3>
-
-- Added the ability to set region-specific callback URLs in the [OIDC config](https://www.cockroachlabs.com/docs/v20.2/sso). The `server.oidc_authentication.redirect_url` [cluster setting](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) can now accept JSON as an alternative to the basic URL string setting. If a JSON value is set, it *must* contain a `redirect_url` key that maps to an object with key-value pairs where the key is a `region` matching an existing locality setting, and the value is a callback URL. [#59651][#59651]
-
-<h3 id="v20-2-5-general-changes">General changes</h3>
-
-- CockroachDB now runs fewer threads in parallel if running inside a container with a CPU limit. [#59184][#59184]
-- Added ability to further debug connections shut down automatically by the server. [#59503][#59503]
-- Renamed instances of "Admin UI" to "DB Console" in the documentation of [OIDC](https://www.cockroachlabs.com/docs/v20.2/sso) cluster settings. [#59651][#59651]
-
-<h3 id="v20-2-5-sql-language-changes">SQL language changes</h3>
-
-- Introduced a cluster setting `sql.show_tables.estimated_row_count.enabled`, which defaults to `true`. If `sql.show_tables.estimated_row_count.enabled=false`, `estimated_row_count` will not display on [`SHOW TABLES`](https://www.cockroachlabs.com/docs/v20.2/show-tables) which improves performance. [#59776][#59776]
-
-<h3 id="v20-2-5-command-line-changes">Command-line changes</h3>
-
-- Previously, for certain log files, CockroachDB would both flush individual writes (i.e., propagate them from within the `cockroach` process to the OS) and synchronize writes (i.e., ask the OS to confirm the log data was written to disk). The per-write synchronization part was unnecessary and, in fact, found to be possibly detrimental to performance and operating cost, so it was removed. Meanwhile, the log data continues to be flushed as previously, and CockroachDB periodically (i.e., every 30s) requests synchronization as previously. [#58996][#58996]
-
-<h3 id="v20-2-5-api-endpoint-changes">API endpoint changes</h3>
-
-- The health API now checks that the SQL server is ready to accept clients when a readiness check is requested. [#59383][#59383]
-
-<h3 id="v20-2-5-bug-fixes">Bug fixes</h3>
-
-- CockroachDB could previously return an internal error when evaluating a binary expression between a [`DECIMAL`](https://www.cockroachlabs.com/docs/v20.2/decimal) and an [`INTERVAL`](https://www.cockroachlabs.com/docs/v20.2/interval) that required a cast to a [`FLOAT`](https://www.cockroachlabs.com/docs/v20.2/float) when the value is out of range. Now a more user-friendly error is returned instead. [#58882][#58882]
-- Fixed a bug that caused errors when accessing a tuple column (`tuple.column` syntax) of a tuple that could be statically determined to be null. [#58896][#58896]
-- Fixed a nil pointer panic edge case in query setup code. [#59003][#59003]
-- Garbage collection jobs now populate the `running_status` column for [`SHOW JOBS`](https://www.cockroachlabs.com/docs/v20.2/show-jobs). [#59137][#59137]
-- Fixed a bug in which some non-conflicting rows provided as input to an [`INSERT ... ON CONFLICT DO NOTHING`](https://www.cockroachlabs.com/docs/v20.2/insert) statement could be discarded, and not inserted. This could happen in cases where the table had one or more [unique indexes](https://www.cockroachlabs.com/docs/v20.2/unique) in addition to the [primary index](https://www.cockroachlabs.com/docs/v20.2/primary-key), and some of the rows in the input conflicted with existing values in one or more unique indexes. This scenario could cause the rows that did not conflict to be erroneously discarded. [#59169][#59169]
-- Fixed a bug causing queries to hang when using large `max_decimal_digits` on [`ST_AsGeoJSON`](https://www.cockroachlabs.com/docs/v20.2/geojson). [#59167][#59167]
-- Improved the accuracy of reported CPU usage when running in containers. [#59184][#59184]
-- Fixed a nil pointer panic bug involving `catalog.FilterDescriptorState`. This bug affected all 20.2 versions since [v20.2.0]({% link releases/v20.2.md %}). [#58998][#58998]
-- Fixed a bug causing CockroachDB to encounter an internal error when executing queries with [`BYTES`](https://www.cockroachlabs.com/docs/v20.2/bytes) or [`STRING`](https://www.cockroachlabs.com/docs/v20.2/string) types via the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) in rare circumstances. [#59151][#59151]
-- Fixed a bug that initialized the GEOS library incorrectly, preventing multi-tenancy SQL pods from starting up correctly. [#59260][#59260]
-- Fixed a bug in the URL handling of HTTP external storage paths on Windows [#59267][#59267]
-- Fixed a bug causing CockroachDB to encounter an internal error when executing queries with tuples containing `NULL` values and [`ENUM`](https://www.cockroachlabs.com/docs/v20.2/enum)s in a distributed setting. [#59025][#59025]
-- Fixed a bug causing CockroachDB to crash when executing [`ALTER INDEX ... SPLIT/UNSPLIT AT`](https://www.cockroachlabs.com/docs/v20.2/alter-index) statements when more values were provided than explicitly specified in the index. [#59271][#59271]
-- Fixed a panic where type hints mismatching placeholder names caused a crash. [#59463][#59463]
-- Previously, CockroachDB did not pass a pointer to the bound account associated with the index backfiller. This would lead to incorrect memory accounting. This bug has been fixed. [#59475][#59475]
-- Previously, the `substring` [function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) on [`BYTES`](https://www.cockroachlabs.com/docs/v20.2/bytes) arrays would treat its input as unicode code points, which would cause the wrong bytes to be returned. Now it only operates on the raw bytes. [#59170][#59170]
-- Previously, the `substring(byte[])` [functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) were not able to interpret bytes that had the `\` character, as the functions were treating the character as the beginning of an escape sequence. This is now fixed. [#59170][#59170]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-5-contributors">Contributors</h3>
-
-This release includes 35 merged PRs by 21 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Cheng Jing (first-time contributor)
-
-</div>
-
-[#58882]: https://github.com/cockroachdb/cockroach/pull/58882
-[#58896]: https://github.com/cockroachdb/cockroach/pull/58896
-[#58996]: https://github.com/cockroachdb/cockroach/pull/58996
-[#58998]: https://github.com/cockroachdb/cockroach/pull/58998
-[#59003]: https://github.com/cockroachdb/cockroach/pull/59003
-[#59025]: https://github.com/cockroachdb/cockroach/pull/59025
-[#59137]: https://github.com/cockroachdb/cockroach/pull/59137
-[#59151]: https://github.com/cockroachdb/cockroach/pull/59151
-[#59167]: https://github.com/cockroachdb/cockroach/pull/59167
-[#59169]: https://github.com/cockroachdb/cockroach/pull/59169
-[#59170]: https://github.com/cockroachdb/cockroach/pull/59170
-[#59184]: https://github.com/cockroachdb/cockroach/pull/59184
-[#59260]: https://github.com/cockroachdb/cockroach/pull/59260
-[#59267]: https://github.com/cockroachdb/cockroach/pull/59267
-[#59271]: https://github.com/cockroachdb/cockroach/pull/59271
-[#59383]: https://github.com/cockroachdb/cockroach/pull/59383
-[#59463]: https://github.com/cockroachdb/cockroach/pull/59463
-[#59475]: https://github.com/cockroachdb/cockroach/pull/59475
-[#59503]: https://github.com/cockroachdb/cockroach/pull/59503
-[#59651]: https://github.com/cockroachdb/cockroach/pull/59651
-[#59776]: https://github.com/cockroachdb/cockroach/pull/59776
diff --git a/src/current/_includes/releases/v20.2/v20.2.6.md b/src/current/_includes/releases/v20.2/v20.2.6.md
deleted file mode 100644
index eceffc7bad4..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.6.md
+++ /dev/null
@@ -1,111 +0,0 @@
-## v20.2.6
-
-Release Date: March 15, 2021
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a63162.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-6-general-changes">General changes</h3>
-
-- `tar` is now included in the CockroachDB Dockerfile. This allows users to use `kubectl cp` on 20.2.x containers. [#61403][#61403] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-6-sql-language-changes">SQL language changes</h3>
-
-- Error messages for cross-database links now include a hint directing to the user to [the deprecation docs]({% link releases/v20.2.md %}#v20-2-0-deprecations). An example message looks like:  `ERROR: the view cannot refer to other databases; (see the 'sql.cross_db_views.enabled' cluster setting) SQLSTATE: 0A000 HINT: Note that cross database references will be removed in future releases. See: https://www.cockroachlabs.com/docs/releases/v21.1.html#deprecations` [#60009][#60009] {% comment %}doc{% endcomment %}
-- A new `parse_timestamp` [function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators) can now be used to parse absolute timestamp strings in [computed column](https://www.cockroachlabs.com/docs/v20.2/computed-columns) expressions or [partial index](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) predicates. [#60814][#60814] {% comment %}doc{% endcomment %}
-- Most batches of data flowing through the [vectorized execution engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) will now be limited in size by `sql.distsql.temp_storage.workmem` (64MiB by default) which should improve the stability of CockroachDB clusters. [#60571][#60571] {% comment %}doc{% endcomment %}
-- The `ST_Buffer` [spatial function](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#spatial-functions) now requires at least 1 quadrant segment. [#61360][#61360] {% comment %}doc{% endcomment %}
-- Prevented `densifyFracs` values of less than 1e-6 for `ST_FrechetDistance` and `ST_HausdorffDistance` [spatial functions](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#spatial-functions) to protect panics and out of memory errors. [#61434][#61434] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-6-command-line-changes">Command-line changes</h3>
-
-- The [`cockroach` command](https://www.cockroachlabs.com/docs/v20.2/cockroach-commands) now supports the command-line parameter `--version` which reports its version parameters. This makes `cockroach --version` equivalent to [`cockroach version`](https://www.cockroachlabs.com/docs/v20.2/cockroach-version). [#59753][#59753] {% comment %}doc{% endcomment %}
-- The [`cockroach version`](https://www.cockroachlabs.com/docs/v20.2/cockroach-version) command now supports a new parameter `--build-tag`. When `--build-tag` is specified, `cockroach version` displays the technical build tag, which makes it possible to integrate with automated deployment tools. [#59753][#59753] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-6-db-console-changes">DB Console changes</h3>
-
-- Manually enqueueing a range in the [GC queue](https://www.cockroachlabs.com/docs/v20.2/architecture/storage-layer#garbage-collection) now properly respects the `SkipShouldQueue` option. This can be useful to force the GC of a specific range. [#60745][#60745] {% comment %}doc{% endcomment %}
-
-<h3 id="v20-2-6-bug-fixes">Bug fixes</h3>
-
-- Re-enabled some file-level performance optimizations such as WAL preallocation and read-ahead that got inadvertently disabled in a past change. [#59825][#59825]
-- Previously if [`RELEASE SAVEPOINT cockroach_restart`](https://www.cockroachlabs.com/docs/v20.2/savepoint) was followed by [`ROLLBACK`](https://www.cockroachlabs.com/docs/v20.2/rollback-transaction), the `sql.txn.rollback.count` metric would be incremented. This was incorrect, since the transaction had already committed. That metric is no longer incremented in this case. [#60250][#60250]
-- Fixed a bug causing [backups](https://www.cockroachlabs.com/docs/v20.2/backup) to fail with an error when trying to read a backup that was written. [#59744][#59744]
-- Fixed a bug in the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) statistics code that could cause an unconstrained [partial index](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) scan to be preferred over a constrained scan of the same index. [#60517][#60517]
-- Fixed a bug that caused errors for some queries on tables with [`GEOMETRY` or `GEOGRAPHY` GIN indexes](https://www.cockroachlabs.com/docs/v20.2/spatial-indexes) with filters containing shapes with zero area. [#60599][#60599]
-- 20.2 introduced the ability to rebalance replicas between multiple stores on the same node. This change fixed a problem with that feature, where occasionally an intra-node rebalance would fail and a range would get stuck, permanently under-replicated. [#60633][#60633]
-- Fixed an internal error caused in some cases involving JSON objects and arrays in a `VALUES` clause. [#60808][#60808]
-- Previously, [retryable errors](https://www.cockroachlabs.com/docs/v20.2/transaction-retry-error-reference) in the cleanup phase of the type schema changer wouldn't be retried automatically in the background. This is now fixed. [#60817][#60817]
-- Fixed a bug that could report that a protected timestamp limit was exceeded when the limit was disabled, if an error were to occur while protecting a record. [#60960][#60960]
-- Previously, running [`DROP TYPE IF EXISTS`](https://www.cockroachlabs.com/docs/v20.2/drop-type) on one existent type and another non-existent type would cause an unhandled error. This is now fixed. [#60951][#60951]
-- Fixed a bug whereby high-latency global clusters could sometimes fall behind checkpointing resolved timestamps. [#60925][#60925]
-- CockroachDB previously didn't account for some RAM used when [disk-spilling operations](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution#disk-spilling-operations) (like sorts and hash joins) were using the temporary storage in the vectorized execution engine. This could result in out-of-memory crashes, especially when the rows are large in size. [#61016][#61016]
-- Fixed execution errors for some queries that use set operations (`UNION` / `EXCEPT` / `INTERSECT`) where a column has types of different widths on the two sides (e.g., `INT4` vs `INT8`). [#61086][#61086]
-- Unexpected internal errors containing stack traces that reference a `countingWriter` nil pointer have now been fixed. [#61072][#61072]
-- Made lease transfers during rebalancing adhere to the rate limit utilized in other lease transfer cases, which eliminates unexpected lease oscillations when adding a new node. [#61038][#61038]
-- Previously, comparing a negative [integer](https://www.cockroachlabs.com/docs/v20.2/int) to an OID would fail to compare correctly because the integer was not converted to an unsigned representation first. This is now fixed for both comparisons and casts. [#61166][#61166]
-- The [`SHOW CREATE`](https://www.cockroachlabs.com/docs/v20.2/show-create) output of a [partitioned](https://www.cockroachlabs.com/docs/v20.2/partition-by) [partial index](https://www.cockroachlabs.com/docs/v20.2/partial-indexes) now lists the `PARTITION BY` and `WHERE` clauses in the order accepted by the parser. The `SHOW CREATE` output of a partial interleaved index also now lists the `INTERLEAVED` and `WHERE` clauses in the order accepted by the parser. [#61104][#61104]
-- Fixed a bug causing [schema changes](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes) on databases and schemas to panic in 20.2 if they failed or were cancelled and entered the reverting state. These jobs are not actually possible to revert. With this change, the correct error causing the job to fail is now returned, and the job now enters the failed state with an error indicating that the job could not be reverted. [#61160][#61160]
-- The [`SHOW TABLES FROM database`](https://www.cockroachlabs.com/docs/v20.2/show-tables) command no longer shows a `NULL estimated_row_count` if inspecting a database that is not the current database. [#61200][#61200]
-- Fixed a bug in `crdb_internal.unsafe_upsert_namespace_entry` related to tables and types in [user-defined schemas](https://www.cockroachlabs.com/docs/v20.2/create-schema). [#61260][#61260]
-- Fixed a bug that prevented renaming a column that was referenced earlier in a transaction as part of a computed expression, index predicate, check expression, or not null constraint. [#61257][#61257]
-- [Schema change jobs](https://www.cockroachlabs.com/docs/v20.2/online-schema-changes) associated with databases and schemas can no longer be canceled. Such jobs cannot actually be reverted successfully, so cancellation had no benefit and could have caused namespace corruption. [#61254][#61254]
-- Fixed a bug with multi-store nodes where concurrent node startups could result in the re-use of store IDs. This could manifest in many different ways (e.g., replica thrashing due to the store ID collision). [#61262][#61262]
-- Fixed a bug where [`DROP SCHEMA ... CASCADE`](https://www.cockroachlabs.com/docs/v20.2/drop-schema) could result in referenced types being dropped. [#61259][#61259]
-- Fixed a bug whereby dropping a schema with a table that used a [user-defined type](https://www.cockroachlabs.com/docs/v20.2/create-type) which was not being dropped (because it is in a different schema) would result in a descriptor corruption due to a dangling back-reference to a dropped table on the type descriptor. [#61259][#61259]
-- Fixed an internal error causing [`EXPLAIN`](https://www.cockroachlabs.com/docs/v20.2/explain) statements on an [`INSERT`](https://www.cockroachlabs.com/docs/v20.2/insert) with an input that was determined by the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer) to produce no rows. [#61312][#61312]
-- [`ALTER TYPE ... ADD VALUE`](https://www.cockroachlabs.com/docs/v20.2/alter-type) changes are now picked up by the [`ARRAY`](https://www.cockroachlabs.com/docs/v20.2/array) type alias correctly. [#61350][#61350]
-- Creating [interleaved](https://www.cockroachlabs.com/docs/v20.2/interleave-in-parent) partitioned indexes is now disallowed. Previously, the database would crash when trying to create one. [#61422][#61422]
-- A bug which caused [`UPSERT`](https://www.cockroachlabs.com/docs/v20.2/upsert) and [`INSERT ... ON CONFLICT ... DO UPDATE`](https://www.cockroachlabs.com/docs/v20.2/insert) statements to fail on tables with both partial indexes and [foreign key references](https://www.cockroachlabs.com/docs/v20.2/foreign-key) has been fixed. This bug has been present since version 20.2.0. [#61489][#61489]
-- An [`UPDATE ... FROM`](https://www.cockroachlabs.com/docs/v20.2/update) statement where the `FROM` clause contained column names that matched table column names previously returned an error if the table had a partial index predicate referencing those columns. This bug, present since partial indexes were released in version 20.2.0, has been fixed. [#61557][#61557]
-- Fixed a bug causing an invalid tuple comparison using `ANY` to raise an internal error. In this case, CockroachDB now returns "unsupported comparison operator". [#61658][#61658]
-
-<h3 id="v20-2-6-performance-improvements">Performance improvements</h3>
-
-- Enabled some file-level optimizations such as WAL preallocation and read-ahead when encryption-at-rest is used. [#59825][#59825]
-- Improved the [optimizer](https://www.cockroachlabs.com/docs/v20.2/cost-based-optimizer)'s cost estimation of [index](https://www.cockroachlabs.com/docs/v20.2/indexes) scans that must visit multiple [partitions](https://www.cockroachlabs.com/docs/v20.2/partition-by). When an index has multiple partitions, the optimizer is now more likely to choose a constrained scan rather than a full index scan. This can lead to better plans and improved performance. It also improves the ability of the database to serve queries if one of the partitions is unavailable. [#61069][#61069]
-
-<h3 id="v20-2-6-contributors">Contributors</h3>
-
-This release includes 52 merged PRs by 25 authors.
-
-[#59744]: https://github.com/cockroachdb/cockroach/pull/59744
-[#59753]: https://github.com/cockroachdb/cockroach/pull/59753
-[#59825]: https://github.com/cockroachdb/cockroach/pull/59825
-[#60009]: https://github.com/cockroachdb/cockroach/pull/60009
-[#60250]: https://github.com/cockroachdb/cockroach/pull/60250
-[#60517]: https://github.com/cockroachdb/cockroach/pull/60517
-[#60571]: https://github.com/cockroachdb/cockroach/pull/60571
-[#60599]: https://github.com/cockroachdb/cockroach/pull/60599
-[#60633]: https://github.com/cockroachdb/cockroach/pull/60633
-[#60745]: https://github.com/cockroachdb/cockroach/pull/60745
-[#60808]: https://github.com/cockroachdb/cockroach/pull/60808
-[#60814]: https://github.com/cockroachdb/cockroach/pull/60814
-[#60817]: https://github.com/cockroachdb/cockroach/pull/60817
-[#60925]: https://github.com/cockroachdb/cockroach/pull/60925
-[#60951]: https://github.com/cockroachdb/cockroach/pull/60951
-[#60960]: https://github.com/cockroachdb/cockroach/pull/60960
-[#61016]: https://github.com/cockroachdb/cockroach/pull/61016
-[#61038]: https://github.com/cockroachdb/cockroach/pull/61038
-[#61069]: https://github.com/cockroachdb/cockroach/pull/61069
-[#61072]: https://github.com/cockroachdb/cockroach/pull/61072
-[#61086]: https://github.com/cockroachdb/cockroach/pull/61086
-[#61104]: https://github.com/cockroachdb/cockroach/pull/61104
-[#61160]: https://github.com/cockroachdb/cockroach/pull/61160
-[#61166]: https://github.com/cockroachdb/cockroach/pull/61166
-[#61200]: https://github.com/cockroachdb/cockroach/pull/61200
-[#61254]: https://github.com/cockroachdb/cockroach/pull/61254
-[#61257]: https://github.com/cockroachdb/cockroach/pull/61257
-[#61259]: https://github.com/cockroachdb/cockroach/pull/61259
-[#61260]: https://github.com/cockroachdb/cockroach/pull/61260
-[#61262]: https://github.com/cockroachdb/cockroach/pull/61262
-[#61312]: https://github.com/cockroachdb/cockroach/pull/61312
-[#61350]: https://github.com/cockroachdb/cockroach/pull/61350
-[#61360]: https://github.com/cockroachdb/cockroach/pull/61360
-[#61403]: https://github.com/cockroachdb/cockroach/pull/61403
-[#61422]: https://github.com/cockroachdb/cockroach/pull/61422
-[#61434]: https://github.com/cockroachdb/cockroach/pull/61434
-[#61489]: https://github.com/cockroachdb/cockroach/pull/61489
-[#61557]: https://github.com/cockroachdb/cockroach/pull/61557
-[#61658]: https://github.com/cockroachdb/cockroach/pull/61658
diff --git a/src/current/_includes/releases/v20.2/v20.2.7.md b/src/current/_includes/releases/v20.2/v20.2.7.md
deleted file mode 100644
index b22e9d6419e..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.7.md
+++ /dev/null
@@ -1,66 +0,0 @@
-## v20.2.7
-
-Release Date: March 29, 2021
-
-{{site.data.alerts.callout_danger}}
-{% include /v20.2/alerts/warning-a63162.md %}
-{{site.data.alerts.end}}
-
-<h3 id="v20-2-7-sql-language-changes">SQL language changes</h3>
-
-- The following [cluster settings](https://www.cockroachlabs.com/docs/v20.2/cluster-settings) were added or changed:
-  - `sql.defaults.statement_timeout` was added to control the default value for the `statement_timeout` session setting.
-  - `sql.defaults.idle_in_transaction_session_timeout` was added to control the default value for the `idle_in_transaction_session_timeout` timeout setting.
-  - `sql.defaults.idle_in_session_timeout` is now a public cluster setting. [#62185][#62185]
-
-<h3 id="v20-2-7-bug-fixes">Bug fixes</h3>
-
-- Previously, [changefeeds](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) were checking the `SELECT` privilege on every descriptor associated with targeted tables, including the database and custom types. They now only check `SELECT` on the targeted tables. [#61661][#61661]
-- The names of custom types are no longer sent to Cockroach Labs in telemetry and crash reports. [#61645][#61645]
-- Fixed a bug where some import failures would cause tables to stay `OFFLINE` when they should have been brought back to `PUBLIC`. [#61480][#61480]
-- Fixed a runtime error observed with a `SpanFromContext` call in the stack trace. [#61703][#61703]
-- Exporting data to userfile locations now works correctly. [#61789][#61789]
-- The `indexdef` column in the `pg_indexes` table would always report that the index belonged to the public schema. Now it correctly reports user-defined schemas if necessary. [#61753][#61753]
-- Previously, when using `SHOW`, the `idle_in_session_timeout` and `idle_in_transaction_session_timeout` settings would incorrectly display the value of the `statement_timeout` setting. This is now fixed. [#61958][#61958]
-- Fixed a bug where random numbers generated as default expressions during an [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import) would be likely to match (collide with) other generated values in the same column. [#61630][#61630]
-- Previously, using [`EXPLAIN (OPT, ENV)`](https://www.cockroachlabs.com/docs/v20.2/explain) would fail when used on a query that referenced a table in a user-defined schema. This is now fixed. [#61890][#61890]
-- Fixed a bug that caused `column does not exist` errors in specific cases of [`UPDATE ... FROM`](https://www.cockroachlabs.com/docs/v20.2/update) statements. The error occurred when updating a `DECIMAL` column to a column in the `FROM` clause where the column had a `CHECK` constraint or was referenced by a partial index predicate. [#61953][#61953]
-- Fixed `command is too large` errors in some cases when using [`EXPLAIN ANALYZE (DEBUG)`](https://www.cockroachlabs.com/docs/v20.2/explain-analyze) or statement diagnostics on complex queries. [#61910][#61910]
-- Previously, the `target` column of `crdb_internal.zones` would show names without properly accounting for user-defined schemas. This is now fixed. [#62019][#62019]
-- Dropping and recreating a view/table/sequence in a transaction will now correctly error out if a conflicting object exists or if the drop is incomplete. [#62343][#62343]
-- Fixed a bug that sometimes caused queries sent to a freshly restarted node to hang for a long time while the node caught up with replication. [#62204][#62204]
-- Previously, the `pg_type_is_visible` [built-in](https://www.cockroachlabs.com/docs/v20.2/functions-and-operators#built-in-functions) function did not correctly handle user-defined types. This is now fixed. [#62231][#62231]
-- Fix a bug where [full cluster restore](https://www.cockroachlabs.com/docs/v20.2/restore#full-cluster) would sometimes (very rarely) fail after retrying. [#61217][#61217]
-- Fixed a bug where an enum with large numbers of values might cause unexpected errors when attempting to read from tables with columns using that enum. [#62211][#62211]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-7-contributors">Contributors</h3>
-
-This release includes 29 merged PRs by 15 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Tharun (first-time contributor)
-
-</div>
-
-[#61217]: https://github.com/cockroachdb/cockroach/pull/61217
-[#61480]: https://github.com/cockroachdb/cockroach/pull/61480
-[#61603]: https://github.com/cockroachdb/cockroach/pull/61603
-[#61630]: https://github.com/cockroachdb/cockroach/pull/61630
-[#61645]: https://github.com/cockroachdb/cockroach/pull/61645
-[#61661]: https://github.com/cockroachdb/cockroach/pull/61661
-[#61703]: https://github.com/cockroachdb/cockroach/pull/61703
-[#61753]: https://github.com/cockroachdb/cockroach/pull/61753
-[#61789]: https://github.com/cockroachdb/cockroach/pull/61789
-[#61890]: https://github.com/cockroachdb/cockroach/pull/61890
-[#61910]: https://github.com/cockroachdb/cockroach/pull/61910
-[#61953]: https://github.com/cockroachdb/cockroach/pull/61953
-[#61958]: https://github.com/cockroachdb/cockroach/pull/61958
-[#62019]: https://github.com/cockroachdb/cockroach/pull/62019
-[#62185]: https://github.com/cockroachdb/cockroach/pull/62185
-[#62204]: https://github.com/cockroachdb/cockroach/pull/62204
-[#62211]: https://github.com/cockroachdb/cockroach/pull/62211
-[#62231]: https://github.com/cockroachdb/cockroach/pull/62231
-[#62343]: https://github.com/cockroachdb/cockroach/pull/62343
-[91048a186]: https://github.com/cockroachdb/cockroach/commit/91048a186
diff --git a/src/current/_includes/releases/v20.2/v20.2.8.md b/src/current/_includes/releases/v20.2/v20.2.8.md
deleted file mode 100644
index 21c8d4e9cb4..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.8.md
+++ /dev/null
@@ -1,91 +0,0 @@
-## v20.2.8
-
-Release Date: April 23, 2021
-
-<h3 id="v20-2-8-sql-language-changes">SQL language changes</h3>
-
-- [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) now re-validates restored indexes if they were restored from an incremental backup that was taken while the index was being created. [#63314][#63314]
-- Fixed an `ST_Segmentize` panic when the number of segments to generate exceeded `math.MaxInt64`. [#63759][#63759]
-
-<h3 id="v20-2-8-operational-changes">Operational changes</h3>
-
-- Added a new setting to set the garbage collector intent age threshold: `kv.gc.intent_age_threshold`. [#62788][#62788]
-
-<h3 id="v20-2-8-db-console-changes">DB Console changes</h3>
-
-- Fixed duplicates of statements on the [**Transaction Details** page](https://www.cockroachlabs.com/docs/v20.2/ui-transactions-page) for multi-node clusters. [#62797][#62797]
-
-<h3 id="v20-2-8-bug-fixes">Bug fixes</h3>
-
-- The `kv.closed_timestamp.target_duration` setting set to `0` will now disable routing requests to follower replicas. [#62441][#62441]
-- Added support for usernames with special characters to [`cockroach userfile`](https://www.cockroachlabs.com/docs/v20.2/use-userfile-for-bulk-operations). [#60020][#60020]
-- Fixed an internal error that could occur during planning for queries involving tables with many columns and at least one [GIN index](https://www.cockroachlabs.com/docs/v20.2/inverted-indexes). The error, `"estimated distinct count must be non-zero"`, was caused by an invalid pointer access in the cardinality estimation code. [#62561][#62561]
-- Fixed an error where writing files to [`cockroach userfile`](https://www.cockroachlabs.com/docs/v20.2/use-userfile-for-bulk-operations) would sometimes result in an error claiming that the userfile table already existed. [#62547][#62547]
-- Fixed a deficiency in the [replication layer](https://www.cockroachlabs.com/docs/v20.2/architecture/replication-layer) that could result in ranges becoming unavailable for prolonged periods of time (hours) when a write burst occurred under system overload. While unavailable, the range status page for the affected range would show a last index much larger than the committed index and no movement in these indexes on a quorum of the replicas. Note that this should be distinguished from the case in which enough replicas are offline to constitute a loss of quorum, where the replication layer can not make progress due to the loss of quorum itself. [#61848][#61848]
-- Fixed a bug where tables that were created by CockroachDB v19.x or older that included [foreign key constraints](https://www.cockroachlabs.com/docs/v20.2/foreign-key) and were [backed up](https://www.cockroachlabs.com/docs/v20.2/backup) with the 'revision_history' option would be malformed when restored by a v20.x cluster if the call to [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) used the [`AS OF SYSTEM TIME`](https://www.cockroachlabs.com/docs/v20.2/as-of-system-time) option. [#62600][#62600]
-- Fixed `"types cannot be matched for WITH RECURSIVE"` error in cases where we can cast the type in the initial expression. [#62825][#62825]
-- Fixed an error where CockroachDB could encounter an internal error in rare circumstances when executing queries via the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) that operate on columns of [`BOOL`](https://www.cockroachlabs.com/docs/v20.2/bool), [`BYTES`](https://www.cockroachlabs.com/docs/v20.2/bytes), [`INT`](https://www.cockroachlabs.com/docs/v20.2/int), and [`FLOAT`](https://www.cockroachlabs.com/docs/v20.2/float) types that have a mix of _NULL_ and non-_NULL_ values. [#62916][#62916]
-- Fixed a rare bug that could cause a node to consume excessive CPU and become unresponsive. [#62907][#62907]
-- Fixed an internal error that could occur during planning when a query used the output of an [`UPDATE`](https://www.cockroachlabs.com/docs/v20.2/update)'s `RETURNING` clause, and one or more of the columns in the `RETURNING` clause were from a table specified in the `FROM` clause of the `UPDATE` (i.e., not from the table being updated). [#62961][#62961]
-- Queries that reference tables with `GEOMETRY` or `GEOGRAPHY` [GIN indexes](https://www.cockroachlabs.com/docs/v20.2/spatial-indexes) and that call [geospatial functions](https://www.cockroachlabs.com/docs/v20.2/spatial-features) with constant `NULL` values cast to a type, like `NULL::GEOMETRY` or `NULL::FLOAT8`, no longer error. This bug was present since v20.2. [#63005][#63005]
-- Dropping a [foreign key](https://www.cockroachlabs.com/docs/v20.2/foreign-key) that was added in the same transaction no longer triggers an internal error. This bug has been present since at least version v20.1. [#62880][#62880]
-- Fixed a rare error `"unexpected type *tree.DOidWrapper for AsJSON"`. [#63232][#63232]
-- Fixed a bug where index backfill data may have been missed by [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) in incremental backups. [#63265][#63265]
-- Fixed a bug where lease acquisitions of descriptors in an offline state may starve out bulk operations such [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup) or [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore). [#63229][#63229]
-- Fixed a bug in [user-defined schemas](https://www.cockroachlabs.com/docs/v20.2/create-schema) whereby the dropping of any schema may prevent creation of schemas with the name of the database and may corrupt existing schemas of that name. [#63397][#63397]
-- [Incremental cluster backups](https://www.cockroachlabs.com/docs/v20.2/take-full-and-incremental-backups) may have missed data written to tables while they were `OFFLINE`. In practice, this could happen if [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) or [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import) were running across incremental backups. This has now been fixed. [#63392][#63392]
-- Fixed a rare issue that could cause replica divergence. These issues would be reported by the replica consistency checker, typically within 24 hours of occurrence, which would cause nodes to terminate. [#63474][#63474]
-- CockroachDB now uses the existing primary key to validate indexes built for [`ALTER PRIMARY KEY`](https://www.cockroachlabs.com/docs/v20.2/alter-primary-key) changes. [#63585][#63585]
-- Fixed an index out of range error that could occur when `crdb_internal_mvcc_timestamp` was selected as part of a [view](https://www.cockroachlabs.com/docs/v20.2/views). It is now possible to select `crdb_internal_mvcc_timestamp` as part of a view as long as it is aliased with a different name. [#63630][#63630]
-- Error gracefully when attempting to run `ST_Segmentize` and generating more than `MaxInt64` points on a `GEOGRAPHY`. [#63759][#63759]
-- Fixed a bug which could cause errors in [`DROP DATABASE CASCADE`](https://www.cockroachlabs.com/docs/v20.2/drop-database) when the database contained temporary views in other sessions which were not explicitly marked as `TEMPORARY`. [#63781][#63781]
-- Fixed an internal error that could occur when executing queries using a [GIN index](https://www.cockroachlabs.com/docs/v20.2/inverted-indexes). The error was an index out of range error, and could occur in rare cases when a filter or join predicate contained at least two [`JSON`](https://www.cockroachlabs.com/docs/v20.2/jsonb), [`ARRAY`](https://www.cockroachlabs.com/docs/v20.2/array), `GEOMETRY` or `GEOGRAPHY` expressions that were combined with `AND`. [#63826][#63826]
-- [`IMPORT`](https://www.cockroachlabs.com/docs/v20.2/import) and [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) jobs are now restored as reverting so that they clean up after themselves. Previously, some of the writes of the jobs while they were running may have been missed by [`BACKUP`](https://www.cockroachlabs.com/docs/v20.2/backup). [#63765][#63765]
-
-<h3 id="v20-2-8-performance-improvements">Performance improvements</h3>
-
-- Improved logic in determining the configuration for data to avoid expensive work when there are a large number of [user-defined schemas](https://www.cockroachlabs.com/docs/v20.2/create-schema). [#62356][#62356]
-- Improved performance of reverting [`IMPORT INTO`](https://www.cockroachlabs.com/docs/v20.2/import-into) jobs that import into empty tables. [#63224][#63224]
-
-<h3 id="v20-2-8-change-data-capture">Change Data Capture</h3>
-
-- Kafka and [cloud storage sinks](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds#create-a-changefeed-connected-to-a-cloud-storage-sink) use a memory monitor to limit the amount of memory that can be used in internal buffers. [#63633][#63633]
-- Connected the [changefeed](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) memory monitor to the parent SQL monitor to ensure that changefeeds do not try to use more memory than is available to the SQL server. [#63410][#63410]
-- Made the Kafka library used in [changefeeds](https://www.cockroachlabs.com/docs/v20.2/stream-data-out-of-cockroachdb-using-changefeeds) configurable via the `kafka_sink_config` option to enable latency vs. throughput configuration. [#63362][#63362]
-
-<h3 id="v20-2-8-contributors">Contributors</h3>
-
-This release includes 45 merged PRs by 22 authors.
-
-[#60020]: https://github.com/cockroachdb/cockroach/pull/60020
-[#61848]: https://github.com/cockroachdb/cockroach/pull/61848
-[#62356]: https://github.com/cockroachdb/cockroach/pull/62356
-[#62441]: https://github.com/cockroachdb/cockroach/pull/62441
-[#62547]: https://github.com/cockroachdb/cockroach/pull/62547
-[#62561]: https://github.com/cockroachdb/cockroach/pull/62561
-[#62600]: https://github.com/cockroachdb/cockroach/pull/62600
-[#62788]: https://github.com/cockroachdb/cockroach/pull/62788
-[#62797]: https://github.com/cockroachdb/cockroach/pull/62797
-[#62825]: https://github.com/cockroachdb/cockroach/pull/62825
-[#62880]: https://github.com/cockroachdb/cockroach/pull/62880
-[#62907]: https://github.com/cockroachdb/cockroach/pull/62907
-[#62916]: https://github.com/cockroachdb/cockroach/pull/62916
-[#62961]: https://github.com/cockroachdb/cockroach/pull/62961
-[#63005]: https://github.com/cockroachdb/cockroach/pull/63005
-[#63224]: https://github.com/cockroachdb/cockroach/pull/63224
-[#63229]: https://github.com/cockroachdb/cockroach/pull/63229
-[#63232]: https://github.com/cockroachdb/cockroach/pull/63232
-[#63265]: https://github.com/cockroachdb/cockroach/pull/63265
-[#63314]: https://github.com/cockroachdb/cockroach/pull/63314
-[#63362]: https://github.com/cockroachdb/cockroach/pull/63362
-[#63392]: https://github.com/cockroachdb/cockroach/pull/63392
-[#63397]: https://github.com/cockroachdb/cockroach/pull/63397
-[#63410]: https://github.com/cockroachdb/cockroach/pull/63410
-[#63474]: https://github.com/cockroachdb/cockroach/pull/63474
-[#63585]: https://github.com/cockroachdb/cockroach/pull/63585
-[#63630]: https://github.com/cockroachdb/cockroach/pull/63630
-[#63633]: https://github.com/cockroachdb/cockroach/pull/63633
-[#63759]: https://github.com/cockroachdb/cockroach/pull/63759
-[#63765]: https://github.com/cockroachdb/cockroach/pull/63765
-[#63781]: https://github.com/cockroachdb/cockroach/pull/63781
-[#63826]: https://github.com/cockroachdb/cockroach/pull/63826
diff --git a/src/current/_includes/releases/v20.2/v20.2.9.md b/src/current/_includes/releases/v20.2/v20.2.9.md
deleted file mode 100644
index b576aea0a20..00000000000
--- a/src/current/_includes/releases/v20.2/v20.2.9.md
+++ /dev/null
@@ -1,77 +0,0 @@
-## v20.2.9
-
-Release Date: May 10, 2021
-
-This page lists additions and changes in v20.2.9 since v20.2.8.
-
-<h3 id="v20-2-9-sql-language-changes">SQL language changes</h3>
-
-- Prior to this change, `st_simplify` with `NaN` caused a node to crash. The behavior has been changed to align with PostGIS. [#63798][#63798]
-- Validation queries that run on behalf of schema changes, such as [foreign key](https://www.cockroachlabs.com/docs/v20.2/foreign-key) validations, [unique constraint](https://www.cockroachlabs.com/docs/v20.2/unique) validations, and [check constraint](https://www.cockroachlabs.com/docs/v20.2/check) validations, will now use the [vectorized engine](https://www.cockroachlabs.com/docs/v20.2/vectorized-execution) and DistSQL distribution based on the defaults set in the cluster settings. This may speed up validation queries. [#64005][#64005]
-- [`TRUNCATE`](https://www.cockroachlabs.com/docs/v20.2/truncate) is now less disruptive on tables with a lot of concurrent traffic. [#64445][#64445]
-
-<h3 id="v20-2-9-bug-fixes">Bug fixes</h3>
-
-- Fixed a correctness bug which caused partitioned index scans to omit rows where the value of the first index column was `NULL`. This bug was present since v19.2.0. [#64049][#64049]
-- Fixed a bug where multiple concurrent invocations of [`cockroach debug zip`](https://www.cockroachlabs.com/docs/v20.2/cockroach-debug-zip) could result in cluster instability. This bug had been present since CockroachDB v20.1. [#64084][#64084]
-- Fixed a rare bug which could cause a crash if [`CREATE SCHEMA`](https://www.cockroachlabs.com/docs/v20.2/create-schema) were run in a transaction which began prior to a cluster version update which enabled that statement. [#63786][#63786]
-- Fixed a race condition where read-only requests during replica removal (e.g., during range merges or rebalancing) could be evaluated on the removed replica, returning an empty result. [#64375][#64375]
-- Fixed a bug where [encryption-at-rest](https://www.cockroachlabs.com/docs/v20.2/encryption#encryption-at-rest-enterprise) metadata was not synced and might become corrupted during a hard reset. [#64496][#64496]
-- Fixed a panic which could occur in cases after a [`RESTORE`](https://www.cockroachlabs.com/docs/v20.2/restore) of a table using user-defined types. [#63550][#63550]
-- Fixed bugs where [`TRUNCATE`](https://www.cockroachlabs.com/docs/v20.2/truncate) concurrent with index construction and other schema changes could result in corruption. [#63153][#63153]
-- Fixed a bug where upon failure of the [`CREATE TABLE AS`](https://www.cockroachlabs.com/docs/v20.2/create-table-as) or `CREATE MATERIALIZED VIEW` statements, tables would be left in an invalid non-public state until GC instead of being marked as dropped, possibly causing spurious validation failures. The bug was introduced in earlier v20.2 testing releases. [#63987][#63987]
-- Fixed `crdb_internal.encode_key` for user-defined types. This would previously return an error. [#64031][#64031]
-- Fixed a theoretical issue in index backfills that could result in stale entries that would likely fail validation. [#64045][#64045]
-- Fixed a bug where CockroachDB would either return an error or crash when comparing an infinite date coming from a subquery against a timestamp. [#64075][#64075]
-- The [`CREATE STATISTICS`](https://www.cockroachlabs.com/docs/v20.2/create-statistics) statement no longer fails when creating statistics on a table with a partial index predicate containing references to an inverted-type column, such as `JSON`, `ARRAY`, `GEOMETRY`, or `GEOGRAPHY`. This bug was present since partial indexes were introduced in v20.2.0. [#64226][#64226]
-- Fixed an issue where store information would be incorrectly redacted from the CockroachDB logs, when configured with redaction. [#64333][#64333]
-- Previously, passwords in SQL statements in telemetry updates and crash reports were anonymized as `*****`. Passwords are now anonymized as `'*****'` so that the SQL statements do not result in parsing errors when executed. [#64345][#64345]
-- Previously, the remote flows of execution in the vectorized engine could take quite a long time to shut down whenever a node participating in the plan dies. This has been fixed. [#64220][#64220]
-- CockroachDB now correctly accounts for used memory when closing compressed files. [#63916][#63916]
-
-<h3 id="v20-2-9-performance-improvements">Performance improvements</h3>
-
-- Certain queries containing `<tuple> IN (<subquery>)` conditions may run significantly faster. [#63869][#63869]
-- The Raft processing goroutine pool's size is now capped at 96. This was observed to prevent instability on large machines (32+ vCPU) in clusters with many ranges (50k+ per node). [#64567][#64567]
-- The Raft scheduler now prioritizes the node liveness Range. This was observed to prevent instability on large machines (32+ vCPU) in clusters with many ranges (50k+ per node). [#64567][#64567]
-- Reduced memory usage in some write-heavy workloads. Improved write performance when a lot of files are being deleted. Addressed one case where too many small sstable files were generated. [#64599][#64599]
-
-<h3 id="v20-2-9-build-changes">Build changes</h3>
-
-- CockroachDB now builds on Ubuntu 20.10 and other distros using gcc-10. [#62201][#62201]
-
-<div class="release-note-contributors" markdown="1">
-
-<h3 id="v20-2-9-contributors">Contributors</h3>
-
-This release includes 35 merged PRs by 22 authors.
-We would like to thank the following contributors from the CockroachDB community:
-
-- Rupesh Harode (first-time contributor)
-
-</div>
-
-[#62201]: https://github.com/cockroachdb/cockroach/pull/62201
-[#63153]: https://github.com/cockroachdb/cockroach/pull/63153
-[#63550]: https://github.com/cockroachdb/cockroach/pull/63550
-[#63786]: https://github.com/cockroachdb/cockroach/pull/63786
-[#63798]: https://github.com/cockroachdb/cockroach/pull/63798
-[#63869]: https://github.com/cockroachdb/cockroach/pull/63869
-[#63916]: https://github.com/cockroachdb/cockroach/pull/63916
-[#63987]: https://github.com/cockroachdb/cockroach/pull/63987
-[#64005]: https://github.com/cockroachdb/cockroach/pull/64005
-[#64031]: https://github.com/cockroachdb/cockroach/pull/64031
-[#64045]: https://github.com/cockroachdb/cockroach/pull/64045
-[#64049]: https://github.com/cockroachdb/cockroach/pull/64049
-[#64075]: https://github.com/cockroachdb/cockroach/pull/64075
-[#64084]: https://github.com/cockroachdb/cockroach/pull/64084
-[#64185]: https://github.com/cockroachdb/cockroach/pull/64185
-[#64220]: https://github.com/cockroachdb/cockroach/pull/64220
-[#64226]: https://github.com/cockroachdb/cockroach/pull/64226
-[#64333]: https://github.com/cockroachdb/cockroach/pull/64333
-[#64345]: https://github.com/cockroachdb/cockroach/pull/64345
-[#64375]: https://github.com/cockroachdb/cockroach/pull/64375
-[#64445]: https://github.com/cockroachdb/cockroach/pull/64445
-[#64496]: https://github.com/cockroachdb/cockroach/pull/64496
-[#64567]: https://github.com/cockroachdb/cockroach/pull/64567
-[#64599]: https://github.com/cockroachdb/cockroach/pull/64599
diff --git a/src/current/_includes/sidebar-data-v20.2.json b/src/current/_includes/sidebar-data-v20.2.json
deleted file mode 100644
index f129998349c..00000000000
--- a/src/current/_includes/sidebar-data-v20.2.json
+++ /dev/null
@@ -1,2815 +0,0 @@
-[
-  {
-    "title": "Docs Home",
-    "is_top_level": true,
-    "urls": [
-      "/"
-    ]
-  },
-  {
-    "title": "Quickstart",
-    "is_top_level": true,
-    "urls": [
-      "/cockroachcloud/quickstart.html",
-      "/cockroachcloud/quickstart-trial-cluster.html"
-    ]
-  },
-  {% include_cached sidebar-data-cockroachcloud.json %},
-  {
-    "title": "CockroachDB",
-    "is_top_level": true,
-    "urls": [
-      "/${VERSION}/index.html"
-    ],
-    "items": [
-      {
-        "title": "Get Started",
-        "items": [
-          {
-            "title": "Install CockroachDB",
-            "urls": [
-              "/${VERSION}/install-cockroachdb.html",
-              "/${VERSION}/install-cockroachdb-mac.html",
-              "/${VERSION}/install-cockroachdb-linux.html",
-              "/${VERSION}/install-cockroachdb-windows.html"
-            ]
-          },
-          {
-            "title": "Start a Local Cluster",
-            "items": [
-              {
-                "title": "From Binary",
-                "urls": [
-                  "/${VERSION}/secure-a-cluster.html",
-                  "/${VERSION}/start-a-local-cluster.html"
-                ]
-              },
-              {
-                "title": "In Kubernetes",
-                "urls": [
-                  "/${VERSION}/orchestrate-a-local-cluster-with-kubernetes.html",
-                  "/${VERSION}/orchestrate-a-local-cluster-with-kubernetes-insecure.html"
-                ]
-              },
-              {
-                "title": "In Docker",
-                "urls": [
-                  "/${VERSION}/start-a-local-cluster-in-docker-mac.html",
-                  "/${VERSION}/start-a-local-cluster-in-docker-linux.html",
-                  "/${VERSION}/start-a-local-cluster-in-docker-windows.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Learn CockroachDB SQL",
-            "urls": [
-              "/${VERSION}/learn-cockroachdb-sql.html"
-            ]
-          },
-          {
-            "title": "Explore Database Features",
-            "items": [
-              {
-                "title": "Replication & Rebalancing",
-                "urls": [
-                  "/${VERSION}/demo-replication-and-rebalancing.html"
-                ]
-              },
-              {
-                "title": "Fault Tolerance & Recovery",
-                "urls": [
-                  "/${VERSION}/demo-fault-tolerance-and-recovery.html"
-                ]
-              },
-              {
-                "title": "Multi-Region Topologies",
-                "urls": [
-                  "/${VERSION}/demo-low-latency-multi-region-deployment.html"
-                ]
-              },
-              {
-                "title": "Serializable Transactions",
-                "urls": [
-                  "/${VERSION}/demo-serializable.html"
-                ]
-              },
-              {
-                "title": "Spatial Data",
-                "urls": [
-                  "/${VERSION}/spatial-tutorial.html"
-                ]
-              },
-              {
-                "title": "Cross-Cloud Migration",
-                "urls": [
-                  "/${VERSION}/demo-automatic-cloud-migration.html"
-                ]
-              },
-              {
-                "title": "Orchestration with Kubernetes",
-                "urls": [
-                  "/${VERSION}/orchestrate-a-local-cluster-with-kubernetes.html"
-                ]
-              },
-              {
-                "title": "JSON Support",
-                "urls": [
-                  "/${VERSION}/demo-json-support.html"
-                ]
-              },
-              {
-                "title": "SQL Tuning with <code>EXPLAIN</code>",
-                "urls": [
-                  "/${VERSION}/sql-tuning-with-explain.html"
-                ]
-              }
-            ]
-          }
-        ]
-      },
-      {
-        "title": "Develop",
-        "items": [
-          {
-            "title": "Overview",
-            "urls": [
-              "/${VERSION}/developer-guide-overview.html"
-            ]
-          },
-          {
-            "title": "Connect to CockroachDB",
-            "items": [
-              {
-                "title": "Install a driver or ORM",
-                "urls": [
-                  "/${VERSION}/install-client-drivers.html"
-                ]
-              },
-              {
-                "title": "Connect to a Cluster",
-                "urls": [
-                  "/${VERSION}/connect-to-the-database.html",
-                  "/${VERSION}/connect-to-the-database-cockroachcloud.html"
-                ]
-              },
-              {
-                "title": "Use Connection Pools",
-                "urls": [
-                  "/${VERSION}/connection-pooling.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Design a Database Schema",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/schema-design-overview.html"
-                ]
-              },
-              {
-                "title": "Create a Database",
-                "urls": [
-                  "/${VERSION}/schema-design-database.html"
-                ]
-              },
-              {
-                "title": "Create a User-defined Schema",
-                "urls": [
-                  "/${VERSION}/schema-design-schema.html"
-                ]
-              },
-              {
-                "title": "Create a Table",
-                "urls": [
-                  "/${VERSION}/schema-design-table.html"
-                ]
-              },
-              {
-                "title": "Add Secondary Indexes",
-                "urls": [
-                  "/${VERSION}/schema-design-indexes.html"
-                ]
-              },
-              {
-                "title": "Update a Database Schema",
-                "items": [
-                  {
-                    "title": "Change and Remove Objects",
-                    "urls": [
-                      "/${VERSION}/schema-design-update.html"
-                    ]
-                  },
-                  {
-                    "title": "Online Schema Changes",
-                    "urls": [
-                      "/${VERSION}/online-schema-changes.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Advanced Schema Design",
-                "items": [
-                  {
-                    "title": "Use Computed Columns",
-                    "urls": [
-                      "/${VERSION}/computed-columns.html"
-                    ]
-                  },
-                  {
-                    "title": "Group Columns into Families",
-                    "urls": [
-                      "/${VERSION}/column-families.html"
-                    ]
-                  },
-                  {
-                    "title": "Index a Subset of Rows",
-                    "urls": [
-                      "/${VERSION}/partial-indexes.html"
-                    ]
-                  },
-                  {
-                    "title": "Index Sequential Keys",
-                    "urls": [
-                      "/${VERSION}/hash-sharded-indexes.html"
-                    ]
-                  },
-                  {
-                    "title": "Index JSON and Array Data",
-                    "urls": [
-                      "/${VERSION}/inverted-indexes.html"
-                    ]
-                  },
-                  {
-                    "title": "Index Spatial Data",
-                    "urls": [
-                      "/${VERSION}/spatial-indexes.html"
-                    ]
-                  }
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Write Data",
-            "items": [
-              {
-                "title": "Insert Data",
-                "urls": [
-                  "/${VERSION}/insert-data.html"
-                ]
-              },
-              {
-                "title": "Update Data",
-                "urls": [
-                  "/${VERSION}/update-data.html"
-                ]
-              },
-              {
-                "title": "Bulk-update Data",
-                "urls": [
-                  "/${VERSION}/bulk-update-data.html"
-                ]
-              },
-              {
-                "title": "Delete Data",
-                "urls": [
-                  "/${VERSION}/delete-data.html"
-                ]
-              },
-              {
-                "title": "Bulk-delete Data",
-                "urls": [
-                  "/${VERSION}/bulk-delete-data.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Read Data",
-            "items": [
-              {
-                "title": "Select Rows of Data",
-                "urls": [
-                  "/${VERSION}/query-data.html"
-                ]
-              },
-              {
-                "title": "Reuse Query Results",
-                "items": [
-                  {
-                    "title": "Reusable Views",
-                    "urls": [
-                      "/${VERSION}/views.html"
-                    ]
-                  },
-                  {
-                    "title": "Subqueries",
-                    "urls": [
-                      "/${VERSION}/subqueries.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Create Temporary Tables",
-                "urls": [
-                  "/${VERSION}/temporary-tables.html"
-                ]
-              },
-              {
-                "title": "Paginate Results",
-                "urls": [
-                  "/${VERSION}/pagination.html"
-                ]
-              },
-              {
-                "title": "Read Historical Data",
-                "items": [
-                  {
-                    "title": "AS OF SYSTEM TIME",
-                    "urls": [
-                      "/${VERSION}/as-of-system-time.html"
-                    ]
-                  },
-                  {
-                    "title": "Follower Reads",
-                    "urls": [
-                      "/${VERSION}/follower-reads.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Query Spatial Data",
-                "urls": [
-                  "/${VERSION}/query-spatial-data.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Manage Transactions",
-            "urls": [
-              "/${VERSION}/transactions.html"
-            ]
-          },
-          {
-            "title": "Debug Your Application",
-            "items":
-            [
-              {
-                "title": "Log Events",
-                "urls": [
-                  "/${VERSION}/debug-and-error-logs.html"
-                ]
-              },
-              {
-                "title": "Monitor CockroachDB Apps in the DB Console",
-                "urls": [
-                  "/${VERSION}/ui-overview.html"
-                ]
-              },
-              {
-                "title": "Troubleshoot Common Problems",
-                "urls": [
-                  "/${VERSION}/error-handling-and-troubleshooting.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Optimize Performance",
-            "items":
-            [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/make-queries-fast.html"
-                ]
-              },
-              {
-                "title": "Performance Best Practices",
-                "urls": [
-                  "/${VERSION}/performance-best-practices-overview.html"
-                ]
-              },
-              {
-                "title": "Use the EXPLAIN statement",
-                "urls": [
-                  "/${VERSION}/sql-tuning-with-explain.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Example Apps",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/example-apps.html"
-                ]
-              },
-              {
-                "title": "Simple CRUD",
-                "items": [
-                  {
-                    "title": "Go",
-                    "urls": [
-                      "/${VERSION}/build-a-go-app-with-cockroachdb.html",
-                      "/${VERSION}/build-a-go-app-with-cockroachdb-pq.html",
-                      "/${VERSION}/build-a-go-app-with-cockroachdb-gorm.html",
-                      "/${VERSION}/build-a-go-app-with-cockroachdb-upperdb.html"
-                    ]
-                  },
-                  {
-                    "title": "Java",
-                    "urls": [
-                      "/${VERSION}/build-a-java-app-with-cockroachdb.html",
-                      "/${VERSION}/build-a-java-app-with-cockroachdb-hibernate.html",
-                      "/${VERSION}/build-a-java-app-with-cockroachdb-jooq.html",
-                      "/${VERSION}/build-a-spring-app-with-cockroachdb-mybatis.html"
-                    ]
-                  },
-                  {
-                    "title": "JavaScript/TypeScript",
-                    "urls": [
-                      "/${VERSION}/build-a-nodejs-app-with-cockroachdb.html",
-                      "/${VERSION}/build-a-nodejs-app-with-cockroachdb-sequelize.html",
-                      "/${VERSION}/build-a-typescript-app-with-cockroachdb.html"
-                    ]
-                  },
-                  {
-                    "title": "Python",
-                    "urls": [
-                      "/${VERSION}/build-a-python-app-with-cockroachdb.html",
-                      "/${VERSION}/build-a-python-app-with-cockroachdb-sqlalchemy.html",
-                      "/${VERSION}/build-a-python-app-with-cockroachdb-django.html"
-                    ]
-                  },
-                  {
-                    "title": "Ruby",
-                    "urls": [
-                      "/${VERSION}/build-a-ruby-app-with-cockroachdb.html",
-                      "/${VERSION}/build-a-ruby-app-with-cockroachdb-activerecord.html"
-                    ]
-                  },
-                  {
-                    "title": "C# (.NET)",
-                    "urls": [
-                      "/${VERSION}/build-a-csharp-app-with-cockroachdb.html"
-                    ]
-                  },
-                  {
-                    "title": "Rust",
-                    "urls": [
-                      "/${VERSION}/build-a-rust-app-with-cockroachdb.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Roach Data",
-                "items": [
-                  {
-                    "title": "Spring Boot with JDBC",
-                    "urls": [
-                      "/${VERSION}/build-a-spring-app-with-cockroachdb-jdbc.html"
-                    ]
-                  },
-                  {
-                    "title": "Spring Boot with JPA",
-                    "urls": [
-                      "/${VERSION}/build-a-spring-app-with-cockroachdb-jpa.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "MovR",
-                "items": [
-                  {
-                    "title": "Overview",
-                    "urls": [
-                      "/${VERSION}/movr.html"
-                    ]
-                  },
-                  {
-                    "title": "Multi-Region",
-                    "items": [
-                      {
-                        "title": "Overview",
-                        "urls": [
-                          "/${VERSION}/multi-region-overview.html"
-                        ]
-                      },
-                      {
-                        "title": "Use-Case",
-                        "urls": [
-                          "/${VERSION}/multi-region-use-case.html"
-                        ]
-                      },
-                      {
-                        "title": "Database Schema",
-                        "urls": [
-                          "/${VERSION}/multi-region-database.html"
-                        ]
-                      },
-                      {
-                        "title": "Setup",
-                        "urls": [
-                          "/${VERSION}/multi-region-setup.html"
-                        ]
-                      },
-                      {
-                        "title": "Application",
-                        "urls": [
-                          "/${VERSION}/multi-region-application.html"
-                        ]
-                      },
-                      {
-                        "title": "Deployment",
-                        "urls": [
-                          "/${VERSION}/multi-region-deployment.html"
-                        ]
-                      }
-                    ]
-                  }
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Third-Party Database Tools",
-            "items": [
-              {
-                "title": "Supported by Cockroach Labs",
-                "urls": [
-                  "/${VERSION}/third-party-database-tools.html"
-                ]
-              },
-              {
-                "title": "Supported by the Community",
-                "urls": [
-                  "/${VERSION}/community-tooling.html"
-                ]
-              },
-              {
-                "title": "Tutorials",
-                "items": [
-                  {
-                    "title": "Schema Migration Tools",
-                    "items": [
-                      {
-                        "title": "Alembic",
-                        "urls": [
-                          "/${VERSION}/alembic.html"
-                        ]
-                      },
-                      {
-                        "title": "Flyway",
-                        "urls": [
-                          "/${VERSION}/flyway.html"
-                        ]
-                      },
-                      {
-                        "title": "Liquibase",
-                        "urls": [
-                          "/${VERSION}/liquibase.html"
-                        ]
-                      }
-                    ]
-                  },
-                  {
-                    "title": "GUIs & IDEs",
-                    "items": [
-                      {
-                        "title": "DBeaver GUI",
-                        "urls": [
-                          "/${VERSION}/dbeaver.html"
-                        ]
-                      },
-                      {
-                        "title": "IntelliJ IDEA",
-                        "urls": [
-                          "/${VERSION}/intellij-idea.html"
-                        ]
-                      }
-                    ]
-                  },
-                  {
-                    "title": "Application Deployment Tools",
-                    "items": [
-                      {
-                        "title": "Google Cloud Run",
-                        "urls": [
-                          "/${VERSION}/deploy-app-gcr.html"
-                        ]
-                      }
-                    ]
-                  }
-                ]
-              }
-            ]
-          }
-        ]
-      },
-      {
-        "title": "Deploy",
-        "items": [
-          {
-            "title": "Production Checklist",
-            "urls": [
-              "/${VERSION}/recommended-production-settings.html"
-            ]
-          },
-          {
-            "title": "Topology Patterns",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/topology-patterns.html"
-                ]
-              },
-              {
-                "title": "Development",
-                "urls": [
-                  "/${VERSION}/topology-development.html"
-                ]
-              },
-              {
-                "title": "Basic Production",
-                "urls": [
-                  "/${VERSION}/topology-basic-production.html"
-                ]
-              },
-              {
-                "title": "Geo-Partitioned Replicas",
-                "urls": [
-                  "/${VERSION}/topology-geo-partitioned-replicas.html"
-                ]
-              },
-              {
-                "title": "Geo-Partitioned Leaseholders",
-                "urls": [
-                  "/${VERSION}/topology-geo-partitioned-leaseholders.html"
-                ]
-              },
-              {
-                "title": "Duplicate Indexes",
-                "urls": [
-                  "/${VERSION}/topology-duplicate-indexes.html"
-                ]
-              },
-              {
-                "title": "Follower Reads",
-                "urls": [
-                  "/${VERSION}/topology-follower-reads.html"
-                ]
-              },
-              {
-                "title": "Follow-the-Workload",
-                "urls": [
-                  "/${VERSION}/topology-follow-the-workload.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Manual Deployment",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/manual-deployment.html"
-                ]
-              },
-              {
-                "title": "On-Premises",
-                "urls": [
-                  "/${VERSION}/deploy-cockroachdb-on-premises.html",
-                  "/${VERSION}/deploy-cockroachdb-on-premises-insecure.html"
-                ]
-              },
-              {
-                "title": "AWS",
-                "urls": [
-                  "/${VERSION}/deploy-cockroachdb-on-aws.html",
-                  "/${VERSION}/deploy-cockroachdb-on-aws-insecure.html"
-                ]
-              },
-              {
-                "title": "Azure",
-                "urls": [
-                  "/${VERSION}/deploy-cockroachdb-on-microsoft-azure.html",
-                  "/${VERSION}/deploy-cockroachdb-on-microsoft-azure-insecure.html"
-                ]
-              },
-              {
-                "title": "Digital Ocean",
-                "urls": [
-                  "/${VERSION}/deploy-cockroachdb-on-digital-ocean.html",
-                  "/${VERSION}/deploy-cockroachdb-on-digital-ocean-insecure.html"
-                ]
-              },
-              {
-                "title": "Google Cloud Platform GCE",
-                "urls": [
-                  "/${VERSION}/deploy-cockroachdb-on-google-cloud-platform.html",
-                  "/${VERSION}/deploy-cockroachdb-on-google-cloud-platform-insecure.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Orchestrated Deployment",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/orchestration.html"
-                ]
-              },
-              {
-                "title": "Kubernetes Single-Cluster Deployment",
-                "urls": [
-                  "/${VERSION}/orchestrate-cockroachdb-with-kubernetes.html",
-                  "/${VERSION}/orchestrate-cockroachdb-with-kubernetes-insecure.html"
-                ]
-              },
-              {
-                "title": "Kubernetes Multi-Cluster Deployment",
-                "urls": [
-                  "/${VERSION}/orchestrate-cockroachdb-with-kubernetes-multi-cluster.html"
-                ]
-              },
-              {
-                "title": "Kubernetes Performance Optimization",
-                "urls": [
-                  "/${VERSION}/kubernetes-performance.html"
-                ]
-              },
-              {
-                "title": "Docker Swarm Deployment",
-                "urls": [
-                  "/${VERSION}/orchestrate-cockroachdb-with-docker-swarm.html",
-                  "/${VERSION}/orchestrate-cockroachdb-with-docker-swarm-insecure.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Back Up and Restore Data",
-            "items": [
-              {
-                "title": "Full and Incremental Backups",
-                "urls": [
-                  "/${VERSION}/take-full-and-incremental-backups.html"
-                ]
-              },
-              {
-                "title": "Backups with Revision History and Point-in-time Restore",
-                "urls": [
-                  "/${VERSION}/take-backups-with-revision-history-and-restore-from-a-point-in-time.html"
-                ]
-              },
-              {
-                "title": "Encrypted Backup and Restore",
-                "urls": [
-                  "/${VERSION}/take-and-restore-encrypted-backups.html"
-                ]
-              },
-              {
-                "title": "Locality-aware Backup and Restore",
-                "urls": [
-                  "/${VERSION}/take-and-restore-locality-aware-backups.html"
-                ]
-              },
-              {
-                "title": "Scheduled Backups",
-                "urls": [
-                  "/${VERSION}/manage-a-backup-schedule.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "File Storage for Bulk Operations",
-            "items": [
-              {
-                "title": "Cloud Storage",
-                "urls": [
-                  "/${VERSION}/use-cloud-storage-for-bulk-operations.html"
-                ]
-              },
-              {
-                "title": "Userfile Storage",
-                "urls": [
-                  "/${VERSION}/use-userfile-for-bulk-operations.html"
-                ]
-              },
-              {
-                "title": "Local File Server",
-                "urls": [
-                  "/${VERSION}/use-a-local-file-server-for-bulk-operations.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Performance",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/performance.html"
-                ]
-              },
-              {
-                "title": "Benchmarking Instructions",
-                "urls": [
-                  "/${VERSION}/performance-benchmarking-with-tpcc-local.html",
-                  "/${VERSION}/performance-benchmarking-with-tpcc-small.html",
-                  "/${VERSION}/performance-benchmarking-with-tpcc-medium.html",
-                  "/${VERSION}/performance-benchmarking-with-tpcc-large.html"
-                ]
-              },
-              {
-                "title": "Tuning Best Practices",
-                "urls": [
-                  "/${VERSION}/performance-best-practices-overview.html"
-                ]
-              },
-              {
-                "title": "Tuning Tutorial",
-                "urls": [
-                  "/${VERSION}/performance-tuning.html",
-                  "/${VERSION}/performance-tuning-insecure.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Security",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/security-overview.html"
-                ]
-              },
-              {
-                "title": "Authentication",
-                "urls": [
-                  "/${VERSION}/authentication.html"
-                ]
-              },
-              {
-                "title": "Encryption",
-                "urls": [
-                  "/${VERSION}/encryption.html"
-                ]
-              },
-              {
-                "title": "Authorization",
-                "urls": [
-                  "/${VERSION}/authorization.html"
-                ]
-              },
-              {
-                "title": "SQL Audit Logging",
-                "urls": [
-                  "/${VERSION}/sql-audit-logging.html"
-                ]
-              },
-              {
-                "title": "GSSAPI Authentication",
-                "urls": [
-                  "/${VERSION}/gssapi_authentication.html"
-                ]
-              },
-              {
-                "title": "Single Sign-on",
-                "urls": [
-                  "/${VERSION}/sso.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Monitoring and Alerting",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/monitoring-and-alerting.html"
-                ]
-              },
-              {
-                "title": "Enable the Node Map",
-                "urls": [
-                  "/${VERSION}/enable-node-map.html"
-                ]
-              },
-              {
-                "title": "Use Prometheus and Alertmanager",
-                "urls": [
-                  "/${VERSION}/monitor-cockroachdb-with-prometheus.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Cluster Maintenance",
-            "items": [
-              {
-                "title": "Upgrade to CockroachDB v20.2",
-                "urls": [
-                  "/${VERSION}/upgrade-cockroach-version.html"
-                ]
-              },
-              {
-                "title": "Online Schema Changes",
-                "urls": [
-                  "/${VERSION}/online-schema-changes.html"
-                ]
-              },
-              {
-                "title": "Manage Long-Running Queries",
-                "urls": [
-                  "/${VERSION}/manage-long-running-queries.html"
-                ]
-              },
-              {
-                "title": "Decommission Nodes",
-                "urls": [
-                  "/${VERSION}/remove-nodes.html"
-                ]
-              },
-              {
-                "title": "Rotate Security Certificates",
-                "urls": [
-                  "/${VERSION}/rotate-certificates.html"
-                ]
-              },
-              {
-                "title": "Disaster Recovery",
-                "urls": [
-                  "/${VERSION}/disaster-recovery.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Replication Controls",
-            "urls": [
-              "/${VERSION}/configure-replication-zones.html"
-            ]
-          },
-          {
-            "title": "Stream Data Out of CockroachDB",
-            "urls": [
-              "/${VERSION}/stream-data-out-of-cockroachdb-using-changefeeds.html"
-            ]
-          },
-          {
-            "title": "Enterprise Features",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/enterprise-licensing.html"
-                ]
-              },
-              {
-                "title": "Table Partitioning",
-                "urls": [
-                  "/${VERSION}/partitioning.html"
-                ]
-              }
-            ]
-          }
-        ]
-      },
-      {
-        "title": "Migrate",
-        "items": [
-          {
-            "title": "Migration Overview",
-            "urls": [
-              "/${VERSION}/migration-overview.html"
-            ]
-          },
-          {
-            "title": "Migrate from Oracle",
-            "urls": [
-              "/${VERSION}/migrate-from-oracle.html"
-            ]
-          },
-          {
-            "title": "Migrate from Postgres",
-            "urls": [
-              "/${VERSION}/migrate-from-postgres.html"
-            ]
-          },
-          {
-            "title": "Migrate from MySQL",
-            "urls": [
-              "/${VERSION}/migrate-from-mysql.html"
-            ]
-          },
-          {
-            "title": "Migrate from CSV",
-            "urls": [
-              "/${VERSION}/migrate-from-csv.html"
-            ]
-          },
-          {
-            "title": "Migrate from Avro",
-            "urls": [
-              "/${VERSION}/migrate-from-avro.html"
-            ]
-          },
-          {
-            "title": "Migrate from Shapefiles",
-            "urls": [
-              "/${VERSION}/migrate-from-shapefiles.html"
-            ]
-          },
-          {
-            "title": "Migrate from OpenStreetMap",
-            "urls": [
-              "/${VERSION}/migrate-from-openstreetmap.html"
-            ]
-          },
-          {
-            "title": "Migrate from GeoJSON",
-            "urls": [
-              "/${VERSION}/migrate-from-geojson.html"
-            ]
-          },
-          {
-            "title": "Migrate from GeoPackage",
-            "urls": [
-              "/${VERSION}/migrate-from-geopackage.html"
-            ]
-          },
-          {
-            "title": "Export Spatial Data",
-            "urls": [
-              "/${VERSION}/export-spatial-data.html"
-            ]
-          },
-          {
-            "title": "Import Performance Best Practices",
-            "urls": [
-              "/${VERSION}/import-performance-best-practices.html"
-            ]
-          }
-        ]
-      },
-      {
-        "title": "Troubleshoot",
-        "items": [
-          {
-            "title": "Overview",
-            "urls": [
-              "/${VERSION}/troubleshooting-overview.html"
-            ]
-          },
-          {
-            "title": "Common Errors",
-            "urls": [
-              "/${VERSION}/common-errors.html"
-            ]
-          },
-          {
-            "title": "Troubleshoot Cluster Setup",
-            "urls": [
-              "/${VERSION}/cluster-setup-troubleshooting.html"
-            ]
-          },
-          {
-            "title": "Troubleshoot Query Behavior",
-            "urls": [
-              "/${VERSION}/query-behavior-troubleshooting.html"
-            ]
-          },
-          {
-            "title": "Understand Debug Logs",
-            "urls": [
-              "/${VERSION}/debug-and-error-logs.html"
-            ]
-          },
-          {
-            "title": "Replication Reports",
-            "urls": [
-              "/${VERSION}/query-replication-reports.html"
-            ]
-          },
-          {
-            "title": "Support Resources",
-            "urls": [
-              "/${VERSION}/support-resources.html"
-            ]
-          },
-          {
-            "title": "File an Issue",
-            "urls": [
-              "/${VERSION}/file-an-issue.html"
-            ]
-          }
-        ]
-      },
-      {
-        "title": "Reference",
-        "items": [
-          {
-            "title": "Architecture",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/architecture/overview.html"
-                ]
-              },
-              {
-                "title": "SQL Layer",
-                "urls": [
-                  "/${VERSION}/architecture/sql-layer.html"
-                ]
-              },
-              {
-                "title": "Transaction Layer",
-                "urls": [
-                  "/${VERSION}/architecture/transaction-layer.html"
-                ]
-              },
-              {
-                "title": "Distribution Layer",
-                "urls": [
-                  "/${VERSION}/architecture/distribution-layer.html"
-                ]
-              },
-              {
-                "title": "Replication Layer",
-                "urls": [
-                  "/${VERSION}/architecture/replication-layer.html"
-                ]
-              },
-              {
-                "title": "Storage Layer",
-                "urls": [
-                  "/${VERSION}/architecture/storage-layer.html"
-                ]
-              },
-              {
-                "title": "Life of a Distributed Transaction",
-                "urls": [
-                  "/${VERSION}/architecture/life-of-a-distributed-transaction.html"
-                ]
-              },
-              {
-                "title": "Reads and Writes Overview",
-                "urls": [
-                  "/${VERSION}/architecture/reads-and-writes-overview.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "SQL",
-            "items": [
-              {
-                "title": "PostgreSQL Compatibility",
-                "urls": [
-                  "/${VERSION}/postgresql-compatibility.html"
-                ]
-              },
-              {
-                "title": "SQL Feature Support",
-                "urls": [
-                  "/${VERSION}/sql-feature-support.html"
-                ]
-              },
-              {
-                "title": "SQL Statements",
-                "items": [
-                  {
-                    "title": "Overview",
-                    "urls": [
-                      "/${VERSION}/sql-statements.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ADD COLUMN</code>",
-                    "urls": [
-                      "/${VERSION}/add-column.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ADD CONSTRAINT</code>",
-                    "urls": [
-                      "/${VERSION}/add-constraint.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER COLUMN</code>",
-                    "urls": [
-                      "/${VERSION}/alter-column.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER DATABASE</code>",
-                    "urls": [
-                      "/${VERSION}/alter-database.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER INDEX</code>",
-                    "urls": [
-                      "/${VERSION}/alter-index.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER PARTITION</code> (Enterprise)",
-                    "urls": [
-                      "/${VERSION}/alter-partition.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER PRIMARY KEY</code>",
-                    "urls": [
-                      "/${VERSION}/alter-primary-key.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER RANGE</code>",
-                    "urls": [
-                      "/${VERSION}/alter-range.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER ROLE</code>",
-                    "urls": [
-                      "/${VERSION}/alter-role.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER SCHEMA</code>",
-                    "urls": [
-                      "/${VERSION}/alter-schema.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER SEQUENCE</code>",
-                    "urls": [
-                      "/${VERSION}/alter-sequence.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER TABLE</code>",
-                    "urls": [
-                      "/${VERSION}/alter-table.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER TYPE</code>",
-                    "urls": [
-                      "/${VERSION}/alter-type.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER USER</code>",
-                    "urls": [
-                      "/${VERSION}/alter-user.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>AS OF SYSTEM TIME</code>",
-                    "urls": [
-                      "/${VERSION}/as-of-system-time.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>EXPERIMENTAL_AUDIT</code>",
-                    "urls": [
-                      "/${VERSION}/experimental-audit.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ALTER VIEW</code>",
-                    "urls": [
-                      "/${VERSION}/alter-view.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>BACKUP</code>",
-                    "urls": [
-                      "/${VERSION}/backup.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>BEGIN</code>",
-                    "urls": [
-                      "/${VERSION}/begin-transaction.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CANCEL JOB</code>",
-                    "urls": [
-                      "/${VERSION}/cancel-job.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CANCEL QUERY</code>",
-                    "urls": [
-                      "/${VERSION}/cancel-query.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CANCEL SESSION</code>",
-                    "urls": [
-                      "/${VERSION}/cancel-session.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>COMMENT ON</code>",
-                    "urls": [
-                      "/${VERSION}/comment-on.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>COMMIT</code>",
-                    "urls": [
-                      "/${VERSION}/commit-transaction.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CONFIGURE ZONE</code>",
-                    "urls": [
-                      "/${VERSION}/configure-zone.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CONVERT TO SCHEMA</code>",
-                    "urls": [
-                      "/${VERSION}/convert-to-schema.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>COPY FROM</code>",
-                    "urls": [
-                      "/${VERSION}/copy-from.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE CHANGEFEED</code> (Enterprise)",
-                    "urls": [
-                      "/${VERSION}/create-changefeed.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE DATABASE</code>",
-                    "urls": [
-                      "/${VERSION}/create-database.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE INDEX</code>",
-                    "urls": [
-                      "/${VERSION}/create-index.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE ROLE</code>",
-                    "urls": [
-                      "/${VERSION}/create-role.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE SCHEDULE FOR BACKUP</code>",
-                    "urls": [
-                      "/${VERSION}/create-schedule-for-backup.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE SCHEMA</code>",
-                    "urls": [
-                      "/${VERSION}/create-schema.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE SEQUENCE</code>",
-                    "urls": [
-                      "/${VERSION}/create-sequence.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE STATISTICS</code>",
-                    "urls": [
-                      "/${VERSION}/create-statistics.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE TABLE</code>",
-                    "urls": [
-                      "/${VERSION}/create-table.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE TABLE AS</code>",
-                    "urls": [
-                      "/${VERSION}/create-table-as.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE TYPE</code>",
-                    "urls": [
-                      "/${VERSION}/create-type.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE USER</code>",
-                    "urls": [
-                      "/${VERSION}/create-user.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>CREATE VIEW</code>",
-                    "urls": [
-                      "/${VERSION}/create-view.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DELETE</code>",
-                    "urls": [
-                      "/${VERSION}/delete.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP COLUMN</code>",
-                    "urls": [
-                      "/${VERSION}/drop-column.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP CONSTRAINT</code>",
-                    "urls": [
-                      "/${VERSION}/drop-constraint.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP DATABASE</code>",
-                    "urls": [
-                      "/${VERSION}/drop-database.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP TYPE</code>",
-                    "urls": [
-                      "/${VERSION}/drop-type.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP INDEX</code>",
-                    "urls": [
-                      "/${VERSION}/drop-index.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP ROLE</code>",
-                    "urls": [
-                      "/${VERSION}/drop-role.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP SCHEDULES</code>",
-                    "urls": [
-                      "/${VERSION}/drop-schedules.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP SCHEMA</code>",
-                    "urls": [
-                      "/${VERSION}/drop-schema.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP SEQUENCE</code>",
-                    "urls": [
-                      "/${VERSION}/drop-sequence.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP TABLE</code>",
-                    "urls": [
-                      "/${VERSION}/drop-table.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP USER</code>",
-                    "urls": [
-                      "/${VERSION}/drop-user.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DROP VIEW</code>",
-                    "urls": [
-                      "/${VERSION}/drop-view.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>EXPERIMENTAL CHANGEFEED FOR</code>",
-                    "urls": [
-                      "/${VERSION}/changefeed-for.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>EXPLAIN</code>",
-                    "urls": [
-                      "/${VERSION}/explain.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>EXPLAIN ANALYZE</code>",
-                    "urls": [
-                      "/${VERSION}/explain-analyze.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>EXPORT</code>",
-                    "urls": [
-                      "/${VERSION}/export.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>GRANT &lt;privileges&gt;</code>",
-                    "urls": [
-                      "/${VERSION}/grant.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>GRANT &lt;roles&gt;</code>",
-                    "urls": [
-                      "/${VERSION}/grant-roles.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>IMPORT</code>",
-                    "urls": [
-                      "/${VERSION}/import.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>IMPORT INTO</code>",
-                    "urls": [
-                      "/${VERSION}/import-into.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>INSERT</code>",
-                    "urls": [
-                      "/${VERSION}/insert.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>JOIN</code>",
-                    "urls": [
-                      "/${VERSION}/joins.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>LIMIT</code>/<code>OFFSET</code>",
-                    "urls": [
-                      "/${VERSION}/limit-offset.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ORDER BY</code>",
-                    "urls": [
-                      "/${VERSION}/order-by.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>OWNER TO</code>",
-                    "urls": [
-                      "/${VERSION}/owner-to.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>PARTITION BY</code> (Enterprise)",
-                    "urls": [
-                      "/${VERSION}/partition-by.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>PAUSE JOB</code>",
-                    "urls": [
-                      "/${VERSION}/pause-job.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>PAUSE SCHEDULES</code>",
-                    "urls": [
-                      "/${VERSION}/pause-schedules.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>REFRESH</code>",
-                    "urls": [
-                      "/${VERSION}/refresh.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RENAME COLUMN</code>",
-                    "urls": [
-                      "/${VERSION}/rename-column.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RENAME CONSTRAINT</code>",
-                    "urls": [
-                      "/${VERSION}/rename-constraint.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RENAME DATABASE</code>",
-                    "urls": [
-                      "/${VERSION}/rename-database.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RENAME INDEX</code>",
-                    "urls": [
-                      "/${VERSION}/rename-index.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RENAME TABLE</code>",
-                    "urls": [
-                      "/${VERSION}/rename-table.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RENAME SEQUENCE</code>",
-                    "urls": [
-                      "/${VERSION}/rename-sequence.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RELEASE SAVEPOINT</code>",
-                    "urls": [
-                      "/${VERSION}/release-savepoint.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RESET</code> &lt;session variable&gt;",
-                    "urls": [
-                      "/${VERSION}/reset-vars.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RESET CLUSTER SETTING</code>",
-                    "urls": [
-                      "/${VERSION}/reset-cluster-setting.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RESTORE</code>",
-                    "urls": [
-                      "/${VERSION}/restore.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RESUME JOB</code>",
-                    "urls": [
-                      "/${VERSION}/resume-job.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>RESUME SCHEDULES</code>",
-                    "urls": [
-                      "/${VERSION}/resume-schedules.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>REVOKE &lt;privileges&gt;</code>",
-                    "urls": [
-                      "/${VERSION}/revoke.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>REVOKE &lt;roles&gt;</code>",
-                    "urls": [
-                      "/${VERSION}/revoke-roles.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ROLLBACK</code>",
-                    "urls": [
-                      "/${VERSION}/rollback-transaction.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SAVEPOINT</code>",
-                    "urls": [
-                      "/${VERSION}/savepoint.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SELECT</code>",
-                    "urls": [
-                      "/${VERSION}/select-clause.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SELECT FOR UPDATE</code>",
-                    "urls": [
-                      "/${VERSION}/select-for-update.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SET</code> &lt;session variable&gt;",
-                    "urls": [
-                      "/${VERSION}/set-vars.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SET CLUSTER SETTING</code>",
-                    "urls": [
-                      "/${VERSION}/set-cluster-setting.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SET SCHEMA</code>",
-                    "urls": [
-                      "/${VERSION}/set-schema.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SET TRANSACTION</code>",
-                    "urls": [
-                      "/${VERSION}/set-transaction.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW</code> &lt;session variables&gt;",
-                    "urls": [
-                      "/${VERSION}/show-vars.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW BACKUP</code>",
-                    "urls": [
-                      "/${VERSION}/show-backup.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW CLUSTER SETTING</code>",
-                    "urls": [
-                      "/${VERSION}/show-cluster-setting.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW COLUMNS</code>",
-                    "urls": [
-                      "/${VERSION}/show-columns.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW CONSTRAINTS</code>",
-                    "urls": [
-                      "/${VERSION}/show-constraints.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW CREATE</code>",
-                    "urls": [
-                      "/${VERSION}/show-create.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW DATABASES</code>",
-                    "urls": [
-                      "/${VERSION}/show-databases.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW ENUMS</code>",
-                    "urls": [
-                      "/${VERSION}/show-enums.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW GRANTS</code>",
-                    "urls": [
-                      "/${VERSION}/show-grants.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW INDEX</code>",
-                    "urls": [
-                      "/${VERSION}/show-index.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW JOBS</code>",
-                    "urls": [
-                      "/${VERSION}/show-jobs.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW LOCALITY</code>",
-                    "urls": [
-                      "/${VERSION}/show-locality.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW PARTITIONS</code> (Enterprise)",
-                    "urls": [
-                      "/${VERSION}/show-partitions.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW QUERIES</code>",
-                    "urls": [
-                      "/${VERSION}/show-queries.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW RANGES</code>",
-                    "urls": [
-                      "/${VERSION}/show-ranges.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW RANGE FOR ROW</code>",
-                    "urls": [
-                      "/${VERSION}/show-range-for-row.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW ROLES</code>",
-                    "urls": [
-                      "/${VERSION}/show-roles.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW SCHEDULES</code>",
-                    "urls": [
-                      "/${VERSION}/show-schedules.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW SCHEMAS</code>",
-                    "urls": [
-                      "/${VERSION}/show-schemas.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW SEQUENCES</code>",
-                    "urls": [
-                      "/${VERSION}/show-sequences.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW SESSIONS</code>",
-                    "urls": [
-                      "/${VERSION}/show-sessions.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW STATISTICS</code>",
-                    "urls": [
-                      "/${VERSION}/show-statistics.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW SAVEPOINT STATUS</code>",
-                    "urls": [
-                      "/${VERSION}/show-savepoint-status.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW TABLES</code>",
-                    "urls": [
-                      "/${VERSION}/show-tables.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW TRACE FOR SESSION</code>",
-                    "urls": [
-                      "/${VERSION}/show-trace.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW TRANSACTIONS</code>",
-                    "urls": [
-                      "/${VERSION}/show-transactions.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW TYPES</code>",
-                    "urls": [
-                      "/${VERSION}/show-types.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW USERS</code>",
-                    "urls": [
-                      "/${VERSION}/show-users.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SHOW ZONE CONFIGURATIONS</code>",
-                    "urls": [
-                      "/${VERSION}/show-zone-configurations.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SPLIT AT</code>",
-                    "urls": [
-                      "/${VERSION}/split-at.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>TRUNCATE</code>",
-                    "urls": [
-                      "/${VERSION}/truncate.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>UNSPLIT AT</code>",
-                    "urls": [
-                      "/${VERSION}/unsplit-at.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>UPDATE</code>",
-                    "urls": [
-                      "/${VERSION}/update.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>UPSERT</code>",
-                    "urls": [
-                      "/${VERSION}/upsert.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>VALIDATE CONSTRAINT</code>",
-                    "urls": [
-                      "/${VERSION}/validate-constraint.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>WITH</code>",
-                    "urls": [
-                      "/${VERSION}/common-table-expressions.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Data Types",
-                "items": [
-                  {
-                    "title": "Overview",
-                    "urls": [
-                      "/${VERSION}/data-types.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ARRAY</code>",
-                    "urls": [
-                      "/${VERSION}/array.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>BIT</code>",
-                    "urls": [
-                      "/${VERSION}/bit.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>BOOL</code>",
-                    "urls": [
-                      "/${VERSION}/bool.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>BYTES</code>",
-                    "urls": [
-                      "/${VERSION}/bytes.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>COLLATE</code>",
-                    "urls": [
-                      "/${VERSION}/collate.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DATE</code>",
-                    "urls": [
-                      "/${VERSION}/date.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>DECIMAL</code>",
-                    "urls": [
-                      "/${VERSION}/decimal.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>ENUM</code>",
-                    "urls": [
-                      "/${VERSION}/enum.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>FLOAT</code>",
-                    "urls": [
-                      "/${VERSION}/float.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>INET</code>",
-                    "urls": [
-                      "/${VERSION}/inet.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>INT</code>",
-                    "urls": [
-                      "/${VERSION}/int.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>INTERVAL</code>",
-                    "urls": [
-                      "/${VERSION}/interval.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>JSONB</code>",
-                    "urls": [
-                      "/${VERSION}/jsonb.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>SERIAL</code>",
-                    "urls": [
-                      "/${VERSION}/serial.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>STRING</code>",
-                    "urls": [
-                      "/${VERSION}/string.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>TIME</code>",
-                    "urls": [
-                      "/${VERSION}/time.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>TIMESTAMP</code>",
-                    "urls": [
-                      "/${VERSION}/timestamp.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>UUID</code>",
-                    "urls": [
-                      "/${VERSION}/uuid.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Constraints",
-                "items": [
-                  {
-                    "title": "Overview",
-                    "urls": [
-                      "/${VERSION}/constraints.html"
-                    ]
-                  },
-                  {
-                    "title": "Check",
-                    "urls": [
-                      "/${VERSION}/check.html"
-                    ]
-                  },
-                  {
-                    "title": "Default Value",
-                    "urls": [
-                      "/${VERSION}/default-value.html"
-                    ]
-                  },
-                  {
-                    "title": "Foreign Key",
-                    "urls": [
-                      "/${VERSION}/foreign-key.html"
-                    ]
-                  },
-                  {
-                    "title": "Not Null",
-                    "urls": [
-                      "/${VERSION}/not-null.html"
-                    ]
-                  },
-                  {
-                    "title": "Primary Key",
-                    "urls": [
-                      "/${VERSION}/primary-key.html"
-                    ]
-                  },
-                  {
-                    "title": "Unique",
-                    "urls": [
-                      "/${VERSION}/unique.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Functions and Operators",
-                "urls": [
-                  "/${VERSION}/functions-and-operators.html"
-                ]
-              },
-              {
-                "title": "Window Functions",
-                "urls": [
-                  "/${VERSION}/window-functions.html"
-                ]
-              },
-              {
-                "title": "SQL Syntax",
-                "items": [
-                  {
-                    "title": "Full SQL Grammar",
-                    "urls": [
-                      "/${VERSION}/sql-grammar.html"
-                    ]
-                  },
-                  {
-                    "title": "Keywords & Identifiers",
-                    "urls": [
-                      "/${VERSION}/keywords-and-identifiers.html"
-                    ]
-                  },
-                  {
-                    "title": "Constants",
-                    "urls": [
-                      "/${VERSION}/sql-constants.html"
-                    ]
-                  },
-                  {
-                    "title": "Selection Queries",
-                    "urls": [
-                      "/${VERSION}/selection-queries.html"
-                    ]
-                  },
-                  {
-                    "title": "Table Expressions",
-                    "urls": [
-                      "/${VERSION}/table-expressions.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>WITH</code> Queries (Common Table Expressions)",
-                    "urls": [
-                      "/${VERSION}/common-table-expressions.html"
-                    ]
-                  },
-                  {
-                    "title": "Scalar Expressions",
-                    "urls": [
-                      "/${VERSION}/scalar-expressions.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>NULL</code> Handling",
-                    "urls": [
-                      "/${VERSION}/null-handling.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Name Resolution",
-                "urls": [
-                  "/${VERSION}/sql-name-resolution.html"
-                ]
-              },
-              {
-                "title": "System Catalogs",
-                "items": [
-                  {
-                    "title": "Overview",
-                    "urls": [
-                      "/${VERSION}/system-catalogs.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>crdb_internal</code>",
-                    "urls": [
-                      "/${VERSION}/crdb-internal.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>information_schema</code>",
-                    "urls": [
-                      "/${VERSION}/information-schema.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>pg_catalog</code>",
-                    "urls": [
-                      "/${VERSION}/pg-catalog.html"
-                    ]
-                  },
-                  {
-                    "title": "<code>pg_extension</code>",
-                    "urls": [
-                      "/${VERSION}/pg-extension.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Transactions",
-                "items": [
-                  {
-                    "title": "Overview",
-                    "urls": [
-                      "/${VERSION}/transactions.html"
-                    ]
-                  },
-                  {
-                    "title": "Advanced Client-side Transaction Retries",
-                    "urls": [
-                      "/${VERSION}/advanced-client-side-transaction-retries.html"
-                    ]
-                  },
-                  {
-                    "title": "Transaction Retry Error Reference",
-                    "urls": [
-                      "/${VERSION}/transaction-retry-error-reference.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Performance Optimization",
-                "items": [
-                  {
-                    "title": "Indexes",
-                    "urls": [
-                      "/${VERSION}/indexes.html"
-                    ]
-                  },
-                  {
-                    "title": "Interleaved Tables",
-                    "urls": [
-                      "/${VERSION}/interleave-in-parent.html"
-                    ]
-                  },
-                  {
-                    "title": "Cost-Based Optimizer",
-                    "urls": [
-                      "/${VERSION}/cost-based-optimizer.html"
-                    ]
-                  },
-                  {
-                    "title": "Vectorized Execution",
-                    "urls": [
-                      "/${VERSION}/vectorized-execution.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Spatial Features",
-                "items": [
-                  {
-                    "title": "Overview",
-                    "urls": [
-                      "/${VERSION}/spatial-features.html"
-                    ]
-                  },
-                  {
-                    "title": "Working with Spatial Data",
-                    "urls": [
-                      "/${VERSION}/spatial-data.html"
-                    ]
-                  },
-                  {
-                    "title": "Spatial and GIS Glossary",
-                    "urls": [
-                      "/${VERSION}/spatial-glossary.html"
-                    ]
-                  },
-                  {
-                    "title": "Spatial Indexes",
-                    "urls": [
-                      "/${VERSION}/spatial-indexes.html"
-                    ]
-                  },
-                  {
-                    "title": "POINT",
-                    "urls": [
-                      "/${VERSION}/point.html"
-                    ]
-                  },
-                  {
-                    "title": "LINESTRING",
-                    "urls": [
-                      "/${VERSION}/linestring.html"
-                    ]
-                  },
-                  {
-                    "title": "POLYGON",
-                    "urls": [
-                      "/${VERSION}/polygon.html"
-                    ]
-                  },
-                  {
-                    "title": "MULTIPOINT",
-                    "urls": [
-                      "/${VERSION}/multipoint.html"
-                    ]
-                  },
-                  {
-                    "title": "MULTILINESTRING",
-                    "urls": [
-                      "/${VERSION}/multilinestring.html"
-                    ]
-                  },
-                  {
-                    "title": "MULTIPOLYGON",
-                    "urls": [
-                      "/${VERSION}/multipolygon.html"
-                    ]
-                  },
-                  {
-                    "title": "GEOMETRYCOLLECTION",
-                    "urls": [
-                      "/${VERSION}/geometrycollection.html"
-                    ]
-                  },
-                  {
-                    "title": "Well Known Text (WKT)",
-                    "urls": [
-                      "/${VERSION}/well-known-text.html"
-                    ]
-                  },
-                  {
-                    "title": "Well Known Binary (WKB)",
-                    "urls": [
-                      "/${VERSION}/well-known-binary.html"
-                    ]
-                  },
-                  {
-                    "title": "GeoJSON",
-                    "urls": [
-                      "/${VERSION}/geojson.html"
-                    ]
-                  },
-                  {
-                    "title": "SRID 4326 - longitude and latitude",
-                    "urls": [
-                      "/${VERSION}/srid-4326.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Contains",
-                    "urls": [
-                      "/${VERSION}/st_contains.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Within",
-                    "urls": [
-                      "/${VERSION}/st_within.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Intersects",
-                    "urls": [
-                      "/${VERSION}/st_intersects.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_CoveredBy",
-                    "urls": [
-                      "/${VERSION}/st_coveredby.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Covers",
-                    "urls": [
-                      "/${VERSION}/st_covers.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Disjoint",
-                    "urls": [
-                      "/${VERSION}/st_disjoint.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Equals",
-                    "urls": [
-                      "/${VERSION}/st_equals.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Overlaps",
-                    "urls": [
-                      "/${VERSION}/st_overlaps.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Touches",
-                    "urls": [
-                      "/${VERSION}/st_touches.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_ConvexHull",
-                    "urls": [
-                      "/${VERSION}/st_convexhull.html"
-                    ]
-                  },
-                  {
-                    "title": "ST_Union",
-                    "urls": [
-                      "/${VERSION}/st_union.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Experimental Features",
-                "urls": [
-                  "/${VERSION}/experimental-features.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "CLI",
-            "items": [
-              {
-                "title": "Overview",
-                "urls": [
-                  "/${VERSION}/cockroach-commands.html"
-                ]
-              },
-              {
-                "title": "Client Connection Parameters",
-                "urls": [
-                  "/${VERSION}/connection-parameters.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach start</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-start.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach init</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-init.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach start-single-node</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-start-single-node.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach cert</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-cert.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach quit</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-quit.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach sql</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-sql.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach sqlfmt</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-sqlfmt.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach node</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-node.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach nodelocal upload</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-nodelocal-upload.html"
-                ]
-              },
-              {
-               "title": "<code>cockroach auth-session</code>",
-               "urls": [
-                 "/${VERSION}/cockroach-auth-session.html"
-               ]
-              },
-              {
-                "title": "<code>cockroach dump</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-dump.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach demo</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-demo.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach debug ballast</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-debug-ballast.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach debug encryption-active-key</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-debug-encryption-active-key.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach debug merge-logs</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-debug-merge-logs.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach debug zip</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-debug-zip.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach statement-diag</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-statement-diag.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach gen</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-gen.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach userfile upload</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-userfile-upload.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach userfile list</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-userfile-list.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach userfile delete</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-userfile-delete.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach version</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-version.html"
-                ]
-              },
-              {
-                "title": "<code>cockroach workload</code>",
-                "urls": [
-                  "/${VERSION}/cockroach-workload.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Cluster Settings",
-            "items": [
-              {
-                "title": "Cluster Settings Overview",
-                "urls": [
-                  "/${VERSION}/cluster-settings.html"
-                ]
-              },
-              {
-                "title": "Cost-Based Optimizer",
-                "urls": [
-                  "/${VERSION}/cost-based-optimizer.html"
-                ]
-              },
-              {
-                "title": "Load-Based Splitting",
-                "urls": [
-                  "/${VERSION}/load-based-splitting.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "DB Console",
-            "items": [
-              {
-                "title": "DB Console Overview",
-                "urls": [
-                  "/${VERSION}/ui-overview.html"
-                ]
-              },
-              {
-                "title": "Cluster Overview Page",
-                "urls": [
-                  "/${VERSION}/ui-cluster-overview-page.html"
-                ]
-              },
-              {
-                "title": "Metrics Dashboards",
-                "items": [
-                  {
-                    "title": "Overview Dashboard",
-                    "urls": [
-                      "/${VERSION}/ui-overview-dashboard.html"
-                    ]
-                  },
-                  {
-                    "title": "Hardware Dashboard",
-                    "urls": [
-                      "/${VERSION}/ui-hardware-dashboard.html"
-                    ]
-                  },
-                  {
-                    "title": "Runtime Dashboard",
-                    "urls": [
-                      "/${VERSION}/ui-runtime-dashboard.html"
-                    ]
-                  },
-                  {
-                    "title": "SQL Dashboard",
-                    "urls": [
-                      "/${VERSION}/ui-sql-dashboard.html"
-                    ]
-                  },
-                  {
-                    "title": "Storage Dashboard",
-                    "urls": [
-                      "/${VERSION}/ui-storage-dashboard.html"
-                    ]
-                  },
-                  {
-                    "title": "Replication Dashboard",
-                    "urls": [
-                      "/${VERSION}/ui-replication-dashboard.html"
-                    ]
-                  },
-                  {
-                    "title": "Changefeeds Dashboard",
-                    "urls": [
-                      "/${VERSION}/ui-cdc-dashboard.html"
-                    ]
-                  },
-                  {
-                    "title": "Custom Chart",
-                    "urls": [
-                      "/${VERSION}/ui-custom-chart-debug-page.html"
-                    ]
-                  }
-                ]
-              },
-              {
-                "title": "Databases Page",
-                "urls": [
-                  "/${VERSION}/ui-databases-page.html"
-                ]
-              },
-              {
-                "title": "Sessions Page",
-                "urls": [
-                  "/${VERSION}/ui-sessions-page.html"
-                ]
-              },
-              {
-                "title": "Transactions Page",
-                "urls": [
-                  "/${VERSION}/ui-transactions-page.html"
-                ]
-              },
-              {
-                "title": "Statements Page",
-                "urls": [
-                  "/${VERSION}/ui-statements-page.html"
-                ]
-              },
-              {
-                "title": "Network Latency Page",
-                "urls": [
-                  "/${VERSION}/ui-network-latency-page.html"
-                ]
-              },
-              {
-                "title": "Jobs Page",
-                "urls": [
-                  "/${VERSION}/ui-jobs-page.html"
-                ]
-              },
-              {
-                "title": "Advanced Debug Page",
-                "urls": [
-                  "/${VERSION}/ui-debug-pages.html"
-                ]
-              }
-            ]
-          },
-          {
-            "title": "Diagnostics Reporting",
-            "urls": [
-              "/${VERSION}/diagnostics-reporting.html"
-            ]
-          }
-        ]
-      },
-      {
-        "title": "FAQs",
-        "items": [
-          {
-            "title": "Product FAQs",
-            "urls": [
-              "/${VERSION}/frequently-asked-questions.html"
-            ]
-          },
-          {
-            "title": "SQL FAQs",
-            "urls": [
-              "/${VERSION}/sql-faqs.html"
-            ]
-          },
-          {
-            "title": "Operational FAQs",
-            "urls": [
-              "/${VERSION}/operational-faqs.html"
-            ]
-          },
-          {
-            "title": "Availability FAQs",
-            "urls": [
-              "/${VERSION}/multi-active-availability.html"
-            ]
-          },
-          {
-            "title": "Licensing FAQs",
-            "urls": [
-              "/${VERSION}/licensing-faqs.html"
-            ]
-          },
-          {
-            "title": "CockroachDB in Comparison",
-            "urls": [
-              "/${VERSION}/cockroachdb-in-comparison.html"
-            ]
-          }
-        ]
-      },
-      {% include_cached sidebar-releases.json %}
-    ]
-  }
-]
diff --git a/src/current/_includes/v21.1/orchestration/kubernetes-upgrade-cluster-helm.md b/src/current/_includes/v21.1/orchestration/kubernetes-upgrade-cluster-helm.md
index f7c83e53024..1d7c6e4805c 100644
--- a/src/current/_includes/v21.1/orchestration/kubernetes-upgrade-cluster-helm.md
+++ b/src/current/_includes/v21.1/orchestration/kubernetes-upgrade-cluster-helm.md
@@ -4,7 +4,7 @@
 
     Therefore, in order to upgrade to v21.1, you must be on a production release of v20.2.
 
-    1. If you are upgrading to v21.1 from a production release earlier than v20.2, or from a testing release (alpha/beta), first [upgrade to a production release of v20.2](../v20.2/orchestrate-cockroachdb-with-kubernetes.html#upgrade-the-cluster). Be sure to complete all the steps.
+    1. If you are upgrading to v21.1 from a production release earlier than v20.2, or from a testing release (alpha/beta), first upgrade to a production release of v20.2. Be sure to complete all the steps.
 
     1. Then return to this page and perform a second upgrade to v21.1.
 
diff --git a/src/current/_includes/v21.1/orchestration/kubernetes-upgrade-cluster-manual.md b/src/current/_includes/v21.1/orchestration/kubernetes-upgrade-cluster-manual.md
index 2abc0bad94e..6d4004fe8bc 100644
--- a/src/current/_includes/v21.1/orchestration/kubernetes-upgrade-cluster-manual.md
+++ b/src/current/_includes/v21.1/orchestration/kubernetes-upgrade-cluster-manual.md
@@ -4,7 +4,7 @@
 
     Therefore, in order to upgrade to v21.1, you must be on a production release of v20.2.
 
-    1. First [upgrade to a production release of v20.2](../v20.2/orchestrate-cockroachdb-with-kubernetes.html?filters=manual#upgrade-the-cluster). Be sure to complete all the steps.
+    1. First upgrade to a production release of v20.2. Be sure to complete all the steps.
 
     1. Then return to this page and perform a second upgrade to v21.1.
 
diff --git a/src/current/_includes/v21.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v21.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 4aa36cf2dec..d900a879ca9 100644
--- a/src/current/_includes/v21.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v21.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes](../v20.2/topology-duplicate-indexes.html)                  | [`GLOBAL` tables](global-tables.html)                                                                                                                       |
-| [Geo-partitioned replicas](../v20.2/topology-geo-partitioned-replicas.html)        | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`ZONE` survival goals](multiregion-overview.html#surviving-zone-failures)     |
-| [Geo-partitioned leaseholders](../v20.2/topology-geo-partitioned-leaseholders.html) | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`REGION` survival goals](multiregion-overview.html#surviving-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables](global-tables.html)                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`ZONE` survival goals](multiregion-overview.html#surviving-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`REGION` survival goals](multiregion-overview.html#surviving-region-failures) |
diff --git a/src/current/_includes/v21.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v21.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 4aa36cf2dec..d900a879ca9 100644
--- a/src/current/_includes/v21.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v21.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes](../v20.2/topology-duplicate-indexes.html)                  | [`GLOBAL` tables](global-tables.html)                                                                                                                       |
-| [Geo-partitioned replicas](../v20.2/topology-geo-partitioned-replicas.html)        | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`ZONE` survival goals](multiregion-overview.html#surviving-zone-failures)     |
-| [Geo-partitioned leaseholders](../v20.2/topology-geo-partitioned-leaseholders.html) | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`REGION` survival goals](multiregion-overview.html#surviving-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables](global-tables.html)                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`ZONE` survival goals](multiregion-overview.html#surviving-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`REGION` survival goals](multiregion-overview.html#surviving-region-failures) |
diff --git a/src/current/_includes/v22.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v22.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 4aa36cf2dec..d900a879ca9 100644
--- a/src/current/_includes/v22.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v22.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes](../v20.2/topology-duplicate-indexes.html)                  | [`GLOBAL` tables](global-tables.html)                                                                                                                       |
-| [Geo-partitioned replicas](../v20.2/topology-geo-partitioned-replicas.html)        | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`ZONE` survival goals](multiregion-overview.html#surviving-zone-failures)     |
-| [Geo-partitioned leaseholders](../v20.2/topology-geo-partitioned-leaseholders.html) | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`REGION` survival goals](multiregion-overview.html#surviving-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables](global-tables.html)                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`ZONE` survival goals](multiregion-overview.html#surviving-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`REGION` survival goals](multiregion-overview.html#surviving-region-failures) |
diff --git a/src/current/_includes/v22.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v22.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 4aa36cf2dec..d900a879ca9 100644
--- a/src/current/_includes/v22.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v22.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes](../v20.2/topology-duplicate-indexes.html)                  | [`GLOBAL` tables](global-tables.html)                                                                                                                       |
-| [Geo-partitioned replicas](../v20.2/topology-geo-partitioned-replicas.html)        | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`ZONE` survival goals](multiregion-overview.html#surviving-zone-failures)     |
-| [Geo-partitioned leaseholders](../v20.2/topology-geo-partitioned-leaseholders.html) | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`REGION` survival goals](multiregion-overview.html#surviving-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables](global-tables.html)                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`ZONE` survival goals](multiregion-overview.html#surviving-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables](regional-tables.html#regional-by-row-tables) with [`REGION` survival goals](multiregion-overview.html#surviving-region-failures) |
diff --git a/src/current/_includes/v23.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v23.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v23.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v23.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_includes/v23.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v23.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v23.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v23.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_includes/v24.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v24.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v24.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v24.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_includes/v24.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v24.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v24.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v24.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_includes/v24.3/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v24.3/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v24.3/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v24.3/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_includes/v25.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v25.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v25.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v25.1/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_includes/v25.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v25.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v25.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v25.2/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_includes/v25.3/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v25.3/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v25.3/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v25.3/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_includes/v25.4/sql/replication-zone-patterns-to-multiregion-sql-mapping.md b/src/current/_includes/v25.4/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
index 6fdea66fc89..93bc2276e4f 100644
--- a/src/current/_includes/v25.4/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
+++ b/src/current/_includes/v25.4/sql/replication-zone-patterns-to-multiregion-sql-mapping.md
@@ -1,5 +1,5 @@
 | Replication Zone Pattern                         | Multi-Region SQL                                                                                                                                    |
 |--------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [Duplicate indexes]({% link v20.2/topology-duplicate-indexes.md %})                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
-| [Geo-partitioned replicas]({% link v20.2/topology-geo-partitioned-replicas.md %})        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
-| [Geo-partitioned leaseholders]({% link v20.2/topology-geo-partitioned-leaseholders.md %}) | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
+| Duplicate indexes                  | [`GLOBAL` tables]({% link {{ page.version.version }}/global-tables.md %})                                                                                                                       |
+| Geo-partitioned replicas        | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`ZONE` survival goals](multiregion-survival-goals.html#survive-zone-failures)     |
+| Geo-partitioned leaseholders | [`REGIONAL BY ROW` tables]({% link {{ page.version.version }}/regional-tables.md %}#regional-by-row-tables) with [`REGION` survival goals](multiregion-survival-goals.html#survive-region-failures) |
diff --git a/src/current/_plugins/sidebar_htmltest.rb b/src/current/_plugins/sidebar_htmltest.rb
index 970926334d0..62017bd7728 100644
--- a/src/current/_plugins/sidebar_htmltest.rb
+++ b/src/current/_plugins/sidebar_htmltest.rb
@@ -1,16 +1,36 @@
 require 'json'
 require 'liquid'
+require 'yaml'
 
 module SidebarHTMLTest
   class Generator < Jekyll::Generator
     def generate(site)
       @site = site
 
+      # Read htmltest configuration to get ignored directories
+      htmltest_config = YAML.load_file('.htmltest.yml') rescue {}
+      ignored_dirs = htmltest_config['IgnoreDirs'] || []
+
+      # Extract version numbers from ignored directories
+      ignored_versions = ignored_dirs.map do |dir|
+        match = dir.match(/\^?docs\/?(v\d+\.\d+)/)
+        match[1] if match
+      end.compact
+
       Dir[File.join(site.config['includes_dir'], 'sidebar-data-v*.json')].each do |f|
         next unless !!site.config['cockroachcloud'] == f.include?('cockroachcloud')
+
+        # Extract version from filename
+        version = f.match(/sidebar-data-(v\d+\.\d+)/)[1]
+
+        # Skip if this version is in the ignored list
+        if ignored_versions.include?(version)
+          Jekyll.logger.info "SidebarHTMLTest:", "Skipping ignored version #{version}"
+          next
+        end
+
         partial = site.liquid_renderer.file(f).parse(File.read(f))
         json = partial.render!(site.site_payload, {registers: {site: site}})
-        version = f.match(/sidebar-data-(v\d+\.\d+)/)[1]
         render_sidebar(json, version)
       end
     end
diff --git a/src/current/releases/v20.2.md b/src/current/releases/v20.2.md
index c500afd7bd0..ee2f7542341 100644
--- a/src/current/releases/v20.2.md
+++ b/src/current/releases/v20.2.md
@@ -8,16 +8,38 @@ docs_area: releases
 keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
 ---
 
-{% assign rel = site.data.releases | where_exp: "rel", "rel.major_version == page.major_version" | sort: "release_date" | reverse %}
+<a name="v20-2-0"></a>
+<a name="v20-2-1"></a>
+<a name="v20-2-2"></a>
+<a name="v20-2-3"></a>
+<a name="v20-2-4"></a>
+<a name="v20-2-5"></a>
+<a name="v20-2-6"></a>
+<a name="v20-2-7"></a>
+<a name="v20-2-8"></a>
+<a name="v20-2-9"></a>
+<a name="v20-2-10"></a>
+<a name="v20-2-11"></a>
+<a name="v20-2-12"></a>
+<a name="v20-2-13"></a>
+<a name="v20-2-14"></a>
+<a name="v20-2-15"></a>
+<a name="v20-2-16"></a>
+<a name="v20-2-17"></a>
+<a name="v20-2-18"></a>
+<a name="v20-2-19"></a>
+<a name="v20-2-0-alpha-1"></a>
+<a name="v20-2-0-alpha-2"></a>
+<a name="v20-2-0-alpha-3"></a>
+<a name="v20-2-0-beta-1"></a>
+<a name="v20-2-0-beta-2"></a>
+<a name="v20-2-0-beta-3"></a>
+<a name="v20-2-0-beta-4"></a>
+<a name="v20-2-0-rc-1"></a>
+<a name="v20-2-0-rc-2"></a>
+<a name="v20-2-0-rc-3"></a>
+<a name="v20-2-0-rc-4"></a>
 
-{% assign vers = site.data.versions | where_exp: "vers", "vers.major_version == page.major_version" | first %}
+This release is no longer supported. For more information, see our [Release support policy]({% link releases/release-support-policy.md %}). 
 
-{% assign today = "today" | date: "%Y-%m-%d" %}
-
-{% include releases/testing-release-notice.md major_version=vers %}
-
-{% include releases/whats-new-intro.md major_version=vers %}
-
-{% for r in rel %}
-{% include releases/{{ page.major_version }}/{{ r.release_name }}.md release=r.release_name %}
-{% endfor %}
+To download the archived documentation for this release, see [Archived Documentation]({% link releases/archived-documentation.md %}).
\ No newline at end of file
diff --git a/src/current/v20.2/404.md b/src/current/v20.2/404.md
deleted file mode 100644
index b2ac679fe65..00000000000
--- a/src/current/v20.2/404.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-description: "Page not found."
-sitemap: false
-search: exclude
-related_pages: none
-toc: false
-contribute: false
-feedback: false
----  
-
-<div class="page-not-found">
-  <p id="page-not-found-heading">Whoops!</p>
-
-  <p id="page-not-found-body">We cannot find the page you are looking for. You may have typed the wrong address or found a broken link.</p>
-</div>
diff --git a/src/current/v20.2/add-column.md b/src/current/v20.2/add-column.md
deleted file mode 100644
index cf66161a82a..00000000000
--- a/src/current/v20.2/add-column.md
+++ /dev/null
@@ -1,333 +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
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/add_column.html %}
-</div>
-
-## 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).<br><br>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).
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-### Setup
-
-The following examples use the [`bank` demo database schema](cockroach-demo.html#datasets).
-
-To follow along, run [`cockroach demo bank`](cockroach-demo.html) to start a temporary, in-memory cluster with the `bank` schema and dataset preloaded:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo bank
-~~~
-
-### Add a single column
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE bank ADD COLUMN active BOOL;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM bank;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  id          | INT8      |    false    | NULL           |                       | {primary} |   false
-  balance     | INT8      |    true     | NULL           |                       | {}        |   false
-  payload     | STRING    |    true     | NULL           |                       | {}        |   false
-  active      | BOOL      |    true     | NULL           |                       | {}        |   false
-(4 rows)
-~~~
-
-### Add multiple columns
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE bank ADD COLUMN location STRING, ADD COLUMN currency STRING;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM bank;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  id          | INT8      |    false    | NULL           |                       | {primary} |   false
-  balance     | INT8      |    true     | NULL           |                       | {}        |   false
-  payload     | STRING    |    true     | NULL           |                       | {}        |   false
-  active      | BOOL      |    true     | NULL           |                       | {}        |   false
-  location    | STRING    |    true     | NULL           |                       | {}        |   false
-  currency    | STRING    |    true     | NULL           |                       | {}        |   false
-(6 rows)
-~~~
-
-### Add a column with a `NOT NULL` constraint and a `DEFAULT` value
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE bank ADD COLUMN interest DECIMAL NOT NULL DEFAULT (DECIMAL '1.3');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM bank;
-~~~
-~~~
-  column_name | data_type | is_nullable |     column_default     | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+------------------------+-----------------------+-----------+------------
-  id          | INT8      |    false    | NULL                   |                       | {primary} |   false
-  balance     | INT8      |    true     | NULL                   |                       | {}        |   false
-  payload     | STRING    |    true     | NULL                   |                       | {}        |   false
-  active      | BOOL      |    true     | NULL                   |                       | {}        |   false
-  location    | STRING    |    true     | NULL                   |                       | {}        |   false
-  currency    | STRING    |    true     | NULL                   |                       | {}        |   false
-  interest    | DECIMAL   |    false    | 1.3:::DECIMAL::DECIMAL |                       | {}        |   false
-(7 rows)
-~~~
-
-### Add a column with a `UNIQUE` constraint
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE bank ADD COLUMN address STRING UNIQUE;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM bank;
-~~~
-~~~
-  column_name | data_type | is_nullable |     column_default     | generation_expression |          indices           | is_hidden
---------------+-----------+-------------+------------------------+-----------------------+----------------------------+------------
-  id          | INT8      |    false    | NULL                   |                       | {primary,bank_address_key} |   false
-  balance     | INT8      |    true     | NULL                   |                       | {}                         |   false
-  payload     | STRING    |    true     | NULL                   |                       | {}                         |   false
-  active      | BOOL      |    true     | NULL                   |                       | {}                         |   false
-  location    | STRING    |    true     | NULL                   |                       | {}                         |   false
-  currency    | STRING    |    true     | NULL                   |                       | {}                         |   false
-  interest    | DECIMAL   |    false    | 1.3:::DECIMAL::DECIMAL |                       | {}                         |   false
-  address     | STRING    |    true     | NULL                   |                       | {bank_address_key}         |   false
-(8 rows)
-~~~
-
-### <span class="version-tag">New in v20.2:</span> Add a column with a `FOREIGN KEY` constraint
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers (
-  id INT PRIMARY KEY,
-  name STRING
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE bank ADD COLUMN cust_number INT REFERENCES customers(id);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM bank;
-~~~
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |          indices           | is_hidden
---------------+-----------+-------------+----------------+-----------------------+----------------------------+------------
-  id          | INT8      |    false    | NULL           |                       | {primary,bank_address_key} |   false
-  balance     | INT8      |    true     | NULL           |                       | {}                         |   false
-  payload     | STRING    |    true     | NULL           |                       | {}                         |   false
-  active      | BOOL      |    true     | NULL           |                       | {}                         |   false
-  location    | STRING    |    true     | NULL           |                       | {}                         |   false
-  currency    | STRING    |    true     | NULL           |                       | {}                         |   false
-  interest    | DECIMAL   |    false    | 1.3:::DECIMAL  |                       | {}                         |   false
-  address     | STRING    |    true     | NULL           |                       | {bank_address_key}         |   false
-  cust_number | INT8      |    true     | NULL           |                       | {}                         |   false
-(9 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS FROM bank;
-~~~
-~~~
-  table_name |       constraint_name        | constraint_type |                      details                       | validated
--------------+------------------------------+-----------------+----------------------------------------------------+------------
-  bank       | bank_address_key             | UNIQUE          | UNIQUE (address ASC)                               |   true
-  bank       | fk_cust_number_ref_customers | FOREIGN KEY     | FOREIGN KEY (cust_number) REFERENCES customers(id) |   true
-  bank       | primary                      | PRIMARY KEY     | PRIMARY KEY (id ASC)                               |   true
-(3 rows)
-~~~
-
-### Add a column with collation
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE bank ADD COLUMN more_names STRING COLLATE en;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM bank;
-~~~
-~~~
-  column_name |     data_type     | is_nullable | column_default | generation_expression |          indices           | is_hidden
---------------+-------------------+-------------+----------------+-----------------------+----------------------------+------------
-  id          | INT8              |    false    | NULL           |                       | {primary,bank_address_key} |   false
-  balance     | INT8              |    true     | NULL           |                       | {}                         |   false
-  payload     | STRING            |    true     | NULL           |                       | {}                         |   false
-  active      | BOOL              |    true     | NULL           |                       | {}                         |   false
-  location    | STRING            |    true     | NULL           |                       | {}                         |   false
-  currency    | STRING            |    true     | NULL           |                       | {}                         |   false
-  interest    | DECIMAL           |    false    | 1.3:::DECIMAL  |                       | {}                         |   false
-  address     | STRING            |    true     | NULL           |                       | {bank_address_key}         |   false
-  cust_number | INT8              |    true     | NULL           |                       | {}                         |   false
-  more_names  | STRING COLLATE en |    true     | NULL           |                       | {}                         |   false
-(10 rows)
-~~~
-
-### 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 bank ADD COLUMN location1 STRING CREATE FAMILY f1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE bank;
-~~~
-~~~
-  table_name |                                                          create_statement
--------------+--------------------------------------------------------------------------------------------------------------------------------------
-  bank       | CREATE TABLE bank (
-             |     id INT8 NOT NULL,
-             |     balance INT8 NULL,
-             |     payload STRING NULL,
-             |     active BOOL NULL,
-             |     location STRING NULL,
-             |     currency STRING NULL,
-             |     interest DECIMAL NOT NULL DEFAULT 1.3:::DECIMAL,
-             |     address STRING NULL,
-             |     cust_number INT8 NULL,
-             |     more_names STRING COLLATE en NULL,
-             |     location1 STRING NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     CONSTRAINT fk_cust_number_ref_customers FOREIGN KEY (cust_number) REFERENCES customers(id),
-             |     UNIQUE INDEX bank_address_key (address ASC),
-             |     FAMILY fam_0_id_balance_payload (id, balance, payload, active, location, currency, interest, address, cust_number, more_names),
-             |     FAMILY f1 (location1)
-             | )
-(1 row)
-~~~
-
-#### Add a column and assign it to an existing column family
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE bank ADD COLUMN location2 STRING FAMILY f1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE bank;
-~~~
-~~~
-  table_name |                                                          create_statement
--------------+--------------------------------------------------------------------------------------------------------------------------------------
-  bank       | CREATE TABLE bank (
-             |     id INT8 NOT NULL,
-             |     balance INT8 NULL,
-             |     payload STRING NULL,
-             |     active BOOL NULL,
-             |     location STRING NULL,
-             |     currency STRING NULL,
-             |     interest DECIMAL NOT NULL DEFAULT 1.3:::DECIMAL,
-             |     address STRING NULL,
-             |     cust_number INT8 NULL,
-             |     more_names STRING COLLATE en NULL,
-             |     location1 STRING NULL,
-             |     location2 STRING NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     CONSTRAINT fk_cust_number_ref_customers FOREIGN KEY (cust_number) REFERENCES customers(id),
-             |     UNIQUE INDEX bank_address_key (address ASC),
-             |     FAMILY fam_0_id_balance_payload (id, balance, payload, active, location, currency, interest, address, cust_number, more_names),
-             |     FAMILY f1 (location1, location2)
-             | )
-(1 row)
-~~~
-
-#### Add a column and create a new column family if column family does not exist
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE bank ADD COLUMN new_name STRING CREATE IF NOT EXISTS FAMILY f2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE bank;
-~~~
-~~~
-  table_name |                                                          create_statement
--------------+--------------------------------------------------------------------------------------------------------------------------------------
-  bank       | CREATE TABLE bank (
-             |     id INT8 NOT NULL,
-             |     balance INT8 NULL,
-             |     payload STRING NULL,
-             |     active BOOL NULL,
-             |     location STRING NULL,
-             |     currency STRING NULL,
-             |     interest DECIMAL NOT NULL DEFAULT 1.3:::DECIMAL,
-             |     address STRING NULL,
-             |     cust_number INT8 NULL,
-             |     more_names STRING COLLATE en NULL,
-             |     location1 STRING NULL,
-             |     location2 STRING NULL,
-             |     new_name STRING NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     CONSTRAINT fk_cust_number_ref_customers FOREIGN KEY (cust_number) REFERENCES customers(id),
-             |     UNIQUE INDEX bank_address_key (address ASC),
-             |     FAMILY fam_0_id_balance_payload (id, balance, payload, active, location, currency, interest, address, cust_number, more_names),
-             |     FAMILY f1 (location1, location2),
-             |     FAMILY f2 (new_name)
-             | )
-(1 row)
-~~~
-
-## 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/v20.2/add-constraint.md b/src/current/v20.2/add-constraint.md
deleted file mode 100644
index a5d1c3932e6..00000000000
--- a/src/current/v20.2/add-constraint.md
+++ /dev/null
@@ -1,245 +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)
-
-To add a primary key constraint to a table, you should explicitly define the primary key at [table creation](create-table.html). To replace an existing primary key, you can use `ADD CONSTRAINT ... PRIMARY KEY`. For details, see [Changing primary keys with `ADD CONSTRAINT ... PRIMARY KEY`](#changing-primary-keys-with-add-constraint-primary-key).
-
-The [`DEFAULT`](default-value.html) and [`NOT NULL`](not-null.html) constraints are managed through [`ALTER COLUMN`](alter-column.html).
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/add_constraint.html %}
-</div>
-
-## 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. <br/><br/>Adding/changing a `DEFAULT` constraint is done through [`ALTER COLUMN`](alter-column.html). <br/><br/>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 %}
-
-## Changing primary keys with `ADD CONSTRAINT ... PRIMARY KEY`
-
- When you change a primary key with [`ALTER TABLE ... ALTER PRIMARY KEY`](alter-primary-key.html), the old primary key index becomes a secondary index. The secondary index created by `ALTER PRIMARY KEY` takes up node memory and can slow down write performance to a cluster. If you do not have queries that filter on the primary key that you are replacing, you can use `ADD CONSTRAINT` to replace the old primary index without creating a secondary index.
-
-`ADD CONSTRAINT ... PRIMARY KEY` can be used to add a primary key to an existing table if one of the following is true:
-
-  - No primary key was explicitly defined at [table creation](create-table.html). In this case, the table is created with a default [primary key on `rowid`](indexes.html#creation). Using `ADD CONSTRAINT ... PRIMARY KEY` drops the default primary key and replaces it with a new primary key.
-  - A [`DROP CONSTRAINT`](drop-constraint.html) statement precedes the `ADD CONSTRAINT ... PRIMARY KEY` statement, in the same transaction. For an example, see [Drop and add the primary key constraint](#drop-and-add-a-primary-key-constraint) below.
-
-{{site.data.alerts.callout_info}}
-`ALTER TABLE ... ADD PRIMARY KEY` is an alias for `ALTER TABLE ... ADD CONSTRAINT ... PRIMARY KEY`.
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### 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 users ADD CONSTRAINT id_name_unique UNIQUE (id, name);
-~~~
-
-### 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 rides ADD CONSTRAINT check_revenue_positive CHECK (revenue >= 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 users ADD COLUMN is_owner STRING;
-> ALTER TABLE users ADD CONSTRAINT check_is_owner CHECK (is_owner 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, `users` and `vehicles`, without foreign key constraints:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE users;
-~~~
-
-~~~
-  table_name |                      create_statement
--------------+--------------------------------------------------------------
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | )
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE vehicles;
-~~~
-
-~~~
-  table_name |                                       create_statement
--------------+------------------------------------------------------------------------------------------------
-  vehicles   | CREATE TABLE vehicles (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     type VARCHAR NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     status VARCHAR NULL,
-             |     current_location VARCHAR NULL,
-             |     ext JSONB NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-             | )
-(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 vehicles ADD CONSTRAINT users_fk FOREIGN KEY (city, owner_id) REFERENCES users (city, id) ON DELETE CASCADE;
-~~~
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> By default, referenced columns must be in the same database as the referencing foreign key column. To enable cross-database foreign key references, set the `sql.cross_db_fks.enabled` [cluster setting](cluster-settings.html) to `true`.
-{{site.data.alerts.end}}
-
-### Drop and add a primary key constraint
-
-Suppose that you want to add `name` to the composite primary key of the `users` table, [without creating a secondary index of the existing primary key](#changing-primary-keys-with-add-constraint-primary-key).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                      create_statement
--------------+--------------------------------------------------------------
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | )
-(1 row)
-~~~
-
-First, add a [`NOT NULL`](not-null.html) constraint to the `name` column with [`ALTER COLUMN`](alter-column.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users ALTER COLUMN name SET NOT NULL;
-~~~
-
-Then, in the same transaction, [`DROP`](drop-constraint.html) the old `"primary"` constraint and `ADD` the new one:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-> ALTER TABLE users DROP CONSTRAINT "primary";
-> ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id);
-> COMMIT;
-~~~
-
-~~~
-NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                          create_statement
--------------+---------------------------------------------------------------------
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NOT NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | )
-(1 row)
-~~~
-
-Using [`ALTER PRIMARY KEY`](alter-primary-key.html) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint.
-
-## 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)
-- ['ALTER PRIMARY KEY'](alter-primary-key.html)
diff --git a/src/current/v20.2/advanced-client-side-transaction-retries.md b/src/current/v20.2/advanced-client-side-transaction-retries.md
deleted file mode 100644
index a2b3cdfbca9..00000000000
--- a/src/current/v20.2/advanced-client-side-transaction-retries.md
+++ /dev/null
@@ -1,80 +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](performance-best-practices-overview.html#understanding-and-avoiding-transaction-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 shown here is a [retry savepoint](#retry-savepoints); that is, it declares the intention to retry the transaction in the case of contention errors. It must be executed after [`BEGIN`](begin-transaction.html), but before the first statement that manipulates a database. Although [nested transactions](savepoint.html#savepoints-for-nested-transactions) are supported in versions of CockroachDB 20.1 and later, a retry savepoint must be the outermost savepoint in a transaction.
-
-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 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.
-
-## Retry savepoints
-
-A savepoint defined with the name `cockroach_restart` is a "retry savepoint" and is used to implement advanced client-side transaction retries. A retry savepoint differs from a [savepoint for nested transactions](savepoint.html#savepoints-for-nested-transactions) as follows:
-
-- It must be the outermost savepoint in the transaction.
-- After a successful [`RELEASE`](release-savepoint.html), a retry savepoint does not allow further use of the transaction. The next statement must be a [`COMMIT`](commit-transaction.html).
-- It cannot be nested. Issuing `SAVEPOINT cockroach_restart` two times in a row only creates a single savepoint marker (this can be verified with [`SHOW SAVEPOINT STATUS`](show-savepoint-status.html)). Issuing `SAVEPOINT cockroach_restart` after `ROLLBACK TO SAVEPOINT cockroach_restart` reuses the marker instead of creating a new one.
-
-Note that you can [customize the retry savepoint name](#customizing-the-retry-savepoint-name) to something other than `cockroach_restart` with a session variable if you need to.
-
-## Customizing the retry 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)
-- [DB Console Transactions Page](ui-transactions-page.html)
-- [CockroachDB Architecture: Transaction Layer](architecture/transaction-layer.html)
\ No newline at end of file
diff --git a/src/current/v20.2/alembic.md b/src/current/v20.2/alembic.md
deleted file mode 100644
index 821e1a7d8e2..00000000000
--- a/src/current/v20.2/alembic.md
+++ /dev/null
@@ -1,574 +0,0 @@
----
-title: Migrate CockroachDB Schemas with Alembic
-summary: Learn how to use Alembic with a CockroachDB cluster.
-toc: true
----
-
-This page walks you through a series of simple database schema changes using the [Alembic](https://alembic.sqlalchemy.org/en/latest/) schema migration module with a simple Python application built on SQLAlchemy and CockroachDB.
-
-For a detailed tutorial about using Alembic, see the [the Alembic documentation site](https://alembic.sqlalchemy.org/en/latest/tutorial.html).
-
-For information about specific migration tasks, see Alembic's [Cookbook](https://alembic.sqlalchemy.org/en/latest/cookbook.html).
-
-## Before you begin
-
-Before you begin the tutorial, [install CockroachDB](install-cockroachdb.html).
-
-## Step 1. Start a cluster and create a database
-
-1. Start a [demo cluster](cockroach-demo.html):
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach demo --empty
-    ~~~
-
-    This command creates a virtual cluster and opens a SQL shell to that cluster.
-
-    {{site.data.alerts.callout_info}}
-    Leave this terminal window open for the duration of the tutorial. Closing the window will destroy the cluster and erase all data in it.
-    {{site.data.alerts.end}}
-
-1. Create the `bank` database:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE bank;
-    ~~~
-
-## Step 2. Get the application code
-
-1. Open a new terminal, and clone the [`example-app-python-sqlalchemy`](https://github.com/cockroachlabs/example-app-python-sqlalchemy) GitHub repository:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ git clone git@github.com:cockroachlabs/example-app-python-sqlalchemy.git
-    ~~~
-
-## Step 3. Install and initialize Alembic
-
-1. Navigate to the `example-app-python-sqlalchemy` project directory, and run the following commands to create and start a virtual environment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ python3 -m venv env
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ source env/bin/activate
-    ~~~
-
-1. Install the `alembic`, [`sqlalchemy-cockroachdb`](https://github.com/cockroachdb/sqlalchemy-cockroachdb), and [`psycopg2`](https://github.com/psycopg/psycopg2/) modules to the virtual environment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ pip install sqlalchemy-cockroachdb psycopg2-binary alembic
-    ~~~
-
-    The `sqlalchemy-cockroachdb` and `psycopg2-binary` modules are required to use the CockroachDB adapter that the app uses to run transactions against a CockroachDB cluster.
-
-    `alembic` includes the `sqlalchemy` module, which is a primary dependency of the `example-app-python-sqlalchemy` sample app. The `alembic` install also includes the `alembic` command line tool, which we use throughout the tutorial to manage migrations.
-
-1. Use the `alembic` command-line tool to initialize Alembic for the project:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ alembic init alembic
-    ~~~
-
-    ~~~
-    Creating directory /path/example-app-python-
-    sqlalchemy/alembic ...  done
-    Creating directory /path/example-app-python-
-    sqlalchemy/alembic/versions ...  done
-    Generating /path/example-app-python-
-    sqlalchemy/alembic/script.py.mako ...  done
-    Generating /path/example-app-python-
-    sqlalchemy/alembic/env.py ...  done
-    Generating /path/example-app-python-
-    sqlalchemy/alembic/README ...  done
-    Generating /path/example-app-python-
-    sqlalchemy/alembic.ini ...  done
-    Please edit configuration/connection/logging settings in
-    '/path/example-app-python-sqlalchemy/alembic.ini' before
-    proceeding.
-    ~~~
-
-    This command creates a migrations directory called `alembic`. This directory will contain the files that specify the schema migrations for the app.
-
-    The command also creates a properties file called `alembic.ini` at the top of the project directory.
-
-1. Open `alembic.ini` and update the `sqlalchemy.url` property to specify the correct connection string to your database:
-
-    For example:
-
-    ~~~
-    sqlalchemy.url = cockroachdb://root:admin@127.0.0.1:50040?sslmode=require
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    You must use the `cockroachdb://` prefix in the connection string for SQLAlchemy to make sure the CockroachDB dialect is used. Using the `postgresql://` URL prefix to connect to your CockroachDB cluster will not work.
-    {{site.data.alerts.end}}
-
-## Step 4. Create and run a migration script
-
-1. Use the `alembic` command-line tool to create the first migration script:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ alembic revision -m "create accounts table"
-    ~~~
-
-    ~~~
-    Generating /path/example-app-python-sqlalchemy/alembic/versions/ad72c7ec8b22_create_accounts_table.py ...  done
-    ~~~
-
-1. Open the newly-created migration file (`alembic/versions/ad72c7ec8b22_create_accounts_table.py`, in this case), and edit the `upgrade()` and `downgrade()` functions to read as follows:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ python
-    def upgrade():
-        op.create_table(
-            'accounts',
-            sa.Column('id', sa.dialects.postgresql.UUID, primary_key=True),
-            sa.Column('balance', sa.Integer),
-        )
-
-
-    def downgrade():
-        op.drop_table('accounts')
-    ~~~
-
-    Running this migration creates the `accounts` table, with an `id` column and a `balance` column.
-
-    Note that this file also specifies an operation for "downgrading" the migration. In this case, downgrading will drop the `accounts` table, effectively reversing the schema changes of the migration.
-
-1. Use the `alembic` tool to run this first migration:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ alembic upgrade head
-    ~~~
-
-    ~~~
-    INFO  [alembic.runtime.migration] Context impl CockroachDBImpl.
-    INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
-    INFO  [alembic.runtime.migration] Running upgrade  -> ad72c7ec8b22, create accounts table
-    ~~~
-
-    Specifying `head` runs the latest migration. This migration will create the `accounts` table. It will also create a table called `alembic_version`, which tracks the current migration version of the database.
-
-## Step 5. Verify the migration
-
-1. Open the terminal with the SQL shell to your demo cluster, and verify that the table was successfully created:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > USE bank;
-    ~~~  
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TABLES;
-    ~~~  
-
-    ~~~
-      schema_name |   table_name    | type  | owner | estimated_row_count | locality
-    --------------+-----------------+-------+-------+---------------------+-----------
-      public      | accounts        | table | demo  |                   0 | NULL
-      public      | alembic_version | table | demo  |                   1 | NULL
-    (2 rows)
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM alembic_version;
-    ~~~
-
-    ~~~
-      version_num
-    ----------------
-      ad72c7ec8b22
-    (1 row)
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SHOW COLUMNS FROM accounts;
-    ~~~
-
-    ~~~
-      column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
-    --------------+-----------+-------------+----------------+-----------------------+-----------+------------
-      id          | UUID      |    false    | NULL           |                       | {primary} |   false
-      balance     | INT8      |    true     | NULL           |                       | {}        |   false
-    (2 rows)
-    ~~~
-
-1. In a different terminal, set the `DATABASE_URL` environment variable to the connection string for your cluster:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ export DATABASE_URL=cockroachdb://demo:demo72529@127.0.0.1:26257/bank?sslmode=require
-    ~~~
-
-    The sample app reads in `DATABASE_URL` as the connection string to the database.
-
-1. Run the app to insert, update, and delete rows of data:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ python main.py
-    ~~~
-
-    ~~~
-    Creating new accounts...
-    Created new account with id e9b4a9da-fbbb-40de-8c44-60c5c741764d and balance 93911.
-    Created new account with id 34a6b5d6-0f08-4435-89cb-c7fa30037926 and balance 989744.
-    ...
-    Created new account with id 18a7a209-72c3-48b6-986c-2631fff38274 and balance 969474.
-    Created new account with id 68e73209-fe2e-42db-a54e-c9d101990cdc and balance 382471.
-    Random account balances:
-    Account 9acbf774-3e22-4d75-aee0-37e63d3b1ab6: 403963
-    Account 82451815-3a87-4d67-a9b0-7766726abd31: 315597
-    Transferring 201981 from account 9acbf774-3e22-4d75-aee0-37e63d3b1ab6 to account 82451815-3a87-4d67-a9b0-7766726abd31...
-    Transfer complete.
-    New balances:
-    Account 9acbf774-3e22-4d75-aee0-37e63d3b1ab6: 201982
-    Account 82451815-3a87-4d67-a9b0-7766726abd31: 517578
-    Deleting existing accounts...
-    Deleted account 13d1b940-9a7b-47d6-b719-6a2b49a3b08c.
-    Deleted account 6958f8f9-4d38-424c-bf41-5673f20169b1.
-    Deleted account c628bd7f-3054-4cd6-b2c9-8c2e3def1720.
-    Deleted account f4268300-6d0a-4d6e-9489-ad30f215d1ad.
-    Deleted account feae4e4a-c003-4c29-b672-5422438a885b.
-    ~~~
-
-## Step 6. Add additional migrations
-
-Suppose you want to add a new [computed column](computed-columns.html) to the `accounts` table that tracks which accounts are overdrawn.
-
-1. Create a new migration with the `alembic` tool:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ alembic revision -m "add overdrawn column"
-    ~~~
-
-    ~~~
-    Generating /path/example-app-python-sqlalchemy/alembic/versions/fd88c68af7b5_add_overdrawn_column.py ...  done
-    ~~~
-
-1. Open the migration file (`alembic/versions/fd88c68af7b5_add_overdrawn_column.py`), update the imports, and edit the `upgrade()` and `downgrade()` functions:
-
-    ~~~ python
-    from alembic import op
-    from sqlalchemy import Column, Boolean, Computed
-
-    ...
-
-    def upgrade():
-        op.add_column('accounts', sa.Column('overdrawn', Boolean, Computed('CASE WHEN balance < 0 THEN True ELSE False END')))
-
-
-    def downgrade():
-        op.drop_column('accounts', 'overdrawn')
-    ~~~
-
-1. Use the `alembic` tool to run the migration.
-
-    Because this is the latest migration, you can specify `head`, or you can use the migration's ID (`fd88c68af7b5`):
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ alembic upgrade fd88c68af7b5
-    ~~~
-
-    ~~~
-    INFO  [alembic.runtime.migration] Context impl CockroachDBImpl.
-    INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
-    INFO  [alembic.runtime.migration] Running upgrade ad72c7ec8b22 -> fd88c68af7b5, add_overdrawn_column
-    ~~~
-
-1. In the terminal with the SQL shell to your demo cluster, verify that the column was successfully created:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SHOW COLUMNS FROM accounts;
-    ~~~
-
-    ~~~
-      column_name | data_type | is_nullable | column_default |             generation_expression              |  indices  | is_hidden
-    --------------+-----------+-------------+----------------+------------------------------------------------+-----------+------------
-      id          | UUID      |    false    | NULL           |                                                | {primary} |   false
-      balance     | INT8      |    true     | NULL           |                                                | {}        |   false
-      overdrawn   | BOOL      |    true     | NULL           | CASE WHEN balance < 0 THEN true ELSE false END | {}        |   false
-    (3 rows)
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM accounts;
-    ~~~
-
-    ~~~
-                       id                  | balance | overdrawn
-    ---------------------------------------+---------+------------
-      01894212-7f32-4e4c-b855-146630d928bc |  548554 |   false
-      033131cf-7c42-4021-9a53-f8a7597ec853 |  828874 |   false
-      041a2c5d-0bce-4ed4-a91d-a9e3a6e06632 |  768526 |   false
-      080be3a3-40f8-40c6-a0cc-a61c108db3f5 |  599729 |   false
-      08503245-ba1a-4255-8ca7-22b3688e69dd |    7962 |   false
-      ...
-    ~~~
-
-    The changes will also be reflected in the `alembic_version` table.
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM alembic_version;
-    ~~~
-
-    ~~~
-      version_num
-    ----------------
-      fd88c68af7b5
-    (1 row)
-    ~~~
-
-## Execute Raw SQL with Alembic
-
-While [Alembic supports most SQL operations](https://alembic.sqlalchemy.org/en/latest/ops.html), you can always execute raw SQL using the `execute()` operation.
-
-{{site.data.alerts.callout_success}}
-Executing DDL statements as raw SQL can be particularly helpful when using SQL syntax for DDL statements specific to CockroachDB, like [`ALTER TABLE ... ALTER PRIMARY KEY`](alter-primary-key.html) statements.
-{{site.data.alerts.end}}
-
-For example, the raw SQL for the second migration would look something like this:
-
-~~~ sql
-ALTER TABLE accounts ADD COLUMN overdrawn BOOLEAN AS (
-  CASE
-    WHEN balance < 0 THEN True
-    ELSE False
-  END
-) STORED;
-~~~
-
-To make the second migration use raw SQL instead of Alembic operations, open `alembic/versions/fd88c68af7b5_add_overdrawn_column.py`, and edit the `upgrade()` function to use `execute()` instead of the operation-specific function:
-
-~~~ python
-def upgrade():
-    op.execute(text("""ALTER TABLE accounts ADD COLUMN overdrawn BOOLEAN AS (
-                        CASE
-                            WHEN balance < 0 THEN True
-                            ELSE False
-                        END
-                        ) STORED;"""))
-~~~
-
-Before running this migration, downgrade the original migration:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ alembic downgrade -1
-~~~
-
-~~~
-INFO  [alembic.runtime.migration] Context impl CockroachDBImpl.
-INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
-INFO  [alembic.runtime.migration] Running downgrade fd88c68af7b5 -> ad72c7ec8b22, add_overdrawn_column
-~~~
-
-Then, in the SQL shell to the demo cluster, verify that the `overdrawn` column has been dropped from the table:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM accounts;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  balance     | INT8      |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-Now, run the updated migration script:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ alembic upgrade fd88c68af7b5
-~~~
-
-~~~
-INFO  [alembic.runtime.migration] Context impl CockroachDBImpl.
-INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
-INFO  [alembic.runtime.migration] Running upgrade ad72c7ec8b22 -> fd88c68af7b5, add_overdrawn_column
-~~~
-
-And verify that the column has been added to the table:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM accounts;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default |             generation_expression              |  indices  | is_hidden
---------------+-----------+-------------+----------------+------------------------------------------------+-----------+------------
-  id          | UUID      |    false    | NULL           |                                                | {primary} |   false
-  balance     | INT8      |    true     | NULL           |                                                | {}        |   false
-  overdrawn   | BOOL      |    true     | NULL           | CASE WHEN balance < 0 THEN true ELSE false END | {}        |   false
-(3 rows)
-~~~
-
-## Auto-generate a Migration
-
-Alembic can automatically generate migrations, based on changes to the models in your application source code.
-
-Let's use the same example `overdrawn` computed column from above.
-
-First, downgrade the `fd88c68af7b5` migration:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ alembic downgrade -1
-~~~
-
-~~~
-INFO  [alembic.runtime.migration] Context impl CockroachDBImpl.
-INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
-INFO  [alembic.runtime.migration] Running downgrade fd88c68af7b5 -> ad72c7ec8b22, add_overdrawn_column
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM accounts;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  balance     | INT8      |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-Delete the old migration file:
-{% include_cached copy-clipboard.html %}
-~~~ shell
-rm alembic/versions/fd88c68af7b5_add_overdrawn_column.py
-~~~
-
-Open the `models.py` file in the app's project, and add the `overdrawn` column to the `Account` class definition:
-
-~~~ python
-from sqlalchemy import Column, Integer, Boolean, Computed
-
-...
-
-class Account(Base):
-    """The Account class corresponds to the "accounts" database table.
-    """
-    __tablename__ = 'accounts'
-    id = Column(UUID(as_uuid=True), primary_key=True)
-    balance = Column(Integer)
-    overdrawn = Column('overdrawn', Boolean, Computed('CASE WHEN balance < 0 THEN True ELSE False END'))
-~~~
-
-Then, open the `alembic/env.py` file, and add the following import to the top of the file:
-
-~~~ python
-from ..models import Base
-~~~
-
-And update the variable `target_metadata` to read as follows:
-
-~~~ python
-target_metadata = Base.metadata
-~~~
-
-These two lines import the database model metadata from the app.
-
-Use the `alembic` command-line tool to auto-generate the migration from the models defined in the app:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ alembic revision --autogenerate -m "add overdrawn column"
-~~~
-
-~~~
-INFO  [alembic.runtime.migration] Context impl CockroachDBImpl.
-INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
-INFO  [alembic.autogenerate.compare] Detected added column 'accounts.overdrawn'
-  Generating /path/example-app-python-sqlalchemy/alembic/versions/44fa7043e441_add_overdrawn_column.py ...  done
-~~~
-
-Alembic creates a new migration file (`44fa7043e441_add_overdrawn_column.py`, in this case).
-
-If you open this file, you'll see that it looks very similar to the one you manually created earlier in the tutorial.
-
-~~~ python
-...
-def upgrade():
-    # ### commands auto generated by Alembic - please adjust! ###
-    op.add_column('accounts', sa.Column('overdrawn', sa.Boolean(), sa.Computed('CASE WHEN balance < 0 THEN True ELSE False END', ), nullable=True))
-    # ### end Alembic commands ###
-
-
-def downgrade():
-    # ### commands auto generated by Alembic - please adjust! ###
-    op.drop_column('accounts', 'overdrawn')
-    # ### end Alembic commands ###
-~~~
-
-Run the migration:
-
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ alembic upgrade 44fa7043e441
-~~~
-
-~~~
-INFO  [alembic.runtime.migration] Context impl CockroachDBImpl.
-INFO  [alembic.runtime.migration] Will assume non-transactional DDL.
-INFO  [alembic.runtime.migration] Running upgrade ad72c7ec8b22 -> 44fa7043e441, add overdrawn column
-~~~
-
-Verify that the new column exists in the `accounts` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM accounts;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default |             generation_expression              |  indices  | is_hidden
---------------+-----------+-------------+----------------+------------------------------------------------+-----------+------------
-  id          | UUID      |    false    | NULL           |                                                | {primary} |   false
-  balance     | INT8      |    true     | NULL           |                                                | {}        |   false
-  overdrawn   | BOOL      |    true     | NULL           | CASE WHEN balance < 0 THEN true ELSE false END | {}        |   false
-(3 rows)
-~~~
-
-## Report Issues with Alembic and CockroachDB
-
-If you run into problems, please file an issue in the [`alembic` repository](https://github.com/sqlalchemy/alembic/issues), including the following details about the environment where you encountered the issue:
-
-- CockroachDB version ([`cockroach version`](cockroach-version.html))
-- Alembic version
-- Operating system
-- Steps to reproduce the behavior
-
-## See Also
-
-- [`cockroach demo`](cockroach-demo.html)
-- [Alembic documentation](https://alembic.sqlalchemy.org/en/latest/)
-- [`alembic` GitHub repository](https://github.com/sqlalchemy/alembic)
-- [Client connection parameters](connection-parameters.html)
-- [Third-Party Database Tools](third-party-database-tools.html)
-- [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
diff --git a/src/current/v20.2/alter-column.md b/src/current/v20.2/alter-column.md
deleted file mode 100644
index 25d08915dcb..00000000000
--- a/src/current/v20.2/alter-column.md
+++ /dev/null
@@ -1,129 +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
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/alter_column.html %}
-</div>
-
-## 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 with the column you want to modify. |
-| `column_name` | The name of the column you want to modify. |
-| `SET DEFAULT a_expr` | The new [Default Value](default-value.html) you want to use. |
-| `typename` | The new, altered type you want to use.<br>In CockroachDB versions < v21.1, support for altering column types is limited to increasing the precision of the current column type. For details, see [Altering column types](#altering-column-types). |
-| `USING a_expr` | <span class="version-tag">New in v20.2:</span> Specifies how to compute a new column value from the old column value. |
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Altering column types
-
-In CockroachDB versions < v21.1, support for altering column types is limited to increasing the precision of the current type of a column. You cannot convert the column type to another data type, or decrease the precision of the column type. Changing the column type from its current type to the same type and precision will result in a no-op, with no error.
-
-You can use `ALTER COLUMN TYPE` if the following conditions are met:
-
-- The on-disk representation of the column remains unchanged. For example, you cannot change the column data type from `STRING` to an `INT`.
-- The existing data remains valid. For example, you can change the column data type from `STRING[10]` to `STRING[20]`, but not to `STRING [5]` since that will invalidate the existing data.
-
-The following are equivalent in CockroachDB:
-
-- `ALTER TABLE ... ALTER ... TYPE`
-- `ALTER TABLE ... ALTER COLUMN TYPE`
-- `ALTER TABLE ... ALTER COLUMN SET DATA TYPE`
-
-For an example of `ALTER COLUMN TYPE`, see [Increase a column type's precision](#increase-a-column-types-precision).
-
-## Examples
-
-### Set or change a `DEFAULT` value
-
-Setting the [`DEFAULT` value constraint](default-value.html) inserts the value when data's written to the table without explicitly defining the value for the column. If the column already has a `DEFAULT` value set, you can use this statement to change it.
-
-The below example inserts the Boolean value `true` whenever you inserted data to the `subscriptions` table without defining a value for the `newsletter` column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE subscriptions ALTER COLUMN newsletter SET DEFAULT true;
-~~~
-
-### Remove `DEFAULT` constraint
-
-If the column has a defined [`DEFAULT` value](default-value.html), you can remove the constraint, which means the column will no longer insert a value by default if one is not explicitly defined for the column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE subscriptions ALTER COLUMN newsletter DROP DEFAULT;
-~~~
-
-### Set `NOT NULL` constraint
-
-Setting the  [`NOT NULL` constraint](not-null.html) specifies that the column cannot contain `NULL` values.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE subscriptions ALTER COLUMN newsletter SET NOT NULL;
-~~~
-
-### Remove `NOT NULL` constraint
-
-If the column has the [`NOT NULL` constraint](not-null.html) applied to it, you can remove the constraint, which means the column becomes optional and can have *NULL* values written into it.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE subscriptions ALTER COLUMN newsletter DROP NOT NULL;
-~~~
-
-### Convert a computed column into a regular column
-
-{% include {{ page.version.version }}/computed-columns/convert-computed-column.md %}
-
-### Alter the formula for a computed column
-
-{% include {{ page.version.version }}/computed-columns/alter-computed-column.md %}
-
-### Increase a column type's precision
-
-The [TPC-C](performance-benchmarking-with-tpcc-small.html) database contains a `customer` table with a column `c_credit_lim` of type [`DECIMAL(10,2)`](decimal.html). Suppose you want to increase the precision of the column's data type to `DECIMAL (12,2)`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE customer ALTER c_credit_lim type DECIMAL (12,2);
-~~~
-
-~~~
-ALTER TABLE
-
-Time: 80.814044ms
-~~~
-
-## See also
-
-- [Constraints](constraints.html)
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/alter-database.md b/src/current/v20.2/alter-database.md
deleted file mode 100644
index 62480b0cae7..00000000000
--- a/src/current/v20.2/alter-database.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: ALTER DATABASE
-summary: Use the ALTER DATABASE statement to change an existing database.
-toc: false
----
-
-The `ALTER DATABASE` [statement](sql-statements.html) applies a schema change to a database. For information on using `ALTER DATABASE`, see the pages for its relevant [subcommands](#subcommands).
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Subcommands
-
-Subcommand | Description
------------|------------
-[`CONFIGURE ZONE`](configure-zone.html) | [Configure replication zones](configure-replication-zones.html) for a database.
-[`CONVERT TO SCHEMA`](convert-to-schema.html) | <span class="version-tag">New in v20.2</span>: Convert a [database](create-database.html) to a [schema](sql-name-resolution.html).
-[`OWNER TO`](owner-to.html) | <span class="version-tag">New in v20.2</span>: Change the owner of a database.
-[`RENAME`](rename-database.html) | Change the name of a database.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
diff --git a/src/current/v20.2/alter-index.md b/src/current/v20.2/alter-index.md
deleted file mode 100644
index e14615f48c4..00000000000
--- a/src/current/v20.2/alter-index.md
+++ /dev/null
@@ -1,23 +0,0 @@
----
-title: ALTER INDEX
-summary: Use the ALTER INDEX statement to change an existing index.
-toc: true
----
-
-The `ALTER INDEX` [statement](sql-statements.html) applies a schema change to an index. For information on using `ALTER INDEX`, see the pages for its relevant [subcommands](#subcommands).
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Subcommands
-
-Subcommand | Description
------------|------------
-[`CONFIGURE ZONE`](configure-zone.html) | [Configure replication zones](configure-replication-zones.html) for an index.
-[`PARTITION BY`](partition-by.html)  | Partition, re-partition, or un-partition an index. ([Enterprise-only](enterprise-licensing.html)).
-[`RENAME`](rename-index.html) | Change the name of an index.
-[`SPLIT AT`](split-at.html) | Force a range split at the specified row in the index.
-[`UNSPLIT AT`](unsplit-at.html) | Remove a range split enforcement at a specified row in the index.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
diff --git a/src/current/v20.2/alter-partition.md b/src/current/v20.2/alter-partition.md
deleted file mode 100644
index d5b7c8df7d5..00000000000
--- a/src/current/v20.2/alter-partition.md
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: ALTER PARTITION
-summary: Use the ALTER PARTITION statement to configure the replication zone for a partition.
-toc: true
----
-
-The `ALTER PARTITION` [statement](sql-statements.html) is used to configure replication zones for [partitioning](partitioning.html). See the [`CONFIGURE ZONE`](configure-zone.html) subcommand for more details.
-
-{% include enterprise-feature.md %}
-
-## Synopsis
-
-<div>
-{% remote_include https://raw.githubusercontent.com/cockroachdb/generated-diagrams/{{ page.release_info.crdb_branch_name }}/grammar_svg/alter_zone_partition.html %}
-</div>
-
-## Required privileges
-
-The user must have the [`CREATE`](grant.html#supported-privileges) privilege on the table.
-
-## Parameters
-
- Parameter | Description
------------+-------------
-`table_name` | The name of the [table](create-table.html) with the [replication zone configurations](configure-replication-zones.html) to modify.
-`partition_name` | The name of the [partition](partitioning.html) with the [replication zone configurations](configure-replication-zones.html) to modify.
-`index_name` | The name of the [index](indexes.html) with the [replication zone configurations](configure-replication-zones.html) to modify.
-`variable` | The name of the [variable](#variables) to change.
-`value` | The value of the variable to change.
-
-### Variables
-
-{% include {{ page.version.version }}/zone-configs/variables.md %}
-
-## Examples
-
-{% include {{ page.version.version }}/sql/movr-statements-geo-partitioned-replicas.md %}
-
-### Create a replication zone for a partition
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-table-partition.md hide-enterprise-warning="true" %}
diff --git a/src/current/v20.2/alter-primary-key.md b/src/current/v20.2/alter-primary-key.md
deleted file mode 100644
index 0b6a71ce1b1..00000000000
--- a/src/current/v20.2/alter-primary-key.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: ALTER PRIMARY KEY
-summary: Use the ALTER PRIMARY KEY statement to change the primary key of a table.
-toc: true
----
-
-  The `ALTER PRIMARY KEY` [statement](sql-statements.html) is a subcommand of [`ALTER TABLE`](alter-table.html) that can be used to change the [primary key](primary-key.html) of a table.
-
-## Watch the demo
-
-{% include_cached youtube.html video_id="MPx-LXY2D-c" %}
-
-## Details
-
-- You cannot change the primary key of a table that is currently undergoing a primary key change, or any other [schema change](online-schema-changes.html).
-
-- `ALTER PRIMARY KEY` might need to rewrite multiple indexes, which can make it an expensive operation.
-
--  When you change a primary key with `ALTER PRIMARY KEY`, the old primary key index becomes a [`UNIQUE`](unique.html) secondary index. This helps optimize the performance of queries that still filter on the old primary key column.
-
-- `ALTER PRIMARY KEY` does not alter the [partitions](partitioning.html) on a table or its indexes, even if a partition is defined on [a column in the original primary key](partitioning.html#partition-using-primary-key). If you alter the primary key of a partitioned table, you must update the table partition accordingly.
-
-- The secondary index created by `ALTER PRIMARY KEY` will not be partitioned, even if a partition is defined on [a column in the original primary key](partitioning.html#partition-using-primary-key). To ensure that the table is partitioned correctly, you must create a partition on the secondary index, or drop the secondary index.
-
-- Any new primary key column set by `ALTER PRIMARY KEY` must have an existing [`NOT NULL` constraint](not-null.html). To add a `NOT NULL` constraint to an existing column, use [`ALTER TABLE ... ALTER COLUMN ... SET NOT NULL`](alter-column.html#set-not-null-constraint).
-
-{{site.data.alerts.callout_success}}
-To change an existing primary key without creating a secondary index from that primary key, use [`DROP CONSTRAINT ... PRIMARY KEY`/`ADD CONSTRAINT ... PRIMARY KEY`](add-constraint.html#changing-primary-keys-with-add-constraint-primary-key). For examples, see the [`ADD CONSTRAINT`](add-constraint.html#examples) and [`DROP CONSTRAINT`](drop-constraint.html#examples) pages.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/alter_primary_key.html %}
-</div>
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table with the primary key that you want to modify.
- `index_params` | The name of the column(s) that you want to use for the primary key. These columns replace the current primary key column(s).
- `USING HASH WITH BUCKET COUNT` | Creates a [hash-sharded index](hash-sharded-indexes.html) with `n_buckets` number of buckets.<br>{{site.data.alerts.callout_info}}To enable hash-sharded indexes, set the `experimental_enable_hash_sharded_indexes` [session variable](set-vars.html) to `on`.{{site.data.alerts.end}}
- `opt_interleave` | [Interleave table into parent object](interleave-in-parent.html).<br>{% include {{ page.version.version }}/misc/interleave-deprecation-note.md %}
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on a table to alter its primary key.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-### Alter a single-column primary key
-
-Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-  name STRING PRIMARY KEY,
-  email STRING
-);
-~~~
-
-The primary key of this table is on the `name` column. This is a poor choice, as some users likely have the same name, and all primary keys enforce a `UNIQUE` constraint on row values of the primary key column. Per our [best practices](performance-best-practices-overview.html#use-uuid-to-generate-unique-ids), you should instead use a `UUID` for single-column primary keys, and populate the rows of the table with generated, unique values.
-
-You can add a column and change the primary key with a couple of `ALTER TABLE` statements:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users ADD COLUMN id UUID NOT NULL DEFAULT gen_random_uuid();
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users ALTER PRIMARY KEY USING COLUMNS (id);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                create_statement
--------------+--------------------------------------------------
-  users      | CREATE TABLE users (
-             |     name STRING NOT NULL,
-             |     email STRING NULL,
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     UNIQUE INDEX users_name_key (name ASC),
-             |     FAMILY "primary" (name, email, id)
-             | )
-(1 row)
-~~~
-
-Note that the old primary key index becomes a secondary index, in this case, `users_name_key`. If you do not want the old primary key to become a secondary index when changing a primary key, you can use [`DROP CONSTRAINT`](drop-constraint.html)/[`ADD CONSTRAINT`](add-constraint.html) instead.
-
-### Make a single-column primary key composite for geo-partitioning
-
-Suppose that you are storing the data for users of your application in a table called `users`, defined by the following `CREATE TABLE` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-  email STRING,
-  name STRING,
-  INDEX users_name_idx (name)
-);
-~~~
-
-Now suppose that you want to expand your business from a single region into multiple regions. After you [deploy your application in multiple regions](topology-patterns.html), you consider [geo-partitioning your data](topology-geo-partitioned-replicas.html) to minimize latency and optimize performance. In order to geo-partition the `user` database, you need to add a column specifying the location of the data (e.g., `region`):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users ADD COLUMN region STRING NOT NULL;
-~~~
-
-When you geo-partition a database, you [partition the database on a primary key column](partitioning.html#partition-using-primary-key). The primary key of this table is still on `id`. Change the primary key to be composite, on `region` and `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users ALTER PRIMARY KEY USING COLUMNS (region, id);
-~~~
-{{site.data.alerts.callout_info}}
-The order of the primary key columns is important when geo-partitioning. For performance, always place the partition column first.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                      create_statement
--------------+-------------------------------------------------------------
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     email STRING NULL,
-             |     name STRING NULL,
-             |     region STRING NOT NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (region ASC, id ASC),
-             |     UNIQUE INDEX users_id_key (id ASC),
-             |     INDEX users_name_idx (name ASC),
-             |     FAMILY "primary" (id, email, name, region)
-             | )
-(1 row)
-~~~
-
-Note that the old primary key index on `id` is now the secondary index `users_id_key`.
-
-With the new primary key on `region` and `id`, the table is ready to be [geo-partitioned](topology-geo-partitioned-replicas.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users PARTITION BY LIST (region) (
-    PARTITION us_west VALUES IN ('us_west'),
-    PARTITION us_east VALUES IN ('us_east')
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION us_west OF INDEX users@primary
-    CONFIGURE ZONE USING constraints = '[+region=us-west1]';
-  ALTER PARTITION us_east OF INDEX users@primary
-    CONFIGURE ZONE USING constraints = '[+region=us-east1]';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW PARTITIONS FROM TABLE users;
-~~~
-
-~~~
-  database_name | table_name | partition_name | parent_partition | column_names |  index_name   | partition_value |            zone_config             |          full_zone_config
-----------------+------------+----------------+------------------+--------------+---------------+-----------------+------------------------------------+--------------------------------------
-  movr          | users      | us_west        | NULL             | region       | users@primary | ('us_west')     | constraints = '[+region=us-west1]' | range_min_bytes = 134217728,
-                |            |                |                  |              |               |                 |                                    | range_max_bytes = 536870912,
-                |            |                |                  |              |               |                 |                                    | gc.ttlseconds = 90000,
-                |            |                |                  |              |               |                 |                                    | num_replicas = 3,
-                |            |                |                  |              |               |                 |                                    | constraints = '[+region=us-west1]',
-                |            |                |                  |              |               |                 |                                    | lease_preferences = '[]'
-  movr          | users      | us_east        | NULL             | region       | users@primary | ('us_east')     | constraints = '[+region=us-east1]' | range_min_bytes = 134217728,
-                |            |                |                  |              |               |                 |                                    | range_max_bytes = 536870912,
-                |            |                |                  |              |               |                 |                                    | gc.ttlseconds = 90000,
-                |            |                |                  |              |               |                 |                                    | num_replicas = 3,
-                |            |                |                  |              |               |                 |                                    | constraints = '[+region=us-east1]',
-                |            |                |                  |              |               |                 |                                    | lease_preferences = '[]'
-(2 rows)
-~~~
-
-The table is now geo-partitioned on the `region` column.
-
-You now need to geo-partition any secondary indexes in the table. In order to geo-partition an index, the index must be prefixed by a column that can be used as a partitioning identifier (in this case, `region`). Currently, neither of the secondary indexes (i.e., `users_id_key` and `users_name_idx`) are prefixed by the `region` column, so they cannot be meaningfully geo-partitioned. Any secondary indexes that you want to keep must be dropped, recreated, and then partitioned.
-
-Start by dropping both indexes:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP INDEX users_id_key CASCADE;
-  DROP INDEX users_name_idx CASCADE;
-~~~
-
-You do not need to recreate the index on `id` with `region`. Both columns are already indexed by the new primary key.
-
-Add `region` to the index on `name`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users(region, name);
-~~~
-
-Then geo-partition the index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX users_region_name_idx PARTITION BY LIST (region) (
-    PARTITION us_west VALUES IN ('us_west'),
-    PARTITION us_east VALUES IN ('us_east')
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION us_west OF INDEX users@users_region_name_idx
-    CONFIGURE ZONE USING constraints = '[+region=us-west1]';
-  ALTER PARTITION us_east OF INDEX users@users_region_name_idx
-    CONFIGURE ZONE USING constraints = '[+region=us-east1]';
-~~~
-
-
-## See also
-
-- [Constraints](constraints.html)
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/alter-range.md b/src/current/v20.2/alter-range.md
deleted file mode 100644
index 664d8b7f1d0..00000000000
--- a/src/current/v20.2/alter-range.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-title: ALTER RANGE
-summary: Use the ALTER RANGE statement to configure the replication zone for a system range.
-toc: true
----
-
-The `ALTER RANGE` [statement](sql-statements.html) is used to configure replication zones for system ranges. See the [`CONFIGURE ZONE`](configure-zone.html) subcommand for more details.
diff --git a/src/current/v20.2/alter-role.md b/src/current/v20.2/alter-role.md
deleted file mode 100644
index 5ff029508ab..00000000000
--- a/src/current/v20.2/alter-role.md
+++ /dev/null
@@ -1,126 +0,0 @@
----
-title: ALTER ROLE
-summary: The ALTER ROLE statement can be used to add or change a role's password.
-toc: true
----
-
- The `ALTER ROLE` [statement](sql-statements.html) can be used to add, change, or remove a [role's](create-role.html) password and to change the role options for a role.
-
-{{site.data.alerts.callout_info}}
-Since the keywords `ROLE` and `USER` can now be used interchangeably in SQL statements for enhanced Postgres compatibility, `ALTER ROLE` is now an alias for [`ALTER USER`](alter-user.html).
-{{site.data.alerts.end}}
-
-## Considerations
-
-- Password creation and alteration is supported only in secure clusters.
-
-## Required privileges
-
- To alter other roles, the role must be a member of the `admin` role or have the [`CREATEROLE`](create-role.html#create-a-role-that-can-create-other-roles-and-manage-authentication-methods-for-the-new-roles) role option set.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/alter_role.html %}</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
-Parameter | Description
-----------|-------------
-`name` | The name of the role whose parameters you want to alter.
-`CREATELOGIN`/`NOCREATELOGIN` | Allow or disallow the role to manage authentication using the `WITH PASSWORD`, `VALID UNTIL`, and `LOGIN/NOLOGIN` role options. <br><br>By default, the role option is set to `NOCREATELOGIN` for all non-admin roles.
-`LOGIN`/`NOLOGIN` | The `LOGIN` role option allows a role to login with one of the [client authentication methods](authentication.html#client-authentication). Setting the role option to `NOLOGIN` prevents the role from logging in using any authentication method.
-`password` | Let the role [authenticate their access to a secure cluster](authentication.html#client-authentication) using this new password. Passwords should be entered as a [string literal](sql-constants.html#string-literals). For compatibility with PostgreSQL, a password can also be entered as an identifier. <br><br>To prevent a role from using [password authentication](authentication.html#client-authentication) and to mandate [certificate-based client authentication](authentication.html#client-authentication), [set the password as `NULL`](#prevent-a-role-from-using-password-authentication).
-`VALID UNTIL` | The date and time (in the [`timestamp`](timestamp.html) format) after which the password is not valid.
-`CREATEROLE`/`NOCREATEROLE` | Allow or disallow the role to [create](create-role.html), alter, and [drop](drop-role.html) other non-admin roles. <br><br>By default, the role option is set to `NOCREATEROLE` for all non-admin roles.
-`CREATEDB`/`NOCREATEDB` | Allow or disallow the role to [create](create-database.html) or [rename](rename-database.html) a database. The role is assigned as the owner of the database. <br><br>By default, the role option is set to `NOCREATEDB` for all non-admin roles.
-`CONTROLJOB`/`NOCONTROLJOB` | Allow or disallow the role to [pause](pause-job.html), [resume](resume-job.html), and [cancel](cancel-job.html) jobs. Non-admin roles cannot control jobs created by admins. <br><br>By default, the role option is set to `NOCONTROLJOB` for all non-admin roles.
-`CANCELQUERY`/`NOCANCELQUERY` | Allow or disallow the role to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) of other roles. Without this privilege, roles can only cancel their own queries and sessions. Even with this privilege, non-admins cannot cancel admin queries or sessions. This option should usually be combined with `VIEWACTIVITY` so that the role can view other roles' query and session information. <br><br>By default, the role option is set to `NOCANCELQUERY` for all non-admin roles.
-`VIEWACTIVITY`/`NOVIEWACTIVITY` | Allow or disallow a role to see other roles' [queries](show-queries.html) and [sessions](show-sessions.html) using `SHOW QUERIES`, `SHOW SESSIONS`, and the [**Statements**](ui-statements-page.html) and **Transactions** pages in the DB Console. Without this privilege, the `SHOW` commands only show the role's own data and the DB Console pages are unavailable. <br><br>By default, the role option is set to `NOVIEWACTIVITY` for all non-admin roles.
-`CONTROLCHANGEFEED`/`NOCONTROLCHANGEFEED` | Allow or disallow the role to run [`CREATE CHANGEFEED`](create-changefeed.html) on tables they have `SELECT` privileges on. <br><br>By default, the role option is set to `NOCONTROLCHANGEFEED` for all non-admin roles.
-`MODIFYCLUSTERSETTING`/`NOMODIFYCLUSTERSETTING` | Allow or disallow the role to modify the [cluster settings](cluster-settings.html) with the `sql.defaults` prefix. <br><br>By default, the role option is set to `NOMODIFYCLUSTERSETTING` for all non-admin roles.
-
-## Examples
-
-{{site.data.alerts.callout_info}}
-The following statements are run by the `root` user that is a member of the `admin` role and has `ALL` privileges.
-{{site.data.alerts.end}}
-
-### Allow a role to log in to the database using a password
-
-The following example allows a role to log in to the database with a [password](authentication.html#client-authentication):
-
-~~~ sql
-root@:26257/defaultdb> ALTER ROLE carl WITH LOGIN PASSWORD 'An0ther$tr0nGpassW0rD' VALID UNTIL '2021-10-10';
-~~~
-
-### Prevent a role from using password authentication
-
-The following statement prevents the user from using password authentication and mandates certificate-based [client authentication](authentication.html#client-authentication):
-
-{% include copy-clipboard.html %}
-~~~ sql
-root@:26257/defaultdb> ALTER ROLE carl WITH PASSWORD NULL;
-~~~
-
-### Allow a role to create other roles and manage authentication methods for the new roles
-
-The following example allows the role to [create other roles](create-role.html) and [manage authentication methods](authentication.html#client-authentication) for them:
-
-~~~ sql
-root@:26257/defaultdb> ALTER ROLE carl WITH CREATEROLE CREATELOGIN;
-~~~
-
-### Allow a role to create and rename databases
-
-The following example allows the role to [create](create-database.html) or [rename](rename-database.html) databases:
-
-~~~ sql
-root@:26257/defaultdb> ALTER ROLE carl WITH CREATEDB;
-~~~
-
-### Allow a role to pause, resume, and cancel non-admin jobs
-
-The following example allows the role to [pause](pause-job.html), [resume](resume-job.html), and [cancel](cancel-job.html) jobs:
-
-~~~ sql
-root@:26257/defaultdb> ALTER ROLE carl WITH CONTROLJOB;
-~~~
-
-### Allow a role to see and cancel non-admin queries and sessions
-
-The following example allows the role to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) for other non-admin roles:
-
-~~~ sql
-root@:26257/defaultdb> ALTER ROLE carl WITH CANCELQUERY VIEWACTIVITY;
-~~~
-
-### Allow a role to control changefeeds
-
-The following example allows the role to run [`CREATE CHANGEFEED`](create-changefeed.html):
-
-~~~ sql
-root@:26257/defaultdb> ALTER ROLE carl WITH CONTROLCHANGEFEED;
-~~~
-
-### Allow a role to modify cluster settings
-
-The following example allows the role to modify [cluster settings](cluster-settings.html):
-
-~~~ sql
-root@:26257/defaultdb> ALTER ROLE carl WITH MODIFYCLUSTERSETTING;
-~~~
-
-## See also
-
-- [`DROP ROLE`](drop-role.html)
-- [`SHOW ROLES`](show-roles.html)
-- [`GRANT <privileges>`](grant.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [Create Security Certificates](cockroach-cert.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/alter-schema.md b/src/current/v20.2/alter-schema.md
deleted file mode 100644
index d739d480047..00000000000
--- a/src/current/v20.2/alter-schema.md
+++ /dev/null
@@ -1,200 +0,0 @@
----
-title: ALTER SCHEMA
-summary: The ALTER SCHEMA statement modifies a user-defined schema in a database.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `ALTER SCHEMA` [statement](sql-statements.html) modifies a user-defined [schema](sql-name-resolution.html#naming-hierarchy) in the current database. CockroachDB currently supports changing the name of the schema and the owner of the schema.
-
-## Syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/alter_schema.html %}
-</div>
-
-### Parameters
-
-Parameter | Description
-----------|------------
-`schema_name` | The name of the schema to alter.
-`RENAME TO schema_name` | Rename the schema to `schema_name`. The new schema name must be unique within the database and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
-`OWNER TO role_spec` | Change the owner of the schema to `role_spec`.
-
-## Required privileges
-
-- To rename a schema, the user must be the owner of the schema.
-- To change the owner of a schema, the user must be the current owner of the schema and a member of the new owner [role](authorization.html#roles). The new owner role must also have the `CREATE` [privilege](authorization.html#assign-privileges) on the database to which the schema belongs.
-
-## Example
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Rename a schema
-
-Suppose that you access the [SQL shell](cockroach-sql.html) as user `root`, and [create a new user](create-user.html) `max` and [a schema](create-schema.html) `org_one` with `max` as the owner:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE USER max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_one AUTHORIZATION max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_one
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-Now, suppose you want to rename the schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER SCHEMA org_one RENAME TO org_two;
-~~~
-
-~~~
-ERROR: must be owner of schema "org_one"
-SQLSTATE: 42501
-~~~
-
-Because you are executing the `ALTER SCHEMA` command as a non-owner of the schema (i.e., `root`), CockroachDB returns an error.
-
-[Drop the schema](drop-schema.html) and create it again, this time with `root` as the owner.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP SCHEMA org_one;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_one;
-~~~
-
-To verify that the owner is now `root`, query the `pg_catalog.pg_namespace` and `pg_catalog.pg_users` tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT
-  nspname, usename
-FROM
-  pg_catalog.pg_namespace
-  LEFT JOIN pg_catalog.pg_user ON pg_namespace.nspowner = pg_user.usesysid
-WHERE
-  nspname LIKE 'org_one';
-~~~
-
-~~~
-  nspname | usename
-----------+----------
-  org_one | root
-(1 row)
-~~~
-
-As its owner, you can rename the schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER SCHEMA org_one RENAME TO org_two;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_two
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-### Change a schema's owner
-
-Suppose that you access the [SQL shell](cockroach-sql.html) as user `root`, and [create a new schema](create-schema.html) named `org_one`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_one;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_one
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-Now, suppose that you want to change the owner of the schema `org_one` to an existing user named `max`. To change the owner of a schema, the current owner must belong to the role of the new owner (in this case, `max`), and the new owner must have `CREATE` privileges on the database.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT max TO root;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT CREATE ON DATABASE defaultdb TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER SCHEMA org_one OWNER TO max;
-~~~
-
-To verify that the owner is now `max`, query the `pg_catalog.pg_namespace` and `pg_catalog.pg_users` tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT
-  nspname, usename
-FROM
-  pg_catalog.pg_namespace
-  LEFT JOIN pg_catalog.pg_user ON pg_namespace.nspowner = pg_user.usesysid
-WHERE
-  nspname LIKE 'org_one';
-~~~
-
-~~~
-  nspname | usename
-----------+----------
-  org_one | max
-(1 row)
-~~~
-
-## See also
-
-- [`CREATE SCHEMA`](create-schema.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [`DROP SCHEMA`](drop-schema.html)
diff --git a/src/current/v20.2/alter-sequence.md b/src/current/v20.2/alter-sequence.md
deleted file mode 100644
index 71f5c1e81ae..00000000000
--- a/src/current/v20.2/alter-sequence.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: ALTER SEQUENCE
-summary: Use the ALTER SEQUENCE statement to change the name, increment values, and other settings of a sequence.
-toc: true
----
-
-The `ALTER SEQUENCE` [statement](sql-statements.html) applies a [schema change](online-schema-changes.html) to a sequence.
-
-
-{{site.data.alerts.callout_info}}
-This page documents all supported sequence changes except for changing the name of a sequence and changing the schema of a sequence. For information about changing the name of a sequence, see [`RENAME SEQUENCE`](rename-sequence.html). For information about changing the schema of a sequence, see [`SET SCHEMA`](set-schema.html).
-{{site.data.alerts.end}}
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the parent database.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/alter_sequence_options.html %}</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
- Parameter | Description
------------|------------
-`IF EXISTS` | Modify the sequence only if it exists; if it does not exist, do not return an error.
-`sequence_name` | The name of the sequence you want to modify.
-`INCREMENT` | The new value by which the sequence is incremented. A negative number creates a descending sequence. A positive number creates an ascending sequence.
-`MINVALUE` | The new minimum value of the sequence. <br><br>**Default:** `1`
-`MAXVALUE` | The new maximum value of the sequence. <br><br>**Default:** `9223372036854775807`
-`START` | The value the sequence starts at if you `RESTART` or if the sequence hits the `MAXVALUE` and `CYCLE` is set. <br><br>`RESTART` and `CYCLE` are not implemented yet.
-`CYCLE` | The sequence will wrap around when the sequence value hits the maximum or minimum value. If `NO CYCLE` is set, the sequence will not wrap.
-`OWNED BY column_name` | Associates the sequence to a particular column. If that column or its parent table is dropped, the sequence will also be dropped.<br><br>Specifying an owner column with `OWNED BY` replaces any existing owner column on the sequence. To remove existing column ownership on the sequence and make the column free-standing, specify `OWNED BY NONE`.<br><br>**Default:** `NONE`
-
-## Examples
-
-### Change the increment value of a sequence
-
-In this example, we're going to change the increment value of a sequence from its current state (i.e., `1`) to `2`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE customer_seq;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE customer_seq;
-~~~
-
-~~~
-   table_name  |                                     create_statement
----------------+-------------------------------------------------------------------------------------------
-  customer_seq | CREATE SEQUENCE customer_seq MINVALUE 1 MAXVALUE 9223372036854775807 INCREMENT 1 START 1
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER SEQUENCE customer_seq INCREMENT 2;
-~~~
-
-~~~
-   table_name  |                                        create_statement
----------------+--------------------------------------------------------------------------------------------------
-  customer_seq | CREATE SEQUENCE public.customer_seq MINVALUE 1 MAXVALUE 9223372036854775807 INCREMENT 2 START 1
-(1 row)
-~~~
-
-## See also
-
-- [`RENAME SEQUENCE`](rename-sequence.html)
-- [`CREATE SEQUENCE`](create-sequence.html)
-- [`DROP SEQUENCE`](drop-sequence.html)
-- [`SHOW SEQUENCES`](show-sequences.html)
-- [`SET SCHEMA`](set-schema.html)
-- [Functions and Operators](functions-and-operators.html)
-- [Other SQL Statements](sql-statements.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/alter-table.md b/src/current/v20.2/alter-table.md
deleted file mode 100644
index 0c249a2c645..00000000000
--- a/src/current/v20.2/alter-table.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: ALTER TABLE
-summary: Use the ALTER TABLE statement to change the schema of a table.
-toc: true
----
-
-The `ALTER TABLE` [statement](sql-statements.html) applies a schema change to a table. For information on using `ALTER TABLE`, see the pages for its relevant [subcommands](#subcommands).
-
-{% include {{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Subcommands
-
-{{site.data.alerts.callout_success}}
-Some subcommands can be used in combination in a single `ALTER TABLE` statement. For example, you can [atomically rename a column and add a new column with the old name of the existing column](rename-column.html#add-and-rename-columns-atomically).
-{{site.data.alerts.end}}
-
-Subcommand | Description | Can combine with other subcommands?
------------|-------------|------------------------------------
-[`ADD COLUMN`](add-column.html) | Add columns to tables. | Yes
-[`ADD CONSTRAINT`](add-constraint.html) | Add constraints to columns. | Yes
-[`ALTER COLUMN`](alter-column.html) | Change an existing column. | Yes
-[`ALTER PRIMARY KEY`](alter-primary-key.html) |  Change the [primary key](primary-key.html) of a table. | Yes | No
-[`DROP COLUMN`](drop-column.html) | Remove columns from tables. | Yes
-[`DROP CONSTRAINT`](drop-constraint.html) | Remove constraints from columns. | Yes
-[`EXPERIMENTAL_AUDIT`](experimental-audit.html) | Enable per-table audit logs, for security purposes. | Yes
-[`OWNER TO`](owner-to.html) | <span class="version-tag">New in v20.2</span>: Change the owner of the table.
-[`PARTITION BY`](partition-by.html)  | Partition, re-partition, or un-partition a table ([Enterprise-only](enterprise-licensing.html)). | Yes
-[`RENAME COLUMN`](rename-column.html) | Change the names of columns. | Yes
-[`RENAME CONSTRAINT`](rename-constraint.html) | Change constraints columns. | Yes
-[`RENAME TO`](rename-table.html) | Change the names of tables. | No
-[`SET SCHEMA`](set-schema.html) | <span class="version-tag">New in v20.2</span>: Change the [schema](sql-name-resolution.html) of a table. | No
-[`SPLIT AT`](split-at.html) | Force a range split at the specified row in the table. | No
-[`UNSPLIT AT`](unsplit-at.html) | Remove a range split enforcement at a specified row in the table. | No
-[`VALIDATE CONSTRAINT`](validate-constraint.html) | Check whether values in a column match a [constraint](constraints.html) on the column. | Yes
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
diff --git a/src/current/v20.2/alter-type.md b/src/current/v20.2/alter-type.md
deleted file mode 100644
index edd936b668c..00000000000
--- a/src/current/v20.2/alter-type.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: ALTER TYPE
-summary: The ALTER TYPE statement modifies a user-defined data type in a database.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `ALTER TYPE` [statement](sql-statements.html) modifies a user-defined, [enumerated data type](enum.html) in the current database.
-
-{{site.data.alerts.callout_info}}
-You can only reference a user-defined type from the database that contains the type.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/alter_type.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`type_name` | The name of the user-defined type.
-`ADD VALUE value` | Add a constant value to the user-defined type's list of values. You can optionally specify `BEFORE value` or `AFTER value` to add the value in sort order relative to an existing value.
-`RENAME TO name` | Rename the user-defined type.
-`RENAME VALUE value TO value` |  Rename a constant value in the user-defined type's list of values.
-`SET SCHEMA`  | Set [the schema](sql-name-resolution.html) of the user-defined type.
-`OWNER TO`  | Change the [role specification](grant-roles.html) for the user-defined type's owner.
-
-## Required privileges
-
-- To [alter a type](alter-type.html), the user must be the owner of the type.
-- To set the schema of a user-defined type, the user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the schema and the `DROP` privilege
-on the type.
-- To alter the owner of a user-defined type:
-    - The user executing the command must be a member of the new owner role.
-    - The new owner role must have the `CREATE` privilege on the schema the type belongs to.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE status AS ENUM ('open', 'closed', 'inactive');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema |  name  |        value
----------+--------+-----------------------
-  public | status | open|closed|inactive
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TYPE status ADD VALUE 'pending';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TYPE status RENAME VALUE 'open' TO 'active';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TYPE status RENAME TO account_status;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema |      name      |             value
----------+----------------+---------------------------------
-  public | account_status | active|closed|inactive|pending
-(1 row)
-~~~
-
-## See also
-
-- [`CREATE TYPE`](create-type.html)
-- [`ENUM`](enum.html)
-- [`SHOW ENUMS`](show-enums.html)
-- [`DROP TYPE`](drop-type.html)
diff --git a/src/current/v20.2/alter-user.md b/src/current/v20.2/alter-user.md
deleted file mode 100644
index f3136829a5c..00000000000
--- a/src/current/v20.2/alter-user.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: ALTER USER
-summary: The ALTER USER statement can be used to add or change a user's password.
-toc: true
----
-
-The `ALTER USER` [statement](sql-statements.html) can be used to add, change, or remove a [user's](create-user.html) password and to change the role options for a user.
-
-{{site.data.alerts.callout_info}}
- Since the keywords `ROLE` and `USER` can now be used interchangeably in SQL statements for enhanced Postgres compatibility, `ALTER USER` is now an alias for [`ALTER ROLE`](alter-role.html).
-{{site.data.alerts.end}}
-
-## Considerations
-
-- Password creation and alteration is supported only in secure clusters.
-
-## Required privileges
-
- To alter other users, the user must be a member of the `admin` role or have the [`CREATEROLE`](create-user.html#create-a-user-that-can-create-other-users-and-manage-authentication-methods-for-the-new-users) parameter set.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/alter_user_password.html %}</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
-Parameter | Description
-----------|-------------
-`name` | The name of the user whose role options you want to alter.
-`CREATELOGIN`/`NOCREATELOGIN` | Allow or disallow the user to manage authentication using the `WITH PASSWORD`, `VALID UNTIL`, and `LOGIN/NOLOGIN` parameters. <br><br>By default, the parameter is set to `NOCREATELOGIN` for all non-admin users.
-`LOGIN`/`NOLOGIN` | The `LOGIN` parameter allows a user to login with one of the [client authentication methods](authentication.html#client-authentication). Setting the parameter to `NOLOGIN` prevents the user from logging in using any authentication method.
-`password` | Let the user [authenticate their access to a secure cluster](authentication.html#client-authentication) using this new password. Passwords should be entered as a [string literal](sql-constants.html#string-literals). For compatibility with PostgreSQL, a password can also be entered as an identifier. <br><br>To prevent a user from using [password authentication](authentication.html#client-authentication) and to mandate [certificate-based client authentication](authentication.html#client-authentication), [set the password as `NULL`](#prevent-a-user-from-using-password-authentication).
-`VALID UNTIL` |  The date and time (in the [`timestamp`](timestamp.html) format) after which the password is not valid.
-`CREATEROLE`/`NOCREATEROLE` |  Allow or disallow the user to [create](create-user.html), alter, and [drop](drop-user.html) other non-admin users. <br><br>By default, the parameter is set to `NOCREATEROLE` for all non-admin users.
-`CREATEDB`/`NOCREATEDB` | Allow or disallow the user to [create](create-database.html) or [rename](rename-database.html) a database. The user is assigned as the owner of the database. <br><br>By default, the parameter is set to `NOCREATEDB` for all non-admin users.
-`CONTROLJOB`/`NOCONTROLJOB` | Allow or disallow the user to [pause](pause-job.html), [resume](resume-job.html), and [cancel](cancel-job.html) jobs. Non-admin users cannot control jobs created by admins. <br><br>By default, the parameter is set to `NOCONTROLJOB` for all non-admin users.
-`CANCELQUERY`/`NOCANCELQUERY` | Allow or disallow the user to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) of other users. Without this privilege, users can only cancel their own queries and sessions. Even with this privilege, non-admins cannot cancel admin queries or sessions. This option should usually be combined with `VIEWACTIVITY` so that the user can view other users' query and session information. <br><br>By default, the parameter is set to `NOCANCELQUERY` for all non-admin users.
-`VIEWACTIVITY`/`NOVIEWACTIVITY` | Allow or disallow a role to see other users' [queries](show-queries.html) and [sessions](show-sessions.html) using `SHOW QUERIES`, `SHOW SESSIONS`, and the [**Statements**](ui-statements-page.html) and **Transactions** pages in the DB Console. Without this privilege, the `SHOW` commands only show the user's own data and the DB Console pages are unavailable. <br><br>By default, the parameter is set to `NOVIEWACTIVITY` for all non-admin users.
-`CONTROLCHANGEFEED`/`NOCONTROLCHANGEFEED` | Allow or disallow the user to run [`CREATE CHANGEFEED`](create-changefeed.html) on tables they have `SELECT` privileges on. <br><br>By default, the parameter is set to `NOCONTROLCHANGEFEED` for all non-admin users.
-`MODIFYCLUSTERSETTING`/`NOMODIFYCLUSTERSETTING` | Allow or disallow the user to modify the [cluster settings](cluster-settings.html) with the `sql.defaults` prefix. <br><br>By default, the parameter is set to `NOMODIFYCLUSTERSETTING` for all non-admin users.
-
-## Examples
-
-{{site.data.alerts.callout_info}}
-The following statements are run by the `root` user that is a member of the `admin` role and has `ALL` privileges.
-{{site.data.alerts.end}}
-
-### Change a user's password
-
-~~~ sql
-root@:26257/defaultdb> ALTER USER carl WITH PASSWORD 'An0ther$tr0nGpassW0rD' VALID UNTIL '2021-10-10';
-~~~
-
-### Prevent a user from using password authentication
-
-The following statement prevents the user from using password authentication and mandates certificate-based [client authentication](authentication.html#client-authentication):
-
-{% include copy-clipboard.html %}
-~~~ sql
-root@:26257/defaultdb> ALTER USER carl WITH PASSWORD NULL;
-~~~
-
-### Allow a user to create other users and manage authentication methods for the new users
-
-The following example allows the user to [create other users](create-user.html) and [manage authentication methods](authentication.html#client-authentication) for them:
-
-~~~ sql
-root@:26257/defaultdb> ALTER USER carl WITH CREATEROLE CREATELOGIN;
-~~~
-
-### Allow a user to create and rename databases
-
-The following example allows the user to [create](create-database.html) or [rename](rename-database.html) databases:
-
-~~~ sql
-root@:26257/defaultdb> ALTER USER carl WITH CREATEDB;
-~~~
-
-### Allow a user to pause, resume, and cancel non-admin jobs
-
-The following example allows the user to [pause](pause-job.html), [resume](resume-job.html), and [cancel](cancel-job.html) jobs:
-
-~~~ sql
-root@:26257/defaultdb> ALTER USER carl WITH CONTROLJOB;
-~~~
-
-### Allow a user to see and cancel non-admin queries and sessions
-
-The following example allows the user to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) for other non-admin roles:
-
-~~~ sql
-root@:26257/defaultdb> ALTER USER carl WITH CANCELQUERY VIEWACTIVITY;
-~~~
-
-### Allow a user to control changefeeds
-
-The following example allows the user to run [`CREATE CHANGEFEED`](create-changefeed.html):
-
-~~~ sql
-root@:26257/defaultdb> ALTER USER carl WITH CONTROLCHANGEFEED;
-~~~
-
-### Allow a user to modify cluster settings
-
-The following example allows the user to modify [cluster settings](cluster-settings.html):
-
-~~~ sql
-root@:26257/defaultdb> ALTER USER carl WITH MODIFYCLUSTERSETTING;
-~~~
-
-## See also
-
-- [`DROP USER`](drop-user.html)
-- [`SHOW USERS`](show-users.html)
-- [`GRANT <privileges>`](grant.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [Create Security Certificates](cockroach-cert.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/alter-view.md b/src/current/v20.2/alter-view.md
deleted file mode 100644
index 85da573d97b..00000000000
--- a/src/current/v20.2/alter-view.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: ALTER VIEW
-summary: The ALTER VIEW statement applies a schema change to a view.
-toc: true
----
-
-The `ALTER VIEW` [statement](sql-statements.html) applies a schema change to a [view](views.html).
-
-{{site.data.alerts.callout_info}}
-`ALTER VIEW ... RENAME TO` can be used to move a view from one database to another, but it cannot be used to move a view from one schema to another. To change a views's schema, use [`SET SCHEMA`](set-schema.html).
-
-Note that, in a future release, `ALTER VIEW ... RENAME TO` will be limited to changing the name of a view, and will not have to the ability to change a view's database.
-{{site.data.alerts.end}}
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the view and the `CREATE` privilege on the parent database.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/alter_view.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`MATERIALIZED` | <span class="version-tag">New in v20.2:</span> Rename a [materialized view](views.html#materialized-views).
-`IF EXISTS` | Rename the view only if a view of `view_name` exists; if one does not exist, do not return an error.
-`view_name` | The name of the view to rename. To find view names, use:<br><br>`SELECT * FROM information_schema.tables WHERE table_type = 'VIEW';`
-`name` | The new [`name`](sql-grammar.html#name) for the view, which must be unique to its database and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
-
-
-## Limitations
-
-CockroachDB does not currently support:
-
-- Changing the [`SELECT`](select-clause.html) statement executed by a view. Instead, you must drop the existing view and create a new view.
-- Renaming a view that other views depend on. This feature may be added in the future (see [tracking issue](https://github.com/cockroachdb/cockroach/issues/10083)).
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.tables WHERE table_type = 'VIEW';
-~~~
-
-~~~
-+---------------+-------------------+--------------------+------------+---------+
-| TABLE_CATALOG |   TABLE_SCHEMA    |     TABLE_NAME     | TABLE_TYPE | VERSION |
-+---------------+-------------------+--------------------+------------+---------+
-| def           | bank              | user_accounts      | VIEW       |       2 |
-| def           | bank              | user_emails        | VIEW       |       1 |
-+---------------+-------------------+--------------------+------------+---------+
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER VIEW bank.user_emails RENAME TO bank.user_email_addresses;
-~~~
-
-{% include copy-clipboard.html %}
-~~~
-> RENAME VIEW
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.tables WHERE table_type = 'VIEW';
-~~~
-
-~~~
-+---------------+-------------------+----------------------+------------+---------+
-| TABLE_CATALOG |   TABLE_SCHEMA    |      TABLE_NAME      | TABLE_TYPE | VERSION |
-+---------------+-------------------+----------------------+------------+---------+
-| def           | bank              | user_accounts        | VIEW       |       2 |
-| def           | bank              | user_email_addresses | VIEW       |       3 |
-+---------------+-------------------+----------------------+------------+---------+
-(2 rows)
-~~~
-
-## See also
-
-- [Views](views.html)
-- [`CREATE VIEW`](create-view.html)
-- [`SHOW CREATE`](show-create.html)
-- [`DROP VIEW`](drop-view.html)
-- [`SET SCHEMA`](set-schema.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/architecture/distribution-layer.md b/src/current/v20.2/architecture/distribution-layer.md
deleted file mode 100644
index 4443bd4ad87..00000000000
--- a/src/current/v20.2/architecture/distribution-layer.md
+++ /dev/null
@@ -1,241 +0,0 @@
----
-title: Distribution Layer
-summary: The distribution layer of CockroachDB's architecture provides a unified view of your cluster's data.
-toc: true
----
-
-The distribution layer of CockroachDB's architecture provides a unified view of your cluster's data.
-
-{{site.data.alerts.callout_info}}
-If you haven't already, we recommend reading the [Architecture Overview](overview.html).
-{{site.data.alerts.end}}
-
-## Overview
-
-To make all data in your cluster accessible from any node, CockroachDB stores data in a monolithic sorted map of key-value pairs. This key-space describes all of the data in your cluster, as well as its location, and is divided into what we call "ranges", contiguous chunks of the key-space, so that every key can always be found in a single range.
-
-CockroachDB implements a sorted map to enable:
-
-  - **Simple lookups**: Because we identify which nodes are responsible for certain portions of the data, queries are able to quickly locate where to find the data they want.
-  - **Efficient scans**: By defining the order of data, it's easy to find data within a particular range during a scan.
-
-### Monolithic sorted map structure
-
-The monolithic sorted map is comprised of two fundamental elements:
-
-- System data, which include **meta ranges** that describe the locations of data in your cluster (among many other cluster-wide and local data elements)
-- User data, which store your cluster's **table data**
-
-#### Meta ranges
-
-The locations of all ranges in your cluster are stored in a two-level index at the beginning of your key-space, known as meta ranges, where the first level (`meta1`) addresses the second, and the second (`meta2`) addresses data in the cluster.
-
-This two-level index plus user data can be visualized as a tree, with the root at `meta1`, the second level at `meta2`, and the leaves of the tree made up of the ranges that hold user data.
-
-![range-lookup.png](../../images/{{page.version.version}}/range-lookup.png "Meta ranges plus user data tree diagram")
-
-Importantly, every node has information on where to locate the `meta1` range (known as its range descriptor, detailed below), and the range is never split.
-
-This meta range structure lets us address up to 4EiB of user data by default: we can address 2^(18 + 18) = 2^36 ranges; each range addresses 2^26 B, and altogether we address 2^(36+26) B = 2^62 B = 4EiB. However, with larger range sizes, it's possible to expand this capacity even further.
-
-Meta ranges are treated mostly like normal ranges and are accessed and replicated just like other elements of your cluster's KV data.
-
-Each node caches values of the `meta2` range it has accessed before, which optimizes access of that data in the future. Whenever a node discovers that its `meta2` cache is invalid for a specific key, the cache is updated by performing a regular read on the `meta2` range.
-
-#### Table data
-
-After the node's meta ranges is the KV data your cluster stores.
-
-Each table and its secondary indexes initially map to a single range, where each key-value pair in the range represents a single row in the table (also called the primary index because the table is sorted by the primary key) or a single row in a secondary index. As soon as a range reaches 512 MiB in size, it splits into two ranges. This process continues as a table and its indexes continue growing. Once a table is split across multiple ranges, it's likely that the table and secondary indexes will be stored in separate ranges. However, a range can still contain data for both the table and a secondary index. 
-
-The default 512 MiB range size represents a sweet spot for us between a size that's small enough to move quickly between nodes, but large enough to store a meaningfully contiguous set of data whose keys are more likely to be accessed together. These ranges are then shuffled around your cluster to ensure survivability.
-
-These table ranges are replicated (in the aptly named replication layer), and have the addresses of each replica stored in the `meta2` range.
-
-### Using the monolithic sorted map
-
-As described in the [meta ranges section](#meta-ranges), the locations of all the ranges in a cluster are stored in a two-level index:
-
-- The first level (`meta1`) addresses the second level.
-- The second level (`meta2`) addresses user data.
-
-This can also be visualized as a tree, with the root at `meta1`, the second level at `meta2`, and the leaves of the tree made up of the ranges that hold user data.
-
-When a node receives a request, it looks up the location of the range(s) that include the keys in the request in a bottom-up fashion, starting with the leaves of this tree. This process works as follows:
-
-1. For each key, the node looks up the location of the range containing the specified key in the second level of range metadata (`meta2`). That information is cached for performance; if the range's location is found in the cache, it is returned immediately.
-
-2. If the range's location is not found in the cache, the node looks up the location of the range where the actual value of `meta2` resides. This information is also cached; if the location of the `meta2` range is found in the cache, the node sends an RPC to the `meta2` range to get the location of the keys the request wants to operate on, and returns that information.
-
-3. Finally, if the location of the `meta2` range is not found in the cache, the node looks up the location of the range where the actual value of the first level of range metadata (`meta1`) resides. This lookup always succeeds because the location of `meta1` is distributed among all the nodes in the cluster using a gossip protocol. The node then uses the information from `meta1` to look up the location of `meta2`, and from `meta2` it looks up the locations of the ranges that include the keys in the request.
-
-Note that the process described above is recursive; every time a lookup is performed, it either (1) gets a location from the cache, or (2) performs another lookup on the value in the next level "up" in the tree. Because the range metadata is cached, a lookup can usually be performed without having to send an RPC to another node.
-
-Now that the node has the location of the range where the key from the request resides, it sends the KV operations from the request along to the range (using the [`DistSender`](#distsender) machinery) in a [`BatchRequest`](#batchrequest).
-
-### Interactions with other layers
-
-In relationship to other layers in CockroachDB, the distribution layer:
-
-- Receives requests from the transaction layer on the same node.
-- Identifies which nodes should receive the request, and then sends the request to the proper node's replication layer.
-
-## Technical details and components
-
-### gRPC
-
-gRPC is the software nodes use to communicate with one another. Because the distribution layer is the first layer to communicate with other nodes, CockroachDB implements gRPC here.
-
-gRPC requires inputs and outputs to be formatted as protocol buffers (protobufs). To leverage gRPC, CockroachDB implements a protocol-buffer-based API defined in `api.proto`.
-
-For more information about gRPC, see the [official gRPC documentation](http://www.grpc.io/docs/guides/).
-
-### BatchRequest
-
-All KV operation requests are bundled into a [protobuf](https://en.wikipedia.org/wiki/Protocol_Buffers), known as a `BatchRequest`. The destination of this batch is identified in the `BatchRequest` header, as well as a pointer to the request's transaction record. (On the other side, when a node is replying to a `BatchRequest`, it uses a protobuf––`BatchResponse`.)
-
-This `BatchRequest` is also what's used to send requests between nodes using gRPC, which accepts and sends protocol buffers.
-
-### DistSender
-
-The gateway/coordinating node's `DistSender` receives `BatchRequest`s from its own `TxnCoordSender`. `DistSender` is then responsible for breaking up `BatchRequests` and routing a new set of `BatchRequests` to the nodes it identifies contain the data using the system [meta ranges](#meta-ranges). For a description of the process by which this lookup from a key to the node holding the key's range is performed, see [Using the monolithic sorted map](#using-the-monolithic-sorted-map).
-
-It sends the `BatchRequest`s to the replicas of a range, ordered in expectation of request latency. The leaseholder is tried first, if the request needs it. Requests received by a non-leaseholder may fail with an error pointing at the replica's last known leaseholder. These requests are retried transparently with the updated lease by the gateway node and never reach the client.
-
-As nodes begin replying to these commands, `DistSender` also aggregates the results in preparation for returning them to the client.
-
-### Meta range KV structure
-
-Like all other data in your cluster, meta ranges are structured as KV pairs. Both meta ranges have a similar structure:
-
-~~~
-metaX/successorKey -> [list of nodes containing data]
-~~~
-
-Element | Description
---------|------------------------
-`metaX` | The level of meta range. Here we use a simplified `meta1` or `meta2`, but these are actually represented in `cockroach` as `\x02` and `\x03` respectively.
-`successorKey` | The first key *greater* than the key you're scanning for. This makes CockroachDB's scans efficient; it simply scans the keys until it finds a value greater than the key it's looking for, and that is where it finds the relevant data.<br/><br/>The `successorKey` for the end of a keyspace is identified as `maxKey`.
-
-Here's an example:
-
-~~~
-meta2/M -> node1:26257, node2:26257, node3:26257
-~~~
-
-In this case, the replica on `node1` is the leaseholder, and nodes 2 and 3 also contain replicas.
-
-#### Example
-
-Let's imagine we have an alphabetically sorted column, which we use for lookups. Here are what the meta ranges would approximately look like:
-
-1. `meta1` contains the address for the nodes containing the `meta2` replicas.
-
-    ~~~
-    # Points to meta2 range for keys [A-M)
-    meta1/M -> node1:26257, node2:26257, node3:26257
-
-    # Points to meta2 range for keys [M-Z]
-    meta1/maxKey -> node4:26257, node5:26257, node6:26257
-    ~~~
-
-2. `meta2` contains addresses for the nodes containing the replicas of each range in the cluster:
-
-    ~~~
-    # Contains [A-G)
-    meta2/G -> node1:26257, node2:26257, node3:26257
-
-    # Contains [G-M)
-    meta2/M -> node1:26257, node2:26257, node3:26257
-
-    #Contains [M-Z)
-    meta2/Z -> node4:26257, node5:26257, node6:26257
-
-    #Contains [Z-maxKey)
-    meta2/maxKey->  node4:26257, node5:26257, node6:26257
-    ~~~
-
-### Table data KV structure
-
-Key-value data, which represents the data in your tables using the following structure:
-
-~~~
-/<table Id>/<index id>/<indexed column values> -> <non-indexed/STORING column values>
-~~~
-
-The table itself is stored with an `index_id` of 1 for its `PRIMARY KEY` columns, with the rest of the columns in the table considered as stored/covered columns.
-
-### Range descriptors
-
-Each range in CockroachDB contains metadata, known as a range descriptor. A range descriptor is comprised of the following:
-
-- A sequential RangeID
-- The keyspace (i.e., the set of keys) the range contains; for example, the first and last `<indexed column values>` in the table data KV structure above. This determines the `meta2` range's keys.
-- The addresses of nodes containing replicas of the range. This determines the `meta2` range's key's values.
-
-Because range descriptors comprise the key-value data of the `meta2` range, each node's `meta2` cache also stores range descriptors.
-
-Range descriptors are updated whenever there are:
-
-- Membership changes to a range's Raft group (discussed in more detail in the [Replication Layer](replication-layer.html#membership-changes-rebalance-repair))
-- Range splits
-- Range merges
-
-All of these updates to the range descriptor occur locally on the range, and then propagate to the `meta2` range.
-
-### Range splits
-
-By default, CockroachDB attempts to keep ranges/replicas at 512 MiB. Once a range reaches that limit we split it into two smaller ranges (composed of contiguous key spaces).
-
-During this range split, the node creates a new Raft group containing all of the same members as the range that was split. The fact that there are now two ranges also means that there is a transaction that updates `meta2` with the new keyspace boundaries, as well as the addresses of the nodes using the range descriptor.
-
-### Range merges
-
-By default, CockroachDB automatically merges small ranges of data together to form fewer, larger ranges (up to the default range size). This can improve both query latency and cluster survivability.
-
-#### How range merges work
-
-As [described above](#overview), CockroachDB splits your cluster's data into many ranges. For example, your cluster might have a range for customers whose IDs are between `[1000, 2000)`. If that range grows beyond the default range size, the range is [split into two smaller ranges](#range-splits).
-
-However, as you delete data from your cluster, a range might contain far less data than the default range size. Over the lifetime of a cluster, this could lead to a number of small ranges.
-
-To reduce the number of small ranges, your cluster can have any range below a certain size threshold try to merge with its "right-hand neighbor", i.e., the range that starts where the current range ends. Using our example above, this range's right-hand neighbor might be the range for customers whose IDs are between `[2000, 3000)`.
-
-If the combined size of the small range and its neighbor is less than the maximum range size, the ranges merge into a single range. In our example, this will create a new range of keys `[1000, 3000)`.
-
-{{site.data.alerts.callout_info}}
-When ranges merge, the left-hand-side (LHS) range consumes the right-hand-side (RHS) range.
-{{site.data.alerts.end}}
-
-#### Why range merges improve performance
-
-##### Query latency
-
-Queries in CockroachDB must contact a replica of each range involved in the query. This creates the following issues for clusters with many small ranges:
-
-- Queries incur a fixed overhead in terms of processing time for each range they must coordinate with.
-- Having many small ranges can increase the number of machines your query must coordinate with. This exposes your query to a greater likelihood of running into issues like network latency or overloaded nodes.
-
-By merging small ranges, CockroachDB can greatly reduce the number of ranges involved in queries, thus reducing query latency.
-
-##### Survivability
-
-CockroachDB automatically rebalances the distribution of ranges in your cluster whenever nodes come online or go offline.
-
-During rebalancing, it's better to replicate a few larger ranges across nodes than many smaller ranges. Replicating larger ranges requires less coordination and often completes more quickly.
-
-By merging smaller ranges together, your cluster needs to rebalance fewer total ranges. This ultimately improves your cluster's performance, especially in the face of availability events like node outages.
-
-## Technical interactions with other layers
-
-### Distribution and transaction layer
-
-The Distribution layer's `DistSender` receives `BatchRequests` from its own node's `TxnCoordSender`, housed in the Transaction layer.
-
-### Distribution and replication layer
-
-The Distribution layer routes `BatchRequests` to nodes containing ranges of data, which is ultimately routed to the Raft group leader or leaseholder, which are handled in the replication layer.
-
-## What's next?
-
-Learn how CockroachDB copies data and ensures consistency in the [replication layer](replication-layer.html).
diff --git a/src/current/v20.2/architecture/life-of-a-distributed-transaction.md b/src/current/v20.2/architecture/life-of-a-distributed-transaction.md
deleted file mode 100644
index 35299d55227..00000000000
--- a/src/current/v20.2/architecture/life-of-a-distributed-transaction.md
+++ /dev/null
@@ -1,187 +0,0 @@
----
-title: Life of a Distributed Transaction
-summary: Learn how a query moves through the layers of CockroachDB's architecture.
-toc: true
----
-
-Because CockroachDB is a distributed transactional database, the path queries take is dramatically different from many other database architectures. To help familiarize you with CockroachDB's internals, this guide covers what that path actually is.
-
-If you've already read the [CockroachDB architecture documentation](overview.html), this guide serves as another way to conceptualize how the database works. This time, instead of focusing on the layers of CockroachDB's architecture, we're going to focus on the linear path that a query takes through the system (and then back out again).
-
-To get the most out of this guide, we recommend beginning with the architecture documentation's [overview](overview.html) and progressing through all of the following sections. This guide provides brief descriptions of each component's function and links  to other documentation where appropriate, but assumes the reader has a basic understanding of the architecture in the first place.
-
-## Overview
-
-This guide is organized by the physical actors in the system, and then broken down into the components of each actor in the sequence in which they're involved.
-
-Here's a brief overview of the physical actors, in the sequence with which they're involved in executing a query:
-
-1. [**SQL Client**](#sql-client-postgres-wire-protocol) sends a query to your cluster.
-1. [**Load Balancing**](#load-balancing-routing) routes the request to CockroachDB nodes in your cluster, which will act as a gateway.
-1. [**Gateway**](#gateway) is a CockroachDB node that processes the SQL request and responds to the client.
-1. [**Leaseholder**](#leaseholder-node) is a CockroachDB node responsible for serving reads and coordinating writes of a specific range of keys in your query.
-1. [**Raft leader**](#raft-leader) is a CockroachDB node responsible for maintaining consensus among your CockroachDB replicas.
-
-Once the transaction completes, queries traverse these actors in approximately reverse order. We say "approximately" because there might be many leaseholders and Raft leaders involved in a single query, and there is little-to-no interaction with the load balancer during the response.
-
-## SQL Client/Postgres Wire Protocol
-
-To begin, a SQL client (e.g., an app) performs some kind of business logic against your CockroachDB cluster, such as inserting a new customer record.
-
-This request is sent over a connection to your CockroachDB cluster that's established using a PostgreSQL driver.
-
-## Load Balancing & Routing
-
-Modern architectures require distributing your cluster across machines to improve throughput, latency, and uptime. This means queries are routed through load balancers, which choose the best CockroachDB node to connect to. Because all CockroachDB nodes have perfectly symmetrical access to data, this means your load balancer can connect your client to any node in the cluster and access any data while still guaranteeing strong consistency.
-
-Your architecture might also have additional layers of routing to enforce regulatory compliance, such as ensuring GDPR compliance.
-
-Once your router and load balancer determine the best node to connect to, your client's connection is established to the gateway node.
-
-## Gateway
-
-The gateway node handles the connection with the client, both receiving and responding to the request.
-
-### SQL parsing & planning
-
-The gateway node first [parses](sql-layer.html#sql-parser-planner-executor) the client's SQL statement to ensure it's valid according to the CockroachDB dialect of SQL, and uses that information to [generate a logical SQL plan](sql-layer.html#logical-planning).
-
-Given that CockroachDB is a distributed database, though, it's also important to take a cluster's topology into account, so the logical plan is then converted into a physical plan&mdash;this means sometimes pushing operations onto the physical machines that contain the data.
-
-### SQL executor
-
-While CockroachDB presents a SQL interface to clients, the actual database is built on top of a key-value store. To mediate this, the physical plan generated at the end of SQL parsing is passed to the SQL executor, which executes the plan by performing key-value operations through the `TxnCoordSender`. For example, the SQL executor converts `INSERT `statements into `Put()` operations.
-
-### TxnCoordSender
-
-The `TxnCoordSender` provides an API to perform key-value operations on your database.
-
-On its back end, the `TxnCoordSender` performs a large amount of the accounting and tracking for a transaction, including:
-
-- Accounts for all keys involved in a transaction. This is used, among other ways, to manage the transaction's state.
-- Packages all key-value operations into a `BatchRequest`, which are forwarded on to the node's `DistSender`.
-
-### DistSender
-
-The gateway node's `DistSender` receives `BatchRequests` from the `TxnCoordSender`. It dismantles the initial `BatchRequest` by taking each operation and finding which physical machine should receive the request for the range&mdash;known as the range's leaseholder. The address of the range's current leaseholder is readily available in both local caches, as well as in the [cluster's `meta` ranges](distribution-layer.html#meta-range-kv-structure).
-
-These dismantled `BatchRequests` are reassembled into new `BatchRequests` containing the address of the range's leaseholder.
-
-All write operations also propagate the leaseholder's address back to the `TxnCoordSender`, so it can track and clean up write operations as necessary.
-
-The `DistSender` sends out the first `BatchRequest` for each range in parallel. As soon as it receives a provisional acknowledgment from the leaseholder node’s evaluator (details below), it sends out the next `BatchRequest` for that range.
-
-The `DistSender` then waits to receive acknowledgments for all of its write operations, as well as values for all of its read operations. However, this wait isn't necessarily blocking, and the `DistSender` may still perform operations with ongoing transactions.
-
-## Leaseholder node
-
-The gateway node's `DistSender` tries to send its `BatchRequests` to the replica identified as the range's [leaseholder](replication-layer.html#leases), which is a single replica that serves all reads for a range, as well as coordinates all writes. Leaseholders play a crucial role in CockroachDB's architecture, so it's a good topic to make sure you're familiar with.
-
-### Request response
-
-Because the leaseholder replica can shift between nodes, all nodes must be able to return a request for any key, returning a response indicating one of these scenarios:
-
-##### No Longer Leaseholder
-
-If a node is no longer the leaseholder, but still contains a replica of the range, it denies the request but includes the last known address for the leaseholder of that range.
-
-Upon receipt of this response, the `DistSender` will update the header of the `BatchRequest` with the new address, and then resend the `BatchRequest` to the newly identified leaseholder.
-
-##### No Longer Has/Never Had Range
-
-If a node doesn't have a replica for the requested range, it denies the request without providing any further information.
-
-In this case, the `DistSender` must look up the current leaseholder using the [cluster's `meta` ranges](distribution-layer.html#meta-range-kv-structure).
-
-##### Success
-
-Once the node that contains the leaseholder of the range receives the `BatchRequest`, it begins processing it, and progresses onto checking the timestamp cache.
-
-### Timestamp cache
-
-The timestamp cache tracks the highest timestamp (i.e., most recent) for any read operation that a given range has served.
-
-Each write operation in a `BatchRequest` checks its own timestamp versus the timestamp cache to ensure that the write operation has a higher timestamp; this guarantees that history is never rewritten and you can trust that reads always served the most recent data. It's one of the crucial mechanisms CockroachDB uses to ensure serializability. If a write operation fails this check, it must be restarted at a timestamp higher than the timestamp cache's value.
-
-### Latch manager
-
-Operations in the `BatchRequest` are serialized through the leaseholder's latch manager.
-
-This works by giving each write operation a latch on a row. Any reads or writes that come in after the latch has been granted on the row must wait for the write to complete, at which point the latch is released and the subsequent operations can continue.
-
-### Batch Evaluation
-
-The batch evaluator ensures that write operations are valid. Our architecture makes this fairly trivial. First, the evaluator can simply check the leaseholder's data to ensure the write is valid; because it has coordinated all writes to the range, it must have the most up-to-date versions of the range's data. Secondly, because of the latch manager, each write operation is guaranteed to uncontested access to the range (i.e., there is no contention with other write operations).
-
-If the write operation is valid according to the evaluator, the leaseholder sends a provisional acknowledgment to the gateway node's `DistSender`; this lets the `DistSender` begin to send its subsequent `BatchRequests` for this range.
-
-Importantly, this feature is entirely built for transactional optimization (known as [transaction pipelining](transaction-layer.html#transaction-pipelining)). There are no issues if an operation passes the evaluator but doesn't end up committing.
-
-### Reads from the storage layer
-
-All operations (including writes) begin by reading from the local instance of the [storage engine](storage-layer.html) to check for write intents for the operation's key. We talk much more about [write intents in the transaction layer of the CockroachDB architecture](transaction-layer.html#write-intents), which is worth reading, but a simplified explanation is that these are provisional, uncommitted writes that express that some other concurrent transaction plans to write a value to the key.
-
-What we detail below is a simplified version of the CockroachDB transaction model. For more detail, check out [the transaction architecture documentation](transaction-layer.html).
-
-#### Resolving Write Intents
-
-If an operation encounters a write intent for a key, it attempts to "resolve" the write intent by checking the state of the write intent's transaction. If the write intent's transaction record is...
-
-- `COMMITTED`, this operation converts the write intent to a regular key-value pair, and then proceeds as if it had read that value instead of a write intent.
-- `ABORTED`, this operation discards the write intent and reads the next-most-recent value from the storage engine.
-- `PENDING`, the new transaction attempts to "push" the write intent's transaction by moving that transaction's timestamp forward (i.e.,  ahead of this transaction's timestamp); however, this only succeeds if the write intent's transaction has become inactive.
-  	- If the push succeeds, the operation continues.
-  	- If this push fails (which is the majority of the time), this transaction goes into the [`TxnWaitQueue`](transaction-layer.html#txnwaitqueue) on this node. The incoming transaction can only continue once the blocking transaction completes (i.e., commits or aborts).
-- `MISSING`, the resolver consults the write intent's timestamp.
-	- If it was created within the transaction liveness threshold, it treats the transaction record as exhibiting the `PENDING` behavior, with the addition of tracking the push in the range's timestamp cache, which will inform the transaction that its timestamp was pushed once the transaction record gets created.
-	- If the write intent is older than the transaction liveness threshold, the resolution exhibits the `ABORTED` behavior.
-
-    Note that transaction records might be missing because we've avoided writing the record until the transaction commits. For more information, see [Transaction Layer: Transaction records](transaction-layer.html#transaction-records).
-
-Check out our architecture documentation for more information about [CockroachDB's transactional model](transaction-layer.html).
-
-#### Read Operations
-
-If the read doesn't encounter a write intent and the key-value operation is meant to serve a read, it can simply use the value it read from the leaseholder's instance of the storage engine. This works because the leaseholder had to be part of the Raft consensus group for any writes to complete, meaning it must have the most up-to-date version of the range's data.
-
-The leaseholder aggregates all read responses into a `BatchResponse` that will get returned to the gateway node's `DistSender`.
-
-As we mentioned before, each read operation also updates the timestamp cache.
-
-### Write Operations
-
-After guaranteeing that there are no existing write intents for the keys, `BatchRequest`'s key-value operations are converted to [Raft operations](replication-layer.html#raft) and have their values converted into write intents.
-
-The leaseholder then proposes these Raft operations to the Raft group leader. The leaseholder and the Raft leader are almost always the same node, but there are situations where the roles might drift to different nodes. However, when the two roles are not collocated on the same physical machine, CockroachDB will attempt to relocate them on the same node at the next opportunity.
-
-## Raft Leader
-
-CockroachDB leverages Raft as its consensus protocol. If you aren't familiar with it, we recommend checking out the details about [how CockroachDB leverages Raft](replication-layer.html#raft), as well as [learning more about how the protocol works at large](http://thesecretlivesofdata.com/raft/).
-
-In terms of executing transactions, the Raft leader receives proposed Raft commands from the leaseholder. Each Raft command is a write that is used to represent an atomic state change of the underlying key-value pairs stored in the storage engine.
-
-### Consensus
-
-For each command the Raft leader receives, it proposes a vote to the other members of the Raft group.
-
-Once the command achieves consensus (i.e., a majority of nodes including itself acknowledge the Raft command), it is committed to the Raft leader’s Raft log and written to the storage engine. At the same time, the Raft leader also sends a command to all other nodes to include the command in their Raft logs.
-
-Once the leader commits the Raft log entry, it’s considered committed. At this point the value is considered written, and if another operation comes in and performs a read from the storage engine for this key, they’ll encounter this value.
-
-Note that this write operation creates a write intent; these writes will not be fully committed until the gateway node sets the transaction record's status to `COMMITTED`.
-
-## On the way back up
-
-Now that we have followed an operation all the way down from the SQL client to the storage engine, we can pretty quickly cover what happens on the way back up (i.e., when generating a response to the client).
-
-1. Once the leaseholder applies a write to its Raft log,
- it sends an commit acknowledgment to the gateway node's `DistSender`, which was waiting for this signal (having already received the provisional acknowledgment from the leaseholder's evaluator).
-1. The gateway node's `DistSender` aggregates commit acknowledgments from all of the write operations in the `BatchRequest`, as well as any values from read operations that should be returned to the client.
-1. Once all operations have successfully completed (i.e., reads have returned values and write intents have been committed), the `DistSender` tries to record the transaction's success in the transaction record (which provides a durable mechanism of tracking the transaction's state), which can cause a few situations to arise:
-    - It checks the timestamp cache of the range where the first write occurred to see if its timestamp got pushed forward. If it did, the transaction performs a [read refresh](transaction-layer.html#read-refreshing) to see if any values it needed have been changed. If the read refresh is successful, the transaction can commit at the pushed timestamp. If the read refresh fails, the transaction must be restarted.
-	- If the transaction is in an `ABORTED` state, the `DistSender` sends a response indicating as much, which ends up back at the SQL interface.
-
-	Upon passing these checks the transaction record is either written for the first time with the `COMMITTED` state, or if it was in a `PENDING` state, it is moved to `COMMITTED`. Only at this point is the transaction considered committed.
-1. The `DistSender` propagates any values that should be returned to the client (e.g., reads or the number of affected rows) to the `TxnCoordSender`, which in turn responds to the SQL interface with the value.
-  The `TxnCoordSender` also begins asynchronous intent cleanup by sending a request to the `DistSender` to convert all write intents it created for the transaction to fully committed values. However, this process is largely an optimization; if any operation encounters a write intent, it checks the write intent's transaction record. If the transaction record is `COMMITTED`, the operation can perform the same cleanup and convert the write intent to a fully committed value.
-1. The SQL interface then responds to the client, and is now prepared to continue accepting new connections.
diff --git a/src/current/v20.2/architecture/overview.md b/src/current/v20.2/architecture/overview.md
deleted file mode 100644
index a1f2faae8ca..00000000000
--- a/src/current/v20.2/architecture/overview.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: Architecture Overview
-summary: Learn about the inner-workings of the CockroachDB architecture.
-toc: true
-key: cockroachdb-architecture.html
----
-
-CockroachDB was designed to create the source-available database we would want to use: one that is both scalable and consistent. Developers often have questions about how we've achieved this, and this guide sets out to detail the inner workings of the `cockroach` process as a means of explanation.
-
-However, you definitely do not need to understand the underlying architecture to use CockroachDB. These pages give serious users and database enthusiasts a high-level framework to explain what's happening under the hood.
-
-## Using this guide
-
-This guide is broken out into pages detailing each layer of CockroachDB. We recommended reading through the layers sequentially, starting with this overview and then proceeding to the [SQL layer](sql-layer.html).
-
-If you're looking for a high-level understanding of CockroachDB, you can read the **Overview** section of each layer. For more technical detail—for example, if you're interested in [contributing to the project](https://cockroachlabs.atlassian.net/wiki/x/QQFdB)—you should read the **Components** sections as well.
-
-{{site.data.alerts.callout_info}}
-This guide details how CockroachDB is built, but does not explain how to build an application using CockroachDB. For more information about how to develop applications that use CockroachDB, check out our [Developer Guide](../developer-guide-overview.html).
-{{site.data.alerts.end}}
-
-## Goals of CockroachDB
-
-CockroachDB was designed to meet the following goals:
-
-- Make life easier for humans. This means being low-touch and highly automated for [operators](../recommended-production-settings.html) and simple to reason about for [developers](../developer-guide-overview.html).
-- Offer industry-leading consistency, even on massively scaled deployments. This means enabling distributed transactions, as well as removing the pain of eventual consistency issues and stale reads.
-- Create an always-on database that accepts reads and writes on all nodes without generating conflicts.
-- Allow flexible deployment in any environment, without tying you to any platform or vendor.
-- Support familiar tools for working with relational data (i.e., SQL).
-
-With the confluence of these features, we hope that CockroachDB helps you build global, scalable, resilient deployments and applications.
-
-## Glossary
-
-### Terms
-
-It's helpful to understand a few terms before reading our architecture documentation.
-
-{% include {{ page.version.version }}/misc/basic-terms.md %}
-
-### Concepts
-
-CockroachDB relies heavily on the following concepts. Being familiar with them will help you understand what our architecture achieves.
-
-Term | Definition
------|-----------
-**Consistency** | CockroachDB uses "consistency" in both the sense of [ACID semantics](https://en.wikipedia.org/wiki/Consistency_(database_systems)) and the [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem), albeit less formally than either definition. What we try to express with this term is that your data should be anomaly-free.
-**Isolation** | CockroachDB provides the [`SERIALIZABLE`](https://en.wikipedia.org/wiki/Serializability) isolation level, which provides the highest level of data consistency and protects against concurrency-based attacks and bugs.
-**Consensus** | <a name="architecture-overview-consensus"></a> When a range receives a write, a quorum of nodes containing replicas of the range acknowledge the write. This means your data is safely stored and a majority of nodes agree on the database's current state, even if some of the nodes are offline.<br/><br/>When a write does not achieve consensus, forward progress halts to maintain consistency within the cluster.
-**Replication** | Replication involves creating and distributing copies of data, as well as ensuring that those copies remain consistent. There are two types of replication: _synchronous_ and _asynchronous_.<br/><br/>Synchronous replication is used by CockroachDB. Synchronous replication requires all writes to propagate to a [quorum](https://en.wikipedia.org/wiki/Quorum_%28distributed_computing%29) of copies of the data before being considered committed. This ensures the consistency of your data.<br/><br/>Asynchronous replication is not used by CockroachDB. It only requires a single node to receive the write to be considered committed; state is then propagated to each copy of the data after the fact. This is more or less equivalent to ["eventual consistency"](https://en.wikipedia.org/wiki/Eventual_consistency), which was popularized by NoSQL databases. This method of replication is likely to cause anomalies and loss of data.
-**Transactions** | A set of operations performed on your database that satisfy the requirements of [ACID semantics](https://en.wikipedia.org/wiki/Database_transaction). This is a crucial component for a consistent system to ensure developers can trust the data in their database. For more information about how transactions work, see the [Transaction Layer](transaction-layer.html) documentation.
-**Multi-Active Availability** | Our consensus-based notion of high availability that lets each node in the cluster handle reads and writes for a subset of the stored data (on a per-range basis). This is in contrast to active-passive replication, in which the active node receives 100% of request traffic, as well as active-active replication, in which all nodes accept requests but typically cannot guarantee that reads are both up-to-date and fast.
-
-## Overview
-
-CockroachDB starts running on machines with two commands:
-
-- [`cockroach start`](../cockroach-start.html) with a `--join` flag for all of the initial nodes in the cluster, so the process knows all of the other machines it can communicate with.
-- [`cockroach init`](../cockroach-init.html) to perform a one-time initialization of the cluster.
-
-Once the CockroachDB cluster is initialized, developers interact with CockroachDB through a [PostgreSQL-compatible](../postgresql-compatibility.html) SQL API. Thanks to the symmetrical behavior of all nodes in a cluster, you can send [SQL requests](sql-layer.html) to any node; this makes CockroachDB easy to integrate with load balancers.
-
-After receiving SQL remote procedure calls (RPCs), nodes convert them into key-value (KV) operations that work with our [distributed, transactional key-value store](transaction-layer.html).
-
-As these RPCs start filling your cluster with data, CockroachDB starts [algorithmically distributing your data among the nodes of the cluster](distribution-layer.html), breaking the data up into 512 MiB chunks that we call ranges. Each range is replicated to at least 3 nodes by default to ensure survivability. This ensures that if any nodes go down, you still have copies of the data which can be used for:
-
-- Continuing to serve reads and writes.
-- Consistently replicating the data to other nodes.
-
-If a node receives a read or write request it cannot directly serve, it finds the node that can handle the request, and communicates with that node. This means you do not need to know where in the cluster a specific portion of your data is stored; CockroachDB tracks it for you, and enables symmetric read/write behavior from each node.
-
-Any changes made to the data in a range rely on a [consensus algorithm](replication-layer.html) to ensure that the majority of the range's replicas agree to commit the change. This is how CockroachDB achieves the industry-leading isolation guarantees that allow it to provide your application with consistent reads and writes, regardless of which node you communicate with.
-
-Ultimately, data is written to and read from disk using an efficient [storage engine](storage-layer.html), which is able to keep track of the data's timestamp. This has the benefit of letting us support the SQL standard [`AS OF SYSTEM TIME`](../as-of-system-time.html) clause, letting you find historical data for a period of time.
-
-While the high-level overview above gives you a notion of what CockroachDB does, looking at how CockroachDB operates at each of these layers will give you much greater understanding of our architecture.
-
-### Layers
-
-At the highest level, CockroachDB converts clients' SQL statements into key-value (KV) data, which is distributed among nodes and written to disk. CockroachDB's architecture is manifested as a number of layers, each of which interacts with the layers directly above and below it as relatively opaque services.
-
-The following pages describe the function each layer performs, while mostly ignoring the details of other layers. This description is true to the experience of the layers themselves, which generally treat the other layers as black-box APIs. There are some interactions that occur between layers that require an understanding of each layer's function to understand the entire process.
-
-Layer | Order | Purpose
-------|------------|--------
-[SQL](sql-layer.html)  | 1  | Translate client SQL queries to KV operations.
-[Transactional](transaction-layer.html)  | 2  | Allow atomic changes to multiple KV entries.
-[Distribution](distribution-layer.html)  | 3  | Present replicated KV ranges as a single entity.
-[Replication](replication-layer.html)  | 4  | Consistently and synchronously replicate KV ranges across many nodes. This layer also enables consistent reads using a consensus algorithm.
-[Storage](storage-layer.html)  | 5  | Read and write KV data on disk.
-
-## What's next?
-
-Start by learning about what CockroachDB does with your SQL statements at the [SQL layer](sql-layer.html).
diff --git a/src/current/v20.2/architecture/reads-and-writes-overview.md b/src/current/v20.2/architecture/reads-and-writes-overview.md
deleted file mode 100644
index da5f959f6e2..00000000000
--- a/src/current/v20.2/architecture/reads-and-writes-overview.md
+++ /dev/null
@@ -1,67 +0,0 @@
----
-title: Reads and Writes in CockroachDB
-summary: Learn how reads and writes are affected by the replicated and distributed nature of data in CockroachDB.
-toc: true
----
-
-This page explains how reads and writes are affected by the replicated and distributed nature of data in CockroachDB. It starts by summarizing some important [CockroachDB architectural concepts](overview.html) and then walks you through a few simple read and write scenarios.
-
-{{site.data.alerts.callout_info}}
-For a more detailed trace of a query through the layers of CockroachDB's architecture, see [Life of a Distributed Transaction](life-of-a-distributed-transaction.html).
-{{site.data.alerts.end}}
-
-## Important concepts
-
-{% include {{ page.version.version }}/misc/basic-terms.md %}
-
-As mentioned above, when a query is executed, the cluster routes the request to the leaseholder for the range containing the relevant data. If the query touches multiple ranges, the request goes to multiple leaseholders. For a read request, only the leaseholder of the relevant range retrieves the data. For a write request, the Raft consensus protocol dictates that a majority of the replicas of the relevant range must agree before the write is committed.
-
-Let's consider how these mechanics play out in some hypothetical queries.
-
-## Read scenario
-
-First, imagine a simple read scenario where:
-
-- There are 3 nodes in the cluster.
-- There are 3 small tables, each fitting in a single range.
-- Ranges are replicated 3 times (the default).
-- A query is executed against node 2 to read from table 3.
-
-<img src="{{ 'images/v20.2/perf_tuning_concepts1.png' | relative_url }}" alt="Perf tuning concepts" style="max-width:100%" />
-
-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:
-
-<img src="{{ 'images/v20.2/perf_tuning_concepts2.png' | relative_url }}" alt="Perf tuning concepts" style="max-width:100%" />
-
-## Write scenario
-
-Now imagine a simple write scenario where a query is executed against node 3 to write to table 1:
-
-<img src="{{ 'images/v20.2/perf_tuning_concepts3.png' | relative_url }}" alt="Perf tuning concepts" style="max-width:100%" />
-
-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:
-
-<img src="{{ 'images/v20.2/perf_tuning_concepts4.png' | relative_url }}" alt="Perf tuning concepts" style="max-width:100%" />
-
-## 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/v20.2/architecture/replication-layer.md b/src/current/v20.2/architecture/replication-layer.md
deleted file mode 100644
index cf45eec0197..00000000000
--- a/src/current/v20.2/architecture/replication-layer.md
+++ /dev/null
@@ -1,171 +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 [lose all of its leases](#how-leases-are-transferred-from-a-dead-node) a few seconds later when the liveness record expires.
-
-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.
-
-#### How leases are transferred from a dead node
-
-When the cluster needs to access a range on a leaseholder node that is dead, that range's lease must be transferred to a healthy node. This process is as follows:
-
-1. The dead node's liveness record, which is stored in a system range, has an expiration time of 9 seconds, and is heartbeated every 4.5 seconds. When the node dies, the amount of time the cluster has to wait for the record to expire varies, but on average is 6.75 seconds.
-1. A healthy node attempts to acquire the lease. This is rejected because lease acquisition can only happen on the Raft leader, which the healthy node is not (yet). Therefore, a Raft election must be held.
-1. The rejected attempt at lease acquisition [unquiesces](../ui-replication-dashboard.html#replica-quiescence) ("wakes up") the range associated with the lease.
-1. What happens next depends on whether the lease is on [table data](#epoch-based-leases-table-data) or [meta ranges or system ranges](#expiration-based-leases-meta-and-system-ranges):
-    - If the lease is on [meta or system ranges](#expiration-based-leases-meta-and-system-ranges), the node that unquiesced the range waits out the Raft election timeout (3 seconds) before kicking off a campaign to try and win Raft leadership so it can become the leaseholder.
-    - If the lease is on [table data](#epoch-based-leases-table-data), the wait described above is skipped and an election is called immediately.
-1. The Raft election is held and a new leader is chosen from among the healthy nodes.
-1. The lease acquisition can now be processed by the newly elected Raft leader.
-
-This process should take no more than 9 seconds for liveness expiration plus the cost of 2 network roundtrips: 1 for Raft leader election, and 1 for lease acquisition. An additional 3 seconds' wait will occur if the lease is on a meta or system range.
-
-Finally, note that the process described above is lazily initiated: it only occurs when a new request comes in for the range associated with the lease.
-
-#### 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](../topology-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 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/v20.2/architecture/sql-layer.md b/src/current/v20.2/architecture/sql-layer.md
deleted file mode 100644
index bb545612477..00000000000
--- a/src/current/v20.2/architecture/sql-layer.md
+++ /dev/null
@@ -1,156 +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 a SQL API to developers and converts high-level [SQL statements](../sql-statements.html) into low-level read and write requests to the underlying key-value store, which are passed to the [transaction Layer](transaction-layer.html).
-
-It consists of the following sublayers:
-
-- [SQL API](#sql-api), which forms the user interface.
-- [Parser](#parsing), which converts SQL text into an abstract syntax tree (AST).
-- [Cost-based optimizer](#logical-planning), which converts the AST into an optimized logical query plan.
-- [Physical planner](#physical-planning), which converts the logical query plan into a physical query plan for execution by one or more nodes in the cluster.
-- [SQL execution engine](#query-execution), which executes the physical plan by making read and write requests to the underlying key-value store.
-
-{{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](../../cockroachcloud/quickstart.html), developers need only a [connection string](../connection-parameters.html) to the cluster, and they can start working with SQL statements.
-
-Because each node in a CockroachDB cluster behaves 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," which processes the request and responds to the client.
-
-Requests to the cluster arrive as SQL statements, but data is ultimately written to and read from the [storage layer](storage-layer.html) as key-value (KV) pairs. To handle this, the SQL layer converts SQL statements into a plan of KV operations, which it then passes along to the [transaction layer](transaction-layer.html).
-
-### Interactions with other layers
-
-In relationship to other layers in CockroachDB, the SQL layer:
-
-- Receives requests from the outside world via its [SQL API](#sql-api).
-- Converts SQL statements into low-level KV operations, which it sends as requests to the [transaction layer](transaction-layer.html).
-
-## Components
-
-### Relational structure
-
-Developers experience data stored in CockroachDB as a relational structure comprised of rows and columns. Sets of rows and columns are further organized into [tables](../show-tables.html). Collections of tables are then organized into [databases](../show-databases.html). A CockroachDB cluster can contain many databases.
-
-CockroachDB provides typical relational features like [constraints](../constraints.html) (e.g., [foreign keys](../foreign-key.html)). These features mean that application developers can 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 most of the ANSI SQL standard to manifest its relational structure. For a complete list of the SQL features CockroachDB supports, see [SQL Feature Support](../sql-feature-support.html).
-
-Importantly, through the SQL API developers have access to ACID-semantic [transactions](../transactions.html) like they would through any SQL database (using [`BEGIN`](../begin-transaction.html), [`COMMIT`](../commit-transaction.html), 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 many PostgreSQL-compatible [drivers and ORMs](../install-client-drivers.html).
-
-### SQL parser, planner, executor
-
-When a node in a CockroachDB cluster receives a SQL request from a client, it [parses the statement](#parsing) and [creates an optimized logical query plan](#logical-planning) that is further translated into a [physical query plan](#physical-planning). Finally, it [executes the physical plan](#query-execution).
-
-#### Parsing
-
-SQL queries are parsed against our `yacc` file (which describes our supported syntax), and the SQL version of each query is converted into an [abstract syntax tree](https://en.wikipedia.org/wiki/Abstract_syntax_tree) (AST).
-
-#### Logical planning
-
-During the *logical planning* phase, the AST is transformed into a query plan in the following steps:
-
-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 operations like:
-    - Checking whether the query is a valid statement in the SQL language.
-    - Resolving names, such as the names of tables or variables to their values.
-    - Eliminating unneeded intermediate computations, e.g., by replacing `0.6 + 0.4` with `1.0`. This is also known as [constant folding](https://en.wikipedia.org/wiki/Constant_folding).
-    - Finalizing which data types to use for intermediate results, e.g., when a query contains one or more [subqueries](../subqueries.html).
-
-2. The logical plan is *simplified* using a series of transformations that are always valid. For example, `a BETWEEN b AND c` may be converted to `a >= b AND a <= c`.
-
-3. The logical plan is *optimized* using a [search algorithm](../cost-based-optimizer.html#how-is-cost-calculated) that evaluates many possible ways to execute a query and selects an execution plan with the least costs.
-
-The result of the final step above is an optimized logical plan. To view the logical plan generated by the [cost-based optimizer](../cost-based-optimizer.html), use the [`EXPLAIN (OPT)`](../explain.html) statement.
-
-#### 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.
-
-More concretely, the physical planning phase transforms the optimized logical plan generated during [logical planning](#logical-planning) into a [directed acyclic graph](https://en.wikipedia.org/wiki/Directed_acyclic_graph) (DAG) of physical *SQL operators*. These operators can be viewed by running the [`EXPLAIN(DISTSQL)`](../explain.html) statement.
-
-Because the [distribution layer](distribution-layer.html) presents the abstraction of a single key space, the SQL layer can perform read and write operations for any range on any node. This allows the SQL operators to behave identically whether planned in gateway or distributed mode.
-
-The decision about whether to distribute a query across multiple nodes is made by a heuristic that estimates the quantity of data that would need to be sent over the network. Queries that only need a small number of rows are executed on the gateway node. Other queries are distributed across multiple nodes.
-
-For example, when a query is distributed, the physical planning phase splits the scan operations from the logical plan into multiple physical _TableReader_ operators, one for each node containing a range read by the scan. The remaining logical operations (which may perform filters, joins, and aggregations) are then scheduled on the same nodes as the TableReaders. This results in computations being performed as close to the physical data as possible.
-
-#### Query execution
-
-Components of the [physical plan](#physical-planning) 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
-
-If [vectorized execution](../vectorized-execution.html) is enabled, the physical plan is sent to nodes to be processed by the vectorized execution engine.
-
-Upon receiving the physical plan, the vectorized engine reads batches of table data [from disk](storage-layer.html) and converts the data from row format to columnar format. These batches of column data are stored in memory so the engine can access them quickly during execution.
-
-The vectorized engine uses specialized, precompiled functions that quickly iterate over the type-specific arrays of column data. The columnar output from the functions is stored in memory as the engine processes each column of data.
-
-After processing all columns of data in the input buffer, the engine converts the columnar output back to row format, and then returns the processed rows to the SQL interface. After a batch of table data has been fully processed, the engine reads the following batch of table data for processing, until the query has been executed.
-
-### Encoding
-
-Though SQL queries are written in parsable strings, lower layers of CockroachDB deal primarily in bytes. This means at the SQL layer, in query execution, CockroachDB must convert row data from their SQL representation as strings into bytes, and convert bytes returned from lower layers into SQL data that can be passed back to the client.
-
-It's also important––for indexed columns––that this byte encoding preserve the same sort order as the data type it represents. This is because of the way CockroachDB ultimately stores data in a sorted key-value map; storing bytes in the same order as the data it represents lets us efficiently scan KV data.
-
-However, for non-indexed columns (e.g., non-`PRIMARY KEY` columns), CockroachDB instead uses an encoding (known as "value encoding") which consumes less space but does not preserve ordering.
-
-You can find more exhaustive detail in the [Encoding Tech Note](https://github.com/cockroachdb/cockroach/blob/master/docs/tech-notes/encoding.md).
-
-### DistSQL
-
-Because CockroachDB is a distributed database, we've developed a Distributed SQL (DistSQL) optimization tool for some queries, which can dramatically speed up queries that involve many ranges. Though DistSQL's architecture is worthy of its own documentation, this cursory explanation can provide some insight into how it works.
-
-In non-distributed queries, the coordinating node receives all of the rows that match its query, and then performs any computations on the entire data set.
-
-However, for DistSQL-compatible queries, each node does computations on the rows it contains, and then sends the results (instead of the entire rows) to the coordinating node. The coordinating node then aggregates the results from each node, and finally returns a single response to the client.
-
-This dramatically reduces the amount of data brought to the coordinating node, and leverages the well-proven concept of parallel computing, ultimately reducing the time it takes for complex queries to complete. In addition, this processes data on the node that already stores it, which lets CockroachDB handle row-sets that are larger than an individual node's storage.
-
-To run SQL statements in a distributed fashion, we introduce a couple of concepts:
-
-- **Logical plan**: Similar to the AST/`planNode` tree described above, it represents the abstract (non-distributed) data flow through computation stages.
-- **Physical plan**: A physical plan is conceptually a mapping of the logical plan nodes to physical machines running `cockroach`. Logical plan nodes are replicated and specialized depending on the cluster topology. Like `planNodes` above, these components of the physical plan are scheduled and run on the cluster.
-
-You can find much greater detail in the [DistSQL RFC](https://github.com/cockroachdb/cockroach/blob/master/docs/RFCS/20160421_distributed_sql.md).
-
-## Schema changes
-
-CockroachDB performs schema changes, such as the [addition of columns](../add-column.html) or [secondary indexes](../create-index.html), using a protocol that allows tables to remain online (i.e., able to serve reads and writes) during the schema change. This protocol allows different nodes in the cluster to asynchronously transition to a new table schema at different times.
-
-The schema change protocol decomposes each schema change into a sequence of incremental changes that will achieve the desired effect.
-
-For example, the addition of a secondary index requires two intermediate schema versions between the start and end versions to ensure that the index is being updated on writes across the entire cluster before it becomes available for reads. To ensure that the database will remain in a consistent state throughout the schema change, we enforce the invariant that there are at most two successive versions of this schema used in the cluster at all times.
-
-This approach is based on the paper [_Online, Asynchronous Schema Change in F1_](https://research.google/pubs/pub41376/).
-
-For more information, including examples and limitations, see [Online Schema Changes](../online-schema-changes.html).
-
-## Technical interactions with other layers
-
-### SQL and transaction layer
-
-KV operations from executed `planNodes` are sent to the transaction layer.
-
-## What's next?
-
-Learn how CockroachDB handles concurrent requests in the [transaction layer](transaction-layer.html).
diff --git a/src/current/v20.2/architecture/storage-layer.md b/src/current/v20.2/architecture/storage-layer.md
deleted file mode 100644
index c6d9802fad3..00000000000
--- a/src/current/v20.2/architecture/storage-layer.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: Storage Layer
-summary: The storage layer of CockroachDB's architecture reads and writes data to disk.
-toc: true
----
-
-The storage layer of CockroachDB's architecture reads and writes data to disk.
-
-{{site.data.alerts.callout_info}}
-If you haven't already, we recommend reading the [Architecture Overview](overview.html).
-{{site.data.alerts.end}}
-
-
-## Overview
-
-Each CockroachDB node contains at least one `store`, specified when the node starts, which is where the `cockroach` process reads and writes its data on disk.
-
-This data is stored as key-value pairs on disk using the storage engine, which is treated primarily as a black-box API.
-
-<span class="version-tag">New in v20.2</span>: By default, [CockroachDB uses the Pebble storage engine](../cockroach-start.html#storage-engine), with RocksDB available as an option.  Pebble is intended to be bidirectionally compatible with the RocksDB on-disk format, but differs in that it:
-
-- Is written in Go and implements a subset of RocksDB's large feature set.
-- Contains optimizations that benefit CockroachDB.
-
-Internally, each store contains two instances of the storage engine:
-
-- One for storing temporary distributed SQL data
-- One for all other data on the node
-
-In addition, there is also a block cache shared amongst all of the stores in a node. These stores in turn have a collection of range replicas. More than one replica for a range will never be placed on the same store or even the same node.
-
-### Interactions with other layers
-
-In relationship to other layers in CockroachDB, the storage layer:
-
-- Serves successful reads and writes from the replication layer.
-
-## Components
-
-### Pebble
-
-<span class="version-tag">New in v20.2</span>: CockroachDB uses [Pebble by default](../cockroach-start.html#storage-engine)––an embedded key-value store with a RocksDB-compatible API developed by Cockroach Labs––to read and write data to disk. You can find more information about it on the [Pebble GitHub page](https://github.com/cockroachdb/pebble) or in the blog post [Introducing Pebble: A RocksDB Inspired Key-Value Store Written in Go](https://www.cockroachlabs.com/blog/pebble-rocksdb-kv-store/).
-
-Pebble integrates well with CockroachDB for a number of reasons:
-
-- It is a key-value store, which makes mapping to our key-value layer simple
-- It provides atomic write batches and snapshots, which give us a subset of transactions
-- It is developed by Cockroach Labs engineers
-- It contains optimizations that are not in RocksDB, that are inspired by how CockroachDB uses the storage engine.  For an example of such an optimization, see the blog post [Faster Bulk-Data Loading in CockroachDB](https://www.cockroachlabs.com/blog/bulk-data-import/).
-
-Efficient storage for the keys is guaranteed by the underlying Pebble engine by means of prefix compression.
-
-### RocksDB
-
-If you [choose it at node startup time (it's not the default)](../cockroach-start.html#storage-engine), CockroachDB uses RocksDB––an embedded key-value store––to read and write data to disk. You can find more information about RocksDB on the [RocksDB Basics GitHub page](https://github.com/facebook/rocksdb/wiki/RocksDB-Basics).
-
-RocksDB integrates well with CockroachDB for a number of reasons:
-
-- It is a key-value store, which makes mapping to our key-value layer simple
-- It provides atomic write batches and snapshots, which give us a subset of transactions
-
-Efficient storage for the keys is guaranteed by the underlying RocksDB engine by means of prefix compression.
-
-### MVCC
-
-CockroachDB relies heavily on [multi-version concurrency control (MVCC)](https://en.wikipedia.org/wiki/Multiversion_concurrency_control) to process concurrent requests and guarantee consistency. Much of this work is done by using [hybrid logical clock (HLC) timestamps](transaction-layer.html#time-and-hybrid-logical-clocks) to differentiate between versions of data, track commit timestamps, and identify a value's garbage collection expiration. All of this MVCC data is then stored in Pebble.
-
-Despite being implemented in the storage layer, MVCC values are widely used to enforce consistency in the [transaction layer](transaction-layer.html). For example, CockroachDB maintains a [timestamp cache](transaction-layer.html#timestamp-cache), which stores the timestamp of the last time that the key was read. If a write operation occurs at a lower timestamp than the largest value in the read timestamp cache, it signifies there’s a potential anomaly and the transaction must be restarted at a later timestamp.
-
-#### Time-travel
-
-As described in the [SQL:2011 standard](https://en.wikipedia.org/wiki/SQL:2011#Temporal_support), CockroachDB supports time travel queries (enabled by MVCC).
-
-To do this, all of the schema information also has an MVCC-like model behind it. This lets you perform `SELECT...AS OF SYSTEM TIME`, and CockroachDB uses the schema information as of that time to formulate the queries.
-
-Using these tools, you can get consistent data from your database as far back as your garbage collection period.
-
-### Garbage collection
-
-CockroachDB regularly garbage collects MVCC values to reduce the size of data stored on disk. To do this, we compact old MVCC values when there is a newer MVCC value with a timestamp that's older than the garbage collection period. The garbage collection period can be set at the cluster, database, or table level by configuring the [`gc.ttlseconds` replication zone variable](../configure-replication-zones.html#gc-ttlseconds). For more information about replication zones, see [Configure Replication Zones](../configure-replication-zones.html).
-
-#### Protected timestamps
-
-Garbage collection can only run on MVCC values which are not covered by a *protected timestamp*. The protected timestamp subsystem exists to ensure the safety of operations that rely on historical data, such as:
-
-- [Imports](../import.html), including [`IMPORT INTO`](../import-into.html)
-- [Backups](../backup.html)
-- [Streaming data out of CockroachDB using changefeeds](../stream-data-out-of-cockroachdb-using-changefeeds.html)
-- [Online schema changes](../online-schema-changes.html)
-
-Protected timestamps ensure the safety of historical data while also enabling shorter [GC TTLs](../configure-replication-zones.html#gc-ttlseconds). A shorter GC TTL means that fewer previous MVCC values are kept around. This can help lower query execution costs for workloads which update rows frequently throughout the day, since [the SQL layer](sql-layer.html) has to scan over previous MVCC values to find the current value of a row.
-
-##### How protected timestamps work
-
-Protected timestamps work by creating *protection records*, which are stored in an internal system table. When a long-running job such as a backup wants to protect data at a certain timestamp from being garbage collected, it creates a protection record associated with that data and timestamp.
-
-Upon successful creation of a protection record, the MVCC values for the specified data at timestamps less than or equal to the protected timestamp will not be garbage collected. When the job that created the protection record finishes its work, it removes the record, allowing the garbage collector to run on the formerly protected values.
-
-## Interactions with other layers
-
-### Storage and replication layers
-
-The storage layer commits writes from the Raft log to disk, as well as returns requested data (i.e., reads) to the replication layer.
-
-## What's next?
-
-Now that you've learned about our architecture, [start a local cluster](../install-cockroachdb.html) and start [building an app with CockroachDB](../example-apps.html).
diff --git a/src/current/v20.2/architecture/transaction-layer.md b/src/current/v20.2/architecture/transaction-layer.md
deleted file mode 100644
index 380e340ff16..00000000000
--- a/src/current/v20.2/architecture/transaction-layer.md
+++ /dev/null
@@ -1,386 +0,0 @@
----
-title: Transaction Layer
-summary: The transaction layer of CockroachDB's architecture implements support for ACID transactions by coordinating concurrent operations.
-toc: true
----
-
-The transaction layer of CockroachDB's architecture implements support for ACID transactions by coordinating concurrent operations.
-
-{{site.data.alerts.callout_info}}
-If you haven't already, we recommend reading the [Architecture Overview](overview.html).
-{{site.data.alerts.end}}
-
-## Overview
-
-Above all else, CockroachDB believes consistency is the most important feature of a database––without it, developers cannot build reliable tools, and businesses suffer from potentially subtle and hard to detect anomalies.
-
-To provide consistency, CockroachDB implements full support for ACID transaction semantics in the transaction layer. However, it's important to realize that *all* statements are handled as transactions, including single statements––this is sometimes referred to as "autocommit mode" because it behaves as if every statement is followed by a `COMMIT`.
-
-For code samples of using transactions in CockroachDB, see our documentation on [transactions](../transactions.html#sql-statements).
-
-Because CockroachDB enables transactions that can span your entire cluster (including cross-range and cross-table transactions), it achieves correctness using a distributed, atomic commit protocol called [Parallel Commits](#parallel-commits).
-
-### Writes and reads (phase 1)
-
-#### Writing
-
-When the transaction layer executes write operations, it doesn't directly write values to disk. Instead, it creates several things that help it mediate a distributed transaction:
-
-- **Locks** for all of a transaction’s writes, which represent a provisional, uncommitted state. CockroachDB has several different types of locking:
-
-  - **Unreplicated Locks** are stored in an in-memory, per-node lock table by the [concurrency control](#concurrency-control) machinery. These locks are not replicated via [Raft](replication-layer.html#raft).
-
-  - **Replicated Locks** (also known as [write intents](#write-intents)) are replicated via [Raft](replication-layer.html#raft), and act as a combination of a provisional value and an exclusive lock. They are essentially the same as standard [multi-version concurrency control (MVCC)](storage-layer.html#mvcc) values but also contain a pointer to the [transaction record](#transaction-records) stored on the cluster.
-
-- A **transaction record** stored in the range where the first write occurs, which includes the transaction's current state (which is either `PENDING`, `STAGING`, `COMMITTED`, or `ABORTED`).
-
-As write intents are created, CockroachDB checks for newer committed values. If newer committed values exist, the transaction may be restarted. If existing write intents for the same keys exist, it is resolved as a [transaction conflict](#transaction-conflicts).
-
-If transactions fail for other reasons, such as failing to pass a SQL constraint, the transaction is aborted.
-
-#### Reading
-
-If the transaction has not been aborted, the transaction layer begins executing read operations. If a read only encounters standard MVCC values, everything is fine. However, if it encounters any write intents, the operation must be resolved as a [transaction conflict](#transaction-conflicts).
-
-### Commits (phase 2)
-
-CockroachDB checks the running transaction's record to see if it's been `ABORTED`; if it has, it restarts the transaction.
-
-In the common case, it sets the transaction record's state to `STAGING`, and checks the transaction's pending write intents to see if they have succeeded (i.e., been replicated across the cluster).
-
-If the transaction passes these checks, CockroachDB responds with the transaction's success to the client, and moves on to the cleanup phase. At this point, the transaction is committed, and the client is free to begin sending more requests to the cluster.
-
-For a more detailed walkthrough of the commit protocol, see [Parallel Commits](#parallel-commits).
-
-### Cleanup (asynchronous phase 3)
-
-After the transaction has been committed, it should be marked as such, and all of the write intents should be resolved. To do this, the coordinating node––which kept a track of all of the keys it wrote––reaches out and:
-
-- Moves the state of the transaction record from `STAGING` to `COMMITTED`.
-- Resolves the transaction's write intents to MVCC values by removing the element that points it to the transaction record.
-- Deletes the write intents.
-
-This is simply an optimization, though. If operations in the future encounter write intents, they always check their transaction records––any operation can resolve or remove write intents by checking the transaction record's status.
-
-### Interactions with other layers
-
-In relationship to other layers in CockroachDB, the transaction layer:
-
-- Receives KV operations from the SQL layer.
-- Controls the flow of KV operations sent to the distribution layer.
-
-## Technical details and components
-
-### Time and hybrid logical clocks
-
-In distributed systems, ordering and causality are difficult problems to solve. While it's possible to rely entirely on Raft consensus to maintain serializability, it would be inefficient for reading data. To optimize performance of reads, CockroachDB implements hybrid-logical clocks (HLC) which are composed of a physical component (always close to local wall time) and a logical component (used to distinguish between events with the same physical component). This means that HLC time is always greater than or equal to the wall time. You can find more detail in the [HLC paper](http://www.cse.buffalo.edu/tech-reports/2014-04.pdf).
-
-In terms of transactions, the gateway node picks a timestamp for the transaction using HLC time. Whenever a transaction's timestamp is mentioned, it's an HLC value. This timestamp is used to both track versions of values (through [multi-version concurrency control](storage-layer.html#mvcc)), as well as provide our transactional isolation guarantees.
-
-When nodes send requests to other nodes, they include the timestamp generated by their local HLCs (which includes both physical and logical components). When nodes receive requests, they inform their local HLC of the timestamp supplied with the event by the sender. This is useful in guaranteeing that all data read/written on a node is at a timestamp less than the next HLC time.
-
-This then lets the node primarily responsible for the range (i.e., the leaseholder) serve reads for data it stores by ensuring the transaction reading the data is at an HLC time greater than the MVCC value it's reading (i.e., the read always happens "after" the write).
-
-#### Max clock offset enforcement
-
-CockroachDB requires moderate levels of clock synchronization to preserve data consistency. For this reason, when a node detects that its clock is out of sync with at least half of the other nodes in the cluster by 80% of the maximum offset allowed (500ms by default), **it crashes immediately**.
-
-While [serializable consistency](https://en.wikipedia.org/wiki/Serializability) is maintained regardless of clock skew, skew outside the configured clock offset bounds can result in violations of single-key linearizability between causally dependent transactions. It's therefore important to prevent clocks from drifting too far by running [NTP](http://www.ntp.org/) or other clock synchronization software on each node.
-
-For more detail about the risks that large clock offsets can cause, see [What happens when node clocks are not properly synchronized?](../operational-faqs.html#what-happens-when-node-clocks-are-not-properly-synchronized)
-
-### Timestamp cache
-
-As part of providing serializability, whenever an operation reads a value, we store the operation's timestamp in a timestamp cache, which shows the high-water mark for values being read.
-
-Whenever a write occurs, its timestamp is checked against the timestamp cache. If the timestamp is less than the timestamp cache's latest value, we attempt to push the timestamp for its transaction forward to a later time. Pushing the timestamp might cause the transaction to restart in the second phase of the transaction (see [read refreshing](#read-refreshing)).
-
-### client.Txn and TxnCoordSender
-
-As we mentioned in the SQL layer's architectural overview, CockroachDB converts all SQL statements into key-value (KV) operations, which is how data is ultimately stored and accessed.
-
-All of the KV operations generated from the SQL layer use `client.Txn`, which is the transactional interface for the CockroachDB KV layer––but, as we discussed above, all statements are treated as transactions, so all statements use this interface.
-
-However, `client.Txn` is actually just a wrapper around `TxnCoordSender`, which plays a crucial role in our code base by:
-
-- Dealing with transactions' state. After a transaction is started, `TxnCoordSender` starts asynchronously sending heartbeat messages to that transaction's transaction record, which signals that it should be kept alive. If the `TxnCoordSender`'s heartbeating stops, the transaction record is moved to the `ABORTED` status.
-- Tracking each written key or key range over the course of the transaction.
-- Clearing the accumulated write intent for the transaction when it's committed or aborted. All requests being performed as part of a transaction have to go through the same `TxnCoordSender` to account for all of its write intents, which optimizes the cleanup process.
-
-After setting up this bookkeeping, the request is passed to the `DistSender` in the distribution layer.
-
-### Transaction records
-
-To track the status of a transaction's execution, we write a value called a transaction record to our key-value store. All of a transaction's write intents point back to this record, which lets any transaction check the status of any write intents it encounters. This kind of canonical record is crucial for supporting concurrency in a distributed environment.
-
-Transaction records are always written to the same range as the first key in the transaction, which is known by the `TxnCoordSender`. However, the transaction record itself isn't created until one of the following conditions occur:
-
-- The write operation commits
-- The `TxnCoordSender` heartbeats the transaction
-- An operation forces the transaction to abort
-
-Given this mechanism, the transaction record uses the following states:
-
-- `PENDING`: Indicates that the write intent's transaction is still in progress.
-- `COMMITTED`: Once a transaction has completed, this status indicates that write intents can be treated as committed values.
-- `STAGING`: Used to enable the [Parallel Commits](#parallel-commits) feature. Depending on the state of the write intents referenced by this record, the transaction may or may not be in a committed state.
-- `ABORTED`: Indicates that the transaction was aborted and its values should be discarded.
-- _Record does not exist_: If a transaction encounters a write intent whose transaction record doesn't exist, it uses the write intent's timestamp to determine how to proceed. If the write intent's timestamp is within the transaction liveness threshold, the write intent's transaction is treated as if it is `PENDING`, otherwise it's treated as if the transaction is `ABORTED`.
-
-The transaction record for a committed transaction remains until all its write intents are converted to MVCC values.
-
-### Write intents
-
-Values in CockroachDB are not written directly to the storage layer; instead values are written in a provisional state known as a "write intent." These are essentially MVCC records with an additional value added to them which identifies the transaction record to which the value belongs. They can be thought of as a combination of a replicated lock and a replicated provisional value.
-
-Whenever an operation encounters a write intent (instead of an MVCC value), it looks up the status of the transaction record to understand how it should treat the write intent value. If the transaction record is missing, the operation checks the write intent's timestamp and evaluates whether or not it is considered expired.
-
- CockroachDB manages concurrency control using a per-node, in-memory lock table. This table holds a collection of locks acquired by in-progress transactions, and incorporates information about write intents as they are discovered during evaluation. For more information, see the section below on [Concurrency control](#concurrency-control).
-
-#### Resolving write intents
-
-Whenever an operation encounters a write intent for a key, it attempts to "resolve" it, the result of which depends on the write intent's transaction record:
-
-- `COMMITTED`: The operation reads the write intent and converts it to an MVCC value by removing the write intent's pointer to the transaction record.
-- `ABORTED`: The write intent is ignored and deleted.
-- `PENDING`: This signals there is a [transaction conflict](#transaction-conflicts), which must be resolved.
-- `STAGING`: This signals that the operation should check whether the staging transaction is still in progress by verifying that the transaction coordinator is still heartbeating the staging transaction’s record. If the coordinator is still heartbeating the record, the operation should wait. For more information, see [Parallel Commits](#parallel-commits).
-- _Record does not exist_: If the write intent was created within the transaction liveness threshold, it's the same as `PENDING`, otherwise it's treated as `ABORTED`.
-
-### Concurrency control
-
- The *concurrency manager* sequences incoming requests and provides isolation between the transactions that issued those requests that intend to perform conflicting operations. This activity is also known as [concurrency control](https://en.wikipedia.org/wiki/Concurrency_control).
-
-The concurrency manager combines the operations of a *latch manager* and a *lock table* to accomplish this work:
-
-- The *latch manager* sequences the incoming requests and provides isolation between those requests.
-- The *lock table* provides both locking and sequencing of requests (in concert with the latch manager). It is a per-node, in-memory data structure that holds a collection of locks acquired by in-progress transactions. To ensure compatibility with the existing system of [write intents](#write-intents) (a.k.a. replicated, exclusive locks), it pulls in information about these external locks as necessary when they are discovered in the course of evaluating requests.
-
-The concurrency manager enables support for pessimistic locking via [SQL](sql-layer.html) using the [`SELECT FOR UPDATE`](../select-for-update.html) statement. This statement can be used to increase throughput and decrease tail latency for contended operations.
-
-For more details about how the concurrency manager works with the latch manager and lock table, see the sections below:
-
-- [Concurrency manager](#concurrency-manager)
-- [Lock table](#lock-table)
-- [Latch manager](#latch-manager)
-
-#### Concurrency manager
-
- The concurrency manager is a structure that sequences incoming requests and provides isolation between the transactions that issued those requests that intend to perform conflicting operations. During sequencing, conflicts are discovered and any found are resolved through a combination of passive queuing and active pushing. Once a request has been sequenced, it is free to evaluate without concerns of conflicting with other in-flight requests due to the isolation provided by the manager. This isolation is guaranteed for the lifetime of the request but terminates once the request completes.
-
-Each request in a transaction should be isolated from other requests, both during the request's lifetime and after the request has completed (assuming it acquired locks), but within the surrounding transaction's lifetime.
-
-The manager accommodates this by allowing transactional requests to acquire locks, which outlive the requests themselves. Locks extend the duration of the isolation provided over specific keys to the lifetime of the lock-holder transaction itself. They are (typically) only released when the transaction commits or aborts. Other requests that find these locks while being sequenced wait on them to be released in a queue before proceeding. Because locks are checked during sequencing, locks do not need to be checked again during evaluation.
-
-However, not all locks are stored directly under the manager's control, so not all locks are discoverable during sequencing. Specifically, write intents (replicated, exclusive locks) are stored inline in the MVCC keyspace, so they are not detectable until request evaluation time. To accommodate this form of lock storage, the manager integrates information about external locks with the concurrency manager structure.
-
-{{site.data.alerts.callout_info}}
-Currently, the concurrency manager operates on an unreplicated lock table structure. In the future, we intend to pull all locks, including those associated with [write intents](#write-intents), into the concurrency manager directly through a replicated lock table structure.
-{{site.data.alerts.end}}
-
-Fairness is ensured between requests. In general, if any two requests conflict then the request that arrived first will be sequenced first. As such, sequencing guarantees first-in, first-out (FIFO) semantics. The primary exception to this is that a request that is part of a transaction which has already acquired a lock does not need to wait on that lock during sequencing, and can therefore ignore any queue that has formed on the lock. For other exceptions to this sequencing guarantee, see the [lock table](#lock-table) section below.
-
-#### Lock table
-
- The lock table is a per-node, in-memory data structure that holds a collection of locks acquired by in-progress transactions. Each lock in the table has a possibly-empty lock wait-queue associated with it, where conflicting transactions can queue while waiting for the lock to be released.  Items in the locally stored lock wait-queue are propagated as necessary (via RPC) to the existing [`TxnWaitQueue`](#txnwaitqueue), which is stored on the leader of the range's Raft group that contains the [transaction record](#transaction-records).
-
-The database is read and written using "requests". Transactions are composed of one or more requests. Isolation is needed across requests. Additionally, since transactions represent a group of requests, isolation is needed across such groups. Part of this isolation is accomplished by maintaining multiple versions and part by allowing requests to acquire locks. Even the isolation based on multiple versions requires some form of mutual exclusion to ensure that a read and a conflicting lock acquisition do not happen concurrently. The lock table provides both locking and sequencing of requests (in concert with the use of latches).
-
-Locks outlive the requests themselves and thereby extend the duration of the isolation provided over specific keys to the lifetime of the lock-holder transaction itself. They are (typically) only released when the transaction commits or aborts. Other requests that find these locks while being sequenced wait on them to be released in a queue before proceeding. Because locks are checked during sequencing, requests are guaranteed access to all declared keys after they have been sequenced. In other words, locks do not need to be checked again during evaluation.
-
-{{site.data.alerts.callout_info}}
-Currently, not all locks are stored directly under lock table control. Some locks are stored as [write intents](#write-intents) in the MVCC layer, and are thus not discoverable during sequencing. Specifically, write intents (replicated, exclusive locks) are stored inline in the MVCC keyspace, so they are often not detectable until request evaluation time. To accommodate this form of lock storage, the lock table adds information about these locks as they are encountered during evaluation. In the future, we intend to pull all locks, including those associated with write intents, into the lock table directly.
-{{site.data.alerts.end}}
-
-The lock table also provides fairness between requests. If two requests conflict then the request that arrived first will typically be sequenced first. There are some exceptions:
-
-- A request that is part of a transaction which has already acquired a lock does not need to wait on that lock during sequencing, and can therefore ignore any queue that has formed on the lock.
-
-- Contending requests that encounter different levels of contention may be sequenced in non-FIFO order. This is to allow for greater concurrency. For example, if requests *R1* and *R2* contend on key *K2*, but *R1* is also waiting at key *K1*, *R2* may slip past *R1* and evaluate.
-
-#### Latch manager
-
-The latch manager sequences incoming requests and provides isolation between those requests under the supervision of the [concurrency manager](#concurrency-manager).
-
-The way the latch manager works is as follows:
-
-As write requests occur for a range, the range's leaseholder serializes them; that is, they are placed into some consistent order.
-
-To enforce this serialization, the leaseholder creates a "latch" for the keys in the write value, providing uncontested access to the keys. If other requests come into the leaseholder for the same set of keys, they must wait for the latch to be released before they can proceed.
-
-Read requests also generate latches.  Multiple read latches over the same keys can be held concurrently, but a read latch and a write latch over the same keys cannot.
-
-Another way to think of a latch is like a [mutex](https://en.wikipedia.org/wiki/Lock_(computer_science)) which is only needed for the duration of a single, low-level request. To coordinate longer-running, higher-level requests (i.e., client transactions), we use a durable system of [write intents](#write-intents).
-
-### Isolation levels
-
-Isolation is an element of [ACID transactions](https://en.wikipedia.org/wiki/ACID), which determines how concurrency is controlled, and ultimately guarantees consistency.
-
-CockroachDB executes all transactions at the strongest ANSI transaction isolation level: `SERIALIZABLE`. All other ANSI transaction isolation levels (e.g., `SNAPSHOT`, `READ UNCOMMITTED`, `READ COMMITTED`, and `REPEATABLE READ`) are automatically upgraded to `SERIALIZABLE`. Weaker isolation levels have historically been used to maximize transaction throughput. However, [recent research](http://www.bailis.org/papers/acidrain-sigmod2017.pdf) has demonstrated that the use of weak isolation levels results in substantial vulnerability to concurrency-based attacks.
-
-CockroachDB now only supports `SERIALIZABLE` isolation. In previous versions of CockroachDB, you could set transactions to `SNAPSHOT` isolation, but that feature has been removed.
-
-`SERIALIZABLE` isolation does not allow any anomalies in your data, and is enforced by requiring the client to retry transactions if serializability violations are possible.
-
-### Transaction conflicts
-
-CockroachDB's transactions allow the following types of conflicts that involve running into an intent:
-
-- **Write/write**, where two `PENDING` transactions create write intents for the same key.
-- **Write/read**, when a read encounters an existing write intent with a timestamp less than its own.
-
-To make this simpler to understand, we'll call the first transaction `TxnA` and the transaction that encounters its write intents `TxnB`.
-
-CockroachDB proceeds through the following steps:
-
-1. If the transaction has an explicit priority set (i.e., `HIGH` or `LOW`), the transaction with the lower priority is aborted (in the write/write case) or has its timestamp pushed (in the write/read case).
-
-1. If the encountered transaction is expired, it's `ABORTED` and conflict resolution succeeds. We consider a write intent expired if:
-	- It doesn't have a transaction record and its timestamp is outside of the transaction liveness threshold.
-	- Its transaction record hasn't been heartbeated within the transaction liveness threshold.
-
-2. `TxnB` enters the `TxnWaitQueue` to wait for `TxnA` to complete.
-
-Additionally, the following types of conflicts that do not involve running into intents can arise:
-
-- **Write after read**, when a write with a lower timestamp encounters a later read. This is handled through the [timestamp cache](#timestamp-cache).
-- **Read within uncertainty window**, when a read encounters a value with a higher timestamp but it's ambiguous whether the value should be considered to be in the future or in the past of the transaction because of possible *clock skew*. This is handled by attempting to push the transaction's timestamp beyond the uncertain value (see [read refreshing](#read-refreshing)). Note that, if the transaction has to be retried, reads will never encounter uncertainty issues on any node which was previously visited, and that there's never any uncertainty on values read from the transaction's gateway node.
-
-### TxnWaitQueue
-
-The `TxnWaitQueue` tracks all transactions that could not push a transaction whose writes they encountered, and must wait for the blocking transaction to complete before they can proceed.
-
-The `TxnWaitQueue`'s structure is a map of blocking transaction IDs to those they're blocking. For example:
-
-~~~
-txnA -> txn1, txn2
-txnB -> txn3, txn4, txn5
-~~~
-
-Importantly, all of this activity happens on a single node, which is the leader of the range's Raft group that contains the transaction record.
-
-Once the transaction does resolve––by committing or aborting––a signal is sent to the `TxnWaitQueue`, which lets all transactions that were blocked by the resolved transaction begin executing.
-
-Blocked transactions also check the status of their own transaction to ensure they're still active. If the blocked transaction was aborted, it's simply removed.
-
-If there is a deadlock between transactions (i.e., they're each blocked by each other's Write Intents), one of the transactions is randomly aborted. In the above example, this would happen if `TxnA` blocked `TxnB` on `key1` and `TxnB` blocked `TxnA` on `key2`.
-
-### Read refreshing
-
-Whenever a transaction's timestamp has been pushed, additional checks are required before allowing it to commit at the pushed timestamp: any values which the transaction previously read must be checked to verify that no writes have subsequently occurred between the original transaction timestamp and the pushed transaction timestamp. This check prevents serializability violation. The check is done by keeping track of all the reads using a dedicated `RefreshRequest`. If this succeeds, the transaction is allowed to commit (transactions perform this check at commit time if they've been pushed by a different transaction or by the timestamp cache, or they perform the check whenever they encounter a `ReadWithinUncertaintyIntervalError` immediately, before continuing).
-If the refreshing is unsuccessful, then the transaction must be retried at the pushed timestamp.
-
-### Transaction pipelining
-
-Transactional writes are pipelined when being replicated and when being written to disk, dramatically reducing the latency of transactions that perform multiple writes. For example, consider the following transaction:
-
-{% include copy-clipboard.html %}
-~~~ sql
--- CREATE TABLE kv (id UUID PRIMARY KEY DEFAULT gen_random_uuid(), key VARCHAR, value VARCHAR);
-> BEGIN;
-INSERT into kv (key, value) VALUES ('apple', 'red');
-INSERT into kv (key, value) VALUES ('banana', 'yellow');
-INSERT into kv (key, value) VALUES ('orange', 'orange');
-COMMIT;
-~~~
-
-With transaction pipelining, write intents are replicated from leaseholders in parallel, so the waiting all happens at the end, at transaction commit time.
-
-At a high level, transaction pipelining works as follows:
-
-1. For each statement, the transaction gateway node communicates with the leaseholders (*L*<sub>1</sub>, *L*<sub>2</sub>, *L*<sub>3</sub>, ..., *L*<sub>i</sub>) for the ranges it wants to write to. Since the primary keys in the table above are UUIDs, the ranges are probably split across multiple leaseholders (this is a good thing, as it decreases [transaction conflicts](#transaction-conflicts)).
-
-2. Each leaseholder *L*<sub>i</sub> receives the communication from the transaction gateway node and does the following in parallel:
-  - Creates write intents and sends them to its follower nodes.
-  - Responds to the transaction gateway node that the write intents have been sent. Note that replication of the intents is still in-flight at this stage.
-
-3. When attempting to commit, the transaction gateway node then waits for the write intents to be replicated in parallel to all of the leaseholders' followers. When it receives responses from the leaseholders that the write intents have propagated, it commits the transaction.
-
-In terms of the SQL snippet shown above, all of the waiting for write intents to propagate and be committed happens once, at the very end of the transaction, rather than for each individual write. This means that the cost of multiple writes is not `O(n)` in the number of SQL DML statements; instead, it's `O(1)`.
-
-### Parallel Commits
-
-The *Parallel Commits* feature introduces a new, optimized atomic commit protocol that cuts the commit latency of a transaction in half, from two rounds of consensus down to one. Combined with [Transaction pipelining](#transaction-pipelining), this brings the latency incurred by common OLTP transactions to near the theoretical minimum: the sum of all read latencies plus one round of consensus latency.
-
-Under the new atomic commit protocol, the transaction coordinator can return to the client eagerly when it knows that the writes in the transaction have succeeded. Once this occurs, the transaction coordinator can set the transaction record's state to `COMMITTED` and resolve the transaction's write intents asynchronously.
-
-The transaction coordinator is able to do this while maintaining correctness guarantees because it populates the transaction record with enough information (via a new `STAGING` state, and an array of in-flight writes) for other transactions to determine whether all writes in the transaction are present, and thus prove whether or not the transaction is committed.
-
-For an example showing how the Parallel Commits feature works in more detail, see [Parallel Commits - step by step](#parallel-commits-step-by-step).
-
-{{site.data.alerts.callout_info}}
-The latency until intents are resolved is unchanged by the introduction of Parallel Commits: two rounds of consensus are still required to resolve intents. This means that [contended workloads](../performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention) are expected to profit less from this feature.
-{{site.data.alerts.end}}
-
-#### Parallel Commits - step by step
-
-This section contains a step by step example of a transaction that writes its data using the Parallel Commits atomic commit protocol and does not encounter any errors or conflicts.
-
-##### Step 1
-
-The client starts the transaction. A transaction coordinator is created to manage the state of that transaction.
-
-![parallel-commits-00.png](../../images/{{page.version.version}}/parallel-commits-00.png "Parallel Commits Diagram #1")
-
-##### Step 2
-
-The client issues a write to the "Apple" key. The transaction coordinator begins the process of laying down a write intent on the key where the data will be written. The write intent has a timestamp and a pointer to an as-yet nonexistent transaction record. Additionally, each write intent in the transaction is assigned a unique sequence number which is used to uniquely identify it.
-
-The coordinator avoids creating the record for as long as possible in the transaction's lifecycle as an optimization. The fact that the transaction record does not yet exist is denoted in the diagram by its dotted lines.
-
-{{site.data.alerts.callout_info}}
-The coordinator does not need to wait for write intents to replicate from leaseholders before moving on to the next statement from the client, since that is handled in parallel by [Transaction Pipelining](#transaction-pipelining).
-{{site.data.alerts.end}}
-
-![parallel-commits-01.png](../../images/{{page.version.version}}/parallel-commits-01.png "Parallel Commits Diagram #2")
-
-##### Step 3
-
-The client issues a write to the "Berry" key. The transaction coordinator lays down a write intent on the key where the data will be written. This write intent has a pointer to the same transaction record as the intent created in [Step 2](#step-2), since these write intents are part of the same transaction.
-
-As before, the coordinator does not need to wait for write intents to replicate from leaseholders before moving on to the next statement from the client.
-
-![parallel-commits-02.png](../../images/{{page.version.version}}/parallel-commits-02.png "Parallel Commits Diagram #3")
-
-##### Step 4
-
-The client issues a request to commit the transaction's writes. The transaction coordinator creates the transaction record and immediately sets the record's state to `STAGING`, and records the keys of each write that the transaction has in flight.
-
-It does this without waiting to see whether the writes from Steps [2](#step-2) and [3](#step-3) have succeeded.
-
-![parallel-commits-03.png](../../images/{{page.version.version}}/parallel-commits-03.png "Parallel Commits Diagram #4")
-
-##### Step 5
-
-The transaction coordinator, having received the client's `COMMIT` request, waits for the pending writes to succeed (i.e., be replicated across the cluster). Once all of the pending writes have succeeded, the coordinator returns a message to the client, letting it know that its transaction has committed successfully.
-
-![parallel-commits-04.png](../../images/{{page.version.version}}/parallel-commits-04.png "Parallel Commits Diagram #4")
-
-The transaction is now considered atomically committed, even though the state of its transaction record is still `STAGING`. The reason this is still considered an atomic commit condition is that a transaction is considered committed if it is one of the following logically equivalent states:
-
-1. The transaction record's state is `STAGING`, and its list of pending writes have all succeeded (i.e., the `InFlightWrites` have achieved consensus across the cluster). Any observer of this transaction can verify that its writes have replicated. Transactions in this state are *implicitly committed*.
-
-2. The transaction record's state is `COMMITTED`. Transactions in this state are *explicitly committed*.
-
-Despite their logical equivalence, the transaction coordinator now works as quickly as possible to move the transaction record from the `STAGING` to the `COMMITTED` state so that other transactions do not encounter a possibly conflicting transaction in the `STAGING` state and then have to do the work of verifying that the staging transaction's list of pending writes has succeeded. Doing that verification (also known as the "transaction status recovery process") would be slow.
-
-Additionally, when other transactions encounter a transaction in `STAGING` state, they check whether the staging transaction is still in progress by verifying that the transaction coordinator is still heartbeating that staging transaction’s record. If the coordinator is still heartbeating the record, the other transactions will wait, on the theory that letting the coordinator update the transaction record with the final result of the attempt to commit will be faster than going through the transaction status recovery process. This means that in practice, the transaction status recovery process is only used if the transaction coordinator dies due to an untimely crash.
-
-## Technical interactions with other layers
-
-### Transaction and SQL layer
-
-The transaction layer receives KV operations from `planNodes` executed in the SQL layer.
-
-### Transaction and distribution layer
-
-The `TxnCoordSender` sends its KV requests to `DistSender` in the distribution layer.
-
-## What's next?
-
-Learn how CockroachDB presents a unified view of your cluster's data in the [distribution layer](distribution-layer.html).
-
-<!-- Links -->
-
-[storage]: storage-layer.html
-[sql]: sql-layer.html
diff --git a/src/current/v20.2/array.md b/src/current/v20.2/array.md
deleted file mode 100644
index d03e76a237f..00000000000
--- a/src/current/v20.2/array.md
+++ /dev/null
@@ -1,338 +0,0 @@
----
-title: ARRAY
-summary: The ARRAY data type stores one-dimensional, 1-indexed, homogeneous arrays of any non-array data types.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-The `ARRAY` data type stores one-dimensional, 1-indexed, homogeneous arrays of any non-array [data type](data-types.html).
-
-The `ARRAY` data type is useful for ensuring compatibility with ORMs and other tools. However, if such compatibility is not a concern, it's more flexible to design your schema with normalized tables.
-
- CockroachDB supports indexing array columns with [GIN indexes](inverted-indexes.html). This permits accelerating containment queries ([`@>`](functions-and-operators.html#supported-operations) and [`<@`](functions-and-operators.html#supported-operations)) on array columns by adding an index to them.
-
-{{site.data.alerts.callout_info}}
-CockroachDB does not support nested arrays.
-{{site.data.alerts.end}}
-
-## Syntax
-
-A value of data type `ARRAY` can be expressed in the following ways:
-
-- Appending square brackets (`[]`) to any non-array [data type](data-types.html).
-- Adding the term `ARRAY` to any non-array [data type](data-types.html).
-
-## Size
-
-The size of an `ARRAY` value is variable, but it's recommended to keep values under 1 MB to ensure performance. Above that threshold, [write amplification](https://en.wikipedia.org/wiki/Write_amplification) and other considerations may cause significant performance degradation.  
-
-## Functions
-
-For the list of supported `ARRAY` functions, see [Functions and Operators](functions-and-operators.html#array-functions).
-
-## Examples
-
-### Creating an array column by appending square brackets
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE a (b STRING[]);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO a VALUES (ARRAY['sky', 'road', 'car']);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM a;
-~~~
-
-~~~
-        b
-------------------
-  {sky,road,car}
-(1 row)
-~~~
-
-### Creating an array column by adding the term `ARRAY`
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE c (d INT ARRAY);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO c VALUES (ARRAY[10,20,30]);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM c;
-~~~
-
-~~~
-      d
---------------
-  {10,20,30}
-(1 row)
-~~~
-
-### Accessing an array element using array index
-
-{{site.data.alerts.callout_info}}
-Arrays in CockroachDB are 1-indexed.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM c;
-~~~
-
-~~~
-      d
---------------
-  {10,20,30}
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT d[2] FROM c;
-~~~
-
-~~~
-  d
-------
-  20
-(1 row)
-~~~
-
-### Accessing an array column using containment queries
-
-You can use the [operators](functions-and-operators.html#supported-operations) `<@` ("is contained by") and `@>` ("contains") to run containment queries on `ARRAY` columns.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM c WHERE d <@ ARRAY[10,20,30,40,50];
-~~~
-
-~~~
-      d
---------------
-  {10,20,30}
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM c WHERE d @> ARRAY[10,20];
-~~~
-
-~~~
-      d
---------------
-  {10,20,30}
-(1 row)
-~~~
-
-### Appending an element to an array
-
-#### Using the `array_append` function
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM c;
-~~~
-
-~~~
-      d
---------------
-  {10,20,30}
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE c SET d = array_append(d, 40) WHERE d[3] = 30;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM c;
-~~~
-
-~~~
-        d
------------------
-  {10,20,30,40}
-(1 row)
-~~~
-
-#### Using the append (`||`) operator
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM c;
-~~~
-
-~~~
-        d
------------------
-  {10,20,30,40}
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE c SET d = d || 50 WHERE d[4] = 40;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM c;
-~~~
-
-~~~
-         d
---------------------
-  {10,20,30,40,50}
-(1 row)
-~~~
-
-### Ordering by an array
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE t (a INT ARRAY, b STRING);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t VALUES (ARRAY[3,4],'threefour'),(ARRAY[1,2],'onetwo');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t;
-~~~
-
-~~~
-    a   |     b
---------+------------
-  {3,4} | threefour
-  {1,2} | onetwo
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t ORDER BY a;
-~~~
-
-~~~
-    a   |     b
---------+------------
-  {1,2} | onetwo
-  {3,4} | threefour
-(2 rows)
-~~~
-
-## Supported casting and conversion
-
-[Casting](data-types.html#data-type-conversions-and-casts) between `ARRAY` values is supported when the data types of the arrays support casting. For example, it is possible to cast from a `BOOL` array to an `INT` array but not from a `BOOL` array to a `TIMESTAMP` array:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ARRAY[true,false,true]::INT[];
-~~~
-
-~~~
-   array
------------
-  {1,0,1}
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ARRAY[true,false,true]::TIMESTAMP[];
-~~~
-
-~~~
-pq: invalid cast: bool[] -> TIMESTAMP[]
-~~~
-
-You can cast an array to a `STRING` value, for compatibility with PostgreSQL:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ARRAY[1,NULL,3]::string;
-~~~
-
-~~~
-    array
---------------
-  {1,NULL,3}
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ARRAY[(1,'a b'),(2,'c"d')]::string;
-~~~
-
-~~~
-               array
-------------------------------------
-  {"(1,\"a b\")","(2,\"c\"\"d\")"}
-(1 row)
-~~~
-
-### Implicit casting
-
-CockroachDB supports implicit casting from string literals to arrays of all data types except the following:
-
-- [`BYTES`](bytes.html)
-- [`ENUM`](enum.html)
-- [`JSONB`](jsonb.html)
-- [`SERIAL`](serial.html)
-- `Box2D` [(spatial type)](spatial-glossary.html#data-types)
-- `GEOGRAPHY` [(spatial type)](spatial-glossary.html#data-types)
-- `GEOMETRY` [(spatial type)](spatial-glossary.html#data-types)
-
-For example, if you create a table with a column of type `INT[]`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE x (a UUID DEFAULT gen_random_uuid() PRIMARY KEY, b INT[]);
-~~~
-
-And then insert a string containing a comma-delimited set of integers contained in brackets:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO x(b) VALUES ('{1,2,3}'), (ARRAY[4,5,6]);
-~~~
-
-CockroachDB implicitly casts the string literal as an `INT[]`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM x;
-~~~
-
-~~~
-                   a                   |    b
----------------------------------------+----------
-  2ec0ed91-8a82-4f2e-888e-ae86ece4fc60 | {4,5,6}
-  a521d6e9-3a2a-490d-968c-1365cace038a | {1,2,3}
-(2 rows)
-~~~
-
-## See also
-
-- [Data Types](data-types.html)
-- [GIN Indexes](inverted-indexes.html)
diff --git a/src/current/v20.2/as-of-system-time.md b/src/current/v20.2/as-of-system-time.md
deleted file mode 100644
index 9fec8613318..00000000000
--- a/src/current/v20.2/as-of-system-time.md
+++ /dev/null
@@ -1,276 +0,0 @@
----
-title: AS OF SYSTEM TIME
-summary: The AS OF SYSTEM TIME clause executes a statement as of a specified time.
-toc: true
----
-
-The `AS OF SYSTEM TIME timestamp` clause causes statements to execute
-using the database contents "as of" a specified time in the past.
-
-This clause can be used to read historical data (also known as "[time
-travel queries](https://www.cockroachlabs.com/blog/time-travel-queries-select-witty_subtitle-the_future/)") and can also be advantageous for performance as it decreases
-transaction conflicts. For more details, see [SQL Performance Best
-Practices](performance-best-practices-overview.html#use-as-of-system-time-to-decrease-conflicts-with-long-running-queries).
-
-{{site.data.alerts.callout_info}}
-Historical data is available only within the garbage collection window, which is determined by the `ttlseconds` field in the [replication zone configuration](configure-replication-zones.html).
-{{site.data.alerts.end}}
-
-## Synopsis
-
-The `AS OF SYSTEM TIME` clause is supported in multiple SQL contexts,
-including but not limited to:
-
-- In [`SELECT` clauses](select-clause.html), at the very end of the `FROM` sub-clause.
-- In [`BACKUP`](backup.html), after the parameters of the `TO` sub-clause.
-- In [`RESTORE`](restore.html), after the parameters of the `FROM` sub-clause.
-- In [`BEGIN`](begin-transaction.html), after the `BEGIN` keyword.
-- In [`SET`](set-transaction.html), after the `SET TRANSACTION` keyword.
-
-## Parameters
-
-The `timestamp` argument supports the following formats:
-
-Format | Notes
----|---
-[`INT`](int.html) | Nanoseconds since the Unix epoch.
-negative [`INTERVAL`](interval.html) | Added to `statement_timestamp()`, and thus must be negative.
-[`STRING`](string.html) | A [`TIMESTAMP`](timestamp.html), [`INT`](int.html) of nanoseconds, or negative [`INTERVAL`](interval.html).
-`follower_read_timestamp()`| A [function](functions-and-operators.html) that returns the [`TIMESTAMP`](timestamp.html) `statement_timestamp() - 4.8s` (known as the [follower read timestamp](follower-reads.html#run-queries-that-use-follower-reads)). Using this function will set the time as close as possible to the present time while remaining safe for [follower reads](follower-reads.html).
-
-## Examples
-
-### Select historical data (time-travel)
-
-Imagine this example represents the database's current data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name, balance
-    FROM accounts
-   WHERE name = 'Edna Barath';
-~~~
-~~~
-+-------------+---------+
-|    name     | balance |
-+-------------+---------+
-| Edna Barath |     750 |
-| Edna Barath |    2200 |
-+-------------+---------+
-~~~
-
-We could instead retrieve the values as they were on October 3, 2016 at 12:45 UTC:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name, balance
-    FROM accounts
-         AS OF SYSTEM TIME '2016-10-03 12:45:00'
-   WHERE name = 'Edna Barath';
-~~~
-~~~
-+-------------+---------+
-|    name     | balance |
-+-------------+---------+
-| Edna Barath |     450 |
-| Edna Barath |    2000 |
-+-------------+---------+
-~~~
-
-
-### Using different timestamp formats
-
-Assuming the following statements are run at `2016-01-01 12:00:00`, they would execute as of `2016-01-01 08:00:00`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t AS OF SYSTEM TIME '2016-01-01 08:00:00'
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t AS OF SYSTEM TIME 1451635200000000000
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t AS OF SYSTEM TIME '1451635200000000000'
-~~~
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT * FROM t AS OF SYSTEM TIME '-4h'
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t AS OF SYSTEM TIME INTERVAL '-4h'
-~~~
-
-### Selecting from multiple tables
-
-{{site.data.alerts.callout_info}}
-It is not yet possible to select from multiple tables at different timestamps. The entire query runs at the specified time in the past.
-{{site.data.alerts.end}}
-
-When selecting over multiple tables in a single `FROM` clause, the `AS
-OF SYSTEM TIME` clause must appear at the very end and applies to the
-entire `SELECT` clause.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT * FROM t, u, v AS OF SYSTEM TIME '-4h';
-~~~
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT * FROM t JOIN u ON t.x = u.y AS OF SYSTEM TIME '-4h';
-~~~
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT * FROM (SELECT * FROM t), (SELECT * FROM u) AS OF SYSTEM TIME '-4h';
-~~~
-
-### Using `AS OF SYSTEM TIME` in subqueries
-
-To enable time travel, the `AS OF SYSTEM TIME` clause must appear in
-at least the top-level statement. It is not valid to use it only in a
-[subquery](subqueries.html).
-
-For example, the following is invalid:
-
-~~~
-SELECT * FROM (SELECT * FROM t AS OF SYSTEM TIME '-4h'), u
-~~~
-
-To facilitate the composition of larger queries from simpler queries,
-CockroachDB allows `AS OF SYSTEM TIME` in sub-queries under the
-following conditions:
-
-- The top level query also specifies `AS OF SYSTEM TIME`.
-- All the `AS OF SYSTEM TIME` clauses specify the same timestamp.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT * FROM (SELECT * FROM t AS OF SYSTEM TIME '-4h') tp
-           JOIN u ON tp.x = u.y
-           AS OF SYSTEM TIME '-4h'  -- same timestamp as above - OK.
-     WHERE x < 123;
-~~~
-
-### Using `AS OF SYSTEM TIME` in transactions
-
-You can use the [`BEGIN`](begin-transaction.html) statement to execute the transaction using the database contents "as of" a specified time in the past.
-
-{% include {{ page.version.version }}/sql/begin-transaction-as-of-system-time-example.md %}
-
-Alternatively, you can use the [`SET`](set-transaction.html) statement to execute the transaction using the database contents "as of" a specified time in the past.
-
-{% include {{ page.version.version }}/sql/set-transaction-as-of-system-time-example.md %}
-
-### Using `AS OF SYSTEM TIME` to recover recently lost data
-
-It is possible to recover lost data as a result of an online schema change prior to when [garbage collection](architecture/storage-layer.html#garbage-collection) begins:
-
-{% include copy-clipboard.html %}
-~~~sql
-> CREATE DATABASE foo;
-~~~
-~~~
-CREATE DATABASE
-
-
-Time: 3ms total (execution 3ms / network 0ms)
-~~~
-{% include copy-clipboard.html %}
-~~~sql
-> CREATE TABLE foo.bar (id INT PRIMARY KEY);
-~~~
-~~~
-CREATE TABLE
-
-
-Time: 4ms total (execution 3ms / network 0ms)
-~~~
-{% include copy-clipboard.html %}
-~~~sql
-> INSERT INTO foo.bar VALUES (1), (2);
-~~~
-~~~
-INSERT 2
-
-
-Time: 5ms total (execution 5ms / network 0ms)
-~~~
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT now();
-~~~
-~~~
-              now
---------------------------------
-  2022-02-01 21:11:53.63771+00
-(1 row)
-
-
-Time: 1ms total (execution 0ms / network 0ms)
-~~~
-{% include copy-clipboard.html %}
-~~~sql
-> DROP TABLE foo.bar;
-~~~
-~~~
-DROP TABLE
-
-
-Time: 45ms total (execution 45ms / network 0ms)
-~~~
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT * FROM foo.bar AS OF SYSTEM TIME '2022-02-01 21:11:53.63771+00';
-~~~
-~~~
-  id
-------
-   1
-   2
-(2 rows)
-
-
-Time: 2ms total (execution 2ms / network 0ms)
-~~~
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT * FROM foo.bar;
-~~~
-~~~
-ERROR: relation "foo.bar" does not exist
-SQLSTATE: 42P01
-~~~
-
-{{site.data.alerts.callout_danger}}
-Once garbage collection has occurred, `AS OF SYSTEM TIME` will no longer be able to recover lost data. For more long-term recovery solutions, consider taking either a [full or incremental backup](take-full-and-incremental-backups.html) of your cluster.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Select Historical Data](select-clause.html#select-historical-data-time-travel)
-- [Time-Travel Queries](https://www.cockroachlabs.com/blog/time-travel-queries-select-witty_subtitle-the_future/)
-- [Follower Reads](follower-reads.html)
-- [Follower Reads Topology Pattern](topology-follower-reads.html)
-
-## Tech note
-
-{{site.data.alerts.callout_info}}
-Although the following format is supported, it is not intended to be used by most users.
-{{site.data.alerts.end}}
-
-HLC timestamps can be specified using a [`DECIMAL`](decimal.html). The
-integer part is the wall time in nanoseconds. The fractional part is
-the logical counter, a 10-digit integer. This is the same format as
-produced by the `cluster_logical_timestamp()` function.
diff --git a/src/current/v20.2/authentication.md b/src/current/v20.2/authentication.md
deleted file mode 100644
index 6efd037990c..00000000000
--- a/src/current/v20.2/authentication.md
+++ /dev/null
@@ -1,310 +0,0 @@
----
-title: Authentication
-summary: Learn about the authentication features for secure CockroachDB clusters.
-toc: true
----
-
-Authentication refers to the act of verifying the identity of the other party in communication. CockroachDB requires TLS 1.3 digital certificates for inter-node authentication and accepts TLS 1.2 and TLS 1.3 certificates for client-node authentication. This document discusses how CockroachDB uses digital certificates and what your options are for configuring user authentication for SQL clients and the DB Console UI. It also offers a [conceptual overview](#background-on-public-key-cryptography-and-digital-certificates) of public key cryptography and digital certificates.
-
-- If you are familiar with public key cryptography and digital certificates, then reading the [Using digital certificates with CockroachDB](#using-digital-certificates-with-cockroachdb) section should be enough.
-- If you are unfamiliar with public key cryptography and digital certificates, you might want to skip over to the [conceptual overview](#background-on-public-key-cryptography-and-digital-certificates) first and then come back to the [Using digital certificates with CockroachDB](#using-digital-certificates-with-cockroachdb) section.
-- If you want to know how to create CockroachDB security certificates, see [Create Security Certificates](cockroach-cert.html).
-
-## Using digital certificates with CockroachDB
-
-Each CockroachDB node in a secure cluster must have a **node certificate**, which is a TLS 1.3 certificate. Note that the node certificate is multi-functional, which means that the same certificate is presented irrespective of whether the node is acting as a server or a client. The nodes use these certificates to establish secure connections with clients and with other nodes. Node certificates have the following requirements:
-
-- The hostname or address (IP address or DNS name) used to reach a node, either directly or through a load balancer, must be listed in the **Common Name** or **Subject Alternative Names** fields of the certificate:
-
-  - The values specified in [`--listen-addr`](cockroach-start.html#networking) and [`--advertise-addr`](cockroach-start.html#networking) flags, or the node hostname and fully qualified hostname if not specified
-  - Any host addresses/names used to reach a specific node
-  - Any load balancer addresses/names or DNS aliases through which the node could be reached
-  - `localhost` and local address if connections are made through the loopback device on the same host
-
-- CockroachDB must be configured to trust the certificate authority that signed the certificate.
-
-Based on your security setup, you can use the [`cockroach cert` commands](cockroach-cert.html), [`openssl` commands](create-security-certificates-openssl.html), or a [custom CA](create-security-certificates-custom-ca.html) to generate all the keys and certificates.
-
-A CockroachDB cluster consists of multiple nodes and clients. The nodes can communicate with each other, with the SQL clients, and the DB Console. In client-node SQL communication and client-UI communication, the node acts as a server, but in inter-node communication, a node may act as a server or a client. Hence authentication in CockroachDB involves:
-
-- Node authentication using [TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security) digital certificates.
-- Client authentication using TLS digital certificates, passwords, or [GSSAPI authentication](gssapi_authentication.html) (for Enterprise users).
-
-### Node authentication
-
-To set up a secure cluster without using an existing certificate authority, you'll need to generate the following files:
-
-- CA certificate
-- Node certificate and key
-- (Optional) UI certificate and key
-
-### Client authentication
-
-CockroachDB offers the following methods for client authentication:
-
-- **Client certificate and key authentication**, which is available to all users. To ensure the highest level of security, we recommend only using client certificate and key authentication.
-
-    Example:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs --user=jpointsman
-    ~~~
-
-- **Password authentication**, which is available to users and roles who you've created passwords for. Password creation is supported only in secure clusters. While users can use passwords to authenticate without supplying client certificates and keys, we recommend using certificate-based authentication whenever possible. For more information, see [Password authentication considerations](#password-authentication-considerations).
-
-    Example:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs --user=jpointsman
-    ~~~
-
-    ~~~
-    # Welcome to the CockroachDB SQL shell.
-    # All statements must be terminated by a semicolon.
-    # To exit, type: \q.
-    #
-    Enter password:
-    ~~~
-
-    Note that the client still needs the CA certificate to validate the nodes' certificates.
-
-    - To create a user with a password, use the `WITH PASSWORD` clause of [`CREATE ROLE`](create-role.html) or `CREATE USER`(create-user.html).
-    - To add a password to an existing user, use the [`ALTER ROLE`](alter-role.html) or [`ALTER USER`](alter-user.html) statement.
-    - To remove a user's password and thereby disable password authentication for the user, use `WITH PASSWORD NULL` clause of [`ALTER ROLE`](alter-role.html) or [`ALTER USER`](alter-user.html). 
-    - Note that the user performing these actions [must have the `CREATEROLE` and `CREATELOGIN` permissions](create-role.html#create-a-role-that-can-create-other-roles-and-manage-authentication-methods-for-the-new-roles) or be a member of the `admin` role.
-
-- **Password authentication without TLS**
-
-    <span class="version-tag">New in v20.2</span> For deployments where transport security is already handled at the infrastructure level (e.g., IPSec with DMZ), and TLS-based transport security is not possible or not desirable, CockroachDB now supports delegating transport security to the infrastructure with the new experimental flag `--accept-sql-without-tls` for [`cockroach start`](cockroach-start.html#security).
-
-    With this flag, SQL clients can establish a session over TCP without a TLS handshake. They still need to present valid authentication credentials, for example a password in the default configuration. Different authentication schemes can be further configured as per `server.host_based_authentication.configuration`. Note that we recommend using certificate-based authentication instead of password authentication whenever possible. For more information, see [Password authentication considerations](#password-authentication-considerations).
-
-    Example:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --user=jpointsman
-    ~~~
-
-    ~~~
-    # Welcome to the CockroachDB SQL shell.
-    # All statements must be terminated by a semicolon.
-    # To exit, type: \q.
-    #
-    Enter password:
-    ~~~
-
-- [**Single sign-on authentication**](sso.html), which is available to [Enterprise users](enterprise-licensing.html) to grant access to the DB Console.
-
-- [**GSSAPI authentication**](gssapi_authentication.html), which is available to [Enterprise users](enterprise-licensing.html).
-
-### Using `cockroach cert` or `openssl` commands
-
-You can use the [`cockroach cert` commands](cockroach-cert.html) or [`openssl` commands](create-security-certificates-openssl.html) to create the CA certificate and key, and node and client certificates and keys.
-
-Note that the node certificate created using `cockroach cert` or`openssl` is multi-functional, which means that the same certificate is presented irrespective of whether the node is acting as a server or a client. Thus all nodes must have the following:
-
-- `CN=node` for the special user `node` when the node acts as a client.
-- All IP addresses and DNS names for the node must be listed in the `Subject Alternative Name` field for when the node acts as a server. CockroachDB also supports [wildcard notation in DNS names](https://en.wikipedia.org/wiki/Wildcard_certificate).
-
-**Node key and certificates**
-
-A node must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate created using the `cockroach cert` command.
-`node.crt`   | Server certificate created using the `cockroach cert` command. <br><br> `node.crt` must have `CN=node` and the list of IP addresses and DNS names listed in the `Subject Alternative Name` field. CockroachDB also supports [wildcard notation in DNS names](https://en.wikipedia.org/wiki/Wildcard_certificate). <br><br>Must be signed by the CA represented by `ca.crt`.
-`node.key`   | Server key created using the `cockroach cert` command.
-
-**Client key and certificates**
-
-A client must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate created using the `cockroach cert` command.
-`client.<user>.crt` | Client certificate for `<user>` (e.g., `client.root.crt` for user `root`). <br><br>Each `client.<user>.crt` must have `CN=<user>`  (for example, `CN=marc` for `client.marc.crt`). <br><br> Must be signed by the CA represented by `ca.crt`.
-`client.<user>.key` | Client key created using the `cockroach cert` command.
-
-Alternatively, you can use [password authentication](#client-authentication). Remember, the client still needs `ca.crt` for node authentication.
-
-### Using a custom CA
-
-In the previous section, we discussed the scenario where the node and client certificates are signed by the CA created using the `cockroach cert` command. But what if you want to use an external CA, like your organizational CA or a public CA? In that case, our certificates might need some modification. Here’s why:
-
-As mentioned earlier, the node certificate is multi-functional, as in the same certificate is presented irrespective of whether the node is acting as a server or client. To make the certificate multi-functional, the `node.crt` must have `CN=node` and the list of IP addresses and DNS names listed in the`Subject Alternative Names` field.
-
-But some CAs will not sign a certificate containing a `CN` that is not an IP address or domain name. Here's why: The TLS client certificates are used to authenticate the client connecting to a server. Because most client certificates authenticate a user instead of a device, the certificates contain usernames instead of hostnames. This makes it difficult for public CAs to verify the client's identity and hence most public CAs will not sign a client certificate.
-
-To get around this issue, we can split the node key and certificate into two:
-
-- `node.crt` and `node.key`: The node certificate to be presented when the node acts as a server and the corresponding key. `node.crt` must have the list of IP addresses and DNS names listed in the `Subject Alternative Names`.
-- `client.node.crt` and `client.node.key`: The node certificate to be presented when the node acts as a client for another node, and the corresponding key. `client.node.crt` must have `CN=node`.
-
-**Node key and certificates**
-
-A node must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate issued by the public CA or your organizational CA.
-`node.crt`   | Node certificate for when node acts as server. <br><br>All IP addresses and DNS names for the node must be listed in the `Subject Alternative Name`. CockroachDB also supports [wildcard notation in DNS names](https://en.wikipedia.org/wiki/Wildcard_certificate). <br><br>Must be signed by the CA represented by `ca.crt`.
-`node.key`   | Server key corresponding to `node.crt`.
-`client.node.crt` | Node certificate for when node acts as client. <br><br>Must have `CN=node`. <br><br> Must be signed by the CA represented by `ca.crt`.
-`client.node.key` | Client key corresponding to `client.node.crt`.
-
-Optionally, if you have a certificate issued by a public CA to securely access the DB Console, you need to place the certificate and key (`ui.crt` and `ui.key` respectively) in the directory specified by the `--certs-dir` flag.
-
-**Client key and certificates**
-
-A client must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate issued by the public CA or your organizational CA.
-`client.<user>.crt` | Client certificate for `<user>` (e.g., `client.root.crt` for user `root`). <br><br>Each `client.<user>.crt` must have `CN=<user>`  (for example, `CN=marc` for `client.marc.crt`). <br><br>Must be signed by the CA represented by `ca.crt`.
-`client.<user>.key` | Client key corresponding to `client.<user>.crt`.
-
-Alternatively, you can use [password authentication](#client-authentication). Remember, the client still needs `ca.crt` for node authentication.
-
-### Using a public CA certificate to access the DB Console for a secure cluster
-
-One of the limitations of using `cockroach cert` or `openssl` is that the browsers used to access the DB Console do not trust the node certificates presented to them. Web browsers come preloaded with CA certificates from well-established entities (e.g., GlobalSign and DigiTrust). The CA certificate generated using the `cockroach cert` or `openssl` is not preloaded in the browser. Hence on accessing the DB Console for a secure cluster, you get the “Unsafe page” warning. Now you could add the CA certificate to the browser to avoid the warning, but that is not a recommended practice. Instead, you can use the established CAs (for example, Let’s Encrypt), to create a certificate and key to access the DB Console.
-
-Once you have the UI cert and key, add it to the Certificates directory specified by the `--certs-dir` flag in the `cockroach cert` command. The next time the browser tries to access the UI, the node will present the UI cert instead of the node cert, and you’ll not see the “unsafe site” warning anymore.
-
-**Node key and certificates**
-
-A node must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate created using the `cockroach cert` command.
-`node.crt`   | Server certificate created using the `cockroach cert` command. <br><br> `node.crt` must have `CN=node` and the list of IP addresses and DNS names listed in the `Subject Alternative Name` field. CockroachDB also supports [wildcard notation in DNS names](https://en.wikipedia.org/wiki/Wildcard_certificate). <br><br>Must be signed by the CA represented by `ca.crt`.
-`node.key`   | Server key created using the `cockroach cert` command.
-`ui.crt` | UI certificate signed by the public CA. `ui.crt` must have the IP addresses and DNS names used to reach the DB Console listed in the `Subject Alternative Name`.
-`ui.key` | UI key corresponding to `ui.crt`.
-
-**Client key and certificates**
-
-A client must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate created using the `cockroach cert` command.
-`client.<user>.crt` | Client certificate for `<user>` (e.g., `client.root.crt` for user `root`). <br><br>Each `client.<user>.crt` must have `CN=<user>`  (for example, `CN=marc` for `client.marc.crt`). <br><br> Must be signed by the CA represented by `ca.crt`.
-`client.<user>.key` | Client key created using the `cockroach cert` command.
-
-Alternatively, you can use [password authentication](#client-authentication). Remember, the client still needs `ca.crt` for node authentication.
-
-### Using split CA certificates
-
-{{site.data.alerts.callout_danger}}
-We do not recommend you use split CA certificates unless your organizational security practices mandate you to do so.
-{{site.data.alerts.end}}
-
-You might encounter situations where you need separate CAs to sign and verify node and client certificates. In that case, you would need two CAs and their respective certificates and keys: `ca.crt` and `ca-client.crt`.
-
-**Node key and certificates**
-
-A node must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate to verify node certificates.
-`ca-client.crt` | CA certificate to verify client certificates.
-`node.crt`   | Node certificate for when node acts as server. <br><br>All IP addresses and DNS names for the node must be listed in the `Subject Alternative Name`. CockroachDB also supports [wildcard notation in DNS names](https://en.wikipedia.org/wiki/Wildcard_certificate). <br><br> Must be signed by the CA represented by `ca.crt`.
-`node.key`   | Server key corresponding to `node.crt`.
-`client.node.crt` | Node certificate for when node acts as client. This certificate must be signed by the CA represented by `ca-client.crt`.  <br><br>Must have `CN=node`.
-`client.node.key` | Client key corresponding to `client.node.crt`.
-
-Optionally, if you have a certificate issued by a public CA to securely access the DB Console, you need to place the certificate and key (`ui.crt` and `ui.key` respectively) in the directory specified by the `--certs-dir` flag.
-
-**Client key and certificates**
-
-A client must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate.
-`client.<user>.crt` | Client certificate for `<user>` (e.g., `client.root.crt` for user `root`). <br><br>Each `client.<user>.crt` must have `CN=<user>` (for example, `CN=marc` for `client.marc.crt`). <br><br> Must be signed by the CA represented by `ca-client.crt`.
-`client.<user>.key` | Client key corresponding to `client.<user>.crt`.
-
-## Authentication for cloud storage
-
-See [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html).
-
-### Authentication best practices
-
-#### Certificate rotation
-
-As a security best practice, we recommend that you rotate the node, client, or CA certificates in the following scenarios:
-
-- The node, client, or CA certificates are expiring soon.
-- Your organization's compliance policy requires periodical certificate rotation.
-- The key (for a node, client, or CA) is compromised.
-- You need to modify the contents of a certificate, for example, to add another DNS name or the IP address of a load balancer through which a node can be reached. In this case, you would need to rotate only the node certificates.
-
-For details about when and how to change security certificates without restarting nodes, see [Rotate Security Certificates](rotate-certificates.html).
-
-#### Password authentication considerations
-
-In most cases, we recommend using client certificate and key authentication rather than password authentication, to ensure a higher level of security.
-
-Passwords are often embedded in connection URLs, which can inadvertently be included in log files, public scripts, and other insecure locations. It is less likely to inadvertently leak a certificate which is transmitted securely from one system to another.
-
-## Background on public key cryptography and digital certificates
-
-As mentioned above, CockroachDB supports the [TLS 1.3 and TLS 1.2](https://en.wikipedia.org/wiki/Transport_Layer_Security) security protocols, which take advantage of both symmetric (to encrypt data in flight) as well as asymmetric encryption (to establish a secure channel as well as **authenticate** the communicating parties).
-
-Authentication refers to the act of verifying the identity of the other party in communication. CockroachDB uses TLS 1.3 digital certificates for inter-node authentication, and your choice of TLS 1.2 and TLS 1.3 certificates for client-node authentication. These authentication methods require a certificate authority (CA) as well as keys and certificates for nodes, clients, and, optionally, the [DB Console](#using-a-public-ca-certificate-to-access-the-db-console-for-a-secure-cluster).
-
-To understand how CockroachDB uses digital certificates, let's first understand what each of these terms means.
-
-Consider two people: Amy and Rosa, who want to communicate securely over an insecure computer network. The traditional solution is to use symmetric encryption that involves encrypting and decrypting a plaintext message using a shared key. Amy encrypts her message using the key and sends the encrypted message across the insecure channel. Rosa decrypts the message using the same key and reads the message. This seems like a logical solution until you realize that you need a secure communication channel to send the encryption key.
-
-To solve this problem, cryptographers came up with **asymmetric encryption** to set up a secure communication channel over which an encryption key can be shared.
-
-### Asymmetric encryption
-
-Asymmetric encryption involves a pair of keys instead of a single key. The two keys are called the **public key** and the **private key**. The keys consist of very long numbers linked mathematically in a way such that a message encrypted using a public key can only be decrypted using the private key and vice versa. The message cannot be decrypted using the same key that was used to encrypt the message.
-
-So going back to our example, Amy and Rosa both have their own public-private key pairs. They keep their private keys safe with themselves and publicly distribute their public keys. Now when Amy wants to send a message to Rosa, she requests Rosa's public key, encrypts the message using Rosa’s public key, and sends the encrypted message. Rosa uses her own private key to decrypt the message.
-
-But what if a malicious imposter intercepts the communication? The imposter might pose as Rosa and send their public key instead of Rosa’s. There's no way for Amy to know that the public key she received isn’t Rosa’s, so she would end up using the imposter's public key to encrypt the message and send it to the imposter. The imposter can use their own private key and decrypt and read the message, thus compromising the secure communication channel between Amy and Rosa.
-
-To prevent this security risk, Amy needs to be sure that the public key she received was indeed Rosa’s. That’s where the certificate authority (CA) comes into the picture.
-
-### Certificate authority
-
-Certificate authorities are established entities with their own public and private key pairs. They act as a root of trust and verify the identities of the communicating parties and validate their public keys. CAs can be public and paid entities (e.g., GeoTrust and Comodo), or public and free CAs (e.g., Let’s Encrypt), or your own organizational CA (e.g., CockroachDB CA). The CAs' public keys are typically widely distributed (e.g., your browser comes preloaded with certs from popular CAs like DigiCert, GeoTrust, and so on).
-
-Think of the CA as the passport authority of a country. When you want to get your passport as your identity proof, you submit an application to your country's passport authority. The application contains important identifying information about you: your name, address, nationality, date of birth, and so on. The passport authority verifies the information they received and validates your identity. They then issue a document - the passport - that can be presented anywhere in the world to verify your identity. For example, the TSA agent at the airport does not know you and has no reason to trust you are who you say you are. However, they trust the passport authority and thus accept your identity as presented on your passport because it has been verified and issued by the passport authority.
-
-Going back to our example and assuming that we trust the CA, Rosa needs to get her public key verified by the CA. She sends a CSR (Certificate Signing Request) to the CA that contains her public key and relevant identifying information. The CA will verify that it is indeed Rosa’s public key and information, _sign_ the CSR using the CA's own private key, and generate a digital document called the **digital certificate**. In our passport analogy, this is Rosa's passport containing verified identifying information about her and trusted by everyone who trusts the CA. The next time Rosa wants to establish her identity, she will present her digital certificate.
-
-### Digital certificate
-
-A public key is shared using a digital certificate signed by a CA using the CA's private key. The digital certificate contains:
-
--   The certificate owner’s public key    
--   Information about the certificate owner
--   The CA's digital signature
-
-### Digital signature
-
-The CA's digital signature works as follows: The certificate contents are put through a mathematical function to create a **hash value**. This hash value is encrypted using the CA's private key to generate the **digital signature**. The digital signature is added to the digital certificate. In our example, the CA adds their digital signature to Rosa's certificate validating her identity and her public key.
-
-As discussed [earlier](#certificate-authority), the CA's public key is widely distributed. In our example, Amy already has the CA's public key. Now when Rosa presents her digital certificate containing her public key, Amy uses the CA's public key to decrypt the digital signature on Rosa's certificate and gets the hash value encoded in the digital signature. Amy also generates the hash value for the certificate on her own. If the hash values match, then Amy can be sure that the certificate and hence the public key it contains indeed belongs to Rosa; otherwise, she can determine that the communication channel has been compromised and refuse further contact.
-
-### How it all works together
-
-Let's see how the digital certificate is used in client-server communication: The client (e.g., a web browser) has the CA certificate (containing the CA's public key). When the client receives a server's certificate signed by the same CA, it can use the CA certificate to verify the server's certificate, thus validating the server's identity, and securely connect to the server. The important thing here is that the client needs to have the CA certificate. If you use your own organizational CA instead of a publicly established CA, you need to make sure you distribute the CA certificate to all the clients.
-
-## See also
-
-- [Client Connection Parameters](connection-parameters.html)
-- [Manual Deployment](manual-deployment.html)
-- [Orchestrated Deployment](orchestration.html)
-- [Local Deployment](secure-a-cluster.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/authorization.md b/src/current/v20.2/authorization.md
deleted file mode 100644
index 88d3611427a..00000000000
--- a/src/current/v20.2/authorization.md
+++ /dev/null
@@ -1,534 +0,0 @@
----
-title: Authorization
-summary: Learn about the authorization features for secure CockroachDB clusters.
-toc: true
----
-
-You can map SQL [roles](#roles) to SQL [privileges](#assign-privileges) and use role membership to group [users](#users-and-roles) that share privileges.
-
-## Users and roles
-
-There is no technical distinction between a SQL role or user in CockroachDB. Depending on its configuration, a role can:
-
-- log in via the [SQL shell](cockroach-sql.html).
-- be used by applications to connect to the database.
-- be granted [privileges](#privileges) to specific actions and database objects.
-- be a member of other roles, inheriting their privileges.
-- have other roles as members that inherit its privileges.
-
-We often refer to these as "roles" when they are created for managing the privileges of their member "users". We often refer to roles that are enabled to log in to a database as "users".
-
-The SQL statements [`CREATE USER`](create-user.html) and [`CREATE ROLE`](create-role.html) will create the same entity with one exception: `CREATE ROLE` will add the [`NOLOGIN`](create-role.html#parameters) option by default, preventing the role from being used to log in. Otherwise, for enhanced PostgreSQL compatibility, the keywords `ROLE` and `USER` can be used interchangeably in SQL statements.
-
-Throughout the documentation, however, we refer to a "user" or "role" based on the intended purpose of the entity, and we default to using the term "role" when we want to include both possibilities for how the role may be used.
-
-## Users
-
-A SQL user (a role with `LOGIN` privileges) can interact with a CockroachDB database using the [built-in SQL shell](cockroach-sql.html) or through an application.
-
-### Create and manage users
-
-You can use the [`CREATE USER`](create-user.html) and [`DROP USER`](drop-user.html) statements to create and remove users, the [`ALTER USER`](alter-user.html) statement to add or change a user's password and role options, and the [`SHOW USERS`](show-users.html) statement to list users.
-
-The statements [`CREATE ROLE`](create-role.html), [`DROP ROLE`](drop-role.html), [`ALTER ROLE`](alter-role.html), and [`SHOW ROLES`](show-roles.html) are equivalent to these, respectively, with the exception of the default `NOLOGIN` setting added with `CREATE ROLE`.
-
-Use the [`GRANT <privileges>`](grant.html) and [`REVOKE <privileges>`](revoke.html) statements to manage the user’s privileges.
-
-For each database and table that the user needs to access, a user must be granted the required privileges or granted membership to roles that confer these privileges.
-
-By default, a new user belongs to the `public` role and has no privileges other than those assigned to the `public` role. For more information, see [Public role](#public-role).
-
-### `root` user
-
-The `root` user is created by default for each cluster. The `root` user is assigned to the [`admin` role](#admin-role) and has all privileges across the cluster.
-
-For secure clusters, in addition to [generating the client certificate](authentication.html#client-authentication) for the `root` user, you can assign or change the password for the `root` user using the [`ALTER USER`](alter-user.html) statement.
-
-## Roles
-
-A role is a group of users and/or other roles for which you can grant or revoke privileges as a whole. To simplify access management, create a role and grant privileges to the role, then create SQL users and grant them membership to the role.
-
-Users and roles and technically the same type of entity. See [Users and roles](#users-and-roles).
-
-### Create and manage roles
-
-To create and manage your cluster's roles, use the following statements:
-
-Statement | Description
-----------|------------
-[`CREATE ROLE`](create-role.html) | Create SQL roles.
-[`DROP ROLE`](drop-role.html) | Remove one or more SQL roles.
-[`GRANT <roles>`](grant-roles.html) | Add a role or user as a member to a role.
-[`REVOKE <roles>`](revoke-roles.html) | Revoke a role or user's membership to a role.
-[`GRANT <privileges>`](grant.html) | Manage each role or user's SQL privileges for interacting with specific databases and tables.
-[`REVOKE <privileges>`](revoke.html) | Revoke privileges from users and/or roles.
-[`SHOW ROLES`](show-roles.html) | List the roles for all databases.
-[`SHOW GRANTS`](show-grants.html) | List the privileges granted to users.
-
-### Default roles
-
-The `admin` and `public` roles exist by default.
-
-#### `admin` role
-
-The `admin` role is created by default and cannot be dropped. Users belonging to the `admin` role have all privileges for all database objects across the cluster. The `root` user belongs to the `admin` role by default.
-
-An `admin` user is a member of the `admin` role. Only `admin` users can use [`CREATE ROLE`](create-role.html) and [`DROP ROLE`](drop-role.html).
-
-To assign a user to the `admin` role:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT admin TO <username>;
-~~~
-
-#### `public` role
-
-All new users and roles belong to the `public` role by default. You can grant and revoke privileges on the `public` role.
-
-### Terminology
-
-#### Role admin
-
-A `role admin` is a member of the role that's allowed to grant or revoke role membership to other users for that specific role. To create a `role admin`, use [`WITH ADMIN OPTION`](grant-roles.html#grant-the-admin-option).
-
-{{site.data.alerts.callout_success}}
-The terms “`admin` role” and “`role admin`” can be confusing. A user who is a member of the `admin` role has all privileges on all database objects across the entire cluster, whereas a `role admin` has privileges limited to the role they are a member of. Assign the `admin` role to a SQL user if you want the user to have privileges across the cluster. Make a SQL user the `role admin` if you want to limit the user’s privileges to its current role, but with an option to grant or revoke role membership to other users. This applies to the `admin` role as well - only admin users with the `WITH ADMIN OPTION` can add or remove other users from the `admin` role.
-{{site.data.alerts.end}}
-
-#### Direct member
-
-A user or role that is an immediate member of the role.
-
-Example: A is a member of B.
-
-#### Indirect member
-
-A user or role that is a member of the role by association.
-
-Example: A is a member of C ... is a member of B where "..." is an arbitrary number of memberships.
-
-## Object ownership
-
-<span class="version-tag">New in v20.2</span> All CockroachDB objects (such as databases, tables, schemas, and types) must have owners. The user that created the object is the default owner of the object and has `ALL` privileges on the object. Similarly, any roles that are members of the owner role also have all privileges on the object.
-
-All objects that do not have owners (for example, objects created before upgrading to v20.2) have `admin` set as the default owner, with the exception of system objects. System objects without owners have `node` as their owner.
-
-To allow another user to use the object, the owner can [assign privileges](#assign-privileges) to the other user. Members of the `admin` role have `ALL` privileges on all objects.
-
-Users that [own objects](authorization.html#privileges) cannot be dropped until the [ownership is transferred to another user](owner-to.html#change-a-databases-owner).
-
-## Privileges
-
-When a user connects to a database, either via the built-in SQL client or a client driver, CockroachDB checks the user and role's privileges for each statement executed. If the user does not have sufficient privileges for a statement, CockroachDB gives an error.
-
-### Supported privileges
-
-Roles and users can be granted the following privileges:
-
-{% include {{ page.version.version }}/sql/privileges.md %}
-
-### Assign privileges
-
-Use the [`GRANT <privileges>`](grant.html) and [`REVOKE <privileges>`](revoke.html) statements to manage privileges for users and roles.
-
-Take the following points into consideration while granting privileges to roles and users:
-
-- When a role or user is granted privileges for a database, new tables created in the database will inherit the privileges, but the privileges can then be changed. To grant privileges to a user on all existing tables in a database, see [Grant privileges on all tables in a database](grant.html#grant-privileges-on-all-tables-in-a-database-or-schema)
-
-    {{site.data.alerts.callout_info}}
-    The user does not get privileges to existing tables in the database.
-    {{site.data.alerts.end}}
-
-- When a role or user is granted privileges for a table, the privileges are limited to the table.
-- In CockroachDB, privileges are granted to users and roles at the database and table levels. They are not yet supported for other granularities such as columns or rows.
-- The `root` user automatically belongs to the `admin` role and has the `ALL` privilege for new databases.
-- For privileges required by specific statements, see the documentation for the respective [SQL statement](sql-statements.html).
-
-## Authorization best practices
-
-We recommend the following best practices to set up access control for your clusters:
-
-- Use the `root` user only for database administration tasks such as creating and managing other [users](#users), creating and managing [roles](#roles), and creating and managing databases. Do not use the `root` user for applications; instead, create users or roles with specific [privileges](#assign-privileges) based on your application’s access requirements.
-- Use the ["least privilege model"](https://en.wikipedia.org/wiki/Principle_of_least_privilege) to grant privileges to users and roles.
-
-## Example
-
-<div class="filters clearfix">
-  <button style="width: 30%" class="filter-button" data-scope="users">Users-based Privileges</button>
-  <button style="width: 30%" class="filter-button" data-scope="rbac">Roles-based Privileges</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="users">
-
-The following example uses MovR, a fictional vehicle-sharing application, to demonstrate CockroachDB [SQL statements](sql-statements.html). For more information about the MovR example application and dataset, see [MovR: A Global Vehicle-sharing App](movr.html).
-
-Let's say we want to create the following access control setup for the `movr` database:
-
-- One database admin (named `db_admin`) who can perform all database operations for existing tables as well as for tables added in the future.
-- One app user (named `app_user`) who can add, read update, and delete vehicles from the `vehicles` table.
-- One user (named `report_user`) who can only read the `vehicles` table.
-
-1. Use the [`cockroach demo`](cockroach-demo.html) command to load the `movr` database and dataset into a CockroachDB cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach demo
-    ~~~
-
-2. Create the database admin (named `db_admin`) who can perform all database operations for existing tables as well as for  tables added in the future:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER db_admin;
-    ~~~
-
-3. Grant all privileges on database `movr` to user `db_admin`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT ALL ON DATABASE movr TO db_admin;
-    ~~~
-
-4. Grant all privileges on all tables in database `movr` to user `db_admin`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT ALL ON TABLE * TO db_admin;
-    ~~~
-
-5. Verify that `db_admin` has all privileges:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW GRANTS FOR db_admin;
-    ~~~
-
-    ~~~
-      database_name |    schema_name     |         table_name         | grantee  | privilege_type  
-    +---------------+--------------------+----------------------------+----------+----------------+
-      movr          | crdb_internal      | NULL                       | db_admin | ALL             
-      movr          | information_schema | NULL                       | db_admin | ALL             
-      movr          | pg_catalog         | NULL                       | db_admin | ALL             
-      movr          | public             | NULL                       | db_admin | ALL             
-      movr          | public             | promo_codes                | db_admin | ALL             
-      movr          | public             | rides                      | db_admin | ALL             
-      movr          | public             | user_promo_codes           | db_admin | ALL             
-      movr          | public             | users                      | db_admin | ALL             
-      movr          | public             | vehicle_location_histories | db_admin | ALL             
-      movr          | public             | vehicles                   | db_admin | ALL             
-    (10 rows)
-    ~~~
-
-6. As the `root` user, create a SQL user named `app_user` with permissions to add, read, update, and delete vehicles in the `vehicles` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER app_user;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT INSERT, DELETE, UPDATE, SELECT ON vehicles TO app_user;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW GRANTS FOR app_user;
-    ~~~
-
-    ~~~
-      database_name | schema_name | table_name | grantee  | privilege_type  
-    +---------------+-------------+------------+----------+----------------+
-      movr          | public      | vehicles   | app_user | DELETE          
-      movr          | public      | vehicles   | app_user | INSERT          
-      movr          | public      | vehicles   | app_user | SELECT          
-      movr          | public      | vehicles   | app_user | UPDATE          
-    (4 rows)
-    ~~~
-
-7. As the `root` user, create a SQL user named `report_user` with permissions to only read from the `vehicles` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER report_user;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT SELECT ON vehicles TO report_user;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW GRANTS FOR report_user;
-    ~~~
-
-    ~~~
-      database_name | schema_name | table_name |   grantee   | privilege_type  
-    +---------------+-------------+------------+-------------+----------------+
-      movr          | public      | vehicles   | report_user | SELECT          
-    (1 row)
-    ~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="rbac">
-
-The following example uses MovR, a fictional vehicle-sharing application, to demonstrate CockroachDB SQL statements. For more information about the MovR example application and dataset, see [MovR: A Global Vehicle-sharing App](movr.html).
-
-Let's say we want to create the following access control setup for the `movr` database:
-
-- Two database admins (named `db_admin_1` and `db_admin_2`) who can perform all database operations for existing tables as well as for tables added in the future.
-- Three app users (named `app_user_1`, `app_user_2`, and `app_user_3`) who can add, read update, and delete vehicles from the `vehicles` table.
-- Five users (named `report_user_1`, `report_user_2`, `report_user_3`, `report_user_4`, `report_user_5`) who can only read the `vehicles` table.
-
-1. Use the [`cockroach demo`](cockroach-demo.html) command to load the `movr` database and dataset into a CockroachDB cluster.:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach demo
-    ~~~
-
-2. Create the database admin role (named `db_admin_role`) whose members can perform all database operations for existing tables as well as for tables added in the future:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE ROLE db_admin_role;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ROLES;
-    ~~~
-
-    ~~~
-        username    |  options   | member_of
-    ----------------+------------+------------
-      admin         | CREATEROLE | {}
-      db_admin_role | NOLOGIN    | {}
-      root          | CREATEROLE | {admin}
-    (3 rows)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT ALL ON DATABASE movr TO db_admin_role;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT ALL ON TABLE * TO db_admin_role;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW GRANTS ON DATABASE movr;
-    ~~~
-
-    ~~~
-      database_name |    schema_name     |    grantee    | privilege_type
-    ----------------+--------------------+---------------+-----------------
-      movr          | crdb_internal      | admin         | ALL
-      movr          | crdb_internal      | db_admin_role | ALL
-      movr          | crdb_internal      | root          | ALL
-      movr          | information_schema | admin         | ALL
-      movr          | information_schema | db_admin_role | ALL
-      movr          | information_schema | root          | ALL
-      movr          | pg_catalog         | admin         | ALL
-      movr          | pg_catalog         | db_admin_role | ALL
-      movr          | pg_catalog         | root          | ALL
-      movr          | public             | admin         | ALL
-      movr          | public             | db_admin_role | ALL
-      movr          | public             | root          | ALL
-    (12 rows)
-    ~~~
-
-3. Create two database admin users (named `db_admin_1` and `db_admin_2`) and grant them membership to the `db_admin_role` role:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER db_admin_1;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER db_admin_2;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT db_admin_role TO db_admin_1, db_admin_2;
-    ~~~
-
-4. Create a role named `app_user_role` whose members can add, read update, and delete vehicles to the `vehicles` table.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE ROLE app_user_role;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ROLES;
-    ~~~
-
-    ~~~
-        username    |  options   |    member_of
-    ----------------+------------+------------------
-      admin         | CREATEROLE | {}
-      app_user_role | NOLOGIN    | {}
-      db_admin_1    |            | {db_admin_role}
-      db_admin_2    |            | {db_admin_role}
-      db_admin_role | NOLOGIN    | {}
-      root          | CREATEROLE | {admin}
-    (6 rows)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT INSERT, UPDATE, DELETE, SELECT ON TABLE vehicles TO app_user_role;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW GRANTS ON vehicles;
-    ~~~
-
-    ~~~
-      database_name | schema_name | table_name |    grantee    | privilege_type
-    ----------------+-------------+------------+---------------+-----------------
-      movr          | public      | vehicles   | admin         | ALL
-      movr          | public      | vehicles   | app_user_role | DELETE
-      movr          | public      | vehicles   | app_user_role | INSERT
-      movr          | public      | vehicles   | app_user_role | SELECT
-      movr          | public      | vehicles   | app_user_role | UPDATE
-      movr          | public      | vehicles   | db_admin_role | ALL
-      movr          | public      | vehicles   | root          | ALL
-    (7 rows)
-    ~~~
-
-5. Create three app users (named `app_user_1`, `app_user_2`, and `app_user_3`) and grant them membership to the `app_user_role` role:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER app_user_1;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER app_user_2;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER app_user_3;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT app_user_role TO app_user_1, app_user_2, app_user_3;
-    ~~~
-
-6. Create a role named `report_user_role` whose members can only read the `vehicles` table.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE ROLE report_user_role;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ROLES;
-    ~~~
-
-    ~~~
-          username     |  options   |    member_of
-    -------------------+------------+------------------
-      admin            | CREATEROLE | {}
-      app_user_1       |            | {app_user_role}
-      app_user_2       |            | {app_user_role}
-      app_user_3       |            | {app_user_role}
-      app_user_role    | NOLOGIN    | {}
-      db_admin_1       |            | {db_admin_role}
-      db_admin_2       |            | {db_admin_role}
-      db_admin_role    | NOLOGIN    | {}
-      report_user_role | NOLOGIN    | {}
-      root             | CREATEROLE | {admin}
-    (10 rows)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT SELECT ON vehicles TO report_user_role;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW GRANTS ON vehicles;
-    ~~~
-
-    ~~~
-      database_name | schema_name | table_name |     grantee      | privilege_type
-    ----------------+-------------+------------+------------------+-----------------
-      movr          | public      | vehicles   | admin            | ALL
-      movr          | public      | vehicles   | app_user_role    | DELETE
-      movr          | public      | vehicles   | app_user_role    | INSERT
-      movr          | public      | vehicles   | app_user_role    | SELECT
-      movr          | public      | vehicles   | app_user_role    | UPDATE
-      movr          | public      | vehicles   | db_admin_role    | ALL
-      movr          | public      | vehicles   | report_user_role | SELECT
-      movr          | public      | vehicles   | root             | ALL
-    (8 rows)
-    ~~~
-
-7. Create five report users (named `report_user_1`, `report_user_2`, `report_user_3`, `report_user_4`, and `report_user_5`) and grant them membership to the `report_user_role` role:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER report_user_1;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER report_user_2;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER report_user_3;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER report_user_4;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER report_user_5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT report_user_role TO report_user_1, report_user_2, report_user_3, report_user_4, report_user_5;
-    ~~~
-
-</section>
-
-## See also
-
-- [Client Connection Parameters](connection-parameters.html)
-- [SQL Statements](sql-statements.html)
-- [`CREATE USER`](create-user.html)
-- [`ALTER USER`](alter-user.html)
-- [`DROP USER`](drop-user.html)
-- [`SHOW USERS`](show-users.html)
-- [`CREATE ROLE`](create-role.html)
-- [`DROP ROLE`](drop-role.html)
-- [`SHOW ROLES`](show-roles.html)
-- [`GRANT <privileges>`](grant.html)
-- [`GRANT <roles>`](grant-roles.html)
-- [`REVOKE <privileges>`](revoke.html)
-- [`REVOKE <roles>`](revoke-roles.html)
-- [`SHOW GRANTS`](show-grants.html)
diff --git a/src/current/v20.2/backup.md b/src/current/v20.2/backup.md
deleted file mode 100644
index db35eb004ab..00000000000
--- a/src/current/v20.2/backup.md
+++ /dev/null
@@ -1,273 +0,0 @@
----
-title: BACKUP
-summary: Back up your CockroachDB cluster to a cloud storage services such as AWS S3, Google Cloud Storage, or other NFS.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-Core users can only take [full backups](take-full-and-incremental-backups.html#full-backups). To use the other backup features, you need an [Enterprise license](enterprise-licensing.html).
-{{site.data.alerts.end}}
-
-CockroachDB's `BACKUP` [statement](sql-statements.html) allows you to create [full or incremental backups](take-full-and-incremental-backups.html) of your cluster's schema and data that are consistent as of a given timestamp.
-
-You can [backup a full cluster](#backup-a-cluster), which includes:
-
-- Relevant system tables
-- All [databases](create-database.html)
-- All [tables](create-table.html) (which automatically includes their [indexes](indexes.html))
-- All [views](views.html)
-- <span class="version-tag">New in v20.2:</span> All [scheduled jobs](manage-a-backup-schedule.html#view-and-control-a-backup-initiated-by-a-schedule)
-
-You can also back up:
-
-- [An individual database](#backup-a-database), which includes all of its tables and views
-- [An individual table](#backup-a-table-or-view), which includes its indexes and views
-
-Because CockroachDB is designed with high fault tolerance, these backups are designed primarily for disaster recovery (i.e., if your cluster loses a majority of its nodes) through [`RESTORE`](restore.html). Isolated issues (such as small-scale node outages) do not require any intervention.
-
-{{site.data.alerts.callout_info}}
-`BACKUP` only backs up entire tables; it _does not_ support backing up subsets of a table.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-`BACKUP` is a blocking statement. To run a backup job asynchronously, use the `DETACHED` option. See the [options](#options) below.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-To view the contents of an Enterprise backup created with the `BACKUP` statement, use [`SHOW BACKUP`](show-backup.html).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-- [Full cluster backups](take-full-and-incremental-backups.html#full-backups) can only be run by members of the [`admin` role](authorization.html#admin-role). By default, the `root` user belongs to the `admin` role.
-- For all other backups, the user must have [read access](authorization.html#assign-privileges) on all objects being backed up. Database and table backups require `SELECT` privileges. Backups of user-defined schemas, or backups containing user-defined types, require `USAGE` privileges.
-- `BACKUP` requires full read and write (including delete and overwrite) permissions to its target destination.
-
-### Destination privileges
-
-{% include {{ page.version.version }}/backups/destination-file-privileges.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/backup.html %}
-</div>
-
-## Parameters
-
- Parameter | Description
-------------|-------------
-`table_pattern` | The table(s) or [view(s)](views.html) you want to back up.
-`database_name` | The name of the database(s) you want to back up (i.e., create backups of all tables and views in the database).|
-`destination` | The URL where you want to store the backup.<br/><br/>For information about this URL structure, see [Backup File URLs](#backup-file-urls).
-`timestamp` | Back up data as it existed as of [`timestamp`](as-of-system-time.html). The `timestamp` must be more recent than your cluster's last garbage collection (which defaults to occur every 25 hours, but is [configurable per table](configure-replication-zones.html#replication-zone-variables)).
-`full_backup_location` | Create an incremental backup using the backup stored at the URL `full_backup_location` as its base. For information about this URL structure, see [Backup File URLs](#backup-file-urls).<br><br>**Note:** After a full backup for an explicit list of tables and/or databases, it is not possible to create an incremental backup if one or more tables were [created](create-table.html), [dropped](drop-table.html), or [truncated](truncate.html). In these cases, you must create a new [full backup](#full-backups) before more incremental backups can be created. To avoid this, [backup the cluster](#backup-a-cluster) instead of the explicit list of tables/databases.
-`incremental_backup_location` | Create an incremental backup that includes all backups listed at the provided URLs. <br/><br/>Lists of incremental backups must be sorted from oldest to newest. The newest incremental backup's timestamp must be within the table's garbage collection period. <br/><br/>For information about this URL structure, see [Backup File URLs](#backup-file-urls). <br/><br/>For more information about garbage collection, see [Configure Replication Zones](configure-replication-zones.html#replication-zone-variables).
-`kv_option_list` | Control the backup behavior with a comma-separated list of [these options](#options).
-
-### Options
-
-{% include {{ page.version.version }}/backups/backup-options.md %}
-
-### Backup file URLs
-
-CockroachDB uses the URL provided to construct a secure API call to the service you specify. The URL structure depends on the type of file storage you are using. For more information, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-## Functional details
-
-### Object dependencies
-
-Dependent objects must be backed up at the same time as the objects they depend on.
-
-Object | Depends On
--------|-----------
-Table with [foreign key](foreign-key.html) constraints | The table it `REFERENCES`; however, this dependency can be [removed during the restore](restore.html#skip_missing_foreign_keys).
-Table with a [sequence](create-sequence.html) | The sequence it uses; however, this dependency can be [removed during the restore](restore.html#skip_missing_sequences).
-[Views](views.html) | The tables used in the view's `SELECT` statement.
-[Interleaved tables](interleave-in-parent.html) | The parent table in the [interleaved hierarchy](interleave-in-parent.html#interleaved-hierarchy).
-
-### Users and privileges
-
-The `system.users` table stores your users and their passwords. To restore your users and privilege [grants](grant.html), do a cluster backup and restore the cluster to a fresh cluster with no user data. You can also backup the `system.users` table, and then use [this procedure](restore.html#restoring-users-from-system-users-backup).
-
-### Backup types
-
-CockroachDB offers two types of backups: [full](#full-backups) and [incremental](#incremental-backups).
-
-#### Full backups
-
-Full backups contain an un-replicated copy of your data and can always be used to restore your cluster. These files are roughly the size of your data and require greater resources to produce than incremental backups. You can take full backups as of a given timestamp and (optionally) include the available [revision history](take-backups-with-revision-history-and-restore-from-a-point-in-time.html).
-
-#### Incremental backups
-
-Incremental backups are smaller and faster to produce than full backups because they contain only the data that has changed since a base set of backups you specify (which must include one full backup, and can include many incremental backups). You can take incremental backups either as of a given timestamp or with full [revision history](take-backups-with-revision-history-and-restore-from-a-point-in-time.html).
-
-{{site.data.alerts.callout_danger}}
-Incremental backups can only be created within the garbage collection period of the base backup's most recent timestamp. This is because incremental backups are created by finding which data has been created or modified since the most recent timestamp in the base backup––that timestamp data, though, is deleted by the garbage collection process. Incremental backups that fail because of a recent garbage collection will throw [an error](common-errors.html#pq-failed-to-verify-protection-id).
-
-You can configure garbage collection periods using the `ttlseconds` [replication zone setting](configure-replication-zones.html).
-{{site.data.alerts.end}}
-
-For an example of an incremental backup, see the [Create incremental backups](#create-incremental-backups) example below.
-
-## Performance
-
-The `BACKUP` process minimizes its impact to the cluster's performance by distributing work to all nodes. Each node backs up only a specific subset of the data it stores (those for which it serves writes; more details about this architectural concept forthcoming), with no two nodes backing up the same data.
-
-`BACKUP`, like any read, cannot export a range if the range contains an [unresolved intent](architecture/transaction-layer.html#resolving-write-intents). While you typically will want bulk, background jobs like `BACKUP` to have as little impact on your foreground traffic as possible, it's more important for backups to actually complete (which maintains your [recovery point objective (RPO)](https://en.wikipedia.org/wiki/Disaster_recovery#Recovery_Point_Objective)). Unlike a normal read transaction that will block until any uncommitted writes it encounters are resolved, `BACKUP` will block only for a configurable duration before invoking priority to ensure it can complete on-time.
-
-We recommend always starting backups with a specific [timestamp](timestamp.html) at least 10 seconds in the past. For example:
-
-~~~ sql
-> BACKUP...AS OF SYSTEM TIME '-10s';
-~~~
-
-This improves performance by decreasing the likelihood that the `BACKUP` will be [retried because it contends with other statements/transactions](transactions.html#transaction-retries). However, because `AS OF SYSTEM TIME` returns historical data, your reads might be stale. Taking backups with `AS OF SYSTEM TIME '-10s'` is a good best practice to reduce the number of still-running transactions you may encounter, since the backup will take priority and will force still-running transactions to restart after the backup is finished.
-
-<span class="version-tag">New in v20.2:</span> `BACKUP` will initially ask individual ranges to backup but to skip if they encounter an intent. Any range that is skipped is placed at the end of the queue. When `BACKUP` has completed its initial pass and is revisiting ranges, it will ask any range that did not resolve within the given time limit (default 1 minute) to attempt to resolve any intents that it encounters and to _not_ skip. Additionally, the backup's transaction priority is then set to `high`, which causes other transactions to abort until the intents are resolved and the backup is finished.
-
-## Viewing and controlling backups jobs
-
-After CockroachDB successfully initiates a backup, it registers the backup as a job, and you can do the following:
-
- Action                | SQL Statement
------------------------+-----------------
-View the backup status | [`SHOW JOBS`](show-jobs.html)
-Pause the backup       | [`PAUSE JOB`](pause-job.html)
-Resume the backup      | [`RESUME JOB`](resume-job.html)
-Cancel the backup      | [`CANCEL JOB`](cancel-job.html)
-
-You can also visit the [**Jobs** page](ui-jobs-page.html) of the DB Console to view job details. The `BACKUP` statement will return when the backup is finished or if it encounters an error.
-
-{{site.data.alerts.callout_info}}
-The presence of a `BACKUP-CHECKPOINT` file in the backup destination usually means the backup is not complete. This file is created when a backup is initiated, and is replaced with a `BACKUP` file once the backup is finished.
-{{site.data.alerts.end}}
-
-## Examples
-
-Per our guidance in the [Performance](#performance) section, we recommend starting backups from a time at least 10 seconds in the past using [`AS OF SYSTEM TIME`](as-of-system-time.html). Each example below follows this guidance.
-
-### Backup a cluster
-
- To backup a full cluster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO \
-'gs://acme-co-backup/test-cluster' \
-AS OF SYSTEM TIME '-10s';
-~~~
-
-### Backup a database
-
-To backup a single database:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP DATABASE bank \
-TO 'gs://acme-co-backup/database-bank-2017-03-27-weekly' \
-AS OF SYSTEM TIME '-10s';
-~~~
-
-To backup multiple databases:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP DATABASE bank, employees \
-TO 'gs://acme-co-backup/database-bank-2017-03-27-weekly' \
-AS OF SYSTEM TIME '-10s';
-~~~
-
-### Backup a table or view
-
-To backup a single table or view:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP bank.customers \
-TO 'gs://acme-co-backup/bank-customers-2017-03-27-weekly' \
-AS OF SYSTEM TIME '-10s';
-~~~
-
-To backup multiple tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP bank.customers, bank.accounts \
-TO 'gs://acme-co-backup/database-bank-2017-03-27-weekly' \
-AS OF SYSTEM TIME '-10s';
-~~~
-
-### Create incremental backups
-
-If you backup to a destination already containing a full backup, an incremental backup will be produced in a subdirectory with a date-based name (e.g., `destination/day/time_1`, `destination/day/time_2`):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO \
-'gs://acme-co-backup/test-cluster' \
-AS OF SYSTEM TIME '-10s';
-~~~
-
-{{site.data.alerts.callout_info}}
-This incremental backup syntax does not work for backups using HTTP storage; you must [explicitly control where your incremental backups go](take-full-and-incremental-backups.html#incremental-backups-with-explicitly-specified-destinations) by using the [`INCREMENTAL FROM` syntax](#synopsis).
-{{site.data.alerts.end}}
-
-### Run a backup asynchronously
-
-<span class="version-tag">New in v20.2:</span> Use the `DETACHED` [option](#options) to execute the backup job asynchronously:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO \
-'gs://acme-co-backup/test-cluster' \
-AS OF SYSTEM TIME '-10s'
-WITH DETACHED;
-~~~
-
-The job ID is returned after the backup job creation completes: 
-
-~~~
-        job_id
-----------------------
-  592786066399264769
-(1 row)
-~~~
-
-**Without** the `DETACHED` option, `BACKUP` will block the SQL connection until the job completes. Once finished, the job status and more detailed job data is returned:
-
-~~~
-job_id             |  status   | fraction_completed | rows | index_entries | bytes
----------------------+-----------+--------------------+------+---------------+--------
-652471804772712449 | succeeded |                  1 |   50 |             0 |  4911
-(1 row)
-~~~
-
-### Advanced examples
-
-{% include {{ page.version.version }}/backups/advanced-examples-list.md %}
-
-## Known limitations
-
-### Slow (or hung) backups and queries due to write intent buildup
-
-{% include {{ page.version.version }}/known-limitations/write-intent-buildup.md %}
-
-## See also
-
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Take and Restore Encrypted Backups](take-and-restore-encrypted-backups.html)
-- [Take and Restore Locality-aware Backups](take-and-restore-locality-aware-backups.html)
-- [Take Backups with Revision History and Restore from a Point-in-time](take-backups-with-revision-history-and-restore-from-a-point-in-time.html)
-- [`SHOW BACKUP`](show-backup.html)
-- [`CREATE SCHEDULE FOR BACKUP`](create-schedule-for-backup.html)
-- [`RESTORE`](restore.html)
-- [Configure Replication Zones](configure-replication-zones.html)
-
-<!-- Reference links -->
-
-[backup]:  backup.html
-[restore]: restore.html
diff --git a/src/current/v20.2/begin-transaction.md b/src/current/v20.2/begin-transaction.md
deleted file mode 100644
index b19616369f2..00000000000
--- a/src/current/v20.2/begin-transaction.md
+++ /dev/null
@@ -1,171 +0,0 @@
----
-title: BEGIN
-summary: Initiate a SQL transaction with the BEGIN statement in CockroachDB.
-toc: true
----
-
-The `BEGIN` [statement](sql-statements.html) initiates a [transaction](transactions.html), which either successfully executes all of the statements it contains or none at all.
-
-{{site.data.alerts.callout_danger}}
-When using transactions, your application should include logic to [retry transactions](transactions.html#transaction-retries) that are aborted to break a dependency cycle between concurrent transactions.
-{{site.data.alerts.end}}
-
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/begin_transaction.html %}
-</div>
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to initiate a transaction. However, privileges are required for each statement within a transaction.
-
-## Aliases
-
-In CockroachDB, the following are aliases for the `BEGIN` statement:
-
-- `BEGIN TRANSACTION`
-- `START TRANSACTION`
-
-## Parameters
-
- Parameter | Description
------------|-------------
-`PRIORITY` | If you do not want the transaction to run with `NORMAL` priority, you can set it to `LOW` or `HIGH`.<br/><br/>Transactions with higher priority are less likely to need to be retried.<br/><br/>For more information, see [Transactions: Priorities](transactions.html#transaction-priorities).<br/><br/>**Default**: `NORMAL`
-`READ` | Set the transaction access mode to `READ ONLY` or `READ WRITE`. The current transaction access mode is also exposed as the [session variable](show-vars.html) `transaction_read_only`.<br><br>**Default**: `READ WRITE`
-`AS OF SYSTEM TIME` | Execute the transaction using the database contents "as of" a specified time in the past.<br/><br/> The `AS OF SYSTEM TIME` clause can be used only when the transaction is read-only. If the transaction contains any writes, or if the `READ WRITE` mode is specified, an error will be returned.<br/><br/>For more information, see [AS OF SYSTEM TIME](as-of-system-time.html).
-`NOT DEFERRABLE`<br>`DEFERRABLE` | <span class="version-tag">New in v20.2:</span> This clause is supported for compatibility with PostgreSQL. `NOT DEFERRABLE` is a no-op and the default behavior for CockroachDB. `DEFERRABLE` returns an `unimplemented` error.
-
- CockroachDB now only supports `SERIALIZABLE` isolation, so transactions can no longer be meaningfully set to any other `ISOLATION LEVEL`. In previous versions of CockroachDB, you could set transactions to `SNAPSHOT` isolation, but that feature has been removed.
-
-## Examples
-
-### Begin a transaction
-
-#### Use default settings
-
-Without modifying the `BEGIN` statement, the transaction uses `SERIALIZABLE` isolation and `NORMAL` priority.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SAVEPOINT cockroach_restart;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE products SET inventory = 0 WHERE sku = '8675309';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders (customer, sku, status) VALUES (1001, '8675309', 'new');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RELEASE SAVEPOINT cockroach_restart;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMIT;
-~~~
-
-{{site.data.alerts.callout_danger}}This example assumes you're using <a href="transactions.html#client-side-intervention">client-side intervention to handle transaction retries</a>.{{site.data.alerts.end}}
-
-#### Change priority
-
-You can set a transaction's priority to `LOW` or `HIGH`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN PRIORITY HIGH;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SAVEPOINT cockroach_restart;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE products SET inventory = 0 WHERE sku = '8675309';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders (customer, sku, status) VALUES (1001, '8675309', 'new');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RELEASE SAVEPOINT cockroach_restart;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMIT;
-~~~
-
-You can also set a transaction's priority with [`SET TRANSACTION`](set-transaction.html).
-
-{{site.data.alerts.callout_danger}}
-This example assumes you're using [client-side intervention to handle transaction retries](transactions.html#client-side-intervention).
-{{site.data.alerts.end}}
-
-### Use the `AS OF SYSTEM TIME` option
-
-You can execute the transaction using the database contents "as of" a specified time in the past.
-
-{% include {{ page.version.version }}/sql/begin-transaction-as-of-system-time-example.md %}
-
-{{site.data.alerts.callout_success}}
-You can also use the [`SET TRANSACTION`](set-transaction.html#use-the-as-of-system-time-option) statement inside the transaction to achieve the same results. This syntax is easier to use from [drivers and ORMs](install-client-drivers.html).
-{{site.data.alerts.end}}
-
-### Begin a transaction with automatic retries
-
-CockroachDB will [automatically retry](transactions.html#transaction-retries) all transactions that contain both `BEGIN` and `COMMIT` in the same batch. Batching is controlled by your driver or client's behavior, but means that CockroachDB receives all of the statements as a single unit, instead of a number of requests.
-
-From the perspective of CockroachDB, a transaction sent as a batch looks like this:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-
-> DELETE FROM customers WHERE id = 1;
-
-> DELETE orders WHERE customer = 1;
-
-> COMMIT;
-~~~
-
-However, in your application's code, batched transactions are often just multiple statements sent at once. For example, in Go, this transaction would sent as a single batch (and automatically retried):
-
-~~~ go
-db.Exec(
-  "BEGIN;
-
-  DELETE FROM customers WHERE id = 1;
-
-  DELETE orders WHERE customer = 1;
-
-  COMMIT;"
-)
-~~~
-
-Issuing statements this way signals to CockroachDB that you do not need to change any of the statement's values if the transaction doesn't immediately succeed, so it can continually retry the transaction until it's accepted.
-
-## See also
-
-- [Transactions](transactions.html)
-- [`COMMIT`](commit-transaction.html)
-- [`SAVEPOINT`](savepoint.html)
-- [`RELEASE SAVEPOINT`](release-savepoint.html)
-- [`ROLLBACK`](rollback-transaction.html)
diff --git a/src/current/v20.2/bit.md b/src/current/v20.2/bit.md
deleted file mode 100644
index 85b3731b172..00000000000
--- a/src/current/v20.2/bit.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: BIT
-summary: The BIT and BIT VARYING data types stores bit arrays.
-toc: true
----
-
-The `BIT` and `VARBIT` [data types](data-types.html) stores bit arrays.
-With `BIT`, the length is fixed; with `VARBIT`, the length can be variable.
-
-## Aliases
-
-The name `BIT VARYING` is an alias for `VARBIT`.
-
-## Syntax
-
-Bit array constants are expressed as literals. For example, `B'100101'` denotes an array of 6 bits.
-
-For more information about bit array constants, see the [constants documentation on bit array literals](sql-constants.html#bit-array-literals).
-
-For usage, see the [Example](#example) below.
-
-## Size
-
-The number of bits in a `BIT` value is determined as follows:
-
-| Type declaration | Logical size                      |
-|------------------|-----------------------------------|
-| BIT              | 1 bit                             |
-| BIT(N)           | N bits                            |
-| VARBIT           | variable with no maximum          |
-| VARBIT(N)        | variable with a maximum of N bits |
-
-The effective size of a `BIT` value is larger than its logical number
-of bits by a bounded constant factor. Internally, CockroachDB stores
-bit arrays in increments of 64 bits plus an extra integer value to
-encode the length.
-
-The total size of a `BIT` value can be arbitrarily large, but it is
-recommended to keep values under 1 MB to ensure performance. Above
-that threshold, [write
-amplification](https://en.wikipedia.org/wiki/Write_amplification) and
-other considerations may cause significant performance degradation.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE b (x BIT, y BIT(3), z VARBIT, w VARBIT(3));
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM b;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+
-  x           | BIT       |    true     | NULL           |                       | {}        |   false
-  y           | BIT(3)    |    true     | NULL           |                       | {}        |   false
-  z           | VARBIT    |    true     | NULL           |                       | {}        |   false
-  w           | VARBIT(3) |    true     | NULL           |                       | {}        |   false
-  rowid       | INT       |    false    | unique_rowid() |                       | {primary} |   true
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO b(x, y, z, w) VALUES (B'1', B'101', B'1', B'1');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM b;
-~~~
-
-~~~
-  x |  y  | z | w
-+---+-----+---+---+
-  1 | 101 | 1 | 1
-~~~
-
-For type `BIT`, the value must match exactly the specified size:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO b(x) VALUES (B'101');
-~~~
-
-~~~
-pq: bit string length 3 does not match type BIT
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO b(y) VALUES (B'10');
-~~~
-
-~~~
-pq: bit string length 2 does not match type BIT(3)
-~~~
-
-For type `VARBIT`, the value must not be larger than the specified maximum size:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO b(w) VALUES (B'1010');
-~~~
-
-~~~
-pq: bit string length 4 too large for type VARBIT(3)
-~~~
-
-## Supported casting and conversion
-
-`BIT` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|---------
-`INT` | Converts the bit array to the corresponding numeric value, interpreting the bits as if the value was encoded using [two's complement](https://en.wikipedia.org/wiki/Two%27s_complement). If the bit array is larger than the integer type, excess bits on the left are ignored. For example, `B'1010'::INT` equals `10`.
-`STRING` | Prints out the binary digits as a string. This recovers the literal representation. For example, `B'1010'::STRING` equals `'1010'`.
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/bool.md b/src/current/v20.2/bool.md
deleted file mode 100644
index fbd5e72f4fa..00000000000
--- a/src/current/v20.2/bool.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: BOOL
-summary: The BOOL data type stores Boolean values of false or true.
-toc: true
----
-
-The `BOOL` [data type](data-types.html) stores a Boolean value of `false` or `true`.
-
-
-## Aliases
-
-In CockroachDB, `BOOLEAN` is an alias for `BOOL`.
-
-## Syntax
-
-There are two predefined [named constants](sql-constants.html#named-constants) for `BOOL`: `TRUE` and `FALSE` (the names are case-insensitive).
-
-Alternately, a boolean value can be obtained by coercing a numeric value: zero is coerced to `FALSE`, and any non-zero value to `TRUE`.
-
-- `CAST(0 AS BOOL)` (false)
-- `CAST(123 AS BOOL)` (true)
-
-## Size
-
-A `BOOL` value is 1 byte in width, but the total storage size is likely to be larger due to CockroachDB metadata.  
-
-## Examples
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE bool (a INT PRIMARY KEY, b BOOL, c BOOLEAN);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM bool;
-~~~
-
-~~~
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-| column_name | data_type | is_nullable | column_default | generation_expression |   indices   |
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-| a           | INT       |    false    | NULL           |                       | {"primary"} |
-| b           | BOOL      |    true     | NULL           |                       | {}          |
-| c           | BOOL      |    true     | NULL           |                       | {}          |
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO bool VALUES (12345, true, CAST(0 AS BOOL));
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM bool;
-~~~
-
-~~~
-+-------+------+-------+
-|   a   |  b   |   c   |
-+-------+------+-------+
-| 12345 | true | false |
-+-------+------+-------+
-~~~
-
-## Supported casting and conversion
-
-`BOOL` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`INT` | Converts `true` to `1`, `false` to `0`
-`DECIMAL` | Converts `true` to `1`, `false` to `0`
-`FLOAT` | Converts `true` to `1`, `false` to `0`
-`STRING` | ––
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/build-a-csharp-app-with-cockroachdb.md b/src/current/v20.2/build-a-csharp-app-with-cockroachdb.md
deleted file mode 100644
index 604516658c5..00000000000
--- a/src/current/v20.2/build-a-csharp-app-with-cockroachdb.md
+++ /dev/null
@@ -1,235 +0,0 @@
----
-title: Build a C# App with CockroachDB and the .NET Npgsql Driver
-summary: Learn how to use CockroachDB from a simple C# (.NET) application with a low-level client driver.
-toc: true
-twitter: true
----
-
-This tutorial shows you how build a simple C# application with CockroachDB and the .NET Npgsql driver.
-
-We have tested the [.NET Npgsql driver](http://www.npgsql.org/) enough to claim **beta-level** support. If you encounter problems, please [open an issue](https://github.com/cockroachdb/cockroach/issues/new) with details to help us make progress toward full support.
-
-## Before you begin
-
-{% include {{page.version.version}}/app/before-you-begin.md %}
-
-## Step 1. Create a .NET project
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ dotnet new console -o cockroachdb-test-app
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cd cockroachdb-test-app
-~~~
-
-The `dotnet` command creates a new app of type `console`. The `-o` parameter creates a directory named `cockroachdb-test-app` where your app will be stored and populates it with the required files. The `cd cockroachdb-test-app` command puts you into the newly created app directory.
-
-## Step 2. Install the Npgsql driver
-
-Install the latest version of the [Npgsql driver](https://www.nuget.org/packages/Npgsql/) into the .NET project using the built-in nuget package manager:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ dotnet add package Npgsql
-~~~
-
-<section class="filter-content" markdown="1" data-scope="secure">
-
-## Step 3. Create the `maxroach` user and `bank` database
-
-{% include {{page.version.version}}/app/create-maxroach-user-and-bank-database.md %}
-
-## Step 4. Generate a certificate for the `maxroach` user
-
-Create a certificate and key for the `maxroach` user by running the following command.  The code samples will run as this user.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client maxroach --certs-dir=certs --ca-key=my-safe-directory/ca.key
-~~~
-
-## Step 5. Convert the key file for use by C# programs
-
-The private key generated for user `maxroach` by CockroachDB is [PEM encoded](https://tools.ietf.org/html/rfc1421).  To read the key in a C# application, you will need to convert it into PKCS#12 format.
-
-To convert the key to PKCS#12 format, run the following OpenSSL command on the `maxroach` user's key file in the directory where you stored your certificates:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ openssl pkcs12 -inkey client.maxroach.key -password pass: -in client.maxroach.crt -export -out client.maxroach.pfx
-~~~
-
-As of December 2018, you need to provide a password for this to work on macOS. See <https://github.com/dotnet/corefx/issues/24225>.
-
-## Step 6. Run the C# code
-
-Now that you have created a database and set up encryption keys, in this section you will:
-
-- [Create a table and insert some rows](#basic-example)
-- [Execute a batch of statements as a transaction](#transaction-example-with-retry-logic)
-
-### Basic example
-
-Replace the contents of `cockroachdb-test-app/Program.cs` with the following code:
-
-{% include copy-clipboard.html %}
-~~~ csharp
-{% include {{ page.version.version }}/app/basic-sample.cs %}
-~~~
-
-Then, run the code to connect as the `maxroach` user.  This time, execute a batch of statements as an atomic transaction to transfer funds from one account to another, where all included statements are either committed or aborted:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ dotnet run
-~~~
-
-The output should be:
-
-~~~
-Initial balances:
-	account 1: 1000
-	account 2: 250
-~~~
-
-### Transaction example (with retry logic)
-
-Open `cockroachdb-test-app/Program.cs` again and replace the contents with the code shown below.
-
-{% include {{page.version.version}}/client-transaction-retry.md %}
-
-{% include copy-clipboard.html %}
-~~~ csharp
-{% include {{ page.version.version }}/app/txn-sample.cs %}
-~~~
-
-Then, run the code to connect as the `maxroach` user.  This time, execute a batch of statements as an atomic transaction to transfer funds from one account to another, where all included statements are either committed or aborted:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ dotnet run
-~~~
-
-The output should be:
-
-~~~
-Initial balances:
-	account 1: 1000
-	account 2: 250
-Final balances:
-	account 1: 900
-	account 2: 350
-~~~
-
-However, if you want to verify that funds were transferred from one account to another, use the [built-in SQL client](cockroach-sql.html):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs --database=bank -e 'SELECT id, balance FROM accounts'
-~~~
-
-~~~
-  id | balance
-+----+---------+
-   1 |     900
-   2 |     350
-(2 rows)
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-
-## Step 3. Create the `maxroach` user and `bank` database
-
-{% include {{page.version.version}}/app/insecure/create-maxroach-user-and-bank-database.md %}
-
-## Step 4. Run the C# code
-
-Now that you have created a database and set up encryption keys, in this section you will:
-
-- [Create a table and insert some rows](#basic2)
-- [Execute a batch of statements as a transaction](#transaction2)
-
-<a name="basic2"></a>
-
-### Basic example
-
-Replace the contents of `cockroachdb-test-app/Program.cs` with the following code:
-
-{% include copy-clipboard.html %}
-~~~ csharp
-{% include {{ page.version.version }}/app/insecure/basic-sample.cs %}
-~~~
-
-Then, run the code to connect as the `maxroach` user and execute some basic SQL statements: creating a table, inserting rows, and reading and printing the rows:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ dotnet run
-~~~
-
-The output should be:
-
-~~~
-Initial balances:
-	account 1: 1000
-	account 2: 250
-~~~
-
-<a name="transaction2"></a>
-
-### Transaction example (with retry logic)
-
-Open `cockroachdb-test-app/Program.cs` again and replace the contents with the code shown below.
-
-{% include {{page.version.version}}/client-transaction-retry.md %}
-
-{% include copy-clipboard.html %}
-~~~ csharp
-{% include {{ page.version.version }}/app/insecure/txn-sample.cs %}
-~~~
-
-Then, run the code to connect as the `maxroach` user.  This time, execute a batch of statements as an atomic transaction to transfer funds from one account to another, where all included statements are either committed or aborted:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ dotnet run
-~~~
-
-The output should be:
-
-~~~
-Initial balances:
-	account 1: 1000
-	account 2: 250
-Final balances:
-	account 1: 900
-	account 2: 350
-~~~
-
-However, if you want to verify that funds were transferred from one account to another, use the [built-in SQL client](cockroach-sql.html):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure  --database=bank -e 'SELECT id, balance FROM accounts'
-~~~
-
-~~~
-  id | balance
-+----+---------+
-   1 |     900
-   2 |     350
-(2 rows)
-~~~
-
-</section>
-
-## What's next?
-
-Read more about using the [.NET Npgsql driver](http://www.npgsql.org/).
-
-{% include {{ page.version.version }}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-go-app-with-cockroachdb-gorm.md b/src/current/v20.2/build-a-go-app-with-cockroachdb-gorm.md
deleted file mode 100644
index 48dc8872645..00000000000
--- a/src/current/v20.2/build-a-go-app-with-cockroachdb-gorm.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: Build a Go App with CockroachDB and GORM
-summary: Learn how to use CockroachDB from a simple Go application with the GORM ORM.
-toc: true
-twitter: false
-referral_id: docs_hello_world_go_gorm
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-go-app-with-cockroachdb.html"><button class="filter-button">Use <strong>pgx</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-pq.html"><button class="filter-button">Use <strong>pq</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-gorm.html"><button class="filter-button current">Use <strong>GORM</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-upperdb.html"><button class="filter-button">Use <strong>upper/db</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple CRUD Go application with CockroachDB and the [GORM ORM](https://gorm.io/index.html).
-
-{{site.data.alerts.callout_success}}
-For another use of GORM with CockroachDB, see our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-{{site.data.alerts.end}}
-
-## Step 1. Start CockroachDB
-
-{% include {{ page.version.version }}/app/sample-setup.md %}
-
-## Step 2. Get the code
-
-Clone the code's GitHub repo:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ git clone https://github.com/cockroachlabs/example-app-go-gorm
-~~~
-
-The project has the following directory structure:
-
-~~~
-├── README.md
-└── main.go
-~~~
-
-The `main.go` file defines an `Account` struct that maps to a new `accounts` table in the `bank` database. The file also contains some read and write database operations that are executed in the `main` method of the program.
-
-{% include_cached copy-clipboard.html %}
-~~~ go
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-go-gorm/master/main.go %}
-~~~
-
-{{site.data.alerts.callout_info}}
-CockroachDB may require the [client to retry a transaction](transactions.html#transaction-retries) in the case of read/write contention. The [CockroachDB Go client](https://github.com/cockroachdb/cockroach-go) includes a generic **retry function** (`ExecuteTx()`) that runs inside a transaction and retries it as needed. The code sample shows how you can use this function to wrap SQL statements.
-{{site.data.alerts.end}}
-
-## Step 3. Run the code
-
-1. Initialize the module:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ go mod init basic-sample && go mod tidy
-    ~~~
-
-1. Run the code:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ go run main.go
-    ~~~
-
-    The program will prompt you for a connection string to the database:
-
-    ~~~
-    Enter a connection string:
-    ~~~
-
-1. Enter the connection string to your running cluster.
-
-    <section class="filter-content" markdown="1" data-scope="local">
-
-    {{site.data.alerts.callout_success}}
-    `postgresql://root@localhost:26257?sslmode=disable` should be the `sql` connection URL provided in the `cockroach` welcome text.
-    {{site.data.alerts.end}}
-
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-    {{site.data.alerts.callout_success}}
-    Use the connection string provided in the **Connection info** window of the CockroachDB {{ site.data.products.cloud }} Console.
-    {{site.data.alerts.end}}
-
-    {{site.data.alerts.callout_info}}
-    You need to provide a SQL user password in order to securely connect to a CockroachDB {{ site.data.products.cloud }} cluster. The connection string should have a placeholder for the password (`<ENTER-PASSWORD>`).
-    {{site.data.alerts.end}}
-
-    </section>
-
-    The output should look similar to the following:
-
-    ~~~
-    2021/09/16 14:17:12 Creating 5 new accounts...
-    2021/09/16 14:17:12 Accounts created.
-    Balance at '2021-09-16 14:17:12.68843 -0400 EDT m=+2.760587790':
-    1580d2f4-c9ec-4f26-bbe7-6a53e9aa5170 1947
-    26ddc77b-8068-409b-b305-0c5d873f7c43 7987
-    3d97ea5a-5108-4388-88e8-92524d5de5e8 4159
-    af49831d-d637-4a20-a9a7-01e9fe4628fe 8181
-    f0cc97ef-e3fe-4abb-a44a-0dd04207f7d4 2181
-    2021/09/16 14:17:12 Transferring 100 from account af49831d-d637-4a20-a9a7-01e9fe4628fe to account 3d97ea5a-5108-4388-88e8-92524d5de5e8...
-    2021/09/16 14:17:12 Funds transferred.
-    Balance at '2021-09-16 14:17:12.759686 -0400 EDT m=+2.831841311':
-    1580d2f4-c9ec-4f26-bbe7-6a53e9aa5170 1947
-    26ddc77b-8068-409b-b305-0c5d873f7c43 7987
-    3d97ea5a-5108-4388-88e8-92524d5de5e8 4259
-    af49831d-d637-4a20-a9a7-01e9fe4628fe 8081
-    f0cc97ef-e3fe-4abb-a44a-0dd04207f7d4 2181
-    2021/09/16 14:17:12 Deleting accounts created...
-    2021/09/16 14:17:12 Accounts deleted.
-    ~~~
-
-    The code runs a migration that creates the `accounts` table in the `bank` database, based on the `Account` struct defined at the top of the `main.go` file.
-
-    As shown in the output, the code also does the following:
-    - Inserts some rows into the `accounts` table.
-    - Reads values from the table.
-    - Updates values in the table.
-    - Deletes values from the table.
-
-## What's next?
-
-Read more about using the [GORM ORM](http://gorm.io), or check out a more realistic implementation of GORM with CockroachDB in our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-
-{% include {{ page.version.version }}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-go-app-with-cockroachdb-pq.md b/src/current/v20.2/build-a-go-app-with-cockroachdb-pq.md
deleted file mode 100644
index 55e8dbad8dd..00000000000
--- a/src/current/v20.2/build-a-go-app-with-cockroachdb-pq.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: Build a Go App with CockroachDB the Go pq Driver
-summary: Learn how to use CockroachDB from a simple Go application with the Go pq driver.
-toc: true
-twitter: false
-referral_id: docs_hello_world_go_pq
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-go-app-with-cockroachdb.html"><button class="filter-button">Use <strong>pgx</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-pq.html"><button class="filter-button current">Use <strong>pq</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-gorm.html"><button class="filter-button">Use <strong>GORM</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-upperdb.html"><button class="filter-button">Use <strong>upper/db</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Go application with CockroachDB and the Go [pq driver](https://github.com/lib/pq).
-
-## Step 1. Start CockroachDB
-
-{% include {{page.version.version}}/app/start-cockroachdb.md %}
-
-## Step 2. Create a database
-
-{% include {{page.version.version}}/app/create-a-database.md %}
-
-## Step 3. Run the Go code
-
-You can now run the code sample (`main.go`) provided in this tutorial to do the following:
-
-- Create a table in the `bank` database.
-- Insert some rows into the table you created.
-- Read values from the table.
-- Execute a batch of statements as an atomic [transaction](transactions.html).
-
-    Note that CockroachDB may require the [client to retry a transaction](transactions.html#transaction-retries) in the case of read/write contention. The [CockroachDB Go client](https://github.com/cockroachdb/cockroach-go) includes a generic **retry function** (`ExecuteTx()`) that runs inside a transaction and retries it as needed. The code sample shows how you can use this function to wrap SQL statements.
-
-### Get the code
-
-You can copy the code below, [download the code directly](https://raw.githubusercontent.com/cockroachlabs/hello-world-go-pq/master/main.go), or clone [the code's GitHub repository](https://github.com/cockroachlabs/hello-world-go-pq).
-
-Here are the contents of `main.go`:
-
-{% include_cached copy-clipboard.html %}
-~~~ go
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/hello-world-go-pq/master/main.go %}
-~~~
-
-### Update the connection parameters
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-Edit the connection string passed to `sql.Open()` so that:
-
-- `{username}` and `{password}` specify the SQL username and password that you created earlier.
-- `{hostname}` and `{port}` specify the hostname and port in the `(sql/tcp)` connection string from SQL shell welcome text.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-Replace the string passed to `sql.Open()` with the connection string that you copied [earlier](#set-up-your-cluster-connection) from the **Connection info** dialog.
-
-The function call should look similar to the following:
-
-{% include_cached copy-clipboard.html %}
-~~~ go
-db, err := sql.Open("postgres", "postgresql://{user}:{password}@{globalhost}:26257/bank?sslmode=verify-full&sslrootcert={path to the CA certificate}&options=--cluster={cluster_name}")
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-</section>
-
-### Run the code
-
-Initialize the module:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ go mod init basic-sample
-~~~
-
-Then run the code:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ go run main.go
-~~~
-
-The output should be:
-
-~~~
-Balances:
-1 1000
-2 250
-Success
-Balances:
-1 900
-2 350
-~~~
-
-To verify that the SQL statements were executed, run the following query from inside the SQL shell:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> USE bank;
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT id, balance FROM accounts;
-~~~
-
-The output should be:
-
-~~~
-  id | balance
------+----------
-   1 |     900
-   2 |     350
-(2 rows)
-~~~
-
-## What's next?
-
-Read more about using the [Go pq driver](https://godoc.org/github.com/lib/pq).
-
-{% include {{ page.version.version }}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-go-app-with-cockroachdb-upperdb.md b/src/current/v20.2/build-a-go-app-with-cockroachdb-upperdb.md
deleted file mode 100644
index 06cb28f019d..00000000000
--- a/src/current/v20.2/build-a-go-app-with-cockroachdb-upperdb.md
+++ /dev/null
@@ -1,163 +0,0 @@
----
-title: Build a Go App with CockroachDB and upper/db
-summary: Learn how to use CockroachDB from a simple Go application with the upper/db data access layer.
-toc: true
-twitter: false
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-go-app-with-cockroachdb.html"><button class="filter-button">Use <strong>pgx</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-pq.html"><button class="filter-button">Use <strong>pq</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-gorm.html"><button class="filter-button">Use <strong>GORM</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-upperdb.html"><button class="filter-button current">Use <strong>upper/db</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Go application with CockroachDB and the [upper/db](https://upper.io/) data access layer.
-
-## Before you begin
-
-{% include {{page.version.version}}/app/before-you-begin.md %}
-
-<section class="filter-content" markdown="1" data-scope="secure">
-
-## Step 1. Create the `maxroach` user and `bank` database
-
-{% include {{page.version.version}}/app/create-maxroach-user-and-bank-database.md %}
-
-## Step 2. Generate a certificate for the `maxroach` user
-
-Create a certificate and key for the `maxroach` user by running the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client maxroach --certs-dir=certs --ca-key=my-safe-directory/ca.key
-~~~
-
-The code samples will run with `maxroach` as the user.
-
-## Step 3. Run the Go code
-
-The sample code shown below uses upper/db to map Go-specific objects to SQL operations. Specifically, the code:
-
-- Creates the `accounts` table, if it does not already exist.
-- Deletes any existing rows in the `accounts` table.
-- Inserts two rows into the `accounts` table.
-- Prints the rows in the `accounts` table to the terminal.
-- Deletes the first row in the `accounts` table.
-- Updates the rows in the `accounts` table within an explicit [transaction](transactions.html).
-- Prints the rows in the `accounts` table to the terminal once more.
-
-{% include copy-clipboard.html %}
-~~~ go
-{% include {{ page.version.version }}/app/upperdb-basic-sample/main.go %}
-~~~
-
-Note that the sample code also includes a function that simulates a transaction error (`crdbForceRetry()`). Upper/db's CockroachDB adapter [automatically retries transactions](transactions.html#client-side-intervention) when transaction errors are thrown. As a result, this function forces a transaction retry.
-
-To run the code, copy the sample above, or <a href="https://raw.githubusercontent.com/cockroachdb/docs/master/_includes/{{ page.version.version }}/app/upperdb-basic-sample/main.go" download>download it directly</a>.
-
-{{site.data.alerts.callout_success}}
-To clone a version of the code below that connects to insecure clusters, run the following command:
-
-`git clone https://github.com/cockroachlabs/hello-world-go-upperdb/`
-
-Note that you will need to edit the connection string to use the certificates that you generated when you set up your secure cluster.
-{{site.data.alerts.end}}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-
-## Step 1. Create the `maxroach` user and `bank` database
-
-{% include {{page.version.version}}/app/insecure/create-maxroach-user-and-bank-database.md %}
-
-## Step 2. Run the Go code
-
-The sample code shown below uses upper/db to map Go-specific objects to SQL operations. Specifically, the code:
-
-- Creates the `accounts` table, if it does not already exist.
-- Deletes any existing rows in the `accounts` table.
-- Inserts two rows into the `accounts` table.
-- Prints the rows in the `accounts` table to the terminal.
-- Deletes the first row in the `accounts` table.
-- Updates the rows in the `accounts` table within an explicit [transaction](transactions.html).
-- Prints the rows in the `accounts` table to the terminal once more.
-
-{% include copy-clipboard.html %}
-~~~ go
-{% include {{ page.version.version }}/app/insecure/upperdb-basic-sample/main.go %}
-~~~
-
-Note that the sample code also includes a function that simulates a transaction error (`crdbForceRetry()`). Upper/db's CockroachDB adapter [automatically retries transactions](transactions.html#client-side-intervention) when transaction errors are thrown. As a result, this function forces a transaction retry.
-
-Copy the code or <a href="https://raw.githubusercontent.com/cockroachdb/docs/master/_includes/{{ page.version.version }}/app/insecure/upperdb-basic-sample/main.go" download>download it directly</a>.
-
-{{site.data.alerts.callout_success}}
-To clone a version of the code below that connects to insecure clusters, run the following command:
-
-`git clone https://github.com/cockroachlabs/hello-world-go-upperdb/`
-{{site.data.alerts.end}}
-
-</section>
-
-Change to the directory where you cloned the repo and get the dependencies with `go mod init`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ go mod init hello-world-go-upperdb
-~~~
-
-Then run the code:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ go run main.go
-~~~
-
-The output should look similar to the following:
-
-~~~
-go: finding module for package github.com/upper/db/v4
-go: finding module for package github.com/upper/db/v4/adapter/cockroachdb
-go: found github.com/upper/db/v4 in github.com/upper/db/v4 v4.0.0
-2020/09/16 10:31:55 Balances:
-	accounts[590467288222990337]: 1000
-	accounts[590467288229576705]: 250
-2020/09/16 10:31:55 Balances:
-	accounts[590467288222990337]: 500
-	accounts[590467288229576705]: 999
-2020/09/16 10:31:55 upper/db: log_level=WARNING file=go/pkg/mod/github.com/upper/db/v4@v4.0.0/internal/sqladapter/session.go:642
-	Session ID:     00006
-	Transaction ID: 00005
-	Query:          SELECT crdb_internal.force_retry('1ms'::INTERVAL)
-	Error:          pq: restart transaction: crdb_internal.force_retry(): TransactionRetryWithProtoRefreshError: forced by crdb_internal.force_retry()
-	Time taken:     0.00171s
-	Context:        context.Background
-
-2020/09/16 10:31:55 upper/db: log_level=WARNING file=go/pkg/mod/github.com/upper/db/v4@v4.0.0/internal/sqladapter/session.go:642
-	Session ID:     00006
-	Transaction ID: 00005
-	Query:          INSERT INTO "accounts" ("balance") VALUES ($1) RETURNING "id"
-	Arguments:      []interface {}{887}
-	Error:          pq: current transaction is aborted, commands ignored until end of transaction block
-	Time taken:     0.00065s
-	Context:        context.Background
-
-2020/09/16 10:31:56 Balances:
-	accounts[590467288229576705]: 999
-	accounts[590467288342757377]: 887
-	accounts[590467288350064641]: 342
-~~~
-
-Note that the forced transaction errors result in errors printed to the terminal, but the transactions are retried until they succeed.
-
-## What's next?
-
-Read more about upper/db:
-
-- [Introduction to upper/db](https://upper.io/v4/getting-started/)
-- [The upper/db tour](https://tour.upper.io/)
-- [upper/db reference docs](https://pkg.go.dev/github.com/upper/db/v4)
-
-{% include {{ page.version.version }}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-go-app-with-cockroachdb.md b/src/current/v20.2/build-a-go-app-with-cockroachdb.md
deleted file mode 100644
index cfe70a5497f..00000000000
--- a/src/current/v20.2/build-a-go-app-with-cockroachdb.md
+++ /dev/null
@@ -1,161 +0,0 @@
----
-title: Build a Simple CRUD Go App with CockroachDB and the Go pgx Driver
-summary: Learn how to use CockroachDB from a simple Go application with the Go pgx driver.
-toc: true
-twitter: false
-referral_id: docs_hello_world_go_pgx
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-go-app-with-cockroachdb.html"><button class="filter-button current">Use <strong>pgx</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-pq.html"><button class="filter-button">Use <strong>pq</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-gorm.html"><button class="filter-button">Use <strong>GORM</strong></button></a>
-    <a href="build-a-go-app-with-cockroachdb-upperdb.html"><button class="filter-button">Use <strong>upper/db</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple CRUD Go application with CockroachDB and the [Go pgx driver](https://pkg.go.dev/github.com/jackc/pgx).
-
-## Step 1. Start CockroachDB
-
-{% include {{ page.version.version }}/app/sample-setup.md %}
-
-## Step 2. Get the code
-
-Clone the code's GitHub repo:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ git clone https://github.com/cockroachlabs/example-app-go-pgx/
-~~~
-
-The project has the following directory structure:
-
-~~~
-├── README.md
-├── dbinit.sql
-└── main.go
-~~~
-
-The `dbinit.sql` file initializes the database schema that the application uses:
-
-{% include_cached copy-clipboard.html %}
-~~~ go
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-go-pgx/master/dbinit.sql %}
-~~~
-
-The `main.go` file contains the code for `INSERT`, `SELECT`, `UPDATE`, and `DELETE` SQL operations. The file also executes the `main` method of the program.
-
-{% include_cached copy-clipboard.html %}
-~~~ go
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-go-pgx/master/main.go %}
-~~~
-
-{{site.data.alerts.callout_info}}
-CockroachDB may require the [client to retry a transaction](transactions.html#transaction-retries) in the case of read/write contention. The [CockroachDB Go client](https://github.com/cockroachdb/cockroach-go) includes a generic **retry function** (`ExecuteTx()`) that runs inside a transaction and retries it as needed. The code sample shows how you can use this function to wrap SQL statements.
-{{site.data.alerts.end}}
-
-## Step 3. Initialize the database
-
-{% include {{ page.version.version }}/app/init-bank-sample.md %}
-
-## Step 4. Run the code
-
-1. Initialize the module:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ go mod init basic-sample && go mod tidy
-    ~~~
-
-1. Run the code:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ go run main.go
-    ~~~
-
-    The program will prompt you for a connection string to the database:
-
-    ~~~
-    Enter a connection string:
-    ~~~
-
-1. Enter the connection string to your running cluster.
-
-    <section class="filter-content" markdown="1" data-scope="local">
-
-    {{site.data.alerts.callout_success}}
-    `postgresql://root@localhost:26257?sslmode=disable` should be the `sql` connection URL provided in the `cockroach` welcome text.
-    {{site.data.alerts.end}}
-
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-    {{site.data.alerts.callout_success}}
-    Use the connection string provided in the **Connection info** window of the CockroachDB {{ site.data.products.cloud }} Console.
-    {{site.data.alerts.end}}
-
-    {{site.data.alerts.callout_info}}
-    You need to provide a SQL user password in order to securely connect to a CockroachDB {{ site.data.products.cloud }} cluster. The connection string should have a placeholder for the password (`<ENTER-PASSWORD>`).
-    {{site.data.alerts.end}}
-
-    </section>
-
-    The output should look similar to the following:
-
-    ~~~
-    2021/07/20 14:48:02 Creating new rows...
-    2021/07/20 14:48:02 New rows created.
-    2021/07/20 14:48:02 Initial balances:
-    2021/07/20 14:48:02 3a936990-a0c9-45bf-bc24-92e10d91dca9: 300
-    2021/07/20 14:48:02 8d1849dd-9222-4b12-a4ff-94e583b544a8: 250
-    2021/07/20 14:48:02 c6ae8917-d24e-4115-b719-f663dbfb9ffb: 500
-    2021/07/20 14:48:02 d0ce1f5c-e468-4899-8590-2bb6076247f2: 100
-    2021/07/20 14:48:02 Transferring funds from account with ID c6ae8917-d24e-4115-b719-f663dbfb9ffb to account with ID d0ce1f5c-e468-4899-8590-2bb6076247f2...
-    2021/07/20 14:48:02 Transfer successful.
-    2021/07/20 14:48:02 Balances after transfer:
-    2021/07/20 14:48:02 3a936990-a0c9-45bf-bc24-92e10d91dca9: 300
-    2021/07/20 14:48:02 8d1849dd-9222-4b12-a4ff-94e583b544a8: 250
-    2021/07/20 14:48:02 c6ae8917-d24e-4115-b719-f663dbfb9ffb: 400
-    2021/07/20 14:48:02 d0ce1f5c-e468-4899-8590-2bb6076247f2: 200
-    2021/07/20 14:48:02 Deleting rows with IDs 8d1849dd-9222-4b12-a4ff-94e583b544a8 and d0ce1f5c-e468-4899-8590-2bb6076247f2...
-    2021/07/20 14:48:02 Rows deleted.
-    2021/07/20 14:48:02 Balances after deletion:
-    2021/07/20 14:48:02 3a936990-a0c9-45bf-bc24-92e10d91dca9: 300
-    2021/07/20 14:48:02 c6ae8917-d24e-4115-b719-f663dbfb9ffb: 400
-    ~~~
-
-    As shown in the output, the code does the following:
-    - Inserts some rows into the `accounts` table.
-    - Reads values from the table.
-    - Updates values in the table.
-    - Deletes values from the table.
-
-1. To verify that the SQL statements were executed, run the following query from inside the SQL shell:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > USE bank;
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SELECT id, balance FROM accounts;
-    ~~~
-
-    The output should look similar to the following:
-
-    ~~~
-                       id                  | balance
-    ---------------------------------------+----------
-      3a936990-a0c9-45bf-bc24-92e10d91dca9 |     300
-      c6ae8917-d24e-4115-b719-f663dbfb9ffb |     400
-    (2 rows)
-    ~~~
-
-## What's next?
-
-Read more about using the [Go pgx driver](https://pkg.go.dev/github.com/jackc/pgx?tab=doc).
-
-{% include {{ page.version.version }}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-java-app-with-cockroachdb-hibernate.md b/src/current/v20.2/build-a-java-app-with-cockroachdb-hibernate.md
deleted file mode 100644
index 9768164da6d..00000000000
--- a/src/current/v20.2/build-a-java-app-with-cockroachdb-hibernate.md
+++ /dev/null
@@ -1,205 +0,0 @@
----
-title: Build a Java App with CockroachDB and Hibernate
-summary: Learn how to use CockroachDB from a simple Java application with the Hibernate ORM.
-toc: true
-twitter: false
-referral_id: docs_hello_world_java_hibernate
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-java-app-with-cockroachdb.html"><button class="filter-button">Use <strong>JDBC</strong></button></a>
-    <a href="build-a-java-app-with-cockroachdb-hibernate.html"><button class="filter-button current">Use <strong>Hibernate</strong></button></a>
-    <a href="build-a-java-app-with-cockroachdb-jooq.html"><button class="filter-button">Use <strong>jOOQ</strong></button></a>
-    <a href="build-a-spring-app-with-cockroachdb-mybatis.html"><button style="width: 25%" class="filter-button">Use <strong>MyBatis-Spring</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Java application with CockroachDB and the Hibernate ORM.
-
-{% include {{page.version.version}}/app/java-version-note.md %}
-
-{{site.data.alerts.callout_success}}
-For a sample app and tutorial that uses Spring Data JPA (Hibernate) and CockroachDB, see [Build a Spring App with CockroachDB and JPA](build-a-spring-app-with-cockroachdb-jpa.html).
-
-For another use of Hibernate with CockroachDB, see our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-{{site.data.alerts.end}}
-
-## Step 1. Start CockroachDB
-
-{% include {{page.version.version}}/app/start-cockroachdb.md %}
-
-## Step 2. Create a database
-
-{% include {{page.version.version}}/app/create-a-database.md %}
-
-## Step 3. Run the Java code
-
-The sample code in this tutorial ([`Sample.java`](#code-contents))uses Hibernate to map Java methods to SQL operations. The code performs the following operations, which roughly correspond to method calls in the `Sample` class:
-
-1. Creates an `accounts` table in the `bank` database as specified by the `Account` mapping class.
-1. Inserts rows into the table with the `addAccounts()` method.
-1. Transfers money from one account to another with the `transferFunds()` method.
-1. Prints out account balances before and after the transfer with the `getAccountBalance()` method.
-
-In addition, the code shows a pattern for automatically handling [transaction retries](transactions.html#client-side-intervention-example) by wrapping transactions in a higher-order function named `runTransaction()`. It also includes a method for testing the retry handling logic (`Sample.forceRetryLogic()`), which will be run if you set the `FORCE_RETRY` variable to `true`.
-
-It does all of the above using the practices we recommend for using Hibernate (and the underlying JDBC connection) with CockroachDB, which are listed in the [Recommended Practices](#recommended-practices) section below.
-
-<a name="code-contents"></a>
-The contents of `Sample.java`:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-java-hibernate/master/src/main/java/com/cockroachlabs/Sample.java %}
-~~~
-
-### Get the code
-
-Clone the `example-app-java-hibernate` repo to your machine:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-git clone https://github.com/cockroachlabs/example-app-java-hibernate/
-~~~
-
-{{site.data.alerts.callout_info}}
-The version of the CockroachDB Hibernate dialect in `hibernate.cfg.xml` corresponds to a version of CockroachDB. For more information, see [Install Client Drivers: Hibernate](install-client-drivers.html).
-{{site.data.alerts.end}}
-
-### Update the connection parameters
-
-Edit `src/main/resources/hibernate.cfg.xml` in a text editor.
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-1. Modify the `hibernate.connection.url` property with the port number from the connection string above:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ xml
-    <property name="hibernate.connection.url">jdbc:postgresql://localhost:{port}/bank?ssl=true&amp;sslmode=require</property>
-    ~~~
-
-    Where `{port}` is the port number on which the CockroachDB demo cluster is listening.
-
-1. Set the `hibernate.connection.username` property to the username you created earlier.
-
-1. Set the `hibernate.connection.password` property to the user's password.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-Modify the `hibernate.connection.url` property with the information from the connection string you copied [earlier](#set-up-your-cluster-connection) host, cluster and database name, and path to the SSL certificate:
-
-{% include_cached copy-clipboard.html %}
-~~~ xml
-<property name="hibernate.connection.url">jdbc:postgresql://{globalhost}:26257/{cluster_name}.bank?sslmode=verify-full&amp;sslrootcert={path to the CA certificate}</property>
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-</section>
-
-### Run the code
-
-Compile and run the code using `gradlew`, which will also download the dependencies.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ ./gradlew run
-~~~
-
-Toward the end of the output, you should see:
-
-~~~
-APP: BEGIN;
-APP: addAccounts() --> 1.00
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(1) --> 1000.00
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(2) --> 250.00
-APP: COMMIT;
-APP: getAccountBalance(1) --> 1000.00
-APP: getAccountBalance(2) --> 250.00
-APP: BEGIN;
-APP: transferFunds(1, 2, 100.00) --> 100.00
-APP: COMMIT;
-APP: transferFunds(1, 2, 100.00) --> 100.00
-APP: BEGIN;
-APP: getAccountBalance(1) --> 900.00
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(2) --> 350.00
-APP: COMMIT;
-APP: getAccountBalance(1) --> 900.00
-APP: getAccountBalance(2) --> 350.00
-~~~
-
-To verify that the account balances were updated successfully, start the [built-in SQL client](cockroach-sql.html):
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir={certs_dir}
-~~~
-
-Where:
-- `{certs_dir}` is the path to the directory containing the certificates and keys you generated earlier.
-
-To check the account balances, issue the following statement:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-SELECT id, balance FROM accounts;
-~~~
-
-~~~
-id |  balance
------+------------
- 1 |    900.00
- 2 |    350.00
- 3 | 314159.00
-(3 rows)
-~~~
-
-</section>
-
-## Recommended Practices
-
-### Generate PKCS8 keys for client authentication
-
-{% include {{page.version.version}}/app/pkcs8-gen.md %}
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-{% include cockroachcloud/cc-no-user-certs.md %}
-
-</section>
-
-### Use `IMPORT` to read in large data sets
-
-If you are trying to get a large data set into CockroachDB all at once (a bulk import), avoid writing client-side code altogether and use the [`IMPORT`](import.html) statement instead. It is much faster and more efficient than making a series of [`INSERT`s](insert.html) and [`UPDATE`s](update.html). It bypasses the [SQL layer](architecture/sql-layer.html) altogether and writes directly to the [storage layer](architecture/storage-layer.html) of the database.
-
-For more information about importing data from Postgres, see [Migrate from Postgres](migrate-from-postgres.html).
-
-For more information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Use `reWriteBatchedInserts` for increased speed
-
-We strongly recommend setting `reWriteBatchedInserts=true`; we have seen 2-3x performance improvements with it enabled. From [the JDBC connection parameters documentation](https://jdbc.postgresql.org/documentation/use/#connection-parameters):
-
-> This will change batch inserts from `insert into foo (col1, col2, col3) values (1,2,3)` into `insert into foo (col1, col2, col3) values (1,2,3), (4,5,6)` this provides 2-3x performance improvement
-
-### Retrieve large data sets in chunks using cursors
-
-CockroachDB now supports the Postgres wire-protocol cursors for implicit transactions and explicit transactions executed to completion. This means the [PGJDBC driver](https://jdbc.postgresql.org) can use this protocol to stream queries with large result sets. This is much faster than [paginating through results in SQL using `LIMIT .. OFFSET`](pagination.html).
-
-For instructions showing how to use cursors in your Java code, see [Getting results based on a cursor](https://jdbc.postgresql.org/documentation/query/#getting-results-based-on-a-cursor) from the PGJDBC documentation.
-
-Note that interleaved execution (partial execution of multiple statements within the same connection and transaction) is not supported when [`Statement.setFetchSize()`](https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#setFetchSize-int-) is used.
-
-## What's next?
-
-Read more about using the [Hibernate ORM](http://hibernate.org/orm/), or check out a more realistic implementation of Hibernate with CockroachDB in our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-java-app-with-cockroachdb-jooq.md b/src/current/v20.2/build-a-java-app-with-cockroachdb-jooq.md
deleted file mode 100644
index cb10572d054..00000000000
--- a/src/current/v20.2/build-a-java-app-with-cockroachdb-jooq.md
+++ /dev/null
@@ -1,276 +0,0 @@
----
-title: Build a Java App with CockroachDB and jOOQ
-summary: Learn how to use CockroachDB from a simple Java application with jOOQ.
-toc: true
-twitter: false
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-java-app-with-cockroachdb.html"><button class="filter-button">Use <strong>JDBC</strong></button></a>
-    <a href="build-a-java-app-with-cockroachdb-hibernate.html"><button class="filter-button">Use <strong>Hibernate</strong></button></a>
-    <a href="build-a-java-app-with-cockroachdb-jooq.html"><button class="filter-button current">Use <strong>jOOQ</strong></button></a>
-    <a href="build-a-spring-app-with-cockroachdb-mybatis.html"><button style="width: 25%" class="filter-button">Use <strong>MyBatis-Spring</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Java application with CockroachDB and [jOOQ](https://www.jooq.org/).
-
-CockroachDB is supported in jOOQ [Professional and Enterprise editions](https://www.jooq.org/download/#databases).
-
-{% include {{page.version.version}}/app/java-version-note.md %}
-
-{{site.data.alerts.callout_success}}
-For another use of jOOQ with CockroachDB, see our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-{{site.data.alerts.end}}
-
-## Before you begin
-
-{% include {{page.version.version}}/app/before-you-begin.md %}
-
-## Step 1. Install Maven
-
-This tutorial uses the [Maven build tool](https://gradle.org/) to manage application dependencies.
-
-To install Maven on Mac, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ brew install maven
-~~~
-
-To install Maven on a Debian-based Linux distribution like Ubuntu:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ apt-get install maven
-~~~
-
-For other ways to install Maven, see [its official documentation](https://maven.apache.org/install.html).
-
-## Step 2. Install jOOQ
-
-Download the free trial of jOOQ Professional or Enterprise edition from [jOOQ's website](https://www.jooq.org/download), and unzip the file.
-
-To install jOOQ to your machine's local Maven repository, run the `maven-install.sh` script included in the jOOQ install folder:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ chmod +x maven-install.sh
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./maven-install.sh
-~~~
-
-<section class="filter-content" markdown="1" data-scope="secure">
-
-## Step 3. Create the `maxroach` user and `bank` database
-
-{% include {{page.version.version}}/app/create-maxroach-user-and-bank-database.md %}
-
-## Step 4. Generate a certificate for the `maxroach` user
-
-Create a certificate and key for the `maxroach` user by running the following command. The code samples will run as this user.
-
-The [`--also-generate-pkcs8-key` flag](cockroach-cert.html#flag-pkcs8) generates a key in [PKCS#8 format](https://tools.ietf.org/html/rfc5208), which is the standard key encoding format in Java. In this case, the generated PKCS8 key will be named `client.maxroach.key.pk8`.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client maxroach --certs-dir=certs --ca-key=my-safe-directory/ca.key --also-generate-pkcs8-key
-~~~
-
-## Step 5. Run the Java code
-
-The code below uses jOOQ to map Java methods to SQL operations. It performs the following steps, some of which correspond to method calls of the `Sample` class.
-
-1. Inputs the `db.sql` file to the database. `db.sql` includes SQL statements that create an `accounts` table in the `bank` database.
-2. Inserts rows into the `accounts` table using `session.save(new Account(int id, int balance))` (see `Sample.addAccounts()`).
-3. Transfers money from one account to another, printing out account balances before and after the transfer (see `transferFunds(long fromId, long toId, long amount)`).
-4. Prints out account balances before and after the transfer (see `Sample.getAccountBalance(long id)`).
-
-In addition, the code shows a pattern for automatically handling [transaction retries](transactions.html#client-side-intervention-example) by wrapping transactions in a higher-order function `Sample.runTransaction()`. It also includes a method for testing the retry handling logic (`Sample.forceRetryLogic()`), which will be run if you set the `FORCE_RETRY` variable to `true`.
-
-To run it:
-
-1. Download and unzip [jooq-basic-sample.zip](https://github.com/cockroachdb/docs/raw/master/_includes/{{ page.version.version }}/app/jooq-basic-sample/jooq-basic-sample.zip).
-2. Open `jooq-basic-sample/src/main/java/com/cockroachlabs/Sample.java`, and edit the connection string passed to `DriverManager.getConnection()` in the `Sample` class's `main()` method so that the certificate paths are fully and correctly specified.
-3. Compile and run the code using Maven:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cd jooq-basic-sample
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mvn compile
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mvn exec:java -Dexec.mainClass=com.cockroachlabs.Sample
-    ~~~
-
-Here are the contents of [`Sample.java`](https://raw.githubusercontent.com/cockroachdb/docs/master/_includes/{{page.version.version}}/app/jooq-basic-sample/Sample.java), the Java file containing the main `Sample` class:
-
-{% include copy-clipboard.html %}
-~~~ java
-{% include {{page.version.version}}/app/jooq-basic-sample/Sample.java %}
-~~~
-
-Toward the end of the output, you should see:
-
-~~~
-APP: BEGIN;
-APP: addAccounts() --> 1
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(1) --> 1000
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(2) --> 250
-APP: COMMIT;
-APP: getAccountBalance(1) --> 1000
-APP: getAccountBalance(2) --> 250
-APP: BEGIN;
-APP: transferFunds(1, 2, 100) --> 100
-APP: COMMIT;
-APP: transferFunds(1, 2, 100) --> 100
-APP: BEGIN;
-APP: getAccountBalance(1) --> 900
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(2) --> 350
-APP: COMMIT;
-APP: getAccountBalance(1) --> 900
-APP: getAccountBalance(2) --> 350
-~~~
-
-To verify that the account balances were updated successfully, start the [built-in SQL client](cockroach-sql.html):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs
-~~~
-
-To check the account balances, issue the following statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT id, balance FROM accounts;
-~~~
-
-~~~
-  id | balance
-+----+---------+
-   1 |     900
-   2 |     350
-   3 |  314159
-(3 rows)
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-
-## Step 3. Create the `maxroach` user and `bank` database
-
-{% include {{page.version.version}}/app/insecure/create-maxroach-user-and-bank-database.md %}
-
-## Step 4. Run the Java code
-
-The code below uses jOOQ to map Java methods to SQL operations. It performs the following steps, some of which correspond to method calls of the `Sample` class.
-
-1. Inputs the `db.sql` file to the database. `db.sql` includes SQL statements that create an `accounts` table in the `bank` database.
-2. Inserts rows into the `accounts` table using `session.save(new Account(int id, int balance))` (see `Sample.addAccounts()`).
-3. Transfers money from one account to another, printing out account balances before and after the transfer (see `transferFunds(long fromId, long toId, long amount)`).
-4. Prints out account balances before and after the transfer (see `Sample.getAccountBalance(long id)`).
-
-In addition, the code shows a pattern for automatically handling [transaction retries](transactions.html#client-side-intervention-example) by wrapping transactions in a higher-order function `Sample.runTransaction()`. It also includes a method for testing the retry handling logic (`Sample.forceRetryLogic()`), which will be run if you set the `FORCE_RETRY` variable to `true`.
-
-To run it:
-
-1. Download and unzip [jooq-basic-sample.zip](https://github.com/cockroachdb/docs/raw/master/_includes/{{ page.version.version }}/app/insecure/jooq-basic-sample/jooq-basic-sample.zip).
-2. Compile and run the code using Maven:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cd jooq-basic-sample
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mvn compile
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mvn exec:java -Dexec.mainClass=com.cockroachlabs.Sample
-    ~~~
-
-Here are the contents of [`Sample.java`](https://raw.githubusercontent.com/cockroachdb/docs/master/_includes/{{page.version.version}}/app/insecure/jooq-basic-sample/Sample.java), the Java file containing the main `Sample` class:
-
-{% include copy-clipboard.html %}
-~~~ java
-{% include {{page.version.version}}/app/insecure/jooq-basic-sample/Sample.java %}
-~~~
-
-Toward the end of the output, you should see:
-
-~~~
-APP: BEGIN;
-APP: addAccounts() --> 1
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(1) --> 1000
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(2) --> 250
-APP: COMMIT;
-APP: getAccountBalance(1) --> 1000
-APP: getAccountBalance(2) --> 250
-APP: BEGIN;
-APP: transferFunds(1, 2, 100) --> 100
-APP: COMMIT;
-APP: transferFunds(1, 2, 100) --> 100
-APP: BEGIN;
-APP: getAccountBalance(1) --> 900
-APP: COMMIT;
-APP: BEGIN;
-APP: getAccountBalance(2) --> 350
-APP: COMMIT;
-APP: getAccountBalance(1) --> 900
-APP: getAccountBalance(2) --> 350
-~~~
-
-To verify that the account balances were updated successfully, start the [built-in SQL client](cockroach-sql.html):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure
-~~~
-
-To check the account balances, issue the following statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT id, balance FROM accounts;
-~~~
-
-~~~
-  id | balance
-+----+---------+
-   1 |     900
-   2 |     350
-   3 |  314159
-(3 rows)
-~~~
-
-</section>
-
-
-## What's next?
-
-Read more about using [jOOQ](https://www.jooq.org/), or check out a more realistic implementation of jOOQ with CockroachDB in our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-java-app-with-cockroachdb.md b/src/current/v20.2/build-a-java-app-with-cockroachdb.md
deleted file mode 100644
index 63062699022..00000000000
--- a/src/current/v20.2/build-a-java-app-with-cockroachdb.md
+++ /dev/null
@@ -1,332 +0,0 @@
----
-title: Build a Simple CRUD Java App with CockroachDB and JDBC
-summary: Learn how to use CockroachDB from a simple Java application with the JDBC driver.
-toc: true
-twitter: false
-referral_id: docs_hello_world_java_jdbc
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-java-app-with-cockroachdb.html"><button class="filter-button current">Use <strong>JDBC</strong></button></a>
-    <a href="build-a-java-app-with-cockroachdb-hibernate.html"><button class="filter-button">Use <strong>Hibernate</strong></button></a>
-    <a href="build-a-java-app-with-cockroachdb-jooq.html"><button class="filter-button">Use <strong>jOOQ</strong></button></a>
-    <a href="build-a-spring-app-with-cockroachdb-mybatis.html"><button style="width: 25%" class="filter-button">Use <strong>MyBatis-Spring</strong></button></a>
-</div>
-
-This tutorial shows you how to build a simple CRUD Java application with CockroachDB and the Java JDBC driver.
-
-{% include {{page.version.version}}/app/java-version-note.md %}
-
-{{site.data.alerts.callout_success}}
-For a sample app and tutorial that uses Spring Data JDBC and CockroachDB, see [Build a Spring App with CockroachDB and JDBC](build-a-spring-app-with-cockroachdb-jdbc.html).
-{{site.data.alerts.end}}
-
-## Step 1. Start CockroachDB
-
-{% include {{ page.version.version }}/app/sample-setup.md %}
-
-## Step 2. Get the code
-
-Clone the code's GitHub repo:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ git clone https://github.com/cockroachlabs/example-app-java-jdbc/
-~~~
-
-<div class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-Check out the `cockroachcloud` branch:
-
-{% include_cached copy-clipboard.html %}
-~~~shell
-git checkout cockroachcloud
-~~~
-
-</div>
-
-The project has the following directory structure:
-
-~~~
-├── README.md
-├── app
-│   ├── build.gradle
-│   └── src
-│       └── main
-│           ├── java
-│           │   └── com
-│           │       └── cockroachlabs
-│           │           └── BasicExample.java
-│           └── resources
-│               └── dbinit.sql
-├── gradle
-│   └── wrapper
-│       ├── gradle-wrapper.jar
-│       └── gradle-wrapper.properties
-├── gradlew
-├── gradlew.bat
-└── settings.gradle
-~~~
-
-The `dbinit.sql` file initializes the database schema that the application uses:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-java-jdbc/master/app/src/main/resources/dbinit.sql %}
-~~~
-
-The `BasicExample.java` file contains the code for `INSERT`, `SELECT`, and `UPDATE` SQL operations. The file also contains the `main` method of the program.
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-java-jdbc/cockroachcloud/app/src/main/java/com/cockroachlabs/BasicExample.java %}
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-java-jdbc/master/app/src/main/java/com/cockroachlabs/BasicExample.java %}
-~~~
-
-</section>
-
-The sample app uses JDBC and the [Data Access Object (DAO)](https://en.wikipedia.org/wiki/Data_access_object) pattern to map Java methods to SQL operations. It consists of two classes:
-
-1. `BasicExample`, which is where the application logic lives.
-2. `BasicExampleDAO`, which is used by the application to access the data store (in this case CockroachDB). This class also includes a helper function (`runSql`) that runs SQL statements inside a transaction, [retrying statements](transactions.html#transaction-retries) as needed.
-
-The `main` method of the app performs the following steps which roughly correspond to method calls in the `BasicExample` class.
-
-| Step                                                                                                       | Method                                                                                          |
-|------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------|
-| 1. Insert account data using a `Map` that corresponds to the input to `INSERT` on the backend              | `BasicExampleDAO.updateAccounts(Map balance)`                                                   |
-| 2. Transfer money from one account to another, printing out account balances before and after the transfer | `BasicExampleDAO.transferFunds(UUID from, UUID to, BigDecimal amount)`                                   |
-| 3. Insert random account data using JDBC's bulk insertion support                                          | `BasicExampleDAO.bulkInsertRandomAccountData()`                                                 |
-| 4. Print out some account data                                                                             | `BasicExampleDAO.readAccounts(int limit)`                                                       |
-
-It does all of the above using the practices we recommend for using JDBC with CockroachDB, which are listed in the [Recommended Practices](#recommended-practices) section below.
-
-## Step 3. Initialize the database
-
-To initialize the example database, use the [`cockroach sql`](cockroach-sql.html) command to execute the SQL statements in the `dbinit.sql` file:
-
-<div class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-cat app/src/main/resources/dbinit.sql | cockroach sql --url "<connection-string>"
-~~~
-
-Where `<connection-string>` is the connection string you obtained earlier from the CockroachDB {{ site.data.products.cloud }} Console.
-
-</div>
-
-<div class="filter-content" markdown="1" data-scope="local">
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-cat app/src/main/resources/dbinit.sql | cockroach sql --url "postgresql://root@localhost:26257?sslmode=disable"
-~~~
-
-{{site.data.alerts.callout_info}}
-`postgresql://root@localhost:26257?sslmode=disable` is the `sql` connection string you obtained earlier from the `cockroach` welcome text.
-{{site.data.alerts.end}}
-
-</div>
-
-The SQL statements in the initialization file should execute:
-
-~~~
-SET
-
-Time: 1ms
-
-SET
-
-Time: 2ms
-
-DROP DATABASE
-
-Time: 1ms
-
-CREATE DATABASE
-
-Time: 2ms
-
-SET
-
-Time: 10ms
-
-CREATE TABLE
-
-Time: 4ms
-~~~
-
-## Step 4. Run the code
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-### Update the connection parameters
-
-In a text editor modify `app/src/main/java/com/cockroachlabs/BasicExample.java` with the settings to connect to the cluster:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-ds.setServerNames(new String[]{"{globalhost}"});
-ds.setDatabaseName("{cluster_name}.bank");
-ds.setUser("{username}");
-ds.setPassword("{password}");
-ds.setSslRootCert(System.getenv("{path to the CA certificate}"));
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-{{site.data.alerts.callout_success}}
-For guidance on connection pooling, with an example using JDBC and [HikariCP](https://github.com/brettwooldridge/HikariCP), see [Connection Pooling](connection-pooling.html).
-{{site.data.alerts.end}}
-
-</section>
-
-Compile and run the code:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-./gradlew run
-~~~
-
-The output will look like the following:
-
-~~~
-com.cockroachlabs.BasicExampleDAO.updateAccounts:
-    'INSERT INTO accounts (id, balance) VALUES ('b5679853-b968-4206-91ec-68945fa3e716', 250)'
-
-com.cockroachlabs.BasicExampleDAO.updateAccounts:
-    'INSERT INTO accounts (id, balance) VALUES ('d1c41041-6589-4b06-8d7c-b9d6d901727e', 1000)'
-BasicExampleDAO.updateAccounts:
-    => 2 total updated accounts
-main:
-    => Account balances at time '15:09:08.902':
-    ID 1 => $1000
-    ID 2 => $250
-
-com.cockroachlabs.BasicExampleDAO.transferFunds:
-    'UPSERT INTO accounts (id, balance) VALUES('d99e6bb5-ecd1-48e5-b6b6-47fc9a4bc752', ((SELECT balance FROM accounts WHERE id = 'd99e6bb5-ecd1-48e5-b6b6-47fc9a4bc752') - 100)),('6f0c1f94-509a-47e3-a9ab-6a9e3965945c', ((SELECT balance FROM accounts WHERE id = '6f0c1f94-509a-47e3-a9ab-6a9e3965945c') + 100))'
-BasicExampleDAO.transferFunds:
-    => $100 transferred between accounts d99e6bb5-ecd1-48e5-b6b6-47fc9a4bc752 and 6f0c1f94-509a-47e3-a9ab-6a9e3965945c, 2 rows updated
-main:
-    => Account balances at time '15:09:09.142':
-    ID 1 => $1000
-    ID 2 => $250
-
-BasicExampleDAO.bulkInsertRandomAccountData:
-    'INSERT INTO accounts (id, balance) VALUES ('b70a0c48-fdf4-42ea-b07a-2fea83d77c7d', '287108674'::numeric)'
-    => 128 row(s) updated in this batch
-
-BasicExampleDAO.bulkInsertRandomAccountData:
-    'INSERT INTO accounts (id, balance) VALUES ('75a5f894-532a-464d-b37e-a4b9ec1c1db6', '189904311'::numeric)'
-    => 128 row(s) updated in this batch
-
-BasicExampleDAO.bulkInsertRandomAccountData:
-    'INSERT INTO accounts (id, balance) VALUES ('0803968f-ba07-4ece-82d5-24d4da9fdee9', '832474731'::numeric)'
-    => 128 row(s) updated in this batch
-
-BasicExampleDAO.bulkInsertRandomAccountData:
-    'INSERT INTO accounts (id, balance) VALUES ('082e634d-4930-41eb-9839-298632a5530a', '665918272'::numeric)'
-    => 128 row(s) updated in this batch
-
-BasicExampleDAO.bulkInsertRandomAccountData:
-    => finished, 512 total rows inserted
-
-com.cockroachlabs.BasicExampleDAO.readAccounts:
-    'SELECT id, balance FROM accounts LIMIT 10'
-    balance  =>  424934060
-    balance  =>   62220740
-    balance  =>  454671673
-    balance  =>  556061618
-    balance  =>  450164589
-    balance  =>  996867752
-    balance  =>   55869978
-    balance  =>  747446662
-    balance  =>  175832969
-    balance  =>  181799597
-
-BUILD SUCCESSFUL in 8s
-3 actionable tasks: 3 executed
-~~~
-
-## Recommended Practices
-
-### Generate PKCS8 keys for user authentication
-
-{% include {{page.version.version}}/app/pkcs8-gen.md %}
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-{% include cockroachcloud/cc-no-user-certs.md %}
-
-</section>
-
-### Use `IMPORT` to read in large data sets
-
-If you are trying to get a large data set into CockroachDB all at once (a bulk import), avoid writing client-side code altogether and use the [`IMPORT`](import.html) statement instead. It is much faster and more efficient than making a series of [`INSERT`s](insert.html) and [`UPDATE`s](update.html). It bypasses the [SQL layer](architecture/sql-layer.html) altogether and writes directly to the [storage layer](architecture/storage-layer.html) of the database.
-
-For more information about importing data from Postgres, see [Migrate from Postgres](migrate-from-postgres.html).
-
-For more information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Use `reWriteBatchedInserts` for increased speed
-
-We strongly recommend setting `reWriteBatchedInserts=true`; we have seen 2-3x performance improvements with it enabled. From [the JDBC connection parameters documentation](https://jdbc.postgresql.org/documentation/use/#connection-parameters):
-
-> This will change batch inserts from `insert into foo (col1, col2, col3) values (1,2,3)` into `insert into foo (col1, col2, col3) values (1,2,3), (4,5,6)` this provides 2-3x performance improvement
-
-### Use a batch size of 128
-
-PGJDBC's batching support only works with [powers of two](https://github.com/pgjdbc/pgjdbc/blob/7b52b0c9e5b9aa9a9c655bb68f23bf4ec57fd51c/pgjdbc/src/main/java/org/postgresql/jdbc/PgPreparedStatement.java#L1597), and will split batches of other sizes up into multiple sub-batches. This means that a batch of size 128 can be 6x faster than a batch of size 250.
-
-The code snippet below shows a pattern for using a batch size of 128, and is taken from the longer example above (specifically, the `BasicExampleDAO.bulkInsertRandomAccountData()` method).
-
-Specifically, it does the following:
-
-1. Turn off auto-commit so you can manage the transaction lifecycle and thus the size of the batch inserts.
-2. Given an overall update size of 500 rows (for example), split it into batches of size 128 and execute each batch in turn.
-3. Finally, commit the batches of statements you've just executed.
-
-~~~ java
-int BATCH_SIZE = 128;
-connection.setAutoCommit(false);
-
-try (PreparedStatement pstmt = connection.prepareStatement("INSERT INTO accounts (id, balance) VALUES (?, ?)")) {
-    for (int i=0; i<=(500/BATCH_SIZE);i++) {
-        for (int j=0; j<BATCH_SIZE; j++) {
-            int id = random.nextInt(1000000000);
-            BigDecimal balance = BigDecimal.valueOf(random.nextInt(1000000000));
-            pstmt.setInt(1, id);
-            pstmt.setBigDecimal(2, balance);
-            pstmt.addBatch();
-        }
-        int[] count = pstmt.executeBatch();
-        System.out.printf("    => %s row(s) updated in this batch\n", count.length); // Verifying 128 rows in the batch
-    }
-    connection.commit();
-}
-~~~
-
-### Retrieve large data sets in chunks using cursors
-
-CockroachDB now supports the Postgres wire-protocol cursors for implicit transactions and explicit transactions executed to completion. This means the [PGJDBC driver](https://jdbc.postgresql.org) can use this protocol to stream queries with large result sets. This is much faster than [paginating through results in SQL using `LIMIT .. OFFSET`](pagination.html).
-
-For instructions showing how to use cursors in your Java code, see [Getting results based on a cursor](https://jdbc.postgresql.org/documentation/query/#getting-results-based-on-a-cursor) from the PGJDBC documentation.
-
-Note that interleaved execution (partial execution of multiple statements within the same connection and transaction) is not supported when [`Statement.setFetchSize()`](https://docs.oracle.com/javase/8/docs/api/java/sql/Statement.html#setFetchSize-int-) is used.
-
-## What's next?
-
-Read more about using the [Java JDBC driver](https://jdbc.postgresql.org/).
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-nodejs-app-with-cockroachdb-sequelize.md b/src/current/v20.2/build-a-nodejs-app-with-cockroachdb-sequelize.md
deleted file mode 100644
index d1c84faf7d2..00000000000
--- a/src/current/v20.2/build-a-nodejs-app-with-cockroachdb-sequelize.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: Build a Node.js App with CockroachDB and Sequelize
-summary: Learn how to use CockroachDB from a simple Node.js application with the Sequelize ORM.
-toc: true
-twitter: false
-referral_id: docs_hello_world_nodejs_sequelize
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-nodejs-app-with-cockroachdb.html"><button class="filter-button">Use <strong>pg</strong></button></a>
-    <a href="build-a-nodejs-app-with-cockroachdb-sequelize.html"><button class="filter-button current">Use <strong>Sequelize</strong></button></a>
-    <a href="build-a-typescript-app-with-cockroachdb.html"><button class="filter-button">Use <strong>TypeORM</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Node.js application with CockroachDB and the Sequelize ORM.
-
-We have tested the [Sequelize ORM](https://sequelize.org/) enough to claim **beta-level** support. If you encounter problems, please [open an issue](https://github.com/cockroachdb/cockroach/issues/new) with details to help us make progress toward full support.
-
-{{site.data.alerts.callout_success}}
-For a more realistic use of Sequelize with CockroachDB, see our [`examples-orms`](https://github.com/cockroachdb/examples-orms)repository.
-{{site.data.alerts.end}}
-
-## Step 1. Start CockroachDB
-
-{% include {{page.version.version}}/app/start-cockroachdb.md %}
-
-## Step 2. Create a database
-
-{% include {{page.version.version}}/app/create-a-database.md %}
-
-## Step 3. Install the Sequelize ORM
-
-To install Sequelize, as well as a [CockroachDB Node.js package](https://github.com/cockroachdb/sequelize-cockroachdb) that accounts for some minor differences between CockroachDB and PostgreSQL, run the following command:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ npm install sequelize sequelize-cockroachdb
-~~~
-
-## Step 4. Get the code
-
-<a href="https://raw.githubusercontent.com/cockroachlabs/example-app-node-sequelize/main/app.js">Download the sample code directly</a>, or clone [the code's GitHub repository](https://github.com/cockroachlabs/example-app-node-sequelize).
-
-## Step 5. Update the connection parameters
-
-Open `app.js`, and edit the connection configuration parameters:
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-- Replace the value for `username` with the user you created earlier.
-- Replace the value for `password` with the password you created for your user.
-- Replace the value for `port` with the port to your cluster.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-- At the top of the file, uncomment the `const fs = require('fs');` line.
-
-    This line imports the `fs` Node module, which enables you to read in the CA cert that you downloaded from the CockroachDB {{ site.data.products.cloud }} Console.
-- Replace the value for `username` with the user you created earlier.
-- Replace the value for `password` with the password you created for your user.
-- Replace the value for `host` with the name of the CockroachDB {{ site.data.products.serverless }} host (e.g., `host: 'free-tier.gcp-us-central1.cockroachlabs.cloud'`).
-- Replace the value for `port` with the port to your cluster.
-- Replace the value for `database` with the database that you created earlier, suffixed with the name of the cluster (e.g., `database: '{cluster_name}.bank'`).
-- Remove the `rejectUnauthorized` key-value pair.
-- Uncomment the `ca` key-value pair, and edit the `fs.readFileSync('certs/ca.crt').toString()` call to use the path to the `cc-ca.crt` file that you downloaded from the CockroachDB {{ site.data.products.cloud }} Console.
-
-</section>
-
-## Step 6. Run the code
-
-The following code uses the [Sequelize](https://sequelize.org/) ORM to map Node.js-specific objects to SQL operations. Specifically, `Account.sync({force: true})` creates an `accounts` table based on the Account model (or drops and recreates the table if it already exists), `Account.bulkCreate([...])` inserts rows into the table, and `Account.findAll()` selects from the table so that balances can be printed.
-
-{% include_cached copy-clipboard.html %}
-~~~ js
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-node-sequelize/main/app.js %}
-~~~
-
-To run the code:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ node app.js
-~~~
-
-The output should be:
-
-~~~ shell
-1 1000
-2 250
-~~~
-
-## What's next?
-
-Read more about using the [Sequelize ORM](https://sequelize.org/), or check out a more realistic implementation of Sequelize with CockroachDB in our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-
-{% include {{ page.version.version }}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-nodejs-app-with-cockroachdb.md b/src/current/v20.2/build-a-nodejs-app-with-cockroachdb.md
deleted file mode 100644
index f1e93d6c7a4..00000000000
--- a/src/current/v20.2/build-a-nodejs-app-with-cockroachdb.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-title: Build a Simple CRUD Node.js App with CockroachDB and the node-postgres Driver
-summary: Learn how to use CockroachDB from a simple CRUD application that uses the node-postgres driver.
-toc: true
-twitter: false
-referral_id: docs_hello_world_nodejs_pg
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-nodejs-app-with-cockroachdb.html"><button class="filter-button current">Use <strong>node-postgres</strong></button></a>
-    <a href="build-a-nodejs-app-with-cockroachdb-sequelize.html"><button class="filter-button">Use <strong>Sequelize</strong></button></a>
-    <a href="build-a-typescript-app-with-cockroachdb.html"><button class="filter-button">Use <strong>TypeORM</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Node.js application with CockroachDB and the [node-postgres driver](https://node-postgres.com/).
-
-## Step 1. Start CockroachDB
-
-{% include {{ page.version.version }}/app/sample-setup.md %}
-
-## Step 2. Get the code
-
-Clone the code's GitHub repo:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ git clone https://github.com/cockroachlabs/example-app-node-postgres
-~~~
-
-The project has the following directory structure:
-
-~~~
-├── README.md
-├── app.js
-├── dbinit.sql
-└── package.json
-~~~
-
-The `dbinit.sql` file initializes the database schema that the application uses:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-node-postgres/main/dbinit.sql %}
-~~~
-
-The `app.js` file contains the code for `INSERT`, `SELECT`, `UPDATE`, and `DELETE` SQL operations:
-
-{% include_cached copy-clipboard.html %}
-~~~ js
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-node-postgres/main/app.js %}
-~~~
-
-All of the database operations are wrapped in a helper function named `retryTxn`. This function attempts to commit statements in the context of an explicit transaction. If a [retry error](transaction-retry-error-reference.html) is thrown, the wrapper will retry committing the transaction, with [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff), until the maximum number of retries is reached (by default, 15).
-
-## Step 3. Initialize the database
-
-{% include {{ page.version.version }}/app/init-bank-sample.md %}
-
-## Step 4. Run the code
-
-1. Install the app requirements:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ npm install
-    ~~~
-
-1. Run the app:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ node app.js
-    ~~~
-
-    The program will prompt you for a connection string to the database:
-
-    ~~~
-    prompt: connectionString:
-    ~~~
-
-1. Enter the connection string to your running cluster.
-
-    <section class="filter-content" markdown="1" data-scope="local">
-
-    {{site.data.alerts.callout_success}}
-    `postgresql://root@localhost:26257?sslmode=disable` should be the `sql` connection URL provided in the `cockroach` welcome text.
-    {{site.data.alerts.end}}
-
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-    {{site.data.alerts.callout_success}}
-    Use the connection string provided in the **Connection info** window of the CockroachDB {{ site.data.products.cloud }} Console.
-    {{site.data.alerts.end}}
-
-    {{site.data.alerts.callout_info}}
-    You need to provide a SQL user password in order to securely connect to a CockroachDB {{ site.data.products.cloud }} cluster. The connection string should have a placeholder for the password (`<ENTER-PASSWORD>`).
-    {{site.data.alerts.end}}
-
-    </section>
-
-After entering the connection string, the program will execute.
-
-The output should look like this:
-
-~~~
-Initializing accounts table...
-New account balances:
-{ id: 'aa0e9b22-0c23-469b-a9e1-b2ace079f44c', balance: '1000' }
-{ id: 'bf8b96da-2c38-4d55-89a0-b2b6ed63ff9e', balance: '0' }
-{ id: 'e43d76d6-388e-4ee6-8b73-a063a63a2138', balance: '250' }
-Transferring funds...
-New account balances:
-{ id: 'aa0e9b22-0c23-469b-a9e1-b2ace079f44c', balance: '900' }
-{ id: 'bf8b96da-2c38-4d55-89a0-b2b6ed63ff9e', balance: '0' }
-{ id: 'e43d76d6-388e-4ee6-8b73-a063a63a2138', balance: '350' }
-Deleting a row...
-New account balances:
-{ id: 'aa0e9b22-0c23-469b-a9e1-b2ace079f44c', balance: '900' }
-{ id: 'e43d76d6-388e-4ee6-8b73-a063a63a2138', balance: '350' }
-~~~
-
-## What's next?
-
-Read more about using the [node-postgres driver](https://www.npmjs.com/package/pg).
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-python-app-with-cockroachdb-django.md b/src/current/v20.2/build-a-python-app-with-cockroachdb-django.md
deleted file mode 100644
index 64e22ba054f..00000000000
--- a/src/current/v20.2/build-a-python-app-with-cockroachdb-django.md
+++ /dev/null
@@ -1,325 +0,0 @@
----
-title: Build a Python App with CockroachDB and Django
-summary: Learn how to use CockroachDB from a simple Django application.
-toc: true
-twitter: false
-referral_id: docs_hello_world_python_django
----
-
-<div class="filters clearfix">
-    <a href="build-a-python-app-with-cockroachdb.html"><button class="filter-button page-level"><strong>psycopg2</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-sqlalchemy.html"><button class="filter-button page-level"><strong>SQLAlchemy</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-django.html"><button class="filter-button page-level current"><strong>Django</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-pony.html"><button class="filter-button page-level"><strong>PonyORM</strong></button></a>
-    <a href="http://docs.peewee-orm.com/en/latest/peewee/playhouse.html#cockroach-database"><button class="filter-button page-level"><strong>peewee</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Python application with CockroachDB and the [Django](https://www.djangoproject.com/) framework.
-
-CockroachDB supports Django versions 3.1+.
-
-{{site.data.alerts.callout_info}}
-The example code and instructions on this page use Python 3.9 and Django 3.1.
-{{site.data.alerts.end}}
-
-## Step 1. Start CockroachDB
-
-{% include {{page.version.version}}/app/start-cockroachdb.md %}
-
-## Step 2. Create a database
-
-{% include {{page.version.version}}/app/create-a-database.md %}
-
-## Step 3. Get the sample code
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-Clone the code's GitHub repo:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ git clone https://github.com/cockroachlabs/example-app-python-django/
-~~~
-
-The project directory structure should look like this:
-
-~~~
-├── Dockerfile
-├── README.md
-├── cockroach_example
-│   ├── cockroach_example
-│   │   ├── __init__.py
-│   │   ├── asgi.py
-│   │   ├── migrations
-│   │   │   ├── 0001_initial.py
-│   │   │   └── __init__.py
-│   │   ├── models.py
-│   │   ├── settings.py
-│   │   ├── urls.py
-│   │   ├── views.py
-│   │   └── wsgi.py
-│   └── manage.py
-└── requirements.txt
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-1. Clone the code's GitHub repo:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ git clone https://github.com/cockroachlabs/example-app-python-django/
-    ~~~
-
-1. Create a new folder named `certs` at the top level of the `example-app-python-django` project, and then copy the root certificate that you downloaded for your cluster to the new folder.
-
-    The project directory structure should look like this:
-
-    ~~~
-    ├── Dockerfile
-    ├── README.md
-    ├── certs
-    │   └── root.crt
-    ├── cockroach_example
-    │   ├── cockroach_example
-    │   │   ├── __init__.py
-    │   │   ├── asgi.py
-    │   │   ├── migrations
-    │   │   │   ├── 0001_initial.py
-    │   │   │   └── __init__.py
-    │   │   ├── models.py
-    │   │   ├── settings.py
-    │   │   ├── urls.py
-    │   │   ├── views.py
-    │   │   └── wsgi.py
-    │   └── manage.py
-    └── requirements.txt
-    ~~~
-
-</section>
-
-## Step 4. Install the application requirements
-
-To use CockroachDB with Django, the following modules are required:
-
-- [`django`](https://docs.djangoproject.com/en/3.1/topics/install/)
-- [`psycopg2`](https://pypi.org/project/psycopg2/) (recommended for production environments) or [`psycopg2-binary`](https://pypi.org/project/psycopg2-binary/) (recommended for development and testing).
-- [`django-cockroachdb`](https://github.com/cockroachdb/django-cockroachdb)
-
-{{site.data.alerts.callout_info}}
-The major version of `django-cockroachdb` must correspond to the major version of `django`. The minor release numbers do not need to match.
-{{site.data.alerts.end}}
-
-The `requirements.txt` file at the top level of the `example-app-python-django` project directory contains a list of the requirements needed to run this application:
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-python-django/master/requirements.txt %}
-~~~
-
-{{site.data.alerts.callout_info}}
-The `requirements.txt` file also lists the `dj_database_url` module, which is not a strict requirement. The sample app uses this module to configure the database connection from a connection URL.
-{{site.data.alerts.end}}
-
-1. At the top level of the app's project directory, create and then activate a virtual environment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ virtualenv env
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ source env/bin/activate
-    ~~~
-
-1. Install the modules listed in `requirements.txt` to the virtual environment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ pip install -r requirements.txt
-    ~~~
-
-## Step 5. Configure the database connection
-
-The `cockroach_example/cockroach_example/settings.py` file defines database connection information for the application, in [the `DATABASES` dictionary](https://docs.djangoproject.com/en/3.2/ref/settings/#databases):
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-DATABASES = {}
-DATABASES['default'] = dj_database_url.config(default=os.path.expandvars(
-    os.environ['DATABASE_URL']), engine='django_cockroachdb')
-~~~
-
-Note that, rather than using [discrete connection parameters](connection-parameters.html), the sample `settings.py` passes a single variable (the `DATABASE_URL` environment variable) to the `dj_database_url` module.
-
-Set the `DATABASE_URL` environment variable to the connection string:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ export DATABASE_URL="<connection_string>"
-~~~
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-Where `<connection_string>` is the `sql` connection URL provided in the cluster's welcome text.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-Where `<connection_string>` is the connection string provided in the **Connection info** window of the CockroachDB {{ site.data.products.cloud }} Console, but with the root certificate located in the local `certs` directory.
-
-Note that you also need to provide a SQL user password in order to securely connect to a CockroachDB {{ site.data.products.cloud }} cluster. The connection string should have a placeholder for the password (`<ENTER-PASSWORD>`).
-
-</section>
-
-## Step 6. Build out the application
-
-After you have configured the app's database connection, you can start building out the application.
-
-### Models
-
-Start by building some [models](https://docs.djangoproject.com/en/3.1/topics/db/models/), defined in a file called `models.py`. You can copy the sample code below and paste it into a new file, or you can <a href="https://raw.githubusercontent.com/cockroachlabs/example-app-python-django/master/cockroach_example/cockroach_example/models.py" download>download the file directly</a>.
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-python-django/master/cockroach_example/cockroach_example/models.py %}
-~~~
-
-In this file, we define some simple classes that map to the tables in the example database `bank`.
-
-### Views
-
-Next, build out some [class-based views](https://docs.djangoproject.com/en/3.1/topics/class-based-views/) for the application in a file called `views.py`. You can copy the sample code below and paste it into a new file, or you can <a href="https://raw.githubusercontent.com/cockroachlabs/example-app-python-django/master/cockroach_example/cockroach_example/views.py" download>download the file directly</a>.
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-python-django/master/cockroach_example/cockroach_example/views.py %}
-~~~
-
-This file defines the application's views as classes. Each view class corresponds to one of the table classes defined in `models.py`. The methods of these classes define read and write transactions on the tables in the database.
-
-Importantly, the file defines a [transaction retry loop](transactions.html#transaction-retries) in the decorator function `retry_on_exception()`. This function decorates each view method, ensuring that transaction ordering guarantees meet the ANSI [SERIALIZABLE](https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable) isolation level. For more information about how transactions (and retries) work, see [Transactions](transactions.html).
-
-### URL routes
-
-Lastly, define some [URL routes](https://docs.djangoproject.com/en/3.1/topics/http/urls/) in a file called `urls.py`. You can copy the sample code below and paste it into the existing `urls.py` file, or you can <a href="https://raw.githubusercontent.com/cockroachlabs/example-app-python-django/master/cockroach_example/cockroach_example/urls.py" download>download the file directly</a> and replace the existing one.
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-python-django/master/cockroach_example/cockroach_example/urls.py %}
-~~~
-
-## Step 7. Initialize the database
-
-1. In the top `cockroach_example` directory, use the [`manage.py` script](https://docs.djangoproject.com/en/3.1/ref/django-admin/) to create [Django migrations](https://docs.djangoproject.com/en/3.1/topics/migrations/) that initialize the database for the application:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ python3 manage.py makemigrations cockroach_example
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ python3 manage.py migrate
-    ~~~
-
-    This initializes the `bank` database with the tables defined in `models.py`, in addition to some other tables for the admin functionality included with Django's starter application.
-
-1. To verify that the migration succeeded, open the terminal with the SQL shell to the temporary CockroachDB cluster, and issue the following statements:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > USE bank;
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TABLES;
-    ~~~
-
-    ~~~
-      schema_name |            table_name            | type  | estimated_row_count
-    --------------+----------------------------------+-------+----------------------
-      public      | auth_group                       | table |                   0
-      public      | auth_group_permissions           | table |                   0
-      public      | auth_permission                  | table |                  36
-      public      | auth_user                        | table |                   0
-      public      | auth_user_groups                 | table |                   0
-      public      | auth_user_user_permissions       | table |                   0
-      public      | cockroach_example_customers      | table |                   0
-      public      | cockroach_example_orders         | table |                   0
-      public      | cockroach_example_orders_product | table |                   0
-      public      | cockroach_example_products       | table |                   0
-      public      | django_admin_log                 | table |                   0
-      public      | django_content_type              | table |                   9
-      public      | django_migrations                | table |                   1
-      public      | django_session                   | table |                   0
-    (14 rows)
-    ~~~
-
-## Step 8. Run the app
-
-1. In a different terminal, navigate to the top of the `cockroach_example` directory, and start the app:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ python3 manage.py runserver 0.0.0.0:8000
-    ~~~
-
-    The output should look like this:
-
-    ~~~
-    ...
-    Starting development server at http://0.0.0.0:8000/
-    Quit the server with CONTROL-C.
-    ~~~
-
-    To perform simple reads and writes to the database, you can send HTTP requests to the application server listening at `http://0.0.0.0:8000/`.
-
-1. In a new terminal, use `curl` to send a POST request to the application:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ curl --header "Content-Type: application/json" \
-    --request POST \
-    --data '{"name":"Carl"}' http://0.0.0.0:8000/customer/
-    ~~~
-
-    This request inserts a new row into the `cockroach_example_customers` table.
-
-1. Send a GET request to read from the `cockroach_example_customers` table:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ curl http://0.0.0.0:8000/customer/
-    ~~~
-
-    ~~~
-    [{"id": "bb7d6c4d-efb3-45f8-b790-9911aae7d8b2", "name": "Carl"}]
-    ~~~
-
-    You can also query the table directly in the [SQL shell](cockroach-sql.html) to see the changes:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.cockroach_example_customers;
-    ~~~
-
-    ~~~
-                       id                  | name
-    ---------------------------------------+-------
-      bb7d6c4d-efb3-45f8-b790-9911aae7d8b2 | Carl
-    (1 row)
-    ~~~
-
-1. Enter **Ctrl+C** to stop the application.
-
-## What's next?
-
-Read more about writing a [Django app](https://docs.djangoproject.com/en/3.1/intro/tutorial01/).
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-python-app-with-cockroachdb-sqlalchemy.md b/src/current/v20.2/build-a-python-app-with-cockroachdb-sqlalchemy.md
deleted file mode 100644
index ba3b4a0096b..00000000000
--- a/src/current/v20.2/build-a-python-app-with-cockroachdb-sqlalchemy.md
+++ /dev/null
@@ -1,236 +0,0 @@
----
-title: Build a Simple CRUD Python App with CockroachDB and SQLAlchemy
-summary: Learn how to use CockroachDB from a simple Python application with SQLAlchemy.
-toc: true
-twitter: false
-referral_id: docs_hello_world_python_sqlalchemy
----
-
-<div class="filters clearfix">
-    <a href="build-a-python-app-with-cockroachdb.html"><button class="filter-button page-level"><strong>psycopg2</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-sqlalchemy.html"><button class="filter-button page-level current"><strong>SQLAlchemy</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-django.html"><button class="filter-button page-level"><strong>Django</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-pony.html"><button class="filter-button page-level"><strong>PonyORM</strong></button></a>
-    <a href="http://docs.peewee-orm.com/en/latest/peewee/playhouse.html#cockroach-database"><button class="filter-button page-level"><strong>peewee</strong></button></a>
-</div>
-
-{% include cockroach_u_pydev.md %}
-
-This tutorial shows you how build a simple CRUD Python application with CockroachDB and the [SQLAlchemy](https://docs.sqlalchemy.org/en/latest/) ORM.
-
-## Step 1. Start CockroachDB
-
-{% include {{ page.version.version }}/app/sample-setup.md %}
-
-## Step 2. Get the code
-
-Clone the code's GitHub repo:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ git clone https://github.com/cockroachlabs/example-app-python-sqlalchemy/
-~~~
-
-The project has the following directory structure:
-
-~~~
-├── README.md
-├── dbinit.sql
-├── main.py
-├── models.py
-└── requirements.txt
-~~~
-
-The `requirements.txt` file includes the required libraries to connect to CockroachDB with SQLAlchemy, including the [`sqlalchemy-cockroachdb` Python package](https://github.com/cockroachdb/sqlalchemy-cockroachdb), which accounts for some differences between CockroachDB and PostgreSQL:
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-python-sqlalchemy/master/requirements.txt %}
-~~~
-
-The `dbinit.sql` file initializes the database schema that the application uses:
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-python-sqlalchemy/master/dbinit.sql %}
-~~~
-
-The `models.py` uses SQLAlchemy to map the `Accounts` table to a Python object:
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-python-sqlalchemy/master/models.py %}
-~~~
-
-The `main.py` uses SQLAlchemy to map Python methods to SQL operations:
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-python-sqlalchemy/master/main.py %}
-~~~
-
-`main.py` also executes the `main` method of the program.
-
-## Step 3. Install the application requirements
-
-1. At the top level of the app's project directory, create and then activate a virtual environment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ virtualenv env
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ source env/bin/activate
-    ~~~
-
-1. Install the required modules to the virtual environment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ pip install -r requirements.txt
-    ~~~
-
-## Step 4. Initialize the database
-
-{% include {{ page.version.version }}/app/init-bank-sample.md %}
-
-## Step 5. Run the code
-
-1. Set the `DATABASE_URL` environment variable to the connection string for your cluster:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ export DATABASE_URL=<connection-string>
-    ~~~
-
-    <section class="filter-content" markdown="1" data-scope="local">
-
-    Where `<connection_string>` is the `sql` connection URL provided in the cluster's welcome text, but **with the `database` parameter set to `bank` instead of `defaultdb`.**
-
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-    Where `<connection_string>` is the connection string you obtained earlier from the CockroachDB {{ site.data.products.cloud }} Console, but **with the `database` parameter set to `bank` instead of `defaultdb`.**
-
-    </section>
-
-1. Run the app:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ python main.py
-    ~~~
-
-    The application will connect to CockroachDB, and then perform some simple row inserts, updates, and deletes.
-
-    The output should look something like the following:
-
-    ~~~
-    Creating new accounts...
-    Created new account with id 3a8b74c8-6a05-4247-9c60-24b46e3a88fd and balance 248835.
-    Created new account with id c3985926-5b77-4c6d-a73d-7c0d4b2a51e7 and balance 781972.
-    ...
-    Created new account with id 7b41386c-11d3-465e-a2a0-56e0dcd2e7db and balance 984387.
-    Random account balances:
-    Account 7ad14d02-217f-48ca-a53c-2c3a2528a0d9: 800795
-    Account 4040aeba-7194-4f29-b8e5-a27ed4c7a297: 149861
-    Transferring 400397 from account 7ad14d02-217f-48ca-a53c-2c3a2528a0d9 to account 4040aeba-7194-4f29-b8e5-a27ed4c7a297...
-    Transfer complete.
-    New balances:
-    Account 7ad14d02-217f-48ca-a53c-2c3a2528a0d9: 400398
-    Account 4040aeba-7194-4f29-b8e5-a27ed4c7a297: 550258
-    Deleting existing accounts...
-    Deleted account 41247e24-6210-4032-b622-c10b3c7222de.
-    Deleted account 502450e4-6daa-4ced-869c-4dff62dc52de.
-    Deleted account 6ff06ef0-423a-4b08-8b87-48af2221bc18.
-    Deleted account a1acb134-950c-4882-9ac7-6d6fbdaaaee1.
-    Deleted account e4f33c55-7230-4080-b5ac-5dde8a7ae41d.
-    ~~~
-
-    In a SQL shell connected to the cluster, you can verify that the rows were inserted, updated, and deleted successfully:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SELECT COUNT(*) FROM bank.accounts;
-    ~~~
-
-    ~~~
-      count
-    ---------
-         95
-    (1 row)
-    ~~~
-
-## Best practices
-
-### Use the `run_transaction` function
-
-We strongly recommend using the [`sqlalchemy_cockroachdb.run_transaction()`](https://github.com/cockroachdb/sqlalchemy-cockroachdb/blob/master/sqlalchemy_cockroachdb/transaction.py) function as shown in the code samples on this page. This abstracts the details of [transaction retries](transactions.html#transaction-retries) away from your application code. Transaction retries are more frequent in CockroachDB than in some other databases because we use [optimistic concurrency control](https://en.wikipedia.org/wiki/Optimistic_concurrency_control) rather than locking. Because of this, a CockroachDB transaction may have to be tried more than once before it can commit. This is part of how we ensure that our transaction ordering guarantees meet the ANSI [SERIALIZABLE](https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable) isolation level.
-
-In addition to the above, using `run_transaction` has the following benefits:
-
-- Because it must be passed a [sqlalchemy.orm.session.sessionmaker](https://docs.sqlalchemy.org/en/latest/orm/session_api.html#session-and-sessionmaker) object (*not* a [session][session]), it ensures that a new session is created exclusively for use by the callback, which protects you from accidentally reusing objects via any sessions created outside the transaction.
-- It abstracts away the [client-side transaction retry logic](transactions.html#client-side-intervention) from your application, which keeps your application code portable across different databases. For example, the sample code given on this page works identically when run against Postgres (modulo changes to the prefix and port number in the connection string).
-
-For more information about how transactions (and retries) work, see [Transactions](transactions.html).
-
-### Avoid mutations of session and/or transaction state inside `run_transaction()`
-
-In general, this is in line with the recommendations of the [SQLAlchemy FAQs](https://docs.sqlalchemy.org/en/latest/orm/session_basics.html#session-frequently-asked-questions), which state (with emphasis added by the original author) that
-
-> As a general rule, the application should manage the lifecycle of the session *externally* to functions that deal with specific data. This is a fundamental separation of concerns which keeps data-specific operations agnostic of the context in which they access and manipulate that data.
-
-and
-
-> Keep the lifecycle of the session (and usually the transaction) **separate and external**.
-
-In keeping with the above recommendations from the official docs, we **strongly recommend** avoiding any explicit mutations of the transaction state inside the callback passed to `run_transaction`, since that will lead to breakage. Specifically, do not make calls to the following functions from inside `run_transaction`:
-
-- [`sqlalchemy.orm.Session.commit()`](https://docs.sqlalchemy.org/en/latest/orm/session_api.html?highlight=commit#sqlalchemy.orm.session.Session.commit) (or other variants of `commit()`): This is not necessary because `cockroachdb.sqlalchemy.run_transaction` handles the savepoint/commit logic for you.
-- [`sqlalchemy.orm.Session.rollback()`](https://docs.sqlalchemy.org/en/latest/orm/session_api.html?highlight=rollback#sqlalchemy.orm.session.Session.rollback) (or other variants of `rollback()`): This is not necessary because `cockroachdb.sqlalchemy.run_transaction` handles the commit/rollback logic for you.
-- [`Session.flush()`][session.flush]: This will not work as expected with CockroachDB because CockroachDB does not support nested transactions, which are necessary for `Session.flush()` to work properly. If the call to `Session.flush()` encounters an error and aborts, it will try to rollback. This will not be allowed by the currently-executing CockroachDB transaction created by `run_transaction()`, and will result in an error message like the following: `sqlalchemy.orm.exc.DetachedInstanceError: Instance <FooModel at 0x12345678> is not bound to a Session; attribute refresh operation cannot proceed (Background on this error at: http://sqlalche.me/e/bhk3)`.
-
-### Break up large transactions into smaller units of work
-
-If you see an error message like `transaction is too large to complete; try splitting into pieces`, you are trying to commit too much data in a single transaction. As described in our [Cluster Settings](cluster-settings.html) docs, the size limit for transactions is defined by the `kv.transaction.max_intents_bytes` setting, which defaults to 256 KiB. Although this setting can be changed by an admin, we strongly recommend against it in most cases.
-
-Instead, we recommend breaking your transaction into smaller units of work (or "chunks"). A pattern that works for inserting large numbers of objects using `run_transaction` to handle retries automatically for you is shown below.
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% include {{page.version.version}}/app/python/sqlalchemy/sqlalchemy-large-txns.py %}
-~~~
-
-### Use `IMPORT` to read in large data sets
-
-If you are trying to get a large data set into CockroachDB all at once (a bulk import), avoid writing client-side code that uses an ORM and use the [`IMPORT`](import.html) statement instead. It is much faster and more efficient than making a series of [`INSERT`s](insert.html) and [`UPDATE`s](update.html) such as are generated by calls to [`session.bulk_save_objects()`](https://docs.sqlalchemy.org/en/latest/orm/session_api.html?highlight=bulk_save_object#sqlalchemy.orm.session.Session.bulk_save_objects).
-
-For more information about importing data from Postgres, see [Migrate from Postgres](migrate-from-postgres.html).
-
-For more information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Prefer the query builder
-
-In general, we recommend using the query-builder APIs of SQLAlchemy (e.g., [`Engine.execute()`](https://docs.sqlalchemy.org/en/latest/core/connections.html?highlight=execute#sqlalchemy.engine.Engine.execute)) in your application over the [Session][session]/ORM APIs if at all possible. That way, you know exactly what SQL is being generated and sent to CockroachDB, which has the following benefits:
-
-- It's easier to debug your SQL queries and make sure they are working as expected.
-- You can more easily tune SQL query performance by issuing different statements, creating and/or using different indexes, etc. For more information, see [SQL Performance Best Practices](performance-best-practices-overview.html).
-
-### Joins without foreign keys
-
-SQLAlchemy relies on the existence of [foreign keys](foreign-key.html) to generate [`JOIN` expressions](joins.html) from your application code. If you remove foreign keys from your schema, SQLAlchemy will not generate joins for you. As a workaround, you can [create a "custom foreign condition" by adding a `relationship` field to your table objects](https://stackoverflow.com/questions/37806625/sqlalchemy-create-relations-but-without-foreign-key-constraint-in-db), or do the equivalent work in your application.
-
-## See also
-
-- The [SQLAlchemy](https://docs.sqlalchemy.org/en/latest/) docs
-- [Transactions](transactions.html)
-
-{% include {{page.version.version}}/app/see-also-links.md %}
-
-<!-- Reference Links -->
-
-[session.flush]: https://docs.sqlalchemy.org/en/latest/orm/session_api.html#sqlalchemy.orm.session.Session.flush
-[session]: https://docs.sqlalchemy.org/en/latest/orm/session.html
diff --git a/src/current/v20.2/build-a-python-app-with-cockroachdb.md b/src/current/v20.2/build-a-python-app-with-cockroachdb.md
deleted file mode 100644
index a2ddd7d1a8d..00000000000
--- a/src/current/v20.2/build-a-python-app-with-cockroachdb.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Build a Python App with CockroachDB and psycopg2
-summary: Learn how to use CockroachDB from a simple Python application with the psycopg2 driver.
-toc: true
-twitter: false
----
-
-<div class="filters clearfix">
-    <a href="build-a-python-app-with-cockroachdb.html"><button class="filter-button page-level current"><strong>psycopg2</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-sqlalchemy.html"><button class="filter-button page-level"><strong>SQLAlchemy</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-django.html"><button class="filter-button page-level"><strong>Django</strong></button></a>
-    <a href="build-a-python-app-with-cockroachdb-pony.html"><button class="filter-button page-level"><strong>PonyORM</strong></button></a>
-    <a href="http://docs.peewee-orm.com/en/latest/peewee/playhouse.html#cockroach-database"><button class="filter-button page-level"><strong>peewee</strong></button></a>
-</div>
-
-{% include cockroach_u_pydev.md %}
-
-This tutorial shows you how build a simple Python application with CockroachDB and the psycopg2 driver. For the CockroachDB back-end, you'll use a temporary local cluster.
-
-## Step 1. Install the psycopg2 driver
-
-To install the Python psycopg2 driver, run the following command:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ pip install psycopg2-binary
-~~~
-
-For other ways to install psycopg2, see the [official documentation](http://initd.org/psycopg/docs/install.html).
-
-## Step 2. Start CockroachDB
-
-{% include {{page.version.version}}/app/start-cockroachdb.md %}
-
-## Step 3. Create a database
-
-{% include {{page.version.version}}/app/create-a-database.md %}
-
-## Step 4. Run the Python code
-
-Now that you have a database, you'll run the code shown below to:
-
-- Create an accounts table and insert some rows.
-- Transfer funds between two accounts inside a [transaction](transactions.html).
-- Delete the accounts from the table before exiting so you can re-run the example code.
-
-To [handle transaction retry errors](error-handling-and-troubleshooting.html#transaction-retry-errors), the code uses an application-level retry loop that, in case of error, sleeps before trying the funds transfer again. If it encounters another retry error, it sleeps for a longer interval, implementing [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff).
-
-### Get the code
-
-Download the [`example.py`](https://raw.githubusercontent.com/cockroachlabs/hello-world-python-psycopg2/master/example.py) file, or create the file yourself and copy the code into it.
-
-If you prefer, you can also clone a version of the code:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ git clone https://github.com/cockroachlabs/hello-world-python-psycopg2/
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/hello-world-python-psycopg2/master/example.py %}
-~~~
-
-### Run the code
-
-The Python code is a command-line utility that accepts the connection string to CockroachDB as a command-line argument:
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ python3 example.py \
-"postgresql://<username>:<password>@<hostname>:<port>/bank?sslmode=require"
-~~~
-
-Before running the command, update the connection string as follows:
-
-- Replace `<username>` and `<password>` with the SQL username and password that you created earlier.
-- Replace `<hostname>` and `<port>` with the hostname and port in the `(sql/tcp)` connection string from SQL shell welcome text.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ python3 example.py \
-"postgres://<username>:<password>@<globalhost>:26257/<cluster-name>.bank?sslmode=verify-full&sslrootcert=<certs_directory>/cc-ca.crt"
-~~~
-
-Before running the command, update the connection string that you copied [earlier](#set-up-your-cluster-connection) from the **Connection info** dialog as follows:
-
-- Replace `<username>` and `<password>` with the SQL username and password that you created earlier.
-- Replace `<globalhost>` with the name of the CockroachDB {{ site.data.products.serverless }} host (e.g., `free-tier.gcp-us-central1.cockroachlabs.cloud`).
-- Replace `<cluster-name>` with the name of your cluster.
-- Replace `<certs_directory>` with the path to the `cc-ca.crt` file that you downloaded from the CockroachDB {{ site.data.products.cloud }} Console.
-
-{{site.data.alerts.callout_info}}
-If you are using the connection string that you [copied from the **Connection info** dialog](#set-up-your-cluster-connection), your username, password, and cluster name will be pre-populated.
-{{site.data.alerts.end}}
-
-</section>
-
-The output should show the account balances before and after the funds transfer:
-
-~~~
-Balances at Fri Oct 30 18:27:00 2020:
-(1, 1000)
-(2, 250)
-Balances at Fri Oct 30 18:27:00 2020:
-(1, 900)
-(2, 350)
-~~~
-
-## What's next?
-
-Read more about using the [Python psycopg2 driver](http://initd.org/psycopg/docs/).
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-ruby-app-with-cockroachdb-activerecord.md b/src/current/v20.2/build-a-ruby-app-with-cockroachdb-activerecord.md
deleted file mode 100644
index c6202501597..00000000000
--- a/src/current/v20.2/build-a-ruby-app-with-cockroachdb-activerecord.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: Build a Ruby App with CockroachDB and ActiveRecord
-summary: Learn how to use CockroachDB from a simple Ruby script with the ActiveRecord gem.
-toc: true
-twitter: false
-referral_id: docs_hello_world_ruby_activerecord
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-ruby-app-with-cockroachdb.html"><button style="width: 28%" class="filter-button">Use <strong>pg</strong></button></a>
-    <a href="build-a-ruby-app-with-cockroachdb-activerecord.html"><button style="width: 28%" class="filter-button current">Use <strong>ActiveRecord</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Ruby application with CockroachDB and [ActiveRecord](http://guides.rubyonrails.org/active_record_basics.html). CockroachDB provides an ActiveRecord adapter for CockroachDB as a [RubyGem](https://rubygems.org/gems/activerecord-cockroachdb-adapter).
-
-{{site.data.alerts.callout_success}}
-For a more realistic use of ActiveRecord with CockroachDB in a Rails app, see our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-{{site.data.alerts.end}}
-
-## Step 1. Start CockroachDB
-
-{% include {{page.version.version}}/app/start-cockroachdb.md %}
-
-## Step 2. Create a database
-
-{% include {{page.version.version}}/app/create-a-database.md %}
-
-## Step 3. Get the code
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button page-level" data-scope="ar61">Active Record 6.1</button>
-  <button class="filter-button page-level" data-scope="ar52">Active Record 5.2</button>
-</div>
-
-Clone [the code's GitHub repository](https://github.com/cockroachlabs/example-app-ruby-activerecord).
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-git clone https://github.com/cockroachlabs/example-app-ruby-activerecord
-~~~
-
-<div class="filter-content" markdown="1" data-scope="local">
-<div class="filter-content" markdown="1" data-scope="ar52">
-Check out the `5.2` branch:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-git checkout 5.2
-~~~
-</div>
-
-</div>
-
-<div class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-<div class="filter-content" markdown="1" data-scope="ar61">
-Check out the `cockroachcloud` branch:
-
-{% include_cached copy-clipboard.html %}
-~~~shell
-git checkout cockroachcloud
-~~~
-
-</div>
-<div class="filter-content" markdown="1" data-scope="ar52">
-Check out the `cockroachcloud-5.2` branch:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-git checkout cockroachcloud-5.2
-~~~
-</div>
-
-</div>
-
-## Step 4. Configure the dependencies
-
-1. Install `libpq` for your platform. For example, to install it on Mac with Homebrew:
-    {% include_cached copy-clipboard.html %}
-    ~~~shell
-    brew install libpq
-    ~~~
-1. Configure `bundle` to use `libpq`. For example, if you installed `libpq` on Mac using Homebrew:
-    {% include_cached copy-clipboard.html %}
-    ~~~shell
-    bundle config --local build.pg --with-opt-dir="/usr/local/opt/libpq"
-    ~~~
-    Set `--with-opt-dir` to the location of `libpq` on your OS.
-
-## Step 5. Install the dependencies
-
-{% include_cached copy-clipboard.html %}
-~~~shell
-bundle install
-~~~
-
-## Step 6. Update the connection parameters
-
-Update the connection parameters to connect to your cluster.
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-{% include_cached copy-clipboard.html %}
-~~~ ruby
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-ruby-activerecord/main/main.rb||# BEGIN connect||# END connect %}
-~~~
-
-Where `{port}` is the port number from the connection string you noted earlier, `{username}` is the database username you created, and `{password}` is the database user's password.
-
-</section>
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-{% include_cached copy-clipboard.html %}
-~~~ ruby
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/example-app-ruby-activerecord/cockroachcloud/main.rb||# BEGIN connect||# END connect %}
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-</section>
-
-## Step 7. Run the Ruby code
-
-Run the code to create a table and insert some rows, and then you'll run code to read and update values as an atomic [transaction](transactions.html).
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-ruby main.rb
-~~~
-
-The output should be:
-
-~~~
--- create_table(:accounts, {:force=>true, :id=>:integer})
-   -> 0.3951s
-account: 1 balance: 1000
-account: 2 balance: 250
-~~~
-
-## What's next?
-
-Read more about using [ActiveRecord](http://guides.rubyonrails.org/active_record_basics.html), or check out a more realistic implementation of ActiveRecord with CockroachDB in a Rails app in our [`examples-orms`](https://github.com/cockroachdb/examples-orms) repository.
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-ruby-app-with-cockroachdb.md b/src/current/v20.2/build-a-ruby-app-with-cockroachdb.md
deleted file mode 100644
index a4ccd8b945a..00000000000
--- a/src/current/v20.2/build-a-ruby-app-with-cockroachdb.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Build a Ruby App with CockroachDB and the Ruby pg Driver
-summary: Learn how to use CockroachDB from a simple Ruby application with the pg client driver.
-toc: true
-twitter: false
-referral_id: docs_hello_world_ruby_pg
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-ruby-app-with-cockroachdb.html"><button style="width: 28%" class="filter-button current">Use <strong>pg</strong></button></a>
-    <a href="build-a-ruby-app-with-cockroachdb-activerecord.html"><button style="width: 28%" class="filter-button">Use <strong>ActiveRecord</strong></button></a>
-</div>
-
-This tutorial shows you how build a simple Ruby application with CockroachDB and the [Ruby pg driver](https://deveiate.org/code/pg/PG/Connection.html).
-
-## Step 1. Start CockroachDB
-
-{% include {{page.version.version}}/app/start-cockroachdb.md %}
-
-## Step 2. Create a database
-
-{% include {{page.version.version}}/app/create-a-database.md %}
-
-## Step 3. Get the code
-
-Clone [the code's GitHub repository](https://github.com/cockroachlabs/hello-world-ruby-pg).
-
-{% include_cached copy-clipboard.html %}
-~~~shell
-git clone https://github.com/cockroachlabs/hello-world-ruby-pg
-~~~
-
-The code connects as the user you created and executes some basic SQL statements: creating a table, inserting rows, and reading and printing the rows.
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-Check out the `cockroachcloud` branch:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-git checkout cockroachcloud
-~~~
-
-</section>
-
-## Step 4. Configure the dependencies
-
-1. Install `libpq` for your platform. For example, to install it on Mac with Homebrew:
-    {% include_cached copy-clipboard.html %}
-    ~~~shell
-    brew install libpq
-    ~~~
-1. Configure `bundle` to use `libpq`. For example, if you installed `libpq` on Mac using Homebrew:
-    {% include_cached copy-clipboard.html %}
-    ~~~shell
-    bundle config --local build.pg --with-opt-dir="/usr/local/opt/libpq"
-    ~~~
-    Set `--with-opt-dir` to the location of `libpq` on your OS.
-
-## Step 5. Install the dependencies
-
-{% include_cached copy-clipboard.html %}
-~~~shell
-bundle install
-~~~
-
-## Step 6. Update the connection parameters
-
-Update the connection parameters to connect to your cluster.
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-{% include_cached copy-clipboard.html %}
-~~~ ruby
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/hello-world-ruby-pg/master/main.rb||# BEGIN connect||# END connect %}
-~~~
-
-Where `{port}` is the port number from the connection string you noted earlier, `{username}` is the database username you created, and `{password}` is the database user's password.
-
-</section>
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-{% include_cached copy-clipboard.html %}
-~~~ ruby
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/hello-world-ruby-pg/cockroachcloud/main.rb||# BEGIN connect||# END connect %}
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-</section>
-
-## Step 7. Run the Ruby code
-
-Run the code to create a table and insert some rows, and then you'll run code to read and update values as an atomic [transaction](transactions.html).
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-ruby main.rb
-~~~
-
-The output should be:
-
-~~~
-------------------------------------------------
-print_balances(): Balances as of '2021-02-23 11:56:54 -0800':
-{"id"=>"1", "balance"=>"1000"}
-{"id"=>"2", "balance"=>"250"}
-------------------------------------------------
-transfer_funds(): Trying to transfer 100 from account 1 to account 2
-------------------------------------------------
-print_balances(): Balances as of '2021-02-23 11:56:55 -0800':
-{"id"=>"1", "balance"=>"900"}
-{"id"=>"2", "balance"=>"350"}
-~~~
-
-## What's next?
-
-Read more about using the [Ruby pg driver](https://rubygems.org/gems/pg).
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/build-a-rust-app-with-cockroachdb.md b/src/current/v20.2/build-a-rust-app-with-cockroachdb.md
deleted file mode 100644
index 4518051abff..00000000000
--- a/src/current/v20.2/build-a-rust-app-with-cockroachdb.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: Build a Rust App with CockroachDB and the Rust Postgres Driver
-summary: Learn how to use CockroachDB from a simple Rust application with a low-level client driver.
-toc: true
-twitter: false
----
-
-This tutorial shows you how build a simple Rust application with CockroachDB and the [Rust-Postgres driver](https://github.com/sfackler/rust-postgres).
-
-We have tested the Rust-Postgres driver enough to claim **beta-level** support. If you encounter problems, please [open an issue](https://github.com/cockroachdb/cockroach/issues/new) with details to help us make progress toward full support.
-
-## Before you begin
-
-{% include {{page.version.version}}/app/before-you-begin.md %}
-
-## Step 1. Specify the Rust Postgres driver as a dependency
-
-Update your `Cargo.toml` file to specify a dependency on the Rust Postgres driver, as described in the <a href="https://crates.io/crates/postgres/" data-proofer-ignore>official documentation</a>.
-
-Additionally, include the <a href="https://crates.io/crates/openssl" data-proofer-ignore>OpenSSL bindings</a> and <a href="https://crates.io/crates/postgres-openssl/" data-proofer-ignore>Rust Postgres OpenSSL</a> crates as dependencies.
-
-## Step 2. Create the `maxroach` users and `bank` database
-
-{% include {{page.version.version}}/app/create-maxroach-user-and-bank-database.md %}
-
-## Step 3. Generate a certificate for the `maxroach` user
-
-Create a certificate and key for the `maxroach` user by running the following command.  The code samples will run as this user.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client maxroach --certs-dir=certs --ca-key=my-safe-directory/ca.key
-~~~
-
-## Step 4. Run the Rust code
-
-Now that you have a database and a user, you'll run code to create a table and insert some rows, and then you'll run code to read and update values as an atomic [transaction](transactions.html).
-
-### Get the code
-
-Clone the [`example-app-rust-postgres`](https://github.com/cockroachdb/example-app-rust-postgres) GitHub repo:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ git clone https://github.com/cockroachdb/example-app-rust-postgres
-~~~
-
-### Basic statements
-
-First, run `basic-sample.rs` to connect as the `maxroach` user and execute some basic SQL statements, inserting rows and reading and printing the rows:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-{% remote_include https://raw.githubusercontent.com/cockroachdb/example-app-rust-postgres/main/basic-sample.rs %}
-~~~
-
-### Transaction (with retry logic)
-
-Next, run `txn-sample.rs` to again connect as the `maxroach` user but this time execute a batch of statements as an atomic transaction to transfer funds from one account to another, where all included statements are either committed or aborted.
-
-{{site.data.alerts.callout_info}}
-CockroachDB may require the [client to retry a transaction](transactions.html#transaction-retries) in case of read/write contention. CockroachDB provides a generic <strong>retry function</strong> that runs inside a transaction and retries it as needed. You can copy and paste the retry function from here into your code.
-{{site.data.alerts.end}}
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-{% remote_include https://raw.githubusercontent.com/cockroachdb/example-app-rust-postgres/main/txn-sample.rs %}
-~~~
-
-After running the code, use the [built-in SQL client](cockroach-sql.html) to verify that funds were transferred from one account to another:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs -e 'SELECT id, balance FROM accounts' --database=bank
-~~~
-
-~~~
-+----+---------+
-| id | balance |
-+----+---------+
-|  1 |     900 |
-|  2 |     350 |
-+----+---------+
-(2 rows)
-~~~
-
-## What's next?
-
-Read more about using the <a href="https://crates.io/crates/postgres/" data-proofer-ignore>Rust Postgres driver</a>.
-
-{% include {{ page.version.version }}/app/see-also-links.md %}
\ No newline at end of file
diff --git a/src/current/v20.2/build-a-spring-app-with-cockroachdb-jdbc.md b/src/current/v20.2/build-a-spring-app-with-cockroachdb-jdbc.md
deleted file mode 100644
index 6cf977692bd..00000000000
--- a/src/current/v20.2/build-a-spring-app-with-cockroachdb-jdbc.md
+++ /dev/null
@@ -1,820 +0,0 @@
----
-title: Build a Spring App with CockroachDB and JDBC
-summary: Learn how to use CockroachDB from a Spring application with the JDBC driver.
-toc: true
-twitter: false
-referral_id: docs_roach_data_java_spring_jdbc
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-spring-app-with-cockroachdb-jdbc.html"><button style="width: 28%" class="filter-button current">Use <strong>JDBC</strong></button></a>
-    <a href="build-a-spring-app-with-cockroachdb-jpa.html"><button style="width: 28%" class="filter-button">Use <strong>JPA</strong></button></a>
-</div>
-
-This tutorial shows you how to build a [Spring Boot](https://spring.io/projects/spring-boot) web application with CockroachDB, using the [Spring Data JDBC](https://spring.io/projects/spring-data-jdbc) module for data access. The code for the example application is available for download from [GitHub](https://github.com/cockroachlabs/roach-data/tree/master), along with identical examples that use [JPA](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-jpa), [jOOQ](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-jooq), and [MyBatis](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-mybatis) for data access.
-
-## Step 1. Start CockroachDB
-
-Choose whether to run a local cluster or a free cluster on CockroachDB {{ site.data.products.cloud }}.
-
-<div class="filters clearfix">
-  <button class="filter-button page-level" data-scope="cockroachcloud">Use CockroachDB {{ site.data.products.cloud }}</button>
-  <button class="filter-button page-level" data-scope="local">Use a Local Cluster</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-1. If you haven't already, [download the CockroachDB binary](install-cockroachdb.html).
-1. [Start a local, secure cluster](secure-a-cluster.html).
-
-</section>
-
-  <section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-### Create a free cluster
-
-{% include cockroachcloud/quickstart/create-a-free-cluster.md %}
-
-### Set up your cluster connection
-
-{% include cockroachcloud/quickstart/set-up-your-cluster-connection.md %}
-
-  </section>
-
-## Step 2. Create a database and a user
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-1. Open a SQL shell to your local cluster using the [`cockroach sql`](cockroach-sql.html) command:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir={certs-dir} --host=localhost:{port}
-    ~~~
-
-    Where `{certs_dir}` is the full path to the `certs` directory that you created when setting up the cluster, and `{port}` is the port at which the cluster is listening for incoming connections.
-
-1. In the SQL shell, create the `roach_data` database that your application will use:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE roach_data;
-    ~~~
-
-1. Create a SQL user for your app:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER {username} WITH PASSWORD {password};
-    ~~~
-
-    Take note of the username and password. You will use it to connect to the database later.
-
-1. Give the user the necessary permissions:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > GRANT ALL ON DATABASE roach_data TO {username};
-    ~~~
-
-1. Exit the shell, and generate a certificate and key for your user by running the following command:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client {user} --certs-dir={certs-dir} --ca-key={certs-dir}/ca.key --also-generate-pkcs8-key
-~~~
-
-The [`--also-generate-pkcs8-key` flag](cockroach-cert.html#flag-pkcs8) generates a key in [PKCS#8 format](https://tools.ietf.org/html/rfc5208), which is the standard key encoding format in Java. In this case, the generated PKCS8 key will be named `client.{user}.key.pk8`.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-1. If you haven't already, [download the CockroachDB binary](install-cockroachdb.html).
-1. Start the [built-in SQL shell](cockroach-sql.html) using the connection string you got from the CockroachDB {{ site.data.products.cloud }} Console [earlier](#set-up-your-cluster-connection):
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --url='postgres://{username}:{password}@{global host}:26257/{cluster_name}.defaultdb?sslmode=verify-full&sslrootcert={certs_dir}/cc-ca.crt'
-    ~~~
-
-    In the connection string copied from the CockroachDB {{ site.data.products.cloud }} Console, your username, password and cluster name are pre-populated. Replace the `{certs_dir}` placeholder with the path to the `certs` directory that you created [earlier](#set-up-your-cluster-connection).
-
-    {% include cockroachcloud/cc-no-user-certs.md %}
-
-1. In the SQL shell, create the `roach_data` database that your application will use:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE roach_data;
-    ~~~
-
-</section>
-
-## Step 3. Install JDK
-
-Download and install a Java Development Kit. Spring Boot supports Java versions 8, 11, and 14. In this tutorial, we use [JDK 8 from OpenJDK](https://openjdk.java.net/install/).
-
-## Step 4. Install Maven
-
-This example application uses [Maven](http://maven.apache.org/) to manage all application dependencies. Spring supports Maven versions 3.2 and later.
-
-To install Maven on macOS, run the following command:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ brew install maven
-~~~
-
-To install Maven on a Debian-based Linux distribution like Ubuntu:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ apt-get install maven
-~~~
-
-To install Maven on a Red Hat-based Linux distribution like Fedora:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ dnf install maven
-~~~
-
-For other ways to install Maven, see [its official documentation](http://maven.apache.org/install.html).
-
-## Step 5. Get the application code
-
-To get the application code, download or clone the [`roach-data` repository](https://github.com/cockroachlabs/roach-data). The code for the example JDBC application is located under the `roach-data-jdbc` directory.
-
-(*Optional*) To recreate the application project structure with the same dependencies as those used by this sample application, you can use [Spring initializr](https://start.spring.io/) with the following settings:
-
-**Project**
-
-- Maven Project
-
-**Language**
-
-- Java
-
-**Spring Boot**
-
-- 2.2.6
-
-**Project Metadata**
-
-- Group: io.roach
-- Artifact: data
-- Name: data
-- Package name: io.roach.data
-- Packaging: Jar
-- Java: 8
-
-**Dependencies**
-
-- Spring Web
-- Spring Data JDBC
-- Spring Boot Actuator
-- Spring HATEOS
-- Liquibase Migration
-- PostgreSQL Driver
-
-
-## Step 6. Run the application
-
-Compiling and running the application code will start a web application, initialize the `accounts` table in the `roach_data` database, and submit some requests to the app's REST API that result in [atomic database transactions](transactions.html) on the running CockroachDB cluster. For details about the application code, see [Implementation details](#implementation-details).
-
-Open the `roach-data/roach-data-jdbc/src/main/resources/application.yml` file and edit the `datasource` settings to connect to your running database cluster:
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-~~~ yml
-  ...
-datasource:
-  url: jdbc:postgresql://localhost:{port}/roach_data?ssl=true&sslmode=require&sslrootcert={certs-dir}/ca.crt&sslkey={certs-dir}/client.{username}.key.pk8&sslcert={certs-dir}/client.{username}.crt
-  username: {username}
-  password: {password}
-  driver-class-name: org.postgresql.Driver
-  ...
-~~~
-
-Where:
-
-- `{port}` is the port number.
-- `{certs-dir}` is the full path to the certificates directory containing the authentication certificates that you created earlier.
-- `{username}` and `{password}` specify the SQL username and password that you created earlier.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-~~~ yml
-...
-datasource:
-  url: jdbc:postgresql://{globalhost}:{port}/{cluster_name}.roach_data?sslmode=verify-full&sslrootcert={path to the CA certificate}/cc-ca.crt
-  username: {username}
-  password: {password}
-  driver-class-name: org.postgresql.Driver
-...
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-</section>
-
-Open a terminal, and navigate to the `roach-data-jdbc` project subfolder:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cd <path>/roach-data/roach-data-jdbc
-~~~
-
-Use Maven to download the application dependencies and compile the code:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ mvn clean install
-~~~
-
-From the `roach-data-jdbc` directory, run the application JAR file:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ java -jar target/roach-data-jdbc.jar
-~~~
-
-The output should look like the following:
-
-~~~
-^__^
-(oo)\_______
-(__)\       )\/\   CockroachDB on Spring Data JDBC  (v1.0.0.BUILD-SNAPSHOT)
-   ||----w |       powered by Spring Boot  (v2.2.7.RELEASE)
-   ||     ||
-
-2020-06-17 14:56:54.507  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Starting JdbcApplication v1.0.0.BUILD-SNAPSHOT on MyComputer with PID 43008 (path/roach-data/roach-data-jdbc/target/roach-data-jdbc.jar started by user in path/roach-data/roach-data-jdbc)
-2020-06-17 14:56:54.510  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : No active profile set, falling back to default profiles: default
-2020-06-17 14:56:55.387  INFO 43008 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JDBC repositories in DEFAULT mode.
-2020-06-17 14:56:55.452  INFO 43008 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 59ms. Found 2 JDBC repository interfaces.
-2020-06-17 14:56:56.581  INFO 43008 --- [           main] org.eclipse.jetty.util.log               : Logging initialized @3378ms to org.eclipse.jetty.util.log.Slf4jLog
-2020-06-17 14:56:56.657  INFO 43008 --- [           main] o.s.b.w.e.j.JettyServletWebServerFactory : Server initialized with port: 9090
-2020-06-17 14:56:56.661  INFO 43008 --- [           main] org.eclipse.jetty.server.Server          : jetty-9.4.28.v20200408; built: 2020-04-08T17:49:39.557Z; git: ab228fde9e55e9164c738d7fa121f8ac5acd51c9; jvm 11.0.7+10
-2020-06-17 14:56:56.696  INFO 43008 --- [           main] o.e.j.s.h.ContextHandler.application     : Initializing Spring embedded WebApplicationContext
-2020-06-17 14:56:56.696  INFO 43008 --- [           main] o.s.web.context.ContextLoader            : Root WebApplicationContext: initialization completed in 2088 ms
-2020-06-17 14:56:57.170  INFO 43008 --- [           main] org.eclipse.jetty.server.session         : DefaultSessionIdManager workerName=node0
-2020-06-17 14:56:57.171  INFO 43008 --- [           main] org.eclipse.jetty.server.session         : No SessionScavenger set, using defaults
-2020-06-17 14:56:57.172  INFO 43008 --- [           main] org.eclipse.jetty.server.session         : node0 Scavenging every 600000ms
-2020-06-17 14:56:57.178  INFO 43008 --- [           main] o.e.jetty.server.handler.ContextHandler  : Started o.s.b.w.e.j.JettyEmbeddedWebAppContext@deb3b60{application,/,[file:///private/var/folders/pg/r58v54857gq_1nqm_2tr6lg40000gn/T/jetty-docbase.3049902632643053896.8080/],AVAILABLE}
-2020-06-17 14:56:57.179  INFO 43008 --- [           main] org.eclipse.jetty.server.Server          : Started @3976ms
-2020-06-17 14:56:58.126  INFO 43008 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
-2020-06-17 14:56:58.369  INFO 43008 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
-2020-06-17 14:56:58.695  INFO 43008 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
-2020-06-17 14:56:59.901  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT COUNT(*) FROM public.databasechangeloglock
-2020-06-17 14:56:59.917  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : CREATE TABLE public.databasechangeloglock (ID INTEGER NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED TIMESTAMP WITHOUT TIME ZONE, LOCKEDBY VARCHAR(255), CONSTRAINT DATABASECHANGELOGLOCK_PKEY PRIMARY KEY (ID))
-2020-06-17 14:56:59.930  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT COUNT(*) FROM public.databasechangeloglock
-2020-06-17 14:56:59.950  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : DELETE FROM public.databasechangeloglock
-2020-06-17 14:56:59.953  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.databasechangeloglock (ID, LOCKED) VALUES (1, FALSE)
-2020-06-17 14:56:59.959  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
-2020-06-17 14:56:59.969  INFO 43008 --- [           main] l.lockservice.StandardLockService        : Successfully acquired change log lock
-2020-06-17 14:57:01.367  INFO 43008 --- [           main] l.c.StandardChangeLogHistoryService      : Creating database history table with name: public.databasechangelog
-2020-06-17 14:57:01.369  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : CREATE TABLE public.databasechangelog (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED TIMESTAMP WITHOUT TIME ZONE NOT NULL, ORDEREXECUTED INTEGER NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35), DESCRIPTION VARCHAR(255), COMMENTS VARCHAR(255), TAG VARCHAR(255), LIQUIBASE VARCHAR(20), CONTEXTS VARCHAR(255), LABELS VARCHAR(255), DEPLOYMENT_ID VARCHAR(10))
-2020-06-17 14:57:01.380  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT COUNT(*) FROM public.databasechangelog
-2020-06-17 14:57:01.396  INFO 43008 --- [           main] l.c.StandardChangeLogHistoryService      : Reading from public.databasechangelog
-2020-06-17 14:57:01.397  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT * FROM public.databasechangelog ORDER BY DATEEXECUTED ASC, ORDEREXECUTED ASC
-2020-06-17 14:57:01.400  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT COUNT(*) FROM public.databasechangeloglock
-2020-06-17 14:57:01.418  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : -- DROP TABLE IF EXISTS account cascade;
--- DROP TABLE IF EXISTS databasechangelog cascade;
--- DROP TABLE IF EXISTS databasechangeloglock cascade;
-
-create table account
-(
-    id      int            not null primary key default unique_rowid(),
-    balance numeric(19, 2) not null,
-    name    varchar(128)   not null,
-    type    varchar(25)    not null
-)
-2020-06-17 14:57:01.426  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : -- insert into account (id,balance,name,type) values
---     (1, 500.00,'Alice','asset'),
---     (2, 500.00,'Bob','expense'),
---     (3, 500.00,'Bobby Tables','asset'),
---     (4, 500.00,'Doris','expense');
-2020-06-17 14:57:01.427  INFO 43008 --- [           main] liquibase.changelog.ChangeSet            : SQL in file db/create.sql executed
-2020-06-17 14:57:01.430  INFO 43008 --- [           main] liquibase.changelog.ChangeSet            : ChangeSet classpath:db/changelog-master.xml::1::root ran successfully in 14ms
-2020-06-17 14:57:01.430  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT MAX(ORDEREXECUTED) FROM public.databasechangelog
-2020-06-17 14:57:01.441  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('1', 'root', 'classpath:db/changelog-master.xml', NOW(), 1, '8:939a1a8c47676119a94d0173802d207e', 'sqlFile', '', 'EXECUTED', 'crdb', NULL, '3.8.9', '2420221402')
-2020-06-17 14:57:01.450  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.account (id, name, balance, type) VALUES ('1', 'Alice', 500.00, 'asset')
-2020-06-17 14:57:01.459  INFO 43008 --- [           main] liquibase.changelog.ChangeSet            : New row inserted into account
-2020-06-17 14:57:01.460  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.account (id, name, balance, type) VALUES ('2', 'Bob', 500.00, 'expense')
-2020-06-17 14:57:01.462  INFO 43008 --- [           main] liquibase.changelog.ChangeSet            : New row inserted into account
-2020-06-17 14:57:01.462  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.account (id, name, balance, type) VALUES ('3', 'Bobby Tables', 500.00, 'asset')
-2020-06-17 14:57:01.464  INFO 43008 --- [           main] liquibase.changelog.ChangeSet            : New row inserted into account
-2020-06-17 14:57:01.465  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.account (id, name, balance, type) VALUES ('4', 'Doris', 500.00, 'expense')
-2020-06-17 14:57:01.467  INFO 43008 --- [           main] liquibase.changelog.ChangeSet            : New row inserted into account
-2020-06-17 14:57:01.469  INFO 43008 --- [           main] liquibase.changelog.ChangeSet            : ChangeSet classpath:db/changelog-master.xml::2::root ran successfully in 19ms
-2020-06-17 14:57:01.470  INFO 43008 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('2', 'root', 'classpath:db/changelog-master.xml', NOW(), 2, '8:c2945f2a445cf60b4b203e1a91d14a89', 'insert tableName=account; insert tableName=account; insert tableName=account; insert tableName=account', '', 'EXECUTED', 'crdb', NULL, '3.8.9', '2420221402')
-2020-06-17 14:57:01.479  INFO 43008 --- [           main] l.lockservice.StandardLockService        : Successfully released change log lock
-2020-06-17 14:57:01.555  INFO 43008 --- [           main] o.s.b.a.e.web.EndpointLinksResolver      : Exposing 8 endpoint(s) beneath base path '/actuator'
-2020-06-17 14:57:01.610  INFO 43008 --- [           main] o.e.j.s.h.ContextHandler.application     : Initializing Spring DispatcherServlet 'dispatcherServlet'
-2020-06-17 14:57:01.610  INFO 43008 --- [           main] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
-2020-06-17 14:57:01.620  INFO 43008 --- [           main] o.s.web.servlet.DispatcherServlet        : Completed initialization in 10 ms
-2020-06-17 14:57:01.653  INFO 43008 --- [           main] o.e.jetty.server.AbstractConnector       : Started ServerConnector@733c423e{HTTP/1.1, (http/1.1)}{0.0.0.0:9090}
-2020-06-17 14:57:01.654  INFO 43008 --- [           main] o.s.b.web.embedded.jetty.JettyWebServer  : Jetty started on port(s) 9090 (http/1.1) with context path '/'
-2020-06-17 14:57:01.657  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Started JdbcApplication in 7.92 seconds (JVM running for 8.454)
-2020-06-17 14:57:01.659  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Lets move some $$ around!
-2020-06-17 14:57:03.552  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Worker finished - 7 remaining
-2020-06-17 14:57:03.606  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Worker finished - 6 remaining
-2020-06-17 14:57:03.606  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Worker finished - 5 remaining
-2020-06-17 14:57:03.607  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Worker finished - 4 remaining
-2020-06-17 14:57:03.608  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Worker finished - 3 remaining
-2020-06-17 14:57:03.608  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Worker finished - 2 remaining
-2020-06-17 14:57:03.608  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Worker finished - 1 remaining
-2020-06-17 14:57:03.608  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : Worker finished - 0 remaining
-2020-06-17 14:57:03.608  INFO 43008 --- [           main] io.roach.data.jdbc.JdbcApplication       : All client workers finished but server keeps running. Have a nice day!
-~~~
-
-As the output states, the application configures a database connection, starts a web servlet listening on the address `http://localhost:9090/`, initializes the `account` table and changelog tables with [Liquibase](https://www.liquibase.org/), and then runs some test operations as requests to the application's REST API.
-
-For more details about the application code, see [Implementation details](#implementation-details).
-
-### Query the database
-
-#### Reads
-
-The `http://localhost:9090/account` endpoint returns information about all accounts in the database. `GET` requests to these endpoints are executed on the database as `SELECT` statements.
-
-The following `curl` command sends a `GET` request to the endpoint. The `json_pp` command formats the JSON response.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account | json_pp
-~~~
-
-~~~
-{
-   "_embedded" : {
-      "accounts" : [
-         {
-            "_links" : {
-               "self" : {
-                  "href" : "http://localhost:9090/account/1"
-               }
-            },
-            "balance" : 500,
-            "name" : "Alice",
-            "type" : "asset"
-         },
-         {
-            "_links" : {
-               "self" : {
-                  "href" : "http://localhost:9090/account/2"
-               }
-            },
-            "balance" : 500,
-            "name" : "Bob",
-            "type" : "expense"
-         },
-         {
-            "_links" : {
-               "self" : {
-                  "href" : "http://localhost:9090/account/3"
-               }
-            },
-            "balance" : 500,
-            "name" : "Bobby Tables",
-            "type" : "asset"
-         },
-         {
-            "_links" : {
-               "self" : {
-                  "href" : "http://localhost:9090/account/4"
-               }
-            },
-            "balance" : 500,
-            "name" : "Doris",
-            "type" : "expense"
-         }
-      ]
-   },
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account?page=0&size=5"
-      }
-   },
-   "page" : {
-      "number" : 0,
-      "size" : 5,
-      "totalElements" : 4,
-      "totalPages" : 1
-   }
-}
-~~~
-
-For a single account, specify the account number in the endpoint. For example, to see information about the accounts `1` and `2`:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account/1 | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account/1"
-      }
-   },
-   "balance" : 500,
-   "name" : "Alice",
-   "type" : "asset"
-}
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account/2 | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account/2"
-      }
-   },
-   "balance" : 500,
-   "name" : "Bob",
-   "type" : "expense"
-}
-~~~
-
-The `http://localhost:9090/transfer` endpoint performs transfers between accounts. `POST` requests to this endpoint are executed as writes (i.e., [`INSERT`s](insert.html) and [`UPDATE`s](update.html)) to the database.
-
-#### Writes
-
-To make a transfer, send a `POST` request to the `transfer` endpoint, using the arguments specified in the `"href`" URL (i.e., `http://localhost:9090/transfer%7B?fromId,toId,amount`).
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X POST -d fromId=2 -d toId=1 -d amount=150 http://localhost:9090/transfer
-~~~
-
-You can use the `accounts` endpoint to verify that the transfer was successfully completed:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account/1 | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account/1"
-      }
-   },
-   "balance" : 350,
-   "name" : "Alice",
-   "type" : "asset"
-}
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account/2 | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account/2"
-      }
-   },
-   "balance" : 650,
-   "name" : "Bob",
-   "type" : "expense"
-}
-~~~
-
-### Monitor the application
-
-`http://localhost:9090/actuator` is the base URL for a number of [Spring Boot Actuator](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready) endpoints that let you monitor the activity and health of the application.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/actuator | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "conditions" : {
-         "href" : "http://localhost:9090/actuator/conditions",
-         "templated" : false
-      },
-      "configprops" : {
-         "href" : "http://localhost:9090/actuator/configprops",
-         "templated" : false
-      },
-      "env" : {
-         "href" : "http://localhost:9090/actuator/env",
-         "templated" : false
-      },
-      "env-toMatch" : {
-         "href" : "http://localhost:9090/actuator/env/{toMatch}",
-         "templated" : true
-      },
-      "health" : {
-         "href" : "http://localhost:9090/actuator/health",
-         "templated" : false
-      },
-      "health-path" : {
-         "href" : "http://localhost:9090/actuator/health/{*path}",
-         "templated" : true
-      },
-      "info" : {
-         "href" : "http://localhost:9090/actuator/info",
-         "templated" : false
-      },
-      "liquibase" : {
-         "href" : "http://localhost:9090/actuator/liquibase",
-         "templated" : false
-      },
-      "metrics" : {
-         "href" : "http://localhost:9090/actuator/metrics",
-         "templated" : false
-      },
-      "metrics-requiredMetricName" : {
-         "href" : "http://localhost:9090/actuator/metrics/{requiredMetricName}",
-         "templated" : true
-      },
-      "self" : {
-         "href" : "http://localhost:9090/actuator",
-         "templated" : false
-      },
-      "threaddump" : {
-         "href" : "http://localhost:9090/actuator/threaddump",
-         "templated" : false
-      }
-   }
-}
-~~~
-
-Each actuator endpoint shows specific metrics on the application. For example:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/actuator/health | json_pp
-~~~
-
-~~~
-{
-   "components" : {
-      "db" : {
-         "details" : {
-            "database" : "PostgreSQL",
-            "result" : 1,
-            "validationQuery" : "SELECT 1"
-         },
-         "status" : "UP"
-      },
-      "diskSpace" : {
-         "details" : {
-            "free" : 125039620096,
-            "threshold" : 10485760,
-            "total" : 250685575168
-         },
-         "status" : "UP"
-      },
-      "ping" : {
-         "status" : "UP"
-      }
-   },
-   "status" : "UP"
-}
-~~~
-
-For more information about actuator endpoints, see the [Spring Boot Actuator Endpoint documentation](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready-endpoints).
-
-## Implementation details
-
-This section walks you through the different components of the application project in detail.
-
-### Main application process
-
-`JdbcApplication.java` defines the application's main process. It starts a Spring Boot web application, and then submits requests to the app's REST API that result in database transactions on the CockroachDB cluster.
-
-Here are the contents of [`JdbcApplication.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/JdbcApplication.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/JdbcApplication.java %}
-~~~
-
-The annotations listed at the top of the `JdbcApplication` class definition declare some important configuration properties for the entire application:
-
-- [`@EnableHypermediaSupport`](https://docs.spring.io/spring-hateoas/docs/current/api/org/springframework/hateoas/config/EnableHypermediaSupport.html) enables [hypermedia support for resource representation](https://en.wikipedia.org/wiki/HATEOAS) in the application. Currently, the only hypermedia format supported by Spring is [HAL](https://en.wikipedia.org/wiki/Hypertext_Application_Language), and so the `type = EnableHypermediaSupport.HypermediaType.HAL`. For details, see [Hypermedia representation](#hypermedia-representation).
-- [`@EnableJdbcRepositories`](https://docs.spring.io/spring-data/jdbc/docs/current/api/org/springframework/data/jdbc/repository/config/EnableJdbcRepositories.html) enables the creation of [Spring repositories](https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/#jdbc.repositories) for data access using [Spring Data JDBC](https://spring.io/projects/spring-data-jdbc). For details, see [Spring repositories](#spring-repositories).
-- [`@EnableAspectJAutoProxy`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/annotation/EnableAspectJAutoProxy.html) enables the use of [`@AspectJ` annotations for declaring aspects](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj). For details, see [Transaction management](#transaction-management).
-- [`@EnableTransactionManagement`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/EnableTransactionManagement.html) enables [declarative transaction management](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative) in the application. For details, see [Transaction management](#transaction-management).
-
-    Note that the `@EnableTransactionManagement` annotation is passed an `order` parameter, which indicates the ordering of advice evaluation when a common join point is reached. For details, see [Ordering advice](#ordering-advice).
-- [`@SpringBootApplication`](https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/autoconfigure/SpringBootApplication.html) is a standard configuration annotation used by Spring Boot applications. For details, see [Using the @SpringBootApplication](https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-using-springbootapplication-annotation) on the Spring Boot documentation site.
-
-### Schema management
-
-To create and initialize the database schema, the application uses [Liquibase](https://www.liquibase.org/).
-
-#### Liquibase changelogs
-
-Liquibase uses [changelog files](https://docs.liquibase.com/concepts/basic/changelog.html) to manage database schema changes. Changelog files include a list of instructions, known as [changesets](https://docs.liquibase.com/concepts/basic/changeset.html), that are executed against the database in a specified order.
-
-`resources/db/changelog-master.xml` defines the changelog for this application:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/resources/db/changelog-master.xml %}
-~~~
-
-The first changeset uses [the `sqlFile` tag](https://docs.liquibase.com/change-types/community/sql-file.html), which tells Liquibase that an external `.sql` file contains some SQL statements to execute. The file specified by the changeset, `resources/db/create.sql`, creates the `account` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/resources/db/create.sql %}
-~~~
-
-The second changeset in the changelog uses the [Liquibase XML syntax](https://docs.liquibase.com/concepts/basic/xml-format.html) to specify a series of sequential `INSERT` statements that initialize the `account` table with some values.
-
-When the application is started, all of the queries specified by the changesets are executed in the order specified by their `changeset` tag's `id` value. At application startup, Liquibase also creates a table called [`databasechangelog`](https://docs.liquibase.com/concepts/databasechangelog-table.html) in the database where it performs changes. This table's rows log all completed changesets.
-
-To see the completed changesets after starting the application, open a new terminal, start the [built-in SQL shell](cockroach-sql.html), and query the `databasechangelog` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM roach_data.databasechangelog;
-~~~
-
-~~~
-  id | author |             filename              |           dateexecuted           | orderexecuted | exectype |               md5sum               |                                              description                                               | comments | tag  | liquibase | contexts | labels | deployment_id
------+--------+-----------------------------------+----------------------------------+---------------+----------+------------------------------------+--------------------------------------------------------------------------------------------------------+----------+------+-----------+----------+--------+----------------
-  1  | root   | classpath:db/changelog-master.xml | 2020-06-17 14:57:01.431506+00:00 |             1 | EXECUTED | 8:939a1a8c47676119a94d0173802d207e | sqlFile                                                                                                |          | NULL | 3.8.9     | crdb     | NULL   | 2420221402
-  2  | root   | classpath:db/changelog-master.xml | 2020-06-17 14:57:01.470847+00:00 |             2 | EXECUTED | 8:c2945f2a445cf60b4b203e1a91d14a89 | insert tableName=account; insert tableName=account; insert tableName=account; insert tableName=account |          | NULL | 3.8.9     | crdb     | NULL   | 2420221402
-(2 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-Liquibase does not [retry transactions](transactions.html#transaction-retries) automatically. If a changeset fails at startup, you might need to restart the application manually to complete the changeset.
-{{site.data.alerts.end}}
-
-#### Liquibase configuration
-
-Typically, Liquibase properties are defined in a separate [`liquibase.properties`](https://docs.liquibase.com/workflows/liquibase-community/creating-config-properties.html) file. In this application, the [Spring properties](https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html) file, `application.yml`, includes properties that enable and configure Liquibase:
-
-~~~ yml
-...
- liquibase:
-   change-log: classpath:db/changelog-master.xml
-   default-schema:
-   drop-first: false
-   contexts: crdb
-   enabled: true
-...
-~~~
-
-The `contexts` property specifies a single [Liquibase context](https://docs.liquibase.com/concepts/advanced/contexts.html) (`crdb`). In order for a changeset to run, its `context` attribute must match a context set by this property. The `context` value is `crdb` in both of the changeset definitions in `changelog-master.xml`, so both changesets run at application startup.
-
-For simplicity, `application.yml` only specifies properties for a single [Spring profile](https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-profiles), with a single set of Liquibase properties. If you want the changelog to include changesets that only run in specific environments (e.g., for debugging and development), you can create a new Spring profile in a separate properties file (e.g., `application-dev.yml`), and specify a different set of Liquibase properties for that profile. The profile set by the application configuration will automatically use the properties in that profile's properties file. For information about setting profiles, see the [Spring documentation website](https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-profiles).
-
-### Domain entities
-
-`Account.java` defines the [domain entity](https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks) for the `accounts` table. This class is used throughout the application to represent a row of data in the `accounts` table.
-
-Here are the contents of [`Account.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/Account.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/Account.java %}
-~~~
-
-### Hypermedia representation
-
-To represent database objects as [HAL+JSON](https://en.wikipedia.org/wiki/Hypertext_Application_Language) for the REST API, the application extends the Spring HATEOAS module's [RepresentationModel](https://docs.spring.io/spring-hateoas/docs/current/reference/html/#fundamentals.representation-models) class with `AccountModel`. Like the `Account` class, its attributes represent a row of data in the `accounts` table.
-
-The contents of [`AccountModel.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/AccountModel.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/AccountModel.java %}
-~~~
-
-We do not go into much detail about hypermedia representation in this tutorial. For more information, see the [Spring HATEOAS Reference Documentation](https://docs.spring.io/spring-hateoas/docs/current/reference/html/).
-
-### Spring repositories
-
-To abstract the database layer, Spring applications use the [`Repository` interface](https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/#repositories), or some subinterface of `Repository`. This interface maps to a database object, like a table, and its methods map to queries against that object, like a [`SELECT`](selection-queries.html) or an [`INSERT`](insert.html) statement against a table.
-
-[`AccountRepository.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/AccountRepository.java) defines the main repository for the `accounts` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/AccountRepository.java %}
-~~~
-
-`AccountRepository` extends a subinterface of `Repository` that is provided by Spring for generic [CRUD operations](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) called `CrudRepository`. To support [pagination queries](pagination.html), repositories in other Spring Data modules, like those in Spring Data JPA, usually extend a subinterface of `CrudRepository`, called `PagingAndSortingRepository`, that includes pagination and sorting methods. At the time this sample application was created, Spring Data JDBC did not support pagination. As a result, `AccountRepository` extends a custom repository, called `PagedAccountRepository`, to provide basic [`LIMIT`/`OFFSET` pagination](pagination.html) on queries against the `accounts` table. The `AccountRepository` methods use the [`@Query`](https://docs.spring.io/spring-data/jdbc/docs/current/reference/html/#jdbc.query-methods.at-query) annotation strategy to define queries manually, as strings.
-
-Note that, in addition to having the `@Repository` annotation, the `AccountRepository` interface has a [`@Transactional` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative-annotations). When [transaction management](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative) is enabled in an application (i.e., with [`@EnableTransactionManagement`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/EnableTransactionManagement.html)), Spring automatically wraps all objects with the `@Transactional` annotation in [a proxy](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-understanding-aop-proxies) that handles calls to the object. For more information, see [Understanding the Spring Framework’s Declarative Transaction Implementation](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#tx-decl-explained) on Spring's documentation website.
-
-`@Transactional` takes a number of parameters, including a `propagation` parameter that determines the transaction propagation behavior around an object (i.e., at what point in the stack a transaction starts and ends). This sample application follows the [entity-control-boundary (ECB) pattern](https://en.wikipedia.org/wiki/Entity-control-boundary). As such, the [REST service boundaries](#rest-controller) should determine where a [transaction](transactions.html) starts and ends rather than the query methods defined in the data access layer. To follow the ECB design pattern, `propagation=MANDATORY` for `AccountRepository`, which means that a transaction must already exist in order to call the `AccountRepository` query methods. In contrast, the `@Transactional` annotations on the [Rest controller entities](#rest-controller) in the web layer have `propagation=REQUIRES_NEW`, meaning that a new transaction must be created for each REST request.
-
-The aspects declared in `TransactionHintsAspect.java` and `RetryableTransactionAspect.java` further control how `@Transactional`-annotated components are handled. For more details on control flow and transaction management in the application, see [Transaction management](#transaction-management).
-
-### REST controller
-
-There are several endpoints exposed by the application's web layer, some of which monitor the health of the application, and some that map to queries executed against the connected database. All of the endpoints served by the application are handled by the `AccountController` class, which is defined in [`AccountController.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/AccountController.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/AccountController.java %}
-~~~
-
- Annotated with [`@RestController`](https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/bind/annotation/RestController.html), `AccountController` defines the primary [web controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) component of the application. The `AccountController` methods define the endpoints, routes, and business logic of REST services for account querying and money transferring. Its attributes include an instantiation of [`AccountRepository`](#spring-repositories), called `accountRepository`, that establishes an interface to the `accounts` table through the data access layer.
-
-As mentioned in the [Spring repositories](#spring-repositories) section, the application's transaction boundaries follow the [entity-control-boundary (ECB) pattern](https://en.wikipedia.org/wiki/Entity-control-boundary), meaning that the web service boundaries of the application determine where a [transaction](transactions.html) starts and ends. To follow the ECB pattern, the `@Transactional` annotation on each of the HTTP entities (`listAccounts()`, `getAccount()`, and `transfer()`) has `propagation=REQUIRES_NEW`. This ensures that each time a REST request is made to an endpoint, a new transaction context is created. For details on how aspects handle control flow and transaction management in the application, see [Transaction management](#transaction-management).
-
-### Transaction management
-
-When [transaction management](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative) is enabled in an application, Spring automatically wraps all objects annotated with `@Transactional` in [a proxy](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-understanding-aop-proxies) that handles calls to the object. By default, this proxy starts and closes transactions according to the configured transaction management behavior (e.g., the `propagation` level).
-
-Using [@AspectJ annotations](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative-aspectj), this sample application extends the default transaction proxy behavior with two other explicitly-defined [aspects](https://en.wikipedia.org/wiki/Aspect_(computer_programming)): `TransactionHintsAspect` and `RetryableTransactionAspect`. Methods of these aspects are declared as [advice](https://en.wikipedia.org/wiki/Advice_(programming)) to be executed around method calls annotated with `@Transactional`.
-
-For more information about transaction management in the app, see the following sections below:
-
-- [Ordering advice](#ordering-advice)
-- [Transaction attributes](#transaction-attributes)
-- [Transaction retries](#transaction-retries)
-
-#### Ordering advice
-
-To determine the order of evaluation when multiple transaction advisors match the same [pointcut](https://en.wikipedia.org/wiki/Pointcut) (in this case, around `@Transactional` method calls), this application explicitly declares an order of precedence for calling advice.
-
-At the top level of the application, in the main `JdbcApplication.java` file, the [`@EnableTransactionManagement`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/EnableTransactionManagement.html) annotation is passed an `order` parameter. This parameter sets the order on the primary transaction advisor to one level of precedence above the lowest level, `Ordered.LOWEST_PRECEDENCE`. This means that the advisor with the lowest level of precedence is evaluated after the primary transaction advisor (i.e., within the context of an open transaction).
-
-For the two explicitly-defined aspects, `TransactionHintsAspect` and `RetryableTransactionAspect`, the [`@Order`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/annotation/Order.html) annotation is used. Like the `order` parameter on the `@EnableTransactionManagement` annotation, `@Order` takes a value that indicates the precedence of advice. The advisor with the lowest level of precedence is declared in `TransactionHintsAspect`, the aspect that defines the [transaction attributes](#transaction-attributes). `RetryableTransactionAspect`, the aspect that defines the [transaction retry logic](#transaction-retries), defines the advisor with the highest level of precedence.
-
-For more details about advice ordering, see [Advice Ordering](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj-advice-ordering) on the Spring documentation site.
-
-
-#### Transaction attributes
-
-The `TransactionHintsAspect` class, declared as an aspect with the [`@Aspect` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-at-aspectj), declares an advice method that defines the attributes of a transaction. The `@Order` annotation is passed the lowest level of precedence, `Ordered.LOWEST_PRECEDENCE`, indicating that this advisor must run after the main transaction advisor, within the context of a transaction. Here are the contents of [`TransactionHintsAspect.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/TransactionHintsAspect.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/TransactionHintsAspect.java %}
-~~~
-
-The `anyTransactionBoundaryOperation` method is declared as a pointcut with the [`@Pointcut` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-pointcuts). In Spring, pointcut declarations must include an expression to determine where [join points](https://en.wikipedia.org/wiki/Join_point) occur in the application control flow. To help define these expressions, Spring supports a set of [designators](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-pointcuts-designators). The application uses two of them here: `execution`, which matches method execution joint points (i.e., defines a joint point when a specific method is executed, in this case, *any* method in the `io.roach.` namespace), and `@annotation`, which limits the matches to methods with a specific annotation, in this case `@Transactional`.
-
-`setTransactionAttributes` sets the transaction attributes in the form of advice. Spring supports [several different annotations to declare advice](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-advice). The [`@Around` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj-around-advice) allows an advice method to work before and after the `anyTransactionBoundaryOperation(transactional)` join point. It also allows the advice method to call the next matching advisor with the `ProceedingJoinPoint.proceed();` method.
-
-On verifying that the transaction is active (using `TransactionSynchronizationManager.isActualTransactionActive()`), the advice [sets some session variables](set-vars.html) using methods of the [`JdbcTemplate`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/jdbc/core/JdbcTemplate.html) object declared at the top of the `TransactionHintsAspect` class definition. These session variables (`application_name`, `statement_timeout`, and `transaction_read_only`) set [the application name](connection-parameters.html#additional-connection-parameters) for the query to "`roach-data`", the time allowed for the statement to execute before timing out to 1000 milliseconds (i.e., 1 second), and the [transaction access mode](set-transaction.html#parameters) as either `READ ONLY` or `READ WRITE`.
-
-#### Transaction retries
-
-Transactions may require retries if they experience deadlock or [transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention) that cannot be resolved without allowing [serialization](demo-serializable.html) anomalies. To handle transactions that are aborted due to transient serialization errors, we highly recommend writing [client-side transaction retry logic](transactions.html#client-side-intervention) into applications written on CockroachDB.
-
-In this application, transaction retry logic is written into the methods of the `RetryableTransactionAspect` class. This class is declared an aspect with the `@Aspect` annotation. The `@Order` annotation on this aspect class is passed `Ordered.LOWEST_PRECEDENCE-2`, a level of precedence above the primary transaction advisor. This indicates that the transaction retry advisor must run outside the context of a transaction. Here are the contents of [`RetryableTransactionAspect.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/RetryableTransactionAspect.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jdbc/src/main/java/io/roach/data/jdbc/RetryableTransactionAspect.java %}
-~~~
-
-The `anyTransactionBoundaryOperation` pointcut definition is identical to the one declared in `TransactionHintsAspect`. The `execution` designator matches all methods in the `io.roach.` namespace, and the `@annotation` designator limits the matches to methods with the `@Transactional` annotation.
-
-`retryableOperation` handles the application retry logic in the form of advice. The [`@Around` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj-around-advice) allows the advice method to work before and after an `anyTransactionBoundaryOperation(transactional)` join point. It also allows the advice method to call the next matching advisor.
-
-`retryableOperation` first verifies that there is no active transaction. It then increments the retry count and attempts to proceed to the next advice method with the `ProceedingJoinPoint.proceed()` method. If the underlying methods (i.e., the primary transaction advisor's methods and the [annotated query methods](#spring-repositories)) succeed, the transaction has been successfully committed to the database. The results are then returned and the application flow continues. If a failure in the underlying layers occurs due to a transient error ([`TransientDataAccessException`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/dao/TransientDataAccessException.html) or [`TransactionSystemException`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/TransactionSystemException.html)), then the transaction is retried. The time between each retry grows with each retry until the maximum number of retries is reached.
-
-## See also
-
-Spring documentation:
-
-- [Spring Boot website](https://spring.io/projects/spring-boot)
-- [Spring Framework Overview](https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html#overview)
-- [Spring Core documentation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#spring-core)
-- [Data Access with JDBC](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#jdbc)
-- [Spring Web MVC](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc)
-
-CockroachDB documentation:
-
-- [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
-- [Client Connection Parameters](connection-parameters.html)
-- [CockroachDB Developer Guide](developer-guide-overview.html)
-- [Hello World Example Apps](example-apps.html)
-- [Transactions](transactions.html)
diff --git a/src/current/v20.2/build-a-spring-app-with-cockroachdb-jpa.md b/src/current/v20.2/build-a-spring-app-with-cockroachdb-jpa.md
deleted file mode 100644
index 4f5fd80a2c5..00000000000
--- a/src/current/v20.2/build-a-spring-app-with-cockroachdb-jpa.md
+++ /dev/null
@@ -1,708 +0,0 @@
----
-title: Build a Spring App with CockroachDB and JPA
-summary: Learn how to use CockroachDB from a Spring application with Spring Data JPA and Hibernate.
-toc: true
-twitter: false
-referral_id: docs_roach_data_java_spring_jpa
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-spring-app-with-cockroachdb-jdbc.html"><button style="width: 28%" class="filter-button">Use <strong>JDBC</strong></button></a>
-    <a href="build-a-spring-app-with-cockroachdb-jpa.html"><button style="width: 28%" class="filter-button current">Use <strong>JPA</strong></button></a>
-</div>
-
-This tutorial shows you how to build a [Spring Boot](https://spring.io/projects/spring-boot) web application with CockroachDB, using the [Spring Data JPA](https://spring.io/projects/spring-data-jpa) module for data access. The code for the example application is available for download from [GitHub](https://github.com/cockroachlabs/roach-data/tree/master), along with identical examples that use [JDBC](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-jdbc), [jOOQ](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-jooq), and [MyBatis](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-mybatis) for data access.
-
-## Step 1. Start CockroachDB
-
-Choose whether to run a local cluster or a free cluster on CockroachDB {{ site.data.products.cloud }}.
-
-<div class="filters clearfix">
-  <button class="filter-button page-level" data-scope="cockroachcloud">Use CockroachDB {{ site.data.products.cloud }}</button>
-  <button class="filter-button page-level" data-scope="local">Use a Local Cluster</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-1. If you haven't already, [download the CockroachDB binary](install-cockroachdb.html).
-1. [Start a local, secure cluster](secure-a-cluster.html).
-
-</section>
-
-  <section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-### Create a free cluster
-
-{% include cockroachcloud/quickstart/create-a-free-cluster.md %}
-
-### Set up your cluster connection
-
-{% include cockroachcloud/quickstart/set-up-your-cluster-connection.md %}
-
-  </section>
-
-## Step 2. Create a database and a user
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-1. Open a SQL shell to your local cluster using the [`cockroach sql`](cockroach-sql.html) command:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir={certs-dir} --host=localhost:{port}
-    ~~~
-
-    Where `{certs_dir}` is the full path to the `certs` directory that you created when setting up the cluster, and `{port}` is the port at which the cluster is listening for incoming connections.
-
-1. In the SQL shell, create the `roach_data` database that your application will use:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE roach_data;
-    ~~~
-
-1. Create a SQL user for your app:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER {username} WITH PASSWORD {password};
-    ~~~
-
-    Take note of the username and password. You will use it to connect to the database later.
-
-1. Give the user the necessary permissions:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > GRANT ALL ON DATABASE roach_data TO {username};
-    ~~~
-
-1. Exit the shell, and generate a certificate and key for your user by running the following command:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client {user} --certs-dir=certs --ca-key={certs-dir}/ca.key --also-generate-pkcs8-key
-~~~
-
-The [`--also-generate-pkcs8-key` flag](cockroach-cert.html#flag-pkcs8) generates a key in [PKCS#8 format](https://tools.ietf.org/html/rfc5208), which is the standard key encoding format in Java. In this case, the generated PKCS8 key will be named `client.{user}.key.pk8`.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-1. If you haven't already, [download the CockroachDB binary](install-cockroachdb.html).
-1. Start the [built-in SQL shell](cockroach-sql.html) using the connection string you got from the CockroachDB {{ site.data.products.cloud }} Console [earlier](#set-up-your-cluster-connection):
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --url='postgres://{username}:{password}@{global host}:26257/{cluster_name}.defaultdb?sslmode=verify-full&sslrootcert={certs_dir}/cc-ca.crt'
-    ~~~
-
-    In the connection string copied from the CockroachDB {{ site.data.products.cloud }} Console, your username, password and cluster name are pre-populated. Replace the `{certs_dir}` placeholder with the path to the `certs` directory that you created [earlier](#set-up-your-cluster-connection).
-
-    {% include cockroachcloud/cc-no-user-certs.md %}
-
-1. In the SQL shell, create the `roach_data` database that your application will use:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE roach_data;
-    ~~~
-
-</section>
-
-## Step 3. Install JDK
-
-Download and install a Java Development Kit on your machine. Spring Boot supports Java versions 8, 11, and 14. In this tutorial, we use [JDK 8 from OpenJDK](https://openjdk.java.net/install/).
-
-## Step 4. Install Maven
-
-This example application uses [Maven](http://maven.apache.org/) to manage all application dependencies. Spring supports Maven versions 3.2 and later.
-
-To install Maven on macOS, run the following command:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ brew install maven
-~~~
-
-To install Maven on a Debian-based Linux distribution like Ubuntu:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ apt-get install maven
-~~~
-
-To install Maven on a Red Hat-based Linux distribution like Fedora:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ dnf install maven
-~~~
-
-For other ways to install Maven, see [its official documentation](http://maven.apache.org/install.html).
-
-## Step 5. Get the application code
-
-To get the application code, download or clone the [`roach-data` repository](https://github.com/cockroachlabs/roach-data). The code for the example JPA application is located under the `roach-data-jpa` directory.
-
-(*Optional*) To recreate the application project structure with the same dependencies as those used by this sample application, you can use [Spring initializr](https://start.spring.io/) with the following settings:
-
-**Project**
-
-- Maven Project
-
-**Language**
-
-- Java
-
-**Spring Boot**
-
-- 2.2.6
-
-**Project Metadata**
-
-- Group: io.roach
-- Artifact: data
-- Name: data
-- Package name: io.roach.data
-- Packaging: Jar
-- Java: 8
-
-**Dependencies**
-
-- Spring Web
-- Spring Data JPA
-- Spring HATEOS
-- Liquibase Migration
-- PostgreSQL Driver
-
-The [Hibernate CockroachDB dialect](https://in.relation.to/2020/07/27/hibernate-orm-5419-final-release/) is supported in Hibernate v5.4.19+. At the time of writing this tutorial, Spring Data JPA used Hibernate v5.4.15 as its default JPA provider. To specify a different version of Hibernate than the default, add an additional entry to your application's `pom.xml` file, as shown in [the `roach-data` GitHub repo](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jpa/pom.xml):
-
-~~~ xml
-<dependency>
-    <groupId>org.hibernate</groupId>
-    <artifactId>hibernate-core</artifactId>
-    <version>5.4.19.Final</version>
-</dependency>
-~~~
-
-## Step 6. Run the application
-
-Compiling and running the application code will start a web application, initialize the `accounts` table in the `roach_data` database, and submit some requests to the app's REST API that result in [atomic database transactions](transactions.html) on the running CockroachDB cluster. For details about the application code, see [Implementation details](#implementation-details).
-
-Open the `roach-data/roach-data-jpa/src/main/resources/application.yml` file and edit the `datasource` settings to connect to your running database cluster:
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-~~~ yml
-...
-datasource:
-  url: jdbc:postgresql://localhost:{port}/roach_data?ssl=true&sslmode=require&sslrootcert={certs-dir}/ca.crt&sslkey={certs-dir}/client.{username}.key.pk8&sslcert={certs-dir}/client.{username}.crt
-  username: {username}
-  password: {password}
-  driver-class-name: org.postgresql.Driver
-...
-~~~
-
-Where:
-
-- `{port}` is the port number.
-- `{certs-dir}` is the full path to the certificates directory containing the authentication certificates that you created earlier.
-- `{username}` and `{password}` specify the SQL username and password that you created earlier.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-~~~ yml
-...
-datasource:
-  url: jdbc:postgresql://{globalhost}:{port}/{cluster_name}.roach_data?sslmode=verify-full&sslrootcert={path to the CA certificate}/cc-ca.crt
-  username: {username}
-  password: {password}
-  driver-class-name: org.postgresql.Driver
-...
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-</section>
-
-Open a terminal, and navigate to the `roach-data-jpa` project subfolder:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cd <path>/roach-data/roach-data-jpa
-~~~
-
-Use Maven to download the application dependencies and compile the code:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ mvn clean install
-~~~
-
-From the `roach-data-jpa` directory, run the application JAR file:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ java -jar target/roach-data-jpa.jar
-~~~
-
-The output should look like the following:
-
-~~~
-  .   ____          _            __ _ _
- /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
-( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
- \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
-  '  |____| .__|_| |_|_| |_\__, | / / / /
- =========|_|==============|___/=/_/_/_/
- :: Spring Boot ::        (v2.2.7.RELEASE)
-
-2020-06-22 11:54:46.243  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Starting JpaApplication v1.0.0.BUILD-SNAPSHOT on MyComputer.local with PID 81343 (path/code/roach-data/roach-data-jpa/target/roach-data-jpa.jar started by user in path/code/roach-data/roach-data-jpa)
-2020-06-22 11:54:46.246  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : No active profile set, falling back to default profiles: default
-2020-06-22 11:54:46.929  INFO 81343 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Multiple Spring Data modules found, entering strict repository configuration mode!
-2020-06-22 11:54:46.930  INFO 81343 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JPA repositories in DEFAULT mode.
-2020-06-22 11:54:47.023  INFO 81343 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 80ms. Found 1 JPA repository interfaces.
-2020-06-22 11:54:47.211  INFO 81343 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Multiple Spring Data modules found, entering strict repository configuration mode!
-2020-06-22 11:54:47.211  INFO 81343 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Bootstrapping Spring Data JDBC repositories in DEFAULT mode.
-2020-06-22 11:54:47.224  INFO 81343 --- [           main] .RepositoryConfigurationExtensionSupport : Spring Data JDBC - Could not safely identify store assignment for repository candidate interface io.roach.data.jpa.AccountRepository. If you want this repository to be a JDBC repository, consider annotating your entities with one of these annotations: org.springframework.data.relational.core.mapping.Table.
-2020-06-22 11:54:47.224  INFO 81343 --- [           main] .s.d.r.c.RepositoryConfigurationDelegate : Finished Spring Data repository scanning in 12ms. Found 0 JDBC repository interfaces.
-2020-06-22 11:54:47.913  INFO 81343 --- [           main] org.eclipse.jetty.util.log               : Logging initialized @2990ms to org.eclipse.jetty.util.log.Slf4jLog
-2020-06-22 11:54:47.982  INFO 81343 --- [           main] o.s.b.w.e.j.JettyServletWebServerFactory : Server initialized with port: 9090
-2020-06-22 11:54:47.985  INFO 81343 --- [           main] org.eclipse.jetty.server.Server          : jetty-9.4.28.v20200408; built: 2020-04-08T17:49:39.557Z; git: ab228fde9e55e9164c738d7fa121f8ac5acd51c9; jvm 11.0.7+10
-2020-06-22 11:54:48.008  INFO 81343 --- [           main] o.e.j.s.h.ContextHandler.application     : Initializing Spring embedded WebApplicationContext
-2020-06-22 11:54:48.008  INFO 81343 --- [           main] o.s.web.context.ContextLoader            : Root WebApplicationContext: initialization completed in 1671 ms
-2020-06-22 11:54:48.123  INFO 81343 --- [           main] org.eclipse.jetty.server.session         : DefaultSessionIdManager workerName=node0
-2020-06-22 11:54:48.123  INFO 81343 --- [           main] org.eclipse.jetty.server.session         : No SessionScavenger set, using defaults
-2020-06-22 11:54:48.124  INFO 81343 --- [           main] org.eclipse.jetty.server.session         : node0 Scavenging every 660000ms
-2020-06-22 11:54:48.130  INFO 81343 --- [           main] o.e.jetty.server.handler.ContextHandler  : Started o.s.b.w.e.j.JettyEmbeddedWebAppContext@41394595{application,/,[file:///private/var/folders/pg/r58v54857gq_1nqm_2tr6lg40000gn/T/jetty-docbase.7785392427958606416.8080/],AVAILABLE}
-2020-06-22 11:54:48.131  INFO 81343 --- [           main] org.eclipse.jetty.server.Server          : Started @3207ms
-2020-06-22 11:54:48.201  INFO 81343 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
-2020-06-22 11:54:48.483  INFO 81343 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
-2020-06-22 11:54:49.507  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT COUNT(*) FROM public.databasechangeloglock
-2020-06-22 11:54:49.522  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : CREATE TABLE public.databasechangeloglock (ID INTEGER NOT NULL, LOCKED BOOLEAN NOT NULL, LOCKGRANTED TIMESTAMP WITHOUT TIME ZONE, LOCKEDBY VARCHAR(255), CONSTRAINT DATABASECHANGELOGLOCK_PKEY PRIMARY KEY (ID))
-2020-06-22 11:54:49.535  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT COUNT(*) FROM public.databasechangeloglock
-2020-06-22 11:54:49.554  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : DELETE FROM public.databasechangeloglock
-2020-06-22 11:54:49.555  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.databasechangeloglock (ID, LOCKED) VALUES (1, FALSE)
-2020-06-22 11:54:49.562  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
-2020-06-22 11:54:49.570  INFO 81343 --- [           main] l.lockservice.StandardLockService        : Successfully acquired change log lock
-2020-06-22 11:54:50.519  INFO 81343 --- [           main] l.c.StandardChangeLogHistoryService      : Creating database history table with name: public.databasechangelog
-2020-06-22 11:54:50.520  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : CREATE TABLE public.databasechangelog (ID VARCHAR(255) NOT NULL, AUTHOR VARCHAR(255) NOT NULL, FILENAME VARCHAR(255) NOT NULL, DATEEXECUTED TIMESTAMP WITHOUT TIME ZONE NOT NULL, ORDEREXECUTED INTEGER NOT NULL, EXECTYPE VARCHAR(10) NOT NULL, MD5SUM VARCHAR(35), DESCRIPTION VARCHAR(255), COMMENTS VARCHAR(255), TAG VARCHAR(255), LIQUIBASE VARCHAR(20), CONTEXTS VARCHAR(255), LABELS VARCHAR(255), DEPLOYMENT_ID VARCHAR(10))
-2020-06-22 11:54:50.534  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT COUNT(*) FROM public.databasechangelog
-2020-06-22 11:54:50.547  INFO 81343 --- [           main] l.c.StandardChangeLogHistoryService      : Reading from public.databasechangelog
-2020-06-22 11:54:50.548  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT * FROM public.databasechangelog ORDER BY DATEEXECUTED ASC, ORDEREXECUTED ASC
-2020-06-22 11:54:50.550  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT COUNT(*) FROM public.databasechangeloglock
-2020-06-22 11:54:50.566  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : create table account
-(
-    id      int            not null primary key default unique_rowid(),
-    balance numeric(19, 2) not null,
-    name    varchar(128)   not null,
-    type    varchar(25)    not null
-)
-2020-06-22 11:54:50.575  INFO 81343 --- [           main] liquibase.changelog.ChangeSet            : SQL in file db/create.sql executed
-2020-06-22 11:54:50.581  INFO 81343 --- [           main] liquibase.changelog.ChangeSet            : ChangeSet classpath:db/changelog-master.xml::1::root ran successfully in 16ms
-2020-06-22 11:54:50.585  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : SELECT MAX(ORDEREXECUTED) FROM public.databasechangelog
-2020-06-22 11:54:50.589  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('1', 'root', 'classpath:db/changelog-master.xml', NOW(), 1, '8:567321cdb0100cbe76731a7ed414674b', 'sqlFile', '', 'EXECUTED', 'crdb', NULL, '3.8.9', '2852090551')
-2020-06-22 11:54:50.593  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.account (id, name, balance, type) VALUES ('1', 'Alice', 500.00, 'asset')
-2020-06-22 11:54:50.601  INFO 81343 --- [           main] liquibase.changelog.ChangeSet            : New row inserted into account
-2020-06-22 11:54:50.602  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.account (id, name, balance, type) VALUES ('2', 'Bob', 500.00, 'expense')
-2020-06-22 11:54:50.603  INFO 81343 --- [           main] liquibase.changelog.ChangeSet            : New row inserted into account
-2020-06-22 11:54:50.604  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.account (id, name, balance, type) VALUES ('3', 'Bobby Tables', 500.00, 'asset')
-2020-06-22 11:54:50.605  INFO 81343 --- [           main] liquibase.changelog.ChangeSet            : New row inserted into account
-2020-06-22 11:54:50.605  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.account (id, name, balance, type) VALUES ('4', 'Doris', 500.00, 'expense')
-2020-06-22 11:54:50.606  INFO 81343 --- [           main] liquibase.changelog.ChangeSet            : New row inserted into account
-2020-06-22 11:54:50.608  INFO 81343 --- [           main] liquibase.changelog.ChangeSet            : ChangeSet classpath:db/changelog-master.xml::2::root ran successfully in 16ms
-2020-06-22 11:54:50.609  INFO 81343 --- [           main] liquibase.executor.jvm.JdbcExecutor      : INSERT INTO public.databasechangelog (ID, AUTHOR, FILENAME, DATEEXECUTED, ORDEREXECUTED, MD5SUM, DESCRIPTION, COMMENTS, EXECTYPE, CONTEXTS, LABELS, LIQUIBASE, DEPLOYMENT_ID) VALUES ('2', 'root', 'classpath:db/changelog-master.xml', NOW(), 2, '8:c2945f2a445cf60b4b203e1a91d14a89', 'insert tableName=account; insert tableName=account; insert tableName=account; insert tableName=account', '', 'EXECUTED', 'crdb', NULL, '3.8.9', '2852090551')
-2020-06-22 11:54:50.615  INFO 81343 --- [           main] l.lockservice.StandardLockService        : Successfully released change log lock
-2020-06-22 11:54:50.727  INFO 81343 --- [           main] o.hibernate.jpa.internal.util.LogHelper  : HHH000204: Processing PersistenceUnitInfo [name: default]
-2020-06-22 11:54:50.817  INFO 81343 --- [           main] org.hibernate.Version                    : HHH000412: Hibernate ORM core version 5.4.19.Final
-2020-06-22 11:54:50.993  INFO 81343 --- [           main] o.hibernate.annotations.common.Version   : HCANN000001: Hibernate Commons Annotations {5.1.0.Final}
-2020-06-22 11:54:51.154  INFO 81343 --- [           main] org.hibernate.dialect.Dialect            : HHH000400: Using dialect: org.hibernate.dialect.CockroachDB201Dialect
-2020-06-22 11:54:51.875  INFO 81343 --- [           main] o.h.e.t.j.p.i.JtaPlatformInitiator       : HHH000490: Using JtaPlatform implementation: [org.hibernate.engine.transaction.jta.platform.internal.NoJtaPlatform]
-2020-06-22 11:54:51.886  INFO 81343 --- [           main] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'
-2020-06-22 11:54:52.700  INFO 81343 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Initializing ExecutorService 'applicationTaskExecutor'
-2020-06-22 11:54:52.958  INFO 81343 --- [           main] o.e.j.s.h.ContextHandler.application     : Initializing Spring DispatcherServlet 'dispatcherServlet'
-2020-06-22 11:54:52.958  INFO 81343 --- [           main] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'
-2020-06-22 11:54:52.966  INFO 81343 --- [           main] o.s.web.servlet.DispatcherServlet        : Completed initialization in 8 ms
-2020-06-22 11:54:52.997  INFO 81343 --- [           main] o.e.jetty.server.AbstractConnector       : Started ServerConnector@1568159{HTTP/1.1, (http/1.1)}{0.0.0.0:9090}
-2020-06-22 11:54:52.999  INFO 81343 --- [           main] o.s.b.web.embedded.jetty.JettyWebServer  : Jetty started on port(s) 9090 (http/1.1) with context path '/'
-2020-06-22 11:54:53.001  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Started JpaApplication in 7.518 seconds (JVM running for 8.077)
-2020-06-22 11:54:53.002  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Lets move some $$ around!
-2020-06-22 11:54:54.399  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Worker finished - 7 remaining
-2020-06-22 11:54:54.447  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Worker finished - 6 remaining
-2020-06-22 11:54:54.447  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Worker finished - 5 remaining
-2020-06-22 11:54:54.447  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Worker finished - 4 remaining
-2020-06-22 11:54:54.447  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Worker finished - 3 remaining
-2020-06-22 11:54:54.447  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Worker finished - 2 remaining
-2020-06-22 11:54:54.447  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Worker finished - 1 remaining
-2020-06-22 11:54:54.447  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : Worker finished - 0 remaining
-2020-06-22 11:54:54.447  INFO 81343 --- [           main] io.roach.data.jpa.JpaApplication         : All client workers finished but server keeps running. Have a nice day!
-~~~
-
-As the output states, the application configures a database connection, starts a web servlet listening on the address `http://localhost:9090/`, initializes the `account` table and changelog tables with [Liquibase](https://www.liquibase.org/), and then runs some test operations as requests to the application's REST API.
-
-For more details about the application code, see [Implementation details](#implementation-details).
-
-### Query the database
-
-#### Reads
-
-The `http://localhost:9090/account` endpoint returns information about all accounts in the database. `GET` requests to these endpoints are executed on the database as `SELECT` statements.
-
-The following `curl` command sends a `GET` request to the endpoint. The `json_pp` command formats the JSON response.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account | json_pp
-~~~
-
-~~~
-{
-   "_embedded" : {
-      "accounts" : [
-         {
-            "_links" : {
-               "self" : {
-                  "href" : "http://localhost:9090/account/1"
-               }
-            },
-            "balance" : 500,
-            "name" : "Alice",
-            "type" : "asset"
-         },
-         {
-            "_links" : {
-               "self" : {
-                  "href" : "http://localhost:9090/account/2"
-               }
-            },
-            "balance" : 500,
-            "name" : "Bob",
-            "type" : "expense"
-         },
-         {
-            "_links" : {
-               "self" : {
-                  "href" : "http://localhost:9090/account/3"
-               }
-            },
-            "balance" : 500,
-            "name" : "Bobby Tables",
-            "type" : "asset"
-         },
-         {
-            "_links" : {
-               "self" : {
-                  "href" : "http://localhost:9090/account/4"
-               }
-            },
-            "balance" : 500,
-            "name" : "Doris",
-            "type" : "expense"
-         }
-      ]
-   },
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account?page=0&size=5"
-      }
-   },
-   "page" : {
-      "number" : 0,
-      "size" : 5,
-      "totalElements" : 4,
-      "totalPages" : 1
-   }
-}
-~~~
-
-For a single account, specify the account number in the endpoint. For example, to see information about the accounts `1` and `2`:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account/1 | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account/1"
-      }
-   },
-   "balance" : 500,
-   "name" : "Alice",
-   "type" : "asset"
-}
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account/2 | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account/2"
-      }
-   },
-   "balance" : 500,
-   "name" : "Bob",
-   "type" : "expense"
-}
-~~~
-
-The `http://localhost:9090/transfer` endpoint performs transfers between accounts. `POST` requests to this endpoint are executed as writes (i.e., [`INSERT`s](insert.html) and [`UPDATE`s](update.html)) to the database.
-
-#### Writes
-
-To make a transfer, send a `POST` request to the `transfer` endpoint, using the arguments specified in the `"href`" URL (i.e., `http://localhost:9090/transfer%7B?fromId,toId,amount`).
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X POST -d fromId=2 -d toId=1 -d amount=150 http://localhost:9090/transfer
-~~~
-
-You can use the `accounts` endpoint to verify that the transfer was successfully completed:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account/1 | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account/1"
-      }
-   },
-   "balance" : 650,
-   "name" : "Alice",
-   "type" : "asset"
-}
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl -X GET http://localhost:9090/account/2 | json_pp
-~~~
-
-~~~
-{
-   "_links" : {
-      "self" : {
-         "href" : "http://localhost:9090/account/2"
-      }
-   },
-   "balance" : 350,
-   "name" : "Bob",
-   "type" : "expense"
-}
-~~~
-
-## Implementation details
-
-This section walks you through the different components of the application project in detail.
-
-### Main application process
-
-`JpaApplication.java` defines the application's main process. It starts a Spring Boot web application, and then submits requests to the app's REST API that result in database transactions on the CockroachDB cluster.
-
-Here are the contents of [`JpaApplication.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jpa/src/main/java/io/roach/data/jpa/JpaApplication.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jpa/src/main/java/io/roach/data/jpa/JpaApplication.java %}
-~~~
-
-The annotations listed at the top of the `JpaApplication` class definition declare some important configuration properties for the entire application:
-
-- [`@EnableHypermediaSupport`](https://docs.spring.io/spring-hateoas/docs/current/api/org/springframework/hateoas/config/EnableHypermediaSupport.html) enables [hypermedia support for resource representation](https://en.wikipedia.org/wiki/HATEOAS) in the application. Currently, the only hypermedia format supported by Spring is [HAL](https://en.wikipedia.org/wiki/Hypertext_Application_Language), and so the `type = EnableHypermediaSupport.HypermediaType.HAL`. For details, see [Hypermedia representation](#hypermedia-representation).
-- [`@EnableJpaRepositories`](https://docs.spring.io/spring-data/data-jpa/docs/current/api/org/springframework/data/jpa/repository/config/EnableJpaRepositories.html) enables the creation of [Spring repositories](https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories) for data access using [Spring Data JPA](https://spring.io/projects/spring-data-jpa). For details, see [Spring repositories](#spring-repositories).
-- [`@EnableAspectJAutoProxy`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/context/annotation/EnableAspectJAutoProxy.html) enables the use of [`@AspectJ` annotations for declaring aspects](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj). For details, see [Transaction management](#transaction-management).
-- [`@EnableTransactionManagement`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/EnableTransactionManagement.html) enables [declarative transaction management](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative) in the application. For details, see [Transaction management](#transaction-management).
-
-    Note that the `@EnableTransactionManagement` annotation is passed an `order` parameter, which indicates the ordering of advice evaluation when a common join point is reached. For details, see [Ordering advice](#ordering-advice).
-- [`@SpringBootApplication`](https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/autoconfigure/SpringBootApplication.html) is a standard configuration annotation used by Spring Boot applications. For details, see [Using the @SpringBootApplication](https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-using-springbootapplication-annotation) on the Spring Boot documentation site.
-
-### Schema management
-
-To create and initialize the database schema, the application uses [Liquibase](https://www.liquibase.org/).
-
-Liquibase uses files called [changelogs](https://docs.liquibase.com/concepts/basic/changelog.html) to manage the changes to the database. Changelog files include a list of instructions, known as [changesets](https://docs.liquibase.com/concepts/basic/changeset.html), that are executed against the database in a specified order.
-
-`resources/db/changelog-master.xml` defines the changelog for this application:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jpa/src/main/resources/db/changelog-master.xml %}
-~~~
-
-The first changeset uses [the `sqlFile` tag](https://docs.liquibase.com/change-types/community/sql-file.html), which tells Liquibase that an external `.sql` file contains some SQL statements to execute. The file specified by the changeset, `resources/db/create.sql`, creates the `account` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jpa/src/main/resources/db/create.sql %}
-~~~
-
-The second changeset in the changelog uses the [Liquibase XML syntax](https://docs.liquibase.com/concepts/basic/xml-format.html) to specify a series of sequential `INSERT` statements that initialize the `account` table with some values.
-
-When the application is started, all of the queries specified by the changesets are executed in the order specified by their `changeset` tag's `id` value. At application startup, Liquibase also creates a table called [`databasechangelog`](https://docs.liquibase.com/concepts/databasechangelog-table.html) in the database where it performs changes. This table's rows log all completed changesets.
-
-To see the completed changesets, open a new terminal, start the [built-in SQL shell](cockroach-sql.html), and query the `databasechangelog` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs
-~~~
-
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM roach_data.databasechangelog;
-~~~
-
-~~~
-  id | author |             filename              |           dateexecuted           | orderexecuted | exectype |               md5sum               |                                              description                                               | comments | tag  | liquibase | contexts | labels | deployment_id
------+--------+-----------------------------------+----------------------------------+---------------+----------+------------------------------------+--------------------------------------------------------------------------------------------------------+----------+------+-----------+----------+--------+----------------
-  1  | root   | classpath:db/changelog-master.xml | 2020-06-17 14:57:01.431506+00:00 |             1 | EXECUTED | 8:939a1a8c47676119a94d0173802d207e | sqlFile                                                                                                |          | NULL | 3.8.9     | crdb     | NULL   | 2420221402
-  2  | root   | classpath:db/changelog-master.xml | 2020-06-17 14:57:01.470847+00:00 |             2 | EXECUTED | 8:c2945f2a445cf60b4b203e1a91d14a89 | insert tableName=account; insert tableName=account; insert tableName=account; insert tableName=account |          | NULL | 3.8.9     | crdb     | NULL   | 2420221402
-(2 rows)
-~~~
-
-Typically, Liquibase properties are defined in a separate [`liquibase.properties`](https://docs.liquibase.com/workflows/liquibase-community/creating-config-properties.html) file. In this application, `application.yml`, the properties file that sets the [Spring properties](https://docs.spring.io/spring-boot/docs/current/reference/html/appendix-application-properties.html), also includes some properties that enable and configure Liquibase:
-
-~~~ yml
-...
- liquibase:
-   change-log: classpath:db/changelog-master.xml
-   default-schema:
-   drop-first: false
-   contexts: crdb
-   enabled: true
-...
-~~~
-
-### Domain entities
-
-`Account.java` defines the [entity](https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks) for the `accounts` table. This class is used throughout the application to represent a row of data in the `accounts` table.
-
-Here are the contents of [`Account.java`](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-jpa/src/main/java/io/roach/data/jpa/Account.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jpa/src/main/java/io/roach/data/jpa/Account.java %}
-~~~
-
-Spring Data JPA supports standard Java Persistence API (JPA) annotations for domain entity class definitions. The `Account` class definition uses these annotations to create the `accounts` table entity:
-
-- `@Entity` declares the `Account` an entity class.
-- `@Table` associates the entity with the persisted `account` table.
-- `@Column` declare each private attribute a column of the `account` table.
-- `@GeneratedValue` indicates that the value for the column should be automatically generated.
-- `@Id` declares the [primary key column](primary-key.html) of the table.
-- `@Enumerated` specifies the type of data that the column holds.
-
-### Hypermedia representation
-
-To represent database objects as [HAL+JSON](https://en.wikipedia.org/wiki/Hypertext_Application_Language) for the REST API, the application extends the Spring HATEOAS module's [RepresentationModel](https://docs.spring.io/spring-hateoas/docs/current/reference/html/#fundamentals.representation-models) class with `AccountModel`. Like the `Account` class, its attributes represent a row of data in the `accounts` table.
-
-The contents of [`AccountModel.java`](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-jpa/src/main/java/io/roach/data/jpa/AccountModel.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jpa/src/main/java/io/roach/data/jpa/AccountModel.java %}
-~~~
-
-We do not go into much detail about hypermedia representation in this tutorial. For more information, see the [Spring HATEOAS Reference Documentation](https://docs.spring.io/spring-hateoas/docs/current/reference/html/).
-
-### Spring repositories
-
-To abstract the database layer, Spring applications use the [`Repository` interface](https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories), or some subinterface of `Repository`. This interface maps to a database object, like a table, and its methods map to queries against that object, like a [`SELECT`](selection-queries.html) or an [`INSERT`](insert.html) statement against a table.
-
-[`AccountRepository.java`](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-jpa/src/main/java/io/roach/data/jpa/AccountRepository.java) defines the main repository for the `accounts` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jpa/src/main/java/io/roach/data/jpa/AccountRepository.java %}
-~~~
-
-`AccountRepository` extends a subinterface of `Repository` that is provided by Spring for JPA data access called `JpaRepository`. The `AccountRepository` methods use the [`@Query`](https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#jpa.query-methods.at-query) annotation strategy to define queries manually, as strings.
-
-Note that, in addition to having the `@Repository` annotation, the `AccountRepository` interface has a [`@Transactional` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative-annotations). When [transaction management](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative) is enabled in an application (i.e., with [`@EnableTransactionManagement`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/EnableTransactionManagement.html)), Spring automatically wraps all objects with the `@Transactional` annotation in [a proxy](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-understanding-aop-proxies) that handles calls to the object.
-
-`@Transactional` takes a number of parameters, including a `propagation` parameter that determines the transaction propagation behavior around an object (i.e., at what point in the stack a transaction starts and ends). This sample application follows the [entity-control-boundary (ECB) pattern](https://en.wikipedia.org/wiki/Entity-control-boundary). As such, the [REST service boundaries](#rest-controller) should determine where a [transaction](transactions.html) starts and ends rather than the query methods defined in the data access layer. To follow the ECB design pattern, `propagation=MANDATORY` for `AccountRepository`, which means that a transaction must already exist in order to call the `AccountRepository` query methods. In contrast, the `@Transactional` annotations on the [Rest controller entities](#rest-controller) in the web layer have `propagation=REQUIRES_NEW`, meaning that a new transaction must be created for each REST request.
-
-For details about control flow and transaction management in this application, see [Transaction management](#transaction-management). For more general information about Spring transaction management, see [Understanding the Spring Framework’s Declarative Transaction Implementation](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#tx-decl-explained) on Spring's documentation website.
-
-### REST controller
-
-There are several endpoints exposed by the application's web layer, some of which monitor the health of the application, and some that map to queries executed against the connected database. All of the endpoints served by the application are handled by the `AccountController` class, which is defined in [`AccountController.java`](https://github.com/cockroachlabs/roach-data/tree/master/roach-data-jpa/src/main/java/io/roach/data/jpa/AccountController.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jpa/src/main/java/io/roach/data/jpa/AccountController.java %}
-~~~
-
- Annotated with [`@RestController`](https://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/web/bind/annotation/RestController.html), `AccountController` defines the primary [web controller](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller) component of the application. The `AccountController` methods define the endpoints, routes, and business logic of REST services for account querying and money transferring. Its attributes include an instantiation of [`AccountRepository`](#spring-repositories), called `accountRepository`, that establishes an interface to the `accounts` table through the data access layer.
-
-As mentioned in the [Spring repositories](#spring-repositories) section, the application's transaction boundaries follow the [entity-control-boundary (ECB) pattern](https://en.wikipedia.org/wiki/Entity-control-boundary), meaning that the web service boundaries of the application determine where a [transaction](transactions.html) starts and ends. To follow the ECB pattern, the `@Transactional` annotation on each of the HTTP entities (`listAccounts()`, `getAccount()`, and `transfer()`) has `propagation=REQUIRES_NEW`. This ensures that each time a REST request is made to an endpoint, a new transaction context is created.
-
-For details on how aspects handle control flow and transaction management in the application, see [Transaction management](#transaction-management).
-
-### Transaction management
-
-When [transaction management](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative) is enabled in an application, Spring automatically wraps all objects annotated with `@Transactional` in [a proxy](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-understanding-aop-proxies) that handles calls to the object. By default, this proxy starts and closes transactions according to the configured transaction management behavior (e.g., the `propagation` level). The proxy methods that handle transactions make up the *primary transaction advisor*.
-
-Using [@AspectJ annotations](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative-aspectj), this sample application extends the default transaction proxy behavior to handle [transaction retries](#transaction-retries) with another explicitly-defined [aspect](https://en.wikipedia.org/wiki/Aspect_(computer_programming)): `RetryableTransactionAspect`. Methods of this aspect are declared as [advice](https://en.wikipedia.org/wiki/Advice_(programming)) to be executed around method calls annotated with `@Transactional`.
-
-#### Ordering advice
-
-To determine the order of evaluation when multiple transaction advisors match the same [pointcut](https://en.wikipedia.org/wiki/Pointcut) (in this case, around `@Transactional` method calls), this application explicitly declares an order of precedence for calling advice.
-
-The [`@Order`](https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/core/annotation/Order.html) annotation takes a value that indicates the precedence of its advice. In the case of `RetryableTransactionAspect`, the annotation is passed `Ordered.LOWEST_PRECEDENCE-1`, which places the retry advisor one level of precedence above the lowest level. By default, the primary transaction advisor has the lowest level of precedence (`Ordered.LOWEST_PRECEDENCE`). This means that the retry logic will be evaluated before a transaction is opened.
-
-For more details about advice ordering, see [Advice Ordering](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj-advice-ordering) on the Spring documentation site.
-
-#### Transaction retries
-
-Transactions may require retries if they experience deadlock or [transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention) that cannot be resolved without allowing [serialization](demo-serializable.html) anomalies. To handle transactions that are aborted due to transient serialization errors, we highly recommend writing [client-side transaction retry logic](transactions.html#client-side-intervention) into applications written on CockroachDB.
-
-In this application, transaction retry logic is written into the methods of the `RetryableTransactionAspect` class, declared an aspect with the `@Aspect` annotation. Here are the contents of [`RetryableTransactionAspect.java`](https://github.com/cockroachlabs/roach-data/blob/master/roach-data-jpa/src/main/java/io/roach/data/jpa/RetryableTransactionAspect.java):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/roach-data/master/roach-data-jpa/src/main/java/io/roach/data/jpa/RetryableTransactionAspect.java %}
-~~~
-
-The `anyTransactionBoundaryOperation` method is declared as a pointcut with the [`@Pointcut` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-pointcuts). In Spring, pointcut declarations must include an expression to determine where [join points](https://en.wikipedia.org/wiki/Join_point) occur in the application control flow. To help define these expressions, Spring supports a set of [designators](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-pointcuts-designators). The application uses two of them here: `execution`, which matches method execution joint points (i.e., defines a joint point when a specific method is executed, in this case, *any* method in the `io.roach.` namespace), and `@annotation`, which limits the matches to methods with a specific annotation, in this case `@Transactional`.
-
-`retryableOperation` handles the application retry logic in the form of advice. Spring supports [several different annotations to declare advice](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-advice). The [`@Around` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj-around-advice) allows an advice method to work before and after the `anyTransactionBoundaryOperation(transactional)` join point. It also allows the advice method to call the next matching advisor with the `ProceedingJoinPoint.proceed();` method.
-
-`retryableOperation` first verifies that there is no active transaction. It then increments the retry count and attempts to proceed to the next advice method with the `ProceedingJoinPoint.proceed()` method. If the underlying methods (i.e., the primary transaction advisor's methods and the [annotated query methods](#spring-repositories)) succeed, the transaction has been successfully committed to the database. The results are then returned and the application flow continues. If a failure in the underlying layers occurs due to a transient error, then the transaction is retried. The time between each retry grows with each retry until the maximum number of retries is reached.
-
-## See also
-
-Spring documentation:
-
-- [Spring Boot website](https://spring.io/projects/spring-boot)
-- [Spring Framework Overview](https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html#overview)
-- [Spring Core documentation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#spring-core)
-- [Accessing Data with JPA](https://spring.io/guides/gs/accessing-data-jpa/)
-- [Data Access with JDBC](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#jpa)
-- [Spring Web MVC](https://docs.spring.io/spring/docs/current/spring-framework-reference/web.html#mvc)
-
-CockroachDB documentation:
-
-- [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
-- [Client Connection Parameters](connection-parameters.html)
-- [CockroachDB Developer Guide](developer-guide-overview.html)
-- [Hello World Example Apps](example-apps.html)
-- [Transactions](transactions.html)
diff --git a/src/current/v20.2/build-a-spring-app-with-cockroachdb-mybatis.md b/src/current/v20.2/build-a-spring-app-with-cockroachdb-mybatis.md
deleted file mode 100644
index 38fee705d3d..00000000000
--- a/src/current/v20.2/build-a-spring-app-with-cockroachdb-mybatis.md
+++ /dev/null
@@ -1,418 +0,0 @@
----
-title: Build a Spring App with CockroachDB and MyBatis
-summary: Learn how to use CockroachDB from a simple Spring application with MyBatis.
-toc: true
-twitter: false
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-java-app-with-cockroachdb.html"><button class="filter-button">Use <strong>JDBC</strong></button></a>
-    <a href="build-a-java-app-with-cockroachdb-hibernate.html"><button class="filter-button">Use <strong>Hibernate</strong></button></a>
-    <a href="build-a-java-app-with-cockroachdb-jooq.html"><button class="filter-button">Use <strong>jOOQ</strong></button></a>
-    <a href="build-a-spring-app-with-cockroachdb-mybatis.html"><button style="width: 25%" class="filter-button current">Use <strong>MyBatis-Spring</strong></button></a>
-</div>
-
-This tutorial shows you how to build a simple [Spring Boot](https://spring.io/projects/spring-boot) application with CockroachDB, using the [MyBatis-Spring-Boot-Starter module](http://mybatis.org/spring-boot-starter) for data access.
-
-## Before you begin
-
-{% include {{page.version.version}}/app/before-you-begin.md %}
-
-## Step 1. Install JDK
-
-Download and install a Java Development Kit. MyBatis-Spring supports Java versions 8+. In this tutorial, we use [JDK 11 from OpenJDK](https://openjdk.java.net/install/).
-
-## Step 2. Install Gradle
-
-This example application uses [Gradle](https://gradle.org/) to manage all application dependencies. Spring supports Gradle versions 6+.
-
-To install Gradle on macOS, run the following command:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ brew install gradle
-~~~
-
-To install Gradle on a Debian-based Linux distribution like Ubuntu:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ apt-get install gradle
-~~~
-
-To install Gradle on a Red Hat-based Linux distribution like Fedora:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ dnf install gradle
-~~~
-
-For other ways to install Gradle, see [its official documentation](https://docs.gradle.org/current/userguide/installation.html).
-
-## Step 3. Get the application code
-
-To get the application code, download or clone the [`mybatis-cockroach-demo` repository](https://github.com/jeffgbutler/mybatis-cockroach-demo).
-
-## Step 4. Create the `maxroach` user and `bank` database
-
-<section class="filter-content" markdown="1" data-scope="secure">
-
-Start the [built-in SQL shell](cockroach-sql.html):
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs
-~~~
-
-In the SQL shell, issue the following statements to create the `maxroach` user and `bank` database:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE USER IF NOT EXISTS maxroach;
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE bank;
-~~~
-
-Give the `bank` user the necessary permissions:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON DATABASE bank TO maxroach;
-~~~
-
-Exit the SQL shell:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> \q
-~~~
-
-## Step 5. Generate a certificate for the `maxroach` user
-
-Create a certificate and key for the `maxroach` user by running the following command. The code samples will run as this user.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client maxroach --certs-dir=certs --ca-key=my-safe-directory/ca.key --also-generate-pkcs8-key
-~~~
-
-The [`--also-generate-pkcs8-key` flag](cockroach-cert.html#flag-pkcs8) generates a key in [PKCS#8 format](https://tools.ietf.org/html/rfc5208), which is the standard key encoding format in Java. In this case, the generated PKCS8 key will be named `client.maxroach.key.pk8`.
-
-## Step 6. Run the application
-
-To run the application:
-
-1. Open and edit the `src/main/resources/application.yml` file so that the `url` field specifies the full [connection string](connection-parameters.html#connect-using-a-url) to the [running CockroachDB cluster](#before-you-begin). To connect to a secure cluster, this connection string must set the `sslmode` connection parameter to `require`, and specify the full path to the client, node, and user certificates in the connection parameters. For example:
-
-      {% include_cached copy-clipboard.html %}
-      ~~~ yml
-      ...
-      datasource:
-        url: jdbc:postgresql://localhost:26257/bank?ssl=true&sslmode=require&sslrootcert=certs/ca.crt&sslkey=certs/client.maxroach.key.pk8&sslcert=certs/client.maxroach.crt
-      ...
-      ~~~
-1. Open a terminal, and navigate to the `mybatis-cockroach-demo` project directory:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ cd <path>/mybatis-cockroach-demo
-    ~~~
-
-1. Run the Gradle script to download the application dependencies, compile the code, and run the application:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ ./gradlew bootRun
-    ~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-
-Start the [built-in SQL shell](cockroach-sql.html):
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure
-~~~
-
-In the SQL shell, issue the following statements to create the `maxroach` user and `bank` database:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE USER IF NOT EXISTS maxroach;
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE bank;
-~~~
-
-Give the `bank` user the necessary permissions:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON DATABASE bank TO maxroach;
-~~~
-
-Exit the SQL shell:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> \q
-~~~
-
-## Step 6. Run the application
-
-To run the application:
-
-1. Open and edit the `src/main/resources/application.yml` file so that the `url` field specifies the full [connection string](connection-parameters.html#connect-using-a-url) to the [running CockroachDB cluster](#before-you-begin). For example:
-
-      ~~~ yaml
-      ...
-      datasource:
-        url: jdbc:postgresql://localhost:26257/bank?ssl=false
-      ...
-      ~~~
-1. Open a terminal, and navigate to the `mybatis-cockroach-demo` project directory:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ cd <path>/mybatis-cockroach-demo
-    ~~~
-
-1. Run the Gradle script to download the application dependencies, compile the code, and run the application:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ ./gradlew bootRun
-    ~~~
-
-</section>
-
-The output should look like the following:
-
-~~~
-> Task :bootRun
-
-  .   ____          _            __ _ _
- /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
-( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
- \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
-  '  |____| .__|_| |_|_| |_\__, | / / / /
- =========|_|==============|___/=/_/_/_/
- :: Spring Boot ::        (v2.2.6.RELEASE)
-
-2020-06-01 14:40:04.333  INFO 55970 --- [           main] c.e.c.CockroachDemoApplication           : Starting CockroachDemoApplication on MyComputer with PID 55970 (path/mybatis-cockroach-demo/build/classes/java/main started by user in path/mybatis-cockroach-demo)
-2020-06-01 14:40:04.335  INFO 55970 --- [           main] c.e.c.CockroachDemoApplication           : No active profile set, falling back to default profiles: default
-2020-06-01 14:40:05.195  INFO 55970 --- [           main] c.e.c.CockroachDemoApplication           : Started CockroachDemoApplication in 1.39 seconds (JVM running for 1.792)
-2020-06-01 14:40:05.216  INFO 55970 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
-2020-06-01 14:40:05.611  INFO 55970 --- [           main] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Start completed.
-deleteAllAccounts:
-    => 2 total deleted accounts
-insertAccounts:
-    => 2 total new accounts in 1 batches
-printNumberOfAccounts:
-    => Number of accounts at time '14:40:05.660226':
-    => 2 total accounts
-printBalances:
-    => Account balances at time '14:40:05.678942':
-    ID 1 => $1000
-    ID 2 => $250
-transferFunds:
-    => $100 transferred between accounts 1 and 2, 2 rows updated
-printBalances:
-    => Account balances at time '14:40:05.688511':
-    ID 1 => $900
-    ID 2 => $350
-bulkInsertRandomAccountData:
-    => finished, 500 total rows inserted in 1 batches
-printNumberOfAccounts:
-    => Number of accounts at time '14:40:05.960214':
-    => 502 total accounts
-2020-06-01 14:40:05.968  INFO 55970 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown initiated...
-2020-06-01 14:40:05.993  INFO 55970 --- [extShutdownHook] com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Shutdown completed.
-
-BUILD SUCCESSFUL in 12s
-3 actionable tasks: 3 executed
-~~~
-
-The application runs a number of test functions that result in reads and writes to the `accounts` table in the `bank` database.
-
-For more details about the application code, see [Application details](#application-details).
-
-## Application details
-
-This section walks you through the different components of the application project in detail.
-
-### Main process
-
-The main process of the application is defined in `src/main/java/com/example/cockroachdemo/CockroachDemoApplication.java`:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/CockroachDemoApplication.java %}
-~~~
-
-The `SpringApplication.run` call in the `main` method bootstraps and launches a Spring application. The [`@SpringBootApplication` annotation](https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-using-springbootapplication-annotation) on the `CockroachDemoApplication` class triggers Spring's [component scanning](https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-structuring-your-code) and [auto-configuration](https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-auto-configuration) features.
-
-The `BasicExample` class, defined in `src/main/java/com/example/cockroachdemo/BasicExample.java`, is one of the components detected in the component scan:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/BasicExample.java %}
-~~~
-
-`BasicExample` implements the [Spring `CommandLineRunner` interface](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#boot-features-command-line-runner). Implementations of this interface automatically run when detected in a Spring project directory. `BasicExample` runs a series of test methods that are eventually executed as SQL queries in the [data access layer of the application](#mappers).
-
-### Configuration
-
-All [MyBatis-Spring](https://mybatis.org/spring/) applications need a [`DataSource`](https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-configure-datasource), a [`SqlSessionFactory`](https://mybatis.org/spring/factorybean.html), and at least one [mapper interface](https://mybatis.org/spring/mappers.html). The [MyBatis-Spring-Boot-Starter](https://mybatis.org/spring-boot-starter/mybatis-spring-boot-autoconfigure) module, built on [MyBatis](https://mybatis.org/mybatis-3/) and MyBatis-Spring, and used by this application, greatly simplifies how you configure each of these required elements.
-
-Applications that use MyBatis-Spring-Boot-Starter typically need just an annotated mapper interface and an existing `DataSource` in the Spring environment. The module detects the `DataSource`, creates a `SqlSessionFactory` from the `DataSource`, creates a thread-safe [`SqlSessionTemplate`](https://mybatis.org/spring/sqlsession.html#SqlSessionTemplate) with the `SqlSessionFactory`, and then auto-scans the mappers and links them to the `SqlSessionTemplate` for injection. The `SqlSessionTemplate` automatically commits, rolls back, and closes sessions, based on the application's [Spring-based transaction configuration](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction).
-
-This sample application implements [batch write operations](insert.html#performance-best-practices), a CockroachDB best practice for executing multiple `INSERT` and `UPSERT` statements. MyBatis applications that support batch operations require some additional configuration work, even if the application uses MyBatis-Spring-Boot-Starter:
-
-- The application must define a specific mapper interface for batch query methods.
-- The application must define a `SqlSessionTemplate` constructor, specifically for batch operations, that uses the [`BATCH` executor type](https://mybatis.org/mybatis-3/apidocs/reference/org/apache/ibatis/executor/BatchExecutor.html).
-- The batch mapper must be explicitly registered with the batch-specific `SqlSessionTemplate`.
-
-The class defined in `src/main/java/com/example/cockroachdemo/MyBatisConfiguration.java` configures the application to meet these requirements:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/MyBatisConfiguration.java %}
-~~~
-
-This class explicitly defines the batch `SqlSessionTemplate` (i.e., `batchSqlSessionTemplate`), and registers `batchmapper`, the batch mapper interface defined in [`src/main/java/com/example/cockroachdemo/batchmapper/BatchMapper.java`](#mappers) with `batchSqlSessionTemplate`. To complete the MyBatis configuration, the class also declares a `DataSource`, and defines the remaining `SqlSessionFactory` and `SqlSessionTemplate` beans.
-
-Note that a configuration class is not required for MyBatis-Spring-Boot-Starter applications that do not implement batch operations.
-
-### Data source
-
-`src/main/resources/application.yml` contains the metadata used to create a connection to the CockroachDB cluster:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/resources/application.yml %}
-~~~
-
-Spring Boot uses the application's `datasource` property [to auto-configure the database connection](https://docs.spring.io/spring-boot/docs/current/reference/html/spring-boot-features.html#boot-features-configure-datasource). This database connection configuration can be injected into the application's `SqlSessionFactoryBean`, as is explicitly done in the [MyBatisConfiguration](#configuration) configuration class definition.
-
-### Mappers
-
-All MyBatis applications require at least one mapper interface. These mappers take the place of manually-defined data access objects (DAOs). They provide other layers of the application an interface to the database.
-
-MyBatis-Spring-Boot-Starter usually scans the project for interfaces annotated with `@Mapper`, links the interfaces to a `SqlSessionTemplate`, and registers them with Spring so they can be [injected into the application's Spring beans](https://docs.spring.io/spring-boot/docs/current/reference/html/using-spring-boot.html#using-boot-spring-beans-and-dependency-injection). As mentioned in the [Configuration section](#configuration), because the application supports batch writes, the two mapper interfaces in the application are registered and linked manually in the `MyBatisConfiguration` configuration class definition.
-
-#### Account mapper
-
-`src/main/java/com/example/cockroachdemo/mapper/AccountMapper.java` defines the mapper interface to the `accounts` table using the [MyBatis Java API](https://mybatis.org/mybatis-3/java-api.html):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/mapper/AccountMapper.java %}
-~~~
-
-The `@Mapper` annotation declares the interface a mapper for MyBatis to scan. The SQL statement annotations on each of the interface methods map them to SQL queries. For example, the first method, `deleteAllAccounts()` is marked as a `DELETE` statement with the `@Delete` annotation. This method executes the SQL statement specified in the string passed to the annotation, "`delete from accounts`", which deletes all rows in the `accounts` table.
-
-#### Batch account mapper
-
-`src/main/java/com/example/cockroachdemo/batchmapper/BatchAccountMapper.java` defines a mapper interface for [batch writes](insert.html#performance-best-practices):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/batchmapper/BatchAccountMapper.java %}
-~~~
-
-This interface has a single `INSERT` statement query method, along with a method for flushing (i.e., executing) a batch of statements.
-
-### Services
-
-`src/main/java/com/example/cockroachdemo/service/AccountService.java` defines the service interface, with a number of methods for reading and writing to the database:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/service/AccountService.java %}
-~~~
-
-`MyBatisAccountService.java` implements the `AccountService` interface, using the mappers defined in [`AccountMapper.java` and `BatchAccountMapper.java`](#mappers), and the models defined in [`Account.java` and `BatchResults.java`](#models):
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/service/MyBatisAccountService.java %}
-~~~
-
-Note that the public methods (i.e., the methods to be called by other classes in the project) are annotated as [`@Transactional`](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative-annotations) methods. This ensures that all of the SQL statements executed in the data access layer are run within the context of a [database transaction](transactions.html)
-
-`@Transactional` takes a number of parameters, including a `propagation` parameter that determines the transaction propagation behavior around an object (i.e., at what point in the stack a transaction starts and ends). `propagation=REQUIRES_NEW` for the methods in the service layer, meaning that a new transaction must be created each time a request is made to the service layer. With this propagation behavior, the application follows the [entity-control-boundary (ECB) pattern](https://en.wikipedia.org/wiki/Entity-control-boundary), as the service boundaries determine where a [transaction](transactions.html) starts and ends rather than the lower-level query methods of the [mapper interfaces](#mappers).
-
-For more details on aspect-oriented transaction management in this application, [see below](#transaction-management).
-
-### Models
-
-Instances of the `Account` class, defined in `src/main/java/com/example/cockroachdemo/model/Account.java`, represent rows in the `accounts` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/model/Account.java %}
-~~~
-
-Instances of the `BatchResults` class, defined in `src/main/java/com/example/cockroachdemo/model/BatchResults.java`, hold metadata about a batch write operation and its results:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/model/BatchResults.java %}
-~~~
-
-### Transaction management
-
-MyBatis-Spring supports Spring's [declarative, aspect-oriented transaction management syntax](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative), including the [`@Transactional`](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative-annotations) annotation and [AspectJ's AOP annotations](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#transaction-declarative-aspectj).
-
-Transactions may require retries if they experience deadlock or [transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention) that cannot be resolved without allowing [serialization](demo-serializable.html) anomalies. To handle transactions that are aborted due to transient serialization errors, we highly recommend writing [client-side transaction retry logic](transactions.html#client-side-intervention) into applications written on CockroachDB. In this application, transaction retry logic is written into the methods of the `RetryableTransactionAspect` class, defined in `src/main/java/com/example/cockroachdemo/RetryableTransactionAspect.java`:
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-{% remote_include https://raw.githubusercontent.com/jeffgbutler/mybatis-cockroach-demo/master/src/main/java/com/example/cockroachdemo/RetryableTransactionAspect.java %}
-~~~
-
-The [`@Aspect` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-at-aspectj) declares `RetryableTransactionAspect` an [aspect](https://en.wikipedia.org/wiki/Aspect_(computer_programming)), with [pointcut](https://en.wikipedia.org/wiki/Pointcut) and [advice](https://en.wikipedia.org/wiki/Advice_(programming)) methods.
-
-#### Transactional pointcut
-
-The [`@Pointcut` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-pointcuts) declares the `anyTransactionBoundaryOperation` method the pointcut for determining when to execute the aspect's advice. The `@annotation` [designator](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-pointcuts-designators) passed to the `@Pointcut` annotation limits the matches (i.e., [join points](https://en.wikipedia.org/wiki/Join_point)) to method calls with a specific annotation, in this case, `@Transactional`.
-
-#### Transaction retry advice
-
-`retryableOperation` handles the application retry logic, with [exponential backoff](https://en.wikipedia.org/wiki/Exponential_backoff), as the advice to execute at an `anyTransactionBoundaryOperation(transactional)` join point. Spring supports [several different annotations to declare advice](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-advice). The [`@Around` annotation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj-around-advice) allows an advice method to work before and after the join point. It also gives the advice method control over executing any other matching advisors.
-
-`retryableOperation` first verifies that there is no active transaction. It then increments the retry count and attempts to proceed to the next advice method with the `ProceedingJoinPoint.proceed()` method. If the underlying data access layer method (i.e., the mapper interface method annotated with `@Transactional`) succeeds, the results are returned and the application flow continues. If the method fails, then the transaction is retried. The time between each retry grows with each retry until the maximum number of retries is reached.
-
-#### Advice ordering
-
-Spring automatically adds [transaction management advice](https://docs.spring.io/spring/docs/current/spring-framework-reference/data-access.html#tx-decl-explained) to all methods annotated with `@Transactional`. Because the pointcut for `RetryableTransactionAspect` also matches methods annotated with `@Transactional`, there will always be two advisors that match the same pointcut. When multiple advisors match at the same pointcut, an `@Order` annotation on an advisor's aspect can specify the order in which the advice should be evaluated.
-
-To control when and how often a transaction is retried, the transaction retry advice must be executed outside the context of a transaction (i.e., it must be evaluated before the primary transaction management advisor). By default, the primary transaction management advisor is given the lowest level of precedence. The `@Order` annotation on `RetryableTransactionAspect` is passed `Ordered.LOWEST_PRECEDENCE-1`, which places this aspect's advice at a level of precedence above the primary transaction advisor, which results in the retry logic being evaluated before the transaction management advisor.
-
-For more details about advice ordering in Spring, see [Advice Ordering](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-ataspectj-advice-ordering) on the Spring documentation site.
-
-## See also
-
-Spring documentation:
-
-- [Spring Boot website](https://spring.io/projects/spring-boot)
-- [Spring Framework Overview](https://docs.spring.io/spring/docs/current/spring-framework-reference/overview.html#overview)
-- [Spring Core documentation](https://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#spring-core)
-- [MyBatis documentation](https://mybatis.org/mybatis-3/)
-- [MyBatis Spring integration](https://mybatis.org/spring/)
-
-CockroachDB documentation:
-
-- [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
-- [Client Connection Parameters](connection-parameters.html)
-- [CockroachDB Developer Guide](developer-guide-overview.html)
-- [Hello World Example Apps](example-apps.html)
-- [Transactions](transactions.html)
diff --git a/src/current/v20.2/build-a-typescript-app-with-cockroachdb.md b/src/current/v20.2/build-a-typescript-app-with-cockroachdb.md
deleted file mode 100644
index 60d57cfd4b9..00000000000
--- a/src/current/v20.2/build-a-typescript-app-with-cockroachdb.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Build a TypeScript App with CockroachDB and TypeORM
-summary: Learn how to use CockroachDB with the TypeORM framework.
-toc: true
-twitter: false
-referral_id: docs_hello_world_typescript_typeorm
----
-
-<div class="filters filters-big clearfix">
-    <a href="build-a-nodejs-app-with-cockroachdb.html"><button class="filter-button">Use <strong>pg</strong></button></a>
-    <a href="build-a-nodejs-app-with-cockroachdb-sequelize.html"><button class="filter-button">Use <strong>Sequelize</strong></button></a>
-    <a href="build-a-typescript-app-with-cockroachdb.html"><button class="filter-button current">Use <strong>TypeORM</strong></button></a>
-</div>
-
-This tutorial shows you how run a simple application built with [TypeORM](https://typeorm.io/#/).
-
-## Step 1. Start CockroachDB
-
-{% include {{page.version.version}}/app/start-cockroachdb.md %}
-
-## Step 2. Create a database
-
-{% include {{page.version.version}}/app/create-a-database.md %}
-
-## Step 3. Get the code
-
-1. Clone [the code's GitHub repository](https://github.com/cockroachlabs/example-app-typescript-typeorm):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ git clone git@github.com:cockroachlabs/example-app-typescript-typeorm.git
-    ~~~
-
-1. Navigate to the repo directory and install the application dependencies:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cd example-app-typescript-typeorm
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ npm install
-    ~~~
-
-## Step 4. Configure your CockroachDB connection
-
-<section class="filter-content" markdown="1" data-scope="local">
-
-1. Open the `datasource.ts` file, and comment out the `ssl: true`, `extra` and `options` configuration properties.
-
-1. In the `datasource.ts` file, uncomment `ssl: { rejectUnauthorized: false }`.
-
-    {{site.data.alerts.callout_danger}}
-    Only use `ssl: { rejectUnauthorized: false }` in development, for insecure connections.
-    {{site.data.alerts.end}}
-
-    The `DataSource` configuration should look similar to the following:
-
-    ~~~ ts
-    export const AppDataSource = new DataSource({
-        type: "cockroachdb",
-        url: process.env.DATABASE_URL,
-        ssl: { rejectUnauthorized: false }, // For insecure connections only
-        /* ssl: true,
-        extra: {
-            options: "--cluster=<routing-id>"
-        }, */
-        synchronize: true,
-        logging: false,
-        entities: ["src/entity/**/*.ts"],
-        migrations: ["src/migration/**/*.ts"],
-        subscribers: ["src/subscriber/**/*.ts"],
-    })
-    ~~~
-
-1. Set the `DATABASE_URL` environment variable to the connection string provided in the `cockroach demo` welcome text.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="cockroachcloud">
-
-1. Open the `datasource.ts` file, and edit the `--cluster=<routing-id>` configuration property to specify the routing ID to your serverless cluster.
-
-1. Set the `DATABASE_URL` environment variable to a CockroachDB connection string compatible with TypeORM.
-
-    TypeORM accepts the following format for CockroachDB {{ site.data.products.serverless }} connection strings:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    postgresql://<username>:<password>@<host>:<port>/<database>
-    ~~~
-
-</section>
-
-## Step 5. Run the code
-
-Start the application:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ npm start
-~~~
-
-You should see the following output in your terminal:
-
-~~~
-Inserting a new account into the database...
-Saved a new account.
-Printing balances from account 1db0f34a-55e8-42e7-adf1-49e76010b763.
-[
-  Account { id: '1db0f34a-55e8-42e7-adf1-49e76010b763', balance: 1000 }
-]
-Inserting a new account into the database...
-Saved a new account.
-Printing balances from account 4e26653a-3821-48c8-a481-47eb73b3e4cc.
-[
-  Account { id: '4e26653a-3821-48c8-a481-47eb73b3e4cc', balance: 250 }
-]
-Transferring 500 from account 1db0f34a-55e8-42e7-adf1-49e76010b763 to account 4e26653a-3821-48c8-a481-47eb73b3e4cc.
-Transfer complete.
-Printing balances from account 1db0f34a-55e8-42e7-adf1-49e76010b763.
-[
-  Account { id: '1db0f34a-55e8-42e7-adf1-49e76010b763', balance: 1000 }
-]
-Printing balances from account 4e26653a-3821-48c8-a481-47eb73b3e4cc.
-[
-  Account { id: '4e26653a-3821-48c8-a481-47eb73b3e4cc', balance: 250 }
-]
-~~~
-
-## What's next?
-
-Read more about using the [TypeORM](https://typeorm.io/#/).
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/bulk-delete-data.md b/src/current/v20.2/bulk-delete-data.md
deleted file mode 100644
index 90f4ffece53..00000000000
--- a/src/current/v20.2/bulk-delete-data.md
+++ /dev/null
@@ -1,201 +0,0 @@
----
-title: Bulk-delete Data
-summary: How to delete a large amount of data from a cluster
-toc: true
----
-
-To delete a large number of rows (i.e., tens of thousands of rows or more), we recommend iteratively deleting subsets of the rows that you want to delete, until all of the unwanted rows have been deleted. You can write a script to do this, or you can write a loop into your application.
-
-This page provides guidance on batch deleting with the `DELETE` query filter [on an indexed column](#batch-delete-on-an-indexed-column) and [on a non-indexed column](#batch-delete-on-a-non-indexed-column). Filtering on an indexed column is both simpler to implement and more efficient, but adding an index to a table can slow down insertions to the table and may cause bottlenecks. Queries that filter on a non-indexed column must perform at least one full-table scan, a process that takes time proportional to the size of the entire table.
-
-{{site.data.alerts.callout_success}}
-If you want to delete all of the rows in a table (and not just a large subset of the rows), use a [`TRUNCATE` statement](#delete-all-of-the-rows-in-a-table).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_danger}}
-Exercise caution when batch deleting rows from tables with foreign key constraints and explicit [`ON DELETE` foreign key actions](foreign-key.html#foreign-key-actions). To preserve `DELETE` performance on tables with foreign key actions, we recommend using smaller batch sizes, as additional rows updated or deleted due to `ON DELETE` actions can make batch loops significantly slower.
-{{site.data.alerts.end}}
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Install a Postgres client](install-client-drivers.html).
-
-    For the example on this page, we use the `psycopg2` Python driver.
-- [Connect to the database](connect-to-the-database.html).
-- [Insert data](insert-data.html) that you now want to delete.
-
-    For the example on this page, we load a cluster with the [`tpcc` database](cockroach-workload.html#tpcc-workload) and data from [`cockroach workload`](cockroach-workload.html).
-
-## Batch delete on an indexed column
-
-For high-performance batch deletes, we recommending filtering the `DELETE` query on an [indexed column](indexes.html).
-
-{{site.data.alerts.callout_info}}
-Having an indexed filtering column can make delete operations faster, but it might lead to bottlenecks in execution, especially if the filtering column is a [timestamp](timestamp.html). To reduce bottlenecks, we recommend using a [hash-sharded index](hash-sharded-indexes.html).
-{{site.data.alerts.end}}
-
-Each iteration of a batch-delete loop should execute a transaction containing a single `DELETE` query. When writing this `DELETE` query:
-
-- Use a `WHERE` clause to filter on a column that identifies the unwanted rows. If the filtering column is not the primary key, the column should have [a secondary index](indexes.html). Note that if the filtering column is not already indexed, it is not beneficial to add an index just to speed up batch deletes. Instead, consider [batch deleting on non-indexed columns](#batch-delete-on-a-non-indexed-column).
-- To ensure that rows are efficiently scanned in the `DELETE` query, add an [`ORDER BY`](order-by.html) clause on the filtering column.
-- Use a [`LIMIT`](limit-offset.html) clause to limit the number of rows to the desired batch size. To determine the optimal batch size, try out different batch sizes (1,000 rows, 10,000 rows, 100,000 rows, etc.) and monitor the change in performance.
-- Add a `RETURNING` clause to the end of the query that returns the filtering column values of the deleted rows. Then, using the values of the deleted rows, update the filter to match only the subset of remaining rows to delete. This narrows each query's scan to the fewest rows possible, and [preserves the performance of the deletes over time](delete.html#preserving-delete-performance-over-time). This pattern assumes that no new rows are generated that match on the `DELETE` filter during the time that it takes to perform the delete.
-
-For example, suppose that you want to delete all rows in the [`tpcc`](cockroach-workload.html#tpcc-workload) `new_order` table where `no_w_id` is less than `5`, in batches of 5,000 rows. To do this, you can write a script that loops over batches of 5,000 rows, following the `DELETE` query guidance provided above. Note that in this case, `no_w_id` is the first column in the primary index, and, as a result, you do not need to create a secondary index on the column.
-
-In Python, the script would look similar to the following:
-
-{% include copy-clipboard.html %}
-~~~ python
-#!/usr/bin/env python3
-
-import psycopg2
-import psycopg2.sql
-import os
-
-conn = psycopg2.connect(os.environ.get('DB_URI'))
-filter = 4
-lastrow = None
-
-while True:
-  with conn:
-    with conn.cursor() as cur:
-        if lastrow:
-            filter = lastrow[0]
-        query = psycopg2.sql.SQL("DELETE FROM new_order WHERE no_w_id <= %s ORDER BY no_w_id DESC LIMIT 5000 RETURNING no_w_id")
-        cur.execute(query, (filter,))
-        print(cur.statusmessage)
-        if cur.rowcount == 0:
-            break
-        lastrow = cur.fetchone()
-
-conn.close()
-~~~
-
-This script iteratively deletes rows in batches of 5,000, until all of the rows where `no_w_id <= 4` are deleted. Note that at each iteration, the filter is updated to match a narrower subset of rows.
-
-## Batch delete on a non-indexed column
-
-If you cannot index the column that identifies the unwanted rows, we recommend defining the batch loop to execute separate read and write operations at each iteration:
-
-1. Execute a [`SELECT` query](selection-queries.html) that returns the primary key values for the rows that you want to delete. When writing the `SELECT` query:
-    - Use a `WHERE` clause that filters on the column identifying the rows.
-    - Add an [`AS OF SYSTEM TIME` clause](as-of-system-time.html) to the end of the selection subquery, or run the selection query in a separate, read-only transaction with [`SET TRANSACTION AS OF SYSTEM TIME`](as-of-system-time.html#using-as-of-system-time-in-transactions). This helps to reduce [transaction contention](transactions.html#transaction-contention).
-    - Use a [`LIMIT`](limit-offset.html) clause to limit the number of rows queried to a subset of the rows that you want to delete. To determine the optimal `SELECT` batch size, try out different sizes (10,000 rows, 100,000 rows, 1,000,000 rows, etc.), and monitor the change in performance. Note that this `SELECT` batch size can be much larger than the batch size of rows that are deleted in the subsequent `DELETE` query.
-    - To ensure that rows are efficiently scanned in the subsequent `DELETE` query, include an [`ORDER BY`](order-by.html) clause on the primary key.
-
-2. Write a nested `DELETE` loop over the primary key values returned by the `SELECT` query, in batches smaller than the initial `SELECT` batch size. To determine the optimal `DELETE` batch size, try out different sizes (1,000 rows, 10,000 rows, 100,000 rows, etc.), and monitor the change in performance. Where possible, we recommend executing each `DELETE` in a separate transaction.
-
-For example, suppose that you want to delete all rows in the [`tpcc`](cockroach-workload.html#tpcc-workload) `history` table that are older than a month. You can create a script that loops over the data and deletes unwanted rows in batches, following the query guidance provided above.
-
-In Python, the script would look similar to the following:
-
-{% include copy-clipboard.html %}
-~~~ python
-#!/usr/bin/env python3
-
-import psycopg2
-import os
-import time
-
-conn = psycopg2.connect(os.environ.get('DB_URI'))
-
-while True:
-    with conn:
-        with conn.cursor() as cur:
-            cur.execute("SET TRANSACTION AS OF SYSTEM TIME '-5s'")
-            cur.execute("SELECT h_w_id, rowid FROM history WHERE h_date < current_date() - INTERVAL '1 MONTH' ORDER BY h_w_id, rowid LIMIT 20000")
-            pkvals = list(cur)
-    if not pkvals:
-        return
-    while pkvals:
-        batch = pkvals[:5000]
-        pkvals = pkvals[5000:]
-        with conn:
-            with conn.cursor() as cur:
-                cur.execute("DELETE FROM history WHERE (h_w_id, rowid) = ANY %s", (batch,))
-                print(cur.statusmessage)
-    del batch
-    del pkvals
-    time.sleep(5)
-
-conn.close()
-~~~
-
-At each iteration, the selection query returns the primary key values of up to 20,000 rows of matching historical data from 5 seconds in the past, in a read-only transaction. Then, a nested loop iterates over the returned primary key values in smaller batches of 5,000 rows. At each iteration of the nested `DELETE` loop, a batch of rows is deleted. After the nested `DELETE` loop deletes all of the rows from the initial selection query, a time delay ensures that the next selection query reads historical data from the table after the last iteration's `DELETE` final delete.
-
-{{site.data.alerts.callout_info}}
- CockroachDB records the timestamp of each row created in the database with the `crdb_internal_mvcc_timestamp` metadata column. In the absence of an explicit timestamp column in your table, you can use `crdb_internal_mvcc_timestamp` to filter expired data.
-
-Note that `crdb_internal_mvcc_timestamp` cannot be indexed. As a result, we recommend following the non-indexed column pattern shown above if you plan to use `crdb_internal_mvcc_timestamp` as a filter for large deletes.
-{{site.data.alerts.end}}
-
-## Batch-delete "expired" data
-
-CockroachDB does not support Time to Live (TTL) on table rows. To delete "expired" rows, we recommend automating a batch delete process using a job scheduler like `cron`.
-
-For example, suppose that every morning you want to delete all rows in the [`tpcc`](cockroach-workload.html#tpcc-workload) `history` table that are older than a month. To do this, you could use the example Python script that [batch deletes on the non-indexed `h_date` column](#batch-delete-on-a-non-indexed-column).
-
-To run the script with a daily `cron` job:
-
-1. Make the file executable:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ chmod +x cleanup.py
-    ~~~
-
-2. Create a new `cron` job:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ crontab -e
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ txt
-    30 10 * * * DB_URI='cockroachdb://user@host:26257/bank' cleanup.py >> ~/cron.log 2>&1
-    ~~~
-
-Saving the `cron` file will install a new job that runs the `cleanup.py` file every morning at 10:30 A.M., writing the results to the `cron.log` file.
-
-## Delete all of the rows in a table
-
-To delete all of the rows in a table, use a [`TRUNCATE` statement](truncate.html).
-
-For example, to delete all rows in the [`tpcc`](cockroach-workload.html#tpcc-workload) `new_order` table, execute the following SQL statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-TRUNCATE new_order;
-~~~
-
-You can execute the statement from a compatible SQL client (e.g., the [CockroachDB SQL client](cockroach-sql.html)), or in a script or application.
-
-For example, in Python, using the `psycopg2` client driver:
-
-{% include copy-clipboard.html %}
-~~~ python
-#!/usr/bin/env python3
-
-import psycopg2
-import os
-
-conn = psycopg2.connect(os.environ.get('DB_URI'))
-
-with conn:
-  with conn.cursor() as cur:
-      cur.execute("TRUNCATE new_order")
-~~~
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `TRUNCATE` statement, including additional examples, see the [`TRUNCATE` syntax page](truncate.html).
-{{site.data.alerts.end}}
-
-## See also
-
-- [Delete data](delete-data.html)
-- [`DELETE`](delete.html)
-- [`TRUNCATE`](truncate.html)
diff --git a/src/current/v20.2/bulk-update-data.md b/src/current/v20.2/bulk-update-data.md
deleted file mode 100644
index 9a5ed303be0..00000000000
--- a/src/current/v20.2/bulk-update-data.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: Bulk-update Data
-summary: How to to update a large amount of data using batch-update loops.
-toc: true
----
-
-To update multiple rows in a table, you can use a single [`UPDATE` statement](update.html), with a `WHERE` clause that filters the rows you want to update.
-
-To update a large number of rows (i.e., tens of thousands of rows or more), we recommend iteratively updating subsets of the rows that you want to update, until all of the rows have been updated. You can write a script to do this, or you can write a loop into your application.
-
-This page provides guidance on writing batch-update loops with a pattern that executes `SELECT` and `UPDATE` statements at different levels of a nested loop.
-
-{{site.data.alerts.callout_danger}}
-Exercise caution when batch-updating rows from tables with foreign key constraints and explicit [`ON UPDATE` foreign key actions](foreign-key.html#foreign-key-actions). To preserve `UPDATE` performance on tables with foreign key actions, we recommend using smaller batch sizes, as additional rows updated due to `ON UPDATE` actions can make batch loops significantly slower.
-{{site.data.alerts.end}}
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Install a Postgres client](install-client-drivers.html).
-
-    For the example on this page, we use the `psycopg2` Python driver.
-- [Connect to the database](connect-to-the-database.html).
-- [Insert data](insert-data.html) that you now want to update.
-
-    For the example on this page, we load a cluster with the `movr` database and data from [`cockroach workload`](cockroach-workload.html).
-
-## Write a batch-update loop
-
-1. At the top level of a loop in your application, or in a script, execute a [`SELECT`](selection-queries.html) query that returns a large batch of primary key values for the rows that you want to update. When defining the `SELECT` query:
-    - Use a `WHERE` clause to filter on columns that identify the rows that you want to update. This clause should also filter out the rows that have been updated by previous iterations of the nested `UPDATE` loop:
-        - For optimal performance, the first condition of the filter should evaluate the last primary key value returned by the last `UPDATE` query that was executed. This narrows each `SELECT` query's scan to the fewest rows possible, and preserves the performance of the row updates over time.
-        - Another condition of the filter should evaluate column values persisted to the database that signal whether or not a row has been updated. This prevents rows from being updated more than once, in the event that the application or script crashes and needs to be restarted. If there is no way to distinguish between an updated row and a row that has not yet been updated, you might need to [add a new column to the table](add-column.html) (e.g., `ALTER TABLE ... ADD COLUMN updated BOOL;`).
-    - Add an [`AS OF SYSTEM TIME` clause](as-of-system-time.html) to the end of the selection subquery, or run the selection query in a separate, read-only transaction with [`SET TRANSACTION AS OF SYSTEM TIME`](as-of-system-time.html#using-as-of-system-time-in-transactions). This helps to reduce [transaction contention](transactions.html#transaction-contention).
-    - Use a [`LIMIT`](limit-offset.html) clause to limit the number of rows queried to a subset of the rows that you want to update. To determine the optimal `SELECT` batch size, try out different sizes (10,000 rows, 20,000 rows, etc.), and monitor the change in performance. Note that this `SELECT` batch size can be much larger than the batch size of rows that are updated in the subsequent `UPDATE` query.
-    - To ensure that rows are efficiently scanned in the subsequent `UPDATE` query, include an [`ORDER BY`](order-by.html) clause on the primary key.
-
-1. Under the `SELECT` query, write a nested loop that executes `UPDATE` queries over the primary key values returned by the `SELECT` query, in batches smaller than the initial `SELECT` batch size. When defining the `UPDATE` query:
-    - Use a `WHERE` clause that filters on a subset of the primary key values returned by the top-level `SELECT` query. To determine the optimal `UPDATE` batch size, try out different sizes (1,000 rows, 2,000 rows, etc.), and monitor the change in performance.
-    - Make sure that the `UPDATE` query updates a column that signals whether or not the row has been updated. This column might be different from the column whose values you want to update.
-    - Add a `RETURNING` clause to the end of the query that returns the primary key values of the rows being updated. The `WHERE` clause in the top-level `SELECT` query should filter out the primary key value of the last row that was updated, using the values returned by the last `UPDATE` query executed.
-    - Where possible, we recommend executing each `UPDATE` in a separate transaction.
-
-## Example
-
-Suppose that over the past year, you've recorded hundreds of thousands of [MovR](movr.html) rides in a cluster loaded with the [`movr`](cockroach-workload.html) database. And suppose that, for the last week of December, you applied a 10% discount to all ride charges billed to users, but you didn't update the `rides` table to reflect the discounts.
-
-To get the `rides` table up-to-date, you can create a loop that updates the relevant rows of the `rides` table in batches, following the query guidance provided [above](#write-a-batch-update-loop).
-
-In this case, you will also need to add a new column to the `rides` table that signals whether or not a row has been updated. Using this column, the top-level `SELECT` query can filter out rows that have already been updated, which will prevent rows from being updated more than once if the script crashes.
-
-For example, you could create a column named `discounted`, of data type [`BOOL`](bool.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE rides ADD COLUMN discounted BOOL DEFAULT false;
-~~~
-
-{% include {{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-In Python, a batch-update script might look similar to the following:
-
-{% include copy-clipboard.html %}
-~~~ python
-#!/usr/bin/env python3
-
-import psycopg2
-import os
-import time
-
-def main():
-    conn = psycopg2.connect(os.environ.get('DB_URI'))
-    lastid = None
-
-    while True:
-        with conn:
-            with conn.cursor() as cur:
-                cur.execute("SET TRANSACTION AS OF SYSTEM TIME '-5s'")
-                if lastid:
-                    cur.execute("SELECT id FROM rides WHERE id > %s AND discounted != true AND extract('month', start_time) = 12 AND extract('day', start_time) > 23 ORDER BY id LIMIT 10000", (lastid,))
-                else:
-                    cur.execute("SELECT id FROM rides WHERE discounted != true AND extract('month', start_time) = 12 AND extract('day', start_time) > 23 ORDER BY id LIMIT 10000")
-                pkvals = list(cur)
-        if not pkvals:
-            return
-        while pkvals:
-            batch = pkvals[:2000]
-            pkvals = pkvals[2000:]
-            with conn:
-                with conn.cursor() as cur:
-                    cur.execute("UPDATE rides SET discounted = true, revenue = revenue*.9 WHERE id = ANY %s RETURNING id", (batch,))
-                    print(cur.statusmessage)
-                    if not pkvals:
-                        lastid = cur.fetchone()[0]
-        del batch
-        del pkvals
-        time.sleep(5)
-
-    conn.close()
-if __name__ == '__main__':
-    main()
-~~~
-
-At each iteration, the `SELECT` query returns the primary key values of up to 10,000 rows of matching historical data from 5 seconds in the past, in a read-only transaction. Then, a nested loop iterates over the returned primary key values in smaller batches of 2,000 rows. At each iteration of the nested `UPDATE` loop, a batch of rows is updated. After the nested `UPDATE` loop updates all of the rows from the initial selection query, a time delay ensures that the next selection query reads historical data from the table after the last iteration's `UPDATE` final update.
-
-Note that the last iteration of the nested loop assigns the primary key value of the last row updated to the `lastid` variable. The next `SELECT` query uses this variable to decrease the number of rows scanned by the number of rows updated in the last iteration of the loop.
-
-## See also
-
-- [Update data](update-data.html)
-- [`UPDATE`](update.html)
diff --git a/src/current/v20.2/bytes.md b/src/current/v20.2/bytes.md
deleted file mode 100644
index 9e2f98bdd27..00000000000
--- a/src/current/v20.2/bytes.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-title: BYTES
-summary: The BYTES data type stores binary strings of variable length.
-toc: true
----
-
-The `BYTES` [data type](data-types.html) stores binary strings of variable length.
-
-
-## Aliases
-
-In CockroachDB, the following are aliases for `BYTES`:
-
-- `BYTEA`
-- `BLOB`
-
-## Syntax
-
-To express a byte array constant, see the section on
-[byte array literals](sql-constants.html#byte-array-literals) for more
-details. For example, the following three are equivalent literals for the same
-byte array: `b'abc'`, `b'\141\142\143'`, `b'\x61\x62\x63'`.
-
-In addition to this syntax, CockroachDB also supports using
-[string literals](sql-constants.html#string-literals), including the
-syntax `'...'`, `e'...'` and `x'....'` in contexts where a byte array
-is otherwise expected.
-
-## Size
-
-The size of a `BYTES` value is variable, but it's recommended to keep values under 1 MB to ensure performance. Above that threshold, [write amplification](https://en.wikipedia.org/wiki/Write_amplification) and other considerations may cause significant performance degradation.  
-
-{{site.data.alerts.callout_success}}
-If your application requires large binary input in single queries, you can store the blobs somewhere your client can access them (using a cloud storage service, for example), and then reference their addresses from a statement.
-{{site.data.alerts.end}}
-
-## Example
-
-~~~ sql
-> CREATE TABLE bytes (a INT PRIMARY KEY, b BYTES);
-
-> -- explicitly typed BYTES literals
-> INSERT INTO bytes VALUES (1, b'\141\142\143'), (2, b'\x61\x62\x63'), (3, b'\141\x62\c');
-
-> -- string literal implicitly typed as BYTES
-> INSERT INTO bytes VALUES (4, 'abc');
-
-
-> SELECT * FROM bytes;
-~~~
-~~~
-+---+-----+
-| a |  b  |
-+---+-----+
-| 1 | abc |
-| 2 | abc |
-| 3 | abc |
-| 4 | abc |
-+---+-----+
-(4 rows)
-~~~
-
-## Supported conversions
-
-`BYTES` values can be
-[cast](data-types.html#data-type-conversions-and-casts) explicitly to
-[`STRING`](string.html). This conversion always succeeds. Two
-conversion modes are supported, controlled by the
-[session variable](set-vars.html#supported-variables) `bytea_output`:
-
-- `hex` (default): The output of the conversion starts with the two
-  characters `\`, `x` and the rest of the string is composed by the
-  hexadecimal encoding of each byte in the input. For example,
-  `x'48AA'::STRING` produces `'\x48AA'`.
-
-- `escape`: The output of the conversion contains each byte in the
-  input, as-is if it is an ASCII character, or encoded using the octal
-  escape format `\NNN` otherwise. For example, `x'48AA'::STRING`
-  produces `'0\252'`.
-
-`STRING` values can be cast explicitly to `BYTES`. This conversion
-will fail if the hexadecimal digits are not valid, or if there is an
-odd number of them. Two conversion modes are supported:
-
-- If the string starts with the two special characters `\` and `x`
-  (e.g., `\xAABB`), the rest of the string is interpreted as a sequence
-  of hexadecimal digits. The string is then converted to a byte array
-  where each pair of hexadecimal digits is converted to one byte.
-
-- Otherwise, the string is converted to a byte array that contains its
-  UTF-8 encoding.
-
-### `STRING` vs. `BYTES`
-
-While both `STRING` and `BYTES` can appear to have similar behavior in many situations, one should understand their nuance before casting one into the other.
-
-`STRING` treats all of its data as characters, or more specifically, Unicode code points. `BYTES` treats all of its data as a byte string. This difference in implementation can lead to dramatically different behavior. For example, let's take a complex Unicode character such as ☃ ([the snowman emoji](https://emojipedia.org/snowman/)):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT length('☃'::string);
-~~~
-
-~~~
-  length
-+--------+
-       1
-~~~
-
-~~~ sql
-> SELECT length('☃'::bytes);
-~~~
-~~~
-  length
-+--------+
-       3
-~~~
-
-In this case, [`LENGTH(string)`](functions-and-operators.html#string-and-byte-functions) measures the number of Unicode code points present in the string, whereas [`LENGTH(bytes)`](functions-and-operators.html#string-and-byte-functions) measures the number of bytes required to store that value. Each character (or Unicode code point) can be encoded using multiple bytes, hence the difference in output between the two.
-
-#### Translating literals to `STRING` vs. `BYTES`
-
-A literal entered through a SQL client will be translated into a different value based on the type:
-
-+ `BYTES` give a special meaning to the pair `\x` at the beginning, and translates the rest by substituting pairs of hexadecimal digits to a single byte. For example, `\xff` is equivalent to a single byte with the value of 255. For more information, see [SQL Constants: String literals with character escapes](sql-constants.html#string-literals-with-character-escapes).
-+ `STRING` does not give a special meaning to `\x`, so all characters are treated as distinct Unicode code points. For example, `\xff` is treated as a `STRING` with length 4 (`\`, `x`, `f`, and `f`).
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/cancel-job.md b/src/current/v20.2/cancel-job.md
deleted file mode 100644
index f80a8bf3e22..00000000000
--- a/src/current/v20.2/cancel-job.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: CANCEL JOB
-summary: The CANCEL JOB statement stops long-running jobs such as imports, backups, and schema changes.
-toc: true
----
-
-The `CANCEL JOB` [statement](sql-statements.html) lets you stop long-running jobs, which include:
-
-- [`IMPORT`](import.html) jobs
-- [`BACKUP`](backup.html) and [`RESTORE`](restore.html) jobs
-- [User-created table statistics](create-statistics.html) jobs
-- [Automatic table statistics](cost-based-optimizer.html#table-statistics) jobs
-- [Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html)
-- [Schema change](online-schema-changes.html) jobs
-- <span class="version-tag">New in v20.2:</span> [Scheduled backup](manage-a-backup-schedule.html) jobs
-
-## Limitations
-
-When an Enterprise [`RESTORE`](restore.html) is canceled, partially restored data is properly cleaned up. This can have a minor, temporary impact on cluster performance.
-
-## Required privileges
-
-To cancel a job, the user must be a member of the `admin` role or must have the [`CONTROLJOB`](create-user.html#create-a-user-that-can-pause-resume-and-cancel-non-admin-jobs) parameter set. Non-admin users cannot cancel admin users' jobs.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/cancel_job.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`job_id` | The ID of the job you want to cancel, which can be found with [`SHOW JOBS`](show-jobs.html).
-`select_stmt` | A [selection query](selection-queries.html) that returns `job_id`(s) to cancel.
-`for_schedules_clause` | <span class="version-tag">New in v20.2:</span> The schedule you want to cancel jobs for. You can cancel jobs for a specific schedule (`FOR SCHEDULE id`) or cancel jobs for multiple schedules by nesting a [`SELECT` clause](select-clause.html) in the statement (`FOR SCHEDULES <select_clause>`). See the [examples](#cancel-jobs-for-a-schedule) below.
-
-## Examples
-
-### Cancel a single job
-
-~~~ sql
-> SHOW JOBS;
-~~~
-~~~
-+----------------+---------+-------------------------------------------+...
-|       id       |  type   |               description                 |...
-+----------------+---------+-------------------------------------------+...
-| 27536791415282 | RESTORE | RESTORE db.* FROM 'azure://backup/db/tbl' |...
-+----------------+---------+-------------------------------------------+...
-~~~
-~~~ sql
-> CANCEL JOB 27536791415282;
-~~~
-
-### Cancel multiple jobs
-
-To cancel multiple jobs, nest a [`SELECT` clause](select-clause.html) that retrieves `job_id`(s) inside the `CANCEL JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL JOBS (SELECT job_id FROM [SHOW JOBS]
-      WHERE user_name = 'maxroach');
-~~~
-
-All jobs created by `maxroach` will be cancelled.
-
-### Cancel automatic table statistics jobs
-
-Canceling an automatic table statistics job is not useful since the system will automatically restart the job immediately. To permanently disable automatic table statistics jobs, disable the `sql.stats.automatic_collection.enabled` [cluster setting](cluster-settings.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.stats.automatic_collection.enabled = false;
-~~~
-
-### Cancel jobs for a schedule
-
-<span class="version-tag">New in v20.2:</span> To cancel jobs for a specific [backup schedule](create-schedule-for-backup.html), use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL JOBS FOR SCHEDULE 590204387299262465;
-~~~
-~~~
-CANCEL JOBS FOR SCHEDULES 1
-~~~
-
-You can also CANCEL multiple schedules by nesting a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `CANCEL JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL JOBS FOR SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'test_schedule';
-~~~
-
-~~~
-CANCEL JOBS FOR SCHEDULES 2
-~~~
-
-## See also
-
-- [`SHOW JOBS`](show-jobs.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`IMPORT`](import.html)
-- [`CREATE CHANGEFEED`](create-changefeed.html)
diff --git a/src/current/v20.2/cancel-query.md b/src/current/v20.2/cancel-query.md
deleted file mode 100644
index f52f3d057b0..00000000000
--- a/src/current/v20.2/cancel-query.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: CANCEL QUERY
-summary: The CANCEL QUERY statement cancels a running SQL query.
-toc: true
----
-
-The `CANCEL QUERY` [statement](sql-statements.html) cancels a running SQL query.
-
-
-## Considerations
-
-- Schema changes are treated differently than other SQL queries. You can use <a href="show-jobs.html"><code>SHOW JOBS</code></a> to monitor the progress of schema changes and <a href="cancel-job.html"><code>CANCEL JOB</code></a> to cancel schema changes that are taking longer than expected.
-- In rare cases where a query is close to completion when a cancellation request is issued, the query may run to completion.
-
-## Required privileges
-
-Members of the `admin` role (include `root`, which belongs to `admin` by default) can cancel any currently active queries. User that are not members of the `admin` role can cancel only their own currently active queries. To view and cancel another non-admin user's query, the user must be a member of the `admin` role or must have the [`VIEWACTIVITY`](create-user.html#create-a-user-that-can-see-and-cancel-non-admin-queries-and-sessions) and [`CANCELQUERY`](create-user.html#create-a-user-that-can-see-and-cancel-non-admin-queries-and-sessions) parameters set.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/cancel_query.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`query_id` | A [scalar expression](scalar-expressions.html) that produces the ID of the query to cancel.<br><br>`CANCEL QUERY` accepts a single query ID. If a subquery is used and returns multiple IDs, the `CANCEL QUERY` statement will fail. To cancel multiple queries, use `CANCEL QUERIES`.
-`select_stmt` | A [selection query](selection-queries.html) whose result you want to cancel.
-
-## Response
-
-When a query is successfully cancelled, CockroachDB sends a `query execution canceled` error to the client that issued the query.
-
-- If the canceled query was a single, stand-alone statement, no further action is required by the client.
-- If the canceled query was part of a larger, multi-statement [transaction](transactions.html), the client should then issue a [`ROLLBACK`](rollback-transaction.html) statement.
-
-## Examples
-
-### Cancel a query via the query ID
-
-In this example, we use the [`SHOW QUERIES`](show-queries.html) statement to get the ID of a query and then pass the ID into the `CANCEL QUERY` statement:
-
-~~~ sql
-> SHOW QUERIES;
-~~~
-
-~~~
-+----------------------------------+---------+----------+----------------------------------+----------------------------------+--------------------+------------------+-------------+-----------+
-|             query_id             | node_id | username |              start               |              query               |   client_address   | application_name | distributed |   phase   |
-+----------------------------------+---------+----------+----------------------------------+----------------------------------+--------------------+------------------+-------------+-----------+
-| 14dacc1f9a781e3d0000000000000001 |       2 | mroach   | 2017-08-10 14:08:22.878113+00:00 | SELECT * FROM test.kv ORDER BY k | 192.168.0.72:56194 | test_app         | false       | executing |
-+----------------------------------+---------+----------+----------------------------------+----------------------------------+--------------------+------------------+-------------+-----------+
-| 14dacc206c47a9690000000000000002 |       2 | root     | 2017-08-14 19:11:05.309119+00:00 | SHOW CLUSTER QUERIES             | 127.0.0.1:50921    |                  | NULL        | preparing |
-+----------------------------------+---------+----------+----------------------------------+----------------------------------+--------------------+------------------+-------------+-----------+
-~~~
-
-~~~ sql
-> CANCEL QUERY '14dacc1f9a781e3d0000000000000001';
-~~~
-
-### Cancel a query via a subquery
-
-In this example, we nest a [`SELECT` clause](select-clause.html) that retrieves the ID of a query inside the `CANCEL QUERY` statement:
-
-~~~ sql
-> CANCEL QUERY (SELECT query_id FROM [SHOW CLUSTER QUERIES]
-      WHERE client_address = '192.168.0.72:56194'
-          AND username = 'mroach'
-          AND query = 'SELECT * FROM test.kv ORDER BY k');
-~~~
-
-{{site.data.alerts.callout_info}}<code>CANCEL QUERY</code> accepts a single query ID. If a subquery is used and returns multiple IDs, the <code>CANCEL QUERY</code> statement will fail. To cancel multiple queries, use <code>CANCEL QUERIES</code>.{{site.data.alerts.end}}
-
-## See also
-
-- [Manage Long-Running Queries](manage-long-running-queries.html)
-- [`SHOW QUERIES`](show-queries.html)
-- [`CANCEL SESSION`](cancel-session.html)
-- [SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/cancel-session.md b/src/current/v20.2/cancel-session.md
deleted file mode 100644
index 9e8e26958de..00000000000
--- a/src/current/v20.2/cancel-session.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: CANCEL SESSION
-summary: The CANCEL SESSION statement stops long-running sessions.
-toc: true
----
-
-The `CANCEL SESSION` [statement](sql-statements.html) lets you stop long-running sessions. `CANCEL SESSION` will attempt to cancel the currently active query and end the session.
-
-
-## Required privileges
-
-To view and cancel a session, the user must be a member of the `admin` role or must have the [`VIEWACTIVITY`](create-user.html#create-a-user-that-can-see-and-cancel-non-admin-queries-and-sessions) and [`CANCELQUERY`](create-user.html#create-a-user-that-can-see-and-cancel-non-admin-queries-and-sessions) parameters set. Non-admin users cannot cancel admin users' sessions.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/cancel_session.html %}</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`session_id` | The ID of the session you want to cancel, which can be found with [`SHOW SESSIONS`](show-sessions.html).<br><br>`CANCEL SESSION` accepts a single session ID. If a subquery is used and returns multiple IDs, the `CANCEL SESSION` statement will fail. To cancel multiple sessions, use `CANCEL SESSIONS`.
-`select_stmt` | A [selection query](selection-queries.html) that returns `session_id`(s) to cancel.
-
-## Example
-
-### Cancel a single session
-
-In this example, we use the [`SHOW SESSIONS`](show-sessions.html) statement to get the ID of a session and then pass the ID into the `CANCEL SESSION` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SESSIONS;
-~~~
-~~~
-+---------+----------------------------------+-----------+...
-| node_id |            session_id            | user_name |...
-+---------+----------------------------------+-----------+...
-|       1 | 1530c309b1d8d5f00000000000000001 | root      |...
-+---------+----------------------------------+-----------+...
-|       1 | 1530fe0e46d2692e0000000000000001 | maxroach  |...
-+---------+----------------------------------+-----------+...
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL SESSION '1530fe0e46d2692e0000000000000001';
-~~~
-
-You can also cancel a session using a subquery that returns a single session ID:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL SESSIONS (SELECT session_id FROM [SHOW SESSIONS]
-      WHERE user_name = 'root');
-~~~
-
-### Cancel multiple sessions
-
-Use the [`SHOW SESSIONS`](show-sessions.html) statement to view all active sessions:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SESSIONS;
-~~~
-~~~
-+---------+----------------------------------+-----------+...
-| node_id |            session_id            | user_name |...
-+---------+----------------------------------+-----------+...
-|       1 | 1530c309b1d8d5f00000000000000001 | root      |...
-+---------+----------------------------------+-----------+...
-|       1 | 1530fe0e46d2692e0000000000000001 | maxroach  |...
-+---------+----------------------------------+-----------+...
-|       1 | 15310cc79671fc6a0000000000000001 | maxroach  |...
-+---------+----------------------------------+-----------+...
-~~~
-
-To cancel multiple sessions, nest a [`SELECT` clause](select-clause.html) that retrieves `session_id`(s) inside the `CANCEL SESSIONS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL SESSIONS (SELECT session_id FROM [SHOW SESSIONS]
-      WHERE user_name = 'maxroach');
-~~~
-
-All sessions created by `maxroach` will be cancelled.
-
-## See also
-
-- [`SHOW SESSIONS`](show-sessions.html)
-- [`SET` (session variable)](set-vars.html)
-- [`SHOW` (session variable)](show-vars.html)
-- [SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/changefeed-for.md b/src/current/v20.2/changefeed-for.md
deleted file mode 100644
index 8dfe0a8cf7d..00000000000
--- a/src/current/v20.2/changefeed-for.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: EXPERIMENTAL CHANGEFEED FOR
-summary: which streams row-level changes to the client indefinitely until the underlying connection is closed or the changefeed is canceled.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-`EXPERIMENTAL CHANGEFEED FOR` is the core implementation of changefeeds. For the [Enterprise-only](enterprise-licensing.html) version, see [`CREATE CHANGEFEED`](create-changefeed.html).
-{{site.data.alerts.end}}
-
-The `EXPERIMENTAL CHANGEFEED FOR` [statement](sql-statements.html) creates a new core changefeed, which streams row-level changes to the client indefinitely until the underlying connection is closed or the changefeed is canceled. A core changefeed can watch one table or multiple tables in a comma-separated list.
-
-{% include {{ page.version.version }}/cdc/core-url.md %}
-
-For more information, see [Stream Data Out of CockroachDB Using Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html).
-
-{% include {{ page.version.version }}/misc/experimental-warning.md %}
-
-## Required privileges
-
-Changefeeds can only be created by superusers, i.e., [members of the `admin` role](authorization.html#create-and-manage-roles). The admin role exists by default with `root` as the member.
-
-## Considerations
-
-- Because core changefeeds return results differently than other SQL statements, they require a dedicated database connection with specific settings around result buffering. In normal operation, CockroachDB improves performance by buffering results server-side before returning them to a client; however, result buffering is automatically turned off for core changefeeds. Core changefeeds also have different cancellation behavior than other queries: they can only be canceled by closing the underlying connection or issuing a [`CANCEL QUERY`](cancel-query.html) statement on a separate connection. Combined, these attributes of changefeeds mean that applications should explicitly create dedicated connections to consume changefeed data, instead of using a connection pool as most client drivers do by default.
-
-    This cancellation behavior (i.e., close the underlying connection to cancel the changefeed) also extends to client driver usage; in particular, when a client driver calls `Rows.Close()` after encountering errors for a stream of rows. The pgwire protocol requires that the rows be consumed before the connection is again usable, but in the case of a core changefeed, the rows are never consumed. It is therefore critical that you close the connection, otherwise the application will be blocked forever on `Rows.Close()`.
-
-- In most cases, each version of a row will be emitted once. However, some infrequent conditions (e.g., node failures, network partitions) will cause them to be repeated. This gives our changefeeds an at-least-once delivery guarantee. For more information, see [Change Data Capture - Ordering Guarantees](stream-data-out-of-cockroachdb-using-changefeeds.html#ordering-guarantees).
-
-## Synopsis
-
-~~~
-> EXPERIMENTAL CHANGEFEED FOR table_name [ WITH (option [= value] [, ...]) ];
-~~~
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table (or tables in a comma separated list) to create a changefeed for.
-`option` / `value` | For a list of available options and their values, see [Options](#options) below.
-
-<!-- `IF NOT EXISTS` | Create a new changefeed only if a changefeed of the same name does not already exist; if one does exist, do not return an error.
-`name` | The name of the changefeed to create, which [must be unique](#create-fails-name-already-in-use) and follow these [identifier rules](keywords-and-identifiers.html#identifiers). -->
-
-### Options
-
-Option | Value | Description
--------|-------|------------
-`updated` | N/A | Include updated timestamps with each row.
-`resolved` | [`INTERVAL`](interval.html) | Emits [resolved timestamp](stream-data-out-of-cockroachdb-using-changefeeds.html#resolved-def) events for the changefeed. Resolved timestamp events do not emit until all ranges in the changefeed have progressed to a specific point in time. <br><br>Set an optional minimal duration between emitting resolved timestamps. Example: `resolved='10s'`. This option will **only** emit a resolved timestamp event if the timestamp has advanced and at least the optional duration has elapsed. If unspecified, all resolved timestamps are emitted as the high-water mark advances.
-`envelope` | `key_only` / `row` | Use `key_only` to emit only the key and no value, which is faster if you only want to know when the key changes.<br><br>Default: `envelope=row`
-`cursor` | [Timestamp](as-of-system-time.html#parameters)  | Emits any changes after the given timestamp, but does not output the current state of the table first. If `cursor` is not specified, the changefeed starts by doing a consistent scan of all the watched rows and emits the current value, then moves to emitting any changes that happen after the scan.<br><br>`cursor` can be used to start a new changefeed where a previous changefeed ended.<br><br>Example: `CURSOR=1536242855577149065.0000000000`
-`format` | `json` / `experimental_avro` | Format of the emitted record. Currently, support for [Avro is limited and experimental](#avro-limitations). <br><br>Default: `format=json`.
-`confluent_schema_registry` | Schema Registry address | The [Schema Registry](https://docs.confluent.io/current/schema-registry/docs/index.html#sr) address is required to use `experimental_avro`.
-
-#### Avro limitations
-
-Currently, support for Avro is limited and experimental. Below is a list of unsupported SQL types and values for Avro changefeeds:
-
-- [Decimals](decimal.html) must have precision specified.
-- [`INTERVAL`](https://github.com/cockroachdb/cockroach/issues/32472), [`ARRAY`](https://github.com/cockroachdb/cockroach/issues/34420), `BIT`, and collated `STRING` are not supported in Avro yet.
-
-## Examples
-
-### Create a changefeed
-
-{% include {{ page.version.version }}/cdc/create-core-changefeed.md %}
-
-### Create a changefeed with Avro
-
-{% include {{ page.version.version }}/cdc/create-core-changefeed-avro.md %}
-
-<!-- ### Pause and resume a changefeed
-
-You can pause a changefeed by -->
-
-## See also
-
-- [Stream Data Out of CockroachDB Using Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/check.md b/src/current/v20.2/check.md
deleted file mode 100644
index d10a9ca1b38..00000000000
--- a/src/current/v20.2/check.md
+++ /dev/null
@@ -1,113 +0,0 @@
----
-title: CHECK Constraint
-summary: The CHECK constraint specifies that values for the column in INSERT or UPDATE statements must satisfy a Boolean expression.
-toc: true
----
-
-The `CHECK` [constraint](constraints.html) specifies that values for the column in [`INSERT`](insert.html) or [`UPDATE`](update.html) statements must return `TRUE` or `NULL` for a Boolean expression. If any values return `FALSE`, the entire statement is rejected.
-
-## Details
-
-- If you add a `CHECK` constraint to an existing table, CockroachDB will run a background job to validate existing table data in the process of adding the constraint. If a row is found that violates the constraint during the validation step, the [`ADD CONSTRAINT`](add-constraint.html) statement will fail. This differs from previous versions of CockroachDB, which allowed you to add a check constraint that was enforced for writes but could be violated by rows that existed prior to adding the constraint.
-- Check constraints can be added to columns that were created earlier in the same transaction. For an example, see [Add the `CHECK` constraint](add-constraint.html#add-the-check-constraint).
-- `CHECK` constraints may be specified at the column or table level and can reference other columns within the table. Internally, all column-level `CHECK` constraints are converted to table-level constraints so they can be handled consistently.
-- You can have multiple `CHECK` constraints on a single column but ideally, for performance optimization, these should be combined using the logical operators. For example:
-
-  ~~~ sql
-  warranty_period INT CHECK (warranty_period >= 0) CHECK (warranty_period <= 24)
-  ~~~
-
-  should be specified as:
-
-  ~~~ sql
-  warranty_period INT CHECK (warranty_period BETWEEN 0 AND 24)
-  ~~~
-- When a column with a `CHECK` constraint is dropped, the `CHECK` constraint is also dropped.
-
-## Syntax
-
-`CHECK` constraints can be defined at the [table level](#table-level). However, if you only want the constraint to apply to a single column, it can be applied at the [column level](#column-level).
-
-{{site.data.alerts.callout_info}}You can also add the <code>CHECK</code> constraint to existing tables through <a href="add-constraint.html#add-the-check-constraint"><code>ADD CONSTRAINT</code></a>.{{site.data.alerts.end}}
-
-### Column level
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/check_column_level.html %}
-</div>
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table you're creating.
- `column_name` | The name of the constrained column.
- `column_type` | The constrained column's [data type](data-types.html).
- `check_expr` | An expression that returns a Boolean value; if the expression evaluates to `FALSE`, the value cannot be inserted.
- `column_constraints` | Any other column-level [constraints](constraints.html) you want to apply to this column.
- `column_def` | Definitions for any other columns in the table.
- `table_constraints` | Any table-level [constraints](constraints.html) you want to apply.
-
-**Example**
-
-~~~ sql
-> CREATE TABLE inventories (
-    product_id        INT NOT NULL,
-    warehouse_id      INT NOT NULL,
-    quantity_on_hand  INT NOT NULL CHECK (quantity_on_hand > 0),
-    PRIMARY KEY (product_id, warehouse_id)
-  );
-~~~
-
-### Table level
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/check_table_level.html %}
-</div>
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table you're creating.
- `column_def` | Definitions for any other columns in the table.
- `name` | The name you want to use for the constraint, which must be unique to its table and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
- `check_expr` | An expression that returns a Boolean value; if the expression evaluates to `FALSE`, the value cannot be inserted.
- `table_constraints` | Any other table-level [constraints](constraints.html) you want to apply.
-
-**Example**
-
-~~~ sql
-> CREATE TABLE inventories (
-    product_id        INT NOT NULL,
-    warehouse_id      INT NOT NULL,
-    quantity_on_hand  INT NOT NULL,
-    PRIMARY KEY (product_id, warehouse_id),
-    CONSTRAINT ok_to_supply CHECK (quantity_on_hand > 0 AND warehouse_id BETWEEN 100 AND 200)
-  );
-~~~
-
-## Usage example
-
-`CHECK` constraints may be specified at the column or table level and can reference other columns within the table. Internally, all column-level `CHECK` constraints are converted to table-level constraints so they can be handled in a consistent fashion.
-
-~~~ sql
-> CREATE TABLE inventories (
-    product_id        INT NOT NULL,
-    warehouse_id      INT NOT NULL,
-    quantity_on_hand  INT NOT NULL CHECK (quantity_on_hand > 0),
-    PRIMARY KEY (product_id, warehouse_id)
-  );
-
-> INSERT INTO inventories (product_id, warehouse_id, quantity_on_hand) VALUES (1, 2, 0);
-~~~
-~~~
-pq: failed to satisfy CHECK constraint (quantity_on_hand > 0)
-~~~
-
-## See also
-
-- [Constraints](constraints.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`DEFAULT` constraint](default-value.html)
-- [`REFERENCES` constraint (Foreign Key)](foreign-key.html)
-- [`NOT NULL` constraint](not-null.html)
-- [`PRIMARY KEY` constraint](primary-key.html)
-- [`UNIQUE` constraint](unique.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
diff --git a/src/current/v20.2/cluster-settings.md b/src/current/v20.2/cluster-settings.md
deleted file mode 100644
index 5aa97c2ef54..00000000000
--- a/src/current/v20.2/cluster-settings.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: Cluster Settings
-summary: Learn about cluster settings that apply to all nodes of a CockroachDB cluster.
-toc: false
----
-
-Cluster settings apply to all nodes of a CockroachDB cluster and control, for example, whether or not to share diagnostic details with Cockroach Labs as well as advanced options for debugging and cluster tuning.
-
-They can be updated anytime after a cluster has been started, but only by a member of the `admin` role, to which the `root` user belongs by default.
-
-{{site.data.alerts.callout_info}}
-In contrast to cluster-wide settings, node-level settings apply to a single node. They are defined by flags passed to the `cockroach start` command when starting a node and cannot be changed without stopping and restarting the node. For more details, see [Start a Node](cockroach-start.html).
-{{site.data.alerts.end}}
-
-## Settings
-
-{{site.data.alerts.callout_danger}}
-Many cluster settings are intended for tuning CockroachDB internals. Before changing these settings, we strongly encourage you to discuss your goals with Cockroach Labs; otherwise, you use them at your own risk.
-{{site.data.alerts.end}}
-
-{% remote_include https://raw.githubusercontent.com/cockroachdb/cockroach/{{ page.release_info.crdb_branch_name }}/docs/generated/settings/settings.html %}
-
-## View current cluster settings
-
-Use the [`SHOW CLUSTER SETTING`](show-cluster-setting.html) statement.
-
-## Change a cluster setting
-
-Use the [`SET CLUSTER SETTING`](set-cluster-setting.html) statement.
-
-Before changing a cluster setting, please note the following:
-
-- 	Changing a cluster setting is not instantaneous, as the change must be propagated to other nodes in the cluster.
-
-- 	Do not change cluster settings while [upgrading to a new version of CockroachDB](upgrade-cockroach-version.html). Wait until all nodes have been upgraded before you make the change.
-
-## See also
-
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`SHOW CLUSTER SETTING`](show-cluster-setting.html)
-- [Diagnostics Reporting](diagnostics-reporting.html)
-- [Start a Node](cockroach-start.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
diff --git a/src/current/v20.2/cluster-setup-troubleshooting.md b/src/current/v20.2/cluster-setup-troubleshooting.md
deleted file mode 100644
index 3f4f2ac525a..00000000000
--- a/src/current/v20.2/cluster-setup-troubleshooting.md
+++ /dev/null
@@ -1,528 +0,0 @@
----
-title: Troubleshoot Cluster Setup
-summary: Learn how to troubleshoot issues with starting CockroachDB clusters
-toc: true
----
-
-If you're having trouble starting or scaling your cluster, this page will help you troubleshoot the issue.
-
-To use this guide, it's important to understand some of CockroachDB's terminology:
-
-  - A **Cluster** acts as a single logical database, but is actually made up of many cooperating nodes.
-  - **Nodes** are single instances of the `cockroach` binary running on a machine. It's possible (though atypical) to have multiple nodes running on a single machine.
-
-## Cannot run a single-node CockroachDB cluster
-
-Try running:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start-single-node --insecure --logtostderr
-~~~
-
-If the process exits prematurely, check for the following:
-
-#### An existing storage directory
-
-When starting a node, the directory you choose to store the data in also contains metadata identifying the cluster the data came from. This causes conflicts when you've already started a node on the server, have quit `cockroach`, and then tried to start another cluster using the same directory. Because the existing directory's cluster ID doesn't match the new cluster ID, the node cannot start.
-
-**Solution:** Disassociate the node from the existing directory where you've stored CockroachDB data. For example, you can do either of the following:
-
--   Choose a different directory to store the CockroachDB data:  
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start-single-node --store=<new directory> --insecure
-    ~~~
--   Remove the existing directory and start the node again:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -r cockroach-data/
-    ~~~
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start-single-node --insecure --logtostderr
-    ~~~
-
-#### Toolchain incompatibility
-
-The components of the toolchain might have some incompatibilities that need to be resolved. For example, a few months ago, there was an incompatibility between Xcode 8.3 and Go 1.8 that caused any Go binaries created with that toolchain combination to crash immediately.
-
-#### Incompatible CPU
-
-If the `cockroach` process had exit status `132 (SIGILL)`, it attempted to use an instruction that is not supported by your CPU. Non-release builds of CockroachDB may not be able to run on older hardware platforms than the one used to build them. Release builds should run on any x86-64 CPU.
-
-#### Default ports already in use
-
-Other services may be running on port 26257 or 8080 (CockroachDB's default `--listen-addr` port and `--http-addr` port respectively). You can either stop those services or start your node with different ports, specified in the [`--listen-addr` and `--http-addr` flags](cockroach-start.html#networking).
-
-  If you change the port, you will need to include the `--port=<specified port>` flag in each subsequent cockroach command or change the `COCKROACH_PORT` environment variable.
-
-#### Single-node networking issues
-
-Networking issues might prevent the node from communicating with itself on its hostname. You can control the hostname CockroachDB uses with the [`--listen-addr` flag](cockroach-start.html#networking).
-
-  If you change the host, you will need to include `--host=<specified host>` in each subsequent cockroach command.
-
-#### CockroachDB process hangs when trying to start a node in the background
-
-See [Why is my process hanging when I try to start it in the background?](operational-faqs.html#why-is-my-process-hanging-when-i-try-to-start-nodes-with-the-background-flag)
-
-## Cannot run SQL statements using built-in SQL client
-
-If the CockroachDB node appeared to [start successfully](start-a-local-cluster.html), in a separate terminal run:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure -e "show databases"
-~~~
-
-You should see a list of the built-in databases:
-
-~~~
-  database_name
-+---------------+
-  defaultdb
-  postgres
-  system
-(3 rows)
-~~~
-
-If you’re not seeing the output above, check for the following:
-
--   `connection refused` error, which indicates you have not included some flag that you used to start the node. We have additional troubleshooting steps for this error [here](common-errors.html#connection-refused).
--   The node crashed. To ascertain if the node crashed, run `ps | grep cockroach` to look for the `cockroach` process. If you cannot locate the `cockroach` process (i.e., it crashed), [file an issue](file-an-issue.html), including the logs from your node and any errors you received.
-
-## Cannot run a multi-node CockroachDB cluster on the same machine
-
-{{site.data.alerts.callout_info}}
-Running multiple nodes on a single host is useful for testing out CockroachDB, but it's not recommended for production deployments. To run a physically distributed cluster in production, see [Manual Deployment](manual-deployment.html) or [Orchestrated Deployment](orchestration.html). Also be sure to review the [Production Checklist](recommended-production-settings.html).
-{{site.data.alerts.end}}
-
-If you are trying to run all nodes on the same machine, you might get the following errors:
-
-#### Store directory already exists
-
-~~~
-ERROR: could not cleanup temporary directories from record file: could not lock temporary directory /Users/amruta/go/src/github.com/cockroachdb/cockroach/cockroach-data/cockroach-temp301343769, may still be in use: IO error: While lock file: /Users/amruta/go/src/github.com/cockroachdb/cockroach/cockroach-data/cockroach-temp301343769/TEMP_DIR.LOCK: Resource temporarily unavailable
-~~~
-
-**Explanation:** When starting a new node on the same machine, the directory you choose to store the data in also contains metadata identifying the cluster the data came from. This causes conflicts when you've already started a node on the server and then tried to start another cluster using the same directory.
-
-**Solution:** Choose a different directory to store the CockroachDB data.
-
-#### Port already in use
-
-~~~
-ERROR: cockroach server exited with error: consider changing the port via --listen-addr: listen tcp 127.0.0.1:26257: bind: address already in use
-~~~
-
-**Solution:** Change the `--port`, `--http-port` flags for each new node that you want to run on the same machine.
-
-## Cannot join a node to an existing CockroachDB cluster
-
-#### Store directory already exists
-
-When joining a node to a cluster, you might receive one of the following errors:
-
-~~~
-no resolvers found; use --join to specify a connected node
-
-node belongs to cluster {"cluster hash"} but is attempting to connect to a gossip network for cluster {"another cluster hash"}
-~~~
-
-**Explanation:** When starting a node, the directory you choose to store the data in also contains metadata identifying the cluster the data came from. This causes conflicts when you've already started a node on the server, have quit the `cockroach` process, and then tried to join another cluster. Because the existing directory's cluster ID doesn't match the new cluster ID, the node cannot join it.  
-
-**Solution:** Disassociate the node from the existing directory where you've stored CockroachDB data. For example, you can do either of the following:
-
--   Choose a different directory to store the CockroachDB data:  
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start --store=<new directory> --join=<cluster host> <other flags>
-    ~~~
--   Remove the existing directory and start a node joining the cluster again:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -r cockroach-data/
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start --join=<cluster host>:26257 <other flags>  
-    ~~~
-
-#### Incorrect `--join` address
-
-If you try to add another node to the cluster, but the `--join` address is not pointing at any of the existing nodes, then the process will never complete, and you'll see a continuous stream of warnings like this:
-
-~~~
-W180817 17:01:56.506968 886 vendor/google.golang.org/grpc/clientconn.go:942 Failed to dial localhost:20000: grpc: the connection is closing; please retry.  
-W180817 17:01:56.510430 914 vendor/google.golang.org/grpc/clientconn.go:1293 grpc: addrConn.createTransport failed to connect to {localhost:20000 0 <nil>}. Err :connection error: desc = "transport: Error while dialing dial tcp [::1]:20000: connect: connection refused". Reconnecting…
-~~~
-
-**Explanation:** These warnings tell you that the node cannot establish a connection with the address specified in the `--join` flag. Without a connection to the cluster, the node cannot join.
-
-**Solution:** To successfully join the node to the cluster, start the node again, but this time include a correct `--join` address.
-
-## Client connection issues
-
-If a client cannot connect to the cluster, check basic network connectivity (`ping`), port connectivity (`telnet`), and certificate validity.
-
-#### Networking issues
-
-Most networking-related issues are caused by one of two issues:
-
--   Firewall rules, which require your network administrator to investigate
--   Inaccessible hostnames on your nodes, which can be controlled with the `--listen-addr` and `--advertise-addr` flags on [`cockroach start`](cockroach-start.html#networking)
-
-
-**Solution:**
-
-To check your networking setup:
-
-1.  Use `ping`. Every machine you are using as a CockroachDB node should be able to ping every other machine, using the hostnames or IP addresses used in the `--join` flags (and the `--advertise-host` flag if you are using it).
-
-2.  If the machines are all pingable, check if you can connect to the appropriate ports. With your CockroachDB nodes still running, log in to each node and use `telnet` or` nc` to verify machine to machine connectivity on the desired port. For instance, if you are running CockroachDB on the default port of 26257, run either:
-  -   `telnet <other-machine> 26257`
-  -   `nc <other-machine> 26257`
-
-  Both `telnet` and `nc` will exit immediately if a connection cannot be established. If you are running in a firewalled environment, the firewall might be blocking traffic to the desired ports even though it is letting ping packets through.
-
-To efficiently troubleshoot the issue, it's important to understand where and why it's occurring. We recommend checking the following network-related issues:
-
--   By default, CockroachDB advertises itself to other nodes using its hostname. If your environment doesn't support DNS or the hostname is not resolvable, your nodes cannot connect to one another. In these cases, you can:
-  -   Change the hostname each node uses to advertises itself with `--advertise-addr`
-  -   Set `--listen-addr=<node's IP address>` if the IP is a valid interface on the machine
--   Every node in the cluster should be able to ping each other node on the hostnames or IP addresses you use in the `--join`, `--listen-addr`, or `--advertise-addr` flags.
--   Every node should be able to connect to other nodes on the port you're using for CockroachDB (26257 by default) through `telnet` or `nc`:
-  -   `telnet <other node host> 26257`
-  -   `nc <other node host> 26257`
-
-Again, firewalls or hostname issues can cause any of these steps to fail.
-
-#### Network partition
-
-If the DB Console lists any dead nodes on the [**Cluster Overview** page](ui-cluster-overview-page.html), then you might have a network partition.
-
-**Explanation:** A network partition prevents nodes from communicating with each other in one or both directions. This can be due to a configuration problem with the network, such as when allowlisted IP addresses or hostnames change after a node is torn down and rebuilt. In a symmetric partition, node communication is broken in both directions. In an asymmetric partition, node communication works in one direction but not the other.
-
-The effect of a network partition depends on which nodes are partitioned, where the ranges are located, and to a large extent, whether [localities](cockroach-start.html#locality) are defined. If localities are not defined, a partition that cuts off at least (n-1)/2 nodes will cause data unavailability.
-
-**Solution:**
-
-To identify a network partition:
-
-1.  Access the [Network Latency](ui-network-latency-page.html) page of the DB Console.
-2.  In the **Latencies** table, check for nodes with [no connections](ui-network-latency-page.html#no-connections). This indicates that a node cannot communicate with another node, and might indicate a network partition.
-
-## Authentication issues
-
-#### Missing certificate
-
-If  you try to add a node to a secure cluster without providing the node's security certificate, you will get the following error:
-
-~~~
-problem with CA certificate: not found  
-*  
-* ERROR: cannot load certificates.  
-* Check your certificate settings, set --certs-dir, or use --insecure for insecure clusters.  
-*  
-* problem with CA certificate: not found  
-*  
-Failed running "start"
-~~~
-
-**Explanation:** The error tells you that because the cluster is secure, it requires the new node to provide its security certificate in order to join.
-
-**Solution:** To successfully join the node to the cluster, start the node again, but this time include the `--certs-dir` flag
-
-#### Certification expiration
-
-If you’re running a secure cluster, be sure to monitor your certificate expiration. If one of the inter-node certificates expires, nodes will no longer be able to communicate which can look like a network partition.
-
-To check the certificate expiration date:
-
-1. [Access the DB Console](ui-overview.html#db-console-access).
-2. Click the gear icon on the left-hand navigation bar to access the **Advanced Debugging** page.
-3. Scroll down to the **Even More Advanced Debugging** section. Click **All Nodes**. The **Node Diagnostics** page appears. Click the certificates for each node and check the expiration date for each certificate in the Valid Until field.
-
-#### Client password not set
-
-While connecting to a secure cluster as a user, CockroachDB first checks if the client certificate exists in the `cert` directory. If the client certificate doesn’t exist, it prompts for a password. If password is not set and you press Enter, the connection attempt fails, and the following error is printed to `stderr`:
-
-~~~
-Error: pq: invalid password  
-Failed running "sql"
-~~~
-
-**Solution:** To successfully connect to the cluster, you must first either generate a client certificate or create a password for the user.
-
-#### Cannot create new connections to cluster for up to 40 seconds after a node dies
-
-When a node [dies abruptly and/or loses its network connection to the cluster](#node-liveness-issues), the following behavior can occur:
-
-1. For a period of up to 40 seconds, clients trying to connect with [username and password authentication](authentication.html#client-authentication) cannot create new connections to any of the remaining nodes in the cluster.
-1. Applications start timing out when trying to connect to the cluster during this window.
-
-The reason this happens is as follows:
-
-- Username and password information is stored in a system range.
-- Since all system ranges are located [near the beginning of the keyspace](architecture/distribution-layer.html#monolithic-sorted-map-structure), the system range containing the username/password info can sometimes be colocated with another system range that is used to determine [node liveness](#node-liveness-issues).
-- If the username/password info and the node liveness record are stored together as described above, it can take extra time for the lease on this range to be transferred to another node. Normally, lease transfers take about 10 seconds, but in this case it may require multiple rounds of consensus to determine that the node in question is actually dead (the node liveness record check may be retried several times before failing).
-
-For more information about how lease transfers work when a node dies, see [How leases are transferred from a dead node](architecture/replication-layer.html#how-leases-are-transferred-from-a-dead-node).
-
-The solution is to add connection retry logic to your application.
-
-## Clock sync issues
-
-#### Node clocks are not properly synchronized
-
-See the following FAQs:
-
-- [What happens when node clocks are not properly synchronized](operational-faqs.html#what-happens-when-node-clocks-are-not-properly-synchronized)
-- [How can I tell how well node clocks are synchronized](operational-faqs.html#how-can-i-tell-how-well-node-clocks-are-synchronized)
-
-## Capacity planning issues
-
-Following are some of the possible issues you might have while planning capacity for your cluster:
-
--   Running CPU at close to 100% utilization with high run queue will result in poor performance.
--   Running RAM at close to 100% utilization triggers Linux OOM and/or swapping that will result in poor performance or stability issues.
--   Running storage at 100% capacity causes writes to fail, which in turn can cause various processes to stop.
--   Running storage at 100% utilization read/write will causes poor service time.
--   Running network at 100% utilization causes response between databases and client to be poor.
-
-**Solution:** [Access the DB Console](ui-overview.html#db-console-access) and navigate to **Metrics > Hardware** dashboard to monitor the following metrics:
-
-First, check adequate capacity was available for the incident for the following components.
-
-Type | Time Series | What to look for
---------|--------|--------|
-RAM capacity | Memory Usage | Any non-zero value
-CPU capacity | CPU Percent | Consistent non-zero values
-Network capacity | Network Bytes Received<br/>Network Bytes Sent | Any non-zero value
-
-Check Near Out of Capacity Conditions:
-
-Type | Time Series | What to look for
---------|--------|--------|
-RAM capacity | Memory Usage | Consistently more than 80%
-CPU capacity | CPU Percent | Consistently less than 20% in idle (i.e.:80% busy)
-Network capacity | Network Bytes Received<br/>Network Bytes Sent | Consistently more than 50% capacity for both
-
-## Storage issues
-
-#### Disks filling up
-
-Like any database system, if you run out of disk space the system will no longer be able to accept writes. Additionally, a CockroachDB node needs a small amount of disk space (a few GBs to be safe) to perform basic maintenance functionality. For more information about this issue, see:
-
-- [Why is memory usage increasing despite lack of traffic?](operational-faqs.html#why-is-memory-usage-increasing-despite-lack-of-traffic)
-- [Why is disk usage increasing despite lack of writes?](operational-faqs.html#why-is-disk-usage-increasing-despite-lack-of-writes)
--  [Can I reduce or disable the storage of timeseries data?](operational-faqs.html#can-i-reduce-or-disable-the-storage-of-time-series-data)
-
-## Memory issues
-
-#### Suspected memory leak
-
-A CockroachDB node will grow to consume all of the memory allocated for its `cache`. The default size for the cache is ¼ of physical memory which can be substantial depending on your machine configuration. This growth will occur even if your cluster is otherwise idle due to the internal metrics that a CockroachDB cluster tracks. See the `--cache` flag in [`cockroach start`](cockroach-start.html#general).
-
-CockroachDB memory usage has 3 components:
-
--   **Go allocated memory**: Memory allocated by the Go runtime to support query processing and various caches maintained in Go by CockroachDB. These caches are generally small in comparison to the RocksDB cache size. If Go allocated memory is larger than a few hundred megabytes, something concerning is going on.
--   **CGo allocated memory**: Memory allocated by the C/C++ libraries linked into CockroachDB and primarily concerns the block caches for the storage engine (this is true for both [Pebble (the default engine) and RocksDB](cockroach-start.html#storage-engine)). This is the “cache” mentioned in the note above. The size of CGo allocated memory is usually very close to the configured cache size.
--   **Overhead**: The process resident set size minus Go/CGo allocated memory.
-
-If Go allocated memory is larger than a few hundred megabytes, you might have encountered a memory leak. Go comes with a built-in heap profiler which is already enabled on your CockroachDB process. See this [excellent blog post](https://blog.golang.org/profiling-go-programs) on profiling Go programs.
-
-**Solution:** To determine Go/CGo allocated memory:
-
-1. [Access the DB Console](ui-overview.html#db-console-access).
-
-2. Navigate to **Metrics > Runtime** dashboard, and check the **Memory Usage** graph.
-
-3. 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.
-
-  -   If CGo allocated memory is larger than the configured `cache` size, [file an issue](file-an-issue.html).
-  -   If the resident set size (RSS) minus Go/CGo total memory is larger than 100 megabytes, [file an issue](file-an-issue.html).
-
-#### Node crashes because of insufficient memory
-
-Often when a node exits without a trace or logging any form of error message, we’ve found that it is the operating system stopping it suddenly due to low memory. So if you're seeing node crashes where the logs just end abruptly, it's probably because the node is running out of memory. On most Unix systems, you can verify if the `cockroach` process was stopped because the node ran out of memory by running:
-
-~~~ shell
-$ sudo dmesg | grep -iC 3 "cockroach"
-~~~
-
-If the command returns the following message, then you know the node crashed due to insufficient memory:
-
-~~~ shell
-$ host kernel: Out of Memory: Killed process <process_id> (cockroach).
-~~~
-
-To rectify the issue, you can either run the cockroachdb process on another node with sufficient memory, or [reduce the cockroachdb memory usage](cockroach-start.html#flags).
-
-## Decommissioning issues
-
-#### Decommissioning process hangs indefinitely
-
-**Explanation:** Before decommissioning a node, you need to make sure other nodes are available to take over the range replicas from the node. If no other nodes are available, the decommission process will hang indefinitely.
-
-**Solution:** Confirm that there are enough nodes with sufficient storage space to take over the replicas from the node you want to remove.
-
-#### Decommissioned nodes displayed in UI forever
-
-By design, decommissioned nodes are displayed in the DB Console forever. We retain the list of decommissioned nodes for the following reasons:
-
--   Decommissioning is not entirely free, so showing those decommissioned nodes in the UI reminds you of the baggage your cluster will have to carry around forever.
--   It also explains to future administrations why your node IDs have gaps (e.g., why the nodes are numbered n1, n2, and n8).
-
-You can follow the discussion here: [https://github.com/cockroachdb/cockroach/issues/24636](https://github.com/cockroachdb/cockroach/issues/24636)
-
-## Replication issues
-
-#### DB Console shows under-replicated/unavailable ranges
-
-When a CockroachDB node dies (or is partitioned) the under-replicated range count will briefly spike while the system recovers.
-
-**Explanation:** CockroachDB uses consensus replication and requires a quorum of the replicas to be available in order to allow both writes and reads to the range. The number of failures that can be tolerated is equal to (Replication factor - 1)/2. Thus CockroachDB requires (n-1)/2 nodes to achieve quorum. For example, with 3x replication, one failure can be tolerated; with 5x replication, two failures, and so on.
-
--   Under-replicated Ranges: When a cluster is first initialized, the few default starting ranges will only have a single replica, but as soon as other nodes are available, they will replicate to them until they've reached their desired replication factor. If a range does not have enough replicas, the range is said to be "under-replicated".
-
--   Unavailable Ranges: If a majority of a range's replicas are on nodes that are unavailable, then the entire range is unavailable and will be unable to process queries.
-
-**Solution:**
-
-To identify under-replicated/unavailable ranges:
-
-1.  [Access the DB Console](ui-overview.html#db-console-access).
-
-2.  On the **Cluster Overview** page, check the **Replication Status**. If the **Under-replicated ranges** or **Unavailable ranges** count is non-zero, then you have under-replicated or unavailable ranges in your cluster.
-
-3. Check for a network partition: Click the gear icon on the left-hand navigation bar to access the **Advanced Debugging** page. On the Advanced Debugging page, click **Network Latency**. In the **Latencies** table, check if any cells are marked as “X”. If yes, it indicates that the nodes cannot communicate with those nodes, and might indicate a network partition. If there's no partition, and there's still no upreplication after 5 mins, then [file an issue](file-an-issue.html).
-
-**Add nodes to the cluster:**
-
-On the DB Console’s Cluster Overview page, check if any nodes are down. If the number of nodes down is less than (n-1)/2, then that is most probably the cause of the under-replicated/unavailable ranges. Add nodes to the cluster such that the cluster has the required number of nodes to replicate ranges properly.
-
-If you still see under-replicated/unavailable ranges on the Cluster Overview page, investigate further:
-
-1.  [Access the DB Console](ui-overview.html#db-console-access)
-2.  Click the gear icon on the left-hand navigation bar to access the **Advanced Debugging** page.
-2.  Click **Problem Ranges**.
-3.  In the **Connections** table, identify the node with the under-replicated/unavailable ranges and click the node ID in the Node column.
-4.  To view the **Range Report** for a range, click on the range number in the **Under-replicated (or slow)** table or **Unavailable** table.
-5. On the Range Report page, scroll down to the **Simulated Allocator Output** section. The table contains an error message which explains the reason for the under-replicated range. Follow the guidance in the message to resolve the issue. If you need help understanding the error or the guidance, [file an issue](file-an-issue.html). Please be sure to include the full range report and error message when you submit the issue.
-
-## Node liveness issues
-
-"Node liveness" refers to whether a node in your cluster has been determined to be "dead" or "alive" by the rest of the cluster. This is achieved using checks that ensure that each node connected to the cluster is updating its liveness record. This information is shared with the rest of the cluster using an internal gossip protocol.
-
-Common reasons for node liveness issues include:
-
-- Heavy I/O load on the node. Because each node needs to update a liveness record on disk, maxing out disk bandwidth can cause liveness heartbeats to be missed. See also: [Capacity planning issues](#capacity-planning-issues).
-- Outright I/O failure due to a disk stall. This will cause node liveness issues for the same reasons as listed above.
-- Any [Networking issues](#networking-issues) with the node.
-
-The [DB Console][db_console] provides several ways to check for node liveness issues in your cluster:
-
-- [Check node heartbeat latency](#check-node-heartbeat-latency)
-- [Check node liveness record last update](#check-node-liveness-record-last-update)
-- [Check command commit latency](#check-command-commit-latency)
-
-{{site.data.alerts.callout_info}}
-For more information about how node liveness works, see [the architecture documentation on the replication layer](architecture/replication-layer.html#epoch-based-leases-table-data).
-{{site.data.alerts.end}}
-
-#### Check node heartbeat latency
-
-To check node heartbeat latency:
-
-1. In the [DB Console][db_console], select the **Metrics** tab from the left-hand side of the page.
-
-2. From the metrics page, select **Dashboard: Distributed** from the dropdown at the top of the page.
-
-3. Scroll down the metrics page to find the **Node Heartbeat Latency: 99th percentile** and **Node Heartbeat Latency: 90th percentile** graphs.
-
-**Expected values for a healthy cluster**: Less than 100ms in addition to the network latency between nodes in the cluster.
-
-#### Check node liveness record last update
-
-To see when a node last updated its liveness record:
-
-1. Go to the **Node Diagnostics** page of the [DB Console][db_console], which lives at:
-
-    `https://yourcluster.yourdomain/#/reports/nodes`
-
-2. On the Node Diagnostics page, you will see a table listing information about the nodes in your cluster.  To see when a node last updated its liveness record, check the **Updated at** field at the bottom of that node's column.
-
-**Expected values for a healthy cluster**: When you load this page, the **Updated at** field should be within 4.5 seconds of the current time.  If it's higher than that, you will see errors [in the logs](debug-and-error-logs.html).
-
-#### Check command commit latency
-
-A good signal of I/O load is the **Command Commit Latency** in the **Storage** section of the dashboards. This dashboard measures how quickly [Raft commands](architecture/replication-layer.html) are being committed by nodes in the cluster.
-
-To view command commit latency:
-
-1. In the [DB Console][db_console], select the **Metrics** tab from the left-hand side of the page.
-
-2. From the Metrics page, select **Dashboard: Storage** from the dropdown at the top of the page.
-
-3. Scroll down the metrics page to find the **Command Commit Latency: 90th percentile** and **Command Commit Latency: 99th percentile** graphs.
-
-**Expected values for a healthy cluster**: On SSDs, this should be between 1 and 100 milliseconds.  On HDDs, this should be no more than 1 second.  Note that we [strongly recommend running CockroachDB on SSDs](recommended-production-settings.html#storage).
-
-#### Impact of node failure is greater than 10 seconds
-
-When the cluster needs to access a range on a leaseholder node that is dead, that range's [lease must be transferred to a healthy node](architecture/replication-layer.html#how-leases-are-transferred-from-a-dead-node). In theory, this process should take no more than 9 seconds for liveness expiration plus the cost of several network roundtrips.
-
-In production, lease transfer upon node failure can take longer than expected. In {{ page.version.version }}, this is observed in the following scenarios:
-
-- **The leaseholder node for the liveness range fails.** The liveness range is a system range that [stores the liveness record](architecture/replication-layer.html#epoch-based-leases-table-data) for each node on the cluster. If a node fails and is also the leaseholder for the liveness range, operations cannot proceed until the liveness range is transferred to a new leaseholder and the liveness record is made available to other nodes. This can cause momentary cluster unavailability.
-
-- **The leaseholder node for `system.users` fails.** The cluster accesses the `system.users` table when authenticating a user. A customer attempting to log in to the cluster will encounter a delay while waiting for the `system.users` table to find a new leaseholder. In **v21.2.0 and later**, there is no login delay because the authentication data is cached.
-
-- **A node comes in and out of liveness, due to network failures or overload.** A "flapping" node can repeatedly lose and acquire leases in between its intermittent heartbeats, causing wide-ranging unavailability. In **v21.1.6 and later**, a node must successfully heartbeat for 30 seconds after failing a heartbeat before it is eligible to acquire leases.
-
-- **Network or DNS issues cause connection issues between nodes.** If there is no live server for the IP address or DNS lookup, connection attempts to a node will not return an immediate error, but will hang until timing out. This can cause unavailability and prevent a speedy movement of leases and recovery. In **v20.2.18, v21.1.12, and later**, CockroachDB avoids contacting unresponsive nodes or DNS during certain performance-critical operations, and the connection issue should generally resolve in 10-30 seconds. However, an attempt to contact an unresponsive node could still occur in other scenarios that are not yet addressed.
-
-- **A node's disk stalls.** A disk stall on a node can cause write operations to stall indefinitely, also causes the node's heartbeats to fail since the storage engine cannot write to disk as part of the heartbeat, and may cause read requests to fail if they are waiting for a conflicting write to complete. Lease acquisition from this node can stall indefinitely until the node is shut down or recovered. Pebble detects most stalls and will terminate the `cockroach` process after 60 seconds, but there are gaps in its detection. In **v21.2.13, v22.1.2, and later**, each lease acquisition attempt on an unresponsive node times out after 6 seconds. However, CockroachDB can still appear to stall as these timeouts are occurring.
-
-- **Otherwise unresponsive nodes.** Internal deadlock due to faulty code, resource exhaustion, OS/hardware issues, and other arbitrary failures can make a node unresponsive. This can cause leases to become stuck in certain cases, such as when a response from the previous leaseholder is needed in order to move the lease.
-
-**Solution:** If you are experiencing intermittent network or connectivity issues, first [shut down the affected nodes](../{{site.versions["stable"]}}/node-shutdown.html) temporarily so that nodes phasing in and out do not cause disruption.
-
-If a node has become unresponsive without returning an error, [shut down the node](../{{site.versions["stable"]}}/node-shutdown.html) so that network requests immediately become hard errors rather than stalling.
-
-If you are running a version of CockroachDB that is affected by an issue described here, [upgrade to a version](upgrade-cockroach-version.html) that contains the fix for the issue, as described in the preceding list.
-
-## Check for under-replicated or unavailable data
-
-To see if any data is under-replicated or unavailable in your cluster, use the `system.replication_stats` report as described in [Replication Reports](query-replication-reports.html).
-
-## Check for replication zone constraint violations
-
-To see if any of your cluster's [data placement constraints](configure-replication-zones.html#replication-constraints) are being violated, use the `system.replication_constraint_stats` report as described in [Replication Reports](query-replication-reports.html).
-
-## Check for critical localities
-
-To see which of your [localities](cockroach-start.html#locality) (if any) are critical, use the `system.replication_critical_localities` report as described in [Replication Reports](query-replication-reports.html). A locality is "critical" for a range if all of the nodes in that locality becoming [unreachable](#node-liveness-issues) would cause the range to become unavailable. In other words, the locality contains a majority of the range's replicas.
-
-## Something else?
-
-If we do not have a solution here, you can try using our other [support resources](support-resources.html), including:
-
-- [StackOverflow](http://stackoverflow.com/questions/tagged/cockroachdb)
-- [CockroachDB Community Forum](https://forum.cockroachlabs.com)
-- [Chatting with our developers on  Slack](https://cockroachdb.slack.com)
-
-<!-- Reference Links -->
-
-[db_console]: ui-overview.html
diff --git a/src/current/v20.2/cockroach-auth-session.md b/src/current/v20.2/cockroach-auth-session.md
deleted file mode 100644
index b4636d484ad..00000000000
--- a/src/current/v20.2/cockroach-auth-session.md
+++ /dev/null
@@ -1,210 +0,0 @@
----
-title: cockroach auth-session
-summary: To create and manage web sessions and authentication tokens to the HTTP interface from the command line, use the cockroach auth-session command.
-toc: true
-docs_area: reference.cli
----
-
-To create and manage web sessions and authentication tokens to the HTTP interface from the command line, use the `cockroach auth-session` [command](cockroach-commands.html) with the appropriate subcommands and flags.
-
-## Subcommands
-
-Subcommand | Usage
------------|------
-`login` | Authenticate a user against a running cluster's HTTP interface, generating an HTTP authentication token (a "cookie") which can also be used by non-interactive HTTP-based database management tools. Must be used with a valid, existing user. May be used to generate a cookie for the `root` user.
-`logout` | Revokes all previously-issued HTTP authentication tokens for the given user.
-`list` | List all authenticated sessions to the HTTP interface, including currently active and recently expired sessions.
-
-## Synopsis
-
-Log in to the HTTP interface, generating an HTTP authentication token for a given user:
-
-~~~ shell
-$ cockroach auth-session login {username} [flags]
-~~~
-
-Log out from the HTTP interface, revoking all active HTTP authentication tokens for a given user:
-
-~~~ shell
-$ cockroach auth-session logout {username} [flags]
-~~~
-
-List all authenticated sessions to the HTTP interface, including currently active and recently expired sessions:
-
-~~~ shell
-$ cockroach auth-session list [flags]
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach auth-session --help
-~~~
-
-~~~ shell
-$ cockroach auth-session {subcommand} --help
-~~~
-
-## Flags
-
-All three `auth-session` subcommands accept the standard [SQL command-line flags](cockroach-start.html#flags).
-
-In addition, the `auth-session login` subcommand supports the following flags.
-
-Flag | Description
------|------------
-`--expire-after` | Duration of the newly-created HTTP authentication token, after which the token expires. Specify the duration in numeric values suffixed by one or more of `h`, `m`, and `s` to indicate hour, minute, and second duration. See the [example](#log-in-to-the-http-interface-with-a-custom-expiry).<br><br>**Default:** `1h0m0s` (1 hour)
-`--only-cookie` | Limits output to only the newly-created HTTP authentication token (the "cookie") in the response, appropriate for output to other commands. See the [example](#log-in-to-the-http-interface-with-limited-command-output).
-
-## Response
-
-The `cockroach auth-session` subcommands return the following fields.
-
-### `auth-session login`
-
-Field | Description
-------|------------
-`username` | The username of the user authenticated.
-`session ID` | The session ID to the HTTP interface previously established for that user.
-`authentication cookie` | The cookie that may be used from the command line, or from other tools, to authenticate access to the HTTP interface for that user.
-
-### `auth-session logout`
-
-Field | Description
-------|------------
-`username` | The username of the user whose session was revoked.
-`session ID` | The session ID to the HTTP interface previously established for that user.
-`revoked` | The date and time of revocation for that user's authenticated session.
-
-### `auth-session list`
-
-Field | Description
-------|------------
-`username` | The username of the user authenticated.
-`session ID` | The session ID to the HTTP interface established for that user.
-`created` | The date and time a session was created.
-`expired` | The date and time a session expired.
-`revoked` | The date and time of revocation for that user's authenticated session. If the session is still active, this will appear as `NULL`.
-`last used` | The date and time of the last access to the HTTP interface using this session token.
-
-## Required roles
-
-To run any of the `auth-session` subcommands, you must be a member of the [`admin` role](authorization.html#admin-role). The user being authenticated via `login` or `logout` does not require any special roles.
-
-## Considerations
-
-- The `login` subcommand allows users with the [`admin` role](authorization.html#admin-role) to create HTTP authentication tokens with an arbitrary duration. If operational policy requires stricter control of authentication sessions, you can:
-
-  - Monitor the `system.web_sessions` table for all current and recent HTTP sessions.
-  - Revoke HTTP authentication tokens as needed with the `logout` subcommand. See the [example](#terminate-all-active-sessions-for-a-user).
-  - Set the `--expire-after` flag with a shorter duration. See the [example](#log-in-to-the-http-interface-with-a-custom-expiry).
-
-- The `logout` subcommand logs out all sessions for the given user; you cannot target individual sessions for logout. If more granular control of sessions is desired, consider setting the `--expire-after` flag with a shorter duration. See the [example](#log-in-to-the-http-interface-with-a-custom-expiry).
-
-## Examples
-
-### Log in to the HTTP interface
-
-Log in to the HTTP interface, by generating a new HTTP authentication token for the `web_user` user:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach auth-session login web_user
-~~~
-
-~~~
-  username |     session ID     |                       authentication cookie
------------+--------------------+---------------------------------------------------------------------
-  web_user | 784445853689282561 | session=CIGAtrWQq7rxChIQTXxYNNQxAYjyLAjHWxgUMQ==; Path=/; HttpOnly; Secure
-(1 row)
-~~~
-
-### Log in to the HTTP interface with a custom expiry
-
-Log in to the HTTP interface, by generating a new HTTP authentication token for the `web_user` user and specifying a token expiry of 4 hours and 30 minutes:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach auth-session login web_user --expire-after=4h30m
-~~~
-
-~~~
-  username |     session ID     |                       authentication cookie
------------+--------------------+---------------------------------------------------------------------
-  web_user | 784445853689282561 | session=CIGAtrWQq7rxChIQTXxYNNQxAYjyLAjHWxgUMQ==; Path=/; HttpOnly; Secure
-(1 row)
-~~~
-
-### Log in to the HTTP interface with limited command output
-
-Log in to the HTTP interface, by generating a new HTTP authentication token for the `web_user` user, limiting command output to only the generated cookie:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach auth-session login web_user --only-cookie
-~~~
-
-~~~
-session=CIGA6t2q0LrxChIQV8QCF3vuYSasR7h4LPSfmg==; Path=/; HttpOnly; Secure
-~~~
-
-This is useful if you intend to use the cookie with other command line tools. For example, you might output the generated cookie to a local file, and then pass that file to `curl` using its `--cookie` flag:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach auth-session login web_user --certs-dir=certs --only-cookie > $HOME/.cockroachdb_api_key
-$ curl --cookie $HOME/.cockroachdb_api_key https://localhost:8080/_status/logfiles/local
-~~~
-
-Of course you can also provide the cookie directly:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-curl --cookie 'session=CIGA8I7/irvxChIQDtZQsMtn3AqpgDko6bldSw==; Path=/; HttpOnly; Secure' https://localhost:8080/_status/logfiles/local
-~~~
-
-### Terminate all active sessions for a user
-
-Terminate all active sessions for the `web_user` user:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach auth-session logout web_user
-~~~
-
-~~~
-  username |     session ID     |          revoked
------------+--------------------+-----------------------------
-  web_user | 784445853689282561 | 2022-08-02 18:24:50.819614
-  web_user | 784447132063662081 | 2022-08-02 18:24:50.819614
-  web_user | 784449147579924481 | 2022-08-02 18:47:20.105254
-  web_user | 784449219848241153 | 2022-08-02 18:47:20.105254
-(4 rows)
-~~~
-
-Note that the output may include recently revoked sessions for this user as well.
-
-### List all sessions
-
-List all authenticated sessions to the HTTP interface, including currently active and recently expired sessions:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach auth-session list
-~~~
-
-~~~
-  username |     session ID     |          created           |          expires           |          revoked           |         last used
------------+--------------------+----------------------------+----------------------------+----------------------------+-----------------------------
-  root     | 784428093743988737 | 2022-08-02 16:47:36.342338 | 2022-08-02 17:47:36.341997 | NULL                       | 2022-08-02 16:47:36.342338
-  root     | 784428586862215169 | 2022-08-02 16:50:06.830294 | 2022-08-02 17:50:06.829974 | NULL                       | 2022-08-02 16:50:06.830294
-  web_user | 784447132063662081 | 2022-08-02 18:24:26.37664  | 2022-08-02 19:24:26.376299 | 2022-08-02 18:24:50.819614 | 2022-08-02 18:24:26.37664
-  web_user | 784449147579924481 | 2022-08-02 18:34:41.463345 | 2022-08-02 19:34:41.463006 | 2022-08-02 18:47:20.105254 | 2022-08-02 18:34:41.463345
-~~~
-
-A value of `NULL` in the `revoked` column indicates that the session is still active.
-
-## See also
-
-- [`cockroach` Commands Overview](cockroach-commands.html)
-- [DB Console Overview](ui-overview.html)
diff --git a/src/current/v20.2/cockroach-cert.md b/src/current/v20.2/cockroach-cert.md
deleted file mode 100644
index 96173c4aa92..00000000000
--- a/src/current/v20.2/cockroach-cert.md
+++ /dev/null
@@ -1,328 +0,0 @@
----
-title: cockroach cert
-summary: A secure CockroachDB cluster uses TLS for encrypted inter-node and client-node communication.
-toc: true
-key: create-security-certificates.html
----
-
-To secure your CockroachDB cluster's inter-node and client-node communication, you need to provide a Certificate Authority (CA) certificate that has been used to sign keys and certificates (SSLs) for:
-
-- Nodes
-- Clients
-- DB Console (optional)
-
-To create these certificates and keys, use the `cockroach cert` [commands](cockroach-commands.html) with the appropriate subcommands and flags, use [`openssl` commands](https://wiki.openssl.org/index.php/), or use a [custom CA](create-security-certificates-custom-ca.html) (for example, a public CA or your organizational CA).
-
-<div class="filters filters-big clearfix">
-  <button style="width:28%" class="filter-button current">Use <strong>cockroach cert</strong></button>
-  <a href="create-security-certificates-openssl.html"><button style="width:28%" class="filter-button">Use Openssl</button></a>
-  <a href="create-security-certificates-custom-ca.html"><button style="width:28%" class="filter-button">Use custom CA</button></a>
-</div>
-
-{{site.data.alerts.callout_success}}For details about when and how to change security certificates without restarting nodes, see <a href="rotate-certificates.html">Rotate Security Certificates</a>.{{site.data.alerts.end}}
-
-## How security certificates work
-
-1. Using the `cockroach cert` command, you create a CA certificate and key and then node and client certificates that are signed by the CA certificate. Since you need access to a copy of the CA certificate and key to create node and client certs, it's best to create everything in one place.
-
-2. You then upload the appropriate node certificate and key and the CA certificate to each node, and you upload the appropriate client certificate and key and the CA certificate to each client.
-
-3. When nodes establish contact to each other, and when clients establish contact to nodes, they use the CA certificate to verify each other's identity.
-
-## Subcommands
-
-Subcommand | Usage
------------|------
-`create-ca` | Create the self-signed certificate authority (CA), which you'll use to create and authenticate certificates for your entire cluster.
-`create-node` | Create a certificate and key for a specific node in the cluster. You specify all addresses at which the node can be reached and pass appropriate flags.
-`create-client` | Create a certificate and key for a [specific user](create-user.html) accessing the cluster from a client. You specify the username of the user who will use the certificate and pass appropriate flags.
-`list` | List certificates and keys found in the certificate directory.
-
-## Certificate directory
-
-When using `cockroach cert` to create node and client certificates, you will need access to a local copy of the CA certificate and key. It is therefore recommended to create all certificates and keys in one place and then distribute node and client certificates and keys appropriately. For the CA key, be sure to store it somewhere safe and keep a backup; if you lose it, you will not be able to add new nodes or clients to your cluster. For a walkthrough of this process, see [Manual Deployment](manual-deployment.html).
-
-## Required keys and certificates
-
-The `create-*` subcommands generate the CA certificate and all node and client certificates and keys in a single directory specified by the `--certs-dir` flag, with the files named as follows:
-
-### Node key and certificates
-
-File name pattern | File usage
--------------|------------
-`ca.crt`     | CA certificate.
-`node.crt`   | Server certificate. <br><br>`node.crt` must be signed by `ca.crt` and must have `CN=node` and the list of IP addresses and DNS names listed in `Subject Alternative Name` field. CockroachDB also supports [wildcard notation in DNS names](https://en.wikipedia.org/wiki/Wildcard_certificate).
-`node.key`   | Key for server certificate.
-
-### Client key and certificates
-
-File name pattern | File usage
--------------|------------
-`ca.crt`     | CA certificate.
-`client.<user>.crt` | Client certificate for `<user>` (e.g., `client.root.crt` for user `root`). <br><br> Must be signed  by `ca.crt`. Also, `client.<username>.crt` must have `CN=<user>` (for example, `CN=marc` for `client.marc.crt`)
-`client.<user>.key` | Key for the client certificate.
-
-Optionally, if you have a certificate issued by a public CA to securely access the DB Console, you need to place the certificate and key (`ui.crt` and `ui.key` respectively) in the directory specified by the `--certs-dir` flag. For more information, refer to [Use a UI certificate and key to access the DB Console](create-security-certificates-custom-ca.html#accessing-the-db-console-for-a-secure-cluster).
-
-Note the following:
-
-- By default, the `node.crt` is multi-functional, as in the same certificate is used for both incoming connections (from SQL and DB Console clients, and from other CockroachDB nodes) and for outgoing connections to other CockroachDB nodes. To make this possible, the `node.crt` created using the `cockroach cert` command has `CN=node` and the list of IP addresses and DNS names listed in `Subject Alternative Name` field.
-
-- The CA key is never loaded automatically by `cockroach` commands, so it should be created in a separate directory, identified by the `--ca-key` flag.
-
-- Keys (files ending in `.key`) must not have group or world permissions (maximum permissions are 0700, or `rwx------`). This check can be disabled by setting the environment variable `COCKROACH_SKIP_KEY_PERMISSION_CHECK=true`.
-
-## Synopsis
-
-Create the CA certificate and key:
-
-~~~ shell
-$ cockroach cert create-ca \
- --certs-dir=[path-to-certs-directory] \
- --ca-key=[path-to-ca-key]
-~~~
-
-Create a node certificate and key:
-
-~~~ shell
-$ cockroach cert create-node \
- [node-hostname] \
- [node-other-hostname] \
- [node-yet-another-hostname] \
- [hostname-in-wildcard-notation] \
- --certs-dir=[path-to-certs-directory] \
- --ca-key=[path-to-ca-key]
-~~~
-
-Create a client certificate and key:
-
-~~~ shell
-$ cockroach cert create-client \
- [username] \
- --certs-dir=[path-to-certs-directory] \
- --ca-key=[path-to-ca-key]
-~~~
-
-List certificates and keys:
-
-~~~ shell
-$ cockroach cert list \
- --certs-dir=[path-to-certs-directory]
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach cert --help
-~~~
-~~~ shell
-$ cockroach cert <subcommand> --help
-~~~
-
-## Flags
-
-The `cert` command and subcommands support the following [general-use](#general) and [logging](#logging) flags.
-
-### General
-
-Flag | Description
------|-----------
-`--certs-dir` | The path to the [certificate directory](#certificate-directory) containing all certificates and keys needed by `cockroach` commands.<br><br>This flag is used by all subcommands.<br><br>**Default:** `${HOME}/.cockroach-certs/`
-`--ca-key` | The path to the private key protecting the CA certificate. <br><br>This flag is required for all `create-*` subcommands. When used with `create-ca` in particular, it defines where to create the CA key; the specified directory must exist.<br><br>**Env Variable:** `COCKROACH_CA_KEY`
-`--allow-ca-key-reuse` | When running the `create-ca` subcommand, pass this flag to re-use an existing CA key identified by `--ca-key`. Otherwise, a new CA key will be generated.<br><br>This flag is used only by the `create-ca` subcommand. It helps avoid accidentally re-using an existing CA key.
-`--overwrite` | When running `create-*` subcommands, pass this flag to allow existing files in the certificate directory (`--certs-dir`) to be overwritten.<br><br>This flag helps avoid accidentally overwriting sensitive certificates and keys.
-`--lifetime` | The lifetime of the certificate, in hours, minutes, and seconds. <br><br>Certificates are valid from the time they are created through the duration specified in `--lifetime`.<br><br>**Default:** `87840h0m0s` (10 years)
-`--key-size` | The size of the CA, node, or client key, in bits.<br><br>**Default:** `2048`
-<a name="flag-pkcs8"></a> `--also-generate-pkcs8-key` | Also create a key in [PKCS#8 format](https://tools.ietf.org/html/rfc5208), which is the standard key encoding format used by Java.  For example usage, see [Build a Java App with CockroachDB](build-a-java-app-with-cockroachdb.html).
-
-### Logging
-
-By default, the `cert` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## Examples
-
-### Create the CA certificate and key pair
-
-1. Create two directories:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir my-safe-directory
-    ~~~
-    - `certs`: You'll generate your CA certificate and all node and client certificates and keys in this directory and then upload some of the files to your nodes.
-    - `my-safe-directory`: You'll generate your CA key in this directory and then reference the key when generating node and client certificates. After that, you'll keep the key safe and secret; you will not upload it to your nodes.
-
-2. Generate the CA certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-ca \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ls -l certs
-    ~~~
-
-    ~~~
-    total 8
-    -rw-r--r--  1 maxroach  maxroach  1.1K Jul 10 14:12 ca.crt
-    ~~~
-
-### Create the certificate and key pairs for nodes
-
-1. Generate the certificate and key for the first node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    node1.example.com \
-    node1.another-example.com \
-    *.dev.another-example.com \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ls -l certs
-    ~~~
-
-    ~~~
-    total 24
-    -rw-r--r--  1 maxroach  maxroach  1.1K Jul 10 14:12 ca.crt
-    -rw-r--r--  1 maxroach  maxroach  1.2K Jul 10 14:16 node.crt
-    -rw-------  1 maxroach  maxroach  1.6K Jul 10 14:16 node.key
-    ~~~
-
-2. Upload certificates to the first node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Create the certs directory:
-    $ ssh <username>@<node1 address> "mkdir certs"
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Upload the CA certificate and node certificate and key:
-    $ scp certs/ca.crt \
-    certs/node.crt \
-    certs/node.key \
-    <username>@<node1 address>:~/certs
-    ~~~
-
-3. Delete the local copy of the first node's certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm certs/node.crt certs/node.key
-    ~~~
-
-    {{site.data.alerts.callout_info}}This is necessary because the certificates and keys for additional nodes will also be named <code>node.crt</code> and <code>node.key</code> As an alternative to deleting these files, you can run the next <code>cockroach cert create-node</code> commands with the <code>--overwrite</code> flag.{{site.data.alerts.end}}
-
-4. Create the certificate and key for the second node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    node2.example.com \
-    node2.another-example.com \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ls -l certs
-    ~~~
-
-    ~~~
-    total 24
-    -rw-r--r--  1 maxroach  maxroach  1.1K Jul 10 14:12 ca.crt
-    -rw-r--r--  1 maxroach  maxroach  1.2K Jul 10 14:17 node.crt
-    -rw-------  1 maxroach  maxroach  1.6K Jul 10 14:17 node.key
-    ~~~
-
-5. Upload certificates to the second node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Create the certs directory:
-    $ ssh <username>@<node2 address> "mkdir certs"
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Upload the CA certificate and node certificate and key:
-    $ scp certs/ca.crt \
-    certs/node.crt \
-    certs/node.key \
-    <username>@<node2 address>:~/certs
-    ~~~
-
-6. Repeat steps 3 - 5 for each additional node.
-
-### Create the certificate and key pair for a client
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client \
-maxroach \
---certs-dir=certs \
---ca-key=my-safe-directory/ca.key
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ls -l certs
-~~~
-
-~~~
-total 40
--rw-r--r--  1 maxroach  maxroach  1.1K Jul 10 14:12 ca.crt
--rw-r--r--  1 maxroach  maxroach  1.1K Jul 10 14:13 client.maxroach.crt
--rw-------  1 maxroach  maxroach  1.6K Jul 10 14:13 client.maxroach.key
--rw-r--r--  1 maxroach  maxroach  1.2K Jul 10 14:17 node.crt
--rw-------  1 maxroach  maxroach  1.6K Jul 10 14:17 node.key
-~~~
-
-### List certificates and keys
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert list \
---certs-dir=certs
-~~~
-
-~~~
-Certificate directory: certs
-+-----------------------+---------------------+---------------------+------------+--------------------------------------------------------+-------+
-|         Usage         |  Certificate File   |      Key File       |  Expires   |                         Notes                          | Error |
-+-----------------------+---------------------+---------------------+------------+--------------------------------------------------------+-------+
-| Certificate Authority | ca.crt              |                     | 2027/07/18 | num certs: 1                                           |       |
-| Node                  | node.crt            | node.key            | 2022/07/14 | addresses: node2.example.com,node2.another-example.com |       |
-| Client                | client.maxroach.crt | client.maxroach.key | 2022/07/14 | user: maxroach                                         |       |
-+-----------------------+---------------------+---------------------+------------+--------------------------------------------------------+-------+
-(3 rows)
-~~~
-
-## See also
-
-- [Security overview](security-overview.html)
-- [Authentication](authentication.html)
-- [Client Connection Parameters](connection-parameters.html)
-- [Rotate Security Certificates](rotate-certificates.html)
-- [Manual Deployment](manual-deployment.html)
-- [Orchestrated Deployment](orchestration.html)
-- [Local Deployment](secure-a-cluster.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/cockroach-commands.md b/src/current/v20.2/cockroach-commands.md
deleted file mode 100644
index 0dc2811d816..00000000000
--- a/src/current/v20.2/cockroach-commands.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Cockroach Commands
-summary: Learn the commands for configuring, starting, and managing a CockroachDB cluster.
-toc: true
----
-
-This page introduces the `cockroach` commands for configuring, starting, and managing a CockroachDB cluster, as well as environment variables that can be used in place of certain flags.
-
-You can run `cockroach help` in your shell to get similar guidance.
-
-
-## Commands
-
-Command | Usage
---------|----
-[`cockroach start`](cockroach-start.html) | Start a node as part of a multi-node cluster.
-[`cockroach init`](cockroach-init.html) | Initialize a multi-node cluster.
-[`cockroach start-single-node`](cockroach-start-single-node.html) | Start a single-node cluster.
-[`cockroach cert`](cockroach-cert.html) | Create CA, node, and client certificates.
-[`cockroach quit`](cockroach-quit.html) | Temporarily stop a node or permanently remove a node.
-[`cockroach sql`](cockroach-sql.html) | Use the built-in SQL client.
-[`cockroach sqlfmt`](cockroach-sqlfmt.html) | Reformat SQL queries for enhanced clarity.
-[`cockroach node`](cockroach-node.html) | List node IDs, show their status, decommission nodes for removal, or recommission nodes.
-[`cockroach auth-session`](cockroach-auth-session.html) | Create and manage web sessions and authentication tokens to the HTTP interface from the command line.
-[`cockroach dump`](cockroach-dump.html) | **Deprecated.** Use one of the following instead:<ul><li>To back up your data, take a [full backup](take-full-and-incremental-backups.html).</li><li>To export your data in plaintext format, use [`EXPORT`](export.html).</li><li>To view table schema in plaintext, use [`SHOW CREATE TABLE`](show-create.html).</li></ul>
-[`cockroach demo`](cockroach-demo.html) | Start a temporary, in-memory CockroachDB cluster, and open an interactive SQL shell to it.
-[`cockroach gen`](cockroach-gen.html) | Generate manpages, a bash completion file, example SQL data, or an HAProxy configuration file for a running cluster.
-[`cockroach version`](cockroach-version.html) | Output CockroachDB version details.
-[`cockroach debug ballast`](cockroach-debug-ballast.html) | Create a large, unused file in a node's storage directory that you can delete if the node runs out of disk space.
-[`cockroach debug encryption-active-key`](cockroach-debug-encryption-active-key.html) | View the encryption algorithm and store key.
-[`cockroach debug zip`](cockroach-debug-zip.html) | Generate a `.zip` file that can help Cockroach Labs troubleshoot issues with your cluster.
-[`cockroach debug merge-logs`](cockroach-debug-merge-logs.html) | Merge multiple log files from different machines into a single stream.
-[`cockroach workload`](cockroach-workload.html) | Run a built-in load generator against a cluster.
-[`cockroach nodelocal upload`](cockroach-nodelocal-upload.html) |  Upload a file to the `externalIODir` on a node's local file system.
-[`cockroach userfile upload`](cockroach-userfile-upload.html)   | <span class="version-tag">New in v20.2:</span> The cockroach userfile upload command uploads a file to user-scoped file storage.
-[`cockroach userfile list`](cockroach-userfile-list.html)       | <span class="version-tag">New in v20.2:</span> List the files stored in the user-scoped file storage.
-[`cockroach userfile delete`](cockroach-userfile-delete.html)   | <span class="version-tag">New in v20.2:</span> Deletes the files stored in the user-scoped file storage.
-
-## Environment variables
-
-For many common `cockroach` flags, such as `--port` and `--user`, you can set environment variables once instead of manually passing the flags each time you execute commands.
-
-- To find out which flags support environment variables, see the documentation for each [command](#commands).
-- To output the current configuration of CockroachDB and other environment variables, run `env`.
-- When a node uses environment variables on [startup](cockroach-start.html), the variable names are printed to the node's logs; however, the variable values are not.
-
-CockroachDB prioritizes command flags, environment variables, and defaults as follows:
-
-1. If a flag is set for a command, CockroachDB uses it.
-2. If a flag is not set for a command, CockroachDB uses the corresponding environment variable.
-3. If neither the flag nor environment variable is set, CockroachDB uses the default for the flag.
-4. If there's no flag default, CockroachDB gives an error.
-
-For more details, see [Client Connection Parameters](connection-parameters.html).
diff --git a/src/current/v20.2/cockroach-debug-ballast.md b/src/current/v20.2/cockroach-debug-ballast.md
deleted file mode 100644
index e271968a174..00000000000
--- a/src/current/v20.2/cockroach-debug-ballast.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: cockroach debug ballast
-summary: Create a large, unused file in a node's storage directory that you can delete if the node runs out of disk space.
-toc: true
----
-
-The `cockroach debug ballast` [command](cockroach-commands.html) creates a large, unused file that you can place in a node's storage directory. In the case that a node runs out of disk space and shuts down, you can delete the ballast file to free up enough space to be able to restart the node.
-
-- Do not run `cockroach debug ballast` with a unix `root` user. Doing so brings the risk of mistakenly affecting system directories or files.
-- Do not name the target file similar to a block device in `/dev`. Doing so brings the risk of mistyping a `/dev` prefix into the command and thereby corrupting a filesystem.  
-- In addition to placing a ballast file in each node's storage directory, it is important to actively [monitor remaining disk space](monitoring-and-alerting.html#events-to-alert-on).
-- Ballast files may be created in many ways, including the standard `dd` command. `cockroach debug ballast` uses the `fallocate` system call when available, so it will be faster than `dd`.
-
-## Subcommands
-
-{% include {{ page.version.version }}/misc/debug-subcommands.md %}
-
-## Synopsis
-
-Create a ballast file:
-
-~~~ shell
-$ cockroach debug ballast [path to ballast file] [flags]
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach debug ballast --help
-~~~
-
-## Flags
-
-Flag | Description
------|-----------
-`--size`<br>`-z` | The amount of space to fill, or to leave available, in a node's storage directory via a ballast file. Positive values equal the size of the ballast file. Negative values equal the amount of space to leave after creating the ballast file. This can be a percentage (notated as a decimal or with %) or any bytes-based unit, for example:<br><br>`--size=1000000000 ----> 1000000000 bytes`<br>`--size=1GiB ----> 1073741824 bytes`<br>`--size=5% ----> 5% of available space`<br>`--size=0.05 ----> 5% of available space`<br>`--size=.05 ----> 5% of available space`<br><br>**Default:** `1GB`
-
-## Examples
-
-### Create a 1GB ballast file (default)
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug ballast cockroach-data/ballast.txt
-~~~
-
-### Create a ballast file of a different size
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug ballast cockroach-data/ballast.txt --size=2GB
-~~~
-
-## See also
-
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Production Checklist](recommended-production-settings.html)
diff --git a/src/current/v20.2/cockroach-debug-encryption-active-key.md b/src/current/v20.2/cockroach-debug-encryption-active-key.md
deleted file mode 100644
index bb171af21ef..00000000000
--- a/src/current/v20.2/cockroach-debug-encryption-active-key.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: cockroach debug encryption-active-key
-summary: Learn the command for viewing the algorithm and store key for an encrypted store.
-toc: true
-key: debug-encryption-active-key.html
----
-
-The `cockroach debug encryption-active-key` [command](cockroach-commands.html) displays the encryption algorithm and store key for an encrypted store.
-
-## Synopsis
-
-~~~ shell
-$ cockroach debug encryption-active-key [path specified by the store flag]
-~~~
-
-## Subcommands
-
-{% include {{ page.version.version }}/misc/debug-subcommands.md %}
-
-## Example
-
-Start a node with encryption-at-rest enabled:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start --store=cockroach-data --enterprise-encryption=path=cockroach-data,key=aes-128.key,old-key=plain --insecure --certs-dir=certs
-~~~
-
-View the encryption algorithm and store key:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug encryption-active-key cockroach-data
-~~~
-
-~~~
-AES128_CTR:be235c29239aa84a48e5e1874d76aebf7fb3c1bdc438cec2eb98de82f06a57a0
-~~~
-
-## See also
-
-- [File an Issue](file-an-issue.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Troubleshooting Overview](troubleshooting-overview.html)
diff --git a/src/current/v20.2/cockroach-debug-merge-logs.md b/src/current/v20.2/cockroach-debug-merge-logs.md
deleted file mode 100644
index b02f4128895..00000000000
--- a/src/current/v20.2/cockroach-debug-merge-logs.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: cockroach debug merge-logs
-summary: Learn the command for merging the collected debug logs from all nodes in your cluster.
-toc: true
-key: debug-merge-logs.html
----
-
-The `cockroach debug merge-logs` [command](cockroach-commands.html) merges log files from multiple nodes into a single time-ordered stream of messages with an added per-message prefix to indicate the corresponding node. You can use it in conjunction with logs collected using the [`debug zip`](cockroach-debug-zip.html) command to aid in debugging.
-
-{{site.data.alerts.callout_danger}}
-The file produced by `cockroach debug zip` can contain highly [sensitive, identifiable information](debug-and-error-logs.html#redacted-logs), such as usernames, hashed passwords, and possibly your table's data. You can use the [`--redact`](#example) flag to redact the sensitive data out of log files and crash reports before sharing them with Cockroach Labs.
-{{site.data.alerts.end}}
-
-## Subcommands
-
-{% include {{ page.version.version }}/misc/debug-subcommands.md %}
-
-## Synopsis
-
-~~~ shell
-$ cockroach debug merge-logs [log file directory] [flags]
-~~~
-
-## Flags
-
-Use the following flags to filter the `debug merge-logs` results for a specified regular expression or time range.
-
-Flag | Description
------|-----------
-`--filter` | Limit the results to the specified regular expression
-`--from` | Start time for the time range filter.
-`--to` | End time for the time range filter.
-`--redact` | Redact [sensitive data](debug-and-error-logs.html#redacted-logs) from the log files.
-
-## Example
-
-Generate a debug zip file:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug zip ./cockroach-data/logs/debug.zip --insecure
-~~~
-
-Unzip the file:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ unzip ./cockroach-data/logs/debug.zip
-~~~
-
-Merge the logs in the debug folder:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug merge-logs debug/nodes/*/logs/*
-~~~
-
-Alternatively, filter the merged logs for a specified time range:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug merge-logs debug/nodes/*/logs/* --from= "18:36:28.208553" --to= "18:36:29.232864"
-~~~
-
-You can also filter the merged logs for a regular expression:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach debug merge-logs debug/nodes/*/logs/* --filter="RUNNING IN INSECURE MODE"
-~~~
-
-You can redact sensitive information from the merged logs:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach debug merge-logs --redact debug/nodes/*/logs/*
-~~~
-
-## See also
-
-- [File an Issue](file-an-issue.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Troubleshooting Overview](troubleshooting-overview.html)
diff --git a/src/current/v20.2/cockroach-debug-zip.md b/src/current/v20.2/cockroach-debug-zip.md
deleted file mode 100644
index f18ac43e742..00000000000
--- a/src/current/v20.2/cockroach-debug-zip.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: cockroach debug zip
-summary: Learn the commands for collecting debug information from all nodes in your cluster.
-toc: true
-key: debug-zip.html
----
-
-The `cockroach debug zip` [command](cockroach-commands.html) connects to your cluster and gathers information from each active node into a single file (inactive nodes are not included):
-
-- [Log files](debug-and-error-logs.html)
-- Secondary log files (e.g., storage engine logs, [execution logs](query-behavior-troubleshooting.html#cluster-wide-execution-logs), [slow query logs](query-behavior-troubleshooting.html#using-the-slow-query-log))
-- Cluster events
-- Schema change events
-- Node liveness
-- Gossip data
-- Stack traces
-- Range lists
-- A list of databases and tables
-- Jobs
-- [Cluster Settings](cluster-settings.html)
-- [Metrics](ui-custom-chart-debug-page.html#available-metrics)
-- Alerts
-- Heap profiles
-- Problem ranges
-- Sessions
-- Queries
-- Thread stack traces (Linux only)
-- CPU profiles
-
-Additionally, you can run the [`debug merge-logs`](cockroach-debug-merge-logs.html) command to merge the collected logs in one file, making it easier to parse them to locate an issue with your cluster.
-
-{{site.data.alerts.callout_danger}}
-The file produced by `cockroach debug zip` can contain highly [sensitive, identifiable information](debug-and-error-logs.html#redacted-logs), such as usernames, hashed passwords, and possibly your table's data. You can use the [`--redact-logs`](#redact-sensitive-information-from-the-logs) flag to redact the sensitive data out of log files and crash reports before sharing them with Cockroach Labs.
-{{site.data.alerts.end}}
-
-## Details
-
-### Use cases
-
-There are two scenarios in which `debug zip` is useful:
-
-- To collect all of your nodes' logs, which you can then parse to locate issues. It's important to note, though, that `debug zip` can only access logs from active nodes. For more information, see [Collecting log files](#collecting-log-files) below.
-
-- If you experience severe or difficult-to-reproduce issues with your cluster, Cockroach Labs might ask you to send us your cluster's debugging information using `cockroach debug zip`.
-
-### Collecting log files
-
-When you issue the `debug zip` command, the node that receives the request connects to each other node in the cluster. Once it's connected, the node requests the content of all log files stored on the node, the location of which is determined by the `--log-dir` value when you [started the node](cockroach-start.html).
-
-Because `debug zip` relies on CockroachDB's distributed architecture, this means that nodes not currently connected to the cluster cannot respond to the request, so their log files *are not* included. In such situations, we recommend using the [`--host` flag](#general) to point `debug zip` at individual nodes until data has been gathered for the entire cluster.
-
-After receiving the log files from all of the active nodes, the requesting node aggregates the files and writes them to an archive file you specify.
-
-You can locate logs in the unarchived file's `debug/nodes/[node dir]/logs` directories.
-
-## Subcommands
-
-{% include {{ page.version.version }}/misc/debug-subcommands.md %}
-
-## Synopsis
-
-~~~ shell
-$ cockroach debug zip [ZIP file destination] [flags]
-~~~
-
-It's important to understand that the `[flags]` here are used to connect to CockroachDB nodes. This means the values you use in those flags must connect to an active node. If no nodes are live, you must [start at least one node](cockroach-start.html).
-
-## Flags
-
-The `debug zip` subcommand supports the following [general-use](#general), [client connection](#client-connection), and [logging](#logging) flags.
-
-### General
-
-Flag | Description
------|-----------
-`--certs-dir` | The path to the [certificate directory](cockroach-cert.html). The directory must contain valid certificates if running in secure mode.<br><br>**Env Variable:** `COCKROACH_CERTS_DIR`<br>**Default:** `${HOME}/.cockroach-certs/`
-`--host` | The server host to connect to. This can be the address of any node in the cluster. <br><br>**Env Variable:** `COCKROACH_HOST`<br>**Default:** `localhost`
-`--cluster-name` | The cluster name to use to verify the cluster's identity. If the cluster has a cluster name, you must include this flag. For more information, see [`cockroach start`](cockroach-start.html#general).
-`--disable-cluster-name-verification` | Disables the cluster name check for this command. This flag must be paired with `--cluster-name`. For more information, see [`cockroach start`](cockroach-start.html#general).
-`--insecure` | Run in insecure mode. If this flag is not set, the `--certs-dir` flag must point to valid certificates.<br><br>**Env Variable:** `COCKROACH_INSECURE`<br>**Default:** `false`
-`--port`<br>`-p` | The server port to connect to. <br><br>**Env Variable:** `COCKROACH_PORT`<br>**Default:** `26257`
-`--nodes` | <span class="version-tag">New in v20.2:</span> Specify nodes to inspect as a comma-separated list or range of node IDs. For example:<br><br>`--nodes=1,10,13-15`
-`--exclude-nodes` | <span class="version-tag">New in v20.2:</span> Specify nodes to exclude from inspection as a comma-separated list or range of node IDs. For example:<br><br>`--exclude-nodes=1,10,13-15`
-`--redact-logs` | Redact [sensitive data](debug-and-error-logs.html#redacted-logs) from the log files. Note that this flag removes sensitive information only from the log files. The other items (listed above) collected by the `debug zip` command may still contain sensitive information.
-
-### Client connection
-
-Flag | Description
------|-----------
-`--url` | A [connection URL](connection-parameters.html#connect-using-a-url) to use instead of the other arguments.<br><br>**Env Variable:** `COCKROACH_URL`<br>**Default:** no URL
-
-### Logging
-
-By default, the `debug zip` command logs errors it experiences to `stderr`. Note that these are errors executing `debug zip`; these are not errors that the logs collected by `debug zip` contain.
-
-If you need to troubleshoot this command's behavior, you can also change its [logging behavior](debug-and-error-logs.html).
-
-## Examples
-
-### Generate a debug zip file
-
-Generate the debug zip file for an insecure cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug zip ./cockroach-data/logs/debug.zip --insecure --host=200.100.50.25
-~~~
-
-Generate the debug zip file for a secure cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug zip ./cockroach-data/logs/debug.zip --host=200.100.50.25
-~~~
-
-{{site.data.alerts.callout_info}}Secure examples assume you have the appropriate certificates in the default certificate directory, <code>${HOME}/.cockroach-certs/</code>.{{site.data.alerts.end}}
-
-### Redact sensitive information from the logs
-
-Example of a log string without redaction enabled:
-
-~~~
-server/server.go:1423 ⋮ password of user ‹admin› was set to ‹"s3cr34?!@x_"›
-~~~
-
-Enable log redaction:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach debug zip ./cockroach-data/logs/debug.zip -- redact-logs --insecure --host=200.100.50.25
-~~~
-
-~~~
-server/server.go:1423 ⋮ password of user ‹×› was set to ‹×›
-~~~
-
-## See also
-
-- [File an Issue](file-an-issue.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Troubleshooting Overview](troubleshooting-overview.html)
diff --git a/src/current/v20.2/cockroach-demo.md b/src/current/v20.2/cockroach-demo.md
deleted file mode 100644
index 636c84d9c7e..00000000000
--- a/src/current/v20.2/cockroach-demo.md
+++ /dev/null
@@ -1,508 +0,0 @@
----
-title: cockroach demo
-summary: Use cockroach demo to open a SQL shell to a temporary, in-memory, CockroachDB cluster.
-toc: true
----
-
-The `cockroach demo` [command](cockroach-commands.html) starts a temporary, in-memory CockroachDB cluster of one or more nodes, with or without a preloaded dataset, and opens an interactive SQL shell to the cluster.
-
-- All [SQL shell](#sql-shell) commands, client-side options, help, and shortcuts supported by the [`cockroach sql`](cockroach-sql.html) command are also supported by `cockroach demo`.
-- The in-memory cluster persists only as long as the SQL shell is open. As soon as the shell is exited, the cluster and all its data are permanently destroyed. This command is therefore recommended only as an easy way to experiment with the CockroachDB SQL dialect.
-- By default, `cockroach demo` starts in secure mode using TLS certificates to encrypt network communication. It also serves a local [DB Console](#connection-parameters) that does not use TLS encryption.
-- Each instance of `cockroach demo` loads a temporary [Enterprise license](https://www.cockroachlabs.com/get-cockroachdb/enterprise/) that expires after 24 hours. To prevent the loading of a temporary license, set the `--disable-demo-license` flag.
-
-## Synopsis
-
-View help for `cockroach demo`:
-
-~~~ shell
-$ cockroach demo --help
-~~~
-
-Start a single-node demo cluster with the `movr` dataset pre-loaded:
-
-~~~ shell
-$ cockroach demo <flags>
-~~~
-
-Load a different dataset into a demo cluster:
-
-~~~ shell
-$ cockroach demo <dataset> <flags>
-~~~
-
-Run the `movr` workload against a demo cluster:
-
-~~~ shell
-$ cockroach demo --with-load <other flags>
-~~~
-
-Execute SQL from the command line against a demo cluster
-
-~~~ shell
-$ cockroach demo --execute="<sql statement>;<sql statement>" --execute="<sql-statement>" <other flags>
-~~~
-
-Start a multi-node demo cluster:
-
-~~~ shell
-$ cockroach demo --nodes=<number of nodes> <other flags>
-~~~
-
-Start a multi-region demo cluster with automatic geo-partitioning
-
-~~~ shell
-$ cockroach demo --geo-partitioned-replicas <other flags>
-~~~
-
-Start a multi-region demo cluster with manually defined localities
-
-~~~ shell
-$ cockroach demo --nodes=<number of nodes> --demo-locality=<key:value pair per node> <other flags>
-~~~
-
-Stop a demo cluster:
-
-~~~ sql
-> \q
-~~~
-
-~~~ sql
-> quit
-~~~
-
-~~~ sql
-> exit
-~~~
-
-~~~ shell
-ctrl-d
-~~~
-
-
-## Datasets
-
-{{site.data.alerts.callout_success}}
-By default, the `movr` dataset is pre-loaded into a demo cluster. To load a different dataset, use [`cockroach demo <dataset>`](#load-a-sample-dataset-into-a-demo-cluster). To start a demo cluster without a pre-loaded dataset, pass the `--empty` flag.
-
-{{site.data.alerts.end}}
-
-Workload | Description
----------|------------
-`bank` | A `bank` database, with one `bank` table containing account details.
-`intro` | An `intro` database, with one table, `mytable`, with a hidden message.
-`kv` | A `kv` database, with one key-value-style table.
-`movr` | A `movr` database, with several tables of data for the [MovR example application](movr.html).<br><br>By default, `cockroach demo` loads the `movr` database as the [current database](sql-name-resolution.html#current-database), with sample region (`region`) and availability zone (`az`) replica localities for each node specified with the [`--nodes` flag](cockroach-demo.html#flags).
-`startrek` | A `startrek` database, with two tables, `episodes` and `quotes`.
-`tpcc` | A `tpcc` database, with a rich schema of multiple tables.
-`ycsb` | A `ycsb` database, with a `usertable` from the Yahoo! Cloud Serving Benchmark.
-
-## Flags
-
-### General
-
-The `demo` command supports the following general-use flags.
-
-Flag | Description
------|------------
-`--cache` | For each demo node, the total size for caches. This can be a percentage (notated as a decimal or with `%`) or any bytes-based unit, for example: <br><br>`--cache=.25`<br>`--cache=25%`<br>`--cache=1000000000 ----> 1000000000 bytes`<br>`--cache=1GB ----> 1000000000 bytes`<br>`--cache=1GiB ----> 1073741824 bytes` <br><br>**Default:** `64MiB`
-`--demo-locality` | Specify [locality](cockroach-start.html#locality) information for each demo node. The input is a colon-separated list of key-value pairs, where the i<sup>th</sup> pair is the locality setting for the i<sup>th</sup> demo cockroach node.<br><br>For example, the following option assigns node 1's region to `us-east1` and availability zone to `1`, node 2's region to `us-east2` and availability zone to `2`, and node 3's region to `us-east3` and availability zone to `3`:<br><br>`--demo-locality=region=us-east1,az=1:region=us-east1,az=2:region=us-east1,az=3`<br><br>By default, `cockroach demo` uses sample region (`region`) and availability zone (`az`) replica localities for each node specified with the `--nodes` flag.
-`--disable-demo-license` |  Start the demo cluster without loading a temporary [Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/) that expires after 24 hours.<br><br>Setting the `COCKROACH_SKIP_ENABLING_DIAGNOSTIC_REPORTING` environment variable will also prevent the loading of a temporary license, along with preventing the sharing of anonymized [diagnostic details](diagnostics-reporting.html) with Cockroach Labs.
-`--echo-sql` | Reveal the SQL statements sent implicitly by the command-line utility. This can also be enabled within the interactive SQL shell via the `\set echo` [shell command](#commands).
-`--empty` | Start the demo cluster without a pre-loaded dataset.
-`--execute`<br>`-e` | Execute SQL statements directly from the command line, without opening a shell. This flag can be set multiple times, and each instance can contain one or more statements separated by semi-colons.<br><br>If an error occurs in any statement, the command exits with a non-zero status code and further statements are not executed. The results of each statement are printed to the standard output (see `--format` for formatting options).
-`--format` | How to display table rows printed to the standard output. Possible values: `tsv`, `csv`, `table`, `raw`, `records`, `sql`, `html`.<br><br>**Default:** `table` for sessions that [output on a terminal](cockroach-sql.html#session-and-output-types); `tsv` otherwise<br /><br />This flag corresponds to the `display_format` [client-side option](#client-side-options) for use in interactive sessions.
-`--geo-partitioned-replicas` | Start a 9-node demo cluster with the [Geo-Partitioned Replicas](topology-geo-partitioned-replicas.html) topology pattern applied to the [`movr`](movr.html) database.
-`--insecure` |  Include this to start the demo cluster in insecure mode.<br><br>**Env Variable:** `COCKROACH_INSECURE`
-`--max-sql-memory` | For each demo node, the maximum in-memory storage capacity for temporary SQL data, including prepared queries and intermediate data rows during query execution. This can be a percentage (notated as a decimal or with `%`) or any bytes-based unit, for example:<br><br>`--max-sql-memory=.25`<br>`--max-sql-memory=25%`<br>`--max-sql-memory=10000000000 ----> 1000000000 bytes`<br>`--max-sql-memory=1GB ----> 1000000000 bytes`<br>`--max-sql-memory=1GiB ----> 1073741824 bytes`<br><br>**Default:** `128MiB`
-`--nodes` | Specify the number of in-memory nodes to create for the demo.<br><br>**Default:** 1
-`--safe-updates` | Disallow potentially unsafe SQL statements, including `DELETE` without a `WHERE` clause, `UPDATE` without a `WHERE` clause, and `ALTER TABLE ... DROP COLUMN`.<br><br>**Default:** `true` for [interactive sessions](cockroach-sql.html#session-and-output-types); `false` otherwise<br><br>Potentially unsafe SQL statements can also be allowed/disallowed for an entire session via the `sql_safe_updates` [session variable](set-vars.html).
-`--set` | Set a [client-side option](#client-side-options) before starting the SQL shell or executing SQL statements from the command line via `--execute`. This flag may be specified multiple times, once per option.<br><br>After starting the SQL shell, the `\set` and `unset` commands can be use to enable and disable client-side options as well.
-`--with-load` |  Run a demo [`movr`](movr.html) workload against the preloaded `movr` database.<br><br> When running a multi-node demo cluster, load is balanced across all nodes.
-
-### Logging
-
-By default, the `demo` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## SQL shell
-
-### Welcome text
-
-When the SQL shell connects to the demo cluster at startup, it prints a welcome text with some tips and cluster details. Most of these details resemble the [welcome text](cockroach-sql.html#welcome-message) that is printed when connecting `cockroach sql` to a permanent cluster. `cockroach demo` also includes some [connection parameters](#connection-parameters) for connecting to the DB Console or for connecting another SQL client to the demo cluster.
-
-~~~ shell
-#
-# Welcome to the CockroachDB demo database!
-#
-# You are connected to a temporary, in-memory CockroachDB cluster of 1 node.
-#
-# This demo session will attempt to enable Enterprise features
-# by acquiring a temporary license from Cockroach Labs in the background.
-# To disable this behavior, set the environment variable
-# COCKROACH_SKIP_ENABLING_DIAGNOSTIC_REPORTING=true.
-#
-# Beginning initialization of the movr dataset, please wait...
-#
-# The cluster has been preloaded with the "movr" dataset
-# (MovR is a fictional vehicle sharing company).
-#
-# Reminder: your changes to data stored in the demo session will not be saved!
-#
-# Connection parameters:
-#   (console) http://127.0.0.1:59403
-#   (sql)     postgres://root:admin@?host=%2Fvar%2Ffolders%2Fk1%2Fr048yqpd7_9337rgxm9vb_gw0000gn%2FT%2Fdemo635924269&port=26257
-#   (sql/tcp) postgres://root:admin@127.0.0.1:59405?sslmode=require
-#
-#
-# The user "root" with password "admin" has been created. Use it to access the Web UI!
-#
-# Server version: CockroachDB CCL v20.2.0 (x86_64-apple-darwin19.6.0, built , go1.14.4) (same version as client)
-# Cluster ID: d4055073-8b30-490b-97bf-39ced0cd6471
-# Organization: Cockroach Demo
-#
-# Enter \? for a brief introduction.
-##
-~~~
-
-### Connection parameters
-
-The SQL shell welcome text includes connection parameters for accessing the DB Console and for connecting other SQL clients to the demo cluster:
-
-~~~
-# Connection parameters:
-#   (console) http://127.0.0.1:50037
-#   (sql)     postgres://root:admin@?host=%2Fvar%2Ffolders%2Fk1%2Fr048yqpd7_9337rgxm9vb_gw0000gn%2FT%2Fdemo294284060&port=26257
-#   (sql/tcp) postgres://root:admin@127.0.0.1:50039?sslmode=require
-~~~
-
-Parameter | Description
-----------|------------
-`console` | Use this link to access a local [DB Console](ui-overview.html). To login, use the `root` user with password `admin`.
-`sql` | Use this connection URL to establish a [Unix domain socket connection](cockroach-sql.html#connect-to-a-cluster-listening-for-unix-domain-socket-connections) with a client that is installed on the same machine.
-`sql/tcp` | Use this connection URL for standard sql/tcp connections from other SQL clients such as [`cockroach sql`](cockroach-sql.html).
-
-{{site.data.alerts.callout_info}}
-You do not need to create or specify node and client certificates in `sql` or `sql/tcp` connection URLs.
-{{site.data.alerts.end}}
-
-When running a multi-node demo cluster, use the `\demo ls` [shell command](#commands) to list the connection parameters for all nodes:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \demo ls
-~~~
-
-~~~
-node 1:
-  (console) http://127.0.0.1:50037
-  (sql)     postgres://root:admin@?host=%2Fvar%2Ffolders%2Fk1%2Fr048yqpd7_9337rgxm9vb_gw0000gn%2FT%2Fdemo294284060&port=26257
-  (sql/tcp) postgres://root:admin@127.0.0.1:50039?sslmode=require
-
-node 2:
-  (console) http://127.0.0.1:50040
-  (sql)     postgres://root:admin@?host=%2Fvar%2Ffolders%2Fk1%2Fr048yqpd7_9337rgxm9vb_gw0000gn%2FT%2Fdemo294284060&port=26258
-  (sql/tcp) postgres://root:admin@127.0.0.1:50042?sslmode=require
-
-node 3:
-  (console) http://127.0.0.1:50048
-  (sql)     postgres://root:admin@?host=%2Fvar%2Ffolders%2Fk1%2Fr048yqpd7_9337rgxm9vb_gw0000gn%2FT%2Fdemo294284060&port=26259
-  (sql/tcp) postgres://root:admin@127.0.0.1:50050?sslmode=require
-~~~
-
-### Commands
-
-- [General](#general)
-- [Demo-specific](#demo-specific)
-
-#### General
-
-{% include {{ page.version.version }}/sql/shell-commands.md %}
-
-#### Demo-specific
-
-`cockroach demo` offers the following additional shell commands. Note that these commands are **experimental** and their interface and output are subject to change.
-
-Command | Usage
---------|------
-`\demo ls` | List the demo nodes and their connection URLs.
-`\demo shutdown <node number>` | Shuts down a node in a multi-node demo cluster.<br><br>This command simulates stopping a node that can be restarted. [See an example](#shut-down-and-restart-nodes-in-a-multi-node-demo-cluster).
-`\demo restart <node number>` | Restarts a node in a multi-node demo cluster. [See an example](#shut-down-and-restart-nodes-in-a-multi-node-demo-cluster).
-`\demo decommission <node number>` | Decommissions a node in a multi-node demo cluster.<br><br>This command simulates [decommissioning a node](remove-nodes.html).
-`\demo recommission <node number>` | Recommissions a decommissioned node in a multi-node demo cluster.
-
-### Client-side options
-
-{% include {{ page.version.version }}/sql/shell-options.md %}
-
-### Help
-
-{% include {{ page.version.version }}/sql/shell-help.md %}
-
-### Shortcuts
-
-{% include {{ page.version.version }}/sql/shell-shortcuts.md %}
-
-## Diagnostics reporting
-
-By default, `cockroach demo` shares anonymous usage details with Cockroach Labs. To opt out, set the [`diagnostics.reporting.enabled`](diagnostics-reporting.html#after-cluster-initialization) [cluster setting](cluster-settings.html) to `false`. You can also opt out by setting the [`COCKROACH_SKIP_ENABLING_DIAGNOSTIC_REPORTING`](diagnostics-reporting.html#at-cluster-initialization) environment variable to `false` before running `cockroach demo`.
-
-## Examples
-
-In these examples, we demonstrate how to start a shell with `cockroach demo`. For more SQL shell features, see the [`cockroach sql` examples](cockroach-sql.html#examples).
-
-### Start a single-node demo cluster
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo
-~~~
-
-By default, `cockroach demo` loads the `movr` dataset in to the demo cluster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-You can query the pre-loaded data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name FROM users LIMIT 10;
-~~~
-
-~~~
-         name
------------------------
-  Tyler Dalton
-  Dillon Martin
-  Deborah Carson
-  David Stanton
-  Maria Weber
-  Brian Campbell
-  Carl Mcguire
-  Jennifer Sanders
-  Cindy Medina
-  Daniel Hernandez MD
-(10 rows)
-~~~
-
-You can also create and query new tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE drivers (
-    id UUID DEFAULT gen_random_uuid(),
-    city STRING NOT NULL,
-    name STRING,
-    dl STRING UNIQUE,
-    address STRING,
-    CONSTRAINT primary_key PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (city, name) VALUES ('new york', 'Catherine Nelson');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM drivers;
-~~~
-
-~~~
-                   id                  |   city   |       name       |  dl  | address
-+--------------------------------------+----------+------------------+------+---------+
-  df3dc272-b572-4ca4-88c8-e9974dbd381a | new york | Catherine Nelson | NULL | NULL
-(1 row)
-~~~
-
-### Start a multi-node demo cluster
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo --nodes=3
-~~~
-
-### Load a sample dataset into a demo cluster
-
-By default, `cockroach demo` loads the `movr` dataset in to the demo cluster. To pre-load any of the other [available datasets](#datasets) using `cockroach demo <dataset>`. For example, to load the `ycsb` dataset:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo ycsb
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name | table_name | type  | owner | estimated_row_count
---------------+------------+-------+-------+----------------------
-  public      | usertable  | table | demo  |                   0
-(1 row)
-~~~
-
-### Run load against a demo cluster
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo --with-load
-~~~
-
-This command starts a demo cluster with the `movr` database preloaded and then inserts rows into each table in the `movr` database. You can monitor the workload progress on the [DB Console](ui-overview-dashboard.html#sql-queries).
-
-When running a multi-node demo cluster, load is balanced across all nodes.
-
-### Execute SQL from the command-line against a demo cluster
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo \
---execute="CREATE TABLE drivers (
-    id UUID DEFAULT gen_random_uuid(),
-    city STRING NOT NULL,
-    name STRING,
-    dl STRING UNIQUE,
-    address STRING,
-    CONSTRAINT primary_key PRIMARY KEY (city ASC, id ASC)
-);" \
---execute="INSERT INTO drivers (city, name) VALUES ('new york', 'Catherine Nelson');" \
---execute="SELECT * FROM drivers;"
-~~~
-
-~~~
-CREATE TABLE
-INSERT 1
-                   id                  |   city   |       name       |  dl  | address
-+--------------------------------------+----------+------------------+------+---------+
-  df3dc272-b572-4ca4-88c8-e9974dbd381a | new york | Catherine Nelson | NULL | NULL
-(1 row)
-~~~
-
-### Connect an additional SQL client to the demo cluster
-
-In addition to the interactive SQL shell that opens when you run `cockroach demo`, you can use the [connection parameters](#connection-parameters) in the welcome text to connect additional SQL clients to the cluster.
-
-First, use `\demo ls` to list the connection parameters for each node in the demo cluster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \demo ls
-~~~
-
-~~~
-node 1:
-  (console) http://127.0.0.1:54880
-  (sql)     postgres://root:admin@?host=%2Fvar%2Ffolders%2Fk1%2Fr048yqpd7_9337rgxm9vb_gw0000gn%2FT%2Fdemo200406637&port=26257
-  (sql/tcp) postgres://root:admin@127.0.0.1:54882?sslmode=require
-
-node 2:
-  (console) http://127.0.0.1:54883
-  (sql)     postgres://root:admin@?host=%2Fvar%2Ffolders%2Fk1%2Fr048yqpd7_9337rgxm9vb_gw0000gn%2FT%2Fdemo200406637&port=26258
-  (sql/tcp) postgres://root:admin@127.0.0.1:54885?sslmode=require
-
-node 3:
-  (console) http://127.0.0.1:54891
-  (sql)     postgres://root:admin@?host=%2Fvar%2Ffolders%2Fk1%2Fr048yqpd7_9337rgxm9vb_gw0000gn%2FT%2Fdemo200406637&port=26259
-  (sql/tcp) postgres://root:admin@127.0.0.1:54893?sslmode=require
-~~~
-
-Then open a new terminal and run [`cockroach sql`](cockroach-sql.html) with the `--url` flag set to the `sql/tcp` connection URL of the node to which you want to connect:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --url='postgres://root:admin@127.0.0.1:54885?sslmode=require'
-~~~
-
-You can also use this URL to connect an application to the demo cluster.
-
-### Start a multi-region demo cluster with automatic geo-partitioning
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo --geo-partitioned-replicas
-~~~
-
-This command starts a 9-node demo cluster with the `movr` database preloaded, and [partitions](partitioning.html) and [zone constraints](configure-replication-zones.html) applied to the primary and secondary indexes. For more information, see the [Geo-Partitioned Replicas](topology-geo-partitioned-replicas.html) topology pattern.
-
-### Shut down and restart nodes in a multi-node demo cluster
-
-In a multi-node demo cluster, you can use `\demo` [shell commands](#commands) to shut down, restart, decommission, and recommission individual nodes.
-
-{% include {{ page.version.version }}/misc/experimental-warning.md %}
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo --nodes=3
-~~~
-
-You can shutdown the 3rd node and then restart it:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \demo shutdown 3
-~~~
-
-~~~
-node 3 has been shutdown
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \demo restart 3
-~~~
-
-~~~
-node 3 has been restarted
-~~~
-
-You can also decommission the 3rd node and then recommission it:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \demo decommission 3
-~~~
-
-~~~
-node 3 has been decommissioned
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \demo recommission 3
-~~~
-
-~~~
-node 3 has been recommissioned
-~~~
-
-### Try your own scenario
-
-In addition to using one of the [pre-loaded dataset](#datasets), you can create your own database (e.g., [`CREATE DATABASE <yourdb>;`](create-database.html)), or use the empty `defaultdb` database (e.g., [`SET DATABASE defaultdb;`](set-vars.html)) to test our your own scenario involving any CockroachDB SQL features you are interested in.
-
-## See also
-
-- [`cockroach sql`](cockroach-sql.html)
-- [`cockroach workload`](cockroach-workload.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [SQL Statements](sql-statements.html)
-- [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
-- [MovR: Vehicle-Sharing App](movr.html)
diff --git a/src/current/v20.2/cockroach-dump.md b/src/current/v20.2/cockroach-dump.md
deleted file mode 100644
index d386fdde339..00000000000
--- a/src/current/v20.2/cockroach-dump.md
+++ /dev/null
@@ -1,454 +0,0 @@
----
-title: cockroach dump
-summary: Learn how to dump schemas and data from a CockroachDB cluster.
-toc: true
-key: sql-dump.html
----
-
-{{site.data.alerts.callout_danger}}
-`cockroach dump` is no longer recommended and has been deprecated in v20.2. Instead, back up your data in a [full backup](take-full-and-incremental-backups.html), [export](export.html) your data in plain text format, or view table schema in plaintext with [`SHOW CREATE TABLE`](show-create.html).</li></ul>
-{{site.data.alerts.end}}
-
-The `cockroach dump` [command](cockroach-commands.html) outputs the SQL statements required to recreate tables, views, and sequences. This command can be used to back up or export each database in a cluster. The output should also be suitable for importing into other relational databases, with minimal adjustments.
-
-## Considerations
-
-When `cockroach dump` is executed:
-
-- Table, sequence, and view schemas and table data are dumped as they appeared at the time that the command is started. Any changes after the command starts will not be included in the dump.
-- Table and view schemas are dumped in the order in which they can successfully be recreated. This is true of sequences as well.
-- If the dump takes longer than the [`ttlseconds`](configure-replication-zones.html) replication setting for the table (25 hours by default), the dump may fail.
-- Reads, writes, and schema changes can happen while the dump is in progress, but will not affect the output of the dump.
-
-{{site.data.alerts.callout_info}}
-The user must have the `SELECT` privilege on the target table(s).
-{{site.data.alerts.end}}
-
-## Synopsis
-
-Dump the schemas and data of specific tables to stdout:
-
-~~~ shell
-$ cockroach dump <database> <table> <table...> <flags>
-~~~
-
-Dump just the data of specific tables to stdout:
-
-~~~ shell
-$ cockroach dump <database> <table> <table...> --dump-mode=data <other flags>
-~~~
-
-Dump just the schemas of specific tables to stdout:
-
-~~~ shell
-$ cockroach dump <database> <table> <table...> --dump-mode=schema <other flags>
-~~~
-
-Dump the schemas and data of all tables in a database to stdout:
-
-~~~ shell
-$ cockroach dump <database> <flags>
-~~~
-
-Dump just the schemas of all tables in a database to stdout:
-
-~~~ shell
-$ cockroach dump <database> --dump-mode=schema <other flags>
-~~~
-
-Dump just the data of all tables in a database to stdout:
-
-~~~ shell
-$ cockroach dump <database> --dump-mode=data <other flags>
-~~~
-
-<span class="version-tag">New in v20.2:</span> Dump all non-system databases:
-
-~~~ shell
-$ cockroach dump --dump-all
-~~~
-
-Dump to a file:
-
-~~~ shell
-$ cockroach dump <database> <table> <flags> > dump-file.sql
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach dump --help
-~~~
-
-## Flags
-
-The `dump` command supports the following [general-use](#general) and [logging](#logging) flags.
-
-### General
-
-Flag | Description
------|------------
-`--as-of` | Dump table schema and/or data as they appear at the specified [timestamp](timestamp.html). See this [example](#dump-table-data-as-of-a-specific-time) for a demonstration.<br><br>Note that historical data is available only within the garbage collection window, which is determined by the [`ttlseconds`](configure-replication-zones.html) replication setting for the table (25 hours by default). If this timestamp is earlier than that window, the dump will fail.<br><br>**Default:** Current time
-`--dump-all` | <span class="version-tag">New in v20.2:</span> [Dump all non-system databases](#dump-all-databases), their table schemas, and data.
-`--dump-mode` | Whether to dump table and view schemas, table data, or both.<br><br>To dump just table and view schemas, set this to `schema`. To dump just table data, set this to `data`. To dump both table and view schemas and table data, leave this flag out or set it to `both`.<br><br>Table and view schemas are dumped in the order in which they can successfully be recreated. For example, if a database includes a table, a second table with a foreign key dependency on the first, and a view that depends on the second table, the dump will list the schema for the first table, then the schema for the second table, and then the schema for the view.<br><br>**Default:** `both`
-`--echo-sql` | Reveal the SQL statements sent implicitly by the command-line utility.
-
-### Client connection
-
-{% include {{ page.version.version }}/sql/connection-parameters.md %}
-
-See [Client Connection Parameters](connection-parameters.html) for more details.
-
-{{site.data.alerts.callout_info}}
-The user specified with `--user` must have the `SELECT` privilege on the target tables.
-{{site.data.alerts.end}}
-
-### Logging
-
-By default, the `dump` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## Examples
-
-{{site.data.alerts.callout_info}}
-These examples use our sample `startrek` database, which you can add to a cluster via the [`cockroach gen`](cockroach-gen.html#generate-example-data) command. Also, the examples assume that the `maxroach` user has been [granted](grant.html) the `SELECT` privilege on all target tables.
-{{site.data.alerts.end}}
-
-### Dump a table's schema and data
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach dump startrek episodes --insecure --user=maxroach > backup.sql
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cat backup.sql
-~~~
-
-~~~
-CREATE TABLE episodes (
-    id INT NOT NULL,
-    season INT NULL,
-    num INT NULL,
-    title STRING NULL,
-    stardate DECIMAL NULL,
-    CONSTRAINT "primary" PRIMARY KEY (id),
-    FAMILY "primary" (id, season, num),
-    FAMILY fam_1_title (title),
-    FAMILY fam_2_stardate (stardate)
-);
-
-INSERT INTO episodes (id, season, num, title, stardate) VALUES
-    (1, 1, 1, 'The Man Trap', 1531.1),
-    (2, 1, 2, 'Charlie X', 1533.6),
-    (3, 1, 3, 'Where No Man Has Gone Before', 1312.4),
-    (4, 1, 4, 'The Naked Time', 1704.2),
-    (5, 1, 5, 'The Enemy Within', 1672.1),
-    (6, 1, 6, e'Mudd\'s Women', 1329.8),
-    (7, 1, 7, 'What Are Little Girls Made Of?', 2712.4),
-    (8, 1, 8, 'Miri', 2713.5),
-    (9, 1, 9, 'Dagger of the Mind', 2715.1),
-    (10, 1, 10, 'The Corbomite Maneuver', 1512.2),
-    ...
-~~~
-
-### Dump just a table's schema
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach dump startrek episodes --insecure --user=maxroach --dump-mode=schema > backup.sql
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cat backup.sql
-~~~
-
-~~~
-CREATE TABLE episodes (
-    id INT NOT NULL,
-    season INT NULL,
-    num INT NULL,
-    title STRING NULL,
-    stardate DECIMAL NULL,
-    CONSTRAINT "primary" PRIMARY KEY (id),
-    FAMILY "primary" (id, season, num),
-    FAMILY fam_1_title (title),
-    FAMILY fam_2_stardate (stardate)
-);
-~~~
-
-### Dump just a table's data
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach dump startrek episodes --insecure --user=maxroach --dump-mode=data > backup.sql
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cat backup.sql
-~~~
-
-~~~
-INSERT INTO episodes (id, season, num, title, stardate) VALUES
-    (1, 1, 1, 'The Man Trap', 1531.1),
-    (2, 1, 2, 'Charlie X', 1533.6),
-    (3, 1, 3, 'Where No Man Has Gone Before', 1312.4),
-    (4, 1, 4, 'The Naked Time', 1704.2),
-    (5, 1, 5, 'The Enemy Within', 1672.1),
-    (6, 1, 6, e'Mudd\'s Women', 1329.8),
-    (7, 1, 7, 'What Are Little Girls Made Of?', 2712.4),
-    (8, 1, 8, 'Miri', 2713.5),
-    (9, 1, 9, 'Dagger of the Mind', 2715.1),
-    (10, 1, 10, 'The Corbomite Maneuver', 1512.2),
-    ...
-~~~
-
-### Dump all tables in a database
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach dump startrek --insecure --user=maxroach > backup.sql
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cat backup.sql
-~~~
-
-~~~
-CREATE TABLE episodes (
-    id INT NOT NULL,
-    season INT NULL,
-    num INT NULL,
-    title STRING NULL,
-    stardate DECIMAL NULL,
-    CONSTRAINT "primary" PRIMARY KEY (id),
-    FAMILY "primary" (id, season, num),
-    FAMILY fam_1_title (title),
-    FAMILY fam_2_stardate (stardate)
-);
-
-CREATE TABLE quotes (
-    quote STRING NULL,
-    characters STRING NULL,
-    stardate DECIMAL NULL,
-    episode INT NULL,
-    INDEX quotes_episode_idx (episode),
-    FAMILY "primary" (quote, rowid),
-    FAMILY fam_1_characters (characters),
-    FAMILY fam_2_stardate (stardate),
-    FAMILY fam_3_episode (episode)
-);
-
-INSERT INTO episodes (id, season, num, title, stardate) VALUES
-    (1, 1, 1, 'The Man Trap', 1531.1),
-    (2, 1, 2, 'Charlie X', 1533.6),
-    (3, 1, 3, 'Where No Man Has Gone Before', 1312.4),
-    (4, 1, 4, 'The Naked Time', 1704.2),
-    (5, 1, 5, 'The Enemy Within', 1672.1),
-    (6, 1, 6, e'Mudd\'s Women', 1329.8),
-    (7, 1, 7, 'What Are Little Girls Made Of?', 2712.4),
-    (8, 1, 8, 'Miri', 2713.5),
-    (9, 1, 9, 'Dagger of the Mind', 2715.1),
-    (10, 1, 10, 'The Corbomite Maneuver', 1512.2),
-    ...
-
-INSERT INTO quotes (quote, characters, stardate, episode) VALUES
-    ('"... freedom ... is a worship word..." "It is our worship word too."', 'Cloud William and Kirk', NULL, 52),
-    ('"Beauty is transitory." "Beauty survives."', 'Spock and Kirk', NULL, 72),
-    ('"Can you imagine how life could be improved if we could do away with jealousy, greed, hate ..." "It can also be improved by eliminating love, tenderness, sentiment -- the other side of the coin"', 'Dr. Roger Corby and Kirk', 2712.4, 7),
-    ...
-~~~
-
-## Dump all databases
-
-<span class="version-tag">New in v20.2:</span> To dump all non-system databases, their table schemas, and data:
-
-~~~ shell
-$ cockroach dump --dump-all
-~~~
-
-~~~
-CREATE DATABASE IF NOT EXISTS movr;
-USE movr;
-
-CREATE TABLE promo_codes (
-	code VARCHAR NOT NULL,
-	description VARCHAR NULL,
-	creation_time TIMESTAMP NULL,
-	expiration_time TIMESTAMP NULL,
-	rules JSONB NULL,
-	CONSTRAINT "primary" PRIMARY KEY (code ASC),
-	FAMILY "primary" (code, description, creation_time, expiration_time, rules)
-);
-
-CREATE TABLE users (
-	...
-);
-
-CREATE TABLE vehicles (
-	...
-);
-
-CREATE TABLE rides (
-	...
-);
-
-CREATE TABLE user_promo_codes (
-	...
-);
-
-CREATE TABLE vehicle_location_histories (
-	...
-);
-
-INSERT INTO promo_codes (code, description, creation_time, expiration_time, rules) VALUES
-	('0_explain_theory_something', 'Live sing car maybe. Give safe edge chair discuss resource. Stop entire look support instead. Sister focus long agency like argue.', '2018-12-27 03:04:05+00:00', '2019-01-02 03:04:05+00:00', '{"type": "percent_discount", "value": "10%"}'),
-	('100_address_garden_certain', 'Hour industry himself student position international. Southern traditional rest name prepare. Tough sign little into class. Money general care guy.', '2018-12-27 03:04:05+00:00', '2019-01-13 03:04:05+00:00', '{"type": "percent_discount", "value": "10%"}'),
-
-  ...
-~~~
-
-### Dump fails (user does not have `SELECT` privilege)
-
-In this example, the `dump` command fails for a user that does not have the `SELECT` privilege on the `episodes` table.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach dump startrek episodes --insecure --user=leslieroach > backup.sql
-~~~
-
-~~~
-Error: pq: user leslieroach has no privileges on table episodes
-Failed running "dump"
-~~~
-
-### Restore a table from a backup file
-
-In this example, a user that has the `CREATE` privilege on the `startrek` database uses the [`cockroach sql`](cockroach-sql.html) command to recreate a table, based on a file created by the `dump` command.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cat backup.sql
-~~~
-
-~~~
-CREATE TABLE quotes (
-    quote STRING NULL,
-    characters STRING NULL,
-    stardate DECIMAL NULL,
-    episode INT NULL,
-    INDEX quotes_episode_idx (episode),
-    FAMILY "primary" (quote, rowid),
-    FAMILY fam_1_characters (characters),
-    FAMILY fam_2_stardate (stardate),
-    FAMILY fam_3_episode (episode)
-);
-
-INSERT INTO quotes (quote, characters, stardate, episode) VALUES
-    ('"... freedom ... is a worship word..." "It is our worship word too."', 'Cloud William and Kirk', NULL, 52),
-    ('"Beauty is transitory." "Beauty survives."', 'Spock and Kirk', NULL, 72),
-    ('"Can you imagine how life could be improved if we could do away with jealousy, greed, hate ..." "It can also be improved by eliminating love, tenderness, sentiment -- the other side of the coin"', 'Dr. Roger Corby and Kirk', 2712.4, 7),
-    ...
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --database=startrek --user=maxroach < backup.sql
-~~~
-
-~~~
-CREATE TABLE
-INSERT 100
-INSERT 100
-~~~
-
-### Dump table data as of a specific time
-
-In this example, we assume there were several inserts into a table both before and after `2017-03-07 19:55:00`.
-
-First, let's use the built-in SQL client to view the table at the current time:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --execute="SELECT * FROM db1.dump_test"
-~~~
-
-~~~
-+--------------------+------+
-|         id         | name |
-+--------------------+------+
-| 225594758537183233 | a    |
-| 225594758537248769 | b    |
-| 225594758537281537 | c    |
-| 225594758537314305 | d    |
-| 225594758537347073 | e    |
-| 225594758537379841 | f    |
-| 225594758537412609 | g    |
-| 225594758537445377 | h    |
-| 225594991654174721 | i    |
-| 225594991654240257 | j    |
-| 225594991654273025 | k    |
-| 225594991654305793 | l    |
-| 225594991654338561 | m    |
-| 225594991654371329 | n    |
-| 225594991654404097 | o    |
-| 225594991654436865 | p    |
-+--------------------+------+
-(16 rows)
-~~~
-
-Next, let's use a [time-travel query](select-clause.html#select-historical-data-time-travel) to view the contents of the table as of `2017-03-07 19:55:00`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --execute="SELECT * FROM db1.dump_test AS OF SYSTEM TIME '2017-03-07 19:55:00'"
-~~~
-
-~~~
-+--------------------+------+
-|         id         | name |
-+--------------------+------+
-| 225594758537183233 | a    |
-| 225594758537248769 | b    |
-| 225594758537281537 | c    |
-| 225594758537314305 | d    |
-| 225594758537347073 | e    |
-| 225594758537379841 | f    |
-| 225594758537412609 | g    |
-| 225594758537445377 | h    |
-+--------------------+------+
-(8 rows)
-~~~
-
-Finally, let's use `cockroach dump` with the `--as-of` flag set to dump the contents of the table as of `2017-03-07 19:55:00`.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach dump db1 dump_test --insecure --dump-mode=data --as-of='2017-03-07 19:55:00'
-~~~
-
-~~~
-INSERT INTO dump_test (id, name) VALUES
-    (225594758537183233, 'a'),
-    (225594758537248769, 'b'),
-    (225594758537281537, 'c'),
-    (225594758537314305, 'd'),
-    (225594758537347073, 'e'),
-    (225594758537379841, 'f'),
-    (225594758537412609, 'g'),
-    (225594758537445377, 'h');
-~~~
-
-As you can see, the results of the dump are identical to the earlier time-travel query.
-
-## See also
-
-- [Import Data](migration-overview.html)
-- [`IMPORT`](import.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/cockroach-gen.md b/src/current/v20.2/cockroach-gen.md
deleted file mode 100644
index 92558cb1248..00000000000
--- a/src/current/v20.2/cockroach-gen.md
+++ /dev/null
@@ -1,395 +0,0 @@
----
-title: cockroach gen
-summary: Use cockroach gen to generate command-line interface utlities, such as man pages, and example data.
-toc: true
-key: generate-cockroachdb-resources.html
----
-
-The `cockroach gen` [command](cockroach-commands.html) can generate command-line interface (CLI) utilities ([`man` pages](https://en.wikipedia.org/wiki/Man_page) and a `bash` autocompletion script), example SQL data suitable to populate test databases, and an HAProxy configuration file for load balancing a running cluster.
-
-## Subcommands
-
-Subcommand | Usage
------------|------
-`man` | Generate man pages for CockroachDB.
-`autocomplete` | Generate `bash` or `zsh` autocompletion script for CockroachDB.<br><br>**Default:** `bash`
-`example-data` | Generate example SQL datasets. You can also use the [`cockroach workload`](cockroach-workload.html) command to generate these sample datasets in a persistent cluster and the [`cockroach demo <dataset>`](cockroach-demo.html) command to generate these datasets in a temporary, in-memory cluster.
-`haproxy` | Generate an HAProxy config file for a running CockroachDB cluster. The node addresses included in the config are those advertised by the nodes. Make sure hostnames are resolvable and IP addresses are routable from HAProxy.<br><br> [Decommissioned nodes](remove-nodes.html) are excluded from the config file.
-
-## Synopsis
-
-Generate man pages:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen man
-~~~
-
-Generate bash autocompletion script:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen autocomplete
-~~~
-
-Generate example SQL data:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen example-data intro | cockroach sql
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen example-data startrek | cockroach sql
-~~~
-
-Generate an HAProxy config file for a running cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen haproxy
-~~~
-
-View help:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen --help
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen man --help
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen autocomplete --help
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen example-data --help
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen haproxy --help
-~~~
-
-## Flags
-
-The `gen` subcommands supports the following [general-use](#general), [logging](#logging), and [client connection](#client-connection) flags.
-
-### General
-
-#### `man`
-
-Flag | Description
------|-----------
-`--path` | The path where man pages will be generated.<br><br>**Default:** `man/man1` under the current directory
-
-#### `autocomplete`
-
-Flag | Description
------|-----------
-`--out` | The path where the autocomplete file will be generated.<br><br>**Default:** `cockroach.bash` in the current directory
-
-#### `example-data`
-
-No flags are supported. See the [Generate Example Data](#generate-example-data) example for guidance.
-
-#### `haproxy`
-
-Flag | Description
------|------------
-`--host` | The server host and port number to connect to. This can be the address of any node in the cluster. <br><br>**Env Variable:** `COCKROACH_HOST`<br>**Default:** `localhost:26257`
-`--port`<br>`-p` | The server port to connect to. Note: The port number can also be specified via `--host`. <br><br>**Env Variable:** `COCKROACH_PORT`<br>**Default:** `26257`
-`--insecure` | Use an insecure connection.<br><br>**Env Variable:** `COCKROACH_INSECURE`<br>**Default:** `false`
-`--certs-dir` | The path to the [certificate directory](cockroach-cert.html) containing the CA and client certificates and client key.<br><br>**Env Variable:** `COCKROACH_CERTS_DIR`<br>**Default:** `${HOME}/.cockroach-certs/`
-`--url` | A [connection URL](connection-parameters.html#connect-using-a-url) to use instead of the other arguments.<br><br>**Env Variable:** `COCKROACH_URL`<br>**Default:** no URL
-`--out` | The path where the `haproxy.cfg` file will be generated. If an `haproxy.cfg` file already exists in the directory, it will be overwritten.<br><br>**Default:** `haproxy.cfg` in the current directory
-`--locality` | If nodes were started with [locality](cockroach-start.html#locality) details, you can use the `--locality` flag here to filter the nodes included in the HAProxy config file, specifying the explicit locality tier(s) or a regular expression to match against. This is useful in cases where you want specific instances of HAProxy to route to specific nodes. See the [Generate an HAProxy configuration file](#generate-an-haproxy-config-file) example for more details.
-
-### Logging
-
-By default, the `gen` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-### Client Connection
-
-#### `haproxy`
-
-Flag | Description
------|------------
-`--cluster-name` | The cluster name to use to verify the cluster's identity. If the cluster has a cluster name, you must include this flag. For more information, see [`cockroach start`](cockroach-start.html#general).
-`--disable-cluster-name-verification` | Disables the cluster name check for this command. This flag must be paired with `--cluster-name`. For more information, see [`cockroach start`](cockroach-start.html#general).
-
-## Examples
-
-### Generate `man` pages
-
-Generate man pages:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen man
-~~~
-
-Move the man pages to the man directory:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ sudo mv man/man1/* /usr/share/man/man1
-~~~
-
-Access man pages:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ man cockroach
-~~~
-
-### Generate a `bash` autocompletion script
-
-Generate bash autocompletion script:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen autocomplete
-~~~
-
-Add the script to your `.bashrc` and `.bash_profle`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ printf "\n\n#cockroach bash autocomplete\nsource '<path to>cockroach.bash'" >> ~/.bashrc
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ printf "\n\n#cockroach bash autocomplete\nsource '<path to>cockroach.bash'" >> ~/.bash_profile
-~~~
-
-You can now use `tab` to autocomplete `cockroach` commands.
-
-### Generate example data
-
-{{site.data.alerts.callout_success}}
-You can also use the [`cockroach workload`](cockroach-workload.html) command to generate these sample datasets in a persistent cluster and the [`cockroach demo <dataset>`](cockroach-demo.html) command to generate these datasets in a temporary, in-memory cluster.
-{{site.data.alerts.end}}
-
-To test out CockroachDB, you can generate an example `startrek` database, which contains 2 tables, `episodes` and `quotes`.
-
-First, start up [a demo cluster](cockroach-demo.html):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo
-~~~
-
-Then, pipe the output from `cockroach gen` to [the URL to the demo cluster](cockroach-demo.html#connection-parameters):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen example-data startrek | cockroach sql --url='postgres://demo:pass@127.0.0.1:55531?sslmode=require'
-~~~
-
-~~~
-CREATE DATABASE
-SET
-DROP TABLE
-DROP TABLE
-CREATE TABLE
-INSERT 1
-...
-CREATE TABLE
-INSERT 1
-...
-~~~
-
-Open a [SQL shell](cockroach-sql.html) to view it:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --url='postgres://demo:pass@127.0.0.1:55531?sslmode=require'
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM startrek;
-~~~
-~~~
-  schema_name | table_name | type  | estimated_row_count
---------------+------------+-------+----------------------
-  public      | episodes   | table |                  79
-  public      | quotes     | table |                 200
-(2 rows)
-~~~
-
-You can also generate an example `intro` database, which contains 1 table, `mytable`, with a hidden message:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen example-data intro | cockroach sql --url='postgres://demo:pass@127.0.0.1:55531?sslmode=require'
-~~~
-
-~~~
-CREATE DATABASE
-SET
-DROP TABLE
-CREATE TABLE
-INSERT 1
-INSERT 1
-INSERT 1
-INSERT 1
-...
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Launch the built-in SQL client to view it:
-$ cockroach sql --url='postgres://demo:pass@127.0.0.1:55531?sslmode=require'
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM intro;
-~~~
-
-~~~
-  schema_name | table_name | type  | estimated_row_count
---------------+------------+-------+----------------------
-  public      | mytable    | table |                  42
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM intro.mytable WHERE (l % 2) = 0;
-~~~
-
-~~~
-  l  |                          v
------+-------------------------------------------------------
-   0 | !__aaawwmqmqmwwwaas,,_        .__aaawwwmqmqmwwaaa,,
-   2 | !"VT?!"""^~~^"""??T$Wmqaa,_auqmWBT?!"""^~~^^""??YV^
-   4 | !                    "?##mW##?"-
-   6 | !  C O N G R A T S  _am#Z??A#ma,           Y
-   8 | !                 _ummY"    "9#ma,       A
-  10 | !                vm#Z(        )Xmms    Y
-  12 | !              .j####mmm#####mm#m##6.
-  14 | !   W O W !    jmm###mm######m#mmm##6
-  16 | !             ]#me*Xm#m#mm##m#m##SX##c
-  18 | !             dm#||+*$##m#mm#m#Svvn##m
-  20 | !            :mmE=|+||S##m##m#1nvnnX##;     A
-  22 | !            :m#h+|+++=Xmm#m#1nvnnvdmm;     M
-  24 | ! Y           $#m>+|+|||##m#1nvnnnnmm#      A
-  26 | !  O          ]##z+|+|+|3#mEnnnnvnd##f      Z
-  28 | !   U  D       4##c|+|+|]m#kvnvnno##P       E
-  30 | !       I       4#ma+|++]mmhvnnvq##P`       !
-  32 | !        D I     ?$#q%+|dmmmvnnm##!
-  34 | !           T     -4##wu#mm#pw##7'
-  36 | !                   -?$##m####Y'
-  38 | !             !!       "Y##Y"-
-  40 | !
-(21 rows)
-~~~
-
-### Generate an HAProxy config file
-
-[HAProxy](http://www.haproxy.org/) is one of the most popular open-source TCP load balancers, and CockroachDB includes a built-in command for generating a configuration file that is preset to work with your running cluster.
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div><p></p>
-
-<div class="filter-content" markdown="1" data-scope="secure">
-To generate an HAProxy config file for an entire secure cluster, run the `cockroach gen haproxy` command, specifying the location of [certificate directory](cockroach-cert.html) and the address of any instance running a CockroachDB node:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen haproxy \
---certs-dir=<path to certs directory> \
---host=<address of any node in the cluster>
-~~~
-
-To limit the HAProxy config file to nodes matching specific ["localities"](cockroach-start.html#locality), use the `--localities` flag, specifying the explicit locality tier(s) or a regular expression to match against:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen haproxy \
---certs-dir=<path to certs directory> \
---host=<address of any node in the cluster>
---locality=region=us.*
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-To generate an HAProxy config file for an entire insecure cluster, run the `cockroach gen haproxy` command, specifying the address of any instance running a CockroachDB node:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen haproxy \
---insecure \
---host=<address of any node in the cluster>
-~~~
-
-To limit the HAProxy config file to nodes matching specific ["localities"](cockroach-start.html#locality), use the `--localities` flag, specifying the explicit locality tier(s) or a regular expression to match against:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen haproxy \
---insecure \
---host=<address of any node in the cluster>
---locality=region=us.*
-~~~
-</div>
-
-By default, the generated configuration file is called `haproxy.cfg` and looks as follows, with the `server` addresses pre-populated correctly:
-
-~~~
-global
-  maxconn 4096
-
-defaults
-    mode                tcp
-    # Timeout values should be configured for your specific use.
-    # See: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-timeout%20connect
-    timeout connect     10s
-    timeout client      1m
-    timeout server      1m
-    # TCP keep-alive on client side. Server already enables them.
-    option              clitcpka
-
-listen psql
-    bind :26257
-    mode tcp
-    balance roundrobin
-    option httpchk GET /health?ready=1
-    server cockroach1 <node1 address>:26257 check port 8080
-    server cockroach2 <node2 address>:26257 check port 8080
-    server cockroach3 <node3 address>:26257 check port 8080
-~~~
-
-The file is preset with the minimal [configurations](http://cbonte.github.io/haproxy-dconv/1.7/configuration.html) needed to work with your running cluster:
-
-Field | Description
-------|------------
-`timeout connect`<br>`timeout client`<br>`timeout server` | Timeout values that should be suitable for most deployments.
-`bind` | The port that HAProxy listens on. This is the port clients will connect to and thus needs to be allowed by your network configuration.<br><br>This tutorial assumes HAProxy is running on a separate machine from CockroachDB nodes. If you run HAProxy on the same machine as a node (not recommended), you'll need to change this port, as `26257` is likely already being used by the CockroachDB node.
-`balance` | The balancing algorithm. This is set to `roundrobin` to ensure that connections get rotated amongst nodes (connection 1 on node 1, connection 2 on node 2, etc.). Check the [HAProxy Configuration Manual](http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-balance) for details about this and other balancing algorithms.
-`option httpchk` | The HTTP endpoint that HAProxy uses to check node health. [`/health?ready=1`](monitoring-and-alerting.html#health-ready-1) ensures that HAProxy doesn't direct traffic to nodes that are live but not ready to receive requests.
-`server` | For each included node, this field specifies the address the node advertises to other nodes in the cluster, i.e., the addressed pass in the [`--advertise-addr` flag](cockroach-start.html#networking) on node startup. Make sure hostnames are resolvable and IP addresses are routable from HAProxy.
-
-{{site.data.alerts.callout_info}}
-For full details on these and other configuration settings, see the [HAProxy Configuration Manual](http://cbonte.github.io/haproxy-dconv/1.7/configuration.html).
-{{site.data.alerts.end}}
-
-## See also
-
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Deploy CockroachDB On-Premises](deploy-cockroachdb-on-premises.html) (using HAProxy for load balancing)
diff --git a/src/current/v20.2/cockroach-init.md b/src/current/v20.2/cockroach-init.md
deleted file mode 100644
index 4c7cb67970e..00000000000
--- a/src/current/v20.2/cockroach-init.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: cockroach init
-summary: Perform a one-time-only initialization of a CockroachDB cluster.
-toc: true
-key: initialize-a-cluster.html
----
-
-This page explains the `cockroach init` [command](cockroach-commands.html), which you use to perform a one-time initialization of a new multi-node cluster. For a full walk-through of the cluster startup and initialization process, see one of the [Manual Deployment](manual-deployment.html) tutorials.
-
-{{site.data.alerts.callout_info}}
-When starting a single-node cluster with [`cockroach start-single-node`](cockroach-start-single-node.html), you do not need to use the `cockroach init` command.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-Perform a one-time initialization of a cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach init <flags>
-~~~
-
-View help:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach init --help
-~~~
-
-## Flags
-
-The `cockroach init` command supports the following [client connection](#client-connection) and [logging](#logging) flags.
-
-{{site.data.alerts.callout_info}}
-`cockroach init` must target one of the nodes that was listed with [`--join`](cockroach-start.html#networking) when starting the cluster. Otherwise, the command will not initialize the cluster correctly.
-{{site.data.alerts.end}}
-
-### Client connection
-
-{% include {{ page.version.version }}/sql/connection-parameters.md %}
-`--cluster-name` | The cluster name to use to verify the cluster's identity. If the cluster has a cluster name, you must include this flag. For more information, see [`cockroach start`](cockroach-start.html#general).
-`--disable-cluster-name-verification` | Disables the cluster name check for this command. This flag must be paired with `--cluster-name`. For more information, see [`cockroach start`](cockroach-start.html#general).
-
-See [Client Connection Parameters](connection-parameters.html) for details.
-
-### Logging
-
-By default, the `init` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## Examples
-
-Usage of `cockroach init` assumes that nodes have already been started with [`cockroach start`](cockroach-start.html) and are waiting to be initialized as a new cluster. For a more detailed walk-through, see one of the [Manual Deployment](manual-deployment.html) tutorials.
-
-### Initialize a Cluster on a Node's Machine
-
-<section class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</section>
-
-<section class="filter-content" markdown="1" data-scope="secure">
-1. SSH to the machine where the node has been started. This must be a node that was listed with [`--join`](cockroach-start.html#networking) when starting the cluster.
-
-2. Make sure the `client.root.crt` and `client.root.key` files for the `root` user are on the machine.
-
-3. Run the `cockroach init` command with the `--certs-dir` flag set to the directory containing the `ca.crt` file and the files for the `root` user, and with the `--host` flag set to the address of the current node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --certs-dir=certs --host=<address of this node>
-    ~~~
-
-    At this point, all the nodes complete startup and print helpful details to the [standard output](cockroach-start.html#standard-output), such as the CockroachDB version, the URL for the DB Console, and the SQL URL for clients.
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-1. SSH to the machine where the node has been started. This must be a node that was listed with [`--join`](cockroach-start.html#networking) when starting the cluster.
-
-2. Run the `cockroach init` command with the `--host` flag set to the address of the current node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --insecure --host=<address of this node>
-    ~~~
-
-    At this point, all the nodes complete startup and print helpful details to the [standard output](cockroach-start.html#standard-output), such as the CockroachDB version, the URL for the DB Console, and the SQL URL for clients.
-</section>
-
-### Initialize a cluster from another machine
-
-<section class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</section>
-
-<section class="filter-content" markdown="1" data-scope="secure">
-1. [Install the `cockroach` binary](install-cockroachdb.html) on a machine separate from the node.
-
-2. Create a `certs` directory and copy the CA certificate and the client certificate and key for the `root` user into the directory.
-
-3. Run the `cockroach init` command with the `--certs-dir` flag set to the directory containing the `ca.crt` file and the files for the `root` user, and with the `--host` flag set to the address of the node.  This must be a node that was listed with [`--join`](cockroach-start.html#networking) when starting the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --certs-dir=certs --host=<address of any node on --join list>
-    ~~~
-
-    At this point, all the nodes complete startup and print helpful details to the [standard output](cockroach-start.html#standard-output), such as the CockroachDB version, the URL for the DB Console, and the SQL URL for clients.
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-1. [Install the `cockroach` binary](install-cockroachdb.html) on a machine separate from the node.
-
-2. Run the `cockroach init` command with the `--host` flag set to the address of the node. This must be a node that was listed with [`--join`](cockroach-start.html#networking) when starting the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --insecure --host=<address of any node on --join list>
-    ~~~
-
-    At this point, all the nodes complete startup and print helpful details to the [standard output](cockroach-start.html#standard-output), such as the CockroachDB version, the URL for the DB Console, and the SQL URL for clients.
-</section>
-
-## See also
-
-- [Manual Deployment](manual-deployment.html)
-- [Orchestrated Deployment](orchestration.html)
-- [Local Deployment](start-a-local-cluster.html)
-- [`cockroach start`](cockroach-start.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/cockroach-node.md b/src/current/v20.2/cockroach-node.md
deleted file mode 100644
index 2a40e65b605..00000000000
--- a/src/current/v20.2/cockroach-node.md
+++ /dev/null
@@ -1,324 +0,0 @@
----
-title: cockroach node
-summary: To view details for each node in the cluster, use the cockroach node command with the appropriate subcommands and flags.
-toc: true
-key: view-node-details.html
----
-
-To view details for each node in the cluster, use the `cockroach node` [command](cockroach-commands.html) with the appropriate subcommands and flags.
-
-The `cockroach node` command is also used in the process of decommissioning nodes for removal from the cluster. See [Decommission Nodes](remove-nodes.html) for more details.
-
-## Subcommands
-
-Subcommand | Usage
------------|------
-`ls` | List the ID of each node in the cluster, excluding those that have been decommissioned and are offline.
-`status` | View the status of one or all nodes, excluding nodes that have been decommissioned and taken offline. Depending on flags used, this can include details about range/replicas, disk usage, and decommissioning progress.
-`decommission` | Decommission nodes for removal from the cluster. See [Decommission Nodes](remove-nodes.html) for more details.
-`recommission` | Recommission nodes that have been decommissioned. See [Recommission Nodes](remove-nodes.html#recommission-nodes) for more details.
-`drain` | Drain nodes of SQL clients, [distributed SQL](architecture/sql-layer.html#distsql) queries, and range leases, and prevent ranges from rebalancing onto the node. This is normally done by sending `SIGTERM` during [node shutdown](cockroach-quit.html), but the `drain` subcommand provides operators an option to interactively monitor, and if necessary intervene in, the draining process.
-
-## Synopsis
-
-List the IDs of active and inactive nodes:
-
-~~~ shell
-$ cockroach node ls <flags>
-~~~
-
-Show status details for active and inactive nodes:
-
-~~~ shell
-$ cockroach node status <flags>
-~~~
-
-Show status and range/replica details for active and inactive nodes:
-
-~~~ shell
-$ cockroach node status --ranges <flags>
-~~~
-
-Show status and disk usage details for active and inactive nodes:
-
-~~~ shell
-$ cockroach node status --stats <flags>
-~~~
-
-Show status and decommissioning details for active and inactive nodes:
-
-~~~ shell
-$ cockroach node status --decommission <flags>
-~~~
-
-Show complete status details for active and inactive nodes:
-
-~~~ shell
-$ cockroach node status --all <flags>
-~~~
-
-Show status details for a specific node:
-
-~~~ shell
-$ cockroach node status <node ID> <flags>
-~~~
-
-Decommission nodes:
-
-~~~ shell
-$ cockroach node decommission <node IDs> <flags>
-~~~
-
-Recommission nodes:
-
-~~~ shell
-$ cockroach node recommission <node IDs> <flags>
-~~~
-
-Drain nodes:
-
-~~~ shell
-$ cockroach node drain <flags>
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach node --help
-~~~
-~~~ shell
-$ cockroach node <subcommand> --help
-~~~
-
-## Flags
-
-All `node` subcommands support the following [general-use](#general) and [logging](#logging) flags.
-
-### General
-
-Flag | Description
------|------------
-`--format` | How to display table rows printed to the standard output. Possible values: `tsv`, `csv`, `table`, `records`, `sql`, `html`.<br><br>**Default:** `tsv`
-
-The `node ls` subcommand also supports the following general flags:
-
-Flag | Description
------|------------
-`--timeout` | Set the duration of time that the subcommand is allowed to run before it returns an error and prints partial information. The timeout is specified with a suffix of `s` for seconds, `m` for minutes, and `h` for hours. If this flag is not set, the subcommand may hang.
-
-The `node status` subcommand also supports the following general flags:
-
-Flag | Description
------|------------
-`--all` | Show all node details.
-`--decommission` | Show node decommissioning details.
-`--ranges` | Show node details for ranges and replicas.
-`--stats` | Show node disk usage details.
-`--timeout` | Set the duration of time that the subcommand is allowed to run before it returns an error and prints partial information. The timeout is specified with a suffix of `s` for seconds, `m` for minutes, and `h` for hours. If this flag is not set, the subcommand may hang.
-
-The `node decommission` subcommand also supports the following general flags:
-
-Flag | Description
------|------------
-`--wait` | When to return to the client. Possible values: `all`, `none`.<br><br>If `all`, the command returns to the client only after all replicas on all specified nodes have been transferred to other nodes. If any specified nodes are offline, the command will not return to the client until those nodes are back online.<br><br>If `none`, the command does not wait for the decommissioning process to complete; it returns to the client after starting the decommissioning process on all specified nodes that are online. Any specified nodes that are offline will automatically be marked as decommissioning; if they come back online, the cluster will recognize this status and will not rebalance data to the nodes.<br><br>**Default:** `all`
-`--self` | Applies the operation to the node against which the command was run (e.g., via `--host`).
-
-The `node drain` subcommand also supports the following general flag:
-
-Flag | Description
------|------------
-`--drain-wait` | Amount of time to wait for the node to drain before returning to the client. <br><br>**Default:** `10m`
-
-The `node recommission` subcommand also supports the following general flag:
-
-Flag | Description
------|------------
-`--self` | Applies the operation to the node against which the command was run (e.g., via `--host`).
-
-### Client connection
-
-{% include {{ page.version.version }}/sql/connection-parameters.md %}
-
-The `node decommission`, `node recommission`, and `node drain` subcommands also support the following client connection flags:
-
-Flag | Description
------|------------
-`--cluster-name` | The cluster name to use to verify the cluster's identity. If the cluster has a cluster name, you must include this flag. For more information, see [`cockroach start`](cockroach-start.html#general).
-`--disable-cluster-name-verification` | Disables the cluster name check for this command. This flag must be paired with `--cluster-name`. For more information, see [`cockroach start`](cockroach-start.html#general).
-
-See [Client Connection Parameters](connection-parameters.html) for more details.
-
-### Logging
-
-By default, the `node` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## Response
-
-The `cockroach node` subcommands return the following fields for each node.
-
-### `node ls`
-
-Field | Description
-------|------------
-`id` | The ID of the node.
-
-### `node status`
-
-Field | Description
-------|------------
-`id` | The ID of the node.<br><br>**Required flag:** None
-`address` | The address of the node.<br><br>**Required flag:** None
-`build` | The version of CockroachDB running on the node. If the binary was built from source, this will be the SHA hash of the commit used.<br><br>**Required flag:** None
-`locality` | The [locality](cockroach-start.html#locality) information specified for the node.<br><br>**Required flag:** None
-`updated_at` | The date and time when the node last recorded the information displayed in this command's output. When healthy, a new status should be recorded every 10 seconds or so, but when unhealthy this command's stats may be much older.<br><br>**Required flag:** None
-`started_at` | The date and time when the node was started.<br><br>**Required flag:** None
-`replicas_leaders` | The number of range replicas on the node that are the Raft leader for their range. See `replicas_leaseholders` below for more details.<br><br>**Required flag:** `--ranges` or `--all`
-`replicas_leaseholders` | The number of range replicas on the node that are the leaseholder for their range. A "leaseholder" replica handles all read requests for a range and directs write requests to the range's Raft leader (usually the same replica as the leaseholder).<br><br>**Required flag:** `--ranges` or `--all`
-`ranges` | The number of ranges that have replicas on the node.<br><br>**Required flag:** `--ranges` or `--all`
-`ranges_unavailable` | The number of unavailable ranges that have replicas on the node.<br><br>**Required flag:** `--ranges` or `--all`
-`ranges_underreplicated` | The number of underreplicated ranges that have replicas on the node.<br><br>**Required flag:** `--ranges` or `--all`
-`live_bytes` | The amount of live data used by both applications and the CockroachDB system. This excludes historical and deleted data.<br><br>**Required flag:** `--stats` or `--all`
-`key_bytes` | The amount of live and non-live data from keys in the key-value storage layer. This does not include data used by the CockroachDB system.<br><br>**Required flag:** `--stats` or `--all`
-`value_bytes` | The amount of live and non-live data from values in the key-value storage layer. This does not include data used by the CockroachDB system.<br><br>**Required flag:** `--stats` or `--all`
-`intent_bytes` | The amount of non-live data associated with uncommitted (or recently-committed) transactions.<br><br>**Required flag:** `--stats` or `--all`
-`system_bytes` | The amount of data used just by the CockroachDB system.<br><br>**Required flag:** `--stats` or `--all`
-`is_available` | If `true`, the node is currently available.<br><br>**Required flag:** None
-`is_live` | If `true`, the node is currently live. <br><br>For unavailable clusters (with an unresponsive DB Console), running the `node status` command and monitoring the `is_live` field is the only way to identify the live nodes in the cluster. However, you need to run the `node status` command on a live node to identify the other live nodes in an unavailable cluster. Figuring out a live node to run the command is a trial-and-error process, so run the command against each node until you get one that responds. <br><br> See [Identify live nodes in an unavailable cluster](#identify-live-nodes-in-an-unavailable-cluster) for more details. <br><br>**Required flag:** None
-`gossiped_replicas` | The number of replicas on the node that are active members of a range. After the decommissioning process completes, this should be 0.<br><br>**Required flag:** `--decommission` or `--all`
-`is_decommissioning` | If `true`, the node's range replicas are being transferred to other nodes. This happens when a live node is marked for [decommissioning](remove-nodes.html).<br><br>**Required flag:** `--decommission` or `--all`
-`is_draining` | If `true`, the node is being drained of in-flight SQL connections, new SQL connections are rejected, and the [`/health?ready=1` monitoring endpoint](monitoring-and-alerting.html#health-ready-1) starts returning a `503 Service Unavailable` status. This happens when a live node is being [stopped](cockroach-quit.html).<br><br>**Required flag:** `--decommission` or `--all`
-
-### `node decommission`
-
-Field | Description
-------|------------
-`id` | The ID of the node.
-`is_live` | If `true`, the node is live.
-`replicas` | The number of replicas on the node that are active members of a range. After the decommissioning process completes, this should be 0.
-`is_decommissioning` | If `true`, the node's range replicas are being transferred to other nodes. This happens when a live node is marked for [decommissioning](remove-nodes.html).
-`is_draining` | If `true`, the node is being drained of in-flight SQL connections, new SQL connections are rejected, and the [`/health?ready=1` monitoring endpoint](monitoring-and-alerting.html#health-ready-1) starts returning a `503 Service Unavailable` status. This happens when a live node is being [stopped](cockroach-quit.html).
-
-### `node recommission`
-
-Field | Description
-------|------------
-`id` | The ID of the node.
-`is_live` | If `true`, the node is live.
-`replicas` | The number of replicas on the node that are active members of a range. After the decommissioning process completes, this should be 0.
-`is_decommissioning` | If `true`, the node's range replicas are being transferred to other nodes. This happens when a live node is marked for [decommissioning](remove-nodes.html).
-`is_draining` | If `true`, the node is being drained of in-flight SQL connections, new SQL connections are rejected, and the [`/health?ready=1` monitoring endpoint](monitoring-and-alerting.html#health-ready-1) starts returning a `503 Service Unavailable` status. This happens when a live node is being [stopped](cockroach-quit.html).
-
-## Examples
-
-### Setup
-
-To follow along with the examples, start [an insecure cluster](start-a-local-cluster.html), with [localities](cockroach-start.html#locality) defined.
-
-### List node IDs
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node ls --insecure
-~~~
-
-~~~
-  id
-+----+
-   1
-   2
-   3
-(3 rows)
-~~~
-
-### Show the status of a single node
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node status 1 --host=localhost:26257 --insecure
-~~~
-
-~~~
-  id |     address     |   sql_address   |                  build                  |            started_at            |           updated_at            |      locality       | is_available | is_live
-+----+-----------------+-----------------+-----------------------------------------+----------------------------------+---------------------------------+---------------------+--------------+---------+
-   1 | localhost:26257 | localhost:26257 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:54.308502+00:00 | 2019-10-01 20:05:43.85563+00:00 | region=us-east,az=1 | true         | true
-(1 row)
-~~~
-
-### Show the status of all nodes
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node status --host=localhost:26257 --insecure
-~~~
-
-~~~
-  id |     address     |   sql_address   |                  build                  |            started_at            |            updated_at            |        locality        | is_available | is_live
-+----+-----------------+-----------------+-----------------------------------------+----------------------------------+----------------------------------+------------------------+--------------+---------+
-   1 | localhost:26257 | localhost:26257 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:54.308502+00:00 | 2019-10-01 20:06:15.356886+00:00 | region=us-east,az=1    | true         | true
-   2 | localhost:26258 | localhost:26258 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:54.551761+00:00 | 2019-10-01 20:06:15.583967+00:00 | region=us-central,az=2 | true         | true
-   3 | localhost:26259 | localhost:26259 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:55.178577+00:00 | 2019-10-01 20:06:16.204549+00:00 | region=us-west,az=3    | true         | true
-(3 rows)
-~~~
-
-### Identify live nodes in an unavailable cluster
-
-The `is_live` and `is_available` fields are marked as `true` as long as a majority of the nodes are up, and a quorum can be reached:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach quit --host=localhost:26258 --insecure
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node status --host=localhost:26257 --insecure
-~~~
-
-~~~
-  id |     address     |   sql_address   |                  build                  |            started_at            |            updated_at            |        locality        | is_available | is_live
-+----+-----------------+-----------------+-----------------------------------------+----------------------------------+----------------------------------+------------------------+--------------+---------+
-   1 | localhost:26257 | localhost:26257 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:54.308502+00:00 | 2019-10-01 20:07:04.857339+00:00 | region=us-east,az=1    | true         | true
-   2 | localhost:26258 | localhost:26258 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:54.551761+00:00 | 2019-10-01 20:06:48.555863+00:00 | region=us-central,az=2 | false        | false
-   3 | localhost:26259 | localhost:26259 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:55.178577+00:00 | 2019-10-01 20:07:01.207697+00:00 | region=us-west,az=3    | true         | true
-(3 rows)
-~~~
-
-If a majority of nodes are down and a quorum cannot be reached, the `is_live` field is marked as `true` for the nodes that are up, but the `is_available` field is marked as `false` for all nodes:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach quit --host=localhost:26259 --insecure
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node status --host=localhost:26257 --insecure
-~~~
-
-~~~
-  id |     address     |   sql_address   |                  build                  |            started_at            |            updated_at            |        locality        | is_available | is_live
-+----+-----------------+-----------------+-----------------------------------------+----------------------------------+----------------------------------+------------------------+--------------+---------+
-   1 | localhost:26257 | localhost:26257 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:54.308502+00:00 | 2019-10-01 20:07:37.464249+00:00 | region=us-east,az=1    | false        | true
-   2 | localhost:26258 | localhost:26258 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:54.551761+00:00 | 2019-10-01 20:07:37.464259+00:00 | region=us-central,az=2 | false        | false
-   3 | localhost:26259 | localhost:26259 | v19.2.0-alpha.20190606-2479-gd98e0839dc | 2019-10-01 20:04:55.178577+00:00 | 2019-10-01 20:07:37.464265+00:00 | region=us-west,az=3    | false        | false
-(3 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-You need to run the `node status` command on a live node to identify the other live nodes in an unavailable cluster. Figuring out a live node to run the command is a trial-and-error process, so run the command against each node until you get one that responds.
-{{site.data.alerts.end}}
-
-### Decommission nodes
-
-See [Decommission Nodes](remove-nodes.html)
-
-### Recommission nodes
-
-See [Recommission Nodes](remove-nodes.html#recommission-nodes)
-
-## See also
-
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Decommission Nodes](remove-nodes.html)
diff --git a/src/current/v20.2/cockroach-nodelocal-upload.md b/src/current/v20.2/cockroach-nodelocal-upload.md
deleted file mode 100644
index 4a80df09779..00000000000
--- a/src/current/v20.2/cockroach-nodelocal-upload.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: cockroach nodelocal upload
-summary: The cockroach nodelocal upload command uploads a file to the external IO directory on a node's (the gateway node, by default) local file system.
-toc: true
----
-
- The `cockroach nodelocal upload` [command](cockroach-commands.html) uploads a file to the external IO directory on a node's (the gateway node, by default) local file system.
-
-This command takes in a source file to upload and a destination filename. It will then use a SQL connection to upload the file to the node's local file system, at `externalIODir/destination/filename`.
-
-{{site.data.alerts.callout_info}}
-The source file is only uploaded to one node, not all of the nodes.
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/misc/userfile.md %}
-
-## Required privileges
-
-Only members of the `admin` role can run `cockroach nodelocal upload`. By default, the `root` user belongs to the `admin` role.
-
-## Considerations
-
-The [`--external-io`](cockroach-start.html#general) flag on the node you're uploading to **cannot** be set to `disabled`.
-
-## Synopsis
-
-Upload a file:
-
-~~~ shell
-$ cockroach nodelocal upload <location/of/file> <destination/of/file> [flags]
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach nodelocal upload --help
-~~~
-
-## Flags
-
- Flag            | Description
------------------+-----------------------------------------------------
-`--certs-dir`    | The path to the [certificate directory](cockroach-cert.html) containing the CA and client certificates and client key.<br><br>**Env Variable:** `COCKROACH_CERTS_DIR`<br>**Default:** `${HOME}/.cockroach-certs/`
-`--echo-sql`     | Reveal the SQL statements sent implicitly by the command-line utility.
-`--host`         | The server host and port number to connect to. This can be the address of any node in the cluster. <br><br>**Env Variable:** `COCKROACH_HOST`<br>**Default:** `localhost:26257`
-`--insecure`     | Use an insecure connection.<br><br>**Env Variable:** `COCKROACH_INSECURE`<br>**Default:** `false`
-`--url`          | A [connection URL](connection-parameters.html#connect-using-a-url) to use instead of the other arguments.<br><br>**Env Variable:** `COCKROACH_URL`<br>**Default:** no URL
-`--user`<br>`-u` | The [SQL user](create-user.html) that will own the client session.<br><br>**Env Variable:** `COCKROACH_USER`<br>**Default:** `root`
-
-## Examples
-
-### Upload a file
-
-To upload a file to the default node (i.e., the gateway node):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach nodelocal upload ./grants.csv test/grants.csv --certs-dir=certs
-~~~
-
-~~~
-successfully uploaded to nodelocal://1/test/grants.csv
-~~~
-
-Then, you can use the file to [`IMPORT`](import.html) or [`IMPORT INTO`](import-into.html) data.
-
-### Upload a file to a specific node
-
-To upload a file to a specific node (e.g., node 2), use the `--host` flag:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach nodelocal upload ./grants.csv grants.csv --host=localhost:26259 --insecure
-~~~
-
-~~~
-successfully uploaded to nodelocal://2/grants.csv
-~~~
-
-Or, use the `--url` flag:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach nodelocal upload ./grants.csv grants.csv --url=postgresql://root@localhost:26258?sslmode=disable --insecure
-~~~
-
-~~~
-successfully uploaded to nodelocal://3/grants.csv
-~~~
-
-Then, you can use the file to [`IMPORT`](import.html) or [`IMPORT INTO`](import-into.html) data.
-
-## See also
-
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Import Data](migration-overview.html)
-- [`IMPORT`](import.html)
-- [`IMPORT INTO`](import-into.html)
diff --git a/src/current/v20.2/cockroach-quit.md b/src/current/v20.2/cockroach-quit.md
deleted file mode 100644
index 99c4b759bcf..00000000000
--- a/src/current/v20.2/cockroach-quit.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: cockroach quit
-summary: This page shows you how to use the cockroach quit command to temporarily stop a node that you plan to restart.
-toc: true
-key: stop-a-node.html
----
-
-{{site.data.alerts.callout_danger}}
-`cockroach quit` is deprecated. To stop a node, do one of the following:
-
-{% include {{ page.version.version }}/prod-deployment/node-shutdown.md %}
-{{site.data.alerts.end}}
-
-This page shows you how to use the `cockroach quit` [command](cockroach-commands.html) to temporarily stop a node that you plan to restart.
-
-You might do this, for example, during the process of [upgrading your cluster's version of CockroachDB](upgrade-cockroach-version.html) or to perform planned maintenance (e.g., upgrading system software).
-
-{{site.data.alerts.callout_info}}
-In other scenarios, such as when downsizing a cluster or reacting to hardware failures, it's best to remove nodes from your cluster entirely. For information about this, see [Decommission Nodes](remove-nodes.html).
-{{site.data.alerts.end}}
-
-## Overview
-
-### How it works
-
-When you stop a node, it performs the following steps:
-
-- Finishes in-flight requests. Note that this is a best effort that times out after the duration specified by the `server.shutdown.query_wait` [cluster setting](cluster-settings.html).
-- Gossips its draining state to the cluster, so that other nodes do not try to distribute query planning to the draining node. Note that this is a best effort that times out after the duration specified by the `server.shutdown.drain_wait` [cluster setting](cluster-settings.html), so other nodes may not receive the gossip info in time.
-
-If the node then stays offline for a certain amount of time (5 minutes by default), the cluster considers the node dead and starts to transfer its **range replicas** to other nodes as well.
-
-After that, if the node comes back online, its range replicas will determine whether or not they are still valid members of replica groups. If a range replica is still valid and any data in its range has changed, it will receive updates from another replica in the group. If a range replica is no longer valid, it will be removed from the node.
-
-Basic terms:
-
-- **Range**: CockroachDB stores all user data and almost all system data in a giant sorted map of key value pairs. This keyspace is divided into "ranges", contiguous chunks of the keyspace, so that every key can always be found in a single range.
-- **Range Replica:** CockroachDB replicates each range (3 times by default) and stores each replica on a different node.
-
-### Considerations
-
-{% include {{ page.version.version }}/faq/planned-maintenance.md %}
-
-## Synopsis
-
-Temporarily stop a node:
-
-~~~ shell
-$ cockroach quit <flags>
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach quit --help
-~~~
-
-## Flags
-
-The `quit` command supports the following [general-use](#general), [client connection](#client-connection), and [logging](#logging) flags.
-
-### General
-
-Flag | Description
------|------------
-`--drain-wait` | Amount of time to wait for the node to drain before stopping the node. See [`cockroach node drain`](cockroach-node.html) for more details.<br><br>**Default:** `10m`
-
-### Client connection
-
-{% include {{ page.version.version }}/sql/connection-parameters.md %}
-`--cluster-name` | The cluster name to use to verify the cluster's identity. If the cluster has a cluster name, you must include this flag. For more information, see [`cockroach start`](cockroach-start.html#general).
-`--disable-cluster-name-verification` | Disables the cluster name check for this command. This flag must be paired with `--cluster-name`. For more information, see [`cockroach start`](cockroach-start.html#general).
-
-See [Client Connection Parameters](connection-parameters.html) for more details.
-
-### Logging
-
-By default, the `quit` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## Examples
-
-### Stop a node from the machine where it's running
-
-1. SSH to the machine where the node is running.
-
-2. If the node is running in the background and you are using a process manager for automatic restarts, use the process manager to stop the `cockroach` process without restarting it.
-
-    If the node is running in the background and you are not using a process manager, send a kill signal to the `cockroach` process, for example:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ pkill cockroach
-    ~~~
-
-    If the node is running in the foreground, press `CTRL-C`.
-
-3. Verify that the `cockroach` process has stopped:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ps aux | grep cockroach
-    ~~~
-
-    Alternately, you can check the node's logs for the message `server drained and shutdown completed`.
-
-### Stop a node from another machine
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="secure">
-1. [Install the `cockroach` binary](install-cockroachdb.html) on a machine separate from the node.
-
-2. Create a `certs` directory and copy the CA certificate and the client certificate and key for the `root` user into the directory.
-
-3. Run the `cockroach quit` command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --certs-dir=certs --host=<address of node to stop>
-    ~~~
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-1. [Install the `cockroach` binary](install-cockroachdb.html) on a machine separate from the node.
-
-2. Run the `cockroach quit` command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=<address of node to stop>
-    ~~~
-</section>
-
-## See also
-
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Decommission Nodes](remove-nodes.html)
-- [Upgrade a Cluster's Version](upgrade-cockroach-version.html)
diff --git a/src/current/v20.2/cockroach-sql.md b/src/current/v20.2/cockroach-sql.md
deleted file mode 100644
index 664f06c0eec..00000000000
--- a/src/current/v20.2/cockroach-sql.md
+++ /dev/null
@@ -1,769 +0,0 @@
----
-title: cockroach sql
-summary: CockroachDB comes with a built-in client for executing SQL statements from an interactive shell or directly from the command line.
-toc: true
-key: use-the-built-in-sql-client.html
----
-
-CockroachDB comes with a built-in client for executing SQL statements from an interactive shell or directly from the command line. To use this client, run the `cockroach sql` [command](cockroach-commands.html) as described below.
-
-To exit the interactive shell, use `\q`, `quit`, `exit`, or `ctrl-d`.
-
-{{site.data.alerts.callout_success}}
-If you want to experiment with CockroachDB SQL but do not have a cluster already running, you can use the [`cockroach demo`](cockroach-demo.html) command to open a shell to a temporary, in-memory cluster.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-Start the interactive SQL shell:
-
-~~~ shell
-$ cockroach sql <flags>
-~~~
-
-Execute SQL from the command line:
-
-~~~ shell
-$ cockroach sql --execute="<sql statement>;<sql statement>" --execute="<sql-statement>" <flags>
-~~~
-~~~ shell
-$ echo "<sql statement>;<sql statement>" | cockroach sql <flags>
-~~~
-~~~ shell
-$ cockroach sql <flags> < file-containing-statements.sql
-~~~
-
-Exit the interactive SQL shell:
-
-~~~ sql
-> \q
-~~~
-
-~~~ sql
-> quit
-~~~
-
-~~~ sql
-> exit
-~~~
-
-~~~ shell
-ctrl-d
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach sql --help
-~~~
-
-## Flags
-
-The `sql` command supports the following types of flags:
-
-- [General Use](#general)
-- [Client Connection](#client-connection)
-- [Logging](#logging)
-
-### General
-
-- To start an interactive SQL shell, run `cockroach sql` with all appropriate connection flags or use just the [`--url` flag](#sql-flag-url), which includes [connection details](connection-parameters.html#connect-using-a-url).
-- To execute SQL statements from the command line, use the [`--execute` flag](#sql-flag-execute).
-
-Flag | Description
------|------------
-`--database`<br>`-d` | A database name to use as [current database](sql-name-resolution.html#current-database) in the newly created session.
-`--echo-sql` | Reveal the SQL statements sent implicitly by the command-line utility. For a demonstration, see the [example](#reveal-the-sql-statements-sent-implicitly-by-the-command-line-utility) below.<br><br>This can also be enabled within the interactive SQL shell via the `\set echo` [shell command](#commands).
-<a name="sql-flag-execute"></a> `--execute`<br />`-e` | Execute SQL statements directly from the command line, without opening a shell. This flag can be set multiple times, and each instance can contain one or more statements separated by semi-colons. If an error occurs in any statement, the command exits with a non-zero status code and further statements are not executed. The results of each statement are printed to the standard output (see `--format` for formatting options).<br><br>For a demonstration of this and other ways to execute SQL from the command line, see the [example](#execute-sql-statements-from-the-command-line) below.
-<a name="sql-flag-format"></a> `--format` | How to display table rows printed to the standard output. Possible values: `tsv`, `csv`, `table`, `raw`, `records`, `sql`, `html`.<br><br>**Default:** `table` for sessions that [output on a terminal](#session-and-output-types); `tsv` otherwise<br /><br />This flag corresponds to the `display_format` [client-side option](#client-side-options).
-`--safe-updates` | Disallow potentially unsafe SQL statements, including `DELETE` without a `WHERE` clause, `UPDATE` without a `WHERE` clause, and `ALTER TABLE ... DROP COLUMN`.<br><br>**Default:** `true` for [interactive sessions](#session-and-output-types); `false` otherwise<br /><br />Potentially unsafe SQL statements can also be allowed/disallowed for an entire session via the `sql_safe_updates` [session variable](set-vars.html).
-`--set` | Set a [client-side option](#client-side-options) before starting the SQL shell or executing SQL statements from the command line via `--execute`. This flag may be specified multiple times, once per option.<br><br>After starting the SQL shell, the `\set` and `unset` commands can be use to enable and disable client-side options as well.  
-`--watch` | Repeat the SQL statements specified with `--execute` or `-e` until a SQL error occurs or the process is terminated. `--watch` applies to all `--execute` or `-e` flags in use.<br />You must also specify an interval at which to repeat the statement, followed by a time unit. For example, to specify an interval of 5 seconds, use `5s`.<br /><br /> Note that this flag is intended for simple monitoring scenarios during development and testing. See the [example](#repeat-a-sql-statement) below.
-
-### Client connection
-
-{% include {{ page.version.version }}/sql/connection-parameters.md %}
-
-See [Client Connection Parameters](connection-parameters.html) for more details.
-
-### Logging
-
-By default, the `sql` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## Session and output types
-
-`cockroach sql` exhibits different behaviors depending on whether or not the session is interactive and/or whether or not the session outputs on a terminal.
-
-- A session is **interactive** when `cockroach sql` is invoked without the `--execute` flag and input is not redirected from a file. In such cases:
-    - The [`errexit` option](#sql-option-errexit) defaults to `false`.
-    - The [`check_syntax` option](#sql-option-check-syntax) defaults to `true` if supported by the CockroachDB server (this is checked when the shell starts up).
-    - **Ctrl+C** at the prompt will only terminate the shell if no other input was entered on the same line already.
-    - The shell will attempt to set the `safe_updates` [session variable](set-vars.html) to `true` on the server.
-- A session **outputs on a terminal** when output is not redirected to a file. In such cases:
-    - The [`--format` flag](#sql-flag-format) and its corresponding [`display_format` option](#sql-option-display-format) default to `table`. These default to `tsv` otherwise.
-    - The `show_times` option defaults to `true`.
-
-When a session is both interactive and outputs on a terminal, `cockroach sql` also activates the interactive prompt with a line editor that can be used to modify the current line of input. Also, command history becomes active.
-
-## SQL shell
-
-### Welcome message
-
-When the SQL shell connects (or reconnects) to a CockroachDB node, it prints a welcome text with some tips and CockroachDB version and cluster details:
-
-~~~ shell
-#
-# Welcome to the CockroachDB SQL shell.
-# All statements must be terminated by a semicolon.
-# To exit, type: \q.
-#
-# Server version: CockroachDB CCL {{page.release_info.version}} (x86_64-apple-darwin17.7.0, built 2019/09/13 00:07:19, go1.12.6) (same version as client)
-# Cluster ID: 7fb9f5b4-a801-4851-92e9-c0db292d03f1
-#
-# Enter \? for a brief introduction.
-#
->
-~~~
-
-The **Version** and **Cluster ID** details are particularly noteworthy:
-
-- When the client and server versions of CockroachDB are the same, the shell prints the `Server version` followed by `(same version as client)`.
-- When the client and server versions are different, the shell prints both the `Client version` and `Server version`. In this case, you may want to [plan an upgrade](upgrade-cockroach-version.html) of older client or server versions.
-- Since every CockroachDB cluster has a unique ID, you can use the `Cluster ID` field to verify that your client is always connecting to the correct cluster.
-
-### Commands
-
-{% include {{ page.version.version }}/sql/shell-commands.md %}
-
-### Client-side options
-
-{% include {{ page.version.version }}/sql/shell-options.md %}
-
-### Help
-
-{% include {{ page.version.version }}/sql/shell-help.md %}
-
-### Shortcuts
-
-{% include {{ page.version.version }}/sql/shell-shortcuts.md %}
-
-### Error messages and `SQLSTATE` codes
-
-When CockroachDB encounters a SQL error, it returns the following information to the client (whether `cockroach sql` or another [client application](developer-guide-overview.html)):
-
-1. An error message, prefixed with [the "Severity" field of the PostgreSQL wire protocol](https://www.postgresql.org/docs/current/protocol-error-fields.html). For example, `ERROR: insert on table "shipments" violates foreign key constraint "fk_customers"`.
-2. A [5-digit `SQLSTATE` error code](https://en.wikipedia.org/wiki/SQLSTATE) as defined by the SQL standard. For example, `SQLSTATE: 23503`.
-
-For example, the following query (taken from [this example of adding multiple foreign key constraints](foreign-key.html#add-multiple-foreign-key-constraints-to-a-single-column)) results in a SQL error, and returns both an error message and a `SQLSTATE` code as described above.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO shipments (carrier, status, customer_id) VALUES ('DHL', 'At facility', 2000);
-~~~
-
-~~~
-ERROR: insert on table "shipments" violates foreign key constraint "fk_customers"
-SQLSTATE: 23503
-DETAIL: Key (customer_id)=(2000) is not present in table "customers".
-~~~
-
-The [`SQLSTATE` code](https://en.wikipedia.org/wiki/SQLSTATE) in particular can be helpful in the following ways:
-
-- It is a standard SQL error code that you can look up in documentation and search for on the web. For any given error state, CockroachDB tries to produce the same `SQLSTATE` code as PostgreSQL.
-- If you are developing automation that uses the CockroachDB SQL shell, it is more reliable to check for `SQLSTATE` values than for error message strings, which are likely to change.
-
-## Examples
-
-### Start a SQL shell
-
-In these examples, we connect a SQL shell to a **secure cluster**.
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Using standard connection flags:
-$ cockroach sql \
---certs-dir=certs \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Using the --url flag:
-$ cockroach sql \
---url="postgresql://maxroach@12.345.67.89:26257/critterdb?sslcert=certs/client.maxroach.crt&sslkey=certs/client.maxroach.key&sslmode=verify-full&sslrootcert=certs/ca.crt"
-~~~
-
-In these examples, we connect a SQL shell to an **insecure cluster**.
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Using standard connection flags:
-$ cockroach sql --insecure \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Using the --url flag:
-$ cockroach sql \
---url="postgresql://maxroach@12.345.67.89:26257/critterdb?sslmode=disable"
-~~~
-
-### Execute SQL statement within the SQL shell
-
-This example assume that we have already started the SQL shell (see examples above).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE animals (id INT PRIMARY KEY DEFAULT unique_rowid(), name STRING);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO animals (name) VALUES ('bobcat'), ('🐢 '), ('barn owl');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM animals;
-~~~
-
-~~~
-+--------------------+----------+
-|         id         |   name   |
-+--------------------+----------+
-| 148899952591994881 | bobcat   |
-| 148899952592060417 | 🐢        |
-| 148899952592093185 | barn owl |
-+--------------------+----------+
-~~~
-
-### Execute SQL statements from the command line
-
-In these examples, we use the `--execute` flag to execute statements from the command line:
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Statements with a single --execute flag:
-$ cockroach sql --insecure \
---execute="CREATE TABLE roaches (name STRING, country STRING); INSERT INTO roaches VALUES ('American Cockroach', 'United States'), ('Brownbanded Cockroach', 'United States')" \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-~~~
-CREATE TABLE
-INSERT 2
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Statements with multiple --execute flags:
-$ cockroach sql --insecure \
---execute="CREATE TABLE roaches (name STRING, country STRING)" \
---execute="INSERT INTO roaches VALUES ('American Cockroach', 'United States'), ('Brownbanded Cockroach', 'United States')" \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-~~~
-CREATE TABLE
-INSERT 2
-~~~
-
-In this example, we use the `echo` command to execute statements from the command line:
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Statements with the echo command:
-$ echo "SHOW TABLES; SELECT * FROM roaches;" | cockroach sql --insecure --user=maxroach --host=12.345.67.89 --database=critterdb
-~~~
-
-~~~
-+----------+
-|  Table   |
-+----------+
-| roaches  |
-+----------+
-+-----------------------+---------------+
-|         name          |    country    |
-+-----------------------+---------------+
-| American Cockroach    | United States |
-| Brownbanded Cockroach | United States |
-+-----------------------+---------------+
-~~~
-
-### Control how table rows are printed
-
-In these examples, we show tables and special characters printed in various formats.
-
-When the standard output is a terminal, `--format` defaults to `table` and tables are printed with ASCII art and special characters are not escaped for easy human consumption:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---execute="SELECT '🐥' AS chick, '🐢' AS turtle" \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-~~~
-+-------+--------+
-| chick | turtle |
-+-------+--------+
-| 🐥    | 🐢     |
-+-------+--------+
-~~~
-
-However, you can explicitly set `--format` to another format, for example, `tsv` or `html`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---format=tsv \
---execute="SELECT '🐥' AS chick, '🐢' AS turtle" \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-~~~
-1 row
-chick	turtle
-🐥	🐢
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---format=html \
---execute="SELECT '🐥' AS chick, '🐢' AS turtle" \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-~~~
-<table>
-<thead><tr><th>chick</th><th>turtle</th></tr></head>
-<tbody>
-<tr><td>🐥</td><td>🐢</td></tr>
-</tbody>
-</table>
-~~~
-
-When piping output to another command or a file, `--format` defaults to `tsv`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---execute="SELECT '🐥' AS chick, '🐢' AS turtle" > out.txt \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cat out.txt
-~~~
-
-~~~
-1 row
-chick	turtle
-🐥	🐢
-~~~
-
-However, you can explicitly set `--format` to another format, for example, `table`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---format=table \
---execute="SELECT '🐥' AS chick, '🐢' AS turtle" > out.txt \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cat out.txt
-~~~
-
-~~~
-+-------+--------+
-| chick | turtle |
-+-------+--------+
-| 🐥    | 🐢     |
-+-------+--------+
-(1 row)
-~~~
-
-### Make the output of `SHOW` statements selectable
-
-To make it possible to select from the output of `SHOW` statements, set `--format` to `raw`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---format=raw \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE customers;
-~~~
-
-~~~
-# 2 columns
-# row 1
-## 14
-test.customers
-## 185
-CREATE TABLE customers (
-	id INT NOT NULL,
-	email STRING NULL,
-	CONSTRAINT "primary" PRIMARY KEY (id ASC),
-	UNIQUE INDEX customers_email_key (email ASC),
-	FAMILY "primary" (id, email)
-)
-# 1 row
-~~~
-
-When `--format` is not set to `raw`, you can use the `display_format` [SQL shell option](#client-side-options) to change the output format within the interactive session:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \set display_format raw
-~~~
-
-~~~
-# 2 columns
-# row 1
-## 14
-test.customers
-## 185
-CREATE TABLE customers (
-  id INT NOT NULL,
-  email STRING NULL,
-  CONSTRAINT "primary" PRIMARY KEY (id ASC),
-  UNIQUE INDEX customers_email_key (email ASC),
-  FAMILY "primary" (id, email)
-)
-# 1 row
-~~~
-
-### Execute SQL statements from a file
-
-In this example, we show and then execute the contents of a file containing SQL statements.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cat statements.sql
-~~~
-
-~~~
-CREATE TABLE roaches (name STRING, country STRING);
-INSERT INTO roaches VALUES ('American Cockroach', 'United States'), ('Brownbanded Cockroach', 'United States');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---user=maxroach \
---host=12.345.67.89 \
---database=critterdb \
-< statements.sql
-~~~
-
-~~~
-CREATE TABLE
-INSERT 2
-~~~
-
-### Run external commands from the SQL shell
-
-In this example, we use `\!` to look at the rows in a CSV file before creating a table and then using `\|` to insert those rows into the table.
-
-{{site.data.alerts.callout_info}}This example works only if the values in the CSV file are numbers. For values in other formats, use an online CSV-to-SQL converter or make your own import program.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \! cat test.csv
-~~~
-
-~~~
-12, 13, 14
-10, 20, 30
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE csv (x INT, y INT, z INT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \| IFS=","; while read a b c; do echo "insert into csv values ($a, $b, $c);"; done < test.csv;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM csv;
-~~~
-
-~~~
-+----+----+----+
-| x  | y  | z  |
-+----+----+----+
-| 12 | 13 | 14 |
-| 10 | 20 | 30 |
-+----+----+----+
-~~~
-
-In this example, we create a table and then use `\|` to programmatically insert values.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE for_loop (x INT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \| for ((i=0;i<10;++i)); do echo "INSERT INTO for_loop VALUES ($i);"; done
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM for_loop;
-~~~
-
-~~~
-+---+
-| x |
-+---+
-| 0 |
-| 1 |
-| 2 |
-| 3 |
-| 4 |
-| 5 |
-| 6 |
-| 7 |
-| 8 |
-| 9 |
-+---+
-~~~
-
-### Edit SQL statements in an external editor
-
-In applications that use [GNU Readline](https://tiswww.case.edu/php/chet/readline/rltop.html) (such as [bash](https://www.gnu.org/software/bash/)), you can edit a long line in your preferred editor by typing `Ctrl-x Ctrl-e`.  However, CockroachDB uses the BSD-licensed [libedit](https://thrysoee.dk/editline/), which does not include this functionality.
-
-If you would like to be able to edit the current line in an external editor by typing `C-x C-e` as in `bash`, do the following:
-
-1. Install the `vipe` program (from the [moreutils](https://joeyh.name/code/moreutils/) suite of tools).
-2. Edit your `~/.editrc` to add the following line, which takes advantage of the SQL client's ability to [run external commands](#run-external-commands-from-the-sql-shell):
-
-    {% include copy-clipboard.html %}
-    ~~~
-    cockroach:bind -s ^X^E '^A^K\\\| echo \"^Y\" | vipe\r'
-    ~~~
-
-This tells libedit to translate `C-x C-e` into the following commands:
-
-1. Move to the beginning of the current line.
-2. Cut the whole line.
-3. Paste the line into your editor via `vipe`.
-4. Pass the edited file back to the SQL client when `vipe` exits.
-
-{{site.data.alerts.callout_info}}
-Future versions of the SQL client may opt to use a different back-end for reading input, in which case please refer to this page for additional updates.
-{{site.data.alerts.end}}
-
-### Allow potentially unsafe SQL statements
-
-The `--safe-updates` flag defaults to `true`. This prevents SQL statements that may have broad, undesired side-effects. For example, by default, we cannot use `DELETE` without a `WHERE` clause to delete all rows from a table:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --execute="SELECT * FROM db1.t1"
-~~~
-
-~~~
-+----+------+
-| id | name |
-+----+------+
-|  1 | a    |
-|  2 | b    |
-|  3 | c    |
-|  4 | d    |
-|  5 | e    |
-|  6 | f    |
-|  7 | g    |
-|  8 | h    |
-|  9 | i    |
-| 10 | j    |
-+----+------+
-(10 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --execute="DELETE FROM db1.t1"
-~~~
-
-~~~
-Error: pq: rejected: DELETE without WHERE clause (sql_safe_updates = true)
-Failed running "sql"
-~~~
-
-However, to allow an "unsafe" statement, you can set `--safe-updates=false`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --safe-updates=false --execute="DELETE FROM db1.t1"
-~~~
-
-~~~
-DELETE 10
-~~~
-
-{{site.data.alerts.callout_info}}Potentially unsafe SQL statements can also be allowed/disallowed for an entire session via the <code>sql_safe_updates</code> <a href="set-vars.html">session variable</a>.{{site.data.alerts.end}}
-
-### Reveal the SQL statements sent implicitly by the command-line utility
-
-In this example, we use the `--execute` flag to execute statements from the command line and the `--echo-sql` flag to reveal SQL statements sent implicitly:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---execute="CREATE TABLE t1 (id INT PRIMARY KEY, name STRING)" \
---execute="INSERT INTO t1 VALUES (1, 'a'), (2, 'b'), (3, 'c')" \
---user=maxroach \
---host=12.345.67.89 \
---database=db1
---echo-sql
-~~~
-
-~~~
-# Server version: CockroachDB CCL f8f3c9317 (darwin amd64, built 2017/09/13 15:05:35, go1.8) (same version as client)
-# Cluster ID: 847a4ba5-c78a-465a-b1a0-59fae3aab520
-> SET sql_safe_updates = TRUE
-> CREATE TABLE t1 (id INT PRIMARY KEY, name STRING)
-CREATE TABLE
-> INSERT INTO t1 VALUES (1, 'a'), (2, 'b'), (3, 'c')
-INSERT 3
-~~~
-
-In this example, we start the interactive SQL shell and enable the `echo` shell option to reveal SQL statements sent implicitly:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---user=maxroach \
---host=12.345.67.89 \
---database=db1
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \set echo
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO db1.t1 VALUES (4, 'd'), (5, 'e'), (6, 'f');
-~~~
-
-~~~
-> INSERT INTO db1.t1 VALUES (4, 'd'), (5, 'e'), (6, 'f');
-INSERT 3
-
-Time: 2.426534ms
-
-> SHOW TRANSACTION STATUS
-> SHOW DATABASE
-~~~
-
-### Repeat a SQL statement
-
-Repeating SQL queries on a table can be useful for monitoring purposes. With the `--watch` flag, you can repeat the statements specified with a `--execute` or `-e` flag periodically, until a SQL error occurs or the process is terminated.
-
-For example, if you want to monitor the number of queries running on the current node, you can use `cockroach sql` with the `--watch` flag to query the node's `crdb_internal.node_statement_statistics` table for the query count:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure \
---execute="SELECT SUM(count) FROM crdb_internal.node_statement_statistics" \
---watch 1m
-~~~
-
-~~~
-  sum
-+-----+
-  926
-(1 row)
-  sum
-+------+
-  4227
-(1 row)
-^C
-~~~
-
-In this example, the statement is executed every minute. We let the process run for a couple minutes before terminating it with Ctrl+C.
-
-### Connect to a cluster listening for Unix domain socket connections
-
-To connect to a cluster that is running on the same machine as your client and is listening for [Unix domain socket](https://en.wikipedia.org/wiki/Unix_domain_socket) connections, [specify a Unix domain socket URI](connection-parameters.html#example-uri-for-a-unix-domain-socket) with the `--url` connection parameter.
-
-For example, suppose you start a single-node cluster with the following [`cockroach start-single-node`](cockroach-start-single-node.html) command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start-single-node --insecure --socket-dir=/tmp
-~~~
-
-~~~
-CockroachDB node starting at 2020-10-12 04:02:54.971369 +0000 UTC (took 1.3s)
-build:               CCL v20.2.0 @ 2020/10/06 17:15:06 (go1.13.14)
-webui:               http://Jesses-MBP-2:8080
-sql:                 postgresql://root@Jesses-MBP-2:26257?sslmode=disable
-RPC client flags:    ./cockroach <client cmd> --host=Jesses-MBP-2:26257 --insecure
-socket:              /tmp/.s.PGSQL.26257
-logs:                /Users/jesseseldess/Downloads/cockroach-v20.2.0-beta.4.darwin-10.9-amd64/cockroach-data/logs
-temp dir:            /Users/jesseseldess/Downloads/cockroach-v20.2.0-beta.4.darwin-10.9-amd64/cockroach-data/cockroach-temp805054895
-external I/O path:   /Users/jesseseldess/Downloads/cockroach-v20.2.0-beta.4.darwin-10.9-amd64/cockroach-data/extern
-store[0]:            path=/Users/jesseseldess/Downloads/cockroach-v20.2.0-beta.4.darwin-10.9-amd64/cockroach-data
-storage engine:      pebble
-status:              initialized new cluster
-clusterID:           455ad71d-21d4-424a-87ad-8097b6b5b99f
-nodeID:              1
-~~~
-
-To connect to this cluster with a socket:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --url='postgres://root@?host=/tmp&port=26257'
-~~~
-
-## See also
-
-- [Client Connection Parameters](connection-parameters.html)
-- [`cockroach demo`](cockroach-demo.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [SQL Statements](sql-statements.html)
-- [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
diff --git a/src/current/v20.2/cockroach-sqlfmt.md b/src/current/v20.2/cockroach-sqlfmt.md
deleted file mode 100644
index 005b7997c12..00000000000
--- a/src/current/v20.2/cockroach-sqlfmt.md
+++ /dev/null
@@ -1,158 +0,0 @@
----
-title: cockroach sqlfmt
-summary: Use cockroach sqlfmt to enhance the text layout of a SQL query.
-toc: true
-key: use-the-query-formatter.html
----
-
-The `cockroach sqlfmt`
-[command](cockroach-commands.html) changes the textual formatting of
-one or more SQL queries. It recognizes all SQL extensions supported by
-CockroachDB.
-
-A [web interface to this feature](https://sqlfum.pt/) is also available.
-
-{% include {{ page.version.version }}/misc/experimental-warning.md %}
-
-## Synopsis
-
-Use the query formatter interactively:
-
-~~~ shell
-$ cockroach sqlfmt <flags>
-<sql stmt>
-CTRL+D
-~~~
-
-Reformat a SQL query given on the command line:
-
-~~~ shell
-$ cockroach sqlfmt <flags> -e "<sql stmt>"
-~~~
-
-Reformat a SQL query already stored in a file:
-
-~~~ shell
-$ cat query.sql | cockroach sqlfmt <flags>
-~~~
-
-## Flags
-
-The `sqlfmt` command supports the following flags.
-
-Flag | Description | Default value
------|------|----
-`--execute`<br>`-e` | Reformat the given SQL query, without reading from standard input. | N/A
-`--print-width` | Desired column width of the output. | 80
-`--tab-width` | Number of spaces occupied by a tab character on the final display device. | 4
-`--use-spaces` | Always use space characters for formatting; avoid tab characters. | Use tabs.
-`--align` | Use vertical alignment during formatting. | Do not align vertically.
-`--no-simplify` | Avoid removing optional grouping parentheses during formatting. | Remove unnecessary grouping parentheses.
-
-## Examples
-
-### Reformat a query with constrained column width
-
-Using the interactive query formatter, output with the default column width (80 columns):
-
-1. Start the interactive query formatter:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sqlfmt
-    ~~~
-
-2. Press **Enter**.
-
-3. Run the query:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE animals (id INT PRIMARY KEY DEFAULT unique_rowid(), name STRING);
-    ~~~
-4. Press **CTRL+D**.
-
-    ~~~ sql
-    CREATE TABLE animals (
-            id INT PRIMARY KEY DEFAULT unique_rowid(),
-            name STRING
-    )
-    ~~~
-
-Using the command line, output with the column width set to `40`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sqlfmt --print-width 40 -e "CREATE TABLE animals (id INT PRIMARY KEY DEFAULT unique_rowid(), name STRING);"
-~~~
-
-~~~ sql
-CREATE TABLE animals (
-        id
-                INT
-                PRIMARY KEY
-                DEFAULT unique_rowid(),
-        name STRING
-)
-~~~
-
-### Reformat a query with vertical alignment
-
-Output with the default vertical alignment:
-
-~~~ shell
-$ cockroach sqlfmt -e "SELECT winner, round(length / (60 * 5)) AS counter FROM players WHERE build = $1 AND (hero = $2 OR region = $3);"
-~~~
-
-~~~ sql
-SELECT
-winner, round(length / (60 * 5)) AS counter
-FROM
-players
-WHERE
-build = $1 AND (hero = $2 OR region = $3)
-~~~
-
-Output with vertical alignment:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sqlfmt --align -e "SELECT winner, round(length / (60 * 5)) AS counter FROM players WHERE build = $1 AND (hero = $2 OR region = $3);"
-~~~
-
-~~~ sql
-SELECT winner, round(length / (60 * 5)) AS counter
-  FROM players
- WHERE build = $1 AND (hero = $2 OR region = $3);
-~~~
-
-### Reformat a query with simplification of parentheses
-
-Output with the default simplification of parentheses:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sqlfmt -e "SELECT (1 * 2) + 3, (1 + 2) * 3;"
-~~~
-
-~~~ sql
-SELECT 1 * 2 + 3, (1 + 2) * 3
-~~~
-
-Output with no simplification of parentheses:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sqlfmt --no-simplify -e "SELECT (1 * 2) + 3, (1 + 2) * 3;"
-~~~
-
-~~~ sql
-SELECT (1 * 2) + 3, (1 + 2) * 3
-~~~
-
-## See also
-
-- [Sequel Fumpt](https://sqlfum.pt/)
-- [`cockroach demo`](cockroach-demo.html)
-- [`cockroach sql`](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/cockroach-start-single-node.md b/src/current/v20.2/cockroach-start-single-node.md
deleted file mode 100644
index 7695dfa5665..00000000000
--- a/src/current/v20.2/cockroach-start-single-node.md
+++ /dev/null
@@ -1,436 +0,0 @@
----
-title: cockroach start-single-node
-summary: The cockroach start-single-node command starts a single-node cluster with replication disabled.
-toc: true
----
-
-This page explains the `cockroach start-single-node` [command](cockroach-commands.html), which you use to start a single-node cluster with replication disabled. A single-node cluster is all you need for quick SQL testing or app development.
-
-{{site.data.alerts.callout_success}}
-To run a multi-node cluster with replicated data for availability and consistency, use [`cockroach start`](cockroach-start.html) and [`cockroach init`](cockroach-init.html).
-{{site.data.alerts.end}}
-
-## Synopsis
-
-Start a single-node cluster:
-
-~~~ shell
-$ cockroach start-single-node <flags>
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach start-single-node --help
-~~~
-
-## Flags
-
-The `cockroach start-single-node` command supports the following [general-use](#general), [networking](#networking), [security](#security), and [logging](#logging) flags.
-
-Many flags have useful defaults that can be overridden by specifying the flags explicitly. If you specify flags explicitly, however, be sure to do so each time the node is restarted, as they will not be remembered.
-
-{{site.data.alerts.callout_info}}
-The `cockroach start-single-node` flags are identical to [`cockroach start`](cockroach-start.html#flags) flags. However, many of them are not relevant for single-node clusters but are provided for users who want to test concepts that appear in multi-node clusters. These flags are called out as such. In most cases, accepting most defaults is sufficient (see the [examples](#examples) below).
-{{site.data.alerts.end}}
-
-### General
-
-Flag | Description
------|-----------
-`--attrs` | **Not relevant for single-node clusters.** Arbitrary strings, separated by colons, specifying node capability, which might include specialized hardware or number of cores, for example:<br><br>`--attrs=ram:64gb`<br><br>These can be used to influence the location of data replicas. See [Configure Replication Zones](configure-replication-zones.html#replication-constraints) for full details.
-`--background` | Runs the node in the background. Control is returned to the shell only once the node is ready to accept requests, so this is recommended over appending `&` to the command. This flag is **not** available in Windows environments.<br><br>**Note:** `--background` is suitable for writing automated test suites or maintenance procedures that need a temporary server process running in the background. It is not intended to be used to start a long-running server, because it does not fully detach from the controlling terminal. Consider using a service manager or a tool like [daemon(8)](https://www.freebsd.org/cgi/man.cgi?query=daemon&sektion=8) instead.
-`--cache` | The total size for caches, shared evenly if there are multiple storage devices. This can be a percentage (notated as a decimal or with `%`) or any bytes-based unit, for example: <br><br>`--cache=.25`<br>`--cache=25%`<br>`--cache=1000000000 ----> 1000000000 bytes`<br>`--cache=1GB ----> 1000000000 bytes`<br>`--cache=1GiB ----> 1073741824 bytes` <br><br><strong>Note:</strong> If you use the `%` notation, you might need to escape the `%` sign, for instance, while configuring CockroachDB through `systemd` service files. For this reason, it's recommended to use the decimal notation instead.<br><br>**Default:** `128MiB`<br><br>The default cache size is reasonable for local development clusters. For production deployments, this should be increased to 25% or higher. Increasing the cache size will generally improve the node's read performance. See [Recommended Production Settings](recommended-production-settings.html#cache-and-sql-memory-size) for more details.
-`--external-io-dir` | The path of the external IO directory with which the local file access paths are prefixed while performing backup and restore operations using local node directories or NFS drives. If set to `disabled`, backups and restores using local node directories and NFS drives are disabled.<br><br>**Default:** `extern` subdirectory of the first configured [`store`](#store).<br><br>To set the `--external-io-dir` flag to the locations you want to use without needing to restart nodes, create symlinks to the desired locations from within the `extern` directory.
-`--listening-url-file` | The file to which the node's SQL connection URL will be written on successful startup, in addition to being printed to the [standard output](#standard-output).<br><br>This is particularly helpful in identifying the node's port when an unused port is assigned automatically (`--port=0`).
-`--locality` | **Not relevant for single-node clusters.** Arbitrary key-value pairs that describe the location of the node. Locality might include country, region, datacenter, rack, etc. For more details, see [Locality](cockroach-start.html#locality) below.
-`--max-disk-temp-storage` | The maximum on-disk storage capacity available to store temporary data for SQL queries that exceed the memory budget (see `--max-sql-memory`). This ensures that JOINs, sorts, and other memory-intensive SQL operations are able to spill intermediate results to disk. This can be a percentage (notated as a decimal or with `%`) or any bytes-based unit (e.g., `.25`, `25%`, `500GB`, `1TB`, `1TiB`).<br><br><strong>Note:</strong> If you use the `%` notation, you might need to escape the `%` sign, for instance, while configuring CockroachDB through `systemd` service files. For this reason, it's recommended to use the decimal notation instead. Also, if expressed as a percentage, this value is interpreted relative to the size of the first store. However, the temporary space usage is never counted towards any store usage; therefore, when setting this value, it's important to ensure that the size of this temporary storage plus the size of the first store doesn't exceed the capacity of the storage device.<br><br>The temporary files are located in the path specified by the `--temp-dir` flag, or in the subdirectory of the first store (see `--store`) by default.<br><br>**Default:** `32GiB`
-`--max-sql-memory` | The maximum in-memory storage capacity available to store temporary data for SQL queries, including prepared queries and intermediate data rows during query execution. This can be a percentage (notated as a decimal or with `%`) or any bytes-based unit, for example:<br><br>`--max-sql-memory=.25`<br>`--max-sql-memory=25%`<br>`--max-sql-memory=10000000000 ----> 1000000000 bytes`<br>`--max-sql-memory=1GB ----> 1000000000 bytes`<br>`--max-sql-memory=1GiB ----> 1073741824 bytes`<br><br>The temporary files are located in the path specified by the `--temp-dir` flag, or in the subdirectory of the first store (see `--store`) by default.<br><br><strong>Note:</strong> If you use the `%` notation, you might need to escape the `%` sign, for instance, while configuring CockroachDB through `systemd` service files. For this reason, it's recommended to use the decimal notation instead.<br><br>**Default:** `25%` <br><br>The default SQL memory size is suitable for production deployments but can be raised to increase the number of simultaneous client connections the node allows as well as the node's capacity for in-memory processing of rows when using `ORDER BY`, `GROUP BY`, `DISTINCT`, joins, and window functions. For local development clusters with memory-intensive workloads, reduce this value to, for example, `128MiB` to prevent out of memory errors.
-`--pid-file` | The file to which the node's process ID will be written on successful startup. When this flag is not set, the process ID is not written to file.
-`--store`<br>`-s` | The file path to a storage device and, optionally, store attributes and maximum size. When using multiple storage devices for a node, this flag must be specified separately for each device, for example: <br><br>`--store=/mnt/ssd01 --store=/mnt/ssd02` <br><br>For more details, see [Store](#store) below.
-`--temp-dir` | The path of the node's temporary store directory. On node start up, the location for the temporary files is printed to the standard output. <br><br>**Default:** Subdirectory of the first [store](#store)
-
-### Networking
-
-Flag | Description
------|-----------
-`--listen-addr` | The IP address/hostname and port to listen on for connections from clients. For IPv6, use the notation `[...]`, e.g., `[::1]` or `[fe80::f6f2:::]`.<br><br>**Default:** Listen on all IP addresses on port `26257`
-`--http-addr` | The IP address/hostname and port to listen on for DB Console HTTP requests. For IPv6, use the notation `[...]`, e.g., `[::1]:8080` or `[fe80::f6f2:::]:8080`.<br><br>**Default:** Listen on the address part of `--listen-addr` on port `8080`
-`--socket-dir` |  The directory path on which to listen for [Unix domain socket](https://en.wikipedia.org/wiki/Unix_domain_socket) connections from clients installed on the same Unix-based machine. For an example, see [Connect to a cluster listening for Unix domain socket connections](cockroach-sql.html#connect-to-a-cluster-listening-for-unix-domain-socket-connections).
-
-### Security
-
-Flag | Description
------|-----------
-`--certs-dir` | The path to the [certificate directory](cockroach-cert.html). The directory must contain valid certificates if running in secure mode.<br><br>**Default:** `${HOME}/.cockroach-certs/`
-`--insecure` | Run in insecure mode. If this flag is not set, the `--certs-dir` flag must point to valid certificates.<br><br><strong>Note the following risks:</strong> An insecure cluster is open to any client that can access any node's IP addresses; any user, even `root`, can log in without providing a password; any user, connecting as `root`, can read or write any data in your cluster; and there is no network encryption or authentication, and thus no confidentiality.<br><br>**Default:** `false`
-`--accept-sql-without-tls` | This experimental flag allows you to connect to the cluster using a SQL user's password without [validating the client's certificate](authentication.html#client-authentication). When connecting using the built-in SQL client, [use the `--insecure` flag with the `cockroach sql` command](cockroach-sql.html#client-connection).
-`--cert-principal-map` |  A comma-separated list of `cert-principal:db-principal` mappings used to map the certificate principals to IP addresses, DNS names, and SQL users. This allows the use of certificates generated by Certificate Authorities that place restrictions on the contents of the `commonName` field. For usage information, see [Create Security Certificates using Openssl](create-security-certificates-openssl.html#examples).
-`--enterprise-encryption` | This optional flag specifies the encryption options for one of the stores on the node. If multiple stores exist, the flag must be specified for each store. <br /><br /> This flag takes a number of options.  For a complete list of options, and usage instructions, see [Encryption at Rest](encryption.html). <br /><br /> Note that this is an [Enterprise feature](enterprise-licensing.html).   
-
-### Store
-
-The `--store` flag supports the following fields. Note that commas are used to separate fields, and so are forbidden in all field values.
-
-{{site.data.alerts.callout_info}}
-In-memory storage is not suitable for production deployments at this time.
-{{site.data.alerts.end}}
-
-Field | Description
-------|------------
-`type` | For in-memory storage, set this field to `mem`; otherwise, leave this field out. The `path` field must not be set when `type=mem`.
-`path` | The file path to the storage device. When not setting `attr` or `size`, the `path` field label can be left out: <br><br>`--store=/mnt/ssd01` <br><br>When either of those fields are set, however, the `path` field label must be used: <br><br>`--store=path=/mnt/ssd01,size=20GB` <br><br> **Default:** `cockroach-data`
-`attrs` | Arbitrary strings, separated by colons, specifying disk type or capability. These can be used to influence the location of data replicas. See [Configure Replication Zones](configure-replication-zones.html#replication-constraints) for full details.<br><br>In most cases, node-level `--locality` or `--attrs` are preferable to store-level attributes, but this field can be used to match capabilities for storage of individual databases or tables. For example, an OLTP database would probably want to allocate space for its tables only on solid state devices, whereas append-only time series might prefer cheaper spinning drives. Typical attributes include whether the store is flash (`ssd`) or spinny disk (`hdd`), as well as speeds and other specs, for example:<br><br> `--store=path=/mnt/hda1,attrs=hdd:7200rpm`
-`size` | The maximum size allocated to the node. When this size is reached, CockroachDB attempts to rebalance data to other nodes with available capacity. When there's no capacity elsewhere, this limit will be exceeded. Also, data may be written to the node faster than the cluster can rebalance it away; in this case, as long as capacity is available elsewhere, CockroachDB will gradually rebalance data down to the store limit.<br><br> The `size` can be specified either in a bytes-based unit or as a percentage of hard drive space (notated as a decimal or with `%`), for example: <br><br>`--store=path=/mnt/ssd01,size=10000000000 ----> 10000000000 bytes`<br>`--store=path=/mnt/ssd01,size=20GB ----> 20000000000 bytes`<br>`--store=path=/mnt/ssd01,size=20GiB ----> 21474836480 bytes`<br>`--store=path=/mnt/ssd01,size=0.02TiB ----> 21474836480 bytes`<br>`--store=path=/mnt/ssd01,size=20% ----> 20% of available space`<br>`--store=path=/mnt/ssd01,size=0.2 ----> 20% of available space`<br>`--store=path=/mnt/ssd01,size=.2 ----> 20% of available space`<br><br>**Default:** 100%<br><br>For an in-memory store, the `size` field is required and must be set to the true maximum bytes or percentage of available memory, for example:<br><br>`--store=type=mem,size=20GB`<br>`--store=type=mem,size=90%`<br><br><strong>Note:</strong> If you use the `%` notation, you might need to escape the `%` sign, for instance, while configuring CockroachDB through `systemd` service files. For this reason, it's recommended to use the decimal notation instead.
-
-### Logging
-
-By default, `cockroach start-single-node` writes all messages to log files, and prints nothing to `stderr`. However, you can control the process's [logging](debug-and-error-logs.html) behavior with the following flags:
-
-{% include {{ page.version.version }}/misc/logging-flags.md %}
-
-#### Defaults
-
-`cockroach start-single-node` uses the equivalent values for these logging flags by default:
-
-- `--log-dir=<first store dir>/logs`
-- `--logtostderr=NONE`
-
-This means, by default, CockroachDB writes all messages to log files, and never prints to `stderr`.
-
-## Standard output
-
-When you run `cockroach start-single-node`, some helpful details are printed to the standard output:
-
-~~~ shell
-CockroachDB node starting at {{ now | date: "%Y-%m-%d %H:%M:%S.%6 +0000 UTC" }}
-build:               CCL {{page.release_info.version}} @ {{page.release_info.build_time}} (go1.12.6)
-webui:               http://localhost:8080
-sql:                 postgresql://root@localhost:26257?sslmode=disable
-RPC client flags:    cockroach <client cmd> --host=localhost:26257 --insecure
-logs:                /Users/<username>/node1/logs
-temp dir:            /Users/<username>/node1/cockroach-temp242232154
-external I/O path:   /Users/<username>/node1/extern
-store[0]:            path=/Users/<username>/node1
-status:              initialized new cluster
-clusterID:           8a681a16-9623-4fc1-a537-77e9255daafd
-nodeID:              1
-~~~
-
-{{site.data.alerts.callout_success}}
-These details are also written to the `INFO` log in the `/logs` directory. You can retrieve them with a command like `grep 'node starting' node1/logs/cockroach.log -A 11`.
-{{site.data.alerts.end}}
-
-Field | Description
-------|------------
-`build` | The version of CockroachDB you are running.
-`webui` | The URL for accessing the DB Console.
-`sql` | The connection URL for your client.
-`RPC client flags` | The flags to use when connecting to the node via [`cockroach` client commands](cockroach-commands.html).
-`logs` | The directory containing debug log data.
-`temp dir` | The temporary store directory of the node.
-`external I/O path` | The external IO directory with which the local file access paths are prefixed while performing [backup](backup.html) and [restore](restore.html) operations using local node directories or NFS drives.
-`attrs` | If node-level attributes were specified in the `--attrs` flag, they are listed in this field. These details are potentially useful for [configuring replication zones](configure-replication-zones.html).
-`locality` | If values describing the locality of the node were specified in the `--locality` field, they are listed in this field. These details are potentially useful for [configuring replication zones](configure-replication-zones.html).
-`store[n]` | The directory containing store data, where `[n]` is the index of the store, e.g., `store[0]` for the first store, `store[1]` for the second store.<br><br>If store-level attributes were specified in the `attrs` field of the [`--store`](#store) flag, they are listed in this field as well. These details are potentially useful for [configuring replication zones](configure-replication-zones.html).
-`status` | Whether the node is the first in the cluster (`initialized new cluster`), joined an existing cluster for the first time (`initialized new node, joined pre-existing cluster`), or rejoined an existing cluster (`restarted pre-existing node`).
-`clusterID` | The ID of the cluster.<br><br>When trying to join a node to an existing cluster, if this ID is different than the ID of the existing cluster, the node has started a new cluster. This may be due to conflicting information in the node's data directory. For additional guidance, see the [troubleshooting](common-errors.html#node-belongs-to-cluster-cluster-id-but-is-attempting-to-connect-to-a-gossip-network-for-cluster-another-cluster-id) docs.
-`nodeID` | The ID of the node.
-
-## Examples
-
-### Start a single-node cluster
-
-<section class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</section>
-
-<section class="filter-content" markdown="1" data-scope="secure">
-1. Create two directories for certificates:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs my-safe-directory
-    ~~~
-
-    Directory | Description
-    ----------|------------
-    `certs` | You'll generate your CA certificate and all node and client certificates and keys in this directory.
-    `my-safe-directory` | You'll generate your CA key in this directory and then reference the key when generating node and client certificates.
-
-2. Create the CA (Certificate Authority) certificate and key pair:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-ca \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-3. Create the certificate and key pair for the node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    localhost \
-    $(hostname) \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-4. Create a client certificate and key pair for the `root` user:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-client \
-    root \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-5. Start the single-node cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start-single-node \
-    --certs-dir=certs \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --background
-    ~~~
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-<p></p>
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start-single-node \
---insecure \
---listen-addr=localhost:26257 \
---http-addr=localhost:8080 \
---background
-~~~
-</section>
-
-### Scale to multiple nodes
-
-Scaling a cluster started with `cockroach start-single-node` involves restarting the first node with the `cockroach start` command instead, and then adding new nodes with that command as well, all using a `--join` flag that forms them into a single multi-node cluster. Since replication is disabled in clusters started with `start-single-node`, you also need to enable replication to get CockroachDB's availability and consistency guarantees.
-
-<section class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</section>
-
-<section class="filter-content" markdown="1" data-scope="secure">
-1. Stop the single-node cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit \
-    --certs-dir=certs \
-    --host=localhost:26257
-    ~~~
-
-2. Restart the node with the [`cockroach start`](cockroach-start.html) command:  
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    The new flag to note is `--join`, which specifies the addresses and ports of the nodes that will initially comprise your cluster. You'll use this exact `--join` flag when starting other nodes as well.
-
-    {% include {{ page.version.version }}/prod-deployment/join-flag-single-region.md %}
-
-3. Add two more nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=node2 \
-    --listen-addr=localhost:26258 \
-    --http-addr=localhost:8081 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=node3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    These commands are the same as before but with unique `--store`, `--listen-addr`, and `--http-addr` flags, since this all nodes are running on the same machine. Also, since all nodes use the same hostname (`localhost`), you can use the first node's certificate. Note that this is different than running a production cluster, where you would need to generate a certificate and key for each node, issued to all common names and IP addresses you might use to refer to the node as well as to any load balancer instances.
-
-4. Open the [built-in SQL shell](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs --host=localhost:26257
-    ~~~
-
-5. Update preconfigured [replication zones](configure-replication-zones.html) to replicate user data 3 times and import internal data 5 times:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE default CONFIGURE ZONE USING num_replicas = 3;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE system CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER database system CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE liveness CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE meta CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE system.public.jobs CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE system.public.replication_constraint_stats CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE system.public.replication_stats CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-1. Stop the single-node cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit \
-    --insecure \
-    --host=localhost:26257
-    ~~~
-
-2. Restart the node with the [`cockroach start`](cockroach-start.html) command:  
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    The new flag to note is `--join`, which specifies the addresses and ports of the nodes that will comprise your cluster. You'll use this exact `--join` flag when starting other nodes as well.
-
-3. Add two more nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=node2 \
-    --listen-addr=localhost:26258 \
-    --http-addr=localhost:8081 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=node3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    These commands are the same as before but with unique `--store`, `--listen-addr`, and `--http-addr` flags, since this all nodes are running on the same machine.
-
-4. Open the [built-in SQL shell](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=localhost:26257
-    ~~~
-
-5. Update preconfigured [replication zones](configure-replication-zones.html) to replicate user data 3 times and import internal data 5 times:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE default CONFIGURE ZONE USING num_replicas = 3;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE system CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER database system CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE liveness CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE meta CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE system.public.jobs CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE system.public.replication_constraint_stats CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE system.public.replication_stats CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-</section>
-
-## See also
-
-- Running a local multi-node cluster:
-    - [From Binary](start-a-local-cluster.html)  
-    - [In Kubernetes](orchestrate-a-local-cluster-with-kubernetes.html)
-    - [In Docker](start-a-local-cluster-in-docker-mac.html)
-- Running a distributed multi-node cluster:
-    - [From Binary](manual-deployment.html)
-    - [In Kubernetes](orchestrate-cockroachdb-with-kubernetes.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/cockroach-start.md b/src/current/v20.2/cockroach-start.md
deleted file mode 100644
index e21b55c9ef5..00000000000
--- a/src/current/v20.2/cockroach-start.md
+++ /dev/null
@@ -1,514 +0,0 @@
----
-title: cockroach start
-summary: Start a new multi-node cluster or add nodes to an existing multi-node cluster.
-toc: true
-key: start-a-node.html
----
-
-This page explains the `cockroach start` [command](cockroach-commands.html), which you use to start a new multi-node cluster or add nodes to an existing cluster.
-
-{{site.data.alerts.callout_success}}
-If you need a simple single-node backend for app development, use [`cockroach start-single-node`](cockroach-start-single-node.html) instead. For quick SQL testing, consider using [`cockroach demo`](cockroach-demo.html) to start a temporary, in-memory cluster with immediate access to an interactive SQL shell.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Node-level settings are defined by [flags](#flags) passed to the `cockroach start` command and cannot be changed without stopping and restarting the node. In contrast, some cluster-wide settings are defined via SQL statements and can be updated anytime after a cluster has been started. For more details, see [Cluster Settings](cluster-settings.html).
-{{site.data.alerts.end}}
-
-## Synopsis
-
-Start a node to be part of a new multi-node cluster:
-
-~~~ shell
-$ cockroach start <flags, including --join>
-~~~
-
-Initialize a new multi-node cluster:
-
-~~~ shell
-$ cockroach init <flags>
-~~~
-
-Add a node to an existing cluster:
-
-~~~ shell
-$ cockroach start <flags, including --join>
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach start --help
-~~~
-
-## Flags
-
-The `cockroach start` command supports the following [general-use](#general), [networking](#networking), [security](#security), and [logging](#logging) flags.
-
-Many flags have useful defaults that can be overridden by specifying the flags explicitly. If you specify flags explicitly, however, be sure to do so each time the node is restarted, as they will not be remembered. The one exception is the `--join` flag, which is stored in a node's data directory. We still recommend specifying the `--join` flag every time, as this will allow nodes to rejoin the cluster even if their data directory was destroyed.
-
-### General
-
-Flag | Description
------|-----------
-`--attrs` | Arbitrary strings, separated by colons, specifying node capability, which might include specialized hardware or number of cores, for example:<br><br>`--attrs=ram:64gb`<br><br>These can be used to influence the location of data replicas. See [Configure Replication Zones](configure-replication-zones.html#replication-constraints) for full details.
-`--background` | Runs the node in the background. Control is returned to the shell only once the node is ready to accept requests, so this is recommended over appending `&` to the command. This flag is **not** available in Windows environments.<br><br>**Note:** `--background` is suitable for writing automated test suites or maintenance procedures that need a temporary server process running in the background. It is not intended to be used to start a long-running server, because it does not fully detach from the controlling terminal.  Consider using a service manager or a tool like [daemon(8)](https://www.freebsd.org/cgi/man.cgi?query=daemon&sektion=8) instead.
-`--cache` | The total size for caches, shared evenly if there are multiple storage devices. This can be a percentage (notated as a decimal or with `%`) or any bytes-based unit, for example: <br><br>`--cache=.25`<br>`--cache=25%`<br>`--cache=1000000000 ----> 1000000000 bytes`<br>`--cache=1GB ----> 1000000000 bytes`<br>`--cache=1GiB ----> 1073741824 bytes` <br><br><strong>Note:</strong> If you use the `%` notation, you might need to escape the `%` sign, for instance, while configuring CockroachDB through `systemd` service files. For this reason, it's recommended to use the decimal notation instead.<br><br>**Default:** `128MiB`<br><br>The default cache size is reasonable for local development clusters. For production deployments, this should be increased to 25% or higher. Increasing the cache size will generally improve the node's read performance. See [Recommended Production Settings](recommended-production-settings.html#cache-and-sql-memory-size) for more details.
-`--clock-device` | Enable CockroachDB to use a [PTP hardware clock](https://www.kernel.org/doc/html/latest/driver-api/ptp.html) when querying the current time. The value is a string that specifies the clock device to use. For example: `--clock-device=/dev/ptp0`<br><br>**Note:** This is supported on Linux only and may be needed in cases where the host clock is unreliable or prone to large jumps (e.g., when using vMotion).
-`--cluster-name` | A string that specifies a cluster name. This is used together with `--join` to ensure that all newly created nodes join the intended cluster when you are running multiple clusters.<br><br>**Note:** If this is set, [`cockroach init`](cockroach-init.html), [`cockroach node decommission`](cockroach-node.html), [`cockroach node recommission`](cockroach-node.html), and the `cockroach debug` commands must specify either `--cluster-name` or `--disable-cluster-name-verification` in order to work.
-`--disable-cluster-name-verification` | On clusters for which a cluster name has been set, this flag paired with `--cluster-name` disables the cluster name check for the command. This is necessary on existing clusters, when setting a cluster name or changing the cluster name: Perform a rolling restart of all nodes and include both the new `--cluster-name` value and `--disable-cluster-name-verification`, then a second rolling restart with `--cluster-name` and without `--disable-cluster-name-verification`.
-<a name="flags-external-io-dir"></a>`--external-io-dir` | The path of the external IO directory with which the local file access paths are prefixed while performing backup and restore operations using local node directories or NFS drives. If set to `disabled`, backups and restores using local node directories and NFS drives, as well as [`cockroach nodelocal upload`](cockroach-nodelocal-upload.html), are disabled.<br><br>**Default:** `extern` subdirectory of the first configured [`store`](#store).<br><br>To set the `--external-io-dir` flag to the locations you want to use without needing to restart nodes, create symlinks to the desired locations from within the `extern` directory.
-`--listening-url-file` | The file to which the node's SQL connection URL will be written as soon as the node is ready to accept connections, in addition to being printed to the [standard output](#standard-output). When `--background` is used, this happens before the process detaches from the terminal.<br><br>This is particularly helpful in identifying the node's port when an unused port is assigned automatically (`--port=0`).
-`--locality` | Arbitrary key-value pairs that describe the location of the node. Locality might include country, region, availability zone, etc. For more details, see [Locality](#locality) below.
-`--max-disk-temp-storage` | The maximum on-disk storage capacity available to store temporary data for SQL queries that exceed the memory budget (see `--max-sql-memory`). This ensures that JOINs, sorts, and other memory-intensive SQL operations are able to spill intermediate results to disk. This can be a percentage (notated as a decimal or with `%`) or any bytes-based unit (e.g., `.25`, `25%`, `500GB`, `1TB`, `1TiB`).<br><br><strong>Note:</strong> If you use the `%` notation, you might need to escape the `%` sign, for instance, while configuring CockroachDB through `systemd` service files. For this reason, it's recommended to use the decimal notation instead. Also, if expressed as a percentage, this value is interpreted relative to the size of the first store. However, the temporary space usage is never counted towards any store usage; therefore, when setting this value, it's important to ensure that the size of this temporary storage plus the size of the first store doesn't exceed the capacity of the storage device.<br><br>The temporary files are located in the path specified by the `--temp-dir` flag, or in the subdirectory of the first store (see `--store`) by default.<br><br>**Default:** `32GiB`
-<a name="flags-max-offset"></a>`--max-offset` | The maximum allowed clock offset for the cluster. If observed clock offsets exceed this limit, servers will crash to minimize the likelihood of reading inconsistent data. Increasing this value will increase the time to recovery of failures as well as the frequency of uncertainty-based read restarts.<br><br>Note that this value must be the same on all nodes in the cluster and cannot be changed with a [rolling upgrade](upgrade-cockroach-version.html). In order to change it, first stop every node in the cluster. Then once the entire cluster is offline, restart each node with the new value.<br><br>**Default:** `500ms`
-`--max-sql-memory` | The maximum in-memory storage capacity available to store temporary data for SQL queries, including prepared queries and intermediate data rows during query execution. This can be a percentage (notated as a decimal or with `%`) or any bytes-based unit, for example:<br><br>`--max-sql-memory=.25`<br>`--max-sql-memory=25%`<br>`--max-sql-memory=10000000000 ----> 1000000000 bytes`<br>`--max-sql-memory=1GB ----> 1000000000 bytes`<br>`--max-sql-memory=1GiB ----> 1073741824 bytes`<br><br>The temporary files are located in the path specified by the `--temp-dir` flag, or in the subdirectory of the first store (see `--store`) by default.<br><br><strong>Note:</strong> If you use the `%` notation, you might need to escape the `%` sign, for instance, while configuring CockroachDB through `systemd` service files. For this reason, it's recommended to use the decimal notation instead.<br><br>**Default:** `25%` <br><br>The default SQL memory size is suitable for production deployments but can be raised to increase the number of simultaneous client connections the node allows as well as the node's capacity for in-memory processing of rows when using `ORDER BY`, `GROUP BY`, `DISTINCT`, joins, and window functions. For local development clusters with memory-intensive workloads, reduce this value to, for example, `128MiB` to prevent out of memory errors.
-`--pid-file` | The file to which the node's process ID will be written as soon as the node is ready to accept connections. When `--background` is used, this happens before the process detaches from the terminal. When this flag is not set, the process ID is not written to file.
-`--store`<br>`-s` | The file path to a storage device and, optionally, store attributes and maximum size. When using multiple storage devices for a node, this flag must be specified separately for each device, for example: <br><br>`--store=/mnt/ssd01 --store=/mnt/ssd02` <br><br>For more details, see [Store](#store) below.
-<a name="flags-spatial-libs"></a>`--spatial-libs` | <span class="version-tag">New in v20.2</span>: The location on disk where CockroachDB looks for [spatial](spatial-features.html) libraries.<br/><br/>**Defaults:** <br/><ul><li>`/usr/local/lib/cockroach`</li><li>A `lib` subdirectory of the CockroachDB binary's current directory.</li></ul><br/>
-`--temp-dir` <a name="temp-dir"></a> | The path of the node's temporary store directory. On node start up, the location for the temporary files is printed to the standard output. <br><br>**Default:** Subdirectory of the first [store](#store)
-
-### Networking
-
-Flag | Description
------|-----------
-`--experimental-dns-srv` | When this flag is included, the node will first attempt to fetch SRV records from DNS for every name specified with `--join`. If a valid SRV record is found, that information is used instead of regular DNS A/AAAA lookups. This feature is experimental and may be removed or modified in a later version.
-`--listen-addr` | The IP address/hostname and port to listen on for connections from other nodes and clients. For IPv6, use the notation `[...]`, e.g., `[::1]` or `[fe80::f6f2:::]`.<br><br>This flag's effect depends on how it is used in combination with `--advertise-addr`. For example, the node will also advertise itself to other nodes using this value if `--advertise-addr` is not specified. For more details, see [Networking](recommended-production-settings.html#networking).<br><br>**Default:** Listen on all IP addresses on port `26257`; if `--advertise-addr` is not specified, also advertise the node's canonical hostname to other nodes
-`--advertise-addr` | The IP address/hostname and port to tell other nodes to use. If using a hostname, it must be resolvable from all nodes. If using an IP address, it must be routable from all nodes; for IPv6, use the notation `[...]`, e.g., `[::1]` or `[fe80::f6f2:::]`.<br><br>This flag's effect depends on how it is used in combination with `--listen-addr`. For example, if the port number is different than the one used in `--listen-addr`, port forwarding is required. For more details, see [Networking](recommended-production-settings.html#networking).<br><br>**Default:** The value of `--listen-addr`; if `--listen-addr` is not specified, advertises the node's canonical hostname and port `26257`
-`--http-addr` | The IP address/hostname and port to listen on for DB Console HTTP requests. For IPv6, use the notation `[...]`, e.g., `[::1]:8080` or `[fe80::f6f2:::]:8080`.<br><br>**Default:** Listen on the address part of `--listen-addr` on port `8080`
-`--locality-advertise-addr` | The IP address/hostname and port to tell other nodes in specific localities to use. This flag is useful when running a cluster across multiple networks, where nodes in a given network have access to a private or local interface while nodes outside the network do not. In this case, you can use `--locality-advertise-addr` to tell nodes within the same network to prefer the private or local address to improve performance and use `--advertise-addr` to tell nodes outside the network to use another address that is reachable from them.<br><br>This flag relies on nodes being started with the [`--locality`](#locality) flag and uses the `locality@address` notation, for example:<br><br>`--locality-advertise-addr=region=us-west@10.0.0.0:26257`<br><br>See the [example](#start-a-multi-node-cluster-across-private-networks) below for more details.
-`--sql-addr` | The IP address/hostname and port to listen on for SQL connections from clients. For IPv6, use the notation `[...]`, e.g., `[::1]` or `[fe80::f6f2:::]`.<br><br>This flag's effect depends on how it is used in combination with `--advertise-sql-addr`. For example, the node will also advertise itself to clients using this value if `--advertise-sql-addr` is not specified. <br><br>**Default:** The value of `--listen-addr`; if `--listen-addr` is not specified, advertises the node's canonical hostname and port `26257` <br><br>For an example, see [Start a cluster with separate RPC and SQL networks](#start-a-cluster-with-separate-rpc-and-sql-networks)
-`--advertise-sql-addr` | The IP address/hostname and port to tell clients to use. If using a hostname, it must be resolvable from all nodes. If using an IP address, it must be routable from all nodes; for IPv6, use the notation `[...]`, e.g., `[::1]` or `[fe80::f6f2:::]`.<br><br>This flag's effect depends on how it is used in combination with `--sql-addr`. For example, if the port number is different than the one used in `--sql-addr`, port forwarding is required. <br><br>**Default:** The value of `--sql-addr`; if `--sql-addr` is not specified, advertises the value of `--listen-addr`
-`--join`<br>`-j` | The host addresses that connect nodes to the cluster and distribute the rest of the node addresses. These can be IP addresses or DNS aliases of nodes.<br><br>When starting a cluster in a single region, specify the addresses of 3-5 initial nodes. When starting a cluster in multiple regions, specify more than 1 address per region, and select nodes that are spread across failure domains. Then run the [`cockroach init`](cockroach-init.html) command against any of these nodes to complete cluster startup. See the [example](#start-a-multi-node-cluster) below for more details.<br><br>Use the same `--join` list for all nodes to ensure that the cluster can stabilize. Do not list every node in the cluster, because this increases the time for a new cluster to stabilize. Note that these are best practices; it is not required to restart an existing node to update its `--join` flag.<br><br>`cockroach start` must be run with the `--join` flag. To start a single-node cluster, use `cockroach start-single-node` instead.
-`--socket-dir` |  The directory path on which to listen for [Unix domain socket](https://en.wikipedia.org/wiki/Unix_domain_socket) connections from clients installed on the same Unix-based machine. For an example, see [Connect to a cluster listening for Unix domain socket connections](cockroach-sql.html#connect-to-a-cluster-listening-for-unix-domain-socket-connections).
-`--advertise-host` | **Deprecated.** Use `--advertise-addr` instead.
-`--host` | **Deprecated.** Use `--listen-addr` instead.
-`--port`<br>`-p` | **Deprecated.** Specify port in `--advertise-addr` and/or `--listen-addr` instead.
-`--http-host` | **Deprecated.** Use `--http-addr` instead.
-`--http-port` | **Deprecated.** Specify port in `--http-addr` instead.
-
-### Security
-
-Flag | Description
------|-----------
-`--certs-dir` | The path to the [certificate directory](cockroach-cert.html). The directory must contain valid certificates if running in secure mode.<br><br>**Default:** `${HOME}/.cockroach-certs/`
-`--insecure` | **Note:** The `--insecure` flag is intended for non-production testing only. It **will be deprecated** and replaced with new secure options in v21.1.<br><br>Run in insecure mode. If this flag is not set, the `--certs-dir` flag must point to valid certificates.<br><br><strong>Note the following risks:</strong> An insecure cluster is open to any client that can access any node's IP addresses; any user, even `root`, can log in without providing a password; any user, connecting as `root`, can read or write any data in your cluster; and there is no network encryption or authentication, and thus no confidentiality.<br><br>**Default:** `false`
-`--accept-sql-without-tls` | This experimental flag allows you to connect to the cluster using a SQL user's password without [validating the client's certificate](authentication.html#client-authentication). When connecting using the built-in SQL client, [use the `--insecure` flag with the `cockroach sql` command](cockroach-sql.html#client-connection).
-`--cert-principal-map` |  A comma-separated list of `cert-principal:db-principal` mappings used to map the certificate principals to IP addresses, DNS names, and SQL users. This allows the use of certificates generated by Certificate Authorities that place restrictions on the contents of the `commonName` field. For usage information, see [Create Security Certificates using Openssl](create-security-certificates-openssl.html#examples).
-`--enterprise-encryption` | This optional flag specifies the encryption options for one of the stores on the node. If multiple stores exist, the flag must be specified for each store. <br /><br /> This flag takes a number of options.  For a complete list of options, and usage instructions, see [Encryption at Rest](encryption.html). <br /><br /> Note that this is an [Enterprise feature](enterprise-licensing.html).
-`--external-io-disable-http` |  This optional flag disables external HTTP(S) access (as well as custom HTTP(S) endpoints) when performing bulk operations (e.g, [`BACKUP`](backup.html), [`IMPORT`](import.html), etc.). This can be used in environments where you cannot run a full proxy server. <br><br>If you want to run a proxy server, you can start CockroachDB while specifying the `HTTP(S)_PROXY` environment variable.
-<a name="flags-external-io-disable-http"></a>`--external-io-disable-implicit-credentials` |  This optional flag disables the use of implicit credentials when accessing external cloud storage services for bulk operations (e.g, [`BACKUP`](backup.html), [`IMPORT`](import.html), etc.).
-
-### Locality
-
-The `--locality` flag accepts arbitrary key-value pairs that describe the location of the node. Locality might include region, country, availability zone, etc. The key-value pairs should be ordered into _locality tiers_ from most inclusive to least inclusive (e.g., region before availability zone as in `region=eu,zone=paris`), and the keys and order of key-value pairs must be the same on all nodes. It's typically better to include more pairs than fewer.
-
-- CockroachDB spreads the replicas of each piece of data across as diverse a set of localities as possible, with the order determining the priority. Locality can also be used to influence the location of data replicas in various ways using [replication zones](configure-replication-zones.html#replication-constraints).
-
-- When there is high latency between nodes (e.g., cross-availability zone deployments), CockroachDB uses locality to move range leases closer to the current workload, reducing network round trips and improving read performance, also known as ["follow-the-workload"](topology-follow-the-workload.html). In a deployment across more than 3 availability zones, however, to ensure that all data benefits from "follow-the-workload", you must increase your replication factor to match the total number of availability zones.
-
-- Locality is also a prerequisite for using the [table partitioning](partitioning.html) and [**Node Map**](enable-node-map.html) Enterprise features.
-
-#### Example
-
-~~~ shell
-# Locality flag for nodes in US East availability zone:
---locality=region=us,zone=us-east
-
-# Locality flag for nodes in US Central availability zone:
---locality=region=us,zone=us-central
-
-# Locality flag for nodes in US West availability zone:
---locality=region=us,zone=us-west
-~~~
-
-### Storage
-
-#### Storage engine
-
- The `--storage-engine` flag is used to choose the storage engine used by the node.  Note that this setting applies to all [stores](#store) on the node, including the [temp store](#temp-dir).
-
-Supported options:
-
-- `pebble`: **Default** unless specified otherwise at node startup. Uses the [Pebble storage engine](https://github.com/cockroachdb/pebble).  Pebble is intended to be bidirectionally compatible with the RocksDB on-disk format.  Pebble differs from RocksDB in that it:
-  - Is written in Go and implements a subset of RocksDB's large feature set.
-  - Contains optimizations that benefit CockroachDB.
-- `rocksdb`: Uses the [RocksDB](https://rocksdb.org) storage engine.
-
-#### Store
-
-The `--store` flag supports the following fields. Note that commas are used to separate fields, and so are forbidden in all field values.
-
-{{site.data.alerts.callout_info}}
-In-memory storage is not suitable for production deployments at this time.
-{{site.data.alerts.end}}
-
-Field | Description
-------|------------
-`type` | For in-memory storage, set this field to `mem`; otherwise, leave this field out. The `path` field must not be set when `type=mem`.
-`path` | The file path to the storage device. When not setting `attr` or `size`, the `path` field label can be left out: <br><br>`--store=/mnt/ssd01` <br><br>When either of those fields are set, however, the `path` field label must be used: <br><br>`--store=path=/mnt/ssd01,size=20GB` <br><br> **Default:** `cockroach-data`
-`attrs` | Arbitrary strings, separated by colons, specifying disk type or capability. These can be used to influence the location of data replicas. See [Configure Replication Zones](configure-replication-zones.html#replication-constraints) for full details.<br><br>In most cases, node-level `--locality` or `--attrs` are preferable to store-level attributes, but this field can be used to match capabilities for storage of individual databases or tables. For example, an OLTP database would probably want to allocate space for its tables only on solid state devices, whereas append-only time series might prefer cheaper spinning drives. Typical attributes include whether the store is flash (`ssd`) or spinny disk (`hdd`), as well as speeds and other specs, for example:<br><br> `--store=path=/mnt/hda1,attrs=hdd:7200rpm`
-`size` | The maximum size allocated to the node. When this size is reached, CockroachDB attempts to rebalance data to other nodes with available capacity. When there's no capacity elsewhere, this limit will be exceeded. Also, data may be written to the node faster than the cluster can rebalance it away; in this case, as long as capacity is available elsewhere, CockroachDB will gradually rebalance data down to the store limit.<br><br> The `size` can be specified either in a bytes-based unit or as a percentage of hard drive space (notated as a decimal or with `%`), for example: <br><br>`--store=path=/mnt/ssd01,size=10000000000 ----> 10000000000 bytes`<br>`--store=path=/mnt/ssd01,size=20GB ----> 20000000000 bytes`<br>`--store=path=/mnt/ssd01,size=20GiB ----> 21474836480 bytes`<br>`--store=path=/mnt/ssd01,size=0.02TiB ----> 21474836480 bytes`<br>`--store=path=/mnt/ssd01,size=20% ----> 20% of available space`<br>`--store=path=/mnt/ssd01,size=0.2 ----> 20% of available space`<br>`--store=path=/mnt/ssd01,size=.2 ----> 20% of available space`<br><br>**Default:** 100%<br><br>For an in-memory store, the `size` field is required and must be set to the true maximum bytes or percentage of available memory, for example:<br><br>`--store=type=mem,size=20GB`<br>`--store=type=mem,size=90%`<br><br><strong>Note:</strong> If you use the `%` notation, you might need to escape the `%` sign, for instance, while configuring CockroachDB through `systemd` service files. For this reason, it's recommended to use the decimal notation instead.
-
-### Logging
-
-By default, `cockroach start` writes all messages to log files, and prints nothing to `stderr`. However, you can control the process's [logging](debug-and-error-logs.html) behavior with the following flags:
-
-{% include {{ page.version.version }}/misc/logging-flags.md %}
-
-#### Defaults
-
-`cockroach start` uses the equivalent values for these logging flags by default:
-
-- `--log-dir=<first store dir>/logs`
-- `--logtostderr=NONE`
-
-This means, by default, CockroachDB writes all messages to log files, and never prints to `stderr`.
-
-## Standard output
-
-When you run `cockroach start`, some helpful details are printed to the standard output:
-
-~~~ shell
-CockroachDB node starting at {{ now | date: "%Y-%m-%d %H:%M:%S.%6 +0000 UTC" }}
-build:               CCL {{page.release_info.version}} @ {{page.release_info.build_time}} (go1.12.6)
-webui:               http://localhost:8080
-sql:                 postgresql://root@localhost:26257?sslmode=disable
-RPC client flags:    cockroach <client cmd> --host=localhost:26257 --insecure
-logs:                /Users/<username>/node1/logs
-temp dir:            /Users/<username>/node1/cockroach-temp242232154
-external I/O path:   /Users/<username>/node1/extern
-store[0]:            path=/Users/<username>/node1
-status:              initialized new cluster
-clusterID:           8a681a16-9623-4fc1-a537-77e9255daafd
-nodeID:              1
-~~~
-
-{{site.data.alerts.callout_success}}
-These details are also written to the `INFO` log in the `/logs` directory. You can retrieve them with a command like `grep 'node starting' node1/logs/cockroach.log -A 11`.
-{{site.data.alerts.end}}
-
-Field | Description
-------|------------
-`build` | The version of CockroachDB you are running.
-`webui` | The URL for accessing the DB Console.
-`sql` | The connection URL for your client.
-`RPC client flags` | The flags to use when connecting to the node via [`cockroach` client commands](cockroach-commands.html).
-`logs` | The directory containing debug log data.
-`temp dir` | The temporary store directory of the node.
-`external I/O path` | The external IO directory with which the local file access paths are prefixed while performing [backup](backup.html) and [restore](restore.html) operations using local node directories or NFS drives.
-`attrs` | If node-level attributes were specified in the `--attrs` flag, they are listed in this field. These details are potentially useful for [configuring replication zones](configure-replication-zones.html).
-`locality` | If values describing the locality of the node were specified in the `--locality` field, they are listed in this field. These details are potentially useful for [configuring replication zones](configure-replication-zones.html).
-`store[n]` | The directory containing store data, where `[n]` is the index of the store, e.g., `store[0]` for the first store, `store[1]` for the second store.<br><br>If store-level attributes were specified in the `attrs` field of the [`--store`](#store) flag, they are listed in this field as well. These details are potentially useful for [configuring replication zones](configure-replication-zones.html).
-`status` | Whether the node is the first in the cluster (`initialized new cluster`), joined an existing cluster for the first time (`initialized new node, joined pre-existing cluster`), or rejoined an existing cluster (`restarted pre-existing node`).
-`clusterID` | The ID of the cluster.<br><br>When trying to join a node to an existing cluster, if this ID is different than the ID of the existing cluster, the node has started a new cluster. This may be due to conflicting information in the node's data directory. For additional guidance, see the [troubleshooting](common-errors.html#node-belongs-to-cluster-cluster-id-but-is-attempting-to-connect-to-a-gossip-network-for-cluster-another-cluster-id) docs.
-`nodeID` | The ID of the node.
-
-## Examples
-
-### Start a multi-node cluster
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div>
-
-To start a multi-node cluster, run the `cockroach start` command for each node, setting the `--join` flag to the addresses of the initial nodes.
-
-{% include {{ page.version.version }}/prod-deployment/join-flag-single-region.md %}
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/prod-deployment/join-flag-multi-region.md %}
-{{site.data.alerts.end}}
-
-<div class="filter-content" markdown="1" data-scope="secure">
-
-{{site.data.alerts.callout_success}}
-Before starting the cluster, use [`cockroach cert`](cockroach-cert.html) to generate node and client certificates for a secure cluster connection.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---certs-dir=certs \
---advertise-addr=<node1 address> \
---join=<node1 address>,<node2 address>,<node3 address> \
---cache=.25 \
---max-sql-memory=.25
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---certs-dir=certs \
---advertise-addr=<node2 address> \
---join=<node1 address>,<node2 address>,<node3 address> \
---cache=.25 \
---max-sql-memory=.25
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---certs-dir=certs \
---advertise-addr=<node3 address> \
---join=<node1 address>,<node2 address>,<node3 address> \
---cache=.25 \
---max-sql-memory=.25
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---advertise-addr=<node1 address> \
---join=<node1 address>,<node2 address>,<node3 address> \
---cache=.25 \
---max-sql-memory=.25
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---advertise-addr=<node2 address> \
---join=<node1 address>,<node2 address>,<node3 address> \
---cache=.25 \
---max-sql-memory=.25
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---advertise-addr=<node3 address> \
---join=<node1 address>,<node2 address>,<node3 address> \
---cache=.25 \
---max-sql-memory=.25
-~~~
-</div>
-
-Then run the [`cockroach init`](cockroach-init.html) command against any node to perform a one-time cluster initialization:
-
-<div class="filter-content" markdown="1" data-scope="secure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach init \
---certs-dir=certs \
---host=<address of any node>
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach init \
---insecure \
---host=<address of any node>
-~~~
-</div>
-
-### Start a multi-node cluster across private networks
-
-**Scenario:**
-
-- You have a cluster that spans GCE and AWS.
-- The nodes on each cloud can reach each other on private addresses, but the private addresses aren't reachable from the other cloud.
-
-**Approach:**
-
-1. Start each node on GCE with `--locality` set to describe its location, `--locality-advertise-addr` set to advertise its private address to other nodes in on GCE, `--advertise-addr` set to advertise its public address to nodes on AWS, and `--join` set to the public addresses of 3-5 of the initial nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --locality=cloud=gce \
-    --locality-advertise-addr=cloud=gce@<private address of node> \
-    --advertise-addr=<public address of node> \
-    --join=<public address of node1>,<public address of node2>,<public address of node3> \
-    --cache=.25 \
-    --max-sql-memory=.25
-    ~~~
-
-2. Start each node on AWS with `--locality` set to describe its location, `--locality-advertise-addr` set to advertise its private address to other nodes on AWS, `--advertise-addr` set to advertise its public address to nodes on GCE, and `--join` set to the public addresses of 3-5 of the initial nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --locality=cloud=aws \
-    --locality-advertise-addr=cloud=aws@<private address of node> \
-    --advertise-addr=<public address of node> \
-    --join=<public address of node1>,<public address of node2>,<public address of node3> \
-    --cache=.25 \
-    --max-sql-memory=.25
-    ~~~
-
-3. Run the [`cockroach init`](cockroach-init.html) command against any node to perform a one-time cluster initialization:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init \
-    --certs-dir=certs \
-    --host=<address of any node>
-    ~~~
-
-### Add a node to a cluster
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div>
-
-To add a node to an existing cluster, run the `cockroach start` command, setting the `--join` flag to the same addresses you used when [starting the cluster](#start-a-multi-node-cluster):
-
-<div class="filter-content" markdown="1" data-scope="secure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---certs-dir=certs \
---advertise-addr=<node4 address> \
---join=<node1 address>,<node2 address>,<node3 address> \
---cache=.25 \
---max-sql-memory=.25
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---advertise-addr=<node4 address> \
---join=<node1 address>,<node2 address>,<node3 address> \
---cache=.25 \
---max-sql-memory=.25
-~~~
-</div>
-
-### Create a table with node locality information
-
-Start a three-node cluster with locality information specified in the `cockroach start` commands:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start --insecure --port=26257 --http-port=26258 --store=cockroach-data/1 --cache=256MiB --locality=region=eu-west-1,cloud=aws,zone=eu-west-1a
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start --insecure --port=26259 --http-port=26260 --store=cockroach-data/2 --cache=256MiB --join=localhost:26257 --locality=region=eu-west-1,cloud=aws,zone=eu-west-1b
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start --insecure --port=26261 --http-port=26262 --store=cockroach-data/3 --cache=256MiB --join=localhost:26257 --locality=region=eu-west-1,cloud=aws,zone=eu-west-1c
-~~~
-
-You can use the [`crdb_internal.locality_value`](functions-and-operators.html#system-info-functions) built-in function to return the current node's locality information from inside a SQL shell. The example below uses the output of `crdb_internal.locality_value('zone')` as the `DEFAULT` value to use for the `zone` column of new rows. Other available locality keys for the running three-node cluster include `region` and `cloud`.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE charges (
-  zone STRING NOT NULL DEFAULT crdb_internal.locality_value('zone'),
-  id INT PRIMARY KEY NOT NULL
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO charges (id) VALUES (1);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM charges WHERE id = 1;
-~~~
-
-~~~
-     zone    | id
-+------------+----+
-  eu-west-1a |  1
-(1 row)
-~~~
-
-The `zone ` column has the zone of the node on which the row was created.
-
-In a separate terminal window, open a SQL shell to a different node on the cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --port 26259
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO charges (id) VALUES (2);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM charges WHERE id = 2;
-~~~
-
-~~~
-     zone    | id
-+------------+----+
-  eu-west-1b |  2
-(1 row)
-~~~
-
-In a separate terminal window, open a SQL shell to the third node:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --port 26261
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO charges (id) VALUES (3);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM charges WHERE id = 3;
-~~~
-
-~~~
-     zone    | id
-+------------+----+
-  eu-west-1c |  3
-(1 row)
-~~~
-
-### Start a cluster with separate RPC and SQL networks
-
-Separating the network addresses used for intra-cluster RPC traffic and application SQL connections can provide an additional level of protection against security issues as a form of [defense in depth](https://en.wikipedia.org/wiki/Defense_in_depth_(computing)). This separation is accomplished with a combination of the [`--sql-addr` flag](#networking) and firewall rules or other network-level access control (which must be maintained outside of CockroachDB).
-
-For example, suppose you want to use port `26257` for SQL connections and `26258` for intra-cluster traffic. Set up firewall rules so that the CockroachDB nodes can reach each other on port `26258`, but other machines cannot. Start the CockroachDB processes as follows:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start --sql-addr=:26257 --listen-addr=:26258 --join=node1:26258,node2:26258,node3:26258 --certs-dir=~/cockroach-certs
-~~~
-
-Note the use of port `26258` (the value for `listen-addr`, not `sql-addr`) in the `--join` flag. Also, if your environment requires the use of the `--advertise-addr` flag, you should probably also use the `--advertise-sql-addr` flag when using a separate SQL address.
-
-Clusters using this configuration with client certificate authentication may also wish to use [split client CA certificates](../v20.1/create-security-certificates-custom-ca.html#split-ca-certificates).
-
-## See also
-
-- [Initialize a Cluster](cockroach-init.html)
-- [Manual Deployment](manual-deployment.html)
-- [Orchestrated Deployment](orchestration.html)
-- [Local Deployment](start-a-local-cluster.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/cockroach-statement-diag.md b/src/current/v20.2/cockroach-statement-diag.md
deleted file mode 100644
index a438a5c1249..00000000000
--- a/src/current/v20.2/cockroach-statement-diag.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: cockroach statement-diag
-summary: Use statement-diag to manage and download statement diagnostics bundles.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `cockroach statement-diag` [command](cockroach-commands.html) can be used to manage and download statement diagnostics bundles generated from the [DB Console](ui-statements-page.html#diagnostics) or [`EXPLAIN ANALYZE (DEBUG)`](explain-analyze.html#explain-analyze-debug).
-
-## Required privileges
-
-Only members of the `admin` role can run `cockroach statement-diag`. By default, the `root` user belongs to the `admin` role.
-
-## Subcommands
-
-Subcommand | Usage
------------|------
-`list` | List available statement diagnostics bundles and outstanding activation requests.
-`download` | Download a specified diagnostics bundle into a `.zip` file.
-`delete` | Delete a statement diagnostics bundle(s).
-`cancel` | Cancel an outstanding activation request(s).
-
-## Synopsis
-
-List available statement diagnostics bundles and outstanding activation requests:
-
-~~~ shell
-$ cockroach statement-diag list <flags>
-~~~
-
-Download a specified diagnostics bundle into a `.zip` file:
-
-~~~ shell
-$ cockroach statement-diag download <diagnostics ID> <bundle filename> <flags>
-~~~
-
-Delete a statement diagnostics bundle:
-
-~~~ shell
-$ cockroach statement-diag delete <diagnostics ID> <flags>
-~~~
-
-Delete all statement diagnostics bundles:
-
-~~~ shell
-$ cockroach statement-diag delete --all <flags>
-~~~
-
-Cancel an outstanding activation request:
-
-~~~ shell
-$ cockroach statement-diag cancel <diagnostics ID> <flags>
-~~~
-
-Cancel all outstanding activation requests:
-
-~~~ shell
-$ cockroach statement-diag cancel --all <flags>
-~~~
-
-## Flags
-
-- The `delete` and `cancel` subcommands support one [general-use](#general) flag.
-- All `statement-diag` subcommands support several [client connection](#client-connection) and [logging](#logging) flags.
-
-### General
-
-Flag | Description
------|------------
-`--all` | Apply to all bundles or activation requests.
-
-### Client connection
-
-{% include {{ page.version.version }}/sql/connection-parameters.md %}
-
-See [Client Connection Parameters](connection-parameters.html) for more details.
-
-### Logging
-
-By default, the `statement-diag` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## Examples
-
-### Setup
-
-These examples assume you are running [an insecure cluster](start-a-local-cluster.html) and have requested and/or generated statement diagnostics bundles using the [DB Console](ui-statements-page.html#diagnostics) or [`EXPLAIN ANALYZE (DEBUG)`](explain-analyze.html#explain-analyze-debug).
-
-### Download a statement diagnostics bundle
-
-List statement diagnostics bundles and/or activation requests:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach statement-diag list --insecure
-~~~
-
-~~~
-Statement diagnostics bundles:
-  ID                  Collection time          Statement
-  603820372518502401  2020-11-02 18:29:13 UTC  CREATE DATABASE bank
-
-Outstanding activation requests:
-  ID                  Activation time          Statement
-  603811900498804737  2020-11-02 17:46:08 UTC  SELECT * FROM bank.accounts
-~~~
-
-Download a statement diagnostics bundle to `bundle.zip`:
-
-~~~ shell
-$ cockroach statement-diag download 603820372518502401 bundle.zip --insecure
-~~~
-
-### Delete all statement diagnostics bundles
-
-Delete all statement diagnostics bundles:
-
-~~~ shell
-$ cockroach statement-diag delete --all --insecure
-~~~
-
-### Cancel an activation request
-
-List statement diagnostics bundles and/or activation requests:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach statement-diag list --insecure
-~~~
-
-~~~
-Outstanding activation requests:
-  ID                  Activation time          Statement
-  603811900498804737  2020-11-02 17:46:08 UTC  SELECT * FROM bank.accounts
-~~~
-
-Delete an activation request:
-
-~~~ shell
-$ cockroach statement-diag cancel 603811900498804737 --insecure
-~~~
-
-## See also
-
-- [DB Console Statement Details page](ui-statements-page.html#statement-details-page)
-- [`EXPLAIN ANALYZE (DEBUG)`](explain-analyze.html#explain-analyze-debug)
-- [SQL Statements](sql-statements.html)
-- [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/cockroach-userfile-delete.md b/src/current/v20.2/cockroach-userfile-delete.md
deleted file mode 100644
index 9f8a25138fb..00000000000
--- a/src/current/v20.2/cockroach-userfile-delete.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: cockroach userfile delete
-summary: The cockroach userfile delete command deletes files stored in user-scoped file storage.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `cockroach userfile delete` [command](cockroach-commands.html) deletes the files stored in the [user-scoped file storage](use-userfile-for-bulk-operations.html) which match the [provided pattern](cockroach-userfile-upload.html#file-destination), using a SQL connection. If the pattern `'*'` is passed, all files in the specified (or default, if unspecified) user-scoped file storage will be deleted. Deletions are not atomic, and all deletions prior to the first failure will occur.
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the target database. CockroachDB will proactively grant the user `GRANT`, `SELECT`, `INSERT`, `DROP`, `DELETE` on the metadata and file tables.
-
-A user can only delete files from their own user-scoped storage, which is accessed through the [userfile URI](cockroach-userfile-upload.html#file-destination) used during the upload. CockroachDB will revoke all access from every other user in the cluster except users in the `admin` role. Users in the `admin` role can delete from any user's storage.
-
-## Synopsis
-
-Delete a file:
-
-~~~ shell
-$ cockroach userfile delete <file | dir> [flags]
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach userfile delete --help
-~~~
-
-## Flags
-
- Flag            | Description
------------------+-----------------------------------------------------
-`--cert-principal-map` | A comma-separated list of `<cert-principal>:<db-principal>` mappings. This allows mapping the principal in a cert to a DB principal such as `node` or `root` or any SQL user. This is intended for use in situations where the certificate management system places restrictions on the `Subject.CommonName` or `SubjectAlternateName` fields in the certificate (e.g., disallowing a `CommonName` like `node` or `root`). If multiple mappings are provided for the same `<cert-principal>`, the last one specified in the list takes precedence. A principal not specified in the map is passed through as-is via the identity function. A cert is allowed to authenticate a DB principal if the DB principal name is contained in the mapped `CommonName` or DNS-type `SubjectAlternateName` fields.
-`--certs-dir`    | The path to the [certificate directory](cockroach-cert.html) containing the CA and client certificates and client key.<br><br>**Env Variable:** `COCKROACH_CERTS_DIR`<br>**Default:** `${HOME}/.cockroach-certs/`
-`--echo-sql`     | Reveal the SQL statements sent implicitly by the command-line utility.
-`--url`          | A [connection URL](connection-parameters.html#connect-using-a-url) to use instead of the other arguments.<br><br>**Env Variable:** `COCKROACH_URL`<br>**Default:** no URL
-`--user`<br>`-u` | The [SQL user](create-user.html) that will own the client session.<br><br>**Env Variable:** `COCKROACH_USER`<br>**Default:** `root`
-
-## Examples
-
-### Delete all files in the default storage
-
-To delete all files in the directory, pass the `'*'` pattern:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile delete '*' --certs-dir=certs
-~~~
-
-~~~
-deleted userfile://defaultdb.public.userfiles_root/test-data-2.csv
-deleted userfile://defaultdb.public.userfiles_root/test-data.csv
-deleted userfile://defaultdb.public.userfiles_root/test-upload/test-data.csv
-~~~
-
-Note that because a fully qualified userfile URI was not specified, files in the default user-scoped storage (`userfile://defaultdb.public.userfiles_$user/`) were deleted.
-
-### Delete a specific file
-
-To delete a specific file, include the file destination in the command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile delete test-data.csv --certs-dir=certs
-~~~
-
-~~~
-deleted userfile://defaultdb.public.userfiles_root/test-data.csv
-~~~
-
-### Delete files that match the provided pattern
-
-To delete all files that match a pattern, use `*`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile delete '*.csv' --certs-dir=certs
-~~~
-
-~~~
-deleted userfile://defaultdb.public.userfiles_root/test-data-2.csv
-deleted userfile://defaultdb.public.userfiles_root/test-data.csv
-~~~
-
-### Delete files from a non-default userfile URI
-
-If you [uploaded a file to a non-default userfile URI](cockroach-userfile-upload.html#upload-a-file-to-a-non-default-userfile-uri) (e.g., `userfile://testdb.public.uploads`):
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach userfile upload /Users/maxroach/Desktop/test-data.csv userfile://testdb.public.uploads/test-data.csv
-~~~
-
-Use the same URI to delete it:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach userfile delete userfile://testdb.public.uploads
-~~~
-
-## See also
-
-- [`cockroach userfile upload`](cockroach-userfile-upload.html)
-- [`cockroach userfile list`](cockroach-userfile-list.html)
-- [Use `userfile` for Bulk Operations](use-userfile-for-bulk-operations.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [`IMPORT`](import.html)
-- [`IMPORT INTO`](import-into.html)
diff --git a/src/current/v20.2/cockroach-userfile-list.md b/src/current/v20.2/cockroach-userfile-list.md
deleted file mode 100644
index 9de14968d56..00000000000
--- a/src/current/v20.2/cockroach-userfile-list.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: cockroach userfile list
-summary: List the files stored in the user-scoped file storage.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `cockroach userfile list` [command](cockroach-commands.html) lists the files stored in the [user-scoped file storage](use-userfile-for-bulk-operations.html) which match the [provided pattern](cockroach-userfile-upload.html#file-destination), using a SQL connection. If no pattern is provided, all files in the specified (or default, if unspecified) user scoped file storage will be listed.
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the target database. CockroachDB will proactively grant the user `GRANT`, `SELECT`, `INSERT`, `DROP`, `DELETE` on the metadata and file tables.
-
-A user can only view files in their own user-scoped storage, which is accessed through the [userfile URI](cockroach-userfile-upload.html#file-destination) used during the upload. CockroachDB will revoke all access from every other user in the cluster except users in the `admin` role.
-
-## Synopsis
-
-View files:
-
-~~~ shell
-$ cockroach userfile list <file | dir> [flags]
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach userfile list --help
-~~~
-
-## Flags
-
- Flag            | Description
------------------+-----------------------------------------------------
-`--cert-principal-map` | A comma-separated list of `<cert-principal>:<db-principal>` mappings. This allows mapping the principal in a cert to a DB principal such as `node` or `root` or any SQL user. This is intended for use in situations where the certificate management system places restrictions on the `Subject.CommonName` or `SubjectAlternateName` fields in the certificate (e.g., disallowing a `CommonName` like `node` or `root`). If multiple mappings are provided for the same `<cert-principal>`, the last one specified in the list takes precedence. A principal not specified in the map is passed through as-is via the identity function. A cert is allowed to authenticate a DB principal if the DB principal name is contained in the mapped `CommonName` or DNS-type `SubjectAlternateName` fields.
-`--certs-dir`    | The path to the [certificate directory](cockroach-cert.html) containing the CA and client certificates and client key.<br><br>**Env Variable:** `COCKROACH_CERTS_DIR`<br>**Default:** `${HOME}/.cockroach-certs/`
-`--echo-sql`     | Reveal the SQL statements sent implicitly by the command-line utility.
-`--url`          | A [connection URL](connection-parameters.html#connect-using-a-url) to use instead of the other arguments.<br><br>**Env Variable:** `COCKROACH_URL`<br>**Default:** no URL
-`--user`<br>`-u` | The [SQL user](create-user.html) that will own the client session.<br><br>**Env Variable:** `COCKROACH_USER`<br>**Default:** `root`
-
-## Examples
-
-### List all files in the default storage
-
-If the file or directory is not specified, all files in the default user-scoped storage (`userfile://defaultdb.public.userfiles_$user/`) will be listed:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile list --certs-dir=certs
-~~~
-
-~~~
-userfile://defaultdb.public.userfiles_root/test-data-2.csv
-userfile://defaultdb.public.userfiles_root/test-data.csv
-userfile://defaultdb.public.userfiles_root/test-upload/test-data.csv
-~~~
-
-### List a specific file
-
-To list all files in a specified directory:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile list test-data.csv --certs-dir=certs
-~~~
-
-~~~
-userfile://defaultdb.public.userfiles_root/test-data.csv
-~~~
-
-### List files that match the provided pattern
-
-To list all files that match a pattern, use `*`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile list '*.csv' --certs-dir=certs
-~~~
-
-~~~
-userfile://defaultdb.public.userfiles_root/test-data-2.csv
-userfile://defaultdb.public.userfiles_root/test-data.csv
-~~~
-
-### List files from a non-default userfile URI
-
-If you [uploaded a file to a non-default userfile URI](cockroach-userfile-upload.html#upload-a-file-to-a-non-default-userfile-uri) (e.g., `userfile://testdb.public.uploads`):
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach userfile upload /Users/maxroach/Desktop/test-data.csv userfile://testdb.public.uploads/test-data.csv
-~~~
-
-Use the same URI to view it:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach userfile list userfile://testdb.public.uploads
-~~~
-
-## See also
-
-- [`cockroach userfile upload`](cockroach-userfile-upload.html)
-- [`cockroach userfile delete`](cockroach-userfile-delete.html)
-- [Use `userfile` for Bulk Operations](use-userfile-for-bulk-operations.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [`IMPORT`](import.html)
-- [`IMPORT INTO`](import-into.html)
diff --git a/src/current/v20.2/cockroach-userfile-upload.md b/src/current/v20.2/cockroach-userfile-upload.md
deleted file mode 100644
index fab5d67b21f..00000000000
--- a/src/current/v20.2/cockroach-userfile-upload.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: cockroach userfile upload
-summary: The cockroach userfile upload command uploads a file to user-scoped file storage.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `cockroach userfile upload` [command](cockroach-commands.html) uploads a file to the [user-scoped file storage](use-userfile-for-bulk-operations.html) using a SQL connection.
-
-This command takes in a source file to upload and a destination filename. It will then use a SQL connection to upload the file to the [destination](#file-destination).
-
-{{site.data.alerts.callout_info}}
-A userfile uses storage space in the cluster, and is replicated with the rest of the cluster's data. We recommended using `cockroach userfile upload` for quick imports from your client (about 15MB or smaller).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the target database. CockroachDB will proactively grant the user `GRANT`, `SELECT`, `INSERT`, `DROP`, `DELETE` on the metadata and file tables.
-
-A user can only upload files to their own user-scoped storage, which is accessed through the [userfile URI](#file-destination). CockroachDB will revoke all access from every other user in the cluster except users in the `admin` role.
-
-## Synopsis
-
-Upload a file:
-
-~~~ shell
-$ cockroach userfile upload <location/of/file> <destination/of/file> [flags]
-~~~
-
-{{site.data.alerts.callout_info}}
-You must specify a source path.
-{{site.data.alerts.end}}
-
-View help:
-
-~~~ shell
-$ cockroach userfile upload --help
-~~~
-
-## File destination
-
-Userfile operations are backed by two tables: `files` (which holds file metadata) and `payload` (which holds the file payloads). To reference these tables, you can:
-
-- Use the default URI: `userfile://defaultdb.public.userfiles_$user/`.
-- Provide a fully qualified userfile URI that specifies the database, schema, and table name prefix you want to use.
-
-    - If you do not specify a destination URI/path, then CockroachDB will use the default URI scheme and host, and the basename from the source argument as the path. For example: `userfile://defaultdb.public.userfiles_root/local`
-    - If the destination is a well-formed userfile URI (i.e., `userfile://db.schema.tablename_prefix/path/to/file`), then CockroachDB will use that as the final URI. For example: `userfile://foo.bar.baz_root/destination/path`
-    - If destination is not a well-formed userfile URI, then CockroachDB will use the default userfile URI schema and host (`userfile://defaultdb.public.userfiles_$user/`), and the destination as the path. For example: `userfile://defaultdb.public.userfiles_root/destination/path`
-
-
-
-{{site.data.alerts.callout_danger}}
-Userfile is **not** a filesystem and does not support filesystem semantics. The destination file path must be the same after normalization (i.e., if you pass any path that results in a different path after normalization, it will be rejected).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Files are uploaded with a `.tmp` suffix and are renamed once the userfile upload transaction has committed (i.e, the process ends gracefully). Therefore, if a file you believed had finished uploading has a `.tmp` suffix, then the upload should be retried.
-{{site.data.alerts.end}}
-
-## Flags
-
- Flag            | Description
------------------+-----------------------------------------------------
-`--cert-principal-map` | A comma-separated list of `<cert-principal>:<db-principal>` mappings. This allows mapping the principal in a cert to a DB principal such as `node` or `root` or any SQL user. This is intended for use in situations where the certificate management system places restrictions on the `Subject.CommonName` or `SubjectAlternateName` fields in the certificate (e.g., disallowing a `CommonName` like `node` or `root`). If multiple mappings are provided for the same `<cert-principal>`, the last one specified in the list takes precedence. A principal not specified in the map is passed through as-is via the identity function. A cert is allowed to authenticate a DB principal if the DB principal name is contained in the mapped `CommonName` or DNS-type `SubjectAlternateName` fields.
-`--certs-dir`    | The path to the [certificate directory](cockroach-cert.html) containing the CA and client certificates and client key.<br><br>**Env Variable:** `COCKROACH_CERTS_DIR`<br>**Default:** `${HOME}/.cockroach-certs/`
-`--echo-sql`     | Reveal the SQL statements sent implicitly by the command-line utility.
-`--url`          | A [connection URL](connection-parameters.html#connect-using-a-url) to use instead of the other arguments.<br><br>**Env Variable:** `COCKROACH_URL`<br>**Default:** no URL
-`--user`<br>`-u` | The [SQL user](create-user.html) that will own the client session.<br><br>**Env Variable:** `COCKROACH_USER`<br>**Default:** `root`
-
-## Examples
-
-### Upload a file
-
-To upload a file to the default storage (`userfile://defaultdb.public.userfiles_$user/`):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile upload /Users/maxroach/Desktop/test-data.csv /test-data.csv --certs-dir=certs
-~~~
-
-~~~
-successfully uploaded to userfile://defaultdb.public.userfiles_root/test-data.csv
-~~~
-
-Also, a file can be uploaded to the default storage if the destination is not specified:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile upload /Users/maxroach/Desktop/test-data2.csv --certs-dir=certs
-~~~
-
-~~~
-successfully uploaded to userfile://defaultdb.public.userfiles_root/test-data2.csv
-~~~
-
-Then, you can use the file to [`IMPORT`](import.html) or [`IMPORT INTO`](import-into.html) data.
-
-### Upload a file to a specific directory
-
-To upload a file to a specific destination, include the destination in the command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile upload /Users/maxroach/Desktop/test-data.csv /test-upload/test-data.csv --cert-dir=certs
-~~~
-
-~~~
-successfully uploaded to userfile://defaultdb.public.userfiles_root/test-upload/test-data.csv
-~~~
-
-Then, you can use the file to [`IMPORT`](import.html) or [`IMPORT INTO`](import-into.html) data.
-
-### Upload a file to a non-default userfile URI
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach userfile upload /Users/maxroach/Desktop/test-data.csv userfile://testdb.public.uploads/test-data.csv
-~~~
-
-~~~
-successfully uploaded to userfile://testdb.public.uploads/test-data.csv
-~~~
-
-## Known limitation
-
-{% include {{ page.version.version }}/known-limitations/userfile-upload-non-recursive.md %}
-
-## See also
-
-- [`cockroach userfile list`](cockroach-userfile-list.html)
-- [`cockroach userfile delete`](cockroach-userfile-delete.html)
-- [Use `userfile` for Bulk Operations](use-userfile-for-bulk-operations.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [`IMPORT`](import.html)
-- [`IMPORT INTO`](import-into.html)
diff --git a/src/current/v20.2/cockroach-version.md b/src/current/v20.2/cockroach-version.md
deleted file mode 100644
index 85d2594526f..00000000000
--- a/src/current/v20.2/cockroach-version.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-title: cockroach version
-summary: To view version details for a specific cockroach binary, run the cockroach version command.
-toc: false
-key: view-version-details.html
----
-
-To view version details for a specific `cockroach` binary, run the `cockroach version` [command](cockroach-commands.html), or run `cockroach --version`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach version
-~~~
-
-~~~
-Build Tag:   {{page.release_info.version}}
-Build Time:  {{page.release_info.build_time}}
-Distribution: CCL
-Platform:     darwin amd64
-Go Version:   go1.8.3
-C Compiler:   4.2.1 Compatible Clang 3.8.0 (tags/RELEASE_380/final)
-Build SHA-1:  5b757262d33d814bda1deb2af20161a1f7749df3
-Build Type:   release
-~~~
-
-## Response
-
-The `cockroach version` command outputs the following fields:
-
-Field | Description
-------|------------
-`Build Tag` | The CockroachDB version. To return just the build tag, use `cockroach version --build-tag`.
-`Build Time` | The date and time when the binary was built.
-`Distribution` | The scope of the binary. If `CCL`, the binary contains functionality covered by both the CockroachDB Community License (CCL) and the Business Source License (BSL). If `OSS`, the binary contains only functionality covered by the Apache 2.0 license. The v19.2 release converts to Apache 2.0 as of Oct 1, 2022, at which time you can use the `make buildoss` command to build a pure open-source binary. For more details about licensing, see the [Licensing FAQs](licensing-faqs.html).
-`Platform` | The platform that the binary can run on.
-`Go Version` | The version of Go in which the source code is written.
-`C Compiler` | The C compiler used to build the binary.
-`Build Commit ID` | The SHA-1 hash of the commit used to build the binary.
-`Build Type` | The type of release. If `release`, `release-gnu`, or `release-musl`, the binary is for a production [release](../releases/). If `development`, the binary is for a testing release.
-
-## See also
-
-- [Install CockroachDB](install-cockroachdb.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/cockroach-workload.md b/src/current/v20.2/cockroach-workload.md
deleted file mode 100644
index 969cc9fc79f..00000000000
--- a/src/current/v20.2/cockroach-workload.md
+++ /dev/null
@@ -1,663 +0,0 @@
----
-title: cockroach workload
-summary: Use cockroach workload to run a load generator against a CockroachDB cluster.
-toc: true
----
-
-CockroachDB comes with built-in load generators for simulating different types of client workloads, printing per-operation statistics and totals after a specific duration or max number of operations. To run one of these load generators, use the `cockroach workload` [command](cockroach-commands.html) as described below.
-
-{{site.data.alerts.callout_danger}}
-The `cockroach workload` command is experimental. The interface and output are subject to change.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-Create the schema for a workload:
-
-~~~ shell
-$ cockroach workload init <workload> <flags> '<connection string>'
-~~~
-
-Run a workload:
-
-~~~ shell
-$ cockroach workload run <workload> <flags> '<connection string>'
-~~~
-
-View help:
-
-~~~ shell
-$ cockroach workload --help
-~~~
-~~~ shell
-$ cockroach workload init --help
-~~~
-~~~ shell
-$ cockroach workload init <workload> --help
-~~~
-~~~ shell
-$ cockroach workload run --help
-~~~
-~~~ shell
-$ cockroach workload run <workload> --help
-~~~
-
-## Subcommands
-
-Command | Usage
---------|------
-`init` | Load the schema for the workload. You run this command once for a given schema.
-`run` | Run a workload. You can run this command multiple times from different machines to increase concurrency. See [Concurrency](#concurrency) for more details.
-
-## Concurrency
-
-There are two ways to increase the concurrency of a workload:
-
-- **Increase the concurrency of a single workload instance** by running `cockroach workload run <workload>` with the `--concurrency` flag set to a value higher than the default. Note that not all workloads support this flag.
-- **Run multiple instances of a workload in parallel** by running `cockroach workload run <workload>` multiple times from different terminals/machines.  
-
-## Workloads
-
-Workload | Description
----------|------------
-[`bank`](#bank-workload) | Models a set of accounts with currency balances.<br><br>For this workload, you run `workload init` to load the schema and then `workload run` to generate data.
-[`intro`](#intro-and-startrek-workloads) | Loads an `intro` database, with one table, `mytable`, with a hidden message.<br><br>For this workload, you run only `workload init` to load the data. The `workload run` subcommand is not applicable.
-[`kv`](#kv-workload) | Reads and writes to keys spread (by default, uniformly at random) across the cluster.<br><br>For this workload, you run `workload init` to load the schema and then `workload run` to generate data.
-[`movr`](#movr-workload) |   Simulates a workload for the [MovR example application](movr.html).<br><br>For this workload, you run `workload init` to load the schema and then `workload run` to generate data.
-[`startrek`](#intro-and-startrek-workloads) | Loads a `startrek` database, with two tables, `episodes` and `quotes`.<br><br>For this workload, you run only `workload init` to load the data. The `workload run` subcommand is not applicable.
-[`tpcc`](#tpcc-workload) | Simulates a transaction processing workload using a rich schema of multiple tables.<br><br>For this workload, you run `workload init` to load the schema and then `workload run` to generate data.
-[`ycsb`](#ycsb-workload) | Simulates a high-scale key value workload, either read-heavy, write-heavy, or scan-based, with additional customizations.<br><br>For this workload, you run `workload init` to load the schema and then `workload run` to generate data.
-
-{{site.data.alerts.callout_info}}
- `cockroach workload` sets the [`application_name`](set-vars.html#supported-variables) for its workload queries to the name of the workload that is used. You can filter queries on `application_name` on the [Statements page of the DB Console](ui-statements-page.html#search-and-filter-by-application), or in a [`SHOW QUERIES`](show-queries.html#filter-for-specific-queries) statement.
-{{site.data.alerts.end}}
-
-## Flags
-
-{{site.data.alerts.callout_info}}
-The `cockroach workload` command does not support connection or security flags like other [`cockroach` commands](cockroach-commands.html). Instead, you must use a [connection string](connection-parameters.html) at the end of the command.
-{{site.data.alerts.end}}
-
-### `bank` workload
-
-Flag | Description
------|------------
-`--concurrency` | The number of concurrent workers.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** 2 * number of CPUs
-`--db` | The SQL database to use.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `bank`
-`--display-every` | The frequency for printing per-operation statistics. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `1s`
-`--display-format` | The format for printing per-operation statistics (`simple`, `incremental-json`). When using `incremental-json`, note that totals are not printed at the end of the workload's duration.<br><br>**Applicable command:** `run`<br>**Default:** `simple`
-`--drop` | Drop the existing database, if it exists.<br><br>**Applicable commands:** `init` or `run`. For the `run` command, this flag must be used in conjunction with `--init`.
-`--duration` | The duration to run, with a required time unit suffix. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `0`, which means run forever.
-`--histograms` | The file to write per-op incremental and cumulative histogram data to.<br><br>**Applicable command:** `run`
-`--init` | **Deprecated.** Use the `init` command instead.<br><br>**Applicable command:** `run`
-`--max-ops` | The maximum number of operations to run.<br><br>**Applicable command:** `run`
-`--max-rate` | The maximum frequency of operations (reads/writes).<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means unlimited.
-`--payload-bytes` | The size of the payload field in each initial row.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `100`
-`--ramp` | The duration over which to ramp up load.<br><br>**Applicable command:** `run`
-`--ranges` | The initial number of ranges in the `bank` table.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `10`
-`--rows` | The initial number of accounts in the `bank` table.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1000`
-`--seed` | The key hash seed.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1`
-`--tolerate-errors` | Keep running on error.<br><br>**Applicable command:** `run`
-
-### `intro` and `startrek` workloads
-
-{{site.data.alerts.callout_info}}
-These workloads generate data but do not offer the ability to run continuous load. Thus, only the `init` subcommand is supported.
-{{site.data.alerts.end}}
-
-Flag | Description
------|------------
-`--drop` | Drop the existing database, if it exists, before loading the dataset.
-
-
-### `kv` workload
-
-Flag | Description
------|------------
-`--batch` | The number of blocks to insert in a single SQL statement.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1`
-`--concurrency` | The number of concurrent workers.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `8`  `--cycle-length`| The number of keys repeatedly accessed by each writer.**Applicable commands:** `init` or `run`<br>**Default:** `9223372036854775807`
-`--db` | The SQL database to use.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `kv`
-`--display-every` | The frequency for printing per-operation statistics. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `1s`
-`--display-format` | The format for printing per-operation statistics (`simple`, `incremental-json`). When using `incremental-json`, note that totals are not printed at the end of the workload's duration.<br><br>**Applicable command:** `run`<br>**Default:** `simple`
-`--drop` | Drop the existing database, if it exists.<br><br>**Applicable commands:** `init` or `run`
-`--duration` | The duration to run, with a required time unit suffix. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means run forever.
-`--histograms` | The file to write per-op incremental and cumulative histogram data to.<br><br>**Applicable command:** `run`
-`--init` | **Deprecated.** Use the `init` command instead.<br><br>**Applicable command:** `run`
-`--max-block-bytes` | The maximum amount of raw data written with each insertion.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `2`
-`--max-ops` | The maximum number of operations to run.<br><br>**Applicable command:** `run`
-`--max-rate` | The maximum frequency of operations (reads/writes).<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means unlimited.
-`--min-block-bytes` | The minimum amount of raw data written with each insertion.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1`
-`--ramp` | The duration over which to ramp up load.<br><br>**Applicable command:** `run`
-`--read-percent` | The percent (0-100) of operations that are reads of existing keys.<br><br>**Applicable commands:** `init` or `run`
-`--seed` | The key hash seed.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1`
-`--sequential` | Pick keys sequentially instead of randomly.<br><br>**Applicable commands:** `init` or `run`
-`--splits` | The number of splits to perform before starting normal operations.<br><br>**Applicable commands:** `init` or `run`
-`--tolerate-errors` | Keep running on error.<br><br>**Applicable command:** `run`
-`--use-opt` | Use [cost-based optimizer](cost-based-optimizer.html).<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `true`
-`--write-seq` | Initial write sequence value.<br><br>**Applicable commands:** `init` or `run`
-
-### `movr` workload
-
-Flag | Description
------|------------
-`--data-loader` | How to load initial table data. Valid options are `INSERT` and `IMPORT`.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `INSERT`
-`--db` | The SQL database to use.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `movr`
-`--display-every` | The frequency for printing per-operation statistics. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `1s`
-`--display-format` | The format for printing per-operation statistics (`simple`, `incremental-json`). When using `incremental-json`, note that totals are not printed at the end of the workload's duration.<br><br>**Applicable command:** `run`<br>**Default:** `simple`
-`--drop` | Drop the existing database, if it exists.<br><br>**Applicable commands:** `init` or `run`
-`--duration` | The duration to run, with a required time unit suffix. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means run forever.
-`--histograms` | The file to write per-op incremental and cumulative histogram data to.<br><br>**Applicable command:** `run`
-`--histograms-max-latency` | Expected maximum latency of running a query, with a required time unit suffix. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `1m40s`
-`--max-ops` | The maximum number of operations to run.<br><br>**Applicable command:** `run`
-`--max-rate` | The maximum frequency of operations (reads/writes).<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means unlimited.
-`--method` | The SQL issue method (`prepare`, `noprepare`, `simple`).<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `prepare`
-`--num-histories` | The initial number of ride location histories.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1000`
-`--num-promo-codes` | The initial number of promo codes.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1000`
-`--num-rides` | Initial number of rides.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `500`
-`--num-users` | Initial number of users.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `50`
-`--num-vehicles` | Initial number of vehicles.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `15`
-`--ramp` | The duration over which to ramp up load.<br><br>**Applicable command:** `run`
-`--seed` | The random number generator seed.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1`
-`--tolerate-errors` | Keep running on error.<br><br>**Applicable command:** `run`
-
-### `tpcc` workload
-
-Flag | Description
------|------------
-`--active-warehouses` | Run the load generator against a specific number of warehouses.<br><br>**Applicable commands:** `init` or `run`<br>**Defaults:** Value of `--warehouses`
-`--data-loader` | How to load initial table data. Valid options are `INSERT` and `IMPORT`.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `INSERT`
-`--db` | The SQL database to use.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `tpcc`
-`--display-every` | The frequency for printing per-operation statistics. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `1s`
-`--display-format` | The format for printing per-operation statistics (`simple`, `incremental-json`). When using `incremental-json`, note that totals are not printed at the end of the workload's duration.<br><br>**Applicable command:** `run`<br>**Default:** `simple`
-`--drop` | Drop the existing database, if it exists.<br><br>**Applicable commands:** `init` or `run`. For the `run` command, this flag must be used in conjunction with `--init`.
-`--duration` | The duration to run, with a required time unit suffix. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means run forever.
-`--fks` | Add foreign keys.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `true`
-`--histograms` | The file to write per-op incremental and cumulative histogram data to.<br><br>**Applicable command:** `run`
-`--init` | **Deprecated.** Use the `init` command instead.<br><br>**Applicable command:** `run`
-`--interleaved` | Use [interleaved tables](interleave-in-parent.html).<br><br>**Applicable commands:** `init` or `run`<br>{% include {{ page.version.version }}/misc/interleave-deprecation-note.md %}
-`--max-ops` | The maximum number of operations to run.<br><br>**Applicable command:** `run`
-`--max-rate` | The maximum frequency of operations (reads/writes).<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means unlimited.
-`--mix` | Weights for the transaction mix.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `newOrder=10,payment=10,orderStatus=1,delivery=1,stockLevel=1`, which matches the [TPC-C specification](http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5.11.0.pdf).
-`--partition-affinity` | Run the load generator against a specific partition. This flag must be used in conjunction with `--partitions`.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `-1`
-`--partitions` | Partition tables. This flag must be used in conjunction with `--split`.<br><br>**Applicable commands:** `init` or `run`
-`--ramp` | The duration over which to ramp up load.<br><br>**Applicable command:** `run`
-`--scatter` | Scatter ranges.<br><br>**Applicable commands:** `init` or `run`
-`--seed` | The random number generator seed.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1`
-`--serializable` | Force serializable mode. CockroachDB only supports `SERIALIZABLE` isolation, so this flag is not necessary.<br><br>**Applicable command:** `init`
-`--split` | [Split tables](split-at.html).<br><br>**Applicable commands:** `init` or `run`
-`--tolerate-errors` | Keep running on error.<br><br>**Applicable command:** `run`
-`--wait` | Run in wait mode, i.e., include think/keying sleeps.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `true`
-`--warehouses` | The number of warehouses for loading initial data, at approximately 200 MB per warehouse.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1`
-`--workers` | The number of concurrent workers.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `--warehouses` * 10
-`--zones` | The number of [replication zones](configure-replication-zones.html) for partitioning. This number should match the number of `--partitions` and the zones used to start the cluster.<br><br>**Applicable command:** `init`
-
-### `ycsb` workload
-
-Flag | Description
------|------------
-`--concurrency` | The number of concurrent workers.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `8`
-`--data-loader` | How to load initial table data. Valid options are `INSERT` and `IMPORT`.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `INSERT`
-`--db` | The SQL database to use.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `ycsb`
-`--display-every` | The frequency for printing per-operation statistics. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `1s`
-`--display-format` | The format for printing per-operation statistics (`simple`, `incremental-json`). When using `incremental-json`, note that totals are not printed at the end of the workload's duration.<br><br>**Applicable command:** `run`<br>**Default:** `simple`
-`--drop` | Drop the existing database, if it exists.<br><br>**Applicable commands:** `init` or `run`. For the `run` command, this flag must be used in conjunction with `--init`.
-`--duration` | The duration to run, with a required time unit suffix. Valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)) are `ns`, `us`, `ms`, `s`, `m`, and `h`.<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means run forever.
-`--families` | Place each column in its own [column family](column-families.html).<br><br>**Applicable commands:** `init` or `run`
-`--histograms` | The file to write per-op incremental and cumulative histogram data to.<br><br>**Applicable command:** `run`
-`--init` | **Deprecated.** Use the `init` command instead.<br><br>**Applicable command:** `run`
-`--insert-count` | Number of rows to sequentially insert before beginning random number generation.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `10000`
-`--json` | Use JSONB rather than relational data.<br><br>**Applicable commands:** `init` or `run`
-`--max-ops` | The maximum number of operations to run.<br><br>**Applicable command:** `run`
-`--max-rate` | The maximum frequency of operations (reads/writes).<br><br>**Applicable command:** `run`<br>**Default:** `0`, which means unlimited.
-`--method` | The SQL issue method (`prepare`, `noprepare`, `simple`).<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `prepare`
-`--ramp` | The duration over which to ramp up load.<br><br>**Applicable command:** `run`
-`--request-distribution` | Distribution for the random number generator (`zipfian`, `uniform`).<br><br>**Applicable commands:** `init` or `run`.<br>**Default:** `zipfian`
-`--seed` | The random number generator seed.<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `1`
-`--splits` | Number of [splits](split-at.html) to perform before starting normal operations.<br><br>**Applicable commands:** `init` or `run`
-`--tolerate-errors` | Keep running on error.<br><br>**Applicable command:** `run`
-`--workload` | The type of workload to run (`A`, `B`, `C`, `D`, or `F`). For details about these workloads, see [YCSB Workloads](https://github.com/brianfrankcooper/YCSB/wiki/Core-Workloads).<br><br>**Applicable commands:** `init` or `run`<br>**Default:** `B`
-
-### Logging
-
-By default, the `cockroach workload` command logs errors to `stderr`.
-
-If you need to troubleshoot this command's behavior, you can change its [logging behavior](debug-and-error-logs.html).
-
-## Examples
-
-These examples assume that you have already [started an insecure cluster locally](start-a-local-cluster.html):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---listen-addr=localhost
-~~~
-
-### Run the `bank` workload
-
-1. Load the initial schema:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init bank \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Run the workload for 1 minute:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run bank \
-    --duration=1m \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    You'll see per-operation statistics print to standard output every second:
-
-    ~~~
-    _elapsed___errors__ops/sec(inst)___ops/sec(cum)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)
-          1s        0         1608.6         1702.2      4.5      7.3     12.6     65.0 transfer
-          2s        0         1725.3         1713.8      4.5      7.9     13.1     19.9 transfer
-          3s        0         1721.1         1716.2      4.5      7.3     11.5     21.0 transfer
-          4s        0         1328.7         1619.2      5.5     10.5     17.8     39.8 transfer
-          5s        0         1389.3         1573.3      5.2     11.5     16.3     23.1 transfer
-          6s        0         1640.0         1584.4      5.0      7.9     12.1     16.3 transfer
-          7s        0         1594.0         1585.8      5.0      7.9     10.5     15.7 transfer
-          8s        0         1652.8         1594.2      4.7      7.9     11.5     29.4 transfer
-          9s        0         1451.9         1578.4      5.2     10.0     15.2     26.2 transfer
-         10s        0         1653.3         1585.9      5.0      7.6     10.0     18.9 transfer
-    ...
-    ~~~
-
-    After the specified duration (1 minute in this case), the workload will stop and you'll see totals printed to standard output:
-
-    ~~~
-    _elapsed___errors_____ops(total)___ops/sec(cum)__avg(ms)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)__result
-       60.0s        0          84457         1407.6      5.7      5.5     10.0     15.2    167.8
-    ~~~
-
-### Run the `kv` workload
-
-1. Load the initial schema:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init kv \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Run the workload for 1 minute:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run kv \
-    --duration=1m \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    You'll see per-operation statistics print to standard output every second:
-
-    ~~~
-    _elapsed___errors__ops/sec(inst)___ops/sec(cum)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)
-          1s        0         5095.8         5123.7      1.5      2.5      3.3      7.3 write
-          2s        0         4795.4         4959.6      1.6      2.8      3.5      8.9 write
-          3s        0         3456.5         4458.5      2.0      4.5      7.3     24.1 write
-          4s        0         2787.9         4040.8      2.4      6.3     12.6     30.4 write
-          5s        0         3558.7         3944.4      2.0      4.2      6.8     11.5 write
-          6s        0         3733.8         3909.3      1.9      4.2      6.0     12.6 write
-          7s        0         3565.6         3860.1      2.0      4.7      7.9     25.2 write
-          8s        0         3469.3         3811.4      2.0      5.0      6.8     22.0 write
-          9s        0         3937.6         3825.4      1.8      3.7      7.3     29.4 write
-         10s        0         3822.9         3825.1      1.8      4.7      8.9     37.7 write
-    ...
-    ~~~
-
-    After the specified duration (1 minute in this case), the workload will stop and you'll see totals printed to standard output:
-
-    ~~~
-    _elapsed___errors_____ops(total)___ops/sec(cum)__avg(ms)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)__result
-       60.0s        0         276067         4601.0      1.7      1.6      3.1      5.2     96.5
-    ~~~
-
-### Load the `intro` dataset
-
-1. Load the dataset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init intro \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Launch the built-in SQL client to view it:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TABLES FROM intro;
-    ~~~
-
-    ~~~
-      table_name
-    +------------+
-      mytable
-    (1 row)
-    ~~~    
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ SELECT * FROM intro.mytable WHERE (l % 2) = 0;
-    ~~~
-
-    ~~~
-      l  |                          v
-    +----+------------------------------------------------------+
-       0 | !__aaawwmqmqmwwwaas,,_        .__aaawwwmqmqmwwaaa,,
-       2 | !"VT?!"""^~~^"""??T$Wmqaa,_auqmWBT?!"""^~~^^""??YV^
-       4 | !                    "?##mW##?"-
-       6 | !  C O N G R A T S  _am#Z??A#ma,           Y
-       8 | !                 _ummY"    "9#ma,       A
-      10 | !                vm#Z(        )Xmms    Y
-      12 | !              .j####mmm#####mm#m##6.
-      14 | !   W O W !    jmm###mm######m#mmm##6
-      16 | !             ]#me*Xm#m#mm##m#m##SX##c
-      18 | !             dm#||+*$##m#mm#m#Svvn##m
-      20 | !            :mmE=|+||S##m##m#1nvnnX##;     A
-      22 | !            :m#h+|+++=Xmm#m#1nvnnvdmm;     M
-      24 | ! Y           $#m>+|+|||##m#1nvnnnnmm#      A
-      26 | !  O          ]##z+|+|+|3#mEnnnnvnd##f      Z
-      28 | !   U  D       4##c|+|+|]m#kvnvnno##P       E
-      30 | !       I       4#ma+|++]mmhvnnvq##P`       !
-      32 | !        D I     ?$#q%+|dmmmvnnm##!
-      34 | !           T     -4##wu#mm#pw##7'
-      36 | !                   -?$##m####Y'
-      38 | !             !!       "Y##Y"-
-      40 | !
-    (21 rows)
-    ~~~
-
-### Load the `startrek` dataset
-
-1. Load the dataset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init startrek \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Launch the built-in SQL client to view it:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TABLES FROM startrek;
-    ~~~
-
-    ~~~
-      table_name
-    +------------+
-      episodes
-      quotes
-    (2 rows)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM startrek.episodes WHERE stardate > 5500;
-    ~~~
-
-    ~~~
-      id | season | num |               title               | stardate
-    +----+--------+-----+-----------------------------------+----------+
-      60 |      3 |   5 | Is There in Truth No Beauty?      |   5630.7
-      62 |      3 |   7 | Day of the Dove                   |   5630.3
-      64 |      3 |   9 | The Tholian Web                   |   5693.2
-      65 |      3 |  10 | Plato's Stepchildren              |   5784.2
-      66 |      3 |  11 | Wink of an Eye                    |   5710.5
-      69 |      3 |  14 | Whom Gods Destroy                 |   5718.3
-      70 |      3 |  15 | Let That Be Your Last Battlefield |   5730.2
-      73 |      3 |  18 | The Lights of Zetar               |   5725.3
-      74 |      3 |  19 | Requiem for Methuselah            |   5843.7
-      75 |      3 |  20 | The Way to Eden                   |   5832.3
-      76 |      3 |  21 | The Cloud Minders                 |   5818.4
-      77 |      3 |  22 | The Savage Curtain                |   5906.4
-      78 |      3 |  23 | All Our Yesterdays                |   5943.7
-      79 |      3 |  24 | Turnabout Intruder                |   5928.5
-    (14 rows)
-    ~~~
-
-### Load the `movr` dataset
-
-1. Load the dataset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init movr \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Launch the built-in SQL client to view it:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TABLES FROM movr;
-    ~~~
-
-    ~~~
-            table_name
-+----------------------------+
-  promo_codes
-  rides
-  user_promo_codes
-  users
-  vehicle_location_histories
-  vehicles
-(6 rows)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM movr.users WHERE city='new york';
-    ~~~
-
-    ~~~
-                   id                  |   city   |       name       |           address           | credit_card
-+--------------------------------------+----------+------------------+-----------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills        | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57 | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61 | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8   | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley              | 0792553487
-(5 rows)
-    ~~~
-
-### Run the `movr` workload
-
-1. Load the initial schema:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init movr \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Initialize and run the workload for 1 minute:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run movr \
-    --duration=1m \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    You'll see per-operation statistics print to standard output every second:
-
-    ~~~
-    _elapsed___errors__ops/sec(inst)___ops/sec(cum)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)
-        1.0s        0           31.9           32.0      0.5      0.6      1.4      1.4 addUser
-        1.0s        0            6.0            6.0      1.2      1.4      1.4      1.4 addVehicle
-        1.0s        0           10.0           10.0      2.2      6.3      6.3      6.3 applyPromoCode
-        1.0s        0            2.0            2.0      0.5      0.6      0.6      0.6 createPromoCode
-        1.0s        0            9.0            9.0      0.9      1.6      1.6      1.6 endRide
-        1.0s        0         1407.5         1407.8      0.3      0.5      0.7      4.1 readVehicles
-        1.0s        0           27.0           27.0      2.1      3.1      4.7      4.7 startRide
-        1.0s        0           86.8           86.9      4.7      8.4     11.5     15.2 updateActiveRides
-        2.0s        0           26.0           29.0      0.5      1.1      1.4      1.4 addUser
-        2.0s        0            8.0            7.0      1.2      2.8      2.8      2.8 addVehicle
-        2.0s        0            2.0            6.0      2.6      2.8      2.8      2.8 applyPromoCode
-        2.0s        0            0.0            1.0      0.0      0.0      0.0      0.0 createPromoCode
-        2.0s        0            6.0            7.5      0.8      1.7      1.7      1.7 endRide
-        2.0s        0         1450.4         1429.1      0.3      0.6      0.9      2.6 readVehicles
-        2.0s        0           17.0           22.0      2.1      3.3      5.5      5.5 startRide
-        2.0s        0           59.0           72.9      6.3     11.5     11.5     14.2 updateActiveRides
-    ...
-    ~~~
-
-    After the specified duration (1 minute in this case), the workload will stop and you'll see totals printed to standard output:
-
-    ~~~
-    _elapsed___errors_____ops(total)___ops/sec(cum)__avg(ms)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)__result
-       60.0s        0          85297         1421.6      0.7      0.3      2.6      7.1     30.4
-    ~~~
-
-### Run the `tpcc` workload
-
-1. Load the initial schema and data:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init tpcc \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Run the workload for 10 minutes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run tpcc \
-    --duration=10m \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    You'll see per-operation statistics print to standard output every second:
-
-    ~~~
-    _elapsed___errors__ops/sec(inst)___ops/sec(cum)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)
-          1s        0         1443.4         1494.8      4.7      9.4     27.3     67.1 transfer
-          2s        0         1686.5         1590.9      4.7      8.1     15.2     28.3 transfer
-          3s        0         1735.7         1639.0      4.7      7.3     11.5     28.3 transfer
-          4s        0         1542.6         1614.9      5.0      8.9     12.1     21.0 transfer
-          5s        0         1695.9         1631.1      4.7      7.3     11.5     22.0 transfer
-          6s        0         1569.2         1620.8      5.0      8.4     11.5     15.7 transfer
-          7s        0         1614.6         1619.9      4.7      8.1     12.1     16.8 transfer
-          8s        0         1344.4         1585.6      5.8     10.0     15.2     31.5 transfer
-          9s        0         1351.9         1559.5      5.8     10.0     16.8     54.5 transfer
-         10s        0         1514.8         1555.0      5.2      8.1     12.1     16.8 transfer
-    ...
-    ~~~
-
-    After the specified duration (10 minutes in this case), the workload will stop and you'll see totals printed to standard output:
-
-    ~~~
-    _elapsed___errors_____ops(total)___ops/sec(cum)__avg(ms)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)__result
-      600.0s        0         823902         1373.2      5.8      5.5     10.0     15.2    209.7
-    ~~~
-
-### Run the `ycsb` workload
-
-1. Load the initial schema and data:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init ycsb \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Run the workload for 10 minutes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run ycsb \
-    --duration=10m \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    You'll see per-operation statistics print to standard output every second:
-
-    ~~~
-    _elapsed___errors__ops/sec(inst)___ops/sec(cum)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)
-          1s        0         9258.1         9666.6      0.7      1.3      2.0      8.9 read
-          1s        0          470.1          490.9      1.7      2.9      4.1      5.0 update
-          2s        0        10244.6         9955.6      0.7      1.2      2.0      6.6 read
-          2s        0          559.0          525.0      1.6      3.1      6.0      7.3 update
-          3s        0         9870.8         9927.4      0.7      1.4      2.4     10.0 read
-          3s        0          500.0          516.6      1.6      4.2      7.9     15.2 update
-          4s        0         9847.2         9907.3      0.7      1.4      2.4     23.1 read
-          4s        0          506.8          514.2      1.6      3.7      7.6     17.8 update
-          5s        0        10084.4         9942.6      0.7      1.3      2.1      7.1 read
-          5s        0          537.2          518.8      1.5      3.5     10.0     15.2 update
-    ...
-    ~~~
-
-    After the specified duration (10 minutes in this case), the workload will stop and you'll see totals printed to standard output:
-
-    ~~~
-    _elapsed___errors_____ops(total)___ops/sec(cum)__avg(ms)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)__result
-      600.0s        0        4728286         7880.2      1.0      0.9      2.2      5.2    268.4
-    ~~~  
-
-### Customize the frequency and format of per-operation statistics
-
-To customize the frequency of per-operation statistics, use the `--display-every` flag, with `ns`, `us`, `ms`, `s`, `m`, and `h` as valid [time units](https://en.wikipedia.org/wiki/Orders_of_magnitude_(time)). To customize the format of per-operation statistics, use the `--display-format` flag, with `incremental-json` or `simple` (default) as options.
-
-1. Load the initial schema and data:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init ycsb \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-2. Run the workload for 1 minute, printing the output every 5 seconds as JSON:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run ycsb \
-    --duration=1m \
-    --display-every=5s \
-    --display-format=incremental-json \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    ~~~
-    {"time":"2019-09-13T03:25:03.950621Z","errs":0,"avgt":8434.5,"avgl":8471.0,"p50l":0.8,"p95l":1.6,"p99l":3.1,"maxl":19.9,"type":"read"}
-    {"time":"2019-09-13T03:25:03.950621Z","errs":0,"avgt":438.1,"avgl":440.0,"p50l":1.5,"p95l":2.8,"p99l":4.5,"maxl":14.7,"type":"update"}
-    {"time":"2019-09-13T03:25:08.95061Z","errs":0,"avgt":7610.6,"avgl":8040.8,"p50l":0.8,"p95l":2.0,"p99l":4.2,"maxl":65.0,"type":"read"}
-    {"time":"2019-09-13T03:25:08.95061Z","errs":0,"avgt":391.8,"avgl":415.9,"p50l":1.6,"p95l":3.5,"p99l":5.8,"maxl":21.0,"type":"update"}
-    {"time":"2019-09-13T03:25:13.950727Z","errs":0,"avgt":7242.0,"avgl":7774.5,"p50l":0.8,"p95l":2.2,"p99l":4.7,"maxl":75.5,"type":"read"}
-    {"time":"2019-09-13T03:25:13.950727Z","errs":0,"avgt":382.0,"avgl":404.6,"p50l":1.6,"p95l":4.7,"p99l":10.5,"maxl":24.1,"type":"update"}
-    ...
-    ~~~
-
-    When using `incremental-json`, note that totals are not printed at the end of the workload's duration.
-
-## See also
-
-- [`cockroach demo`](cockroach-demo.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Performance Benchmarking with TPC-C](performance-benchmarking-with-tpcc-small.html)
diff --git a/src/current/v20.2/cockroachdb-in-comparison.md b/src/current/v20.2/cockroachdb-in-comparison.md
deleted file mode 100644
index 105b04654ea..00000000000
--- a/src/current/v20.2/cockroachdb-in-comparison.md
+++ /dev/null
@@ -1,353 +0,0 @@
----
-title: CockroachDB in Comparison
-summary: Learn how CockroachDB compares to other popular databases like PostgreSQL, Cassandra, MongoDB, Google Cloud Spanner, and more.
-tags: mongodb, mysql, dynamodb
-toc: false
-comparison: true
----
-
-This page shows you how the key features of CockroachDB stack up against other databases. Hover over the features for their intended meanings.
-
-<table class="comparison-chart">
-  <tr>
-    <th></th>
-    <th>
-      <select data-column="one">
-        <option value="MySQL">MySQL</option>
-        <option value="PostgreSQL">PostgreSQL</option>
-        <option value="Oracle">Oracle</option>
-        <option value="AWS Aurora">AWS Aurora</option>
-        <option value="Cassandra">Cassandra</option>
-        <option value="MongoDB" selected>MongoDB</option>
-        <option value="Spanner">Spanner</option>
-        <option value="Yugabyte">Yugabyte</option>
-      </select>
-    </th>
-    <th class="comparison-chart__column-two">
-      <select data-column="two">
-        <option value="MySQL">MySQL</option>
-        <option value="PostgreSQL" selected>PostgreSQL</option>
-        <option value="Oracle">Oracle</option>
-        <option value="AWS Aurora">AWS Aurora</option>
-        <option value="Cassandra">Cassandra</option>
-        <option value="MongoDB">MongoDB</option>
-        <option value="Spanner">Spanner</option>
-        <option value="Yugabyte">Yugabyte</option>
-      </select>
-    </th>
-    <th>CockroachDB</th>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Database horizontal scale
-      <a href="#" data-toggle="tooltip" title="Increase capacity of the database by adding more instances/nodes">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support" data-dbs='["MySQL", "PostgreSQL"]'>Manual Sharding</span>
-      <span class="support" data-dbs='["Oracle"]'>Add on configuration</span>
-      <span class="support" data-dbs='["AWS Aurora", "MongoDB", "Spanner", "Yugobyte"]'>Node based, automated read scale, limited write</span>
-      <span class="support" data-dbs='["Cassandra"]'>Node based, automated for both reads and writes</span>
-    </td>
-    <td class="comparison-chart__column-two">
-      <span class="support" data-dbs='["MySQL", "PostgreSQL"]'>Manual Sharding</span>
-      <span class="support" data-dbs='["Oracle"]'>Add on configuration</span>
-      <span class="support" data-dbs='["AWS Aurora", "MongoDB", "Spanner", "Yugobyte"]'>Node based, automated read scale, limited write</span>
-      <span class="support" data-dbs='["Cassandra"]'>Node based, automated for both reads and writes</span>
-    </td>
-    <td>Node based, automated for both reads and writes</a></td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Database load balancing (internal)
-      <a href="#" data-toggle="tooltip" title="Locate data across multiple instances/nodes based on optimization criteria for balancing load">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support" data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Manual - not part of database</span>
-      <span class="support" data-dbs='["AWS Aurora"]'>None and full copies across regions</span>
-      <span class="support" data-dbs='["Cassandra", "MongoDB", "Spanner", "Yugobyte"]'>Even distribution to optimize storage</span>
-    </td>
-    <td class="comparison-chart__column-two">
-          <span class="support" data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Manual - not part of database</span>
-      <span class="support" data-dbs='["AWS Aurora"]'>None and full copies across regions</span>
-      <span class="support" data-dbs='["Cassandra", "MongoDB", "Spanner", "Yugobyte"]'>Even distribution to optimize storage</span>
-    </td>
-    <td>Detailed options to optimize storage, compute and latency</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Failover
-      <a href="#" data-toggle="tooltip" title="Provide access to backup data upon failure">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support" data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Manual - not part of database</span>
-      <span class="support" data-dbs='["AWS Aurora"]'>Automated for reads, limited for writes to one region</span>
-      <span class="support" data-dbs='["MongoDB", "Cassandra"]'>Automated for reads, limited guarantees for writes</span>
-      <span class="support" data-dbs='["Spanner", "Yugabyte"]'>Fully automated for both reads and writes</span>
-    </td>
-    <td class="comparison-chart__column-two">
-          <span class="support" data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Manual - not part of database</span>
-      <span class="support" data-dbs='["AWS Aurora"]'>Automated for reads, limited for writes to one region</span>
-      <span class="support" data-dbs='["MongoDB", "Cassandra"]'>Automated for reads, limited guarantees for writes</span>
-      <span class="support" data-dbs='["Spanner", "Yugabyte"]'>Fully automated for both reads and writes</span>
-    </td>
-    <td>Fully automated for both reads and writes</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Automated repair and RPO(Recovery Point Objective)
-      <a href="#" data-toggle="tooltip" title="Repair the database after failure and the time it takes for the db to come back online">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support" data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Manual repair RPO ~1-60 mins</span>
-      <span class="support" data-dbs='["AWS Aurora"]'>Automated RPO ~1 -5 mins</span>
-      <span class="support" data-dbs='["MongoDB", "Cassandra]'>Manual & automated repair RPO &lt;1 min</span>
-      <span class="support" data-dbs='["Spanner", "Yugabyte]'>"Automated repair RPO &lt;10 sec"</span>
-    </td>
-    <td class="comparison-chart__column-two">
-          <span class="support" data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Manual repair RPO ~1-60 mins</span>
-      <span class="support" data-dbs='["AWS Aurora"]'>Automated RPO ~1 -5 mins</span>
-      <span class="support" data-dbs='["MongoDB", "Cassandra]'>Manual & automated repair RPO &lt;1 min</span>
-      <span class="support" data-dbs='["Spanner", "Yugabyte]'>"Automated repair RPO &lt;10 sec"</span>
-    </td>
-    <td>Automated repair RPO = 0 sec</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Distributed reads
-      <a href="#" data-toggle="tooltip" title="Reliably read data in any instance/node of the database">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support" data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Manual - asynchronous</span>
-      <span class="support" data-dbs='["AWS Aurora", "MongoDB", "Cassandra", "Spanner", "Yugabyte"]'>Yes</span>
-    </td>
-    <td class="comparison-chart__column-two">
-          <span class="support" data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Manual - asynchronous</span>
-      <span class="support" data-dbs='["AWS Aurora", "MongoDB", "Cassandra", "Spanner", "Yugabyte"]'>Yes</span>
-    </td>
-    <td>Yes</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Distributed transactions
-      <a href="#" data-toggle="tooltip" title="Allow for acid writes across multiple instances/nodes">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle", "AWS Aurora"]'>No</span>
-      <span class="support " data-dbs='["MongoDB", "Cassandra"]'>Lightweight transactions only</span>
-      <span class="support " data-dbs='["Spanner", "Yugabyrte"]'>Yes</span>
-    </td>
-    <td class="comparison-chart__column-two">
-          <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle", "AWS Aurora"]'>No</span>
-      <span class="support " data-dbs='["MongoDB", "Cassandra"]'>Lightweight transactions only</span>
-      <span class="support " data-dbs='["Spanner", "Yugabyrte"]'>Yes</span>
-    </td>
-    <td>Yes</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Database isolation levels
-      <a href="#" data-toggle="tooltip" title="Transaction isolation levels allowed for writes in the database">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle", "AWS Aurora"]'>Single region consistent default - Snapshot highest - Serializable</span>
-      <span class="support " data-dbs='["MongoDB"]'>Eventual consistent default - Read uncommitted highest - Snapshot read</span>
-      <span class="support " data-dbs='["Cassandra"]'>Eventual consistent - No transaction isolation guarantees</span>
-      <span class="support " data-dbs='["Spanner", "Yugabyte"]'>Default - Snapshot highest - Serializable</span>
-    </td>
-    <td class="comparison-chart__column-two">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle", "AWS Aurora"]'>Single region consistent default - Snapshot highest - Serializable</span>
-      <span class="support " data-dbs='["MongoDB"]'>Eventual consistent default - Read uncommitted highest - Snapshot read</span>
-      <span class="support " data-dbs='["Cassandra"]'>Eventual consistent - No transaction isolation guarantees</span>
-      <span class="support " data-dbs='["Spanner", "Yugabyte"]'>Default - Snapshot highest - Serializable</span>
-    </td>
-    <td>Guaranteed consistent default - Serializable highest - Serializable</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Potential data issues (default)
-      <a href="#" data-toggle="tooltip" title="Possible data inconsistency issues at default isolation level">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle", "AWS Aurora"]'>Phantom reads, non-repeatable reads, write skew</span>
-      <span class="support " data-dbs='["MongoDB"]'>Dirty reads, phantom reads, non-repeatable reads, write skew</span>
-      <span class="support " data-dbs='["Cassandra"]'>Dirty reads, phantom reads, non-repeatable reads, write conflicts</span>
-      <span class="support " data-dbs='["Spanner"]'>None</span>
-      <span class="support " data-dbs='["Yugabyte"]'>Phantom reads, non-repeatable reads</span>
-    </td>
-    <td class="comparison-chart__column-two">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle", "AWS Aurora"]'>Phantom reads, non-repeatable reads, write skew</span>
-      <span class="support " data-dbs='["MongoDB"]'>Dirty reads, phantom reads, non-repeatable reads, write skew</span>
-      <span class="support " data-dbs='["Cassandra"]'>Dirty reads, phantom reads, non-repeatable reads, write conflicts</span>
-      <span class="support " data-dbs='["Spanner"]'>None</span>
-      <span class="support " data-dbs='["Yugabyte"]'>Phantom reads, non-repeatable reads</span>
-    </td>
-    <td>None</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      SQL
-      <a href="#" data-toggle="tooltip" title="Compliance with standard SQL">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle", "AWS Aurora"]'>Yes</span>
-      <span class="support " data-dbs='["MongoDB", "Cassandra"]'>No</span>
-      <span class="support " data-dbs='["Spanner", "Yugabyte"]'>Yes - with limitations</span>
-    </td>
-    <td class="comparison-chart__column-two">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle", "AWS Aurora"]'>Yes</span>
-      <span class="support " data-dbs='["MongoDB", "Cassandra"]'>No</span>
-      <span class="support " data-dbs='["Spanner", "Yugabyte"]'>Yes - with limitations</span>
-    </td>
-    <td>Yes - wire compatible with PostgreSQL</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Database schema change
-      <a href="#" data-toggle="tooltip" title="Modify database schema across all tables">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Yes</span>
-      <span class="support " data-dbs='["AWS Aurora","MongoDB", "Cassandra"]'>Offline</span>
-      <span class="support " data-dbs='["Spanner", "Yugabyte"]'>Online, Active and Dynamic</span>
-    </td>
-    <td class="comparison-chart__column-two">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Yes</span>
-      <span class="support " data-dbs='["AWS Aurora","MongoDB", "Cassandra"]'>Offline</span>
-      <span class="support " data-dbs='["Spanner", "Yugabyte"]'>Online, Active and Dynamic</span>
-    </td>
-    <td>Online, Active and Dynamic</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Cost based optimization
-      <a href="#" data-toggle="tooltip" title="Optimize execution of queries based on transaction analytics">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Yes</span>
-      <span class="support " data-dbs='["AWS Aurora","MongoDB", "Cassandra"]'>No</span>
-      <span class="support " data-dbs='["Spanner"]'>?</span>
-      <span class="support " data-dbs='["Yugabyte"]'>No</span>
-    </td>
-    <td class="comparison-chart__column-two">
-          <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Yes</span>
-      <span class="support " data-dbs='["AWS Aurora","MongoDB", "Cassandra"]'>No</span>
-      <span class="support " data-dbs='["Spanner"]'>?</span>
-      <span class="support " data-dbs='["Yugabyte"]'>No</span>
-    </td>
-    <td>Yes</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Data Geo-partitioning
-      <a href="#" data-toggle="tooltip" title="Tie data to an instance/node to comply with regulations or optimize access latency">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle","AWS Aurora","MongoDB"]'>No</span>
-      <span class="support " data-dbs='[ "Cassandra"]'>Yes, object level</span>
-      <span class="support " data-dbs='["Spanner"]'>Yes</span>
-      <span class="support " data-dbs='["Yugabyte"]'>No</span>
-    </td>
-    <td class="comparison-chart__column-two">
-          <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle","AWS Aurora","MongoDB"]'>No</span>
-      <span class="support " data-dbs='[ "Cassandra"]'>Yes, object level</span>
-      <span class="support " data-dbs='["Spanner"]'>Yes</span>
-      <span class="support " data-dbs='["Yugabyte"]'>No</span>
-    </td>
-    <td>Yes, row level</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Upgrade method
-      <a href="#" data-toggle="tooltip" title="Upgrade the database software">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle","AWS Aurora"]'>Offline</span>
-      <span class="support " data-dbs='[ "MongoDB", "Cassandra","Spanner","Yugabyte"]'>Online, rolling</span>
-    </td>
-    <td class="comparison-chart__column-two">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle","AWS Aurora"]'>Offline</span>
-      <span class="support " data-dbs='[ "MongoDB", "Cassandra","Spanner","Yugabyte"]'>Online, rolling</span>
-    </td>
-    <td>Online, rolling</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Multi-region
-      <a href="#" data-toggle="tooltip" title="Deploy a single database across multiple regions">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Yes - manual</span>
-      <span class="support " data-dbs='[ "AWS Aurora", "MongoDB", "Spanner", "Yugabyte"]'>Yes, but not for writes</span>
-      <span class="support " data-dbs='[ "Cassandra"]'>Yes, for both reads and writes</span>
-    </td>
-    <td class="comparison-chart__column-two">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle"]'>Yes - manual</span>
-      <span class="support " data-dbs='[ "AWS Aurora", "MongoDB", "Spanner", "Yugabyte"]'>Yes, but not for writes</span>
-      <span class="support " data-dbs='[ "Cassandra"]'>Yes, for both reads and writes</span>
-    </td>
-    <td>Yes for both reads and writes</td>
-  </tr>
-
-  <tr>
-    <td class="comparison-chart__feature">
-      Multi-cloud
-      <a href="#" data-toggle="tooltip" title="Deploy a single database across multiple cloud providers or on-prem">
-        <img src="{{ 'images/v20.2/icon_info.svg' | relative_url }}" alt="tooltip icon">
-      </a>
-    </td>
-    <td class="comparison-chart__column-one">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle","AWS Aurora", "MongoDB", "Spanner","Yugabyte"]'>No</span>
-      <span class="support " data-dbs='["Cassandra"]'>Yes</span>
-    </td>
-    <td class="comparison-chart__column-two">
-      <span class="support " data-dbs='["MySQL", "PostgreSQL", "Oracle","AWS Aurora", "MongoDB", "Spanner","Yugabyte"]'>No</span>
-      <span class="support " data-dbs='["Cassandra"]'>Yes</span>
-    </td>
-    <td>Yes</td>
-  </tr>
-
-</table>
-
-<div style="display:none;" class="footnote">* In DynamoDB, distributed transactions and ACID semantics across all data in the database, not just per row, requires an additional <a href="https://aws.amazon.com/blogs/aws/dynamodb-transaction-library/">transaction library</a>.</div>
diff --git a/src/current/v20.2/collate.md b/src/current/v20.2/collate.md
deleted file mode 100644
index 7b29c9ab2d8..00000000000
--- a/src/current/v20.2/collate.md
+++ /dev/null
@@ -1,270 +0,0 @@
----
-title: COLLATE
-summary: The COLLATE feature lets you sort strings according to language- and country-specific rules.
-toc: true
----
-
-The `COLLATE` feature lets you sort [`STRING`](string.html) values according to language- and country-specific rules, known as collations.
-
-Collated strings are important because different languages have [different rules for alphabetic order](https://en.wikipedia.org/wiki/Alphabetical_order#Language-specific_conventions), especially with respect to accented letters. For example, in German accented letters are sorted with their unaccented counterparts, while in Swedish they are placed at the end of the alphabet. A collation is a set of rules used for ordering and usually corresponds to a language, though some languages have multiple collations with different rules for sorting; for example Portuguese has separate collations for Brazilian and European dialects (`pt-BR` and `pt-PT` respectively).
-
-## Details
-
-- Operations on collated strings cannot involve strings with a different collation or strings with no collation. However, it is possible to <a href="#ad-hoc-collation-casting">add or overwrite a collation on the fly</a>.
-
-- Only use the collation feature when you need to sort strings by a specific collation. We recommend this because every time a collated string is constructed or loaded into memory, CockroachDB computes its collation key, whose size is linear in relationship to the length of the collated string, which requires additional resources.
-
-- Collated strings can be considerably larger than the corresponding uncollated strings, depending on the language and the string content. For example, strings containing the character `é` produce larger collation keys in the French locale than in Chinese.
-
-- Collated strings that are indexed require additional disk space as compared to uncollated strings. In case of indexed collated strings, collation keys must be stored in addition to the strings from which they are derived, creating a constant factor overhead.
-
-## Supported collations
-
-CockroachDB supports collations identified by [Unicode locale identifiers](https://cldr.unicode.org/development/core-specification#h.vgyyng33o798). For example, `en-US` identifies US English, `es` identifies Spanish, and `fr-CA` identifies Canadian French. Collation names are case-insensitive, and hyphens and underscores are interchangeable.
-
-{{site.data.alerts.callout_info}}
-If a hyphen is used in a SQL query, the collation name must be enclosed in double quotes, as single quotes are used for SQL string literals.
-{{site.data.alerts.end}}
-
-A list of supported collations can be found in the `pg_catalog.pg_collation` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT collname from pg_catalog.pg_collation;
-~~~
-
-~~~
-       collname
------------------------
-  und
-  aa
-  af
-  ar
-...
-(95 rows)
-~~~
-
-CockroachDB supports standard aliases for the collations listed in `pg_collation`. For example, `es-419` (Latin American Spanish) and `zh-Hans` (Simplified Chinese) are supported, but they do not appear in the `pg_collations` table because they are equivalent to the `es` and `zh` collations listed in the table.
-
-CockroachDB also supports the following Unicode locale extensions:
-
-- `co` (collation type)
-- `ks` (strength)
-- `kc` (case level)
-- `kb` (backwards second level weight)
-- `kn` (numeric)
-- `ks` (strength)
-- `ka` (alternate handling)
-
-To use a locale extension, append `-u-` to the base locale name, followed by the extension. For example, `en-US-u-ks-level2` is case-insensitive US English. The `ks` modifier changes the "strength" of the collation, causing it to treat certain classes of characters as equivalent (PostgreSQL calls these "non-deterministic collations"). Setting the `ks` to `level2` makes the collation case-insensitive (for languages that have this concept).
-
-For more details on locale extensions, see the [Unicode Collation Algorithm](https://en.wikipedia.org/wiki/Unicode_collation_algorithm).
-
-## Collation versioning
-
-While changes to collations are rare, they are possible, especially in languages with a large numbers of characters (e.g., Simplified and Traditional Chinese). CockroachDB updates its support with new versions of the Unicode standard every year, but there is currently no way to specify the version of Unicode to use. As a result, it is possible for a collation change to invalidate existing collated string data. To prevent collated data from being invalidated by Unicode changes, we recommend storing data in columns with an uncollated string type, and then using a [computed column](computed-columns.html) for the desired collation. In the event that a collation change produces undesired effects, the computed column can be dropped and recreated.
-
-## SQL syntax
-
-Collated strings are used as normal strings in SQL, but have a `COLLATE` clause appended to them.
-
-- **Column syntax**: `STRING COLLATE <collation>`. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE foo (a STRING COLLATE en PRIMARY KEY);
-    ~~~
-
-    {{site.data.alerts.callout_info}}You can also use any of the <a href="string.html#aliases">aliases for <code>STRING</code></a>.{{site.data.alerts.end}}
-
-- **Value syntax**: `<STRING value> COLLATE <collation>`. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO foo VALUES ('dog' COLLATE en);
-    ~~~
-
-## Examples
-
-### Specify collation for a column
-
-You can set a default collation for all values in a `STRING` column.
-
-For example, you can set a column's default collation to German (`de`):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE de_names (name STRING COLLATE de PRIMARY KEY);
-~~~
-
-When inserting values into this column, you must specify the collation for every value:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO de_names VALUES ('Backhaus' COLLATE de), ('Bär' COLLATE de), ('Baz' COLLATE de);
-~~~
-
-The sort will now honor the `de` collation that treats *ä* as *a* in alphabetic sorting:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM de_names ORDER BY name;
-~~~
-~~~
-    name
-+----------+
-  Backhaus
-  Bär
-  Baz
-(3 rows)
-~~~
-
-### Specify collations with locale extensions
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE nocase_strings (greeting STRING COLLATE "en-US-u-ks-level2");
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO nocase_strings VALUES ('Hello, friend.' COLLATE "en-US-u-ks-level2"), ('Hi. My name is Petee.' COLLATE "en-US-u-ks-level2");
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM nocase_strings WHERE greeting = ('hi. my name is petee.' COLLATE "en-US-u-ks-level2");
-~~~
-
-~~~
-        greeting
-+-----------------------+
-  Hi. My name is Petee.
-(1 row)
-~~~
-
-### Order by non-default collation
-
-You can sort a column using a specific collation instead of its default.
-
-For example, you receive different results if you order results by German (`de`) and Swedish (`sv`) collations:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM de_names ORDER BY name COLLATE sv;
-~~~
-~~~
-    name
-+----------+
-  Backhaus
-  Baz
-  Bär
-(3 rows)
-~~~
-
-### Ad-hoc collation casting
-
-You can cast any string into a collation on the fly.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT 'A' COLLATE de < 'Ä' COLLATE de;
-~~~
-~~~
-  ?column?
-+----------+
-    true
-(1 row)
-~~~
-
-However, you cannot compare values with different collations:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT 'Ä' COLLATE sv < 'Ä' COLLATE de;
-~~~
-~~~
-pq: unsupported comparison operator: <collatedstring{sv}> < <collatedstring{de}>
-~~~
-
-You can also use casting to remove collations from values.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT CAST(name AS STRING) FROM de_names ORDER BY name;
-~~~
-~~~
-    name
-+----------+
-  Backhaus
-  Baz
-  Bär
-(3 rows)
-~~~
-
-### Show collation for strings
-
-You can use the `pg_collation_for` [built-in function](functions-and-operators.html#string-and-byte-functions), or its alternative [syntax form](functions-and-operators.html#special-syntax-forms) `COLLATION FOR`, to return the locale name of a collated string.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT pg_collation_for('Bär' COLLATE de);
-~~~
-
-~~~
-  pg_collation_for
-+------------------+
-  de
-(1 row)
-~~~
-
-This is equivalent to:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT COLLATION FOR ('Bär' COLLATE de);
-~~~
-
-~~~
-  pg_collation_for
-+------------------+
-  de
-(1 row)
-~~~
-
-## Known limitations
-
-### Collation names that include upper-case or hyphens may cause errors
-
-Using a [collation](collate.html) name with upper-case letters or hyphens may result in errors.
-
-For example, the following SQL will result in an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE nocase_strings (s STRING COLLATE "en-US-u-ks-level2");
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO nocase_strings VALUES ('Aaa' COLLATE "en-US-u-ks-level2"), ('Bbb' COLLATE "en-US-u-ks-level2");
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT s FROM nocase_strings WHERE s = ('bbb' COLLATE "en-US-u-ks-level2");
-~~~
-
-~~~
-ERROR: internal error: "$0" = 'bbb' COLLATE en_us_u_ks_level2: unsupported comparison operator: <collatedstring{en-US-u-ks-level2}> = <collatedstring{en_us_u_ks_level2}>
-~~~
-
-As a workaround, only use collation names that have lower-case letters and underscores.
-
-[Tracking GitHub issue](https://github.com/cockroachdb/cockroach/issues/56335)
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/column-families.md b/src/current/v20.2/column-families.md
deleted file mode 100644
index 6755913b178..00000000000
--- a/src/current/v20.2/column-families.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: Column Families
-summary: A column family is a group of columns in a table that are stored as a single key-value pair in the underlying key-value store.
-toc: true
----
-
-A column family is a group of columns in a table that are stored as a single key-value pair in the [underlying key-value store](architecture/storage-layer.html). Column families reduce the number of keys stored in the key-value store, resulting in improved performance during [`INSERT`](insert.html), [`UPDATE`](update.html), and [`DELETE`](delete.html) operations.
-
-This page explains how CockroachDB organizes columns into families as well as cases in which you might want to manually override the default behavior.
-
- [Secondary indexes](indexes.html) respect the column family definitions applied to tables. When you define a secondary index, CockroachDB breaks the secondary index key-value pairs into column families, according to the family and stored column configurations.
-
-## Default behavior
-
-When a table is created, all columns are stored as a single column family.  
-
-This default approach ensures efficient key-value storage and performance in most cases. However, when frequently updated columns are grouped with seldom updated columns, the seldom updated columns are nonetheless rewritten on every update. Especially when the seldom updated columns are large, it's more performant to split them into a distinct family.
-
-## Manual override
-
-### Assign column families on table creation
-
-To manually assign a column family on [table creation](create-table.html), use the `FAMILY` keyword.  
-
-For example, let's say we want to create a table to store an immutable blob of data (`data BYTES`) with a last accessed timestamp (`last_accessed TIMESTAMP`). Because we know that the blob of data will never get updated, we use the `FAMILY` keyword to break it into a separate column family:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE test (
-    id INT PRIMARY KEY,
-    last_accessed TIMESTAMP,
-    data BYTES,
-    FAMILY f1 (id, last_accessed),
-    FAMILY f2 (data)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE test;
-~~~
-
-~~~
-  table_name |                create_statement
--------------+-------------------------------------------------
-  test       | CREATE TABLE test (
-             |     id INT8 NOT NULL,
-             |     last_accessed TIMESTAMP NULL,
-             |     data BYTES NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     FAMILY f1 (id, last_accessed),
-             |     FAMILY f2 (data)
-             | )
-(1 row)
-~~~
-
-
-### Assign column families when adding columns
-
-When using the [`ALTER TABLE .. ADD COLUMN`](add-column.html) statement to add a column to a table, you can assign the column to a new or existing column family.
-
-- Use the `CREATE FAMILY` keyword to assign a new column to a **new family**. For example, the following would add a `data2 BYTES` column to the `test` table above and assign it to a new column family:
-
-  {% include copy-clipboard.html %}
-  ~~~ sql
-  > ALTER TABLE test ADD COLUMN data2 BYTES CREATE FAMILY f3;
-  ~~~
-
-- Use the `FAMILY` keyword to assign a new column to an **existing family**. For example, the following would add a `name STRING` column to the `test` table above and assign it to family `f1`:
-
-  {% include copy-clipboard.html %}
-  ~~~ sql
-  > ALTER TABLE test ADD COLUMN name STRING FAMILY f1;
-  ~~~
-
-- Use the `CREATE IF NOT EXISTS FAMILY` keyword to assign a new column to an **existing family or, if the family doesn't exist, to a new family**. For example, the following would assign the new column to the existing `f1` family; if that family didn't exist, it would create a new family and assign the column to it:
-
-  {% include copy-clipboard.html %}
-  ~~~ sql
-  > ALTER TABLE test ADD COLUMN name STRING CREATE IF NOT EXISTS FAMILY f1;
-  ~~~
-
-- If a column is added to a table and the family is not specified, it will be added to the first column family. For example, the following would add the new column to the `f1` family, since that is the first column family:
-
-  {% include copy-clipboard.html %}
-  ~~~ sql
-  > ALTER TABLE test ADD COLUMN last_name STRING;
-  ~~~
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [`ADD COLUMN`](add-column.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/comment-on.md b/src/current/v20.2/comment-on.md
deleted file mode 100644
index 410cb6fe20f..00000000000
--- a/src/current/v20.2/comment-on.md
+++ /dev/null
@@ -1,185 +0,0 @@
----
-title: COMMENT ON
-summary: The COMMENT ON statement associates comments to databases, tables, columns, or indexes.
-toc: true
----
-
-The `COMMENT ON` [statement](sql-statements.html) associates comments to [databases](create-database.html), [tables](create-table.html), [columns](add-column.html), or [indexes](indexes.html).
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the object they are commenting on.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/comment.html %}</div>
-
-## Parameters
-
- Parameter | Description
-------------|--------------
-`database_name` | The name of the [database](create-database.html) on which you are commenting.
-`table_name` | The name of the [table](create-table.html) on which you are commenting.
-`column_name` | The name of the [column](add-column.html) on which you are commenting.
-`table_index_name` | The name of the [index](indexes.html) on which you are commenting.
-`comment_text` | The comment ([`STRING`](string.html)) you are associating to the object.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Add a comment to a database
-
-To add a comment to a database:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMENT ON DATABASE movr IS 'This database contains information about users, vehicles, and rides.';
-~~~
-
-To view database comments, use [`SHOW DATABASES`](show-databases.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW DATABASES WITH COMMENT;
-~~~
-
-~~~
-  database_name |                              comment
-+---------------+-------------------------------------------------------------------+
-  defaultdb     | NULL
-  movr          | This database contains information about users, vehicles, and rides.
-  postgres      | NULL
-  system        | NULL
-(4 rows)
-~~~
-
-### Add a comment to a table
-
-To add a comment to a table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMENT ON TABLE vehicles IS 'This table contains information about vehicles registered with MovR.';
-~~~
-
-To view table comments, use [`SHOW TABLES`](show-tables.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr WITH COMMENT;
-~~~
-
-~~~
-          table_name         |                               comment
-+----------------------------+----------------------------------------------------------------------+
-  users                      |
-  vehicles                   | This table contains information about vehicles registered with MovR.
-  rides                      |
-  vehicle_location_histories |
-  promo_codes                |
-  user_promo_codes           |
-(6 rows)
-~~~
-
- You can also view comments on a table with [`SHOW CREATE`](show-create.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE vehicles;
-~~~
-
-~~~
-  table_name |                                          create_statement
--------------+------------------------------------------------------------------------------------------------------
-  vehicles   | CREATE TABLE vehicles (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     type VARCHAR NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     status VARCHAR NULL,
-             |     current_location VARCHAR NULL,
-             |     ext JSONB NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     CONSTRAINT fk_city_ref_users FOREIGN KEY (city, owner_id) REFERENCES users(city, id),
-             |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-             | );
-             | COMMENT ON TABLE vehicles IS 'This table contains information about vehicles registered with MovR.'
-(1 row)
-~~~
-
-### Add a comment to a column
-
-To add a comment to a column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMENT ON COLUMN users.credit_card IS 'This column contains user payment information.';
-~~~
-
-To view column comments, use [`SHOW COLUMNS`](show-columns.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users WITH COMMENT;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden |                    comment
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+------------------------------------------------+
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false   | NULL
-  city        | VARCHAR   |    false    | NULL           |                       | {primary} |   false   | NULL
-  name        | VARCHAR   |    true     | NULL           |                       | {}        |   false   | NULL
-  address     | VARCHAR   |    true     | NULL           |                       | {}        |   false   | NULL
-  credit_card | VARCHAR   |    true     | NULL           |                       | {}        |   false   | This column contains user payment information.
-(5 rows)
-~~~
-
-### Add a comment to an index
-
-Suppose we [create an index](create-index.html) on the `name` column of the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users(name);
-~~~
-
-To add a comment to the index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMENT ON INDEX users_name_idx IS 'This index improves performance on queries that filter by name.';
-~~~
-
-To view column comments, use [`SHOW INDEXES ... WITH COMMENT`](show-index.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM users WITH COMMENT;
-~~~
-
-~~~
-  table_name |   index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit |                             comment
--------------+----------------+------------+--------------+-------------+-----------+---------+----------+------------------------------------------------------------------
-  users      | primary        |   false    |            1 | city        | ASC       |  false  |  false   | NULL
-  users      | primary        |   false    |            2 | id          | ASC       |  false  |  false   | NULL
-  users      | users_name_idx |    true    |            1 | name        | ASC       |  false  |  false   | This index improves performance on queries that filter by name.
-  users      | users_name_idx |    true    |            2 | city        | ASC       |  false  |   true   | This index improves performance on queries that filter by name.
-  users      | users_name_idx |    true    |            3 | id          | ASC       |  false  |   true   | This index improves performance on queries that filter by name.
-  users      | primary        |   false    |            1 | city        | ASC       |  false  |  false   | NULL
-  users      | primary        |   false    |            2 | id          | ASC       |  false  |  false   | NULL
-...
-(15 rows)
-~~~
-
-## See also
-
-- [`CREATE DATABASE`](create-database.html)
-- [`CREATE TABLE`](create-table.html)
-- [`ADD COLUMN`](add-column.html)
-- [`CREATE INDEX`](create-index.html)
-- [`SHOW TABLES`](show-tables.html)
-- [Other SQL Statements](sql-statements.html)
-- [dBeaver](dbeaver.html)
diff --git a/src/current/v20.2/commit-transaction.md b/src/current/v20.2/commit-transaction.md
deleted file mode 100644
index 18eb71ede77..00000000000
--- a/src/current/v20.2/commit-transaction.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: COMMIT
-summary: Commit a transaction with the COMMIT statement in CockroachDB.
-toc: true
----
-
-The `COMMIT` [statement](sql-statements.html) commits the current [transaction](transactions.html) or, when using [advanced client-side transaction retries](advanced-client-side-transaction-retries.html), clears the connection to allow new transactions to begin.
-
-When using [advanced client-side transaction retries](advanced-client-side-transaction-retries.html), statements issued after [`SAVEPOINT`](savepoint.html) are committed when [`RELEASE SAVEPOINT`](release-savepoint.html) is issued instead of `COMMIT`. However, you must still issue a `COMMIT` statement to clear the connection for the next transaction.
-
-For non-retryable transactions, if statements in the transaction [generated any errors](transactions.html#error-handling), `COMMIT` is equivalent to `ROLLBACK`, which aborts the transaction and discards *all* updates made by its statements.
-
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/commit_transaction.html %}</div>
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to commit a transaction. However, privileges are required for each statement within a transaction.
-
-## Aliases
-
-In CockroachDB, `END` is an alias for the `COMMIT` statement.
-
-## Example
-
-### Commit a transaction
-
-How you commit transactions depends on how your application handles [transaction retries](transactions.html#transaction-retries).
-
-#### Client-side retryable transactions
-
-When using [advanced client-side transaction retries](advanced-client-side-transaction-retries.html), statements are committed by [`RELEASE SAVEPOINT`](release-savepoint.html). `COMMIT` itself only clears the connection for the next transaction.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SAVEPOINT cockroach_restart;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE products SET inventory = 0 WHERE sku = '8675309';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders (customer, sku, status) VALUES (1001, '8675309', 'new');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RELEASE SAVEPOINT cockroach_restart;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMIT;
-~~~
-
-{{site.data.alerts.callout_danger}}This example assumes you're using <a href="transactions.html#client-side-intervention">client-side intervention to handle transaction retries</a>.{{site.data.alerts.end}}
-
-#### Automatically retried transactions
-
-If you are using transactions that CockroachDB will [automatically retry](transactions.html#automatic-retries) (i.e., all statements sent in a single batch), commit the transaction with `COMMIT`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN; UPDATE products SET inventory = 100 WHERE = '8675309'; UPDATE products SET inventory = 100 WHERE = '8675310'; COMMIT;
-~~~
-
-## See also
-
-- [Transactions](transactions.html)
-- [`BEGIN`](begin-transaction.html)
-- [`RELEASE SAVEPOINT`](release-savepoint.html)
-- [`ROLLBACK`](rollback-transaction.html)
-- [`SAVEPOINT`](savepoint.html)
-- [`SHOW SAVEPOINT STATUS`](show-savepoint-status.html)
diff --git a/src/current/v20.2/common-errors.md b/src/current/v20.2/common-errors.md
deleted file mode 100644
index c47e03094b9..00000000000
--- a/src/current/v20.2/common-errors.md
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Common Errors
-summary: Understand and resolve common error messages written to stderr or logs.
-toc: false
----
-
-This page helps you understand and resolve error messages written to `stderr` or your [logs](debug-and-error-logs.html).
-
-| Topic                                  | Message                                                                                                                                                                                                                                         
-|----------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-| Client connection                      | [`connection refused`](#connection-refused)                                                                                                                                                                                                     
-| Client connection                      | [`node is running secure mode, SSL connection required`](#node-is-running-secure-mode-ssl-connection-required)                                                                                                                                  
-| Transaction retries                    | [`restart transaction`](#restart-transaction)                                                                                                                                                                                                   
-| Node startup                           | [`node belongs to cluster <cluster ID> but is attempting to connect to a gossip network for cluster <another cluster ID>`](#node-belongs-to-cluster-cluster-id-but-is-attempting-to-connect-to-a-gossip-network-for-cluster-another-cluster-id)
-| Node configuration                     | [`clock synchronization error: this node is more than 500ms away from at least half of the known nodes`](#clock-synchronization-error-this-node-is-more-than-500ms-away-from-at-least-half-of-the-known-nodes)                                  
-| Node configuration                     | [`open file descriptor limit of <number> is under the minimum required <number>`](#open-file-descriptor-limit-of-number-is-under-the-minimum-required-number)                                                                                   
-| Replication                            | [`replicas failing with "0 of 1 store with an attribute matching []; likely not enough nodes in cluster"`](#replicas-failing-with-0-of-1-store-with-an-attribute-matching-likely-not-enough-nodes-in-cluster)                                   
-| Split failed                           | [`split failed while applying backpressure; are rows updated in a tight loop?`](#split-failed-while-applying-backpressure-are-rows-updated-in-a-tight-loop)                                   
-| Deadline exceeded                      | [`context deadline exceeded`](#context-deadline-exceeded)                                                                                                                                                                                       
-| Incremental backups | [`pq: failed to verify protection id...`](#pq-failed-to-verify-protection-id)                                                                                                         
-| Ambiguous results                      | [`result is ambiguous`](#result-is-ambiguous)
-| Import key collision | [`checking for key collisions: ingested key collides with an existing one`](#checking-for-key-collisions-ingested-key-collides-with-an-existing-one)                                                                                                                                                                             
-
-## connection refused
-
-This message indicates a client is trying to connect to a node that is either not running or is not listening on the specified interfaces (i.e., hostname or port).
-
-To resolve this issue, do one of the following:
-
-- If the node hasn't yet been started, [start the node](cockroach-start.html).
-- If you specified a [`--listen-addr` and/or a `--advertise-addr` flag](cockroach-start.html#networking) when starting the node, you must include the specified IP address/hostname and port with all other [`cockroach` commands](cockroach-commands.html) or change the `COCKROACH_HOST` environment variable.
-
-If you're not sure what the IP address/hostname and port values might have been, you can look in the node's [logs](debug-and-error-logs.html). If necessary, you can also terminate the `cockroach` process, and then restart the node:
-
-{% include {{ page.version.version }}/prod-deployment/node-shutdown.md %}
-
-Then restart the node:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start [flags]
-~~~
-
-## node is running secure mode, SSL connection required
-
-This message indicates that the cluster is using TLS encryption to protect network communication, and the client is trying to open a connection without using the required TLS certificates.
-
-To resolve this issue, use the [`cockroach cert create-client`](cockroach-cert.html) command to generate a client certificate and key for the user trying to connect. For a secure deployment walkthrough, including generating security certificates and connecting clients, see [Manual Deployment](manual-deployment.html).
-
-## restart transaction
-
-Messages with the error code `40001` and the string `restart transaction` indicate that a transaction failed because it conflicted with another concurrent or recent transaction accessing the same data. The transaction needs to be retried by the client. For more information about how to implement client-side retries, see [client-side retry handling](transactions.html#client-side-intervention).
-
-For more information about the different types of transaction retry errors such as "retry write too old", "read within uncertainty interval", etc., see the [Transaction Retry Error Reference](transaction-retry-error-reference.html).
-
-## node belongs to cluster \<cluster ID> but is attempting to connect to a gossip network for cluster \<another cluster ID>
-
-This message usually indicates that a node tried to connect to a cluster, but the node is already a member of a different cluster. This is determined by metadata in the node's data directory. To resolve this issue, do one of the following:
-
-- Choose a different directory to store the CockroachDB data:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start [flags] --store=[new directory] --join=[cluster host]:26257
-    ~~~
-
-- Remove the existing directory and start a node joining the cluster again:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -r cockroach-data/
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start [flags] --join=[cluster host]:26257
-    ~~~
-
-## clock synchronization error: this node is more than 500ms away from at least half of the known nodes
-
-This error indicates that a node has spontaneously shut down because it detected that its clock is out of sync with at least half of the other nodes in the cluster by 80% of the maximum offset allowed (500ms by default). CockroachDB requires moderate levels of [clock synchronization](recommended-production-settings.html#clock-synchronization) to preserve data consistency, so the node shutting down in this way avoids the risk of consistency anomalies.
-
-To prevent this from happening, you should run clock synchronization software on each node. For guidance on synchronizing clocks, see the tutorial for your deployment environment:
-
-Environment | Recommended Approach
-------------|---------------------
-[Manual](deploy-cockroachdb-on-premises.html#step-1-synchronize-clocks) | Use NTP with Google's external NTP service.
-[AWS](deploy-cockroachdb-on-aws.html#step-3-synchronize-clocks) | Use the Amazon Time Sync Service.
-[Azure](deploy-cockroachdb-on-microsoft-azure.html#step-3-synchronize-clocks) | Disable Hyper-V time synchronization and use NTP with Google's external NTP service.
-[Digital Ocean](deploy-cockroachdb-on-digital-ocean.html#step-2-synchronize-clocks) | Use NTP with Google's external NTP service.
-[GCE](deploy-cockroachdb-on-google-cloud-platform.html#step-3-synchronize-clocks) | Use NTP with Google's internal NTP service.
-
-## open file descriptor limit of \<number> is under the minimum required \<number>
-
-CockroachDB can use a large number of open file descriptors, often more than is available by default. This message indicates that the machine on which a CockroachDB node is running is under CockroachDB's recommended limits.
-
-For more details on CockroachDB's file descriptor limits and instructions on increasing the limit on various platforms, see [File Descriptors Limit](recommended-production-settings.html#file-descriptors-limit).
-
-## replicas failing with "0 of 1 store with an attribute matching []; likely not enough nodes in cluster
-
-### When running a single-node cluster
-
-When running a single-node CockroachDB cluster, an error about replicas failing will eventually show up in the node's log files, for example:
-
-~~~ shell
-E160407 09:53:50.337328 storage/queue.go:511  [replicate] 7 replicas failing with "0 of 1 store with an attribute matching []; likely not enough nodes in cluster"
-~~~
-
-This happens because CockroachDB expects three nodes by default. If you do not intend to add additional nodes, you can stop this error by using [`ALTER RANGE ... CONFIGURE ZONE`](configure-zone.html) to update your default zone configuration to expect only one node:
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Insecure cluster:
-$ cockroach sql --execute="ALTER RANGE default CONFIGURE ZONE USING num_replicas=1;" --insecure
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Secure cluster:
-$ cockroach sql --execute="ALTER RANGE default CONFIGURE ZONE USING num_replicas=1;" --certs-dir=[path to certs directory]
-~~~
-
-The zone's replica count is reduced to 1. For more information, see [`ALTER RANGE ... CONFIGURE ZONE`](configure-zone.html) and [Configure Replication Zones](configure-replication-zones.html).
-
-### When running a multi-node cluster
-
-When running a multi-node CockroachDB cluster, if you see an error like the one above about replicas failing, some nodes might not be able to talk to each other. For recommended actions, see [Cluster Setup Troubleshooting](cluster-setup-troubleshooting.html#replication-issues).
-
-## split failed while applying backpressure; are rows updated in a tight loop?
-
-In CockroachDB, a table row is stored on disk as a key-value pair. Whenever the row is updated, CockroachDB also stores a distinct version of the key-value pair to enable concurrent request processing while guaranteeing consistency (see [multi-version concurrency control (MVCC)](architecture/storage-layer.html#mvcc)). All versions of a key-value pair belong to a larger ["range"](architecture/overview.html#terms) of the total key space, and the historical versions remain until the garbage collection period defined by the `gc.ttlseconds` variable in the applicable [zone configuration](configure-replication-zones.html#gc-ttlseconds) has passed (25 hours by default). Once a range reaches a size threshold (512 MiB by default), CockroachDB splits the range into two ranges. However, this message indicates that a range cannot be split as intended.
-
-One possible cause is that the range consists only of MVCC version data due to a row being repeatedly updated, and the range cannot be split because doing so would spread MVCC versions for a single row across multiple ranges.
-
-To resolve this issue, make sure you are not repeatedly updating a single row. If frequent updates of a row are necessary, consider one of the following:
-
-- Reduce the `gc.ttlseconds` variable in the applicable [zone configuration](configure-replication-zones.html#gc-ttlseconds) to reduce the garbage collection period and prevent such a large build-up of historical values.
-- If a row contains large columns that are not being updated with other columns, put the large columns in separate [column families](column-families.html).
-
-## context deadline exceeded
-
-This message occurs when a component of CockroachDB gives up because it was relying on another component that has not behaved as expected, for example, another node dropped a network connection. To investigate further, look in the node's logs for the primary failure that is the root cause.
-
-## pq: failed to verify protection id...
-
-Messages that begin with `pq: failed to verify protection id…` indicate that your [incremental backup](take-full-and-incremental-backups.html#incremental-backups) failed because the data you are trying to backup was garbage collected. This happens when incremental backups are taken less frequently than the garbage collection periods for any of the objects in the base backup. For example, if your incremental backups recur daily, but the garbage collection period of one table in your backup is less than one day, all of your incremental backups will fail.
-
-The error message will specify which part of your backup is causing the failure. For example, `r13485:/Table/771` indicates that table `771` is part of the problem. You can then inspect this table by running [`SELECT * FROM crdb_internal.tables WHERE id=771`](select-clause.html). You can also run [`SHOW ZONE CONFIGURATIONS`](show-zone-configurations.html) and look for any `gc.ttlseconds` values that are set lower than your incremental backup frequency.
-
-To resolve this issue, take a new [full backup](take-full-and-incremental-backups.html) after doing either of the following:
-
-- Increase the garbage collection period by [configuring the `gc.ttlseconds` replication zone variable](configure-replication-zones.html#gc-ttlseconds), or
-- [Increase the frequency of incremental backups](manage-a-backup-schedule.html).
-
-## result is ambiguous
-
-In a distributed system, some errors can have ambiguous results. For
-example, if you receive a `connection closed` error while processing a
-`COMMIT` statement, you cannot tell whether the transaction
-successfully committed or not. These errors are possible in any
-database, but CockroachDB is somewhat more likely to produce them than
-other databases because ambiguous results can be caused by failures
-between the nodes of a cluster. These errors are reported with the
-PostgreSQL error code `40003` (`statement_completion_unknown`) and the
-message `result is ambiguous`.
-
-Ambiguous errors can be caused by nodes crashing, network failures, or
-timeouts. If you experience a lot of these errors when things are
-otherwise stable, look for performance issues. Note that ambiguity is
-only possible for the last statement of a transaction (`COMMIT` or
-`RELEASE SAVEPOINT`) or for statements outside a transaction. If a connection drops during a transaction that has not yet tried to commit, the transaction will definitely be aborted.
-
-In general, you should handle ambiguous errors the same way as
-`connection closed` errors. If your transaction is
-[idempotent](https://en.wikipedia.org/wiki/Idempotence#Computer_science_meaning),
-it is safe to retry it on ambiguous errors. `UPSERT` operations are
-typically idempotent, and other transactions can be written to be
-idempotent by verifying the expected state before performing any
-writes. Increment operations such as `UPDATE my_table SET x=x+1 WHERE
-id=$1` are typical examples of operations that cannot easily be made
-idempotent. If your transaction is not idempotent, then you should
-decide whether to retry or not based on whether it would be better for
-your application to apply the transaction twice or return an error to
-the user.
-
-## checking for key collisions: ingested key collides with an existing one
-
-When importing into an existing table with [`IMPORT INTO`](import-into.html), this error occurs because the rows in the import file conflict with an existing primary key or another [`UNIQUE`](unique.html) constraint on the table. The import will fail as a result. `IMPORT INTO` is an insert-only statement, so you cannot use it to update existing rows. To update rows in an existing table, use the [`UPDATE`](update.html) statement.
-
-## Something else?
-
-Try searching the rest of our docs for answers or using our other [support resources](support-resources.html), including:
-
-- [CockroachDB Community Forum](https://forum.cockroachlabs.com)
-- [CockroachDB Community Slack](https://cockroachdb.slack.com)
-- [StackOverflow](http://stackoverflow.com/questions/tagged/cockroachdb)
-- [CockroachDB Support Portal](https://support.cockroachlabs.com)
-- [Transaction retry error reference](transaction-retry-error-reference.html)
diff --git a/src/current/v20.2/common-table-expressions.md b/src/current/v20.2/common-table-expressions.md
deleted file mode 100644
index e4b8b9ef524..00000000000
--- a/src/current/v20.2/common-table-expressions.md
+++ /dev/null
@@ -1,320 +0,0 @@
----
-title: WITH Queries (Common Table Expressions)
-summary: Common table expressions (CTEs) simplify the definition and use of subqueries
-toc: true
----
-
-`WITH` queries, also called *common table expressions* or CTEs, provide a shorthand name to a possibly complex [subquery](subqueries.html) before it is used in a larger query context. This improves the readability of SQL code.
-
-CTEs can be used in combination with [`SELECT` clauses](select-clause.html) and [`INSERT`](insert.html), [`DELETE`](delete.html), [`UPDATE`](update.html) and [`UPSERT`](upsert.html) statements.
-
-
-## Synopsis
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/with_clause.html %}
-</div>
-<div markdown="1"></div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_alias_name` | The name to use to refer to the common table expression from the accompanying query or statement.
-`name` | A name for one of the columns in the newly defined common table expression.
-`preparable_stmt` | The statement or subquery to use as common table expression.
-`MATERIALIZED`/`NOT MATERIALIZED` | <span class="version-tag">New in v20.2:</span> Override the [optimizer](cost-based-optimizer.html)'s decision to materialize (i.e., store the results) of the common table expression. By default, the optimizer materializes the common table expression if it affects other objects in the database, or if it is used in the query multiple times.
-
-## Overview
-
-{{site.data.alerts.callout_info}}
-The examples on this page use MovR, a fictional vehicle-sharing application, to demonstrate CockroachDB SQL statements. To follow along, run [`cockroach demo`](cockroach-demo.html) from the command line to start a temporary, in-memory cluster with the `movr` dataset preloaded.
-
-For more information about the MovR example application and dataset, see [MovR: A Global Vehicle-sharing App](movr.html).
-{{site.data.alerts.end}}
-
-A query or statement of the form `WITH x AS y IN z` creates the
-temporary table name `x` for the results of the subquery `y`, to be
-reused in the context of the query `z`.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH r AS (SELECT * FROM rides WHERE revenue > 98)
-  SELECT * FROM users AS u, r WHERE r.rider_id = u.id;
-~~~
-
-~~~
-                   id                  |     city      |       name       |            address             | credit_card |                  id                  |     city      | vehicle_city  |               rider_id               |              vehicle_id              |           start_address           |        end_address        |        start_time         |         end_time          | revenue
----------------------------------------+---------------+------------------+--------------------------------+-------------+--------------------------------------+---------------+---------------+--------------------------------------+--------------------------------------+-----------------------------------+---------------------------+---------------------------+---------------------------+----------
-  ae147ae1-47ae-4800-8000-000000000022 | amsterdam     | Tyler Dalton     | 88194 Angela Gardens Suite 94  | 4443538758  | bbe76c8b-4395-4000-8000-00000000016f | amsterdam     | amsterdam     | ae147ae1-47ae-4800-8000-000000000022 | aaaaaaaa-aaaa-4800-8000-00000000000a | 45295 Brewer View Suite 52        | 62188 Jade Causeway       | 2018-12-17 03:04:05+00:00 | 2018-12-17 13:04:05+00:00 |   99.00
-  c7ae147a-e147-4000-8000-000000000027 | paris         | Tina Miller      | 97521 Mark Extensions          | 8880478663  | d5810624-dd2f-4800-8000-0000000001a1 | paris         | paris         | c7ae147a-e147-4000-8000-000000000027 | cccccccc-cccc-4000-8000-00000000000c | 47713 Reynolds Mountains Suite 39 | 1417 Stephanie Villages   | 2018-12-17 03:04:05+00:00 | 2018-12-18 22:04:05+00:00 |   99.00
-  75c28f5c-28f5-4400-8000-000000000017 | san francisco | William Wood     | 36021 Steven Cove Apt. 89      | 5669281259  | 8ac08312-6e97-4000-8000-00000000010f | san francisco | san francisco | 75c28f5c-28f5-4400-8000-000000000017 | 77777777-7777-4800-8000-000000000007 | 84407 Tony Crest                  | 55336 Jon Manors          | 2018-12-10 03:04:05+00:00 | 2018-12-11 13:04:05+00:00 |   99.00
-  8a3d70a3-d70a-4000-8000-00000000001b | san francisco | Jessica Martinez | 96676 Jennifer Knolls Suite 91 | 1601930189  | 7d70a3d7-0a3d-4000-8000-0000000000f5 | san francisco | san francisco | 8a3d70a3-d70a-4000-8000-00000000001b | 77777777-7777-4800-8000-000000000007 | 78978 Stevens Ramp Suite 8        | 7340 Alison Field Apt. 44 | 2018-12-19 03:04:05+00:00 | 2018-12-21 10:04:05+00:00 |   99.00
-  47ae147a-e147-4000-8000-00000000000e | washington dc | Patricia Herrera | 80588 Perez Camp               | 6812041796  | 4083126e-978d-4000-8000-00000000007e | washington dc | washington dc | 47ae147a-e147-4000-8000-00000000000e | 44444444-4444-4400-8000-000000000004 | 33055 Julie Dale Suite 93         | 17280 Jill Drives         | 2019-01-01 03:04:05+00:00 | 2019-01-01 14:04:05+00:00 |   99.00
-(5 rows)
-~~~
-
-In this example, the `WITH` clause defines the temporary name `r` for
-the subquery over `rides`, and that name becomes a valid table name
-for use in any [table expression](table-expressions.html) of the
-subsequent `SELECT` clause.
-
-This query is equivalent to, but arguably simpler to read than:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users AS u, (SELECT * FROM rides WHERE revenue > 98) AS r
-  WHERE r.rider_id = u.id;
-~~~
-
-It is also possible to define multiple common table expressions
-simultaneously with a single `WITH` clause, separated by commas. Later
-subqueries can refer to earlier subqueries by name. For example, the
-following query is equivalent to the two examples above:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH r AS (SELECT * FROM rides WHERE revenue > 98),
-	results AS (SELECT * FROM users AS u, r WHERE r.rider_id = u.id)
-  SELECT * FROM results;
-~~~
-
-In this example, the second CTE `results` refers to the first CTE `r`
-by name. The final query refers to the CTE `results`.
-
-## Nested `WITH` clauses
-
-It is possible to use a `WITH` clause in a subquery, or even a `WITH` clause within another `WITH` clause. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH u AS
-	(SELECT * FROM
-		(WITH u_tab AS (SELECT * FROM users) SELECT * FROM u_tab))
-  SELECT * FROM u;
-~~~
-
-When analyzing [table expressions](table-expressions.html) that
-mention a CTE name, CockroachDB will choose the CTE definition that is
-closest to the table expression. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH
-  u AS (SELECT * FROM users),
-  v AS (WITH u AS (SELECT * from vehicles) SELECT * FROM u)
-	SELECT * FROM v;
-~~~
-
-In this example, the inner subquery `SELECT * FROM v` will select from
-table `vehicles` (closest `WITH` clause), not from table `users`.
-
-{{site.data.alerts.callout_info}}
- CockroachDB does not support nested `WITH` clauses containing [data-modifying statements](#data-modifying-statements). `WITH` clauses containing data-modifying statements must be at the top level of the query.
-{{site.data.alerts.end}}
-
-## Data-modifying statements
-
-It is possible to use a [data-modifying statement](sql-statements.html#data-manipulation-statements) (`INSERT`, `DELETE`,
-etc.) as a common table expression, as long as the `WITH` clause containing the data-modifying statement is at the top level of the query.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH final_code AS
-  (INSERT INTO promo_codes(code, description, rules)
-  VALUES ('half_off', 'Half-price ride!', '{"type": "percent_discount", "value": "50%"}'), ('free_ride', 'Free ride!', '{"type": "percent_discount", "value": "100%"}')
-  returning rules)
-  SELECT rules FROM final_code;
-~~~
-
-~~~
-                      rules
-+-----------------------------------------------+
-  {"type": "percent_discount", "value": "50%"}
-  {"type": "percent_discount", "value": "100%"}
-(2 rows)
-~~~
-
-If the `WITH` clause containing the data-modifying statement is at a lower level, the statement results in an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT (WITH final_code AS
-  (INSERT INTO promo_codes(code, description, rules)
-  VALUES ('half_off', 'Half-price ride!', '{"type": "percent_discount", "value": "50%"}'), ('free_ride', 'Free ride!', '{"type": "percent_discount", "value": "100%"}')
-  returning rules)
-  SELECT rules FROM final_code);
-~~~
-
-~~~
-ERROR: WITH clause containing a data-modifying statement must be at the top level
-SQLSTATE: 0A000
-~~~
-
-{{site.data.alerts.callout_info}}
-If a common table expression contains
-a data-modifying statement (<code>INSERT</code>, <code>DELETE</code>,
-etc.), the modifications are performed fully even if only part
-of the results are used, e.g., with <a
-href="limit-offset.html"><code>LIMIT</code></a>. See <a
-href="subqueries.html#data-writes-in-subqueries">Data
-Writes in Subqueries</a> for details.
-{{site.data.alerts.end}}
-
-## Reusing common table expressions
-
-You can reference a CTE multiple times in a single query, using a `WITH` operator.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH
-    users_ny AS (SELECT name, id FROM users WHERE city='new york'),
-    vehicles_ny AS (SELECT type, id, owner_id FROM vehicles WHERE city='new york')
-    SELECT * FROM users_ny JOIN vehicles_ny ON users_ny.id = vehicles_ny.owner_id;
-~~~
-
-~~~
-        name       |                  id                  |    type    |                  id                  |               owner_id
-+------------------+--------------------------------------+------------+--------------------------------------+--------------------------------------+
-  James Hamilton   | 051eb851-eb85-4ec0-8000-000000000001 | skateboard | 00000000-0000-4000-8000-000000000000 | 051eb851-eb85-4ec0-8000-000000000001
-  Catherine Nelson | 147ae147-ae14-4b00-8000-000000000004 | scooter    | 11111111-1111-4100-8000-000000000001 | 147ae147-ae14-4b00-8000-000000000004
-(2 rows)
-~~~
-
-In this single query, you define two CTE's and then reuse them in a table join.
-
-## Recursive common table expressions
-
- CockroachDB supports [recursive common table expressions](https://en.wikipedia.org/wiki/Hierarchical_and_recursive_queries_in_SQL#Common_table_expression). Recursive common table expressions are common table expressions that contain subqueries that refer to their own output.
-
-Recursive CTE definitions take the following form:
-
-~~~ sql
-WITH RECURSIVE <cte name> (<columns>) AS (
-    <initial subquery>
-  UNION ALL
-    <recursive subquery>
-)
-<query>
-~~~
-
-To write a recursive CTE:
-
-1. Add the `RECURSIVE` keyword directly after the `WITH` operator in the CTE definition, and before the CTE name.
-1. Define an initial, non-recursive subquery. This subquery defines the initial values of the CTE.
-1. Add the `UNION ALL` keyword after the initial subquery.
-1. Define a recursive subquery that references its own output. This subquery can also reference the CTE name, unlike the initial subquery.
-1. Write a parent query that evaluates the results of the CTE.
-
-CockroachDB evaluates recursive CTEs as follows:
-
-1. The initial query is evaluated. Its results are stored to rows in the CTE and copied to a temporary, working table. This working table is updated across iterations of the recursive subquery.
-1. The recursive subquery is evaluated iteratively on the contents of the working table. The results of each iteration replace the contents of the working table. The results are also stored to rows of the CTE. The recursive subquery iterates until no results are returned.
-
-{{site.data.alerts.callout_info}}
-Recursive subqueries must eventually return no results, or the query will run indefinitely.
-{{site.data.alerts.end}}
-
-For example, the following recursive CTE calculates the factorial of the numbers 0 through 9:
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH RECURSIVE cte (n, factorial) AS (
-    VALUES (0, 1) -- initial subquery
-  UNION ALL
-    SELECT n+1, (n+1)*factorial FROM cte WHERE n < 9 -- recursive subquery
-)
-SELECT * FROM cte;
-~~~
-
-~~~
-  n | factorial
-+---+-----------+
-  0 |         1
-  1 |         1
-  2 |         2
-  3 |         6
-  4 |        24
-  5 |       120
-  6 |       720
-  7 |      5040
-  8 |     40320
-  9 |    362880
-(10 rows)
-~~~
-
-The initial subquery (`VALUES (0, 1)`) initializes the working table with the values `0` for the `n` column and `1` for the `factorial` column. The recursive subquery (`SELECT n+1, (n+1)*factorial FROM cte WHERE n < 9`) evaluates over the initial values of the working table and replaces its contents with the results. It then iterates over the contents of the working table, replacing its contents at each iteration, until `n` reaches `9`, when the [`WHERE` clause](select-clause.html#filter-rows) evaluates as false.
-
-If no `WHERE` clause were defined in the example, the recursive subquery would always return results and loop indefinitely, resulting in an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH RECURSIVE cte (n, factorial) AS (
-    VALUES (0, 1) -- initial subquery
-  UNION ALL
-    SELECT n+1, (n+1)*factorial FROM cte -- recursive subquery with no WHERE clause
-)
-SELECT * FROM cte;
-~~~
-
-~~~
-ERROR: integer out of range
-SQLSTATE: 22003
-~~~
-
-If you are unsure if your recursive subquery will loop indefinitely, you can limit the results of the CTE with the [`LIMIT`](limit-offset.html) keyword.
-
-For example, if we remove the `WHERE` clause from the factorial example, we can use `LIMIT` to limit the results and avoid the `integer out of range` error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH RECURSIVE cte (n, factorial) AS (
-    VALUES (0, 1) -- initial subquery
-  UNION ALL
-    SELECT n+1, (n+1)*factorial FROM cte -- recursive subquery
-)
-SELECT * FROM cte LIMIT 10;
-~~~
-
-~~~
-  n | factorial
-+---+-----------+
-  0 |         1
-  1 |         1
-  2 |         2
-  3 |         6
-  4 |        24
-  5 |       120
-  6 |       720
-  7 |      5040
-  8 |     40320
-  9 |    362880
-(10 rows)
-~~~
-
-While this practice works for testing and debugging, we do not recommend it in production.
-
-{{site.data.alerts.callout_info}}
-CockroachDB does not currently support the [Postgres recursive CTE variant](https://www.postgresql.org/docs/10/queries-with.html) with the keyword `UNION`.
-{{site.data.alerts.end}}
-
-## Known limitations
-
-### Correlated common table expressions
-
-{% include {{ page.version.version }}/known-limitations/correlated-ctes.md %}
-
-For details, see the [tracking issue](https://github.com/cockroachdb/cockroach/issues/42540).
-
-## See also
-
-- [Subqueries](subqueries.html)
-- [Selection Queries](selection-queries.html)
-- [Table Expressions](table-expressions.html)
-- [`EXPLAIN`](explain.html)
diff --git a/src/current/v20.2/community-tooling.md b/src/current/v20.2/community-tooling.md
deleted file mode 100644
index 1efe8eb31ca..00000000000
--- a/src/current/v20.2/community-tooling.md
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: Third-Party Tools Supported by the Community
-summary: Learn about third-party software that works with CockroachDB.
-toc: true
-docs_area: reference.third_party_support
----
-
-The following tools have been tested or developed by the CockroachDB community, but are not officially supported by Cockroach Labs.
-
-If you encounter problems with using these tools, please contact the maintainer of the tool with details.
-
-{{site.data.alerts.callout_success}}
-If you have a tested or developed a third-party tool with CockroachDB, and would like it listed on this page, please [open a pull request to our docs GitHub repository](https://github.com/cockroachdb/docs/edit/master/v21.2/community-tooling.md).
-{{site.data.alerts.end}}
-
-## Drivers and data access frameworks
-
-### C++
-
-- [libpqxx](https://github.com/cockroachdb/community-tooling-samples/tree/main/cxx)
-
-### Go
-
-- [sqlx](http://jmoiron.github.io/sqlx/)
-
-### Java
-
-- [JDBI](https://jdbi.org/)
-- [clojure.java.jdbc](https://github.com/cockroachdb/community-tooling-samples/tree/main/clojure)
-
-### PHP
-
-- [php-pgsql](https://github.com/cockroachdb/community-tooling-samples/tree/main/php)
-
-### PowerShell
-
-- [Npgsql](https://blog.ervits.com/2020/03/exploring-cockroachdb-with-jupyter.html)
-
-### R
-
-- [RPostgres](https://blog.ervits.com/2020/02/exploring-cockroachdb-with-r-and.html)
-
-### Other
-
-- [Apache Hop (Incubating)](https://hop.apache.org)
-
-## Visualization tools
-
-- [Beekeeper Studio](https://www.beekeeperstudio.io/db/cockroachdb-client/)
-- [DbVisualizer](https://www.cdata.com/kb/tech/cockroachdb-jdbc-dbv.rst)
-- [Navicat for PostgreSQL](https://www.navicat.com/en/products/navicat-for-postgresql)/[Navicat Premium](https://www.navicat.com/en/products/navicat-premium)
-- [Pgweb](http://sosedoff.github.io/pgweb/)
-- [Postico](https://eggerapps.at/postico/)
-- [TablePlus](https://tableplus.com/blog/2018/06/best-cockroachdb-gui-client-tableplus.html)
-
-## Schema migration tools
-
-- [SchemaHero](https://schemahero.io/databases/cockroachdb/connecting/)
-- [DbUp](https://github.com/DbUp/DbUp/issues/464#issuecomment-895503849)
-- [golang-migrate](https://github.com/golang-migrate/migrate/tree/master/database/cockroachdb)
-- [db-migrate](https://db-migrate.readthedocs.io/en/latest/)
-
-## Connection pooling tools
-
-- [PGBouncer](https://dzone.com/articles/using-pgbouncer-with-cockroachdb)
-
-## IAM tools
-
-- [Vault](https://www.vaultproject.io/docs/configuration/storage/cockroachdb)
-
-## See also
-
-- [Build an App with CockroachDB](example-apps.html)
-- [Install a Postgres Client](install-client-drivers.html)
-- [Third-Party Tools Supported by Cockroach Labs](third-party-database-tools.html)
diff --git a/src/current/v20.2/computed-columns.md b/src/current/v20.2/computed-columns.md
deleted file mode 100644
index a19e4bb31bd..00000000000
--- a/src/current/v20.2/computed-columns.md
+++ /dev/null
@@ -1,86 +0,0 @@
----
-title: Use Computed Columns
-summary: A computed column stores data generated by an expression included in the column definition.
-toc: true
----
-
-A computed column stores data generated from other columns by a [scalar expression](scalar-expressions.html) included in the column definition.
-
-
-## Why use computed columns?
-
-Computed columns are especially useful when used with [partitioning](partitioning.html), [`JSONB`](jsonb.html) columns, or [secondary indexes](indexes.html).
-
-- **Partitioning** requires that partitions are defined using columns that are a prefix of the [primary key](primary-key.html). In the case of geo-partitioning, some applications will want to collapse the number of possible values in this column, to make certain classes of queries more performant. For example, if a users table has a country and state column, then you can make a stored computed column locality with a reduced domain for use in partitioning. For more information, see the [partitioning example](#create-a-table-with-geo-partitions-and-a-computed-column) below.
-
-- **JSONB** columns are used for storing semi-structured `JSONB` data. When the table's primary information is stored in `JSONB`, it's useful to index a particular field of the `JSONB` document. In particular, computed columns allow for the following use case: a two-column table with a `PRIMARY KEY` column and a `payload` column, whose primary key is computed as some field from the `payload` column. This alleviates the need to manually separate your primary keys from your JSON blobs. For more information, see the [`JSONB` example](#create-a-table-with-a-jsonb-column-and-a-computed-column) below.
-
-- **Secondary indexes** can be created on computed columns, which is especially useful when a table is frequently sorted. See the [secondary indexes example](#create-a-table-with-a-secondary-index-on-a-computed-column) below.
-
-## Considerations
-
-Computed columns:
-
-- Cannot be used to generate other computed columns.
-- Cannot be a [foreign key](foreign-key.html) reference.
-- Behave like any other column, with the exception that they cannot be written to directly.
-- Are mutually exclusive with [`DEFAULT`](default-value.html).
-
-Once a computed column is created, you cannot directly alter the formula. To make modifications to a computed column's formula, see the [example](#alter-the-formula-for-a-computed-column) below.
-
-## Creation
-
-To define a computed column, use the following syntax:
-
-~~~
-column_name <type> AS (<expr>) STORED
-~~~
-
-Parameter | Description
-----------|------------
-`column_name` | The [name/identifier](keywords-and-identifiers.html#identifiers) of the computed column.
-`<type>` | The [data type](data-types.html) of the computed column.
-`<expr>` | The pure [scalar expression](scalar-expressions.html) used to compute column values. Any functions marked as `impure`, such as `now()` or `nextval()` cannot be used.
-`STORED` | _(Required)_ The computed column is stored alongside other columns.
-
-<span class="version-tag">New in v20.2</span>: For compatibility with PostgresSQL, CockroachDB also supports creating computed columns with the syntax `column_name <type> GENERATED ALWAYS AS (<expr>) STORED`.
-
-## Examples
-
-### Create a table with a computed column
-
-{% include {{ page.version.version }}/computed-columns/simple.md %}
-
-### Create a table with geo-partitions and a computed column
-
-{% include {{ page.version.version }}/computed-columns/partitioning.md %} The `locality` values can then be used for geo-partitioning.
-
-### Create a table with a `JSONB` column and a computed column
-
-{% include {{ page.version.version }}/computed-columns/jsonb.md %}
-
-### Create a table with a secondary index on a computed column
-
-{% include {{ page.version.version }}/computed-columns/secondary-index.md %}
-
-### Add a computed column to an existing table
-
-{% include {{ page.version.version }}/computed-columns/add-computed-column.md %}
-
-For more information, see [`ADD COLUMN`](add-column.html).
-
-### Convert a computed column into a regular column
-
-{% include {{ page.version.version }}/computed-columns/convert-computed-column.md %}
-
-### Alter the formula for a computed column
-
-{% include {{ page.version.version }}/computed-columns/alter-computed-column.md %}
-
-## See also
-
-- [Scalar Expressions](scalar-expressions.html)
-- [Information Schema](information-schema.html)
-- [`CREATE TABLE`](create-table.html)
-- [`JSONB`](jsonb.html)
-- [Define Table Partitions (Enterprise)](partitioning.html)
diff --git a/src/current/v20.2/configure-replication-zones.md b/src/current/v20.2/configure-replication-zones.md
deleted file mode 100644
index 2763093c669..00000000000
--- a/src/current/v20.2/configure-replication-zones.md
+++ /dev/null
@@ -1,693 +0,0 @@
----
-title: Configure Replication Zones
-summary: In CockroachDB, you use replication zones to control the number and location of replicas for specific sets of data.
-keywords: ttl, time to live, availability zone
-toc: true
----
-
-Replication zones give you the power to control what data goes where in your CockroachDB cluster.  Specifically, they are used to control the number and location of replicas for data belonging to the following objects:
-
-- Databases
-- Tables
-- Rows ([Enterprise-only](enterprise-licensing.html))
-- Indexes ([Enterprise-only](enterprise-licensing.html))
-- All data in the cluster, including internal system data ([via the default replication zone](#view-the-default-replication-zone))
-
-For each of the above objects you can control:
-
-- How many copies of each range to spread through the cluster.
-- Which constraints are applied to which data, e.g., "table X's data can only be stored in the German availability zones".
-- The maximum size of ranges (how big ranges get before they are split).
-- How long old data is kept before being garbage collected.
-- Where you would like the leaseholders for certain ranges to be located, e.g., "for ranges that are already constrained to have at least one replica in `region=us-west`, also try to put their leaseholders in `region=us-west`".
-
-This page explains how replication zones work and how to use the [`CONFIGURE ZONE`](configure-zone.html) statement to manage them.
-
-{{site.data.alerts.callout_info}}
-To configure replication zones, a user must be a member of the [`admin` role](authorization.html#admin-role) or have been granted [`CREATE`](authorization.html#supported-privileges) or [`ZONECONFIG`](authorization.html#supported-privileges) privileges. To configure [`system` objects](#for-system-data), the user must be a member of the `admin` role.
-{{site.data.alerts.end}}
-
-## Overview
-
-Every [range](architecture/overview.html#glossary) in the cluster is part of a replication zone.  Each range's zone configuration is taken into account as ranges are rebalanced across the cluster to ensure that any constraints are honored.
-
-When a cluster starts, there are two categories of replication zone:
-
-1. Pre-configured replication zones that apply to internal system data.
-2. A single default replication zone that applies to the rest of the cluster.
-
-You can adjust these pre-configured zones as well as add zones for individual databases, tables, rows, and secondary indexes as needed.  Note that adding zones for rows and secondary indexes is [Enterprise-only](enterprise-licensing.html).
-
-For example, you might rely on the [default zone](#view-the-default-replication-zone) to spread most of a cluster's data across all of your availability zones, but [create a custom replication zone for a specific database](#create-a-replication-zone-for-a-database) to make sure its data is only stored in certain availability zones and/or geographies.
-
-## Replication zone levels
-
-There are five replication zone levels for [**table data**](architecture/distribution-layer.html#table-data) in a cluster, listed from least to most granular:
-
-Level | Description
-------|------------
-Cluster | CockroachDB comes with a pre-configured `default` replication zone that applies to all table data in the cluster not constrained by a database, table, or row-specific replication zone. This zone can be adjusted but not removed. See [View the Default Replication Zone](#view-the-default-replication-zone) and [Edit the Default Replication Zone](#edit-the-default-replication-zone) for more details.
-Database | You can add replication zones for specific databases. See [Create a Replication Zone for a Database](#create-a-replication-zone-for-a-database) for more details.
-Table | You can add replication zones for specific tables. See [Create a Replication Zone for a Table](#create-a-replication-zone-for-a-table).
-Index ([Enterprise-only](enterprise-licensing.html)) | The [secondary indexes](indexes.html) on a table will automatically use the replication zone for the table. However, with an Enterprise license, you can add distinct replication zones for secondary indexes. See [Create a Replication Zone for a Secondary Index](#create-a-replication-zone-for-a-secondary-index) for more details.
-Row ([Enterprise-only](enterprise-licensing.html)) | You can add replication zones for specific rows in a table or secondary index by [defining table partitions](partitioning.html). See [Create a Replication Zone for a Table Partition](#create-a-replication-zone-for-a-partition) for more details.
-
-### For system data
-
-In addition, CockroachDB stores internal [**system data**](architecture/distribution-layer.html#monolithic-sorted-map-structure) in what are called system ranges. There are two replication zone levels for this internal system data, listed from least to most granular:
-
-Level | Description
-------|------------
-Cluster | The `default` replication zone mentioned above also applies to all system ranges not constrained by a more specific replication zone.
-System Range | CockroachDB comes with pre-configured replication zones for important system ranges, such as the "meta" and "liveness" ranges. If necessary, you can add replication zones for the "timeseries" range and other system ranges as well. Editing replication zones for system ranges may override settings from `default`. See [Create a Replication Zone for a System Range](#create-a-replication-zone-for-a-system-range) for more details.<br><br>CockroachDB also comes with pre-configured replication zones for the internal `system` database and the `system.jobs` table, which stores metadata about long-running jobs such as schema changes and backups.
-
-### Level priorities
-
-When replicating data, whether table or system, CockroachDB always uses the most granular replication zone available. For example, for a piece of user data:
-
-1. If there's a replication zone for the row, CockroachDB uses it.
-2. If there's no applicable row replication zone and the row is from a secondary index, CockroachDB uses the secondary index replication zone.
-3. If the row isn't from a secondary index or there is no applicable secondary index replication zone, CockroachDB uses the table replication zone.
-4. If there's no applicable table replication zone, CockroachDB uses the database replication zone.
-5. If there's no applicable database replication zone, CockroachDB uses the `default` cluster-wide replication zone.
-
-## Manage replication zones
-
-Use the [`CONFIGURE ZONE`](configure-zone.html) statement to [add](#create-a-replication-zone-for-a-system-range), [modify](#edit-the-default-replication-zone), [reset](#reset-a-replication-zone), and [remove](#remove-a-replication-zone) replication zones.
-
-### Replication zone variables
-
-Use the [`ALTER ... CONFIGURE ZONE`](configure-zone.html) [statement](sql-statements.html) to set a replication zone:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE t CONFIGURE ZONE USING range_min_bytes = 0, range_max_bytes = 90000, gc.ttlseconds = 89999, num_replicas = 5, constraints = '[-region=west]';
-~~~
-
-{% include {{page.version.version}}/zone-configs/variables.md %}
-
-### Replication constraints
-
-The location of replicas, both when they are first added and when they are rebalanced to maintain cluster equilibrium, is based on the interplay between descriptive attributes assigned to nodes and constraints set in zone configurations.
-
-{{site.data.alerts.callout_success}}For demonstrations of how to set node attributes and replication constraints in different scenarios, see <a href="#scenario-based-examples">Scenario-based Examples</a> below.{{site.data.alerts.end}}
-
-#### Descriptive attributes assigned to nodes
-
-When starting a node with the [`cockroach start`](cockroach-start.html) command, you can assign the following types of descriptive attributes:
-
-Attribute Type | Description
----------------|------------
-**Node Locality** | <a name="zone-config-node-locality"></a> Using the [`--locality`](cockroach-start.html#locality) flag, you can assign arbitrary key-value pairs that describe the location of the node. Locality might include region, country, availability zone, etc. The key-value pairs should be ordered into _locality tiers_ that range from most inclusive to least inclusive (e.g., region before availability zone as in `region=eu,az=paris`), and the keys and the order of key-value pairs must be the same on all nodes. It's typically better to include more pairs than fewer. For example:<br><br>`--locality=region=east,az=us-east-1`<br>`--locality=region=east,az=us-east-2`<br>`--locality=region=west,az=us-west-1`<br><br>CockroachDB attempts to spread replicas evenly across the cluster based on locality, with the order of locality tiers determining the priority. Locality can also be used to influence the location of data replicas in various ways using replication zones.<br><br>When there is high latency between nodes, CockroachDB uses locality to move range leases closer to the current workload, reducing network round trips and improving read performance. See [Follow-the-workload](topology-follow-the-workload.html) for more details.
-**Node Capability** | Using the `--attrs` flag, you can specify node capability, which might include specialized hardware or number of cores, for example:<br><br>`--attrs=ram:64gb`
-**Store Type/Capability** | Using the `attrs` field of the `--store` flag, you can specify disk type or capability, for example:<br><br>`--store=path=/mnt/ssd01,attrs=ssd`<br>`--store=path=/mnt/hda1,attrs=hdd:7200rpm`
-
-#### Types of constraints
-
-The node-level and store-level descriptive attributes mentioned above can be used as the following types of constraints in replication zones to influence the location of replicas. However, note the following general guidance:
-
-- When locality is the only consideration for replication, it's recommended to set locality on nodes without specifying any constraints in zone configurations. In the absence of constraints, CockroachDB attempts to spread replicas evenly across the cluster based on locality.
-- Required and prohibited constraints are useful in special situations where, for example, data must or must not be stored in a specific country or on a specific type of machine.
-- Avoid conflicting constraints. CockroachDB returns an error if you:
-    - Redefine a required constraint key within the same `constraints` definition on all replicas. For example, `constraints = '[+region=west, +region=east]'` will result in an error.
-    - Define a required and prohibited definition for the same key-value pair. For example, `constraints = '[-region=west, +region=west]'` will result in an error.
-
-Constraint Type | Description | Syntax
-----------------|-------------|-------
-**Required** | When placing replicas, the cluster will consider only nodes/stores with matching attributes or localities. When there are no matching nodes/stores, new replicas will not be added. | `+ssd`
-**Prohibited** | When placing replicas, the cluster will ignore nodes/stores with matching attributes or localities. When there are no alternate nodes/stores, new replicas will not be added. | `-ssd`
-
-#### Scope of constraints
-
-Constraints can be specified such that they apply to all replicas in a zone or such that different constraints apply to different replicas, meaning you can effectively pick the exact location of each replica.
-
-Constraint Scope | Description | Syntax
------------------|-------------|-------
-**All Replicas** | Constraints specified using JSON array syntax apply to all replicas in every range that's part of the replication zone. | `constraints = '[+ssd, -region=west]'`
-**Per-Replica** | Multiple lists of constraints can be provided in a JSON object, mapping each list of constraints to an integer number of replicas in each range that the constraints should apply to.<br><br>The total number of replicas constrained cannot be greater than the total number of replicas for the zone (`num_replicas`). However, if the total number of replicas constrained is less than the total number of replicas for the zone, the non-constrained replicas will be allowed on any nodes/stores.<br><br>Note that per-replica constraints must be "required" (e.g., `'{"+region=west": 1}'`); they cannot be "prohibited" (e.g., `'{"-region=west": 1}'`). Also, when defining per-replica constraints on a database or table, `num_replicas` must be specified as well, but not when defining per-replica constraints on an index or partition.<br><br>See the [Per-replica constraints](#per-replica-constraints-to-specific-availability-zones) example for more details. | `constraints = '{"+ssd,+region=west": 2, "+region=east": 1}', num_replicas = 3`
-
-### Node/replica recommendations
-
-See [Cluster Topography](recommended-production-settings.html#topology) recommendations for production deployments.
-
-### Troubleshooting zone constraint violations
-
-To see if any of the data placement constraints defined in your replication zone configurations are being violated, use the `system.replication_constraint_stats` report as described in [Replication Reports](query-replication-reports.html).
-
-## View replication zones
-
-Use the [`SHOW ZONE CONFIGURATIONS`](#view-all-replication-zones) statement to view details about existing replication zones.
-
-You can also use the [`SHOW PARTITIONS`](show-partitions.html) statement to view the zone constraints on existing table partitions, or [`SHOW CREATE TABLE`](show-create.html) to view zone configurations for a table.
-
-{% include {{page.version.version}}/sql/crdb-internal-partitions.md %}
-
-## Basic examples
-
-{% include {{ page.version.version }}/sql/movr-statements-geo-partitioned-replicas.md %}
-
-These examples focus on the basic approach and syntax for working with zone configuration. For examples demonstrating how to use constraints, see [Scenario-based examples](#scenario-based-examples).
-
-For more examples, see [`CONFIGURE ZONE`](configure-zone.html) and [`SHOW ZONE CONFIGURATIONS`](show-zone-configurations.html).
-
-### View all replication zones
-
-{% include {{ page.version.version }}/zone-configs/view-all-replication-zones.md %}
-
-For more information, see [`SHOW ZONE CONFIGURATIONS`](show-zone-configurations.html).
-
-### View the default replication zone
-
-{% include {{ page.version.version }}/zone-configs/view-the-default-replication-zone.md %}
-
-For more information, see [`SHOW ZONE CONFIGURATIONS`](show-zone-configurations.html).
-
-### Edit the default replication zone
-
-{% include {{ page.version.version }}/zone-configs/edit-the-default-replication-zone.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-### Create a replication zone for a system range
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-system-range.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-### Create a replication zone for a database
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-database.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-### Create a replication zone for a table
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-table.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-### Create a replication zone for a secondary index
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-secondary-index.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-### Create a replication zone for a partition
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-table-partition.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-### Reset a replication zone
-
-{% include {{ page.version.version }}/zone-configs/reset-a-replication-zone.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-### Remove a replication zone
-
-{% include {{ page.version.version }}/zone-configs/remove-a-replication-zone.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-### Constrain leaseholders to specific availability zones
-
-{% include {{ page.version.version }}/zone-configs/constrain-leaseholders-to-specific-datacenters.md %}
-
-For more information, see [`CONFIGURE ZONE`](configure-zone.html).
-
-## Scenario-based examples
-
-### Even replication across availability zones
-
-**Scenario:**
-
-- You have 6 nodes across 3 availability zones, 2 nodes in each availability zone.
-- You want data replicated 3 times, with replicas balanced evenly across all three availability zones.
-
-**Approach:**
-
-1. Start each node with its availability zone location specified in the [`--locality`](cockroach-start.html#locality) flag:
-
-    Availability zone 1:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node1 hostname> --locality=az=us-1 \
-    --join=<node1 hostname>,<node3 hostname>,<node5 hostname>
-    $ cockroach start --insecure --advertise-addr=<node2 hostname> --locality=az=us-1 \
-    --join=<node1 hostname>,<node3 hostname>,<node5 hostname>
-    ~~~
-
-    Availability zone 2:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node3 hostname> --locality=az=us-2 \
-    --join=<node1 hostname>,<node3 hostname>,<node5 hostname>
-    $ cockroach start --insecure --advertise-addr=<node4 hostname> --locality=az=us-2 \
-    --join=<node1 hostname>,<node3 hostname>,<node5 hostname>
-    ~~~
-
-    Availability zone 3:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node5 hostname> --locality=az=us-3 \
-    --join=<node1 hostname>,<node3 hostname>,<node5 hostname>
-    $ cockroach start --insecure --advertise-addr=<node6 hostname> --locality=az=us-3 \
-    --join=<node1 hostname>,<node3 hostname>,<node5 hostname>
-    ~~~
-
-2. Initialize the cluster:
-
-    ~~~ shell
-    $ cockroach init --insecure --host=<any node hostname>
-    ~~~
-
-There's no need to make zone configuration changes; by default, the cluster is configured to replicate data three times, and even without explicit constraints, the cluster will aim to diversify replicas across node localities.
-
-### Per-replica constraints to specific availability zones
-
-**Scenario:**
-
-- You have 5 nodes across 5 availability zones in 3 regions, 1 node in each availability zone.
-- You want data replicated 3 times, with a quorum of replicas for a database holding West Coast data centered on the West Coast and a database for nation-wide data replicated across the entire country.
-
-**Approach:**
-
-1. Start each node with its region and availability zone location specified in the [`--locality`](cockroach-start.html#locality) flag:
-
-    Start the five nodes:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node1 hostname> --locality=region=us-west1,az=us-west1-a \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>
-    $ cockroach start --insecure --advertise-addr=<node2 hostname> --locality=region=us-west1,az=us-west1-b \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>
-    $ cockroach start --insecure --advertise-addr=<node3 hostname> --locality=region=us-central1,az=us-central1-a \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>
-    $ cockroach start --insecure --advertise-addr=<node4 hostname> --locality=region=us-east1,az=us-east1-a \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>
-    $ cockroach start --insecure --advertise-addr=<node5 hostname> --locality=region=us-east1,az=us-east1-b \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>
-    ~~~
-
-    Initialize the cluster:
-
-    ~~~ shell
-    $ cockroach init --insecure --host=<any node hostname>
-    ~~~
-
-2. On any node, open the [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-3. Create the database for the West Coast application:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE west_app_db;
-    ~~~
-
-4. Configure a replication zone for the database:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER DATABASE west_app_db
-    CONFIGURE ZONE USING constraints = '{"+region=us-west1": 2, "+region=us-central1": 1}', num_replicas = 3;
-    ~~~
-
-    ~~~
-    CONFIGURE ZONE 1
-    ~~~
-
-5. View the replication zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ZONE CONFIGURATION FOR DATABASE west_app_db;
-    ~~~
-
-    ~~~
-             target        |                           raw_config_sql
-    +----------------------+--------------------------------------------------------------------+
-      DATABASE west_app_db | ALTER DATABASE west_app_db CONFIGURE ZONE USING
-                           |     range_min_bytes = 134217728,
-                           |     range_max_bytes = 536870912,
-                           |     gc.ttlseconds = 90000,
-                           |     num_replicas = 3,
-                           |     constraints = '{+region=us-central1: 1, +region=us-west1: 2}',
-                           |     lease_preferences = '[]'
-    (1 row)
-    ~~~
-
-    Two of the database's three replicas will be put in `region=us-west1` and its remaining replica will be put in `region=us-central1`. This gives the application the resilience to survive the total failure of any one availability zone while providing low-latency reads and writes on the West Coast because a quorum of replicas are located there.
-
-6. No configuration is needed for the nation-wide database. The cluster is configured to replicate data 3 times and spread them as widely as possible by default. Because the first key-value pair specified in each node's locality is considered the most significant part of each node's locality, spreading data as widely as possible means putting one replica in each of the three different regions.
-
-### Multiple applications writing to different databases
-
-**Scenario:**
-
-- You have 2 independent applications connected to the same CockroachDB cluster, each application using a distinct database.
-- You have 6 nodes across 2 availability zones, 3 nodes in each availability zone.
-- You want the data for application 1 to be replicated 5 times, with replicas evenly balanced across both availability zones.
-- You want the data for application 2 to be replicated 3 times, with all replicas in a single availability zone.
-
-**Approach:**
-
-1. Start each node with its availability zone location specified in the [`--locality`](cockroach-start.html#locality) flag:
-
-    Availability zone 1:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node1 hostname> --locality=az=us-1 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>,<node6 hostname>
-    $ cockroach start --insecure --advertise-addr=<node2 hostname> --locality=az=us-1 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>,<node6 hostname>
-    $ cockroach start --insecure --advertise-addr=<node3 hostname> --locality=az=us-1 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>,<node6 hostname>
-    ~~~
-
-    Availability zone 2:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node4 hostname> --locality=az=us-2 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>,<node6 hostname>
-    $ cockroach start --insecure --advertise-addr=<node5 hostname> --locality=az=us-2 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>,<node6 hostname>
-    $ cockroach start --insecure --advertise-addr=<node6 hostname> --locality=az=us-2 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>,<node4 hostname>,<node5 hostname>,<node6 hostname>
-    ~~~
-
-    Initialize the cluster:
-
-    ~~~ shell
-    $ cockroach init --insecure --host=<any node hostname>
-    ~~~
-
-2. On any node, open the [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-3. Create the database for application 1:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE app1_db;
-    ~~~
-
-4. Configure a replication zone for the database used by application 1:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER DATABASE app1_db CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-    ~~~
-    CONFIGURE ZONE 1
-    ~~~
-
-5. View the replication zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ZONE CONFIGURATION FOR DATABASE app1_db;
-    ~~~
-
-    ~~~
-           target      |               raw_config_sql
-    +------------------+---------------------------------------------+
-      DATABASE app1_db | ALTER DATABASE app1_db CONFIGURE ZONE USING
-                       |     range_min_bytes = 134217728,
-                       |     range_max_bytes = 536870912,
-                       |     gc.ttlseconds = 90000,
-                       |     num_replicas = 5,
-                       |     constraints = '[]',
-                       |     lease_preferences = '[]'
-    (1 row)
-    ~~~
-
-    Nothing else is necessary for application 1's data. Since all nodes specify their availability zone locality, the cluster will aim to balance the data in the database used by application 1 between availability zones 1 and 2.
-
-6. Still in the SQL client, create a database for application 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE app2_db;
-    ~~~
-
-7. Configure a replication zone for the database used by application 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER DATABASE app2_db CONFIGURE ZONE USING constraints = '[+az=us-2]';
-    ~~~
-
-8. View the replication zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ZONE CONFIGURATION FOR DATABASE app2_db;
-    ~~~
-
-    ~~~
-           target      |               raw_config_sql
-    +------------------+---------------------------------------------+
-      DATABASE app2_db | ALTER DATABASE app2_db CONFIGURE ZONE USING
-                       |     range_min_bytes = 134217728,
-                       |     range_max_bytes = 536870912,
-                       |     gc.ttlseconds = 90000,
-                       |     num_replicas = 3,
-                       |     constraints = '[+az=us-2]',
-                       |     lease_preferences = '[]'
-    (1 row)
-    ~~~
-
-    The required constraint will force application 2's data to be replicated only within the `us-2` availability zone.
-
-### Stricter replication for a table and its secondary indexes
-
-**Scenario:**
-
-- You have 7 nodes, 5 with SSD drives and 2 with HDD drives.
-- You want data replicated 3 times by default.
-- Speed and availability are important for a specific table and its indexes, which are queried very frequently, however, so you want the data in the table and secondary indexes to be replicated 5 times, preferably on nodes with SSD drives.
-
-**Approach:**
-
-1. Start each node with `ssd` or `hdd` specified as store attributes:
-
-    5 nodes with SSD storage:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node1 hostname> --store=path=node1,attrs=ssd \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node2 hostname> --store=path=node2,attrs=ssd \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node3 hostname> --store=path=node3,attrs=ssd \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node4 hostname> --store=path=node4,attrs=ssd \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node5 hostname> --store=path=node5,attrs=ssd \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    ~~~
-
-    2 nodes with HDD storage:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node6 hostname> --store=path=node6,attrs=hdd \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node7 hostname> --store=path=node7,attrs=hdd \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    ~~~
-
-    Initialize the cluster:
-
-    ~~~ shell
-    $ cockroach init --insecure --host=<any node hostname>
-    ~~~
-
-2. On any node, open the [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-3. Create a database and table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE db;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE db.important_table;
-    ~~~
-
-4. Configure a replication zone for the table that must be replicated more strictly:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE db.important_table CONFIGURE ZONE USING num_replicas = 5, constraints = '[+ssd]'
-    ~~~
-
-5. View the replication zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ZONE CONFIGURATION FOR TABLE db.important_table;
-    ~~~
-
-    ~~~
-                 target             |                config_sql
-    +-------------------------------+---------------------------------------------+
-         TABLE db.important_table   | ALTER DATABASE app2_db CONFIGURE ZONE USING
-                                    |     range_min_bytes = 1048576,
-                                    |     range_max_bytes = 536870912,
-                                    |     gc.ttlseconds = 90000,
-                                    |     num_replicas = 5,
-                                    |     constraints = '[+ssd]',
-                                    |     lease_preferences = '[]'
-    (1 row)
-    ~~~
-
-    The secondary indexes on the table will use the table's replication zone, so all data for the table will be replicated 5 times, and the required constraint will place the data on nodes with `ssd` drives.
-
-### Tweaking the replication of system ranges
-
-**Scenario:**
-
-- You have nodes spread across 7 availability zones.
-- You want data replicated 5 times by default.
-- For better performance, you want a copy of the meta ranges in all of the availability zones.
-- To save disk space, you only want the internal timeseries data replicated 3 times by default.
-
-**Approach:**
-
-1. Start each node with a different [locality](cockroach-start.html#locality) attribute:
-
-    ~~~ shell
-    $ cockroach start --insecure --advertise-addr=<node1 hostname> --locality=az=us-1 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>   
-    $ cockroach start --insecure --advertise-addr=<node2 hostname> --locality=az=us-2 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node3 hostname> --locality=az=us-3 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node4 hostname> --locality=az=us-4 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node5 hostname> --locality=az=us-5 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node6 hostname> --locality=az=us-6 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    $ cockroach start --insecure --advertise-addr=<node7 hostname> --locality=az=us-7 \
-    --join=<node1 hostname>,<node2 hostname>,<node3 hostname>
-    ~~~
-
-    Initialize the cluster:
-
-    ~~~ shell
-    $ cockroach init --insecure --host=<any node hostname>
-    ~~~
-
-2. On any node, open the [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-3. Configure the default replication zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE default CONFIGURE ZONE USING num_replicas = 5;
-    ~~~
-
-4. View the replication zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ZONE CONFIGURATION FOR RANGE default;
-    ~~~
-    ~~~
-         target     |              raw_config_sql
-    +---------------+------------------------------------------+
-      RANGE default | ALTER RANGE default CONFIGURE ZONE USING
-                    |     range_min_bytes = 134217728,
-                    |     range_max_bytes = 536870912,
-                    |     gc.ttlseconds = 90000,
-                    |     num_replicas = 5,
-                    |     constraints = '[]',
-                    |     lease_preferences = '[]'
-    (1 row)
-    ~~~
-
-    All data in the cluster will be replicated 5 times, including both SQL data and the internal system data.
-
-5. Configure the `meta` replication zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE meta CONFIGURE ZONE USING num_replicas = 7;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ZONE CONFIGURATION FOR RANGE meta;
-    ~~~
-    ~~~
-        target   |            raw_config_sql
-    +------------+---------------------------------------+
-      RANGE meta | ALTER RANGE meta CONFIGURE ZONE USING
-                 |     range_min_bytes = 134217728,
-                 |     range_max_bytes = 536870912,
-                 |     gc.ttlseconds = 3600,
-                 |     num_replicas = 7,
-                 |     constraints = '[]',
-                 |     lease_preferences = '[]'
-    (1 row)
-    ~~~
-
-    The `meta` addressing ranges will be replicated such that one copy is in all 7 availability zones, while all other data will be replicated 5 times.
-
-6. Configure the `timeseries` replication zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER RANGE timeseries CONFIGURE ZONE USING num_replicas = 3;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ZONE CONFIGURATION FOR RANGE timeseries;
-    ~~~
-    ~~~
-           target      |               raw_config_sql
-    +------------------+---------------------------------------------+
-      RANGE timeseries | ALTER RANGE timeseries CONFIGURE ZONE USING
-                       |     range_min_bytes = 134217728,
-                       |     range_max_bytes = 536870912,
-                       |     gc.ttlseconds = 90000,
-                       |     num_replicas = 3,
-                       |     constraints = '[]',
-                       |     lease_preferences = '[]'
-    (1 row)
-    ~~~
-
-    The timeseries data will only be replicated 3 times without affecting the configuration of all other data.
-
-## See also
-
-- [`SHOW ZONE CONFIGURATIONS`](show-zone-configurations.html)
-- [`CONFIGURE ZONE`](configure-zone.html)
-- [`SHOW PARTITIONS`](show-partitions.html)
-- [SQL Statements](sql-statements.html)
-- [Table Partitioning](partitioning.html)
-- [Replication Reports](query-replication-reports.html)
diff --git a/src/current/v20.2/configure-zone.md b/src/current/v20.2/configure-zone.md
deleted file mode 100644
index 115fa557c1d..00000000000
--- a/src/current/v20.2/configure-zone.md
+++ /dev/null
@@ -1,131 +0,0 @@
----
-title: CONFIGURE ZONE
-summary: Use the CONFIGURE ZONE statement to add, modify, reset, and remove replication zones.
-toc: true
----
-
-`CONFIGURE ZONE` is a subcommand of the `ALTER DATABASE`, `ALTER TABLE`, `ALTER INDEX`, `ALTER PARTITION`, and `ALTER RANGE` statements and is used to add, modify, reset, or remove [replication zones](configure-replication-zones.html) for those objects. To view details about existing replication zones, see [`SHOW ZONE CONFIGURATIONS`](show-zone-configurations.html).
-
-In CockroachDB, you can use **replication zones** to control the number and location of replicas for specific sets of data, both when replicas are first added and when they are rebalanced to maintain cluster equilibrium.
-
-{{site.data.alerts.callout_info}}
-Adding replication zones for secondary indexes and partitions is an [Enterprise-only](enterprise-licensing.html) feature.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-**alter_zone_database_stmt ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/alter_zone_database.html %}
-</div>
-
-**alter_zone_table_stmt ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/alter_zone_table.html %}
-</div>
-
-**alter_zone_index_stmt ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/alter_zone_index.html %}
-</div>
-
-**alter_zone_partition_stmt ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/alter_zone_partition.html %}
-</div>
-
-**alter_zone_range_stmt ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/alter_zone_range.html %}
-</div>
-
-## Required privileges
-
-If the target is a [`system` range](#create-a-replication-zone-for-a-system-range), the [`system` database](show-databases.html#preloaded-databases), or a table in the `system` database, the user must be a member of the [`admin` role](authorization.html#create-and-manage-roles). For all other databases and tables, the user must have been granted either the [`CREATE`](grant.html#supported-privileges) or the [`ZONECONFIG`](grant.html#supported-privileges) privilege on the target database or table.
-
-## Parameters
-
- Parameter | Description
------------+-------------
-`range_name` | The name of the system [range](architecture/overview.html#glossary) for which to show [replication zone configurations](configure-replication-zones.html).
-`database_name` | The name of the [database](create-database.html) for which to show [replication zone configurations](configure-replication-zones.html).
-`table_name` | The name of the [table](create-table.html) for which to show [replication zone configurations](configure-replication-zones.html).
-`partition_name` | The name of the [partition](partitioning.html) for which to show [replication zone configurations](configure-replication-zones.html).
-`index_name` | The name of the [index](indexes.html) for which to show [replication zone configurations](configure-replication-zones.html).
-`variable` | The name of the [variable](#variables) to change.
-`value` | The value of the variable to change.
-`DISCARD` | Remove a replication zone.
-
-### Variables
-
-{% include {{ page.version.version }}/zone-configs/variables.md %}
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-{% include {{ page.version.version }}/sql/movr-statements-geo-partitioned-replicas.md %}
-
-### Edit a replication zone
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users CONFIGURE ZONE USING range_min_bytes = 0, range_max_bytes = 90000, gc.ttlseconds = 89999, num_replicas = 4;
-~~~
-
-~~~
-CONFIGURE ZONE 1
-~~~
-
-### Edit the default replication zone
-
-{% include {{ page.version.version }}/zone-configs/edit-the-default-replication-zone.md %}
-
-### Create a replication zone for a database
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-database.md %}
-
-### Create a replication zone for a table
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-table.md %}
-
-### Create a replication zone for a secondary index
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-secondary-index.md %}
-
-### Create a replication zone for a partition
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-table-partition.md %}
-
-### Create a replication zone for a system range
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-system-range.md %}
-
-### Reset a replication zone
-
-{% include {{ page.version.version }}/zone-configs/reset-a-replication-zone.md %}
-
-### Remove a replication zone
-
-{% include {{ page.version.version }}/zone-configs/remove-a-replication-zone.md %}
-
-## See also
-
-- [Configure Replication Zones](configure-replication-zones.html)
-- [`PARTITION BY`](partition-by.html)
-- [`SHOW ZONE CONFIGURATIONS`](show-zone-configurations.html)
-- [`ALTER DATABASE`](alter-database.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`ALTER INDEX`](alter-index.html)
-- [`ALTER PARTITION`](alter-partition.html)
-- [`ALTER RANGE`](alter-range.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [Table Partitioning](partitioning.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/connect-to-the-database-cockroachcloud.md b/src/current/v20.2/connect-to-the-database-cockroachcloud.md
deleted file mode 100644
index a1c64575ed5..00000000000
--- a/src/current/v20.2/connect-to-the-database-cockroachcloud.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: Connect to the Database (CockroachDB Cloud)
-summary: How to connect to a CockroachDB Cloud cluster from your application
-toc: true
----
-
-<div class="filters filters-big clearfix">
-  <a href="connect-to-the-database.html"><button class="filter-button">Local</button></a>
-  <button class="filter-button current">CockroachDB {{ site.data.products.cloud }}</button>
-</div>
-
-This page has instructions for connecting to a CockroachDB {{ site.data.products.cloud }} cluster from your application using various programming languages. Each example shows a [connection string][connection_params] for a secure cluster to a `bank` database. Depending on your cluster's configuration, you may need to edit this connection string.
-
-The connection strings listed on this page set the required authentication options to connect to [free CockroachDB {{ site.data.products.cloud }}](../cockroachcloud/authentication.html) clusters. CockroachDB {{ site.data.products.cloud }} clusters use a signed certificate generated for your cluster that you download from the CockroachDB {{ site.data.products.cloud }} console.
-
-For a reference that lists all of the supported cluster connection parameters, see [Connection Parameters][connection_params].
-
-## Before you begin
-
-Do the following:
-
- <a name="set-up-your-cluster-connection"></a>
-
-- Set up a CockroachDB {{ site.data.products.cloud }} cluster:
-  - [Create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-  - [Connect to the CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/connect-to-your-cluster.html).
-- [Install a client driver or ORM framework](install-client-drivers.html).
-
-## Connect
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go</button>
-  <button class="filter-button" data-scope="java">Java</button>
-  <button class="filter-button" data-scope="python">Python</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---url='postgres://{username}:{password}@{globalhost}:26257/{cluster_name}.{database}?sslmode=verify-full&sslrootcert={path to the CA certificate}'
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-For more information about how to use the built-in SQL client, see the [`cockroach sql`](cockroach-sql.html) reference docs.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-import (
-    "database/sql"
-    "fmt"
-    "log"
-    _ "github.com/lib/pq"
-)
-
-db, err := sql.Open("postgres",
-        "postgresql://{username}:{password}@{globalhost}:26257/bank?sslmode=verify-full&sslrootcert={path to the CA certificate}&options=--cluster={cluster_name}")
-if err != nil {
-    log.Fatal("error connecting to the database: ", err)
-}
-defer db.Close()
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-{% include {{page.version.version}}/app/for-a-complete-example-go.md %}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-import java.sql.*;
-import javax.sql.DataSource;
-
-PGSimpleDataSource ds = new PGSimpleDataSource();
-ds.setServerName("{globalhost}");
-ds.setPortNumber(26257);
-ds.setDatabaseName("{cluster_name}.bank");
-ds.setUser("{username}");
-ds.setPassword("{password}");
-ds.setSsl(true);
-ds.setSslMode("verify-full");
-ds.setSslrootCert("{path to the CA certificate}");
-ds.setReWriteBatchedInserts(true); // add `rewriteBatchedInserts=true` to pg connection string
-ds.setApplicationName("BasicExample");
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-{% include {{page.version.version}}/app/for-a-complete-example-java.md %}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-import psycopg2
-
-conn = psycopg2.connect(
-    database='bank',
-    user='{username}',
-    password='{password}'
-    sslmode='verify-full',
-    sslrootcert='{path to the CA certificate}',
-    port=26257,
-    host='{globalhost}',
-    options="--cluster={cluster_name}"
-)
-~~~
-
-{% include {{page.version.version}}/app/cc-free-tier-params.md %}
-
-{% include {{page.version.version}}/app/for-a-complete-example-python.md %}
-
-</section>
-
-{% include cockroachcloud/cc-no-user-certs.md %}
-
-## What's next?
-
-<a name="tasks"></a>
-
-- [Design a Database Schema](schema-design-overview.html)
-- [Insert Data](insert-data.html)
-- [Query Data](query-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-
-You might also be interested in the following pages:
-
-- [Connection Pooling](connection-pooling.html)
-- [Connection Parameters][connection_params]
-- [Manual Deployments][manual]
-- [Orchestrated Deployments][orchestrated]
-- [Start a Local Cluster][local_secure]
-- [Error Handling and Troubleshooting](error-handling-and-troubleshooting.html)
-- [Optimize Query Performance](make-queries-fast.html)
-- [Hello World example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[manual]: manual-deployment.html
-[orchestrated]: orchestration.html
-[local_secure]: secure-a-cluster.html
-[connection_params]: connection-parameters.html
diff --git a/src/current/v20.2/connect-to-the-database.md b/src/current/v20.2/connect-to-the-database.md
deleted file mode 100644
index 16d4422bf57..00000000000
--- a/src/current/v20.2/connect-to-the-database.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: Connect to the Database
-summary: How to connect to a CockroachDB cluster from your application
-toc: true
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current">Local</button>
-  <a href="connect-to-the-database-cockroachcloud.html"><button class="filter-button">CockroachDB {{ site.data.products.cloud }}</button></a>
-</div>
-
-This page has instructions for connecting to a CockroachDB cluster from your application using various programming languages. Each example shows a [connection string][connection_params] for a secure cluster to a `bank` database. Depending on your cluster's configuration, you may need to edit this connection string.
-
-The connection strings listed on this page set the required authentication options to connect to [local](authentication.html) clusters. Local clusters use self-signed SSL certificates.
-
-For a reference that lists all of the supported cluster connection parameters, see [Connection Parameters][connection_params].
-
-## Before you begin
-
-Do the following:
-
-- Set up a local CockroachDB cluster:
-  - [Install CockroachDB](install-cockroachdb.html).
-  - [Start a local cluster](secure-a-cluster.html).
-- [Install a client driver or ORM framework](install-client-drivers.html).
-
-## Connect
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go</button>
-  <button class="filter-button" data-scope="java">Java</button>
-  <button class="filter-button" data-scope="python">Python</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs --host=localhost:26257
-~~~
-
-For more information about how to use the built-in SQL client, see the [`cockroach sql`](cockroach-sql.html) reference docs.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-import (
-    "database/sql"
-    "fmt"
-    "log"
-    _ "github.com/lib/pq"
-)
-
-db, err := sql.Open("postgres",
-        "postgresql://maxroach@localhost:26257/bank?ssl=true&sslmode=require&sslrootcert=certs/ca.crt&sslkey=certs/client.maxroach.key&sslcert=certs/client.maxroach.crt")
-if err != nil {
-    log.Fatal("error connecting to the database: ", err)
-}
-defer db.Close()
-~~~
-
-{% include {{page.version.version}}/app/for-a-complete-example-go.md %}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-import java.sql.*;
-import javax.sql.DataSource;
-
-PGSimpleDataSource ds = new PGSimpleDataSource();
-ds.setServerName("localhost");
-ds.setPortNumber(26257);
-ds.setDatabaseName("bank");
-ds.setUser("maxroach");
-ds.setPassword(null);
-ds.setSsl(true);
-ds.setSslMode("require");
-ds.setSslCert("certs/client.maxroach.crt");
-ds.setSslKey("certs/client.maxroach.key.pk8");
-ds.setReWriteBatchedInserts(true); // add `rewriteBatchedInserts=true` to pg connection string
-ds.setApplicationName("BasicExample");
-~~~
-
-{{site.data.alerts.callout_success}}
-{% include {{page.version.version}}/app/pkcs8-gen.md %}
-{{site.data.alerts.end}}
-
-{% include {{page.version.version}}/app/for-a-complete-example-java.md %}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-import psycopg2
-
-conn = psycopg2.connect(
-    database='bank',
-    user='maxroach',
-    sslmode='require',
-    sslrootcert='certs/ca.crt',
-    sslkey='certs/client.maxroach.key',
-    sslcert='certs/client.maxroach.crt',
-    port=26257,
-    host='localhost'
-)
-~~~
-
-{% include {{page.version.version}}/app/for-a-complete-example-python.md %}
-
-</section>
-
-## What's next?
-
-<a name="tasks"></a>
-
-- [Design a Database Schema](schema-design-overview.html)
-- [Insert Data](insert-data.html)
-- [Query Data](query-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-
-You might also be interested in the following pages:
-
-- [Connection Pooling](connection-pooling.html)
-- [Connection Parameters][connection_params]
-- [Manual Deployments][manual]
-- [Orchestrated Deployments][orchestrated]
-- [Start a Local Cluster][local_secure]
-- [Error Handling and Troubleshooting](error-handling-and-troubleshooting.html)
-- [Optimize Query Performance](make-queries-fast.html)
-- [Hello World example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[manual]: manual-deployment.html
-[orchestrated]: orchestration.html
-[local_secure]: secure-a-cluster.html
-[connection_params]: connection-parameters.html
diff --git a/src/current/v20.2/connection-parameters.md b/src/current/v20.2/connection-parameters.md
deleted file mode 100644
index 0326438a3c1..00000000000
--- a/src/current/v20.2/connection-parameters.md
+++ /dev/null
@@ -1,254 +0,0 @@
----
-title: Client Connection Parameters
-summary: This page describes the parameters used to establish a client connection.
-toc: true
----
-
-Client applications, including [`cockroach` client
-commands](cockroach-commands.html), work by establishing a network
-connection to a CockroachDB cluster. The client connection parameters
-determine which CockroachDB cluster they connect to, and how to
-establish this network connection.
-
-## Supported connection parameters
-
-Most client apps, including `cockroach`  client commands, determine
-which CockroachDB server to connect to using a [PostgreSQL connection
-URL](#connect-using-a-url). When using a URL, a client can also
-specify additional SQL-level parameters. This mode provides the most
-configuration flexibility.
-
-In addition, all `cockroach` client commands also accept [discrete
-connection parameters](#connect-using-discrete-parameters) that can
-specify the connection parameters separately from a URL.
-
-## When to use a URL and when to use discrete parameters
-
-Specifying client parameters using a URL may be more convenient during
-experimentation, as it facilitates copy-pasting the connection
-parameters (the URL) between different tools: the output of `cockroach
-start`, other `cockroach` commands, GUI database visualizer,
-programming tools, etc.
-
-
-Discrete parameters may be more convenient in automation, where the
-components of the configuration are filled in separately from
-different variables in a script or a service manager.
-
-## Connect using a URL
-
-A connection URL has the following format:
-
-{% include_cached copy-clipboard.html %}
-~~~
-postgres://<username>:<password>@<host>:<port>/<database>?<parameters>
-~~~
-
-`cockroach` client commands also support [UNIX domain socket URIs](https://en.wikipedia.org/wiki/Unix_domain_socket) of the following form:
-
-{% include_cached copy-clipboard.html %}
-~~~
-postgres://<username>:<password>@?host=<directory-path>&port=<port>&<parameters>
-~~~
-
- Component      | Description                                                                                                                                                                                               | Required
-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------
- `<username>`   | The [SQL user](create-user.html) that will own the client session.                                                                                                                            | ✗
- `<password>`   | The user's password. It is not recommended to pass the password in the URL directly.<br><br>Note that CockroachDB currently does not allow passwords with special characters to be passed in a URL. For details, see [tracking issue](https://github.com/cockroachdb/cockroach/issues/35998).<br><br>[Find more detail about how CockroachDB handles passwords](authentication.html#client-authentication). | ✗
- `<host>`       | The host name or address of a CockroachDB node or load balancer. | Required by most client drivers.
- `<port>`       | The port number of the SQL interface of the CockroachDB node or load balancer. The default port number for CockroachDB is 26257. Use this value when in doubt. | Required by most client drivers.
- `<database>`   | A database name to use as [current database](sql-name-resolution.html#current-database). Defaults to `defaultdb`. | ✗
- `<directory-path>` |  The directory path to the client listening for a socket connection.                                                                                             | Required when specifying a Unix domain socket URI.
- `<parameters>` | [Additional connection parameters](#additional-connection-parameters), including SSL/TLS certificate settings. | `options=--cluster=<cluster name>` required for free CockroachDB {{ site.data.products.cloud }} clusters.
-
-
-{{site.data.alerts.callout_info}}
-For cockroach commands that accept a URL, you can specify the URL with the command-line flag `--url`.
-If `--url` is not specified but
-the environment variable `COCKROACH_URL` is defined, the environment
-variable is used. Otherwise, the `cockroach` command will use
-[discrete connection parameters](#connect-using-discrete-parameters)
-as described below.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-The `<database>` part is not used for [`cockroach`
-commands](cockroach-commands.html) other than [`cockroach
-sql`](cockroach-sql.html). A warning
-is currently printed if it is mistakenly specified, and
-future versions of CockroachDB may return an error in that case.
-{{site.data.alerts.end}}
-
-### Additional connection parameters
-
-The following additional parameters can be passed after the `?` character in the URL. After the first parameter is specified, any additional parameters must be separated by an ampersand (`&`).
-
-Parameter | Description | Default value
-----------|-------------|---------------
-`application_name` | An initial value for the [`application_name` session variable](set-vars.html).<br><br>Note: For [Java JDBC](build-a-java-app-with-cockroachdb.html), use `ApplicationName`. | Empty string.
-`sslmode` | Which type of secure connection to use: `disable`, `allow`, `prefer`, `require`, `verify-ca` or `verify-full`. See [Secure Connections With URLs](#secure-connections-with-urls) for details. | `disable`
-`sslrootcert` | Path to the [CA certificate](cockroach-cert.html), when `sslmode` is not `disable`. | Empty string.
-`sslcert` | Path to the [client certificate](cockroach-cert.html), when `sslmode` is not `disable`. | Empty string.
-`sslkey` | Path to the [client private key](cockroach-cert.html), when `sslmode` is not `disable`. | Empty string.
-`options` | Additional command-line options to be passed to the server. Specify the cluster name when connecting to CockroachDB {{ site.data.products.serverless }}-tier clusters by setting `options=--cluster=<cluster name>`. | Empty string
-
-### Secure connections with URLs
-
-The following values are supported for `sslmode`, although only the first and the last are recommended for use.
-
-Parameter | Description | Recommended for use
-----------|-------------|--------------------
-`sslmode=disable` | Do not use an encrypted, secure connection at all. | Use during development.
-`sslmode=allow` | Enable a secure connection only if the server requires it.<br><br>**Not supported in all clients.** |
-`sslmode=prefer` | Try to establish a secure connection, but accept an insecure connection if the server does not support secure connections.<br><br>**Not supported in all clients.** |
-`sslmode=require` | Force a secure connection. An error occurs if the secure connection cannot be established. |
-`sslmode=verify-ca` | Force a secure connection and verify that the server certificate is signed by a known CA. |
-`sslmode=verify-full` | Force a secure connection, verify that the server certificate is signed by a known CA, and verify that the server address matches that specified in the certificate. | Use for [secure deployments](secure-a-cluster.html).
-
-{{site.data.alerts.callout_danger}}
-Some client drivers and the `cockroach` commands do not support
-`sslmode=allow` and `sslmode=prefer`. Check the documentation of your
-SQL driver to determine whether these options are supported.
-{{site.data.alerts.end}}
-
-### Example URL for an insecure connection
-
-The following URL is suitable to connect to a CockroachDB node using an insecure connection:
-
-{% include_cached copy-clipboard.html %}
-~~~
-postgres://root@servername:26257/mydb?sslmode=disable
-~~~
-
-This specifies a connection for the `root` user to server `servername`
-on port 26257 (the default CockroachDB SQL port), with `mydb` set as
-current database. `sslmode=disable` makes the connection insecure.
-
-### Example URL for a secure connection
-
-The following URL is suitable to connect to a CockroachDB node using a secure connection:
-
-{% include_cached copy-clipboard.html %}
-~~~
-postgres://root@servername:26257/mydb?sslmode=verify-full&sslrootcert=path/to/ca.crt&sslcert=path/to/client.username.crt&sslkey=path/to/client.username.key
-~~~
-
-This uses the following components:
-
-- User `root`
-- Host name `servername`, port number 26257 (the default CockroachDB SQL port)
-- Current database `mydb`
-- SSL/TLS mode `verify-full`:
-  - Root CA certificate `path/to/ca.crt`
-  - Client certificate `path/to/client.username.crt`
-  - Client key `path/to/client.username.key`
-
-For details about how to create and manage SSL/TLS certificates, see
-[Create Security Certificates](cockroach-cert.html) and
-[Rotate Certificates](rotate-certificates.html).
-
-### Example URI for a Unix domain socket
-
-The following URI is suitable to connect to a CockroachDB cluster listening for Unix domain socket connections at `/path/to/client`:
-
-{% include_cached copy-clipboard.html %}
-~~~
-postgres://root@?host=/path/to/client&port=26257
-~~~
-
-This specifies a connection for the `root` user to an insecure cluster listening for a socket connection (e.g., a cluster started with the [`--socket-dir` flag](cockroach-start.html#networking)) at `/path/to/client`, and on port 26257.
-
-## Connect using discrete parameters
-
-Most [`cockroach` commands](cockroach-commands.html) accept connection
-parameters as separate, discrete command-line flags, in addition (or
-in replacement) to `--url` which [specifies all parameters as a
-URL](#connect-using-a-url).
-
-For each command-line flag that directs a connection parameter,
-CockroachDB also recognizes an environment variable. The environment
-variable is used when the command-line flag is not specified.
-
-{% include {{ page.version.version }}/sql/connection-parameters.md %}
-
-### Example command-line flags for an insecure connection
-
-The following command-line flags establish an insecure connection:
-
-{% include_cached copy-clipboard.html %}
-~~~
---user=root \
---host=<servername>
---insecure
-~~~
-
-This specifies a connection for the `root` user to server `servername`
-on port 26257 (the default CockroachDB SQL port). `--insecure` makes
-the connection insecure.
-
-### Example command-line flags for a secure connection
-
-The following command-line flags establish a secure connection:
-
-{% include_cached copy-clipboard.html %}
-~~~
---user=root \
---host=<servername>
---certs-dir=path/to/certs
-~~~
-
-This uses the following components:
-
-- User `root`
-- Host name `servername`, port number 26257 (the default CockroachDB SQL port)
-- SSL/TLS enabled, with settings:
-  - Root CA certificate `path/to/certs/ca.crt`
-  - Client certificate `path/to/client.<user>.crt` (`path/to/certs/client.root.crt` with `--user root`)
-  - Client key `path/to/client.<user>.key` (`path/to/certs/client.root.key` with `--user root`)
-
-{{site.data.alerts.callout_info}}
-When using discrete connection parameters, the file names of the CA
-and client certificates and client key are derived automatically from
-the value of `--certs-dir`.
-{{site.data.alerts.end}}
-
-## Using both URL and client parameters
-
-Most `cockroach` commands accept both a URL and client parameters.
-The information contained therein is combined in the order it appears
-in the command line.
-
-This combination is useful so that discrete command-line flags can
-override settings not otherwise set in the URL.
-
-### Example override of the current database
-
-The `cockroach start` command prints out the following connection URL, which connects to the `defaultdb` database:
-
-{% include_cached copy-clipboard.html %}
-~~~
-postgres://root@servername:26257/?sslmode=disable
-~~~
-
-To specify `mydb` as the current database using [`cockroach sql`](cockroach-sql.html), run the following command:
-
-{% include_cached copy-clipboard.html %}
-~~~
-cockroach sql \
---url "postgres://root@servername:26257/?sslmode=disable" \
---database mydb
-~~~
-
-This is equivalent to:
-
-{% include_cached copy-clipboard.html %}
-~~~
-cockroach sql --url "postgres://root@servername:26257/mydb?sslmode=disable"
-~~~
-
-## See also
-
-- [`cockroach` commands](cockroach-commands.html)
-- [Create Security Certificates](cockroach-cert.html)
-- [Secure a Cluster](secure-a-cluster.html)
-- [Create and Manage Users](authorization.html#create-and-manage-users)
diff --git a/src/current/v20.2/connection-pooling.md b/src/current/v20.2/connection-pooling.md
deleted file mode 100644
index 17d1d6e4f84..00000000000
--- a/src/current/v20.2/connection-pooling.md
+++ /dev/null
@@ -1,117 +0,0 @@
----
-title: Connection Pooling
-summary: How to plan, configure, and use connection pools when using drivers or frameworks with CockroachDB.
-toc: true
----
-
-This page has information on planning, configuring, and using connection pools when using drivers or frameworks with CockroachDB.
-
-## About connection pools
-
-A typical database operation consists of several steps.
-
-1. The driver uses a configuration to start a connection to the database server.
-1. A network socket is opened on the client that connects to the database server.
-1. Data is read or written through the network socket.
-1. The connection is closed down.
-1. The network socket is closed down and its resources are freed.
-
-For simple database operations, these steps are not expensive, but as an application scales up, the performance of the application will suffer as each connection is created and destroyed. One pattern for improving performance is a connection pool, a group of already configured and established network connections between the client and database that can be reused for data operations within an application.
-
-Each time an application reads or writes data, it will request one of the connections in the pool. After the data operation completes, the connection is returned to the pool so other operations can use it.
-
-Connection pooling can be a enabled as a feature of the driver, a separate library used in conjunction with a driver, a feature of an application server, or a proxy server that acts as a gateway to the database server.
-
-## Sizing connection pools
-
-Idle connections in CockroachDB do not consume many resources compared to PostgreSQL. Cockroach Labs estimates the memory overhead of idle connections in CockroachDB is 20 kB to 30 kB per connection.
-
-Creating the appropriate size pool of connections is critical to gaining maximum performance in an application. Too few connections in the pool will result in high latency as each operation waits for a connection to open up. But adding too many connections to the pool can also result in high latency as each connection thread is being run in parallel by the system. The time it takes for many threads to complete in parallel is typically higher than the time it takes a smaller number of threads to run sequentially.
-
-Each processor core can only execute one thread at a time. When there are more threads than processor cores, the system will use context switching to [time-slice](https://en.wikipedia.org/wiki/Preemption_(computing)#Time_slice) the thread execution. For example, if you have a system with a single core and two threads, processing threads 1 and 2 in parallel results in the system context switching to pause execution of thread 1 and begin executing thread 2, and then pause execution of thread 2 to resume executing thread 1. Executing thread 1 completely and then executing thread 2 will be faster because the system doesn't need to context switch, even though thread 2 had to wait until thread 1 fully completed to begin executing.
-
-Storage and network performance also will affect the ability of a thread to fully execute. If a thread is blocked by network or storage latency, adding connections to the pool is a good idea so other threads can execute while the original thread is being blocked.
-
-Cockroach Labs performed lab testing of various customer workloads and found no improvement in scalability beyond:
-
-**connections = (number of cores * 4)**
-
-Many workloads perform best when the maximum number of active connections is between 2 and 4 times the number of CPU cores in the cluster.
-
-If you have a large number of services connecting to the same cluster, make sure the number of concurrent active connections across all the services does not exceed this recommendation by a large amount. If each service has its own connection pool, then you should make sure the sum of all the pool sizes is close to our maximum connections recommendation. Each workload and application is different, so you should conduct testing to determine the best-performing pool sizes for each service in your architecture.
-
-In addition to setting a maximum connection pool size, set the maximum number of idle connections if possible. Cockroach Labs recommends setting the maximum number of idle connections to the maximum pool size. While this uses more memory, it allows many connections when concurrency is high without having to create a new connection for every new operation.
-
-## Validating connections in a pool
-
-After a connection pool initializes connections to CockroachDB clusters, those connections can occasionally break. This could be due to changes in the cluster topography, or rolling upgrades and restarts, or network disruptions. CockroachDB {{ site.data.products.cloud }} clusters periodically are restarted for minor version updates, for example, so previously established connections would be invalid after the restart.
-
-Validating connections is typically handled automatically by the connection pool. For example, in HikariCP the connection is validated whenever you request a connection from the pool, and the `keepaliveTime` property allows you to configure an interval to periodically check if the connections in the pool are valid. Whatever connection pool you use, make sure connection validation is enabled when running your application.
-
-## Example
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="java">Java (Hikari/JDBC)</button>
-  <button class="filter-button" data-scope="go">Go (pgxpool)</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-In this example, a Java application similar to the [basic JDBC example](build-a-java-app-with-cockroachdb.html) uses the [PostgreSQL JDBC driver](https://jdbc.postgresql.org/) and [HikariCP](https://github.com/brettwooldridge/HikariCP) as the connection pool layer to connect to a CockroachDB cluster. The database is being run on 10 cores across the cluster.
-
-Using the connection pool formula above:
-
-**connections = (10 [processor cores] * 4)**
-
-The connection pool size should be 40.
-
-{% include_cached copy-clipboard.html %}
-~~~ java
-HikariConfig config = new HikariConfig();
-config.setJdbcUrl("jdbc:postgresql://localhost:26257/bank");
-config.setUsername("maxroach");
-config.setPassword("password");
-config.addDataSourceProperty("ssl", "true");
-config.addDataSourceProperty("sslMode", "require")
-config.addDataSourceProperty("reWriteBatchedInserts", "true");
-config.setAutoCommit(false);
-config.setMaximumPoolSize(40);
-config.setKeepaliveTime(150000);
-
-HikariDataSource ds = new HikariDataSource(config);
-
-Connection conn = ds.getConnection();
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-In this example, a Go application similar to the [basic pgx example](build-a-go-app-with-cockroachdb.html) uses the [pgxpool library](https://pkg.go.dev/github.com/jackc/pgx/v4/pgxpool) to create a connection pool on a CockroachDB cluster. The database is being run on 10 cores across the cluster.
-
-Using the connection pool formula above:
-
-**connections = (10 [processor cores] * 4)**
-
-The connection pool size should be 40.
-
-~~~ go
-// Set connection pool configuration, with maximum connection pool size.
-config, err := pgxpool.ParseConfig("postgres://max:roach@127.0.0.1:26257/bank?sslmode=require&pool_max_conns=40")
-	if err != nil {
-		log.Fatal("error configuring the database: ", err)
-	}
-
-// Create a connection pool to the "bank" database.
-dbpool, err := pgxpool.ConnectConfig(context.Background(), config)
-if err != nil {
-	log.Fatal("error connecting to the database: ", err)
-}
-defer dbpool.Close()
-~~~
-
-This example uses the `pool_max_conns` parameter to set the maximum number of connections in the connection pool to 30.
-
-For a full list of connection pool configuration parameters for pgxpool, see [the pgxpool documentation](https://pkg.go.dev/github.com/jackc/pgx/v4/pgxpool#Config).
-
-</section>
diff --git a/src/current/v20.2/constraints.md b/src/current/v20.2/constraints.md
deleted file mode 100644
index e0a8f79a0f0..00000000000
--- a/src/current/v20.2/constraints.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-title: Constraints
-summary: Constraints offer additional data integrity by enforcing conditions on the data within a column.
-toc: true
----
-
-Constraints offer additional data integrity by enforcing conditions on the data within a column. Whenever values are manipulated (inserted, deleted, or updated), constraints are checked and modifications that violate constraints are rejected.
-
-For example, the `UNIQUE` constraint requires that all values in a column be unique from one another (except *NULL* values). If you attempt to write a duplicate value, the constraint rejects the entire statement.
-
-
-## Supported constraints
-
- Constraint | Description
-------------|-------------
- [`CHECK`](check.html) | Values must return `TRUE` or `NULL` for a Boolean expression.
- [`DEFAULT` value](default-value.html) | If a value is not defined for the constrained column in an `INSERT` statement, the `DEFAULT` value is written to the column.
- [`FOREIGN KEY`](foreign-key.html) | Values must exactly match existing values from the column it references.
- [`NOT NULL`](not-null.html) | Values may not be *NULL*.
- [`PRIMARY KEY`](primary-key.html) | Values must uniquely identify each row *(one per table)*. This behaves as if the `NOT NULL` and `UNIQUE` constraints are applied, as well as automatically creates an [index](indexes.html) for the table using the constrained columns.
- [`UNIQUE`](unique.html) | Each non-*NULL* value must be unique. This also automatically creates an [index](indexes.html) for the table using the constrained columns.
-
-## Using constraints
-
-### Add constraints
-
-How you add constraints depends on the number of columns you want to constrain, as well as whether or not the table is new.
-
-- **One column of a new table** has its constraints defined after the column's data type. For example, this statement applies the `PRIMARY KEY` constraint to `foo.a`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE foo (a INT PRIMARY KEY);
-    ~~~
-- **Multiple columns of a new table** have their constraints defined after the table's columns. For example, this statement applies the `PRIMARY KEY` constraint to `foo`'s columns `a` and `b`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE bar (a INT, b INT, PRIMARY KEY (a,b));
-    ~~~
-
-  {{site.data.alerts.callout_info}}
-  The `DEFAULT` and `NOT NULL` constraints cannot be applied to multiple columns.
-  {{site.data.alerts.end}}
-
-- **Existing tables** can have the following constraints added:
-  - `CHECK`, `FOREIGN KEY`, and `UNIQUE` constraints can be added through [`ALTER TABLE...ADD CONSTRAINT`](add-constraint.html). For example, this statement adds the `UNIQUE` constraint to `baz.id`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE baz ADD CONSTRAINT id_unique UNIQUE (id);
-    ~~~
-
-  - `DEFAULT` values and `NOT NULL` constraints can be added through [`ALTER TABLE...ALTER COLUMN`](alter-column.html#set-or-change-a-default-value). For example, this statement adds the Default Value constraint to `baz.bool`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE baz ALTER COLUMN bool SET DEFAULT true;
-    ~~~
-
-  -  [`PRIMARY KEY`](primary-key.html) constraints can be added with [`ADD CONSTRAINT`](add-constraint.html)/[`ADD PRIMARY KEY`](alter-table.html) in the following circumstances:
-
-      - A [`DROP CONSTRAINT`](drop-constraint.html) statement precedes the `ADD CONSTRAINT`/`ADD PRIMARY KEY` statement in the same transaction. For examples, see the [`ADD CONSTRAINT`](add-constraint.html#examples) and [`DROP CONSTRAINT`](drop-constraint.html#examples) pages.
-      - The current [primary key is on `rowid`](indexes.html#creation), the default primary key created if none is explicitly defined at table creation.
-      - The `ADD CONSTRAINT`/`ADD PRIMARY KEY` is in the same transaction as a `CREATE TABLE` statement with no primary key defined.
-
-#### Order of constraints
-
-The order in which you list constraints is not important because constraints are applied to every modification of their respective tables or columns.
-
-#### Name constraints on new tables
-
-You can name constraints applied to new tables using the `CONSTRAINT` clause before defining the constraint:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE foo (a INT CONSTRAINT another_name PRIMARY KEY);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE bar (a INT, b INT, CONSTRAINT yet_another_name PRIMARY KEY (a,b));
-~~~
-
-### View constraints
-
-To view a table's constraints, use [`SHOW CONSTRAINTS`](show-constraints.html) or [`SHOW CREATE`](show-create.html).
-
-### Remove constraints
-
-The procedure for removing a constraint depends on its type:
-
-Constraint Type | Procedure
------------------|-----------
-[`CHECK`](check.html) | Use [`DROP CONSTRAINT`](drop-constraint.html).
-[`DEFAULT` value](default-value.html) | Use [`ALTER COLUMN`](alter-column.html#remove-default-constraint).
-[`FOREIGN KEY`](foreign-key.html) | Use [`DROP CONSTRAINT`](drop-constraint.html).
-[`NOT NULL`](not-null.html) | Use [`ALTER COLUMN`](alter-column.html#remove-not-null-constraint).
-[`PRIMARY KEY`](primary-key.html) |   Primary key constraints can be dropped with [`DROP CONSTRAINT`](drop-constraint.html) if an [`ADD CONSTRAINT`](add-constraint.html) statement follows the `DROP CONSTRAINT` statement in the same transaction.
-[`UNIQUE`](unique.html) | The `UNIQUE` constraint cannot be dropped directly.  To remove the constraint, [drop the index](drop-index.html) that was created by the constraint, e.g., `DROP INDEX my_unique_constraint`.
-
-### Change constraints
-
-The procedure for changing a constraint depends on its type:
-
-Constraint Type | Procedure
------------------|-----------
-[`CHECK`](check.html) | [Issue a transaction](transactions.html#syntax) that adds a new `CHECK` constraint ([`ADD CONSTRAINT`](add-constraint.html)), and then remove the existing one ([`DROP CONSTRAINT`](drop-constraint.html)).
-[`DEFAULT` value](default-value.html) | The `DEFAULT` value can be changed through [`ALTER COLUMN`](alter-column.html).
-[`FOREIGN KEY`](foreign-key.html) | [Issue a transaction](transactions.html#syntax) that adds a new `FOREIGN KEY` constraint ([`ADD CONSTRAINT`](add-constraint.html)), and then remove the existing one ([`DROP CONSTRAINT`](drop-constraint.html)).
-[`NOT NULL`](not-null.html) | The `NOT NULL` constraint cannot be changed, only added and removed with [`ALTER COLUMN`](alter-column.html).
-[`PRIMARY KEY`](primary-key.html) |   To change a primary key, use an [`ALTER TABLE ... ALTER PRIMARY KEY`](alter-primary-key.html) statement.<br><br>When you change a primary key with [`ALTER PRIMARY KEY`](alter-primary-key.html), the old primary key index becomes a secondary index. If you do not want the old primary key to become a secondary index, use [`DROP CONSTRAINT`](drop-constraint.html)/[`ADD CONSTRAINT`](add-constraint.html) to change the primary key.
-[`UNIQUE`](unique.html) | [Issue a transaction](transactions.html#syntax) that adds a new `UNIQUE` constraint ([`ADD CONSTRAINT`](add-constraint.html)), and then remove the existing one ([`DROP CONSTRAINT`](drop-constraint.html)).
-
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`SHOW CREATE`](show-create.html)
-- [`ALTER PRIMARY KEY`](alter-primary-key.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`ALTER COLUMN`](alter-column.html)
diff --git a/src/current/v20.2/convert-to-schema.md b/src/current/v20.2/convert-to-schema.md
deleted file mode 100644
index c2d1c013137..00000000000
--- a/src/current/v20.2/convert-to-schema.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: CONVERT TO SCHEMA
-summary: The CONVERT TO SCHEMA statement converts a database to a schema.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: The `CONVERT TO SCHEMA` [statement](sql-statements.html) converts a database to a new, user-defined [schema](sql-name-resolution.html). When you convert a database to a schema, all [tables](create-table.html), [sequences](create-sequence.html), and [user-defined types](enum.html) in the database become child objects of the new schema, and the database is deleted.
-
-In CockroachDB versions < v20.2, [user-defined schemas](create-schema.html) are not supported, and all stored objects in a given database use the `public` schema. To provide a [multi-level structure for stored objects](sql-name-resolution.html) in earlier versions of CockroachDB, we've recommended using [database](create-database.html) namespaces instead of schema namespaces. The `CONVERT TO SCHEMA` statement is meant to help users who are upgrading to v20.2 and want to use schema namespaces in a way that is more similar to [PostgreSQL](https://www.postgresql.org/docs/current/ddl-schemas.html).
-
-{{site.data.alerts.callout_info}}
-`CONVERT TO SCHEMA` is a subcommand of [`ALTER DATABASE`](alter-database.html).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-Only members of the `admin` role can convert databases to schemas. By default, the `root` user belongs to the `admin` role.
-
-## Syntax
-
-~~~
-ALTER DATABASE <name> CONVERT TO SCHEMA WITH PARENT <parent_name>
-~~~
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`name` | The name of the database to convert.
-`parent_name` | The name of the parent database to which the new schema will belong.
-
-## Limitations
-
-A database cannot be converted to a schema if:
-
-- The database is the [current database](sql-name-resolution.html#current-database).
-- The database has a child schema other than the `public` schema.
-- The database contains dependent objects (e.g., [views](views.html)).
-
-## Example
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Convert a database to a schema
-
-By default, tables are stored in the `public` schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM public;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-Suppose that you want to convert `movr` to a schema, with a new database named `cockroach_labs` as its parent.
-
-First, create the new database:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE cockroach_labs;
-~~~
-
-Then, set the new database as the current database (recall that you cannot convert the current database to a schema):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> USE cockroach_labs;
-~~~
-
-Convert the `movr` database to a schema, with `cockroach_labs` as its parent database:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER DATABASE movr CONVERT TO SCHEMA WITH PARENT cockroach_labs;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  movr
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  movr        | promo_codes                | table |                   0
-  movr        | rides                      | table |                   0
-  movr        | user_promo_codes           | table |                   0
-  movr        | users                      | table |                   0
-  movr        | vehicle_location_histories | table |                   0
-  movr        | vehicles                   | table |                   0
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM public;
-~~~
-
-~~~
-  schema_name | table_name | type | estimated_row_count
---------------+------------+------+----------------------
-(0 rows)
-~~~
-
-## See also
-
-- [`CREATE SCHEMA`](create-schema.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [`Name Resolution`](sql-name-resolution.html)
diff --git a/src/current/v20.2/copy-from.md b/src/current/v20.2/copy-from.md
deleted file mode 100644
index 7d5e8c4431a..00000000000
--- a/src/current/v20.2/copy-from.md
+++ /dev/null
@@ -1,122 +0,0 @@
----
-title: COPY FROM
-summary: Copy data from a third-party client to CockroachDB.
-toc: true
----
-
-The `COPY FROM` statement copies data from third-party clients to tables in your cluster.
-
-{{site.data.alerts.callout_info}}
-CockroachDB currently only supports `COPY FROM` statements issued from third-party clients, for compatibility with PostgreSQL drivers and ORMs. `COPY FROM` statements cannot be issued from the [`cockroach` SQL shell](cockroach-sql.html). To copy data from a file to your cluster, we recommend using an [`IMPORT`](import.html) statement instead.
-{{site.data.alerts.end}}
-
-## Syntax
-
-~~~
-COPY table_name [( <colnames...> )] FROM STDIN [WITH <option> = <value>]
-~~~
-
-### Parameters
-
-Parameter | Description
------------|-------------
-`table_name` | The name of the table to which to copy data.
-`<colnames>` | The name(s) of the column(s) to which to copy data.
-`WITH <option> = value` | Specify one or more [copy options](#options).
-
-### Options
-
-Option | Description
------------|-------------
-`BINARY` | Copy data from binary format.<br>If not specified, CockroachDB copies in plaintext format. Note that CSV format is not yet supported.
-
-## Required privileges
-
-Only members of the `admin` role can run `COPY` statements. By default, the `root` user belongs to the `admin` role.
-
-## Known limitations
-
-### `COPY FROM` statements are not supported in the CockroachDB SQL shell
-
-{% include {{ page.version.version }}/known-limitations/copy-from-clients.md %}
-
-### `COPY` syntax not supported by CockroachDB
-
-{% include {{ page.version.version }}/known-limitations/copy-syntax.md %}
-
-## Example
-
-The following example copies data from the PostgreSQL [`psql` client](https://www.postgresql.org/docs/current/app-psql.html) into a demo CockroachDB cluster. To follow along, make sure that you have [PostgreSQL](https://www.postgresql.org/download/) installed.
-
-Run [`cockroach demo`](cockroach-demo.html) to start a temporary, in-memory cluster with the [`movr` database](movr.html) preloaded:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo
-~~~
-
-Take note of the `(sql/tcp)` connection string listed under `Connection parameters` in the welcome message of the demo cluster's SQL shell:
-
-~~~
-# Connection parameters:
-...
-#   (sql/tcp) postgres://root:admin@127.0.0.1:65207?sslmode=require
-~~~
-
-Open a new terminal window, and connect to your demo cluster with `psql`, using the connection string provided for the demo cluster, with the `movr` database specified:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ psql postgres://root:admin@127.0.0.1:65207/movr?sslmode=require
-~~~
-
-In the `psql` shell, run the following command to start copying data from `psql` to the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> movr=# COPY users FROM STDIN;
-~~~
-
-The following prompt should appear:
-
-~~~
-Enter data to be copied followed by a newline.
-End with a backslash and a period on a line by itself, or an EOF signal.
-~~~
-
-Enter some tab-delimited data that you want copied to the `users` table:
-
-{% include copy-clipboard.html %}
-~~~
->> 8a3d70a3-d70a-4000-8000-00000000001d seattle	Hannah	400 Broad St	0987654321
->> 9eb851eb-851e-4800-8000-00000000001e	new york	Carl	53 W 23rd St	5678901234
->> \.
-~~~
-
-~~~
-COPY 2
-~~~
-
-In the demo cluster's shell, query the `users` table for the rows that you just inserted:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users WHERE id IN ('8a3d70a3-d70a-4000-8000-00000000001d', '9eb851eb-851e-4800-8000-00000000001e');
-~~~
-
-~~~
-                   id                  |   city   |  name  |   address    | credit_card
----------------------------------------+----------+--------+--------------+--------------
-  8a3d70a3-d70a-4000-8000-00000000001d | seattle  | Hannah | 400 Broad St | 0987654321
-  9eb851eb-851e-4800-8000-00000000001e | new york | Carl   | 53 W 23rd St | 5678901234
-(2 rows)
-~~~
-
-## See also
-
-- [`IMPORT`](import.html)
-- [`IMPORT INTO`](import-into.html)
-- [`EXPORT`](export.html)
-- [Migrate from Postgres](migrate-from-postgres.html)
-- [Migration Overview](migration-overview.html)
-
diff --git a/src/current/v20.2/copy.pl b/src/current/v20.2/copy.pl
deleted file mode 100644
index 7877a361544..00000000000
--- a/src/current/v20.2/copy.pl
+++ /dev/null
@@ -1,122 +0,0 @@
-#!/usr/bin/env perl
-
-use strict;
-use warnings;
-use feature qw/ say /;
-
-my @files = qw/
-  create-table-as.md
-  delete.md
-  export.md
-  import.md
-  import-into.md
-  insert.md
-  select-clause.md
-  selection-queries.md
-  truncate.md
-  update.md
-  upsert.md
-  selection-queries.md
-  add-column.md
-  add-constraint.md
-  alter-column.md
-  alter-database.md
-  alter-index.md
-  alter-partition.md
-  alter-range.md
-  alter-sequence.md
-  alter-table.md
-  alter-type.md
-  alter-user.md
-  alter-view.md
-  comment-on.md
-  configure-zone.md
-  create-database.md
-  create-index.md
-  create-sequence.md
-  create-table.md
-  create-table-as.md
-  create-view.md
-  drop-column.md
-  drop-constraint.md
-  drop-database.md
-  drop-index.md
-  drop-sequence.md
-  drop-table.md
-  drop-view.md
-  experimental-audit.md
-  partition-by.md
-  rename-column.md
-  rename-constraint.md
-  rename-database.md
-  rename-index.md
-  rename-sequence.md
-  rename-table.md
-  show-columns.md
-  show-constraints.md
-  show-create.md
-  show-databases.md
-  show-partitions.md
-  show-index.md
-  show-locality.md
-  show-schemas.md
-  show-sequences.md
-  show-tables.md
-  show-ranges.md
-  show-zone-configurations.md
-  split-at.md
-  unsplit-at.md
-  validate-constraint.md
-  begin-transaction.md
-  commit-transaction.md
-  release-savepoint.md
-  rollback-transaction.md
-  savepoint.md
-  set-transaction.md
-  show-vars.md
-  create-role.md
-  create-user.md
-  drop-role.md
-  drop-user.md
-  grant.md
-  grant-roles.md
-  revoke.md
-  revoke-roles.md
-  show-grants.md
-  show-roles.md
-  show-users.md
-  reset-vars.md
-  set-vars.md
-  set-transaction.md
-  show-trace.md
-  show-vars.md
-  reset-cluster-setting.md
-  set-cluster-setting.md
-  show-cluster-setting.md
-  show-sessions.md
-  cancel-session.md
-  cancel-query.md
-  show-queries.md
-  create-statistics.md
-  explain.md
-  explain-analyze.md
-  show-statistics.md
-  cancel-job.md
-  pause-job.md
-  resume-job.md
-  show-jobs.md
-  enterprise-licensing.md
-  backup.md
-  backup.md
-  restore.md
-  show-backup.md
-  stream-data-out-of-cockroachdb-using-changefeeds.md
-  create-changefeed.md
-  changefeed-for.md
-  /;
-
-for my $file (@files) {
-    my $target_dir = qq[/Users/rloveland/work/code/sqlchecker/data/];
-    my $cmd        = qq[cp $file $target_dir];
-    system $cmd;
-}
diff --git a/src/current/v20.2/cost-based-optimizer.md b/src/current/v20.2/cost-based-optimizer.md
deleted file mode 100644
index a5ffa4393a2..00000000000
--- a/src/current/v20.2/cost-based-optimizer.md
+++ /dev/null
@@ -1,693 +0,0 @@
----
-title: Cost-Based Optimizer
-summary: The cost-based optimizer seeks the lowest cost for a query, usually related to time.
-toc: true
----
-
-The cost-based optimizer seeks the lowest cost for a query, usually related to time.
-
-## How is cost calculated?
-
-A given SQL query can have thousands of equivalent query plans with vastly different execution times. The cost-based optimizer enumerates these plans and chooses the lowest cost plan.
-
-Cost is roughly calculated by:
-
-- Estimating how much time each node in the query plan will use to process all results
-- Modeling how data flows through the query plan
-
-The most important factor in determining the quality of a plan is cardinality (i.e., the number of rows); the fewer rows each SQL operator needs to process, the faster the query will run.
-
-## Table statistics
-
-The cost-based optimizer can often find more performant query plans if it has access to statistical data on the contents of your tables. This data needs to be generated from scratch for new tables, and regenerated periodically for existing tables.
-
-By default, CockroachDB automatically generates table statistics when tables are [created](create-table.html), and as they are [updated](update.html). It does this using a [background job](create-statistics.html#view-statistics-jobs) that automatically determines which columns to get statistics on &mdash; specifically, it chooses:
-
-- Columns that are part of the primary key or an index (in other words, all indexed columns).
-- Up to 100 non-indexed columns.
-
-By default, CockroachDB also automatically collects [multi-column statistics](create-statistics.html#create-statistics-on-multiple-columns) on columns that prefix an index.
-
-{{site.data.alerts.callout_info}}
-[Schema changes](online-schema-changes.html) trigger automatic statistics collection for the affected table(s).
-{{site.data.alerts.end}}
-
-### Control automatic statistics
-
-For best query performance, most users should leave automatic statistics enabled with the default settings. The information provided in this section is useful for troubleshooting or performance tuning by advanced users.
-
-#### Control statistics refresh rate
-
-Statistics are refreshed in the following cases:
-
-- When there are no statistics.
-- When it's been a long time since the last refresh, where "long time" is defined according to a moving average of the time across the last several refreshes.
-- After a successful [`IMPORT`](import.html) or [`RESTORE`](restore.html) into the table.
-- After any schema change affecting the table.
-- After each mutation operation ([`INSERT`](insert.html), [`UPDATE`](update.html), or [`DELETE`](delete.html)), the probability of a refresh is calculated using a formula that takes the [cluster settings](cluster-settings.html) shown in the following table as inputs. These settings define the target number of rows in a table that should be stale before statistics on that table are refreshed.  Increasing either setting will reduce the frequency of refreshes. In particular, `min_stale_rows` impacts the frequency of refreshes for small tables, while `fraction_stale_rows` has more of an impact on larger tables.
-
-
-    | Setting                                              | Default Value | Details                                                                              |
-    |------------------------------------------------------+---------------+--------------------------------------------------------------------------------------|
-    | `sql.stats.automatic_collection.fraction_stale_rows` |           0.2 | Target fraction of stale rows per table that will trigger a statistics refresh       |
-    | `sql.stats.automatic_collection.min_stale_rows`      |           500 | Target minimum number of stale rows per table that will trigger a statistics refresh |
-
-    {{site.data.alerts.callout_info}}
-    Because the formula for statistics refreshes is probabilistic, you will not see statistics update immediately after changing these settings, or immediately after exactly 500 rows have been updated.
-    {{site.data.alerts.end}}
-
-#### Turn off statistics
-
-To turn off automatic statistics collection, follow these steps:
-
-1. Run the following statement to disable the automatic statistics [cluster setting](cluster-settings.html):
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING sql.stats.automatic_collection.enabled = false;
-    ~~~
-
-1. Use the [`SHOW STATISTICS`](show-statistics.html) statement to view automatically generated statistics.
-
-1. Delete the automatically generated statistics using the following statement:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > DELETE FROM system.table_statistics WHERE true;
-    ~~~
-
-1. Restart the nodes in your cluster to clear the statistics caches.
-
-To see how to manually generate statistics, see the [`CREATE STATISTICS` examples](create-statistics.html#examples).
-
-#### Control histogram collection
-
-By default, the optimizer collects histograms for all index columns (specifically the first column in each index) during automatic statistics collection. If a single column statistic is explicitly requested using manual invocation of [`CREATE STATISTICS`](create-statistics.html), a histogram will be collected, regardless of whether or not the column is part of an index.
-
-{{site.data.alerts.callout_info}}
-- CockroachDB does not support histograms on [`ARRAY`-typed](array.html) columns. As a result, statistics created on `ARRAY`-typed columns do not include histograms.
-- CockroachDB does not support multi-column histograms.
-{{site.data.alerts.end}}
-
-If you are an advanced user and need to disable histogram collection for troubleshooting or performance tuning reasons, change the [`sql.stats.histogram_collection.enabled` cluster setting](cluster-settings.html) by running [`SET CLUSTER SETTING`](set-cluster-setting.html) as follows:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-SET CLUSTER SETTING sql.stats.histogram_collection.enabled = false;
-~~~
-
-When `sql.stats.histogram_collection.enabled` is set to `false`, histograms are never collected, either as part of automatic statistics collection or by manually invoking [`CREATE STATISTICS`](create-statistics.html).
-
-## Query plan cache
-
-CockroachDB uses a cache for the query plans generated by the optimizer. This can lead to faster query execution since the database can reuse a query plan that was previously calculated, rather than computing a new plan each time a query is executed.
-
-The query plan cache is enabled by default. To disable it, execute the following statement:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.query_cache.enabled = false;
-~~~
-
-Only the following statements use the plan cache:
-
-- [`SELECT`](select-clause.html)
-- [`INSERT`](insert.html)
-- [`UPDATE`](update.html)
-- [`UPSERT`](upsert.html)
-- [`DELETE`](delete.html)
-
-## Join reordering
-
-For a query involving multiple joins, the cost-based optimizer will explore additional [join orderings](joins.html) in an attempt to find the lowest-cost execution plan, which can lead to significantly better performance in some cases.
-
-Because this process leads to an exponential increase in the number of possible execution plans for such queries, it's only used to reorder subtrees containing 4 or fewer joins by default.
-
-To change this setting, which is controlled by the `reorder_joins_limit` [session variable](set-vars.html), run the following statement. To disable this feature, set the variable to `0`.
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SET reorder_joins_limit = 6;
-~~~
-
-{{site.data.alerts.callout_danger}}
-We strongly recommend not setting this value higher than 8 to avoid performance degradation. If set too high, the cost of generating and costing execution plans can end up dominating the total execution time of the query.
-{{site.data.alerts.end}}
-
-For more information about the difficulty of selecting an optimal join ordering, see our blog post [An Introduction to Join Ordering](https://www.cockroachlabs.com/blog/join-ordering-pt1/).
-
-## Join hints
-
-The optimizer supports hint syntax to force the use of a specific join algorithm even if the optimizer determines that a different plan would have a lower cost. The algorithm is specified between the join type (`INNER`, `LEFT`, etc.) and the `JOIN` keyword, for example:
-
-- `INNER HASH JOIN`
-- `OUTER MERGE JOIN`
-- `LEFT LOOKUP JOIN`
-- `CROSS HASH JOIN`
-- `INNER INVERTED JOIN`
-- `LEFT INVERTED JOIN`
-
-You cannot specify the hint with a bare hint keyword (e.g., `MERGE`) - in that case, you must add the `INNER` keyword. For example, `a INNER MERGE JOIN b` will work, but `a MERGE JOIN b` will not work.
-
-{{site.data.alerts.callout_info}}
-You cannot specify join hints with a bare hint keyword (e.g., `MERGE`) due to SQL's implicit `AS` syntax. If you're not careful, you can make `MERGE` an alias for a table; for example, `a MERGE JOIN b` will be interpreted as having an implicit `AS` and be executed as `a AS MERGE JOIN b`, which is just a long way of saying `a JOIN b`. Because the resulting query might execute without returning any hint-related error (because it is valid SQL), it will seem like the join hint "worked", but actually it didn't affect which join algorithm was used. In this case, the correct syntax is `a INNER MERGE JOIN b`.
-{{site.data.alerts.end}}
-
-### Supported join algorithms
-
-- `HASH`: Forces a hash join; in other words, it disables merge and lookup joins. A hash join is always possible, even if there are no equality columns - CockroachDB considers the nested loop join with no index a degenerate case of the hash join (i.e., a hash table with one bucket).
-
-- `MERGE`: Forces a merge join, even if it requires re-sorting both sides of the join.
-
-- `LOOKUP`: Forces a lookup join into the right side; the right side must be a table with a suitable index. Note that `LOOKUP` can only be used with `INNER` and `LEFT` joins.
-
-If it is not possible to use the algorithm specified in the hint, an error is signaled.
-
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> To make the optimizer prefer lookup joins to merge joins when performing foreign key checks, set the `prefer_lookup_joins_for_fks` [session variable](set-vars.html) to `on`.
-{{site.data.alerts.end}}
-
-### Additional considerations
-
-- This syntax is consistent with the [SQL Server syntax for join hints](https://docs.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-join?view=sql-server-2017), except that:
-
-  - SQL Server uses `LOOP` instead of `LOOKUP`.
-
-  - CockroachDB does not support `LOOP` and instead supports `LOOKUP` for the specific case of nested loop joins with an index.
-
-- When you specify a join hint, the two tables will not be reordered by the optimizer. The reordering behavior has the following characteristics, which can be affected by hints:
-
-  - Given `a JOIN b`, CockroachDB will not try to commute to `b JOIN a`. This means that you will need to pay attention to this ordering, which is especially important for lookup joins. Without a hint, `a JOIN b` might be executed as `b INNER LOOKUP JOIN a` using an index into `a`, whereas `a INNER LOOKUP JOIN b` requires an index into `b`.
-
-  - `(a JOIN b) JOIN c` might be changed to `a JOIN (b JOIN c)`, but this does not happen if `a JOIN b` uses a hint; the hint forces that particular join to happen as written in the query.
-
-- You should reconsider hint usage with each new release of CockroachDB. Due to improvements in the optimizer, hints specified to work with an older version may cause decreased performance in a newer version.
-
-## Preferring the nearest index
-
-Given multiple identical [indexes](indexes.html) that have different locality constraints using [replication zones](configure-replication-zones.html), the optimizer will prefer the index that is closest to the gateway node that is planning the query. In a properly configured geo-distributed cluster, this can lead to performance improvements due to improved data locality and reduced network traffic.
-
-{{site.data.alerts.callout_info}}
-This feature is only available to users with an [Enterprise license](enterprise-licensing.html). For insight into how to use this feature to get low latency, consistent reads in multi-region deployments, see the [Duplicate Indexes](topology-follower-reads.html) topology pattern.
-{{site.data.alerts.end}}
-
-This feature enables scenarios such as:
-
-- Reference data such as a table of postal codes that can be replicated to different regions, and queries will use the copy in the same region. See [Example - zone constraints](#zone-constraints) for more details.
-- Optimizing for local reads (potentially at the expense of writes) by adding leaseholder preferences to your zone configuration. See [Example - leaseholder preferences](#leaseholder-preferences) for more details.
-
-To take advantage of this feature, you need to:
-
-1. Have an [Enterprise license](enterprise-licensing.html).
-2. Determine which data consists of reference tables that are rarely updated (such as postal codes) and can therefore be easily replicated to different regions.
-3. Create multiple [secondary indexes](indexes.html) on the reference tables. **Note that these indexes must include (in key or using [`STORED`](create-index.html#store-columns)) *every* column that you wish to query**. For example, if you run `SELECT * from db.table` and not every column of `db.table` is in the set of secondary indexes you created, the optimizer will have no choice but to fall back to the primary index.
-4. Create [replication zones](configure-replication-zones.html) for each index.
-
-With the above pieces in place, the optimizer will automatically choose the index nearest the gateway node that is planning the query.
-
-{{site.data.alerts.callout_info}}
-The optimizer does not actually understand geographic locations, i.e., the relative closeness of the gateway node to other nodes that are located to its "east" or "west". It is matching against the [node locality constraints](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes) you provided when you configured your replication zones.
-{{site.data.alerts.end}}
-
-## Examples
-
-#### Zone constraints
-
-We can demonstrate the necessary configuration steps using a local cluster. The instructions below assume that you are already familiar with:
-
-- How to [start a local cluster](start-a-local-cluster.html).
-- The syntax for [assigning node locality when configuring replication zones](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes).
-- Using [the built-in SQL client](cockroach-sql.html).
-
-First, start 3 local nodes as shown below. Use the [`--locality`](cockroach-start.html#locality) flag to put them each in a different region as denoted by `region=usa`, `region=eu`, etc.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach start --locality=region=usa  --insecure --store=/tmp/node0 --listen-addr=localhost:26257 \
-  --http-port=8888  --join=localhost:26257,localhost:26258,localhost:26259 --background
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach start --locality=region=eu   --insecure --store=/tmp/node1 --listen-addr=localhost:26258 \
-  --http-port=8889  --join=localhost:26257,localhost:26258,localhost:26259 --background
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach start --locality=region=apac --insecure --store=/tmp/node2 --listen-addr=localhost:26259 \
-  --http-port=8890  --join=localhost:26257,localhost:26258,localhost:26259 --background
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach init --insecure --host=localhost --port=26257
-~~~
-
-Next, from the SQL client, add your organization name and Enterprise license:
-
-{% include_cached copy-clipboard.html %}
-~~~ sh
-$ cockroach sql --insecure --host=localhost --port=26257
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING cluster.organization = 'FooCorp - Local Testing';
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING enterprise.license = 'xxxxx';
-~~~
-
-Create a test database and table. The table will have 3 indexes into the same data. Later, we'll configure the cluster to associate each of these indexes with a different datacenter using replication zones.
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE IF NOT EXISTS test;
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> USE test;
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-CREATE TABLE postal_codes (
-    id INT PRIMARY KEY,
-    code STRING,
-    INDEX idx_eu (id) STORING (code),
-    INDEX idx_apac (id) STORING (code)
-);
-~~~
-
-Next, we modify the replication zone configuration via SQL so that:
-
-- Nodes in the USA will use the primary key index.
-- Nodes in the EU will use the `postal_codes@idx_eu` index (which is identical to the primary key index).
-- Nodes in APAC will use the `postal_codes@idx_apac` index (which is also identical to the primary key index).
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-ALTER TABLE postal_codes CONFIGURE ZONE USING constraints='["+region=usa"]';
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-ALTER INDEX postal_codes@idx_eu CONFIGURE ZONE USING constraints='["+region=eu"]';
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-ALTER INDEX postal_codes@idx_apac CONFIGURE ZONE USING constraints='["+region=apac"]';
-~~~
-
-To verify this feature is working as expected, we'll query the database from each of our local nodes as shown below. Each node has been configured to be in a different region, and it should now be using the index pinned to that region.
-
-{{site.data.alerts.callout_info}}
-In a geo-distributed scenario with a cluster that spans multiple datacenters, it may take time for the optimizer to fetch schemas from other nodes the first time a query is planned; thereafter, the schema should be cached locally.
-
-For example, if you have 11 nodes, you may see 11 queries with high latency due to schema cache misses.  Once all nodes have cached the schema locally, the latencies will drop.
-
-This behavior may also cause the [Statements page of the Web UI](ui-statements-page.html) to show misleadingly high latencies until schemas are cached locally.
-{{site.data.alerts.end}}
-
-As expected, the node in the USA region uses the primary key index.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --host=localhost --port=26257 --database=test -e 'EXPLAIN SELECT * FROM postal_codes WHERE id=1;'
-~~~
-
-~~~
-  tree |        field        |     description
--------+---------------------+-----------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 1
-       | table               | postal_codes@primary
-       | spans               | [/1 - /1]
-(6 rows)
-~~~
-
-As expected, the node in the EU uses the `idx_eu` index.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --host=localhost --port=26258 --database=test -e 'EXPLAIN SELECT * FROM postal_codes WHERE id=1;'
-~~~
-
-~~~
-  tree |        field        |     description
--------+---------------------+----------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 1
-       | table               | postal_codes@idx_eu
-       | spans               | [/1 - /1]
-(6 rows)
-~~~
-
-As expected, the node in APAC uses the `idx_apac` index.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --host=localhost --port=26259 --database=test -e 'EXPLAIN SELECT * FROM postal_codes WHERE id=1;'
-~~~
-
-~~~
-  tree |        field        |      description
--------+---------------------+------------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 1
-       | table               | postal_codes@idx_apac
-       | spans               | [/1 - /1]
-(6 rows)
-~~~
-
-You'll need to make changes to the above configuration to reflect your [production environment](recommended-production-settings.html), but the concepts will be the same.
-
-#### Leaseholder preferences
-
-If you provide [leaseholder preferences](configure-replication-zones.html#lease_preferences) in addition to replication zone constraints, the optimizer will attempt to take your leaseholder preferences into account as well when selecting an index for your query. There are several factors to keep in mind:
-
-- Zone constraints are always respected (hard constraint), whereas lease preferences are taken into account as "additional information" -- as long as they do not contradict the zone constraints.
-
-- The optimizer does not consider the real-time location of leaseholders when selecting an index; it is pattern matching on the text values passed in the configuration (e.g., the [`ALTER INDEX`](alter-index.html) statements shown below). For the same reason, the optimizer only matches against the first locality in your `lease_preferences` array.
-
-- The optimizer may use an index that satisfies your leaseholder preferences even though that index has moved to a different node/region due to [leaseholder rebalancing](architecture/replication-layer.html#leaseholder-rebalancing). This can cause slower performance than you expected. Therefore, you should only use this feature if you’re confident you know where the leaseholders will end up based on your cluster's usage patterns. We recommend thoroughly testing your configuration to ensure the optimizer is selecting the index(es) you expect.
-
-In this example, we'll set up an authentication service using the access token / refresh token pattern from [OAuth 2](https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2). To support fast local reads in our geo-distributed use case, we will have 3 indexes into the same authentication data: one for each region of our cluster. We configure each index using zone configurations and lease preferences so that the optimizer will use the local index for better performance.
-
-The instructions below assume that you are already familiar with:
-
-- How to [start a local cluster](start-a-local-cluster.html).
-- The syntax for [assigning node locality when configuring replication zones](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes).
-- Using [the built-in SQL client](cockroach-sql.html).
-
-First, start 3 local nodes as shown below. Use the [`--locality`](cockroach-start.html#locality) flag to put them each in a different region.
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach start --locality=region=us-east  --insecure --store=/tmp/node0 --listen-addr=localhost:26257 \
-  --http-port=8888  --join=localhost:26257,localhost:26258,localhost:26259 --background
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach start --locality=region=us-central   --insecure --store=/tmp/node1 --listen-addr=localhost:26258 \
-  --http-port=8889  --join=localhost:26257,localhost:26258,localhost:26259 --background
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach start --locality=region=us-west --insecure --store=/tmp/node2 --listen-addr=localhost:26259 \
-  --http-port=8890  --join=localhost:26257,localhost:26258,localhost:26259 --background
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ cockroach init --insecure --host=localhost --port=26257
-~~~
-
-From the SQL client, add your organization name and Enterprise license:
-
-{% include_cached copy-clipboard.html %}
-~~~ sh
-$ cockroach sql --insecure --host=localhost --port=26257
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING cluster.organization = 'FooCorp - Local Testing';
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING enterprise.license = 'xxxxx';
-~~~
-
-Create an authentication database and table:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE if NOT EXISTS auth;
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> USE auth;
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE token (
-	token_id VARCHAR(100) NULL,
-	access_token VARCHAR(4000) NULL,
-	refresh_token VARCHAR(4000) NULL
-  );
-~~~
-
-Create the indexes for each region:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX token_id_west_idx ON token (token_id) STORING (access_token, refresh_token);
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX token_id_central_idx ON token (token_id) STORING (access_token, refresh_token);
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX token_id_east_idx ON token (token_id) STORING (access_token, refresh_token);
-~~~
-
-Enter zone configurations to distribute replicas across the cluster as follows:
-
-- For the "East" index, store 2 replicas in the East, 2 in Central, and 1 in the West. Further, prefer that the leaseholders for that index live in the East or, failing that, in the Central region.
-- Follow the same replica and leaseholder patterns for each of the Central and West regions.
-
-The idea is that, for example, `token_id_east_idx` will have sufficient replicas (2/5) so that even if one replica goes down, the leaseholder will stay in the East region. That way, if a query comes in that accesses the columns covered by that index from the East gateway node, the optimizer will select `token_id_east_idx` for fast reads.
-
-{{site.data.alerts.callout_info}}
-The `ALTER TABLE` statement below is not required since it's later made redundant by the `token_id_west_idx` index. In production, you might go with the `ALTER TABLE` to put your table's lease preferences in the West, and then create only 2 indexes (for East and Central); however, the use of 3 indexes makes the example easier to understand.
-{{site.data.alerts.end}}
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE token CONFIGURE ZONE USING
-        num_replicas = 5, constraints = '{+region=us-east: 1, +region=us-central: 2, +region=us-west: 2}', lease_preferences = '[[+region=us-west], [+region=us-central]]';
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX token_id_east_idx CONFIGURE ZONE USING num_replicas = 5,
-        constraints = '{+region=us-east: 2, +region=us-central: 2, +region=us-west: 1}', lease_preferences = '[[+region=us-east], [+region=us-central]]';
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX token_id_central_idx CONFIGURE ZONE USING num_replicas = 5,
-        constraints = '{+region=us-east: 2, +region=us-central: 2, +region=us-west: 1}', lease_preferences = '[[+region=us-central], [+region=us-east]]';
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX token_id_west_idx CONFIGURE ZONE USING num_replicas = 5,
-        constraints = '{+region=us-west: 2, +region=us-central: 2, +region=us-east: 1}', lease_preferences = '[[+region=us-west], [+region=us-central]]';
-~~~
-
-Next let's [check our zone configurations](show-zone-configurations.html) to make sure they match our expectation:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SHOW ZONE CONFIGURATIONS;
-~~~
-
-The output should include the following:
-
-~~~
-                       target                      |                                    raw_config_sql
----------------------------------------------------+---------------------------------------------------------------------------------------
-  RANGE default                                    | ALTER RANGE default CONFIGURE ZONE USING
-                                                   |     range_min_bytes = 134217728,
-                                                   |     range_max_bytes = 536870912,
-                                                   |     gc.ttlseconds = 90000,
-                                                   |     num_replicas = 3,
-                                                   |     constraints = '[]',
-                                                   |     lease_preferences = '[]'
-  DATABASE system                                  | ALTER DATABASE system CONFIGURE ZONE USING
-                                                   |     range_min_bytes = 134217728,
-                                                   |     range_max_bytes = 536870912,
-                                                   |     gc.ttlseconds = 90000,
-                                                   |     num_replicas = 5,
-                                                   |     constraints = '[]',
-                                                   |     lease_preferences = '[]'
-  RANGE meta                                       | ALTER RANGE meta CONFIGURE ZONE USING
-                                                   |     range_min_bytes = 134217728,
-                                                   |     range_max_bytes = 536870912,
-                                                   |     gc.ttlseconds = 3600,
-                                                   |     num_replicas = 5,
-                                                   |     constraints = '[]',
-                                                   |     lease_preferences = '[]'
-  RANGE system                                     | ALTER RANGE system CONFIGURE ZONE USING
-                                                   |     range_min_bytes = 134217728,
-                                                   |     range_max_bytes = 536870912,
-                                                   |     gc.ttlseconds = 90000,
-                                                   |     num_replicas = 5,
-                                                   |     constraints = '[]',
-                                                   |     lease_preferences = '[]'
-  RANGE liveness                                   | ALTER RANGE liveness CONFIGURE ZONE USING
-                                                   |     range_min_bytes = 134217728,
-                                                   |     range_max_bytes = 536870912,
-                                                   |     gc.ttlseconds = 600,
-                                                   |     num_replicas = 5,
-                                                   |     constraints = '[]',
-                                                   |     lease_preferences = '[]'
-  TABLE system.public.replication_constraint_stats | ALTER TABLE system.public.replication_constraint_stats CONFIGURE ZONE USING
-                                                   |     gc.ttlseconds = 600,
-                                                   |     constraints = '[]',
-                                                   |     lease_preferences = '[]'
-  TABLE system.public.replication_stats            | ALTER TABLE system.public.replication_stats CONFIGURE ZONE USING
-                                                   |     gc.ttlseconds = 600,
-                                                   |     constraints = '[]',
-                                                   |     lease_preferences = '[]'
-  TABLE auth.public.token                          | ALTER TABLE auth.public.token CONFIGURE ZONE USING
-                                                   |     num_replicas = 5,
-                                                   |     constraints = '{+region=us-central: 2, +region=us-east: 1, +region=us-west: 2}',
-                                                   |     lease_preferences = '[[+region=us-west], [+region=us-central]]'
-  INDEX auth.public.token@token_id_east_idx        | ALTER INDEX auth.public.token@token_id_east_idx CONFIGURE ZONE USING
-                                                   |     num_replicas = 5,
-                                                   |     constraints = '{+region=us-central: 2, +region=us-east: 2, +region=us-west: 1}',
-                                                   |     lease_preferences = '[[+region=us-east], [+region=us-central]]'
-  INDEX auth.public.token@token_id_central_idx     | ALTER INDEX auth.public.token@token_id_central_idx CONFIGURE ZONE USING
-                                                   |     num_replicas = 5,
-                                                   |     constraints = '{+region=us-central: 2, +region=us-east: 2, +region=us-west: 1}',
-                                                   |     lease_preferences = '[[+region=us-central], [+region=us-east]]'
-  INDEX auth.public.token@token_id_west_idx        | ALTER INDEX auth.public.token@token_id_west_idx CONFIGURE ZONE USING
-                                                   |     num_replicas = 5,
-                                                   |     constraints = '{+region=us-central: 2, +region=us-east: 1, +region=us-west: 2}',
-                                                   |     lease_preferences = '[[+region=us-west], [+region=us-central]]'
-(11 rows)
-~~~
-
-Now that we've set up our indexes the way we want them, we need to insert some data. The first statement below inserts 10,000 rows of placeholder data; the second inserts a row with a specific UUID string that we'll later query against to check which index is used.
-
-{{site.data.alerts.callout_info}}
-On a freshly created cluster like this one, you may need to wait a moment after adding the data to give [automatic statistics](#table-statistics) time to update. Then, the optimizer can generate a query plan that uses the expected index.
-{{site.data.alerts.end}}
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> INSERT
-  INTO
-      token (token_id, access_token, refresh_token)
-  SELECT
-      gen_random_uuid()::STRING,
-      gen_random_uuid()::STRING,
-      gen_random_uuid()::STRING
-  FROM
-      generate_series(1, 10000);
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> INSERT
-  INTO
-      token (token_id, access_token, refresh_token)
-  VALUES
-      (
-          '2E1B5BFE-6152-11E9-B9FD-A7E0F13211D9',
-          '49E36152-6152-11E9-8CDC-3682F23211D9',
-          '4E0E91B6-6152-11E9-BAC1-3782F23211D9'
-      );
-~~~
-
-Finally, we [`EXPLAIN`](explain.html) a [selection query](selection-queries.html) from each node to verify which index is being queried against. For example, when running the query shown below against the `us-west` node, we expect it to use the `token_id_west_idx` index.
-
-{% include_cached copy-clipboard.html %}
-~~~ sh
-$ cockroach sql --insecure --host=localhost --port=26259 --database=auth # "West" node
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> EXPLAIN
-      SELECT
-          access_token, refresh_token
-      FROM
-          token
-      WHERE
-          token_id = '2E1B5BFE-6152-11E9-B9FD-A7E0F13211D9';
-~~~
-
-~~~
-  tree |        field        |                                     description
--------+---------------------+--------------------------------------------------------------------------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 1
-       | table               | token@token_id_east_idx
-       | spans               | [/'2E1B5BFE-6152-11E9-B9FD-A7E0F13211D9' - /'2E1B5BFE-6152-11E9-B9FD-A7E0F13211D9']
-(6 rows)
-~~~
-
-Similarly, queries from the `us-east` node should use the `token_id_east_idx` index (and the same should be true for `us-central`).
-
-{% include_cached copy-clipboard.html %}
-~~~ sh
-$ cockroach sql --insecure --host=localhost --port=26257 --database=auth # "East" node
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> EXPLAIN
-      SELECT
-          access_token, refresh_token
-      FROM
-          token
-      WHERE
-          token_id = '2E1B5BFE-6152-11E9-B9FD-A7E0F13211D9';
-~~~
-
-~~~
-  tree |        field        |                                     description
--------+---------------------+--------------------------------------------------------------------------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 1
-       | table               | token@token_id_east_idx
-       | spans               | [/'2E1B5BFE-6152-11E9-B9FD-A7E0F13211D9' - /'2E1B5BFE-6152-11E9-B9FD-A7E0F13211D9']
-(6 rows)
-~~~
-
-You'll need to make changes to the above configuration to reflect your [production environment](recommended-production-settings.html), but the concepts will be the same.
-
-## Known Limitations
-
-* {% include {{page.version.version}}/known-limitations/old-multi-col-stats.md %}
-* {% include {{page.version.version}}/known-limitations/single-col-stats-deletion.md %}
-* {% include {{page.version.version}}/known-limitations/stats-refresh-upgrade.md %}
-
-## See also
-
-- [`JOIN` expressions](joins.html)
-- [`SET (session variable)`](set-vars.html)
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`RESET CLUSTER SETTING`](reset-cluster-setting.html)
-- [`SHOW (session variable)`](show-vars.html)
-- [`CREATE STATISTICS`](create-statistics.html)
-- [`SHOW STATISTICS`](show-statistics.html)
-- [`EXPLAIN`](explain.html)
diff --git a/src/current/v20.2/crdb-internal.md b/src/current/v20.2/crdb-internal.md
deleted file mode 100644
index e961d35851a..00000000000
--- a/src/current/v20.2/crdb-internal.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: crdb_internal
-summary: The crdb_internal schema contains read-only views that you can use for introspection into CockroachDB internals.
-toc: true
----
-
-The `crdb_internal` [system catalog](system-catalogs.html) is a schema that contains information about internal objects, processes, and metrics related to a specific database.
-
-{{site.data.alerts.callout_danger}}
-We do not recommend using `crdb_internal` tables in production environments for the following reasons:
-
-- The contents of `crdb_internal` are unstable, and subject to change in new releases of CockroachDB, without prior notice.
-- There are memory and latency costs associated with each table in `crdb_internal`. Accessing the tables in the schema can impact cluster stability and performance.
-{{site.data.alerts.end}}
-
-## Data exposed by `crdb_internal`
-
-Each table in `crdb_internal` corresponds to an internal object, process, or metric, for a specific database. `crdb_internal` tables are read-only.
-
-In CockroachDB {{ page.version.version }}, `crdb_internal` includes the following tables:
-
-Table | Description
--------|-------
-`backward_dependencies` | Contains information about backward dependencies.
-`builtin_functions` | Contains information about supported [functions](functions-and-operators.html).
-`cluster_database_privileges` | Contains information about the [database privileges](authorization.html#privileges) on your cluster.
-`cluster_queries` | Contains information about queries running on your cluster.
-`cluster_sessions` | Contains information about cluster sessions, including current and past queries.
-`cluster_settings` | Contains information about [cluster settings](cluster-settings.html).
-`cluster_transactions` | Contains information about transactions running on your cluster.
-`create_statements` | Contains information about tables and indexes in your database.
-`create_type_statements` | Contains information about [user-defined types](enum.html) in your database.
-`databases` | Contains information about the databases in your cluster.
-`feature_usage` | Contains information about feature usage on your cluster.
-`forward_dependencies` | Contains information about forward dependencies.
-`gossip_alerts` | Contains information about gossip alerts.
-`gossip_liveness` | Contains information about your cluster's gossip liveness.
-`gossip_network` | Contains information about your cluster's gossip network.
-`gossip_nodes` | Contains information about nodes in your cluster's gossip network.
-`index_columns` | Contains information about indexed columns in your cluster.
-`jobs` | Contains information about [jobs](show-jobs.html) running on your cluster.
-`kv_node_status` | Contains information about node status at the [key-value layer](architecture/storage-layer.html).
-`kv_store_status` | Contains information about the key-value store for your cluster.
-`leases` | Contains information about [leases](architecture/replication-layer.html#leases) in your cluster.
-`node_build_info` | Contains information about nodes in your cluster.
-`node_metrics` | Contains metrics for nodes in your cluster.
-`node_queries` | Contains information about queries running on nodes in your cluster.
-`node_runtime_info` | Contains runtime information about nodes in your cluster.
-`node_sessions` | Contains information about sessions to nodes in your cluster.
-`node_statement_statistics` | Contains statement statistics for nodes in your cluster.
-`node_transaction_statistics` | Contains transaction statistics for nodes in your cluster.
-`node_transactions` | Contains information about transactions for nodes in your cluster.
-`node_txn_stats` | Contains transaction statistics for nodes in your cluster.
-`partitions` | Contains information about [partitions](partitioning.html) in your cluster.
-`predefined_comments` | Contains predefined comments about your cluster.
-`ranges` | Contains information about ranges in your cluster.
-`ranges_no_leases` | Contains information about ranges in your cluster, without leases.
-`schema_changes` | Contains information about schema changes in your cluster.
-`session_trace` | Contains session trace information for your cluster.
-`session_variables` | Contains information about [session variables](set-vars.html) in your cluster.
-`table_columns` | Contains information about table columns in your cluster.
-`table_indexes` | Contains information about table indexes in your cluster.
-`table_row_statistics` | Contains row count statistics for tables in the current database.
-`tables` | Contains information about tables in your cluster.
-`zones` | Contains information about [zone configurations](configure-replication-zones.html) in your cluster.
-
-To list the `crdb_internal` tables for the [current database](sql-name-resolution.html#current-database), use the following [`SHOW TABLES`](show-tables.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM crdb_internal;
-~~~
-
-~~~
-   schema_name  |         table_name          | type  | owner | estimated_row_count
-----------------+-----------------------------+-------+-------+----------------------
-  crdb_internal | backward_dependencies       | table | NULL  |                NULL
-  crdb_internal | builtin_functions           | table | NULL  |                NULL
-  crdb_internal | cluster_database_privileges | table | NULL  |                NULL
-  ...
-~~~
-
-## Querying `crdb_internal` tables
-
-To get detailed information about objects, processes, or metrics related to your database, you can read from the `crdb_internal` table that corresponds to the item of interest.
-
-{{site.data.alerts.callout_success}}
-To ensure that you can view all of the tables in `crdb_internal`, query the tables as a user with [`admin` privileges](authorization.html#admin-role).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Unless specified otherwise, queries to `crdb_internal` assume the [current database](sql-name-resolution.html#current-database).
-{{site.data.alerts.end}}
-
-For example, to return the `crdb_internal` table for the ranges of the [`movr`](movr.html) database, you can use the following statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM movr.crdb_internal.ranges;
-~~~
-
-~~~
-  range_id |                                                                         start_key                                                                          |                                        start_pretty                                         |                                                                          end_key                                                                           |                                         end_pretty                                          | database_name |           table_name            | index_name | replicas |    replica_localities    | learner_replicas |       split_enforced_until       | lease_holder | range_size
------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------+---------------+---------------------------------+------------+----------+--------------------------+------------------+----------------------------------+--------------+-------------
-         1 |                                                                                                                                                            | /Min                                                                                        | \004\000liveness-                                                                                                                                          | /System/NodeLiveness                                                                        |               |                                 |            | {1}      | {"region=us-east1,az=b"} | {}               | NULL                             |            1 |       8323
-         2 | \004\000liveness-                                                                                                                                          | /System/NodeLiveness                                                                        | \004\000liveness.                                                                                                                                          | /System/NodeLivenessMax                                                                     |               |                                 |            | {1}      | {"region=us-east1,az=b"} | {}               | NULL                             |            1 |       9278
-         3 | \004\000liveness.                                                                                                                                          | /System/NodeLivenessMax                                                                     | \004tsd                                                                                                                                                    | /System/tsd                                                                                 |               |                                 |            | {1}      | {"region=us-east1,az=b"} | {}               | NULL                             |            1 |      32377
-         4 | \004tsd                                                                                                                                                    | /System/tsd                                                                                 | \004tse                                                                                                                                                    | /System/"tse"                                                                               |               |                                 |            | {1}      | {"region=us-east1,az=b"} | {}               | NULL                             |            1 |    4067446
-(65 rows)
-~~~
-
-## See also
-
-- [`SHOW`](show-vars.html)
-- [`SHOW COLUMNS`](show-columns.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`SHOW CREATE`](show-create.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [`SHOW INDEX`](show-index.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [`SHOW TABLES`](show-tables.html)
-- [SQL Name Resolution](sql-name-resolution.html)
-- [System Catalogs](system-catalogs.html)
diff --git a/src/current/v20.2/create-changefeed.md b/src/current/v20.2/create-changefeed.md
deleted file mode 100644
index c3b42fc7773..00000000000
--- a/src/current/v20.2/create-changefeed.md
+++ /dev/null
@@ -1,350 +0,0 @@
----
-title: CREATE CHANGEFEED
-summary: The CREATE CHANGEFEED statement creates a changefeed of row-level change subscriptions in a configurable format to a configurable sink.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-`CREATE CHANGEFEED` is an [Enterprise-only](enterprise-licensing.html) feature. For the core version, see [`EXPERIMENTAL CHANGEFEED FOR`](changefeed-for.html).
-{{site.data.alerts.end}}
-
-The `CREATE CHANGEFEED` [statement](sql-statements.html) creates a new Enterprise changefeed, which targets an allowlist of tables, called "watched rows".  Every change to a watched row is emitted as a record in a configurable format (`JSON` or Avro) to a configurable sink ([Kafka](https://kafka.apache.org/) or a [cloud storage sink](#cloud-storage-sink)). You can [create](#create-a-changefeed-connected-to-kafka), [pause](#pause-a-changefeed), [resume](#resume-a-paused-changefeed), or [cancel](#cancel-a-changefeed) an Enterprise changefeed.
-
-For more information, see [Stream Data Out of CockroachDB Using Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html).
-
-## Required privileges
-
-To create a changefeed, the user must be a member of the `admin` role or have the [`CREATECHANGEFEED`](create-user.html#create-a-user-that-can-control-changefeeds) parameter set.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_changefeed.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table (or tables in a comma separated list) to create a changefeed for.<br><br>**Note:** Changefeeds do not share internal buffers, so each running changefeed will increase total memory usage. To watch multiple tables, we recommend creating a changefeed with a comma-separated list of tables.
-`sink` | The location of the configurable sink. The scheme of the URI indicates the type. For more information, see [Sink URI](#sink-uri) below.
-`option` / `value` | For a list of available options and their values, see [Options](#options) below.
-
-<!-- `IF NOT EXISTS` | Create a new changefeed only if a changefeed of the same name does not already exist; if one does exist, do not return an error.
-`name` | The name of the changefeed to create, which [must be unique](#create-fails-name-already-in-use) and follow these [identifier rules](keywords-and-identifiers.html#identifiers). -->
-
-### Sink URI
-
-The sink URI follows the basic format of:
-
-~~~
-'{scheme}://{host}:{port}?{query_parameters}'
-~~~
-
-URI Component      | Description
--------------------+------------------------------------------------------------------
-`scheme`           | The type of sink: [`kafka`](#kafka) or any [cloud storage sink](#cloud-storage-sink).
-`host`             | The sink's hostname or IP address.
-`port`             | The sink's port.
-`query_parameters` | The sink's [query parameters](#query-parameters).
-
-#### Kafka
-
-Example of a Kafka sink URI:
-
-~~~
-'kafka://broker.address.com:9092?topic_prefix=bar_&tls_enabled=true&ca_cert=LS0tLS1CRUdJTiBDRVJUSUZ&sasl_enabled=true&sasl_user=petee&sasl_password=bones'
-~~~
-
-#### Cloud storage sink
-
-Use a cloud storage sink to deliver changefeed data to OLAP or big data systems without requiring transport via Kafka.
-
-{{site.data.alerts.callout_info}}
-Currently, cloud storage sinks only work with `JSON` and emits newline-delimited `JSON` files.
-{{site.data.alerts.end}}
-
-Example of a cloud storage sink URI:
-
-~~~
-`experimental-s3://acme-co/employees?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456`
-~~~
-
-Cloud storage sink URIs must be prepended with `experimental-` when working with changefeeds. For more information on the sink URI structure, see [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html#example-file-urls).
-
-#### Query parameters
-
-{% include {{ page.version.version }}/cdc/url-encoding.md %}
-
-Query parameters include:
-
-Parameter          | <div style="width:100px">Sink Type</div>      | <div style="width:75px">Type</div>  | Description
--------------------+-----------------------------------------------+-------------------------------------+------------------------------------------------------------
-`topic_prefix`     | [Kafka](#kafka), [cloud](#cloud-storage-sink) | [`STRING`](string.html)             | Adds a prefix to all topic names.<br><br>For example, `CREATE CHANGEFEED FOR TABLE foo INTO 'kafka://...?topic_prefix=bar_'` would emit rows under the topic `bar_foo` instead of `foo`.
-`tls_enabled`      | [Kafka](#kafka)                               | [`BOOL`](bool.html)                 | If `true`, enable Transport Layer Security (TLS) on the connection to Kafka. This can be used with a `ca_cert`. <br><br>**Default:** `false`
-`ca_cert`          | [Kafka](#kafka)                               | [`STRING`](string.html)             | The base64-encoded `ca_cert` file.<br><br>Note: To encode your `ca.cert`, run `base64 -w 0 ca.cert`.
-`client_cert`      | [Kafka](#kafka)                               | [`STRING`](string.html)             | The base64-encoded Privacy Enhanced Mail (PEM) certificate. This is used with `client_key`.
-`client_key`       | [Kafka](#kafka)                               | [`STRING`](string.html)             | The base64-encoded private key for the PEM certificate. This is used with `client_cert`.
-`sasl_enabled`     | [Kafka](#kafka)                               | [`BOOL`](bool.html)                 | If `true`, [use SASL/PLAIN to authenticate](https://docs.confluent.io/current/kafka/authentication_sasl/authentication_sasl_plain.html). This requires a `sasl_user` and `sasl_password`. <br><br>**Default:** `false`
-`sasl_user`        | [Kafka](#kafka)                               | [`STRING`](string.html)             | Your SASL username.
-`sasl_password`    | [Kafka](#kafka)                               | [`STRING`](string.html)             | Your SASL password.
-`file_size`        | [cloud](#cloud-storage-sink)                  | [`STRING`](string.html)             | The file will be flushed (i.e., written to the sink) when it exceeds the specified file size. This can be used with the [`WITH resolved` option](#options), which flushes on a specified cadence. <br><br>**Default:** `16MB`
-`insecure_tls_skip_verify` |  [Kafka](#kafka)                      | [`BOOL`](bool.html)                 | <span class="version-tag">New in v20.2:</span> If `true`, disable client-side validation of responses. **Warning:** Use this query parameter with caution, as it creates [MITM](https://en.wikipedia.org/wiki/Man-in-the-middle_attack) vulnerabilities unless combined with another method of authentication. <br><br>**Default:** `false`
-
-### Options
-
-Option | Value | Description
--------|-------|------------
-`updated` | N/A | Include updated timestamps with each row.<br><br>If a `cursor` is provided, the "updated" timestamps will match the [MVCC](architecture/storage-layer.html#mvcc) timestamps of the emitted rows, and there is no initial scan. If a `cursor` is not provided, the changefeed will perform an initial scan (as of the time the changefeed was created), and the "updated" timestamp for each change record emitted in the initial scan will be the timestamp of the initial scan. Similarly, when a [backfill is performed for a schema change](stream-data-out-of-cockroachdb-using-changefeeds.html#schema-changes-with-column-backfill), the "updated" timestamp is set to the first timestamp for when the new schema is valid.
-<a name="resolved-option"></a>`resolved` | [Duration string](https://pkg.go.dev/time#ParseDuration) | Emits [resolved timestamp](stream-data-out-of-cockroachdb-using-changefeeds.html#resolved-def) events per changefeed in a format dependent on the connected sink. Resolved timestamp events do not emit until all ranges in the changefeed have progressed to a specific point in time. <br><br>Set an optional minimal duration between emitting resolved timestamps. Example: `resolved='10s'`. This option will **only** emit a resolved timestamp event if the timestamp has advanced and at least the optional duration has elapsed. If unspecified, all resolved timestamps are emitted as the high-water mark advances.
-`envelope` | `key_only` / `wrapped` | Use `key_only` to emit only the key and no value, which is faster if you only want to know when the key changes.<br><br>Default: `envelope=wrapped`
-`cursor` | [Timestamp](as-of-system-time.html#parameters)  | Emit any changes after the given timestamp, but does not output the current state of the table first. If `cursor` is not specified, the changefeed starts by doing an initial scan of all the watched rows and emits the current value, then moves to emitting any changes that happen after the scan.<br><br>When starting a changefeed at a specific `cursor`, the `cursor` cannot be before the configured garbage collection window (see [`gc.ttlseconds`](configure-replication-zones.html#replication-zone-variables)) for the table you're trying to follow; otherwise, the changefeed will error. With default garbage collection settings, this means you cannot create a changefeed that starts more than 25 hours in the past.<br><br>`cursor` can be used to [start a new changefeed where a previous changefeed ended.](#start-a-new-changefeed-where-another-ended)<br><br>Example: `CURSOR='1536242855577149065.0000000000'`
-`format` | `json` / `experimental_avro` | Format of the emitted record. Currently, support for [Avro is limited and experimental](#avro-limitations). For mappings of CockroachDB types to Avro types, [see the table below](#avro-types). <br><br>Default: `format=json`
-`confluent_schema_registry` | Schema Registry address | The [Schema Registry](https://docs.confluent.io/current/schema-registry/docs/index.html#sr) address is required to use `experimental_avro`.
-`key_in_value` | N/A | Make the [primary key](primary-key.html) of a deleted row recoverable in sinks where each message has a value but not a key (most have a key and value in each message). `key_in_value` is automatically used for these sinks (currently only [cloud storage sinks](#cloud-storage-sink)).
-`diff` | N/A |  Publish a `before` field with each message, which includes the value of the row before the update was applied.
-`compression` | `gzip` |  Compress changefeed data files written to a [cloud storage sink](#cloud-storage-sink). Currently, only [Gzip](https://www.gnu.org/software/gzip/) is supported for compression.
-`protect_data_from_gc_on_pause` | N/A |  When a [changefeed is paused](pause-job.html), ensure that the data needed to [resume the changefeed](resume-job.html) is not garbage collected.<br><br>Note: If you use this option, changefeeds left paused can prevent garbage collection for long periods of time.
-`schema_change_events` | `default` / `column_changes` |  The type of schema change event that triggers the behavior specified by the `schema_change_policy` option:<ul><li>`default`: Include all [`ADD COLUMN`](add-column.html) events for columns that have a non-`NULL` [`DEFAULT` value](default-value.html) or are [computed](computed-columns.html), and all [`DROP COLUMN`](drop-column.html) events.</li><li>`column_changes`: Include all schema change events that add or remove any column.</li></ul><br>Default: `schema_change_events=default`
-<a name="schema-policy"></a>`schema_change_policy` | `backfill` / `nobackfill` / `stop` |  The behavior to take when an event specified by the `schema_change_events` option occurs:<ul><li>`backfill`: When [schema changes with column backfill](stream-data-out-of-cockroachdb-using-changefeeds.html#schema-changes-with-column-backfill) are finished, output all watched rows using the new schema.</li><li>`nobackfill`: For [schema changes with column backfill](stream-data-out-of-cockroachdb-using-changefeeds.html#schema-changes-with-column-backfill), perform no logical backfills. The changefeed will still emit any duplicate records for the table being altered, but will not emit the new schema records.</li><li>`stop`: [schema changes with column backfill](stream-data-out-of-cockroachdb-using-changefeeds.html#schema-changes-with-column-backfill), wait for all data preceding the schema change to be resolved before exiting with an error indicating the timestamp at which the schema change occurred. An `error: schema change occurred at <timestamp>` will display in the `cockroach.log` file.</li></ul><br>Default: `schema_change_policy=backfill`
-`initial_scan` / `no_initial_scan` | N/A |  Control whether or not an initial scan will occur at the start time of a changefeed. `initial_scan` and `no_initial_scan` cannot be used simultaneously. If neither `initial_scan` nor `no_initial_scan` is specified, an initial scan will occur if there is no `cursor`, and will not occur if there is one. This preserves the behavior from previous releases.<br><br>Default: `initial_scan` <br>If used in conjunction with `cursor`, an initial scan will be performed at the cursor timestamp. If no `cursor` is specified, the initial scan is performed at `now()`.
-`full_table_name` | N/A | Use fully-qualified table name in topics, subjects, schemas, and record output instead of the default table name. This can prevent unintended behavior when the same table name is present in multiple databases. <br><br>Example: `CREATE CHANGEFEED FOR foo... WITH full_table_name` will create the topic name `defaultdb.public.foo` instead of `foo`.
-`avro_schema_prefix` | Schema prefix name               | Provide a namespace for the schema of a table in addition to the default, the table name. This allows multiple databases or clusters to share the same schema registry when the same table name is present in multiple databases.<br><br>Example: `CREATE CHANGEFEED FOR foo WITH format=experimental_avro, confluent_schema_registry='registry_url', avro_schema_prefix='super'` will register subjects as `superfoo-key` and `superfoo-value` with the namespace `super`.
-
-{{site.data.alerts.callout_info}}
- Using the `format=experimental_avro`, `envelope=key_only`, and `updated` options together is rejected. `envelope=key_only` prevents any rows with updated fields from being emitted, which makes the `updated` option meaningless.
-{{site.data.alerts.end}}
-
-#### Avro limitations
-
-Currently, support for Avro is limited and experimental. Below is a list of unsupported SQL types and values for Avro changefeeds:
-
-- [Decimals](decimal.html) must have precision specified.
-- [`INTERVAL`](https://github.com/cockroachdb/cockroach/issues/32472), [`ARRAY`](https://github.com/cockroachdb/cockroach/issues/34420), `BIT`, and collated `STRING` are not supported in Avro yet.
-
-#### Avro types
-
-Below is a mapping of CockroachDB types to Avro types:
-
-CockroachDB Type | Avro Type | Avro Logical Type
------------------+-----------+---------------------
-[`INT`](int.html) | [`LONG`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) |
-[`BOOL`](bool.html) | [`BOOLEAN`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) |
-[`FLOAT`](float.html) | [`DOUBLE`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) |
-[`STRING`](string.html) | [`STRING`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) |
-[`DATE`](date.html) | [`INT`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) | [`DATE`](https://avro.apache.org/docs/1.8.1/spec.html#Date)
-[`TIME`](time.html) | [`LONG`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) | [`TIME-MICROS`](https://avro.apache.org/docs/1.8.1/spec.html#Time+%28microsecond+precision%29)
-[`TIMESTAMP`](timestamp.html) | [`LONG`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) | [`TIME-MICROS`](https://avro.apache.org/docs/1.8.1/spec.html#Time+%28microsecond+precision%29)
-[`TIMESTAMPTZ`](timestamp.html) | [`LONG`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) | [`TIME-MICROS`](https://avro.apache.org/docs/1.8.1/spec.html#Time+%28microsecond+precision%29)
-[`DECIMAL`](decimal.html) | [`BYTES`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) | [`DECIMAL`](https://avro.apache.org/docs/1.8.1/spec.html#Decimal)
-[`UUID`](uuid.html) | [`STRING`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) |
-[`INET`](inet.html) | [`STRING`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) |
-[`JSONB`](jsonb.html) | [`STRING`](https://avro.apache.org/docs/1.8.1/spec.html#schema_primitive) |
-
-#### Topic Naming
-
-By default, a Kafka topic has the same name as the table that a changefeed was created on. If a changefeed was created on multiple tables, the changefeed will write to multiple topics corresponding to those table names. You can specify a [topic prefix](#query-parameters) or use the [`full_table_name` option](#options) to modify this.
-
-You can either manually create a topic in your Kafka cluster before starting the changefeed, or the topic will be automatically created when the changefeed connects to your Kafka cluster.
-
-{{site.data.alerts.callout_info}}
-You must have the Kafka cluster setting [`auto.create.topics.enable`](https://kafka.apache.org/documentation/#brokerconfigs_auto.create.topics.enable) set to `true` for automatic topic creation. This will create the topic when the changefeed sends its first message. If you create the consumer before that, you will also need the Kafka consumer configuration [`allow.auto.create.topics`](https://kafka.apache.org/documentation/#consumerconfigs_allow.auto.create.topics) to be set to `true`.
-{{site.data.alerts.end}}
-
-Kafka has the following topic limitations:
-
-- [Legal characters](https://github.com/apache/kafka/blob/0.10.2/core/src/main/scala/kafka/common/Topic.scala#L29) are numbers, letters, and `[._-]`.
-- The maximum character length of a topic name is 249.
-- Topics with a period (`.`) and underscore (`_`) can collide on internal Kafka data structures, so you should use either but not both.
-- Characters not accepted by Kafka will be automatically encoded as unicode characters by CockroachDB.
-
-## Responses
-
-### Messages
-
-The messages (i.e., keys and values) emitted to a sink are specific to the [`envelope`](#options). The default format is `wrapped`, and the output messages are composed of the following:
-
-- **Key**: An array always composed of the row's `PRIMARY KEY` field(s) (e.g., `[1]` for `JSON` or `{"id":{"long":1}}` for Avro).
-- **Value**:
-    - One of three possible top-level fields:
-        - `after`, which contains the state of the row after the update (or `null`' for `DELETE`s).
-        - `updated`, which contains the updated timestamp.
-        - `resolved`, which is emitted for records representing resolved timestamps. These records do not include an "after" value since they only function as checkpoints.
-    - For [`INSERT`](insert.html) and [`UPDATE`](update.html), the current state of the row inserted or updated.
-    - For [`DELETE`](delete.html), `null`.
-
-For example:
-
-Statement                                      | Response
------------------------------------------------+-----------------------------------------------------------------------
-`INSERT INTO office_dogs VALUES (1, 'Petee');` | JSON: `[1]	{"after": {"id": 1, "name": "Petee"}}` </br>Avro: `{"id":{"long":1}}	{"after":{"office_dogs":{"id":{"long":1},"name":{"string":"Petee"}}}}`
-`DELETE FROM office_dogs WHERE name = 'Petee'` | JSON: `[1]	{"after": null}` </br>Avro: `{"id":{"long":1}}	{"after":null}`
-
-### Files
-
-The files emitted to a sink use the following naming conventions:
-
-- [General file format](#general-file-format)
-- [Resolved file format](#resolved-file-format)
-
-{{site.data.alerts.callout_info}}
-The timestamp format is `YYYYMMDDHHMMSSNNNNNNNNNLLLLLLLLLL`.
-{{site.data.alerts.end}}
-
-#### General file format
-
-~~~
-/[date]/[timestamp]-[uniquer]-[topic]-[schema-id]
-~~~
-
-For example:
-
-~~~
-/2020-04-02/202004022058072107140000000000000-56087568dba1e6b8-1-72-00000000-test_table-1.ndjson
-~~~
-
-#### Resolved file format
-
-~~~
-/[date]/[timestamp].RESOLVED
-~~~
-
-For example:
-
-~~~
-/2020-04-04/202004042351304139680000000000000.RESOLVED
-~~~
-
-## Examples
-
-### Create a changefeed connected to Kafka
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE CHANGEFEED FOR TABLE name, name2, name3
-  INTO 'kafka://host:port'
-  WITH updated, resolved;
-~~~
-~~~
-+--------------------+
-|       job_id       |
-+--------------------+
-| 360645287206223873 |
-+--------------------+
-(1 row)
-~~~
-
-For more information on how to create a changefeed connected to Kafka, see [Stream Data Out of CockroachDB Using Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html#create-a-changefeed-connected-to-kafka).
-
-### Create a changefeed connected to Kafka using Avro
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE CHANGEFEED FOR TABLE name, name2, name3
-  INTO 'kafka://host:port'
-  WITH format = experimental_avro, confluent_schema_registry = <schema_registry_address>;
-~~~
-~~~
-+--------------------+
-|       job_id       |
-+--------------------+
-| 360645287206223873 |
-+--------------------+
-(1 row)
-~~~
-
-For more information on how to create a changefeed that emits an [Avro](https://avro.apache.org/docs/1.8.2/spec.html) record, see [Stream Data Out of CockroachDB Using Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html#create-a-changefeed-connected-to-kafka-using-avro).
-
-### Create a changefeed connected to a cloud storage sink
-
-{{site.data.alerts.callout_danger}}
-**This is an experimental feature.** The interface and output are subject to change.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE CHANGEFEED FOR TABLE name, name2, name3
-  INTO 'experimental-scheme://host?parameters'
-  WITH updated, resolved;
-~~~
-~~~
-+--------------------+
-|       job_id       |
-+--------------------+
-| 360645287206223873 |
-+--------------------+
-(1 row)
-~~~
-
-For more information on how to create a changefeed connected to a cloud storage sink, see [Stream Data Out of CockroachDB Using Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html#create-a-changefeed-connected-to-a-cloud-storage-sink).
-
-### Manage a changefeed
-
-Use the following SQL statements to pause, resume, and cancel a changefeed.
-
-{{site.data.alerts.callout_info}}
-Changefeed-specific SQL statements (e.g., `CANCEL CHANGEFEED`) will be added in the future.
-{{site.data.alerts.end}}
-
-#### Pause a changefeed
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOB job_id;
-~~~
-
-For more information, see [`PAUSE JOB`](pause-job.html).
-
-#### Resume a paused changefeed
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOB job_id;
-~~~
-
-For more information, see [`RESUME JOB`](resume-job.html).
-
-#### Cancel a changefeed
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL JOB job_id;
-~~~
-
-For more information, see [`CANCEL JOB`](cancel-job.html).
-
-#### Configuring all changefeeds
-
-{% include {{ page.version.version }}/cdc/configure-all-changefeed.md %}
-
-### Start a new changefeed where another ended
-
-Find the [high-water timestamp](stream-data-out-of-cockroachdb-using-changefeeds.html#monitor-a-changefeed) for the ended changefeed:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM crdb_internal.jobs WHERE job_id = <job_id>;
-~~~
-~~~
-        job_id       |  job_type  | ... |      high_water_timestamp      | error | coordinator_id
-+--------------------+------------+ ... +--------------------------------+-------+----------------+
-  383870400694353921 | CHANGEFEED | ... | 1537279405671006870.0000000000 |       |              1
-(1 row)
-~~~
-
-Use the `high_water_timestamp` to start the new changefeed:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE CHANGEFEED FOR TABLE name, name2, name3
-  INTO 'kafka//host:port'
-  WITH cursor = '<high_water_timestamp>';
-~~~
-
-Note that because the cursor is provided, the initial scan is not performed.
-
-## See also
-
-- [Stream Data Out of CockroachDB Using Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html)
-- [Other SQL Statements](sql-statements.html)
-- [Changefeed Dashboard](ui-cdc-dashboard.html)
diff --git a/src/current/v20.2/create-database.md b/src/current/v20.2/create-database.md
deleted file mode 100644
index 12b1914facd..00000000000
--- a/src/current/v20.2/create-database.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: CREATE DATABASE
-summary: The CREATE DATABASE statement creates a new CockroachDB database.
-toc: true
----
-
-The `CREATE DATABASE` [statement](sql-statements.html) creates a new CockroachDB database.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-To create a database, the user must be a member of the `admin` role or must have the [`CREATEDB`](create-role.html#create-a-role-that-can-create-and-rename-databases) parameter set.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_database.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`IF NOT EXISTS` | Create a new database only if a database of the same name does not already exist; if one does exist, do not return an error.
-`name` | The name of the database to create, which [must be unique](#create-fails-name-already-in-use) and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
-`encoding` | The `CREATE DATABASE` statement accepts an optional `ENCODING` clause for compatibility with PostgreSQL, but `UTF-8` is the only supported encoding. The aliases `UTF8` and `UNICODE` are also accepted. Values should be enclosed in single quotes and are case-insensitive.<br><br>Example: `CREATE DATABASE bank ENCODING = 'UTF-8'`.
-`CONNECTION LIMIT` | <span class="version-tag">New in v20.2:</span> Supported for compatibility with PostgreSQL. A value of `-1` indicates no connection limit. Values other than `-1` are currently not supported. By default, `CONNECTION LIMIT = -1`. 
-
-## Example
-
-### Create a database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE bank;
-~~~
-
-{% include copy-clipboard.html %}
-~~~
-> SHOW DATABASES;
-~~~
-
-~~~
-+---------------+
-| database_name |
-+---------------+
-| bank          |
-| defaultdb     |
-| postgres      |
-| system        |
-+---------------+
-(4 rows)
-~~~
-
-### Create fails (name already in use)
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE bank;
-~~~
-
-~~~
-pq: database "bank" already exists
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE IF NOT EXISTS bank;
-~~~
-
-SQL does not generate an error, but instead responds `CREATE DATABASE` even though a new database wasn't created.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW DATABASES;
-~~~
-
-~~~
-+---------------+
-| database_name |
-+---------------+
-| bank          |
-| defaultdb     |
-| postgres      |
-| system        |
-+---------------+
-(4 rows)
-~~~
-
-## See also
-
-- [`SHOW DATABASES`](show-databases.html)
-- [`RENAME DATABASE`](rename-database.html)
-- [`SET DATABASE`](set-vars.html)
-- [`DROP DATABASE`](drop-database.html)
-- [Other SQL Statements](sql-statements.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/create-index.md b/src/current/v20.2/create-index.md
deleted file mode 100644
index 14d73840ec2..00000000000
--- a/src/current/v20.2/create-index.md
+++ /dev/null
@@ -1,286 +0,0 @@
----
-title: CREATE INDEX
-summary: The CREATE INDEX statement creates an index for a table. Indexes improve your database's performance by helping SQL quickly locate data.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-The `CREATE INDEX` [statement](sql-statements.html) creates an index for a table. [Indexes](indexes.html) improve your database's performance by helping SQL locate data without having to look through every row of a table.
-
-The following types cannot be included in an index key, but can be stored (and used in a covered query) using the [`STORING` or `COVERING`](create-index.html#store-columns) clause:
-
-- [`JSONB`](jsonb.html)
-- [`ARRAY`](array.html)
-- The computed [`TUPLE`](scalar-expressions.html#tuple-constructor) type, even if it is constructed from indexed fields
-
-To create an index on the schemaless data in a [`JSONB`](jsonb.html) column, or on the data in an [`ARRAY`](array.html), use a [GIN index](inverted-indexes.html).
-
-{{site.data.alerts.callout_info}}
-Indexes are automatically created for a table's [`PRIMARY KEY`](primary-key.html) and [`UNIQUE`](unique.html) columns. When querying a table, CockroachDB uses the fastest index. For more information about that process, see [Index Selection in CockroachDB](https://www.cockroachlabs.com/blog/index-selection-cockroachdb-2/).
-{{site.data.alerts.end}}
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the table.
-
-## Synopsis
-
-**Standard index:**
-
-<div>{% include {{ page.version.version }}/sql/diagrams/create_index.html %}</div>
-
-**GIN index:**
-
-<div>{% include {{ page.version.version }}/sql/diagrams/create_inverted_index.html %}</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`UNIQUE` | Apply the [`UNIQUE` constraint](unique.html) to the indexed columns.<br><br>This causes the system to check for existing duplicate values on index creation. It also applies the `UNIQUE` constraint at the table level, so the system checks for duplicate values when inserting or updating data.
-`INVERTED` | Create a [GIN index](inverted-indexes.html) on the schemaless data in the specified [`JSONB`](jsonb.html) column.<br><br> You can also use the PostgreSQL-compatible syntax `USING GIN`. For more details, see [GIN Indexes](inverted-indexes.html#creation).
-`IF NOT EXISTS` | Create a new index only if an index of the same name does not already exist; if one does exist, do not return an error.
-`opt_index_name`<br>`index_name` | The name of the index to create, which must be unique to its table and follow these [identifier rules](keywords-and-identifiers.html#identifiers).<br><br>If you do not specify a name, CockroachDB uses the format `<table>_<columns>_key/idx`. `key` indicates the index applies the `UNIQUE` constraint; `idx` indicates it does not. Example: `accounts_balance_idx`
-`table_name` | The name of the table you want to create the index on.
-`USING name` | An optional clause for compatibility with third-party tools. Accepted values for `name` are `btree`, `gin`, and `gist`, with `btree` for a standard secondary index, `gin` as the PostgreSQL-compatible syntax for a [GIN index](#create-gin-indexes), and `gist` for a [spatial index](spatial-indexes.html).
-`name` | The name of the column you want to index.
-`ASC` or `DESC`| Sort the column in ascending (`ASC`) or descending (`DESC`) order in the index. How columns are sorted affects query results, particularly when using `LIMIT`.<br><br>__Default:__ `ASC`
-`STORING ...`| Store (but do not sort) each column whose name you include.<br><br>For information on when to use `STORING`, see  [Store Columns](#store-columns).  Note that columns that are part of a table's [`PRIMARY KEY`](primary-key.html) cannot be specified as `STORING` columns in secondary indexes on the table.<br><br>`COVERING` and `INCLUDE` are aliases for `STORING` and work identically.
-`opt_partition_by` | An [Enterprise-only](enterprise-licensing.html) option that lets you [define index partitions at the row level](partitioning.html).
-`opt_where_clause` | <span class="version-tag">New in v20.2:</span> An optional `WHERE` clause that defines the predicate boolean expression of a [partial index](partial-indexes.html).
-`USING HASH WITH BUCKET COUNT` |  Creates a [hash-sharded index](hash-sharded-indexes.html) with `n_buckets` number of buckets.<br>{{site.data.alerts.callout_info}}To enable hash-sharded indexes, set the `experimental_enable_hash_sharded_indexes` [session variable](set-vars.html) to `on`.{{site.data.alerts.end}}
-`WITH storage_parameter` | <span class="version-tag">New in v20.2:</span> A comma-separated list of [spatial index tuning parameters](spatial-indexes.html#index-tuning-parameters). Supported parameters include `fillfactor`, `s2_max_level`, `s2_level_mod`, `s2_max_cells`, `geometry_min_x`, `geometry_max_x`, `geometry_min_y`, and `geometry_max_y`. The `fillfactor` parameter is a no-op, allowed for PostgreSQL-compatibility.<br><br>For details, see [Spatial index tuning parameters](spatial-indexes.html#index-tuning-parameters). For an example, see [Create a spatial index that uses all of the tuning parameters](spatial-indexes.html#create-a-spatial-index-that-uses-all-of-the-tuning-parameters).
-`CONCURRENTLY` |  Optional, no-op syntax for PostgreSQL compatibility. All indexes are created concurrently in CockroachDB.
-`opt_interleave` | [Interleave index into parent object](interleave-in-parent.html).<br>{% include {{ page.version.version }}/misc/interleave-deprecation-note.md %}
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Create standard indexes
-
-To create the most efficient indexes, we recommend reviewing:
-
-- [Indexes: Best Practices](indexes.html#best-practices)
-- [Index Selection in CockroachDB](https://www.cockroachlabs.com/blog/index-selection-cockroachdb-2/)
-
-#### Single-column indexes
-
-Single-column indexes sort the values of a single column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (name);
-~~~
-
-Because each query can only use one index, single-column indexes are not typically as useful as multiple-column indexes.
-
-#### Multiple-column indexes
-
-Multiple-column indexes sort columns in the order you list them.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (name, city);
-~~~
-
-To create the most useful multiple-column indexes, we recommend reviewing our [best practices](schema-design-indexes.html).
-
-#### Unique indexes
-
-Unique indexes do not allow duplicate values among their columns.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE UNIQUE INDEX ON users (name, id);
-~~~
-
-This also applies the [`UNIQUE` constraint](unique.html) at the table level, similarly to [`ALTER TABLE`](alter-table.html). The above example is equivalent to:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users ADD CONSTRAINT users_name_id_key UNIQUE (name, id);
-~~~
-
-### Create GIN indexes
-
-[GIN indexes](inverted-indexes.html) can be created on schemaless data in a [`JSONB`](jsonb.html) column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INVERTED INDEX ON promo_codes (rules);
-~~~
-
-The above example is equivalent to the following PostgreSQL-compatible syntax:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON promo_codes USING GIN (rules);
-~~~
-
-### Create spatial indexes
-
-[Spatial indexes](spatial-indexes.html) can be created on `GEOMETRY` and `GEOGRAPHY` columns.  Spatial indexes are a special type of [GIN index](inverted-indexes.html).
-
-To create a spatial index on a `GEOMETRY` column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX geom_idx_1 ON some_spatial_table USING GIST(geom);
-~~~
-
-Unlike GIN indexes, spatial indexes do not support an alternate `CREATE INVERTED INDEX ...` syntax.  Only the syntax shown here is supported.
-
-For advanced users, there are a number of [spatial index tuning parameters](spatial-indexes.html#create-a-spatial-index-that-uses-all-of-the-tuning-parameters) that can be passed in using the syntax `WITH (var1=val1, var2=val2)` as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX geom_idx_2
-  ON some_spatial_table USING GIST(geom)
-  WITH (s2_max_cells = 20, s2_max_level = 12, s2_level_mod = 3);
-~~~
-
-{{site.data.alerts.callout_danger}}
-Most users should not change the default spatial index settings. There is a risk that you will get worse performance by changing the default settings. For more information , see [Spatial indexes](spatial-indexes.html).
-{{site.data.alerts.end}}
-
-### Store columns
-
-Storing a column improves the performance of queries that retrieve (but do not filter) its values.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (city) STORING (name);
-~~~
-
-However, to use stored columns, queries must filter another column in the same index. For example, SQL can retrieve `name` values from the above index only when a query's `WHERE` clause filters `city`.
-
-### Change column sort order
-
-To sort columns in descending order, you must explicitly set the option when creating the index. (Ascending order is the default.)
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (city DESC, name);
-~~~
-
-Note that how a column is ordered in the index will affect the ordering of the index keys, and may affect the efficiency of queries that include an `ORDER BY` clause.
-
-### Query specific indexes
-
-Normally, CockroachDB selects the index that it calculates will scan the fewest rows. However, you can override that selection and specify the name of the index you want to use. To find the name, use [`SHOW INDEX`](show-index.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM users;
-~~~
-
-~~~
-  table_name |   index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit
-+------------+----------------+------------+--------------+-------------+-----------+---------+----------+
-  users      | primary        |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary        |   false    |            2 | id          | ASC       |  false  |  false
-  users      | users_name_idx |    true    |            1 | name        | ASC       |  false  |  false
-  users      | users_name_idx |    true    |            2 | city        | ASC       |  false  |   true
-  users      | users_name_idx |    true    |            3 | id          | ASC       |  false  |   true
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name FROM users@users_name_idx WHERE city='new york';
-~~~
-
-~~~
-        name
-+------------------+
-  Catherine Nelson
-  Devin Jordan
-  James Hamilton
-  Judy White
-  Robert Murphy
-(5 rows)
-~~~
-
-### Create a hash-sharded secondary index
-
-{% include {{page.version.version}}/performance/use-hash-sharded-indexes.md %}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE events (
-    product_id INT8,
-    owner UUID,
-    serial_number VARCHAR,
-    event_id UUID,
-    ts TIMESTAMP,
-    data JSONB,
-    PRIMARY KEY (product_id, owner, serial_number, ts, event_id)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET experimental_enable_hash_sharded_indexes=on;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON events(ts) USING HASH WITH BUCKET_COUNT=8;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM events;
-~~~
-
-~~~
-  table_name |               index_name               | non_unique | seq_in_index |       column_name        | direction | storing | implicit
--------------+----------------------------------------+------------+--------------+--------------------------+-----------+---------+-----------
-  events     | primary                                |   false    |            1 | product_id               | ASC       |  false  |  false
-  events     | primary                                |   false    |            2 | owner                    | ASC       |  false  |  false
-  events     | primary                                |   false    |            3 | serial_number            | ASC       |  false  |  false
-  events     | primary                                |   false    |            4 | ts                       | ASC       |  false  |  false
-  events     | primary                                |   false    |            5 | event_id                 | ASC       |  false  |  false
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            1 | crdb_internal_ts_shard_8 | ASC       |  false  |  false
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            2 | ts                       | ASC       |  false  |  false
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            3 | product_id               | ASC       |  false  |   true
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            4 | owner                    | ASC       |  false  |   true
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            5 | serial_number            | ASC       |  false  |   true
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            6 | event_id                 | ASC       |  false  |   true
-(11 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM events;
-~~~
-
-~~~
-        column_name        | data_type | is_nullable | column_default |       generation_expression       |                     indices                      | is_hidden
----------------------------+-----------+-------------+----------------+-----------------------------------+--------------------------------------------------+------------
-  product_id               | INT8      |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  owner                    | UUID      |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  serial_number            | VARCHAR   |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  event_id                 | UUID      |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  ts                       | TIMESTAMP |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  data                     | JSONB     |    true     | NULL           |                                   | {}                                               |   false
-  crdb_internal_ts_shard_8 | INT4      |    false    | NULL           | mod(fnv32(CAST(ts AS STRING)), 8) | {events_crdb_internal_ts_shard_8_ts_idx}         |   true
-(7 rows)
-~~~
-
-## See also
-
-- [Indexes](indexes.html)
-- [`SHOW INDEX`](show-index.html)
-- [`DROP INDEX`](drop-index.html)
-- [`RENAME INDEX`](rename-index.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [Other SQL Statements](sql-statements.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/create-role.md b/src/current/v20.2/create-role.md
deleted file mode 100644
index c644883bf44..00000000000
--- a/src/current/v20.2/create-role.md
+++ /dev/null
@@ -1,322 +0,0 @@
----
-title: CREATE ROLE
-summary: The CREATE ROLE statement creates SQL roles, which can act as database users or groups of users and be used to manage database access and privileges.
-toc: true
----
-
-The `CREATE ROLE` statement creates a new SQL role. A role acts as a database user or a group of member roles/users.
-There is no distinct "user" entity in CockroachDB. A role with the `LOGIN` option enabled can log in to the database and is often called a user.
-
-
-You can [assign privileges](authorization.html#assign-privileges) to the role and [set other roles as members](grant-roles.html) of the role. A role's [privileges](authorization.html#privileges) are inherited by its members and any further members of members ([indirect members](authorization.html#indirect-member)).
-
-{{site.data.alerts.callout_info}}
- `CREATE USER` is equivalent to the statement `CREATE ROLE`, with one exception: `CREATE ROLE` sets the [`NOLOGIN`](#parameters) option by default, preventing the new role from being used to log in to the database. You can use `CREATE ROLE` and specify the [`LOGIN`](#parameters) option to achieve the same result as `CREATE USER`.
-{{site.data.alerts.end}}
-
-See [Authorization](authorization.html) for more information on privilege management and role membership.
-
-## Considerations
-
-{% include {{ page.version.version }}/sql/role-considerations.md %}
-
-## Required privileges
-
-Unless a role is a member of the admin role, additional [privileges](#parameters) are required to manage other roles.
-
-- To create other roles, a role must have the [`CREATEROLE`](#create-a-role-that-can-create-other-roles-and-manage-authentication-methods-for-the-new-roles) role option set.
-- To add the `LOGIN` capability for other roles so that they may log in as users, a role must also have the [`CREATELOGIN`](#create-a-role-that-can-create-other-roles-and-manage-authentication-methods-for-the-new-roles) role option set.
-- To be able to grant or revoke membership to a role for additional roles, a member of the role must be set as a [role admin](authorization.html#role-admin) for that role.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_role.html %}
-</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
-| Parameter | Description |
-------------|--------------
-`name` | The name of the role you want to create. See the [Considerations](#considerations) section for important naming guidelines.
-`CREATELOGIN`/`NOCREATELOGIN` | Allow or disallow the role to manage authentication using the `WITH PASSWORD`, `VALID UNTIL`, and `LOGIN/NOLOGIN` role options. <br><br>By default, the role option is set to `NOCREATELOGIN` for all non-admin roles.
-`LOGIN`/`NOLOGIN` | The `LOGIN` role option allows a role to login with one of the [client authentication methods](authentication.html#client-authentication). Setting the role option to `NOLOGIN` prevents the role from logging in using any authentication method. `NOLOGIN` is set by default when using `CREATE ROLE`, but not when using the otherwise equivalent `CREATE USER` statement.
-`password` | Let the role [authenticate their access to a secure cluster](authentication.html#client-authentication) using this password. Passwords should be entered as a [string literal](sql-constants.html#string-literals). For compatibility with PostgreSQL, a password can also be entered as an identifier. <br><br>To prevent a role from using [password authentication](authentication.html#client-authentication) and to mandate [certificate-based client authentication](authentication.html#client-authentication), [set the password as `NULL`](#prevent-a-role-from-using-password-authentication).
-`VALID UNTIL` |  The date and time (in the [`timestamp`](timestamp.html) format) after which the password is not valid.
-`CREATEROLE`/`NOCREATEROLE` |  Allow or disallow the new role to create, [alter](alter-role.html), and [drop](drop-role.html) other non-admin roles. <br><br>By default, the role option is set to `NOCREATEROLE` for all non-admin users.
-`CREATEDB`/`NOCREATEDB` | Allow or disallow the role to [create](create-database.html) or [rename](rename-database.html) a database. The role is assigned as the owner of the database. <br><br>By default, the role option is set to `NOCREATEDB` for all non-admin roles.
-`CONTROLJOB`/`NOCONTROLJOB` | Allow or disallow the role to [pause](pause-job.html), [resume](resume-job.html), and [cancel](cancel-job.html) jobs. Non-admin roles cannot control jobs created by admins. <br><br>By default, the role option is set to `NOCONTROLJOB` for all non-admin roles.
-`CANCELQUERY`/`NOCANCELQUERY` | Allow or disallow the role to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) of other roles. Without this privilege, roles can only cancel their own queries and sessions. Even with this privilege, non-admins cannot cancel admin queries or sessions. This option should usually be combined with `VIEWACTIVITY` so that the role can view other roles' query and session information. <br><br>By default, the role option is set to `NOCANCELQUERY` for all non-admin roles.
-`VIEWACTIVITY`/`NOVIEWACTIVITY` | Allow or disallow a role to see other roles' [queries](show-queries.html) and [sessions](show-sessions.html) using `SHOW QUERIES`, `SHOW SESSIONS`, and the [**Statements**](ui-statements-page.html) and **Transactions** pages in the DB Console. Without this privilege, the `SHOW` commands only show the role's own data and the DB Console pages are unavailable. <br><br>By default, the role option is set to `NOVIEWACTIVITY` for all non-admin roles.
-`CONTROLCHANGEFEED`/`NOCONTROLCHANGEFEED` | Allow or disallow the role to run [`CREATE CHANGEFEED`](create-changefeed.html) on tables they have `SELECT` privileges on. <br><br>By default, the role option is set to `NOCONTROLCHANGEFEED` for all non-admin roles.
-`MODIFYCLUSTERSETTING`/`NOMODIFYCLUSTERSETTING` | Allow or disallow the role to modify the [cluster settings](cluster-settings.html) with the `sql.defaults` prefix. <br><br>By default, the role option is set to `NOMODIFYCLUSTERSETTING` for all non-admin roles.
-
-## Examples
-
-To run the following examples, [start a secure single-node cluster](cockroach-start-single-node.html) and use the built-in SQL shell:
-
-~~~ shell
-$ cockroach sql --certs-dir=certs
-~~~
-
-~~~ sql
-> SHOW ROLES;
-~~~
-
-~~~
-username | options | member_of
----------+---------+------------
-admin    |         | {}
-root     |         | {admin}
-(2 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-The following statements are run by the `root` user that is a member of the `admin` role and has `ALL` privileges.
-{{site.data.alerts.end}}
-
-### Create a role
-
-Note the [considerations](#considerations) for role names.
-
-~~~ sql
-root@:26257/defaultdb> CREATE ROLE no_options;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
- username  | options | member_of
- ----------+---------+------------
-admin      |         | {}
-no_options | NOLOGIN | {}
-root       |         | {admin}
-(3 rows)
-~~~
-
-After creating roles, you must [grant them privileges to databases](grant.html).
-
-### Create a role that can log in to the database
-
-~~~ sql
-root@:26257/defaultdb> CREATE ROLE can_login WITH LOGIN PASSWORD '$tr0nGpassW0rD' VALID UNTIL '2021-10-10';
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
- username  |                options                | member_of
------------+---------------------------------------+------------
-admin      |                                       | {}
-can_login  | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-no_options | NOLOGIN                               | {}
-root       |                                       | {admin}
-(4 rows)
-~~~
-
-### Prevent a role from using password authentication
-
-The following statement prevents the role from using password authentication and mandates certificate-based client authentication:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE ROLE no_password WITH PASSWORD NULL;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
- username  |                options                | member_of
------------+---------------------------------------+------------
-admin      |                                       | {}
-can_login  | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-no_options | NOLOGIN                               | {}
-no_password| NOLOGIN                               | {}
-root       |                                       | {admin}
-(5 rows)
-~~~
-
-### Create a role that can create other roles and manage authentication methods for the new roles
-
-The following example allows the role to [create other users](create-user.html) and [manage authentication methods](authentication.html#client-authentication) for them:
-
-~~~ sql
-root@:26257/defaultdb> CREATE ROLE can_create_role WITH CREATEROLE CREATELOGIN;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
-   username     |                options                | member_of
-----------------+---------------------------------------+------------
-admin           |                                       | {}
-can_create_role | CREATELOGIN, CREATEROLE, NOLOGIN      | {}
-can_login       | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-no_options      | NOLOGIN                               | {}
-no_password     | NOLOGIN                               | {}
-root            |                                       | {admin}
-(6 rows)
-~~~
-
-### Create a role that can create and rename databases
-
-The following example allows the role to [create](create-database.html) or [rename](rename-database.html) databases:
-
-~~~ sql
-root@:26257/defaultdb> CREATE ROLE can_create_db WITH CREATEDB;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
-      username        |                options                | member_of
-----------------------+---------------------------------------+------------
-admin                 |                                       | {}
-can_create_db         | CREATEDB, NOLOGIN                     | {}
-can_create_role       | CREATELOGIN, CREATEROLE, NOLOGIN      | {}
-can_login             | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-no_options            | NOLOGIN                               | {}
-no_password           | NOLOGIN                               | {}
-root                  |                                       | {admin}
-(7 rows)
-~~~
-
-### Create a role that can pause, resume, and cancel non-admin jobs
-
-The following example allows the role to [pause](pause-job.html), [resume](resume-job.html), and [cancel](cancel-job.html) jobs:
-
-~~~ sql
-root@:26257/defaultdb> CREATE ROLE can_control_job WITH CONTROLJOB;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
-      username        |                options                | member_of
-----------------------+---------------------------------------+------------
-admin                 |                                       | {}
-can_control_job       | CONTROLJOB, NOLOGIN                   | {}
-can_create_db         | CREATEDB, NOLOGIN                     | {}
-can_create_role       | CREATELOGIN, CREATEROLE, NOLOGIN      | {}
-can_login             | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-manage_auth_for_roles | CREATELOGIN, NOLOGIN                  | {}
-no_options            | NOLOGIN                               | {}
-no_password           | NOLOGIN                               | {}
-root                  |                                       | {admin}
-(8 rows)
-~~~
-
-### Create a role that can see and cancel non-admin queries and sessions
-
-The following example allows the role to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) for other non-admin roles:
-
-~~~ sql
-root@:26257/defaultdb> CREATE ROLE can_manage_queries WITH CANCELQUERY VIEWACTIVITY;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
-      username        |                options                | member_of
-----------------------+---------------------------------------+------------
-admin                 |                                       | {}
-can_control_job       | CONTROLJOB, NOLOGIN                   | {}
-can_create_db         | CREATEDB, NOLOGIN                     | {}
-can_create_role       | CREATELOGIN, CREATEROLE, NOLOGIN      | {}
-can_login             | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-can_manage_queries    | CANCELQUERY, NOLOGIN, VIEWACTIVITY    | {}
-no_options            | NOLOGIN                               | {}
-no_password           | NOLOGIN                               | {}
-root                  |                                       | {admin}
-(9 rows)
-~~~
-
-### Create a role that can control changefeeds
-
-The following example allows the role to run [`CREATE CHANGEFEED`](create-changefeed.html):
-
-~~~ sql
-root@:26257/defaultdb> CREATE ROLE can_control_changefeed WITH CONTROLCHANGEFEED;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
-       username        |                options                | member_of
------------------------+---------------------------------------+------------
-admin                  |                                       | {}
-can_control_changefeed | CONTROLCHANGEFEED, NOLOGIN            | {}
-can_control_job        | CONTROLJOB, NOLOGIN                   | {}
-can_create_db          | CREATEDB, NOLOGIN                     | {}
-can_create_role        | CREATELOGIN, CREATEROLE, NOLOGIN      | {}
-can_login              | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-can_manage_queries     | CANCELQUERY, NOLOGIN, VIEWACTIVITY    | {}
-no_options             | NOLOGIN                               | {}
-no_password            | NOLOGIN                               | {}
-root                   |                                       | {admin}
-(10 rows)
-~~~
-
-### Create a role that can modify cluster settings
-
-The following example allows the role to modify [cluster settings](cluster-settings.html):
-
-~~~ sql
-root@:26257/defaultdb> CREATE ROLE can_modify_cluster_setting WITH MODIFYCLUSTERSETTING;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW ROLES;
-~~~
-
-~~~
-         username          |                options                | member_of
----------------------------+---------------------------------------+------------
-admin                      |                                       | {}
-can_control_changefeed     | CONTROLCHANGEFEED, NOLOGIN            | {}
-can_control_job            | CONTROLJOB, NOLOGIN                   | {}
-can_create_db              | CREATEDB, NOLOGIN                     | {}
-can_create_role            | CREATELOGIN, CREATEROLE, NOLOGIN      | {}
-can_login                  | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-can_manage_queries         | CANCELQUERY, NOLOGIN, VIEWACTIVITY    | {}
-can_modify_cluster_setting | MODIFYCLUSTERSETTING, NOLOGIN         | {}
-no_options                 | NOLOGIN                               | {}
-no_password                | NOLOGIN                               | {}
-root                       |                                       | {admin}
-(11 rows)
-~~~
-
-## See also
-
-- [Authorization](authorization.html)
-- [`DROP ROLE`](drop-role.html)
-- [`GRANT <privileges>`](grant.html)
-- [`REVOKE <privileges>`](revoke.html)
-- [`GRANT <roles>`](grant-roles.html)
-- [`REVOKE <roles>`](revoke-roles.html)
-- [`SHOW ROLES`](show-roles.html)
-- [`SHOW USERS`](show-users.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/create-schedule-for-backup.md b/src/current/v20.2/create-schedule-for-backup.md
deleted file mode 100644
index 4f887012b35..00000000000
--- a/src/current/v20.2/create-schedule-for-backup.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: CREATE SCHEDULE FOR BACKUP
-summary: The CREATE SCHEDULE FOR BACKUP statement creates a schedule for periodic backups.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `CREATE SCHEDULE FOR BACKUP` [statement](sql-statements.html) creates a schedule for periodic [backups](backup.html).
-
-For more information about creating, managing, monitoring, and restoring from a scheduled backup, see [Manage a Backup Schedule](manage-a-backup-schedule.html).
-
-{{site.data.alerts.callout_info}}
-Core users can only use backup scheduling for [full backups](#create-a-schedule-for-full-backups-only-core) of clusters, databases, or tables.
-
-To use the other backup features, you need an [Enterprise license](enterprise-licensing.html).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-- Only members of the [`admin` role](authorization.html#default-roles) can run `CREATE SCHEDULE FOR BACKUP`. By default, the `root` user belongs to the `admin` role.
-- `BACKUP` requires full read and write (including delete and overwrite) permissions to its target destination.
-
-## Synopsis
-
-~~~
-CREATE SCHEDULE <label>
-FOR BACKUP [<targets>] INTO <location>
-[WITH <backup_options>[=<value>] [, ...]]
-RECURRING [crontab] [FULL BACKUP <crontab|ALWAYS>]
-[WITH SCHEDULE OPTIONS <schedule_option>[= <value>] [, ...] ]
-
-Targets:
-   Empty targets list: backup full cluster.
-   TABLE <table_pattern> [, ...]
-   DATABASE <database_name> [, ...]
-~~~
-
-## Parameters
-
- Parameter                              | Description
-----------------------------------------+-------------------------------------------------------------------------------------------------------------------------
-`label`                                 | The name used to identify the backup schedule. This is optional and does not need to be unique. If not provided, the schedule will be assigned the name `BACKUP`.
-`table_pattern`                         | The [table(s)](create-table.html) or [view(s)](views.html) you want to back up.
-`database_name`                         | The name of the [database(s)](create-database.html) you want to back up (i.e., create backups of all tables and views in the database).
-`location`                              | The URI where you want to store the backup. The backup files will be stored in year > month > day subdirectories. The location can be [cloud storage](use-cloud-storage-for-bulk-operations.html), or `nodelocal`.<br><br><b>Note:</b> If you want to schedule a backup using temporary credentials, we recommend that you use `implicit` authentication; otherwise, you'll need to drop and then recreate schedules each time you need to update the credentials.
-`backup_options`                        | Control the backup behavior with a comma-separated list of [options](#backup-options).
-`RECURRING crontab`                     | Specifies when the backup should be taken. By default, these are incremental backups that capture changes since the last backup and append to the current full backup. The schedule is specified as a [`STRING`](string.html) in [crontab format](https://en.wikipedia.org/wiki/Cron). All times in UTC. <br><br>Example: `'@daily'` (run daily at midnight)
-<a name="full-backup-clause"></a>`FULL BACKUP crontab` | Specifies when to take a new full backup. The schedule is specified as a [`STRING`](string.html) in [crontab format](https://en.wikipedia.org/wiki/Cron) or as `ALWAYS`. <br><br>If `FULL BACKUP ALWAYS` is specified, then the backups triggered by the `RECURRING` clause will always be full backups. For free users, `ALWAYS` is the only accepted value of `FULL BACKUP`.<br><br>If the `FULL BACKUP` clause is omitted, CockroachDB will default to the following full backup schedule: <ul><li>`RECURRING` <= 1 hour: Default to `FULL BACKUP '@daily'`</li><li>`RECURRING` <= 1 day: Default to `FULL BACKUP '@weekly'`</li><li>Otherwise: Default to `FULL BACKUP ALWAYS`</li></ul>
-`WITH SCHEDULE OPTIONS schedule_option` | _Experimental feature._ Control the schedule behavior with a comma-separated list of [these options](#schedule-options).
-
-{{site.data.alerts.callout_info}}
-For schedules that include both [full and incremental backups](take-full-and-incremental-backups.html), CockroachDB will create two schedules (one for each type).
-{{site.data.alerts.end}}
-
-### Backup options
-
-{% include {{ page.version.version }}/backups/backup-options.md %}
-
-### Schedule options
-
-{{site.data.alerts.callout_danger}}
-**This is an experimental feature.**  Its interface, options, and outputs are subject to change, and there may be bugs.
-
-If you encounter a bug, please [file an issue](file-an-issue.html).
-{{site.data.alerts.end}}
-
- Option                     | Value                                   | Description
-----------------------------+-----------------------------------------+------------------------------
-`first_run`                 | [`TIMESTAMPTZ`](timestamp.html) / `now` | Execute the schedule at the specified time in the future. If not specified, the default behavior is to execute the schedule based on its next `RECURRING` time.
-`on_execution_failure`      | `retry` / `reschedule` / `pause`        | If an error occurs during the backup execution, do the following: <ul><li>`retry`: Retry the backup right away.</li><li>`reschedule`: Retry the backup by rescheduling it based on the `RECURRING` expression.</li><li>`pause`: Pause the schedule. This requires manual intervention to [resume the schedule](resume-schedules.html).</li></ul><br>**Default**: `reschedule`
-<a name="on-previous-running-option"></a>`on_previous_running`       | `start` / `skip` / `wait`               | If the previous backup started by the schedule is still running, do the following: <ul><li>`start`: Start the new backup anyway, even if the previous one still running.</li><li>`skip`: Skip the new backup and run the next backup based on the `RECURRING` expression.</li><li>`wait`: Wait for the previous backup to complete.</li></ul><br>**Default**: `wait`
-`ignore_existing_backups`   | N/A                                     | If backups were already created in the [destination](use-cloud-storage-for-bulk-operations.html) that the new schedule references, this option must be passed to acknowledge that the new schedule may be backing up different objects.
-
-## Considerations
-
-- We recommend that you schedule your backups at a cadence that your cluster can keep up with; for example, if a previous backup is still running when it is time to start the next one, adjust the schedule so the backups do not end up falling behind or update the [`on_previous_running` option](#on-previous-running-option).
-- To prevent scheduled backups from falling behind, first determine how long a single backup takes and use that as your starting point for the schedule's cadence.
-- Ensure you are monitoring your backup schedule (e.g., [Prometheus](monitor-cockroachdb-with-prometheus.html)) and alerting metrics that will confirm that your backups are completing, but also that they're not running more concurrently than you expect.
-- Ensure that your [GC window](configure-replication-zones.html#gc-ttlseconds) is long enough to accommodate your backup schedule, otherwise your incremental backups will throw [an error](common-errors.html#pq-failed-to-verify-protection-id). For example, if you set up your schedule to be `RECURRING '@daily'` but your GC window is less than 1 day, all your incremental backups will fail.
-- The `AS OF SYSTEM TIME` clause cannot be set on scheduled backups. Scheduled backups are started shortly after the scheduled time has passed by an internal polling mechanism and are automatically run with `AS OF SYSTEM TIME` set to the time at which the backup was scheduled to run.
-- If you want to schedule a backup using temporary credentials, we recommend that you use `implicit` authentication; otherwise, you'll need to drop and then recreate schedules each time you need to update the credentials.
-
-## View and control backup schedules
-
-Once a backup schedule is successfully created, you can do the following:
-
- Action                | SQL Statement
------------------------+-----------------
-View the schedule      | [`SHOW SCHEDULES`](show-schedules.html)
-Pause the schedule     | [`PAUSE SCHEDULES`](pause-schedules.html)
-Resume the schedule    | [`RESUME SCHEDULES`](resume-schedules.html)
-Drop the schedule      | [`DROP SCHEDULES`](drop-schedules.html)
-
-## View and control a backup initiated by a schedule
-
-After CockroachDB successfully initiates a scheduled backup, it registers the backup as a job. You can do the following with each individual backup job:
-
- Action                | SQL Statement
------------------------+-----------------
-View the backup status | [`SHOW JOBS`](show-jobs.html)
-Pause the backup       | [`PAUSE JOB`](pause-job.html)
-Resume the backup      | [`RESUME JOB`](resume-job.html)
-Cancel the backup      | [`CANCEL JOB`](cancel-job.html)
-
-You can also visit the [**Jobs** page](ui-jobs-page.html) of the DB Console to view job details. The `BACKUP` statement will return when the backup is finished or if it encounters an error.
-
-## Examples
-
-### Create a schedule for full backups only (core)
-
-Core users can only use backup scheduling for full backups of clusters, databases, or tables. Full backups are taken with the `FULL BACKUP ALWAYS` clause, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEDULE core_schedule_label
-  FOR BACKUP INTO 's3://test/schedule-test-core?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x'
-    RECURRING '@daily'
-    FULL BACKUP ALWAYS
-    WITH SCHEDULE OPTIONS first_run = 'now';
-~~~
-~~~
-     schedule_id     |        name         | status |         first_run         | schedule |                                                                                       backup_stmt
----------------------+---------------------+--------+---------------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  588799238330220545 | core_schedule_label | ACTIVE | 2020-09-11 00:00:00+00:00 | @daily   | BACKUP INTO 's3://test/schedule-test-core?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH detached
-(1 row)
-~~~
-
-To use the other backup features, you need an [Enterprise license](enterprise-licensing.html).
-
-### Create a scheduled backup for a cluster
-
-This example creates a schedule for a cluster backup with revision history that's taken every day at midnight:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEDULE schedule_label
-  FOR BACKUP INTO 's3://test/backups/schedule_test?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x'
-    WITH revision_history
-    RECURRING '@daily';
-~~~
-
-~~~
-     schedule_id     |     name       |                     status                     |            first_run             | schedule |                                                                               backup_stmt
----------------------+----------------+------------------------------------------------+----------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------
-  588796190000218113 | schedule_label | PAUSED: Waiting for initial backup to complete | NULL                             | @daily   | BACKUP INTO LATEST IN 's3://test/schedule-test?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH revision_history, detached
-  588796190012702721 | schedule_label | ACTIVE                                         | 2020-09-10 16:52:17.280821+00:00 | @weekly  | BACKUP INTO 's3://test/schedule-test?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH revision_history, detached
-(2 rows)
-~~~
-
-Because the [`FULL BACKUP` clause](#full-backup-clause) was not included, CockroachDB also scheduled a full backup to run `@weekly`. This is the default cadence for incremental backups `RECURRING` > 1 hour but <= 1 day.
-
-### Create a scheduled backup for a database
-
-This example creates a schedule for a backup of the database `movr` with revision history that's taken every day 1 minute past midnight (`00:00:01`):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEDULE schedule_database
-  FOR BACKUP DATABASE movr INTO 's3://test/schedule-database?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x'
-    WITH revision_history
-    RECURRING '1 0 * * *';
-~~~
-
-~~~
-     schedule_id     |       name        |                     status                     |            first_run             | schedule  |                                                                           backup_stmt
----------------------+-------------------+------------------------------------------------+----------------------------------+-----------+-----------------------------------------------------------------------------------------------------------------------------------------------------
-  588819866656997377 | schedule_database | PAUSED: Waiting for initial backup to complete | NULL                             | 1 0 * * * | BACKUP DATABASE movr INTO LATEST IN 's3://test/schedule-database?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH revision_history, detached
-  588819866674233345 | schedule_database | ACTIVE                                         | 2020-09-10 18:52:42.823003+00:00 | @weekly   | BACKUP DATABASE movr INTO 's3://test/schedule-database?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH revision_history, detached
-(2 rows)
-~~~
-
-Because the [`FULL BACKUP` clause](#full-backup-clause) was not included, CockroachDB also scheduled a full backup to run `@weekly`. This is the default cadence for incremental backups `RECURRING` > 1 hour but <= 1 day.
-
-### Create a scheduled backup for a table
-
-This example creates a schedule for a backup of the table `movr.vehicles` with revision history that's taken every hour:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEDULE schedule_table
-  FOR BACKUP TABLE movr.vehicles INTO 's3://test/schedule-table?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x'
-    WITH revision_history
-    RECURRING '@hourly';
-~~~
-
-~~~
-     schedule_id     |       name     |                     status                     |            first_run             | schedule |                                                                             backup_stmt
----------------------+----------------+------------------------------------------------+----------------------------------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------
-  588820615348027393 | schedule_table | PAUSED: Waiting for initial backup to complete | NULL                             | @hourly  | BACKUP TABLE movr.vehicles INTO LATEST IN 's3://test/schedule-table?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH revision_history, detached
-  588820615382302721 | schedule_table | ACTIVE                                         | 2020-09-10 18:56:31.305782+00:00 | @daily   | BACKUP TABLE movr.vehicles INTO 's3://test/schedule-table?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH revision_history, detached
-(2 rows)
-~~~
-
-Because the [`FULL BACKUP` clause](#full-backup-clause) was not included, CockroachDB also scheduled a full backup to run `@daily`. This is the default cadence for incremental backups `RECURRING` <= 1 hour.
-
-### Create a scheduled backup with a scheduled first run
-
-This example creates a schedule for a backup of the table `movr.vehicles` with revision history that's taken every hour, with its first run scheduled for `2020-09-15 00:00:00.00` (UTC):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEDULE scheduled_first_run
-  FOR BACKUP TABLE movr.vehicles INTO 's3://test/schedule-table?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x'
-    WITH revision_history
-    RECURRING '@hourly'
-    WITH SCHEDULE OPTIONS first_run = '2020-09-15 00:00:00.00';
-~~~
-
-~~~
-     schedule_id     |        name         |                     status                     |         first_run         | schedule |                                                                                backup_stmt
----------------------+---------------------+------------------------------------------------+---------------------------+----------+----------------------------------------------------------------------------------------------------------------------------------------------------------
-  589963390457741313 | scheduled_first_run | PAUSED: Waiting for initial backup to complete | NULL                      | @hourly  | BACKUP TABLE movr.vehicles INTO LATEST IN 's3://test/scheduled-first-run?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH revision_history, detached
-  589963390487363585 | scheduled_first_run | ACTIVE                                         | 2020-09-15 00:00:00+00:00 | @daily   | BACKUP TABLE movr.vehicles INTO 's3://test/scheduled-first-run?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH revision_history, detached
-(2 rows)
-~~~
-
-Because the [`FULL BACKUP` clause](#full-backup-clause) was not included, CockroachDB also scheduled a full backup to run `@daily`. This is the default cadence for incremental backups `RECURRING` <= 1 hour.
-
-### View scheduled backup details
-
-When a [backup is created by a schedule](create-schedule-for-backup.html), it is stored within a collection of backups in the given location. To view details for a backup created by a schedule, you can use the following:
-
-- `SHOW BACKUPS IN y` statement to [view a list of the full backup's subdirectories](#view-a-list-of-the-full-backups-subdirectories).
-- `SHOW BACKUP x IN y` statement to [view a list of the full and incremental backups that are stored in a specific full backup's subdirectory](#view-a-list-of-the-full-and-incremental-backups-in-a-specific-full-backup-subdirectory).
-
-For more details, see [`SHOW BACKUP`](show-backup.html).
-
-{% include {{ page.version.version }}/backups/show-scheduled-backups.md %}
-
-## See also
-
-- [Manage a Backup Schedule](manage-a-backup-schedule.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`SHOW BACKUP`](show-backup.html)
-- [`SHOW SCHEDULES`](show-schedules.html)
-- [`PAUSE SCHEDULES`](pause-schedules.html)
-- [`RESUME SCHEDULES`](resume-schedules.html)
-- [`DROP SCHEDULES`](drop-schedules.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`RESUME JOB`](pause-job.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/create-schema.md b/src/current/v20.2/create-schema.md
deleted file mode 100644
index 9e18b7ffcb7..00000000000
--- a/src/current/v20.2/create-schema.md
+++ /dev/null
@@ -1,304 +0,0 @@
----
-title: CREATE SCHEMA
-summary: The CREATE SCHEMA statement creates a new user-defined schema.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: The `CREATE SCHEMA` [statement](sql-statements.html) creates a user-defined [schema](sql-name-resolution.html#naming-hierarchy) in the current database.
-
-{{site.data.alerts.callout_info}}
-You can also create a user-defined schema by converting an existing database to a schema using [`ALTER DATABASE ... CONVERT TO SCHEMA`](convert-to-schema.html).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-- Only members of the `admin` role can create new schemas. By default, the `root` user belongs to the `admin` role.
-- To [grant privileges](grant.html) on a user-defined schema, a user must have the `GRANT` privilege on the schema and the privilege that they want to grant.
-- To create or interact with objects that depend on a user-defined schema, a user must have the `USAGE` privilege on the schema.
-
-## Syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_schema.html %}
-</div>
-
-### Parameters
-
-Parameter | Description
-----------|------------
-`IF NOT EXISTS` | Create a new schema only if a schema of the same name does not already exist within the database. If one does exist, do not return an error.
-`name` | The name of the schema to create. The schema name must be unique within its database and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
-`AUTHORIZATION role_spec` | Optionally identify a user (`role_spec`) to be the owner of the schema.<br><br>If a `CREATE SCHEMA` statement has an `AUTHORIZATION` clause, but no schema name is specified, the schema will be named after the specified owner of the schema. If a `CREATE SCHEMA` statement does not have an `AUTHORIZATION` clause, the user executing the statement will be named the owner.
-
-## Example
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Create a schema
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_one;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_one
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-By default, the user executing the `CREATE SCHEMA` statement is the owner of the schema. For example, suppose you created the schema as user `root`. `root` would be the owner of the schema.
-
-### Create a schema if one does not exist
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_one;
-~~~
-
-~~~
-ERROR: schema "org_one" already exists
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA IF NOT EXISTS org_one;
-~~~
-
-SQL does not generate an error, even though a new schema wasn't created.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_one
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-### Create two tables of the same name in different schemas
-
-You can create tables of the same name in the same database if they are in separate schemas.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA IF NOT EXISTS org_one;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA IF NOT EXISTS org_two;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_one
-  org_two
-  pg_catalog
-  pg_extension
-  public
-(7 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE org_one.employees (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        name STRING,
-        desk_no INT UNIQUE
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE org_two.employees (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        name STRING,
-        desk_no INT UNIQUE
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW TABLES] WHERE table_name='employees';
-~~~
-
-~~~
-  schema_name | table_name | type  | estimated_row_count
---------------+------------+-------+----------------------
-  org_one     | employees  | table |                   0
-  org_two     | employees  | table |                   0
-(2 rows)
-~~~
-
-### Create a schema with authorization
-
-To specify the owner of a schema, add an `AUTHORIZATION` clause to the `CREATE SCHEMA` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE USER max WITH PASSWORD 'roach';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_two AUTHORIZATION max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_two
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-If no schema name is specified in a `CREATE SCHEMA` statement with an `AUTHORIZATION` clause, the schema will be named after the user specified:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA AUTHORIZATION max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  max
-  org_two
-  pg_catalog
-  pg_extension
-  public
-(7 rows)
-~~~
-
-When you [use a table without specifying a schema](sql-name-resolution.html#search-path), CockroachDB looks for the table in the `$user` schema (i.e., a schema named after the current user). If no schema exists with the name of the current user, the `public` schema is used.
-
-For example, suppose that you [grant the `root` role](grant-roles.html) (i.e., the role of the current user `root`) to the `max` user:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT root TO max;
-~~~
-
-Then, `max` [accesses the cluster](cockroach-sql.html) and creates two tables of the same name, in the same database, one in the `max` schema, and one in the `public` schema:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --url 'postgres://max:roach@host:port/db?sslmode=require'
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE max.accounts (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        name STRING,
-        balance DECIMAL
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE public.accounts (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        name STRING,
-        balance DECIMAL
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name | table_name | type  | estimated_row_count
---------------+------------+-------+----------------------
-  max         | accounts   | table |                   0
-  public      | accounts   | table |                   0
-(2 rows)
-~~~
-
-`max` then inserts some values into the `accounts` table, without specifying a schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO accounts (name, balance) VALUES ('checking', 1000), ('savings', 15000);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-                   id                  |   name   | balance
----------------------------------------+----------+----------
-  7610607e-4928-44fb-9f4e-7ae6d6520666 | savings  |   15000
-  860b7891-cde4-4aff-a318-f928d47374bc | checking |    1000
-(2 rows)
-~~~
-
-Because `max` is the current user, all unqualified `accounts` table names resolve as `max.accounts`, and not `public.accounts`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM public.accounts;
-~~~
-
-~~~
-  id | name | balance
------+------+----------
-(0 rows)
-~~~
-
-## See also
-
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [`SET SCHEMA`](set-schema.html)
-- [`DROP SCHEMA`](drop-schema.html)
-- [`ALTER SCHEMA`](alter-schema.html)
-- [Other SQL Statements](sql-statements.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/create-security-certificates-custom-ca.md b/src/current/v20.2/create-security-certificates-custom-ca.md
deleted file mode 100644
index 03815dd7fa3..00000000000
--- a/src/current/v20.2/create-security-certificates-custom-ca.md
+++ /dev/null
@@ -1,173 +0,0 @@
----
-title: Create Security Certificates using a Custom CA
-summary: A secure CockroachDB cluster uses TLS for encrypted inter-node and client-node communication.
-toc: true
----
-
-To secure your CockroachDB cluster's inter-node and client-node communication, you need to provide a Certificate Authority (CA) certificate that has been used to sign keys and certificates (SSLs) for:
-
-- Nodes
-- Clients
-- DB Console (optional)
-
-To create these certificates and keys, use the `cockroach cert` [commands](cockroach-commands.html) with the appropriate subcommands and flags, use [`openssl` commands](https://wiki.openssl.org/index.php/), or use a [custom CA](create-security-certificates-custom-ca.html) (for example, a public CA or your organizational CA).
-
-<div class="filters filters-big clearfix">
-  <a href="cockroach-cert.html"><button style="width:28%" class="filter-button">Use cockroach cert</button>
-  <a href="create-security-certificates-openssl.html"><button style="width:28%" class="filter-button">Use Openssl</button></a>
-  <button style="width:28%" class="filter-button current">Use <strong>custom CA</strong></button></a>
-</div>
-
-This document discusses the following advanced use cases for using security certificates with CockroachDB:
-
-Approach | Use case description
--------------|------------
-[UI certificate and key](#accessing-the-db-console-for-a-secure-cluster) | When you want to access the DB Console for a secure cluster and avoid clicking through a warning message to get to the UI.
-[Split-node certificate](#split-node-certificates) | When your organizational CA requires you to have separate certificates for the node's incoming connections (from SQL and DB Console clients, and from other CockroachDB nodes) and for outgoing connections to other CockroachDB nodes.
-[Split-CA certificates](#split-ca-certificates) | When you have multiple CockroachDB clusters and need to restrict access to clients from accessing the other cluster.
-
-## Accessing the DB Console for a secure cluster
-
-On [accessing the DB Console](ui-overview.html#db-console-access) for a secure cluster, your web browser will consider the CockroachDB-issued certificate invalid, because the browser hasn't been configured to trust the CA that issued the certificate.
-
-For secure clusters, you can avoid getting the warning message by using a certificate issued by a public CA whose certificates are trusted by browsers, in addition to the CockroachDB-created certificates:
-
-1. Request a certificate from a public CA (for example, [Let's Encrypt](https://letsencrypt.org/)). The certificate must have the IP addresses and DNS names used to reach the DB Console listed in the `Subject Alternative Name` field.
-2. Rename the certificate and key as `ui.crt` and `ui.key`.
-3. Add the `ui.crt` and `ui.key` to the [certificate directory](cockroach-cert.html#certificate-directory). `ui.key` must not have group or world permissions (maximum permissions are 0700, or rwx------). You can disable this check by setting the environment variable `COCKROACH_SKIP_KEY_PERMISSION_CHECK=true`.
-4. For nodes that are already running, load the `ui.crt` certificate without restarting the node by issuing a `SIGHUP` signal to the cockroach process:
-   {% include copy-clipboard.html %}
-   ~~~ shell
-   pkill -SIGHUP -x cockroach
-   ~~~
-   The `SIGHUP` signal must be sent by the same user running the process (e.g., run with sudo if the cockroach process is running under user root).
-
-### Node key and certificates
-
-A node must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate issued by the public CA or your organizational CA.
-`node.crt`   | Server certificate created using the `cockroach cert` command. <br><br> `node.crt` must have `CN=node` and the list of IP addresses and DNS names listed in `Subject Alternative Name` field. <br><br>Must be signed by `ca.crt`.
-`node.key`   | Server key created using the `cockroach cert` command.
-`ui.crt` | UI certificate signed by the public CA. `ui.crt` must have the IP addresses and DNS names used to reach the DB Console listed in `Subject Alternative Name`.
-`ui.key` | UI key corresponding to `ui.crt`.
-
-### Client key and certificates
-
-A client must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate issued by the public CA or your organizational CA.
-`client.<user>.crt` | Client certificate for `<user>` (e.g., `client.root.crt` for user `root`). <br><br>Each `client.<user>.crt` must have `CN=<user>`  (for example, `CN=marc` for `client.marc.crt`) <br><br> Must be signed by `ca.crt`.
-`client.<user>.key` | Client key created using the `cockroach cert` command.
-
-## Split node certificates
-
-The node certificate discussed in the `cockroach cert` command [documentation](cockroach-cert.html) is multifunctional, which means the same certificate is presented for the node's incoming connections (from SQL and DB Console clients, and from other CockroachDB nodes) and for outgoing connections to other CockroachDB nodes. To make the certificate multi-functional, the `node.crt` created using the `cockroach cert` command has `CN=node` and the list of IP addresses and DNS names listed in `Subject Alternative Name` field. This works if you are also using the CockroachDB CA created using the `cockroach cert` command. However, if you need to use an external public CA or your own organizational CA, the CA policy might not allow it to sign a server certificate containing a CN that is not an IP address or domain name.
-
-To get around this issue, you can split the node key and certificate into two:
-
-- `node.crt` and `node.key`: `node.crt` is used as the server certificate when a node receives incoming connections from clients and other nodes. All IP addresses and DNS names for the node must be listed in the `Subject Alternative Name` field.
-- `client.node.crt` and `client.node.key`: `client.node.crt` is used as the client certificate when making connections to other nodes. `client.node.crt` must have `CN=node`.
-
-### Node key and certificates
-
-A node must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate issued by the public CA or your organizational CA.
-`node.crt`   | Server certificate used when a node receives incoming connections from clients and other nodes. <br><br>All IP addresses and DNS names for the node must be listed in `Subject Alternative Name`. <br><br>Must be signed by `ca.crt`.
-`node.key`   | Server key corresponding to `node.crt`.
-`client.node.crt` | Client certificate when making connections to other nodes. <br><br>Must have `CN=node`. <br><br> Must be signed by `ca.crt`.
-`client.node.key` | Client key corresponding to `client.node.crt`.
-
-Optionally, if you have a certificate issued by a public CA to securely access the DB Console, you need to place the certificate and key (`ui.crt` and `ui.key` respectively) in the directory specified by the `--certs-dir` flag.
-
-### Client key and certificates
-
-A client must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate issued by the public CA or your organizational CA.
-`client.<user>.crt` | Client certificate for `<user>` (e.g., `client.root.crt` for user `root`). <br><br>Each `client.<user>.crt` must have `CN=<user>`  (for example, `CN=marc` for `client.marc.crt`) <br><br>Must be signed by `ca.crt`.
-`client.<user>.key` | Client key corresponding to `client.<user>.crt`.
-
-## Split CA certificates
-
-{{site.data.alerts.callout_danger}}
-We do not recommend you use split CA certificates unless your organizational security practices mandate you to do so.
-{{site.data.alerts.end}}
-
-If you need to use separate CAs to sign node certificates and client certificates, then you need two CAs and their respective certificates and keys: `ca.crt` and `ca-client.crt`.
-
-### Node key and certificates
-
-A node must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate to verify node certificates.
-`ca-client.crt` | CA certificate to verify client certificates.
-`node.crt`   | Server certificate used when a node receives incoming connections from clients and other nodes. <br><br>All IP addresses and DNS names for the node must be listed in `Subject Alternative Name`. <br><br> Must be signed by `ca.crt`.
-`node.key`   | Server key corresponding to `node.crt`.
-`client.node.crt` | Client certificate when making connections to other nodes. This certificate must be signed using `ca-client.crt`  <br><br>Must have `CN=node`.
-`client.node.key` | Client key corresponding to `client.node.crt`.
-
-Optionally, if you have a certificate issued by a public CA to securely access the DB Console, you need to place the certificate and key (`ui.crt` and `ui.key` respectively) in the directory specified by the `--certs-dir` flag.
-
-### Client key and certificates
-
-A client must have the following files with file names as specified in the table:
-
-File name | File usage
--------------|------------
-`ca.crt`     | CA certificate.
-`client.<user>.crt` | Client certificate for `<user>` (e.g., `client.root.crt` for user `root`). <br><br>Each `client.<user>.crt` must have `CN=<user>` (for example, `CN=marc` for `client.marc.crt`). <br><br> Must be signed by `ca-client.crt`.
-`client.<user>.key` | Client key corresponding to `client.<user>.crt`.
-
-## Certificate revocation with OCSP
-
-<span class="version-tag">New in v20.2</span> CockroachDB now supports certificate revocation for custom CA certificate setups running an [OCSP](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol) server.
-
-To enable certificate revocation:
-
-1. Ensure that your Certificate Authority sets the OCSP server address in the `authorityInfoAccess` field in the certificate.
-2. [Set the cluster setting](set-cluster-setting.html) `security.ocsp.mode` to `lax` (by default, the cluster setting is set to `off`).
-
-      {% include copy-clipboard.html %}
-      ~~~ sql
-      > SHOW CLUSTER SETTING security.ocsp.mode;
-      ~~~
-
-      ~~~
-      security.ocsp.mode
-      ----------------------
-      off
-      (1 row)
-
-      Server Execution Time: 56µs
-      Network Latency: 181µs
-      ~~~
-
-      {% include copy-clipboard.html %}
-      ~~~ sql
-      > SET CLUSTER SETTING security.ocsp.mode = lax;
-      ~~~
-
-      For production clusters, you might want to set the setting to `strict`.
-
-      {{site.data.alerts.callout_info}}
-      In the `strict` mode, all certificates are presumed to be invalid if the OCSP server is not reachable. Setting the cluster setting `security.ocsp.mode` to `strict` will lock you out of your CockroachDB database if your OCSP server goes down.
-      {{site.data.alerts.end}}
-
-
-## See also
-
-- [Manual Deployment](manual-deployment.html): Learn about starting a multi-node secure cluster and accessing it from a client.
-- [Start a Node](cockroach-start.html): Learn more about the flags you pass when adding a node to a secure cluster
-- [Client Connection Parameters](connection-parameters.html)
diff --git a/src/current/v20.2/create-security-certificates-openssl.md b/src/current/v20.2/create-security-certificates-openssl.md
deleted file mode 100644
index f91785b965e..00000000000
--- a/src/current/v20.2/create-security-certificates-openssl.md
+++ /dev/null
@@ -1,446 +0,0 @@
----
-title: Create Security Certificates using Openssl
-summary: A secure CockroachDB cluster uses TLS for encrypted inter-node and client-node communication.
-toc: true
----
-
-To secure your CockroachDB cluster's inter-node and client-node communication, you need to provide a Certificate Authority (CA) certificate that has been used to sign keys and certificates (SSLs) for:
-
-- Nodes
-- Clients
-- DB Console (optional)
-
-To create these certificates and keys, use the `cockroach cert` [commands](cockroach-commands.html) with the appropriate subcommands and flags, use [`openssl` commands](https://wiki.openssl.org/index.php/), or use a [custom CA](create-security-certificates-custom-ca.html) (for example, a public CA or your organizational CA).
-
-<div class="filters filters-big clearfix">
-  <a href="cockroach-cert.html"><button style="width:28%" class="filter-button">Use cockroach cert</button>
-  <button style="width:28%" class="filter-button current">Use <strong>Openssl</strong></button></a>
-  <a href="create-security-certificates-custom-ca.html"><button style="width:28%" class="filter-button">Use custom CA</button></a>
-</div>
-
-## Subcommands
-
-Subcommand | Usage
------------|------
-[`openssl genrsa`](https://www.openssl.org/docs/manmaster/man1/genrsa.html) | Create an RSA private key.
-[`openssl req`](https://www.openssl.org/docs/manmaster/man1/req.html) | Create CA certificate and CSRs (certificate signing requests).
-[`openssl ca`](https://www.openssl.org/docs/manmaster/man1/ca.html) | Create node and client certificates using the CSRs.
-
-## Configuration files
-
-To use [`openssl req`](https://www.openssl.org/docs/manmaster/man1/req.html) and [`openssl ca`](https://www.openssl.org/docs/manmaster/man1/ca.html) subcommands, you need the following configuration files:
-
-File name pattern | File usage
--------------|------------
-`ca.cnf`     | CA configuration file
-`node.cnf`   | Server configuration file
-`client.cnf` | Client configuration file
-
-## Certificate directory
-
-To create node and client certificates using the OpenSSL commands, you need access to a local copy of the CA certificate and key. We recommend creating all certificates (node, client, and CA certificates), and node and client keys in one place and then distributing them appropriately. Store the CA key somewhere safe and keep a backup; if you lose it, you will not be able to add new nodes or clients to your cluster.
-
-## Required keys and certificates
-
-Use the [`openssl genrsa`](https://www.openssl.org/docs/manmaster/man1/genrsa.html) and [`openssl req`](https://www.openssl.org/docs/manmaster/man1/req.html) subcommands to create all certificates, and node and client keys in a single directory, with the files named as follows:
-
-### Node key and certificates
-
-File name pattern | File usage
--------------|------------
-`ca.crt`     | CA certificate
-`node.crt`   | Server certificate
-`node.key`   | Key for server certificate
-
-### Client key and certificates
-
-File name pattern | File usage
--------------|------------
-`ca.crt`     | CA certificate.
-`client.<user>.crt` | Client certificate for `<user>` (for example: `client.root.crt` for user `root`).
-`client.<user>.key` | Key for the client certificate.
-
-Note the following:
-
-- The CA key should not be uploaded to the nodes and clients, so it should be created in a separate directory.
-
-- Keys (files ending in `.key`) must not have group or world permissions (maximum permissions are 0700, or `rwx------`). This check can be disabled by setting the environment variable `COCKROACH_SKIP_KEY_PERMISSION_CHECK=true`.
-
-## Examples
-
-### Step 1. Create the CA key and certificate pair
-
-1. Create two directories:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs my-safe-directory
-    ~~~
-    - `certs`: Create your CA certificate and all node and client certificates and keys in this directory and then upload the relevant files to the nodes and clients.
-    - `my-safe-directory`: Create your CA key in this directory and then reference the key when generating node and client certificates. After that, keep the key safe and secret; do not upload it to your nodes or clients.
-
-2. Create the `ca.cnf` file and copy the following configuration into it.
-
-    You can set the CA certificate expiration period using the `default_days` parameter. We recommend using the CockroachDB default value of the CA certificate expiration period, which is 365 days.
-
-    {% include copy-clipboard.html %}
-    ~~~
-    # OpenSSL CA configuration file
-    [ ca ]
-    default_ca = CA_default
-
-    [ CA_default ]
-    default_days = 365
-    database = index.txt
-    serial = serial.txt
-    default_md = sha256
-    copy_extensions = copy
-    unique_subject = no
-
-    # Used to create the CA certificate.
-    [ req ]
-    prompt=no
-    distinguished_name = distinguished_name
-    x509_extensions = extensions
-
-    [ distinguished_name ]
-    organizationName = Cockroach
-    commonName = Cockroach CA
-
-    [ extensions ]
-    keyUsage = critical,digitalSignature,nonRepudiation,keyEncipherment,keyCertSign
-    basicConstraints = critical,CA:true,pathlen:1
-
-    # Common policy for nodes and users.
-    [ signing_policy ]
-    organizationName = supplied
-    commonName = optional
-
-    # Used to sign node certificates.
-    [ signing_node_req ]
-    keyUsage = critical,digitalSignature,keyEncipherment
-    extendedKeyUsage = serverAuth,clientAuth
-
-    # Used to sign client certificates.
-    [ signing_client_req ]
-    keyUsage = critical,digitalSignature,keyEncipherment
-    extendedKeyUsage = clientAuth
-    ~~~
-
-    {{site.data.alerts.callout_danger}}
-    The `keyUsage` and `extendedkeyUsage` parameters are vital for CockroachDB functions. You can modify or omit other parameters as per your preferred OpenSSL configuration and you can add additional usages, but do not omit `keyUsage` and `extendedkeyUsage` parameters or remove the listed usages.
-    {{site.data.alerts.end}}
-
-3. Create the CA key using the [`openssl genrsa`](https://www.openssl.org/docs/manmaster/man1/genrsa.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl genrsa -out my-safe-directory/ca.key 2048
-    ~~~
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ chmod 400 my-safe-directory/ca.key
-    ~~~
-
-4. Create the CA certificate using the [`openssl req`](https://www.openssl.org/docs/manmaster/man1/req.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl req \
-    -new \
-    -x509 \
-    -config ca.cnf \
-    -key my-safe-directory/ca.key \
-    -out certs/ca.crt \
-    -days 365 \
-    -batch
-    ~~~
-
-6. Reset database and index files:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -f index.txt serial.txt
-    ~~~
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ touch index.txt
-    ~~~
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ echo '01' > serial.txt
-    ~~~
-
-### Step 2. Create the certificate and key pairs for nodes
-
-In the following steps, replace the placeholder text in the code with the actual username and node address.
-
-1. Create the `node.cnf` file for the first node and copy the following configuration into it:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    # OpenSSL node configuration file
-    [ req ]
-    prompt=no
-    distinguished_name = distinguished_name
-    req_extensions = extensions
-
-    [ distinguished_name ]
-    organizationName = Cockroach
-
-    [ extensions ]
-    subjectAltName = critical,DNS:<node-hostname>,DNS:<node-domain>,IP:<IP Address>
-    ~~~
-
-    {{site.data.alerts.callout_danger}}
-    The `subjectAltName` parameter is vital for CockroachDB functions. You can modify or omit other parameters as per your preferred OpenSSL configuration, but do not omit the `subjectAltName` parameter.
-    {{site.data.alerts.end}}
-
-2. Create the key for the first node using the [`openssl genrsa`](https://www.openssl.org/docs/manmaster/man1/genrsa.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl genrsa -out certs/node.key 2048
-    ~~~
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ chmod 400 certs/node.key
-    ~~~
-
-3. Create the CSR for the first node using the [`openssl req`](https://www.openssl.org/docs/manmaster/man1/req.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl req \
-    -new \
-    -config node.cnf \
-    -key certs/node.key \
-    -out node.csr \
-    -batch
-    ~~~
-
-4. Sign the node CSR to create the node certificate for the first node using the [`openssl ca`](https://www.openssl.org/docs/manmaster/man1/ca.html) command.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl ca \
-    -config ca.cnf \
-    -keyfile my-safe-directory/ca.key \
-    -cert certs/ca.crt \
-    -policy signing_policy \
-    -extensions signing_node_req \
-    -out certs/node.crt \
-    -outdir certs/ \
-    -in node.csr \
-    -batch
-    ~~~
-
-5. Verify the values in the `Subject Alternative Name` field in the certificate:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl x509 -in certs/node.crt -text | grep "X509v3 Subject Alternative Name" -A 1
-    ~~~
-
-    Sample output:
-
-    ~~~
-    X509v3 Subject Alternative Name: critical
-                DNS:localhost, DNS:node.example.io, IP Address:127.0.0.1
-    ~~~
-
-### Step 3. Create the certificate and key pair for the first user
-
-In the following steps, replace the placeholder text in the code with the actual username.
-
-1. Create the `client.cnf` file for the first user and copy the following configuration into it:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    [ req ]
-    prompt=no
-    distinguished_name = distinguished_name
-    req_extensions = extensions
-
-    [ distinguished_name ]
-    organizationName = Cockroach
-    commonName = <username_1>
-
-    [ extensions ]
-    subjectAltName = DNS:root
-    ~~~
-
-    {{site.data.alerts.callout_danger}}
-    The `commonName` and `subjectAltName` parameters are vital for CockroachDB functions. You can modify or omit other parameters as per your preferred OpenSSL configuration, but do not omit the `commonName` parameter or modify the `subjectAltName` parameter.
-    {{site.data.alerts.end}}
-
-2. Create the key for the first client using the [`openssl genrsa`](https://www.openssl.org/docs/manmaster/man1/genrsa.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl genrsa -out certs/client.<username_1>.key 2048
-    ~~~
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ chmod 400 certs/client.<username_1>.key
-    ~~~
-
-3. Create the CSR for the first client using the [`openssl req`](https://www.openssl.org/docs/manmaster/man1/req.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl req \
-    -new \
-    -config client.cnf \
-    -key certs/client.<username_1>.key \
-    -out client.<username_1>.csr \
-    -batch
-    ~~~
-
-4. Sign the client CSR to create the client certificate for the first client using the [`openssl ca`](https://www.openssl.org/docs/manmaster/man1/ca.html) command.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl ca \
-    -config ca.cnf \
-    -keyfile my-safe-directory/ca.key \
-    -cert certs/ca.crt \
-    -policy signing_policy \
-    -extensions signing_client_req \
-    -out certs/client.<username_1>.crt \
-    -outdir certs/ \
-    -in client.<username_1>.csr \
-    -batch
-    ~~~    
-
-5. Verify the values in the `CN` field in the certificate:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl x509 -in certs/client.<username_1>.crt -text | grep "CN ="
-    ~~~
-
-    Sample Output:
-
-    ~~~
-    Issuer: O=Cockroach, CN=Cockroach CA
-        Subject: O=Cockroach, CN=maxroach
-    ~~~
-
-### Step 4. Start a local cluster and connect using a connection URL
-
-1. Start a single-node cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start-single-node --certs-dir=certs --cert-principal-map=<node-domain>:node,<username_1>:root --background
-    ~~~
-
-2. Connect to the cluster using a connection URL:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --url='postgres://<hostname>:26257/?sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.<username_1>.crt&sslkey=certs/client.<username_1>.key&sslmode=verify-full'
-    ~~~
-
-3. Create a new SQL user:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > create user <username_2>;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-### Step 5. Create the certificate and key pair for a client
-
-In the following steps, replace the placeholder text in the code with the actual username.
-
-1. Edit the `client.cnf` file for the client and copy the following configuration into it:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    [ req ]
-    prompt=no
-    distinguished_name = distinguished_name
-
-    [ distinguished_name ]
-    organizationName = Cockroach
-    commonName = <username_2>
-    ~~~
-
-    {{site.data.alerts.callout_danger}}
-    The `commonName` parameter is vital for CockroachDB functions. You can modify or omit other parameters as per your preferred OpenSSL configuration, but do not omit the `commonName` parameter.  {{site.data.alerts.end}}
-
-2. Create the key for the first client using the [`openssl genrsa`](https://www.openssl.org/docs/manmaster/man1/genrsa.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl genrsa -out certs/client.<username_2>.key 2048
-    ~~~
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ chmod 400 certs/client.<username_2>.key
-    ~~~
-
-3. Create the CSR for the first client using the [`openssl req`](https://www.openssl.org/docs/manmaster/man1/req.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl req \
-    -new \
-    -config client.cnf \
-    -key certs/client.<username_2>.key \
-    -out client.<username_2>.csr \
-    -batch
-    ~~~
-
-4. Sign the client CSR to create the client certificate for the first client using the [`openssl ca`](https://www.openssl.org/docs/manmaster/man1/ca.html) command.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl ca \
-    -config ca.cnf \
-    -keyfile my-safe-directory/ca.key \
-    -cert certs/ca.crt \
-    -policy signing_policy \
-    -extensions signing_client_req \
-    -out certs/client.<username_2>.crt \
-    -outdir certs/ \
-    -in client.<username_2>.csr \
-    -batch
-    ~~~    
-
-5. Verify the values in the `CN` field in the certificate:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ openssl x509 -in certs/client.<username_2>.crt -text | grep CN=
-    ~~~
-
-    Sample output:
-
-    ~~~
-    Issuer: O=Cockroach, CN=Cockroach CA
-        Subject: O=Cockroach, CN=roach
-    ~~~
-
-6. Connect to the SQL client using the client certificate:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --url='postgres://<username_2>@<hostname>:26257/?sslmode=verify-full&sslrootcert=certs/ca.crt&sslcert=certs/client.<username_2>.crt&sslkey=certs/client.<username_2>.key&sslmode=verify-full'
-    ~~~
-
-For each node in your deployment, repeat [Step 2](#step-2-create-the-certificate-and-key-pairs-for-nodes) and upload the CA certificate and node key and certificate to the node. For each client, repeat [Step 5](#step-5-create-the-certificate-and-key-pair-for-a-client) and upload the CA certificate and client key and certificate to the client.
-
-After you have uploaded all the keys and certificates to the corresponding nodes and clients, remove the `.pem` files in the `certs` directory. These files are unnecessary duplicates of the `.crt` files that CockroachDB requires.
-
-## See also
-
-- [Manual Deployment](manual-deployment.html): Learn about starting a multi-node secure cluster and accessing it from a client.
-- [Start a Node](cockroach-start.html): Learn more about the flags you pass when adding a node to a secure cluster
-- [Client Connection Parameters](connection-parameters.html)
diff --git a/src/current/v20.2/create-sequence.md b/src/current/v20.2/create-sequence.md
deleted file mode 100644
index 88cc5cc9076..00000000000
--- a/src/current/v20.2/create-sequence.md
+++ /dev/null
@@ -1,287 +0,0 @@
----
-title: CREATE SEQUENCE
-summary: The CREATE SEQUENCE statement creates a new sequence in a database. Use a sequence to auto-increment integers in a table.
-toc: true
----
-
-The `CREATE SEQUENCE` [statement](sql-statements.html) creates a new sequence in a database. Use a sequence to auto-increment integers in a table.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Considerations
-
-- Using a sequence is slower than [auto-generating unique IDs with the `gen_random_uuid()`, `uuid_v4()` or `unique_rowid()` built-in functions](sql-faqs.html#how-do-i-auto-generate-unique-row-ids-in-cockroachdb). Incrementing a sequence requires a write to persistent storage, whereas auto-generating a unique ID does not. Therefore, use auto-generated unique IDs unless an incremental sequence is preferred or required.
-- A column that uses a sequence can have a gap in the sequence values if a transaction advances the sequence and is then rolled back. Sequence updates are committed immediately and aren't rolled back along with their containing transaction. This is done to avoid blocking concurrent transactions that use the same sequence.
-- {% include {{page.version.version}}/performance/use-hash-sharded-indexes.md %}
-- If a table references a sequence, and the reference explicitly specifies a database name, that [database cannot be renamed](rename-database.html). In this case, you can drop the column in the table that references the sequence, or you can modify the reference so that it does not specify the database name.
-- <span class="version-tag">New in v20.2</span> By default, you cannot create sequences that are [owned by](authorization.html#object-ownership) columns in tables in other databases. You can enable such sequence creation by setting the `sql.cross_db_sequence_owners.enabled` [cluster setting](cluster-settings.html) to `true`.
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the parent database.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/create_sequence.html %}</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
- Parameter | Description
------------|------------
-`seq_name` | The name of the sequence to be created, which must be unique within its database and follow the [identifier rules](keywords-and-identifiers.html#identifiers). When the parent database is not set as the default, the name must be formatted as `database.seq_name`.
-`INCREMENT` | The value by which the sequence is incremented. A negative number creates a descending sequence. A positive number creates an ascending sequence.<br><br>**Default:** `1`
-`MINVALUE` | The minimum value of the sequence. Default values apply if not specified or if you enter `NO MINVALUE`.<br><br>**Default for ascending:** `1` <br><br>**Default for descending:** `MININT`
-`MAXVALUE` | The maximum value of the sequence. Default values apply if not specified or if you enter `NO MAXVALUE`.<br><br>**Default for ascending:** `MAXINT` <br><br>**Default for descending:** `-1`
-`START` | The first value of the sequence. <br><br>**Default for ascending:** `1` <br><br>**Default for descending:** `-1`
-`NO CYCLE` | Currently, all sequences are set to `NO CYCLE` and the sequence will not wrap.
-`OWNED BY column_name` <a name="owned-by"></a> | Associates the sequence to a particular column. If that column or its parent table is dropped, the sequence will also be dropped.<br>Specifying an owner column with `OWNED BY` replaces any existing owner column on the sequence. To remove existing column ownership on the sequence and make the column free-standing, specify `OWNED BY NONE`.<br><br>**Default:** `NONE`
-`opt_temp` |  Defines the sequence as a session-scoped temporary sequence. For more information, see [Temporary sequences](#temporary-sequences).<br><br>**Support for temporary sequences is [experimental](experimental-features.html#temporary-objects)**.
-
-<!-- CYCLE | Not yet implemented. The sequence will wrap around when the sequence value hits the maximum or minimum value.
-`CACHE <seq_value>` | The number of sequence values to allocate in memory for faster access. Currently, you can only `CACHE 1` or leave unspecified.-->
-
-## Sequence functions
-
-We support the following [SQL sequence functions](functions-and-operators.html):
-
-- `nextval('seq_name')`
-- `currval('seq_name')`
-- `lastval()`
-- `setval('seq_name', value, is_called)`
-
-## Temporary sequences
-
- CockroachDB supports session-scoped temporary sequences. Unlike persistent sequences, temporary sequences can only be accessed from the session in which they were created, and they are dropped at the end of the session. You can create temporary sequences on both persistent tables and [temporary tables](temporary-tables.html).
-
-{{site.data.alerts.callout_danger}}
-**This is an experimental feature**. The interface and output are subject to change. For details, see the tracking issue [cockroachdb/cockroach#46260](https://github.com/cockroachdb/cockroach/issues/46260).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Temporary tables must be enabled in order to use temporary sequences. By default, temporary tables are disabled in CockroachDB. To enable temporary tables, set the `experimental_enable_temp_tables` [session variable](set-vars.html) to `on`.
-{{site.data.alerts.end}}
-
-### Details
-
-- Temporary sequences are automatically dropped at the end of the session.
-- A temporary sequence can only be accessed from the session in which it was created.
-- Temporary sequences persist across transactions in the same session.
-- Temporary sequences cannot be converted to persistent sequences.
-
-{{site.data.alerts.callout_info}}
-Like [temporary tables](temporary-tables.html), temporary sequences are not in the `public` schema. Instead, when you create the first temporary table, view, or sequence for a session, CockroachDB generates a single temporary schema (`pg_temp_<id>`) for all of the temporary objects in the current session for a database.
-{{site.data.alerts.end}}
-
-### Usage
-
-To create a temporary sequence, add [`TEMP`/`TEMPORARY`](sql-grammar.html#opt_temp) to a `CREATE SEQUENCE` statement.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET experimental_enable_temp_tables=on;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TEMP SEQUENCE temp_seq START 1 INCREMENT 1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE temp_seq;
-~~~
-
-~~~
-  table_name |                                     create_statement
--------------+--------------------------------------------------------------------------------------------
-  temp_seq   | CREATE TEMP SEQUENCE temp_seq MINVALUE 1 MAXVALUE 9223372036854775807 INCREMENT 1 START 1
-(1 row)
-~~~
-
-## Examples
-
-### Create a sequence with default settings
-
-In this example, we create a sequence with default settings.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE customer_seq;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE customer_seq;
-~~~
-
-~~~
-   table_name  |                                     create_statement
----------------+-------------------------------------------------------------------------------------------
-  customer_seq | CREATE SEQUENCE customer_seq MINVALUE 1 MAXVALUE 9223372036854775807 INCREMENT 1 START 1
-(1 row)
-~~~
-
-### Use a sequence when creating a table
-
-In this example, we [create a table](create-table.html), using the [`nextval()` function](functions-and-operators.html#sequence-functions) for a [default value](default-value.html), with the `customer_seq` sequence as its input:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE customers (
-    uid UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    rownum INT DEFAULT nextval('customer_seq'),
-    name STRING
-);
-~~~
-
-Inserting into this table with an `INSERT` statement that relies on default values will call `nextval`, which increments the sequence.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers (name) VALUES ('Max'), ('Alice');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers;
-~~~
-
-~~~
-                  uid                  | rownum | name
----------------------------------------+--------+--------
-  1c7f5b79-88c4-49ec-b40b-6098d28bb822 |      2 | Alice
-  7ce844af-6a3f-4c52-ba07-25623f345804 |      1 | Max
-(2 rows
-~~~
-
-### View the current value of a sequence
-
-To view the current value without incrementing the sequence, use:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customer_seq;
-~~~
-
-~~~
-  last_value | log_cnt | is_called
--------------+---------+------------
-           2 |       0 |   true
-(1 row)
-~~~
-
-{{site.data.alerts.callout_info}}The <code>log_cnt</code> and <code>is_called</code> columns are returned only for PostgreSQL compatibility; they are not stored in the database.{{site.data.alerts.end}}
-
-If a value has been obtained from the sequence in the current session, you can also use the `currval('seq_name')` function to get that most recently obtained value:
-
-~~~ sql
-> SELECT currval('customer_seq');
-~~~
-
-~~~
-  currval
------------
-        2
-(1 row)
-~~~
-
-### Set the next value of a sequence
-
-In this example, we're going to change the next value of `customer_seq` using the [`setval()` function](functions-and-operators.html#sequence-functions). Currently, the next value will be `3` (i.e., `2` + `INCREMENT 1`). We will change the next value to `5`.
-
-{{site.data.alerts.callout_info}}
-You cannot set a value outside the <code>MAXVALUE</code> or <code>MINVALUE</code> of the sequence.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT setval('customer_seq', 5, false);
-~~~
-
-~~~
-  setval
-----------
-       5
-(1 row)
-~~~
-
-{{site.data.alerts.callout_info}}
-The `setval('seq_name', value, is_called)` function in CockroachDB SQL mimics the `setval()` function in PostgreSQL, but it does not store the `is_called` flag. Instead, it sets the value to `val - increment` for `false` or `val` for `true`.
-{{site.data.alerts.end}}
-
-Let's add another record to the table to check that the new record adheres to the new next value.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers (name) VALUES ('Sam');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers;
-~~~
-
-~~~
-                  uid                  | rownum | name
----------------------------------------+--------+--------
-  19ffe03d-5eac-4a2f-8aa8-1569b998aa44 |      5 | Sam
-  1c7f5b79-88c4-49ec-b40b-6098d28bb822 |      2 | Alice
-  7ce844af-6a3f-4c52-ba07-25623f345804 |      1 | Max
-(3 rows)
-~~~
-
-### Create a sequence with user-defined settings
-
-In this example, we create a sequence that starts at -1 and descends in increments of 2.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE desc_customer_list START -1 INCREMENT -2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE desc_customer_list;
-~~~
-
-~~~
-      table_name     |                                          create_statement
----------------------+-----------------------------------------------------------------------------------------------------
-  desc_customer_list | CREATE SEQUENCE desc_customer_list MINVALUE -9223372036854775808 MAXVALUE -1 INCREMENT -2 START -1
-(1 row)
-~~~
-
-### List all sequences
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES;
-~~~
-
-~~~
-         sequence_schema        |   sequence_name
---------------------------------+---------------------
-  public                        | customer_seq
-  public                        | desc_customer_list
-  pg_temp_1603124728816183000_1 | temp_seq
-(3 rows)
-~~~
-
-## See also
-
-- [`ALTER SEQUENCE`](alter-sequence.html)
-- [`RENAME SEQUENCE`](rename-sequence.html)
-- [`DROP SEQUENCE`](drop-sequence.html)
-- [`SHOW CREATE`](show-create.html)
-- [`SHOW SEQUENCES`](show-sequences.html)
-- [Functions and Operators](functions-and-operators.html)
-- [Other SQL Statements](sql-statements.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/create-statistics.md b/src/current/v20.2/create-statistics.md
deleted file mode 100644
index 26c957b6b8a..00000000000
--- a/src/current/v20.2/create-statistics.md
+++ /dev/null
@@ -1,225 +0,0 @@
----
-title: CREATE STATISTICS
-summary: Use the CREATE STATISTICS statement to generate table statistics for the cost-based optimizer to use.
-toc: true
----
-Use the `CREATE STATISTICS` [statement](sql-statements.html) to generate table statistics for the [cost-based optimizer](cost-based-optimizer.html) to use.
-
-Once you [create a table](create-table.html) and load data into it (e.g., [`INSERT`](insert.html), [`IMPORT`](import.html)), table statistics can be generated. Table statistics help the cost-based optimizer determine the cardinality of the rows used in each query, which helps to predict more accurate costs.
-
-<span class="version-tag">New in v20.2:</span> For compatibility with PostgreSQL, CockroachDB supports the `ANALYZE`/`ANALYSE` statement as an alias for `CREATE STATISTICS`. For syntax, [see below](#aliases).
-
-{{site.data.alerts.callout_info}}
-[By default, CockroachDB automatically generates statistics](cost-based-optimizer.html#table-statistics) on all indexed columns, and up to 100 non-indexed columns. As a result, most users do not need to issue `CREATE STATISTICS` statements directly.
-
-<span class="version-tag">New in v20.2:</span> CockroachDB also automatically collects [multi-column statistics](#create-statistics-on-multiple-columns) on columns that prefix each index.
-{{site.data.alerts.end}}
-
-## Syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_stats.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`statistics_name` | The name of the set of statistics you are creating.
-`opt_stats_columns`   | The name of the column(s) you want to create statistics for.
-`create_stats_target` | The name of the table you want to create statistics for.
-`opt_as_of_clause`    | Used to create historical stats using the [`AS OF SYSTEM TIME`](as-of-system-time.html) clause.  For instructions, see [Create statistics as of a given time](#create-statistics-as-of-a-given-time).
-
-## Required Privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the parent database.
-
-## Aliases
-
-<span class="version-tag">New in v20.2:</span> For PostgreSQL compatibility, CockroachDB supports `ANALYZE`/`ANALYSE` as an alias for `CREATE STATISTICS`.
-
-### Alias syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/analyze.html %}
-</div>
-
-### Alias parameters
-
-Parameter | Description
-----------|------------
-`analyze_target` | The name of the table for which you want to create statistics.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Create statistics on a single column
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE STATISTICS revenue_stats ON revenue FROM rides;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW STATISTICS FOR TABLE rides;
-~~~
-
-~~~
-  statistics_name |       column_names        |             created              | row_count | distinct_count | null_count |    histogram_id
-------------------+---------------------------+----------------------------------+-----------+----------------+------------+---------------------
-  __auto__        | {city}                    | 2020-08-26 16:55:24.725089+00:00 |       500 |              9 |          0 | 584550071425531905
-  __auto__        | {id}                      | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071432740865
-  __auto__        | {city,id}                 | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 |               NULL
-  __auto__        | {rider_id}                | 2020-08-26 16:55:24.725089+00:00 |       500 |             50 |          0 | 584550071446732801
-  __auto__        | {city,rider_id}           | 2020-08-26 16:55:24.725089+00:00 |       500 |             50 |          0 |               NULL
-  __auto__        | {vehicle_city}            | 2020-08-26 16:55:24.725089+00:00 |       500 |              9 |          0 | 584550071461019649
-  __auto__        | {vehicle_id}              | 2020-08-26 16:55:24.725089+00:00 |       500 |             15 |          0 | 584550071467966465
-  __auto__        | {vehicle_city,vehicle_id} | 2020-08-26 16:55:24.725089+00:00 |       500 |             15 |          0 |               NULL
-  __auto__        | {start_address}           | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071482122241
-  __auto__        | {end_address}             | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071489167361
-  __auto__        | {start_time}              | 2020-08-26 16:55:24.725089+00:00 |       500 |             30 |          0 | 584550071496671233
-  __auto__        | {end_time}                | 2020-08-26 16:55:24.725089+00:00 |       500 |            367 |          0 | 584550071504437249
-  __auto__        | {revenue}                 | 2020-08-26 16:55:24.725089+00:00 |       500 |            100 |          0 | 584550071512137729
-  revenue_stats   | {revenue}                 | 2020-08-26 16:55:33.986698+00:00 |       500 |            100 |          0 | 584550101775384577
-(14 rows)
-~~~
-
-Note that statistics are automatically collected for all columns in the `rides` table, making the `revenue_stats` statistics a duplicate of the statistics automatically collected on the `revenue` column.
-
-### Create statistics on multiple columns
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE STATISTICS city_revenue_stats ON city, revenue FROM rides;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW STATISTICS FOR TABLE rides;
-~~~
-
-~~~
-   statistics_name   |       column_names        |             created              | row_count | distinct_count | null_count |    histogram_id
----------------------+---------------------------+----------------------------------+-----------+----------------+------------+---------------------
-  __auto__           | {city}                    | 2020-08-26 16:55:24.725089+00:00 |       500 |              9 |          0 | 584550071425531905
-  __auto__           | {id}                      | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071432740865
-  __auto__           | {city,id}                 | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 |               NULL
-  __auto__           | {rider_id}                | 2020-08-26 16:55:24.725089+00:00 |       500 |             50 |          0 | 584550071446732801
-  __auto__           | {city,rider_id}           | 2020-08-26 16:55:24.725089+00:00 |       500 |             50 |          0 |               NULL
-  __auto__           | {vehicle_city}            | 2020-08-26 16:55:24.725089+00:00 |       500 |              9 |          0 | 584550071461019649
-  __auto__           | {vehicle_id}              | 2020-08-26 16:55:24.725089+00:00 |       500 |             15 |          0 | 584550071467966465
-  __auto__           | {vehicle_city,vehicle_id} | 2020-08-26 16:55:24.725089+00:00 |       500 |             15 |          0 |               NULL
-  __auto__           | {start_address}           | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071482122241
-  __auto__           | {end_address}             | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071489167361
-  __auto__           | {start_time}              | 2020-08-26 16:55:24.725089+00:00 |       500 |             30 |          0 | 584550071496671233
-  __auto__           | {end_time}                | 2020-08-26 16:55:24.725089+00:00 |       500 |            367 |          0 | 584550071504437249
-  __auto__           | {revenue}                 | 2020-08-26 16:55:24.725089+00:00 |       500 |            100 |          0 | 584550071512137729
-  revenue_stats      | {revenue}                 | 2020-08-26 16:55:33.986698+00:00 |       500 |            100 |          0 | 584550101775384577
-  city_revenue_stats | {city,revenue}            | 2020-08-26 16:55:52.539795+00:00 |       500 |            372 |          0 |               NULL
-(15 rows)
-~~~
-
-<span class="version-tag">New in v20.2:</span> Multi-column statistics are automatically collected for all columns that prefix an index. In this example, `city` and `revenue` are not an index prefix, making the `city_revenue_stats` statistics unique for the table.
-
-### Create statistics on a default set of columns
-
-The `CREATE STATISTICS` statement shown below automatically figures out which columns to get statistics on.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE STATISTICS users_stats FROM users;
-~~~
-
-This statement creates statistics identical to the statistics that CockroachDB creates automatically.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW STATISTICS FOR TABLE users;
-~~~
-
-~~~
-  statistics_name | column_names  |             created              | row_count | distinct_count | null_count |    histogram_id
-------------------+---------------+----------------------------------+-----------+----------------+------------+---------------------
-  __auto__        | {city}        | 2020-08-26 16:55:24.765331+00:00 |        50 |              9 |          0 | 584550071556964353
-  __auto__        | {id}          | 2020-08-26 16:55:24.765331+00:00 |        50 |             50 |          0 | 584550071563976705
-  __auto__        | {city,id}     | 2020-08-26 16:55:24.765331+00:00 |        50 |             50 |          0 |               NULL
-  __auto__        | {name}        | 2020-08-26 16:55:24.765331+00:00 |        50 |             49 |          0 | 584550071577477121
-  __auto__        | {address}     | 2020-08-26 16:55:24.765331+00:00 |        50 |             50 |          0 | 584550071583997953
-  __auto__        | {credit_card} | 2020-08-26 16:55:24.765331+00:00 |        50 |             50 |          0 | 584550071591141377
-  users_stats     | {city}        | 2020-08-26 16:56:12.802308+00:00 |        50 |              9 |          0 | 584550228973027329
-  users_stats     | {id}          | 2020-08-26 16:56:12.802308+00:00 |        50 |             50 |          0 | 584550228985905153
-  users_stats     | {city,id}     | 2020-08-26 16:56:12.802308+00:00 |        50 |             50 |          0 |               NULL
-  users_stats     | {name}        | 2020-08-26 16:56:12.802308+00:00 |        50 |             49 |          0 | 584550229015625729
-  users_stats     | {address}     | 2020-08-26 16:56:12.802308+00:00 |        50 |             50 |          0 | 584550229028765697
-  users_stats     | {credit_card} | 2020-08-26 16:56:12.802308+00:00 |        50 |             50 |          0 | 584550229043937281
-(12 rows)
-~~~
-
-### Create statistics as of a given time
-
-To create statistics as of a given time (in this example, 1 minute ago to avoid interfering with the production workload), run a statement like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE STATISTICS vehicle_stats_1 FROM vehicles AS OF SYSTEM TIME '-1m';
-~~~
-
-For more information about how the `AS OF SYSTEM TIME` clause works, including supported time formats, see [`AS OF SYSTEM TIME`](as-of-system-time.html).
-
-### Delete statistics
-
-{% include {{ page.version.version }}/misc/delete-statistics.md %}
-
-### View statistics jobs
-
-Every time the `CREATE STATISTICS` statement is executed, it kicks off a background job. This is true for queries issued by your application as well as queries issued by the [automatic stats feature](cost-based-optimizer.html#table-statistics).
-
-To view statistics jobs, there are two options:
-
-1. Use  [`SHOW JOBS`](show-jobs.html) to see all statistics jobs that were created by user queries (i.e., someone entering `CREATE STATISTICS` at the SQL prompt or via application code):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM [SHOW JOBS] WHERE job_type LIKE '%CREATE STATS%';
-    ~~~
-
-    ~~~
-            job_id       |   job_type   |                                           description                                            | statement | user_name |  status   | running_status |             created              |             started              |             finished             |             modified             | fraction_completed | error | coordinator_id
-    ---------------------+--------------+--------------------------------------------------------------------------------------------------+-----------+-----------+-----------+----------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+--------------------+-------+-----------------
-      584550101732950017 | CREATE STATS | CREATE STATISTICS revenue_stats ON revenue FROM movr.public.rides                                |           | root      | succeeded | NULL           | 2020-08-26 16:55:33.976113+00:00 | 2020-08-26 16:55:33.979043+00:00 | 2020-08-26 16:55:33.990197+00:00 | 2020-08-26 16:55:33.989405+00:00 |                  1 |       |           NULL
-      584550162508382209 | CREATE STATS | CREATE STATISTICS city_revenue_stats ON city, revenue FROM movr.public.rides                     |           | root      | succeeded | NULL           | 2020-08-26 16:55:52.523299+00:00 | 2020-08-26 16:55:52.527194+00:00 | 2020-08-26 16:55:52.544301+00:00 | 2020-08-26 16:55:52.543148+00:00 |                  1 |       |           NULL
-      584550228891500545 | CREATE STATS | CREATE STATISTICS users_stats FROM movr.public.users                                             |           | root      | succeeded | NULL           | 2020-08-26 16:56:12.781808+00:00 | 2020-08-26 16:56:12.789111+00:00 | 2020-08-26 16:56:12.830659+00:00 | 2020-08-26 16:56:12.82907+00:00  |                  1 |       |           NULL
-      584550307147874305 | CREATE STATS | CREATE STATISTICS vehicle_stats_1 FROM movr.public.vehicles WITH OPTIONS AS OF SYSTEM TIME '-1m' |           | root      | succeeded | NULL           | 2020-08-26 16:56:36.663773+00:00 | 2020-08-26 16:56:36.668101+00:00 | 2020-08-26 16:56:36.705743+00:00 | 2020-08-26 16:56:36.704696+00:00 |                  1 |       |           NULL
-    (5 rows)
-    ~~~
-
-2. Use `SHOW AUTOMATIC JOBS` to see statistics jobs that were created by the [automatic statistics feature](cost-based-optimizer.html#table-statistics):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM [SHOW AUTOMATIC JOBS] WHERE job_type LIKE '%CREATE STATS%';
-    ~~~
-
-    ~~~
-            job_id       |     job_type      |                             description                             |                                         statement                                         | user_name |  status   | running_status |             created              |             started              |             finished             |             modified             | fraction_completed | error | coordinator_id
-    ---------------------+-------------------+---------------------------------------------------------------------+-------------------------------------------------------------------------------------------+-----------+-----------+----------------+----------------------------------+----------------------------------+----------------------------------+----------------------------------+--------------------+-------+-----------------
-      584550071026876417 | AUTO CREATE STATS | Table statistics refresh for movr.public.user_promo_codes           | CREATE STATISTICS __auto__ FROM [58] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s' | root      | succeeded | NULL           | 2020-08-26 16:55:24.605364+00:00 | 2020-08-26 16:55:24.608296+00:00 | 2020-08-26 16:55:24.632626+00:00 | 2020-08-26 16:55:24.631635+00:00 |                  1 |       |           NULL
-      584550071124131841 | AUTO CREATE STATS | Table statistics refresh for movr.public.vehicle_location_histories | CREATE STATISTICS __auto__ FROM [56] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s' | root      | succeeded | NULL           | 2020-08-26 16:55:24.635051+00:00 | 2020-08-26 16:55:24.636861+00:00 | 2020-08-26 16:55:24.672699+00:00 | 2020-08-26 16:55:24.671777+00:00 |                  1 |       |           NULL
-      584550071255498753 | AUTO CREATE STATS | Table statistics refresh for movr.public.promo_codes                | CREATE STATISTICS __auto__ FROM [57] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s' | root      | succeeded | NULL           | 2020-08-26 16:55:24.675136+00:00 | 2020-08-26 16:55:24.677263+00:00 | 2020-08-26 16:55:24.709619+00:00 | 2020-08-26 16:55:24.708881+00:00 |                  1 |       |           NULL
-      584550071376281601 | AUTO CREATE STATS | Table statistics refresh for movr.public.rides                      | CREATE STATISTICS __auto__ FROM [55] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s' | root      | succeeded | NULL           | 2020-08-26 16:55:24.712003+00:00 | 2020-08-26 16:55:24.713674+00:00 | 2020-08-26 16:55:24.754449+00:00 | 2020-08-26 16:55:24.753735+00:00 |                  1 |       |           NULL
-      584550071523082241 | AUTO CREATE STATS | Table statistics refresh for movr.public.users                      | CREATE STATISTICS __auto__ FROM [53] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s' | root      | succeeded | NULL           | 2020-08-26 16:55:24.756802+00:00 | 2020-08-26 16:55:24.758638+00:00 | 2020-08-26 16:55:24.77889+00:00  | 2020-08-26 16:55:24.777899+00:00 |                  1 |       |           NULL
-      584550071604314113 | AUTO CREATE STATS | Table statistics refresh for movr.public.vehicles                   | CREATE STATISTICS __auto__ FROM [54] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s' | root      | succeeded | NULL           | 2020-08-26 16:55:24.781594+00:00 | 2020-08-26 16:55:24.783519+00:00 | 2020-08-26 16:55:24.815104+00:00 | 2020-08-26 16:55:24.814103+00:00 |                  1 |       |           NULL
-    (6 rows)
-    ~~~
-
-## See Also
-
-- [Cost-Based Optimizer](cost-based-optimizer.html)
-- [`SHOW STATISTICS`](show-statistics.html)
-- [`CREATE TABLE`](create-table.html)
-- [`INSERT`](insert.html)
-- [`IMPORT`](import.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/create-table-as.md b/src/current/v20.2/create-table-as.md
deleted file mode 100644
index 961d6b8f146..00000000000
--- a/src/current/v20.2/create-table-as.md
+++ /dev/null
@@ -1,360 +0,0 @@
----
-title: CREATE TABLE AS
-summary: The CREATE TABLE AS statement persists the result of a query into the database for later reuse.
-toc: true
----
-
-The `CREATE TABLE ... AS` [statement](sql-statements.html) creates a new table from a [selection query](selection-queries.html).
-
-
-## Intended use
-
-Tables created with `CREATE TABLE ... AS` are intended to persist the
-result of a query for later reuse.
-
-This can be more efficient than a [view](create-view.html) when the
-following two conditions are met:
-
-- The result of the query is used as-is multiple times.
-- The copy needs not be kept up-to-date with the original table over time.
-
-When the results of a query are reused multiple times within a larger
-query, a view is advisable instead. The query optimizer can "peek"
-into the view and optimize the surrounding query using the primary key
-and indices of the tables mentioned in the view query.
-
-A view is also advisable when the results must be up-to-date; a view
-always retrieves the current data from the tables that the view query
-mentions.
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the parent database.
-
-## Synopsis
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="basic">Basic</button>
-  <button style="width: 15%" class="filter-button" data-scope="expanded">Expanded</button>
-</div><p></p>
-
-<div class="filter-content horizontal-scroll" markdown="1" data-scope="basic">
-{% include {{ page.version.version }}/sql/diagrams/create_table_as.html %}
-</div>
-
-<div class="filter-content" markdown="1" data-scope="expanded">
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/create_table_as.html %}
-</div>
-
-**create_as_col_qual_list ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_as_col_qual_list.html %}
-</div>
-
-**create_as_constraint_def ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_as_constraint_def.html %}
-</div>
-
-**opt_with_storage_parameter_list ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/opt_with_storage_parameter_list.html %}
-</div>
-
-</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
- Parameter | Description
------------|-------------
- `IF NOT EXISTS` | Create a new table only if a table of the same name does not already exist in the database; if one does exist, do not return an error.<br><br>Note that `IF NOT EXISTS` checks the table name only; it does not check if an existing table has the same columns, indexes, constraints, etc., of the new table.
- `table_name` | The name of the table to create, which must be unique within its database and follow these [identifier rules](keywords-and-identifiers.html#identifiers). When the parent database is not set as the default, the name must be formatted as `database.name`.<br><br>The [`UPSERT`](upsert.html) and [`INSERT ON CONFLICT`](insert.html) statements use a temporary table called `excluded` to handle uniqueness conflicts during execution. It's therefore not recommended to use the name `excluded` for any of your tables.
- `column_name` | The name of the column you want to use instead of the name of the column from `select_stmt`.
- `create_as_col_qual_list` | An optional column definition, which may include [primary key constraints](primary-key.html) and [column family assignments](column-families.html).
- `family_def` | An optional [column family definition](column-families.html). Column family names must be unique within the table but can have the same name as columns, constraints, or indexes.
- `create_as_constraint_def` | An optional [primary key constraint](primary-key.html).
- `select_stmt` | A [selection query](selection-queries.html) to provide the data.
- `opt_persistence_temp_table` |  Defines the table as a session-scoped temporary table. For more information, see [Temporary Tables](temporary-tables.html).<br><br>Note that the `LOCAL`, `GLOBAL`, and `UNLOGGED` options are no-ops, allowed by the parser for PostgresSQL compatibility.<br><br>**Support for temporary tables is [experimental](experimental-features.html#temporary-objects)**.
- `opt_with_storage_parameter_list` | <span class="version-tag">New in v20.2:</span> A comma-separated list of [spatial index tuning parameters](spatial-indexes.html#index-tuning-parameters). Supported parameters include `fillfactor`, `s2_max_level`, `s2_level_mod`, `s2_max_cells`, `geometry_min_x`, `geometry_max_x`, `geometry_min_y`, and `geometry_max_y`. The `fillfactor` parameter is a no-op, allowed for PostgreSQL-compatibility.<br><br>For details, see [Spatial index tuning parameters](spatial-indexes.html#index-tuning-parameters). For an example, see [Create a spatial index that uses all of the tuning parameters](spatial-indexes.html#create-a-spatial-index-that-uses-all-of-the-tuning-parameters).
- `ON COMMIT PRESERVE ROWS` | This clause is a no-op, allowed by the parser for PostgresSQL compatibility. CockroachDB only supports session-scoped [temporary tables](temporary-tables.html), and does not support the clauses `ON COMMIT DELETE ROWS` and `ON COMMIT DROP`, which are used to define transaction-scoped temporary tables in PostgreSQL.
-
-## Limitations
-
-- The default rules for [column families](column-families.html) apply.
-
-- The [primary key](primary-key.html) of tables created with `CREATE TABLE ... AS` is not automatically derived from the query results. You must specify new primary keys at table creation. For examples, see [Specify a primary key](create-table-as.html#specify-a-primary-key) and [Specify a primary key for partitioning](create-table-as.html#specify-a-primary-key-for-partitioning).
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Create a table from a `SELECT` query
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users WHERE city = 'new york';
-~~~
-~~~
-                   id                  |   city   |       name       |           address           | credit_card
-+--------------------------------------+----------+------------------+-----------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills        | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57 | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61 | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8   | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley              | 0792553487
-  19999999-9999-4a00-8000-000000000005 | new york | Nicole Mcmahon   | 11540 Patton Extensions     | 0303726947
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users_ny AS SELECT * FROM users WHERE city = 'new york';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users_ny;
-~~~
-~~~
-                   id                  |   city   |       name       |           address           | credit_card
-+--------------------------------------+----------+------------------+-----------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills        | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57 | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61 | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8   | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley              | 0792553487
-  19999999-9999-4a00-8000-000000000005 | new york | Nicole Mcmahon   | 11540 Patton Extensions     | 0303726947
-(6 rows)
-~~~
-
-### Change column names
-
-This statement creates a copy of an existing table but with changed column names:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users_ny_names (user_id, user_name) AS SELECT id, name FROM users WHERE city = 'new york';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users_ny_names;
-~~~
-~~~
-                user_id                |    user_name
-+--------------------------------------+------------------+
-  00000000-0000-4000-8000-000000000000 | Robert Murphy
-  051eb851-eb85-4ec0-8000-000000000001 | James Hamilton
-  0a3d70a3-d70a-4d80-8000-000000000002 | Judy White
-  0f5c28f5-c28f-4c00-8000-000000000003 | Devin Jordan
-  147ae147-ae14-4b00-8000-000000000004 | Catherine Nelson
-  19999999-9999-4a00-8000-000000000005 | Nicole Mcmahon
-(6 rows)
-~~~
-
-### Create a table from a `VALUES` clause
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE drivers (id, city, name) AS VALUES (gen_random_uuid(), 'new york', 'Harry Potter'), (gen_random_uuid(), 'seattle', 'Evelyn Martin');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM drivers;
-~~~
-~~~
-                   id                  |   city   |     name
-+--------------------------------------+----------+---------------+
-  146eebc4-c913-4678-8ea3-c5797d2b7f83 | new york | Harry Potter
-  43cafd3b-2537-4fd8-a987-8138f88a22a4 | seattle  | Evelyn Martin
-(2 rows)
-~~~
-
-### Create a copy of an existing table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users_ny_copy AS TABLE users_ny;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users_ny_copy;
-~~~
-~~~
-                   id                  |   city   |       name       |           address           | credit_card
-+--------------------------------------+----------+------------------+-----------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills        | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57 | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61 | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8   | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley              | 0792553487
-  19999999-9999-4a00-8000-000000000005 | new york | Nicole Mcmahon   | 11540 Patton Extensions     | 0303726947
-(6 rows)
-~~~
-
-When a table copy is created this way, the copy is not associated to
-any primary key, secondary index, or constraint that was present on the
-original table.
-
-### Specify a primary key
-
-You can specify the [primary key](primary-key.html) of a new table created from a selection query:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users_ny_pk (id, city, name PRIMARY KEY) AS SELECT id, city, name FROM users WHERE city = 'new york';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users_ny_pk;
-~~~
-~~~
-                   id                  |   city   |       name
-+--------------------------------------+----------+------------------+
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White
-  19999999-9999-4a00-8000-000000000005 | new york | Nicole Mcmahon
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users_ny_pk;
-~~~
-~~~
-    table_name   |                 create_statement
-+----------------+--------------------------------------------------+
-  users_ny_extra | CREATE TABLE users_ny_extra (
-                 |     id UUID NULL,
-                 |     city VARCHAR NULL,
-                 |     name VARCHAR NOT NULL,
-                 |     CONSTRAINT "primary" PRIMARY KEY (name ASC),
-                 |     FAMILY "primary" (id, city, name)
-                 | )
-(1 row)
-~~~
-
-### Define column families
-
-You can define the [column families](column-families.html) of a new table created from a selection query:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users_ny_alt (id PRIMARY KEY FAMILY ids, name, city FAMILY locs, address, credit_card FAMILY payments) AS SELECT id, name, city, address, credit_card FROM users WHERE city = 'new york';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users_ny_alt;
-~~~
-~~~
-                   id                  |       name       |   city   |           address           | credit_card
-+--------------------------------------+------------------+----------+-----------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | Robert Murphy    | new york | 99176 Anderson Mills        | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | James Hamilton   | new york | 73488 Sydney Ports Suite 57 | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | Judy White       | new york | 18580 Rosario Ville Apt. 61 | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | Devin Jordan     | new york | 81127 Angela Ferry Apt. 8   | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | Catherine Nelson | new york | 1149 Lee Alley              | 0792553487
-  19999999-9999-4a00-8000-000000000005 | Nicole Mcmahon   | new york | 11540 Patton Extensions     | 0303726947
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users_ny_alt;
-~~~
-~~~
-   table_name  |                create_statement
-+--------------+------------------------------------------------+
-  users_ny_alt | CREATE TABLE users_ny_alt (
-               |     id UUID NOT NULL,
-               |     name VARCHAR NULL,
-               |     city VARCHAR NULL,
-               |     address VARCHAR NULL,
-               |     credit_card VARCHAR NULL,
-               |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-               |     FAMILY ids (id, name, address),
-               |     FAMILY locs (city),
-               |     FAMILY payments (credit_card)
-               | )
-(1 row)
-~~~
-
-### Specify a primary key for partitioning
-
-If you are [partitioning](partitioning.html) a table based on a [primary key](primary-key.html), the primary key must be properly defined. To change the primary key after table creation, you can use an [`ALTER TABLE ... ALTER PRIMARY KEY`](alter-primary-key.html) statement.
-
-Suppose that you want to [geo-partition](demo-low-latency-multi-region-deployment.html) the `drivers` table that you created with the following statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE drivers (id, city, name) AS VALUES (gen_random_uuid(), 'new york', 'Harry Potter'), (gen_random_uuid(), 'seattle', 'Evelyn Martin');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE drivers;
-~~~
-~~~
-  table_name |               create_statement
-+------------+----------------------------------------------+
-  drivers    | CREATE TABLE drivers (
-             |     id UUID NULL,
-             |     city STRING NULL,
-             |     name STRING NULL,
-             |     FAMILY "primary" (id, city, name, rowid)
-             | )
-(1 row)
-~~~
-
-In order for this table to be properly geo-partitioned with the other tables in the `movr` dataset, the table must have a composite primary key defined that includes the unique row identifier (`id`, in this case) and the row locality identifier (`city`). Use the following statement to change the primary key to a composite primary key:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE drivers_pk (id, city, name, PRIMARY KEY (id, city)) AS SELECT id, city, name FROM drivers;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE drivers_pk;
-~~~
-~~~
-  table_name |                     create_statement
-+------------+----------------------------------------------------------+
-  drivers_pk | CREATE TABLE drivers_pk (
-             |     id UUID NOT NULL,
-             |     city STRING NOT NULL,
-             |     name STRING NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC, city ASC),
-             |     FAMILY "primary" (id, city, name)
-             | )
-(1 row)
-~~~
-
-## See also
-
-- [Selection Queries](selection-queries.html)
-- [Simple `SELECT` Clause](select-clause.html)
-- [`CREATE TABLE`](create-table.html)
-- [`CREATE VIEW`](create-view.html)
-- [`INSERT`](insert.html)
-- [`DROP TABLE`](drop-table.html)
-- [Other SQL Statements](sql-statements.html)
-- [`ALTER PRIMARY KEY`](alter-primary-key.html)
-- [`ALTER TABLE`](alter-table.html)
diff --git a/src/current/v20.2/create-table.md b/src/current/v20.2/create-table.md
deleted file mode 100644
index f388d97ecaa..00000000000
--- a/src/current/v20.2/create-table.md
+++ /dev/null
@@ -1,781 +0,0 @@
----
-title: CREATE TABLE
-summary: The CREATE TABLE statement creates a new table in a database.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-The `CREATE TABLE` [statement](sql-statements.html) creates a new table in a database.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the parent database.
-
-## Synopsis
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="basic">Basic</button>
-  <button style="width: 15%" class="filter-button" data-scope="expanded">Expanded</button>
-</div><p></p>
-
-<div class="filter-content" markdown="1" data-scope="basic">
-{% include {{ page.version.version }}/sql/diagrams/create_table.html %}
-</div>
-
-<div class="filter-content" markdown="1" data-scope="expanded">
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_table.html %}
-</div>
-
-**opt_persistence_temp_table ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/opt_persistence_temp_table.html %}
-</div>
-
-**column_def ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/column_def.html %}
-</div>
-
-**col_qualification ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/col_qualification.html %}
-</div>
-
-**index_def ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/index_def.html %}
-</div>
-
-**family_def ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/family_def.html %}
-</div>
-
-**table_constraint ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/table_constraint.html %}
-</div>
-
-**like_table_option_list::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/like_table_option_list.html %}
-</div>
-
-
-**opt_with_storage_parameter_list ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/opt_with_storage_parameter_list.html %}
-</div>
-
-</div>
-
-{{site.data.alerts.callout_success}}To create a table from the results of a <code>SELECT</code> statement, use <a href="create-table-as.html"><code>CREATE TABLE AS</code></a>.
-{{site.data.alerts.end}}
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`opt_persistence_temp_table` |  Defines the table as a session-scoped temporary table. For more information, see [Temporary Tables](temporary-tables.html).<br><br>Note that the `LOCAL`, `GLOBAL`, and `UNLOGGED` options are no-ops, allowed by the parser for PostgresSQL compatibility.<br><br>**Support for temporary tables is [experimental](experimental-features.html#temporary-objects)**.
-`IF NOT EXISTS` | Create a new table only if a table of the same name does not already exist in the database; if one does exist, do not return an error.<br><br>Note that `IF NOT EXISTS` checks the table name only; it does not check if an existing table has the same columns, indexes, constraints, etc., of the new table.
-`table_name` | The name of the table to create, which must be unique within its database and follow these [identifier rules](keywords-and-identifiers.html#identifiers). When the parent database is not set as the default, the name must be formatted as `database.name`.<br><br>The [`UPSERT`](upsert.html) and [`INSERT ON CONFLICT`](insert.html) statements use a temporary table called `excluded` to handle uniqueness conflicts during execution. It's therefore not recommended to use the name `excluded` for any of your tables.
-`column_def` | A comma-separated list of column definitions. Each column requires a [name/identifier](keywords-and-identifiers.html#identifiers) and [data type](data-types.html); optionally, a [column-level constraint](constraints.html) or other column qualification (e.g., [computed columns](computed-columns.html)) can be specified. Column names must be unique within the table but can have the same name as indexes or constraints.<br><br>Any `PRIMARY KEY`, `UNIQUE`, and `CHECK` [constraints](constraints.html) defined at the column level are moved to the table-level as part of the table's creation. Use the [`SHOW CREATE`](show-create.html) statement to view them at the table level.
-`index_def` | An optional, comma-separated list of [index definitions](indexes.html). For each index, the column(s) to index must be specified; optionally, a name can be specified. Index names must be unique within the table and follow these [identifier rules](keywords-and-identifiers.html#identifiers). See the [Create a Table with Secondary Indexes and GIN Indexes](#create-a-table-with-secondary-and-gin-indexes) example below.<br><br> To enable [hash-sharded indexes](hash-sharded-indexes.html), set the `experimental_enable_hash_sharded_indexes` [session variable](set-vars.html) to `on`. For examples, see [Create a table with hash-sharded indexes](#create-a-table-with-a-hash-sharded-primary-index) below.<br><br>The [`CREATE INDEX`](create-index.html) statement can be used to create an index separate from table creation.
-`family_def` | An optional, comma-separated list of [column family definitions](column-families.html). Column family names must be unique within the table but can have the same name as columns, constraints, or indexes.<br><br>A column family is a group of columns that are stored as a single key-value pair in the underlying key-value store. CockroachDB automatically groups columns into families to ensure efficient storage and performance. However, there are cases when you may want to manually assign columns to families. For more details, see [Column Families](column-families.html).
-`table_constraint` | An optional, comma-separated list of [table-level constraints](constraints.html). Constraint names must be unique within the table but can have the same name as columns, column families, or indexes.
-`LIKE table_name like_table_option_list` | <span class="version-tag">New in v20.2:</span> Create a new table based on the schema of an existing table, using supported specifiers. For details, see [Create a table like an existing table](#create-a-table-like-an-existing-table). For examples, see [Create a new table from an existing one](#create-a-new-table-from-an-existing-one).
-`opt_partition_by` | An [Enterprise-only](enterprise-licensing.html) option that lets you define table partitions at the row level. You can define table partitions by list or by range. See [Define Table Partitions](partitioning.html) for more information.
-`opt_where_clause` | <span class="version-tag">New in v20.2:</span> An optional `WHERE` clause that defines the predicate boolean expression of a [partial index](partial-indexes.html).
-`opt_with_storage_parameter_list` | <span class="version-tag">New in v20.2:</span> A comma-separated list of [spatial index tuning parameters](spatial-indexes.html#index-tuning-parameters). Supported parameters include `fillfactor`, `s2_max_level`, `s2_level_mod`, `s2_max_cells`, `geometry_min_x`, `geometry_max_x`, `geometry_min_y`, and `geometry_max_y`. The `fillfactor` parameter is a no-op, allowed for PostgreSQL-compatibility.<br><br>For details, see [Spatial index tuning parameters](spatial-indexes.html#index-tuning-parameters). For an example, see [Create a spatial index that uses all of the tuning parameters](spatial-indexes.html#create-a-spatial-index-that-uses-all-of-the-tuning-parameters).
-`ON COMMIT PRESERVE ROWS` | This clause is a no-op, allowed by the parser for PostgresSQL compatibility. CockroachDB only supports session-scoped [temporary tables](temporary-tables.html), and does not support the clauses `ON COMMIT DELETE ROWS` and `ON COMMIT DROP`, which are used to define transaction-scoped temporary tables in PostgreSQL.
-`opt_interleave` | [Interleave table into parent table](interleave-in-parent.html).<br>{% include {{ page.version.version }}/misc/interleave-deprecation-note.md %}
-
-## Table-level replication
-
-By default, tables are created in the default replication zone but can be placed into a specific replication zone. See [Create a Replication Zone for a Table](configure-replication-zones.html#create-a-replication-zone-for-a-table) for more information.
-
-## Row-level replication
-
-CockroachDB allows [Enterprise users](enterprise-licensing.html) to [define table partitions](partitioning.html), thus providing row-level control of how and where the data is stored. See [Create a Replication Zone for a Table Partition](configure-replication-zones.html#create-a-replication-zone-for-a-partition) for more information.
-
-{{site.data.alerts.callout_info}}The primary key required for partitioning is different from the conventional primary key. To define the primary key for partitioning, prefix the unique identifier(s) in the primary key with all columns you want to partition and subpartition the table on, in the order in which you want to nest your subpartitions. See <a href=partitioning.html#partition-using-primary-key>Partition using Primary Key</a> for more details.{{site.data.alerts.end}}
-
-## Create a table like an existing table
-
-<span class="version-tag">New in v20.2:</span> CockroachDB supports the `CREATE TABLE LIKE` syntax for creating a new table based on the schema of an existing table.
-
-The following options are supported:
-
-- `INCLUDING CONSTRAINTS` adds all [`CHECK`](check.html) constraints from the source table.
-- `INCLUDING DEFAULTS` adds all [`DEFAULT`](default-value.html) column expressions from the source table.
-- `INCLUDING GENERATED` adds all [computed column](computed-columns.html) expressions from the source table.
-- `INCLUDING INDEXES` adds all [indexes](indexes.html) from the source table.
-- `INCLUDING ALL` includes all of the specifiers above.
-
-To exclude specifiers, use the `EXCLUDING` keyword. Excluding specifiers can be useful if you want to use `INCLUDING ALL`, and exclude just one or two specifiers. The last `INCLUDING`/`EXCLUDING` keyword for a given specifier takes priority.
-
-{{site.data.alerts.callout_info}}
-Column families, partitioning, interleavings, and foreign key constraints
-cannot be preserved from the old table and will have to be recreated
-manually in the new table if the user wishes.
-{{site.data.alerts.end}}
-
-Supported `LIKE` specifiers can also be mixed with ordinary `CREATE TABLE` specifiers. For example:
-
-~~~ sql
-CREATE TABLE table1 (a INT PRIMARY KEY, b INT NOT NULL DEFAULT 3 CHECK (b > 0), INDEX(b));
-
-CREATE TABLE table2 (LIKE table1 INCLUDING ALL EXCLUDING CONSTRAINTS, c INT, INDEX(b,c));
-~~~
-
-In this example, `table2` is created with the indexes and default values of `table1`, but not the `CHECK` constraints, because `EXCLUDING CONSTRAINTS` was
-specified after `INCLUDING ALL`. `table2` also includes an additional column and index.
-
-For additional examples, see [Create a new table from an existing one](#create-a-new-table-from-an-existing-one).
-
-## Examples
-
-### Create a table
-
-In this example, we create the `users` table with a single [primary key](primary-key.html) column defined. In CockroachDB, every table requires a [primary key](primary-key.html). If one is not explicitly defined, a column called `rowid` of the type `INT` is added automatically as the primary key, with the `unique_rowid()` function used to ensure that new rows always default to unique `rowid` values. The primary key is automatically indexed.
-
-For performance recommendations on primary keys, see the [Schema Design: Create a Table](schema-design-table.html) page and the [SQL Performance Best Practices](performance-best-practices-overview.html#use-multi-column-primary-keys) page.
-
-{{site.data.alerts.callout_info}}
-  If no primary key is explicitly defined in a `CREATE TABLE` statement, you can add a primary key to the table with [`ADD CONSTRAINT ... PRIMARY KEY`](add-constraint.html) or [`ALTER PRIMARY KEY`](alter-primary-key.html). If the `ADD` or `ALTER` statement follows the `CREATE TABLE` statement, and is part of the same transaction, no default primary key will be created. If the table has already been created and the transaction committed, the `ADD` or `ALTER` statements replace the default primary key.
- {{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}Strictly speaking, a primary key's unique index is not created; it is derived from the key(s) under which the data is stored, so it takes no additional space. However, it appears as a normal unique index when using commands like <code>SHOW INDEX</code>.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-        id UUID PRIMARY KEY,
-        city STRING,
-        name STRING,
-        address STRING,
-        credit_card STRING,
-        dl STRING
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  city        | STRING    |    true     | NULL           |                       | {}        |   false
-  name        | STRING    |    true     | NULL           |                       | {}        |   false
-  address     | STRING    |    true     | NULL           |                       | {}        |   false
-  credit_card | STRING    |    true     | NULL           |                       | {}        |   false
-  dl          | STRING    |    true     | NULL           |                       | {}        |   false
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM users;
-~~~
-
-~~~
-  table_name | index_name | non_unique | seq_in_index | column_name | direction | storing | implicit
-+------------+------------+------------+--------------+-------------+-----------+---------+----------+
-  users      | primary    |   false    |            1 | id          | ASC       |  false  |  false
-(1 row)
-~~~
-
-### Create a table with secondary and GIN indexes
-
-In this example, we create secondary and GIN indexes during table creation. Secondary indexes allow efficient access to data with keys other than the primary key. [GIN indexes](inverted-indexes.html) allow efficient access to the schemaless data in a [`JSONB`](jsonb.html) column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE vehicles (
-        id UUID NOT NULL,
-        city STRING NOT NULL,
-        type STRING,
-        owner_id UUID,
-        creation_time TIMESTAMP,
-        status STRING,
-        current_location STRING,
-        ext JSONB,
-        CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-        INDEX index_status (status),
-        INVERTED INDEX ix_vehicle_ext (ext),
-        FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM vehicles;
-~~~
-
-~~~
-  table_name |   index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+----------------+------------+--------------+-------------+-----------+---------+-----------
-  vehicles   | primary        |   false    |            1 | city        | ASC       |  false  |  false
-  vehicles   | primary        |   false    |            2 | id          | ASC       |  false  |  false
-  vehicles   | index_status   |    true    |            1 | status      | ASC       |  false  |  false
-  vehicles   | index_status   |    true    |            2 | city        | ASC       |  false  |   true
-  vehicles   | index_status   |    true    |            3 | id          | ASC       |  false  |   true
-  vehicles   | ix_vehicle_ext |    true    |            1 | ext         | ASC       |  false  |  false
-  vehicles   | ix_vehicle_ext |    true    |            2 | city        | ASC       |  false  |   true
-  vehicles   | ix_vehicle_ext |    true    |            3 | id          | ASC       |  false  |   true
-(8 rows)
-~~~
-
-We also have other resources on indexes:
-
-- Create indexes for existing tables using [`CREATE INDEX`](create-index.html).
-- [Learn more about indexes](indexes.html).
-
-### Create a table with auto-generated unique row IDs
-
-{% include {{ page.version.version }}/faq/auto-generate-unique-ids.html %}
-
-### Create a table with a foreign key constraint
-
-[Foreign key constraints](foreign-key.html) guarantee a column uses only values that already exist in the column it references, which must be from another table. This constraint enforces referential integrity between the two tables.
-
-There are a [number of rules](foreign-key.html#rules-for-creating-foreign-keys) that govern foreign keys, but the most important rule is that referenced columns must contain only unique values. This means the `REFERENCES` clause must use exactly the same columns as a [primary key](primary-key.html) or [unique](unique.html) constraint.
-
-You can include a [foreign key action](foreign-key.html#foreign-key-actions) to specify what happens when a column referenced by a foreign key constraint is updated or deleted. The default actions are `ON UPDATE NO ACTION` and `ON DELETE NO ACTION`.
-
-In this example, we use `ON DELETE CASCADE` (i.e., when row referenced by a foreign key constraint is deleted, all dependent rows are also deleted).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        city STRING,
-        name STRING,
-        address STRING,
-        credit_card STRING,
-        dl STRING UNIQUE CHECK (LENGTH(dl) < 8)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE vehicles (
-        id UUID NOT NULL DEFAULT gen_random_uuid(),
-        city STRING NOT NULL,
-        type STRING,
-        owner_id UUID REFERENCES users(id) ON DELETE CASCADE,
-        creation_time TIMESTAMP,
-        status STRING,
-        current_location STRING,
-        ext JSONB,
-        CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-        INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-        INVERTED INDEX ix_vehicle_ext (ext),
-        FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE vehicles;
-~~~
-
-~~~
-  table_name |                                          create_statement
-+------------+-----------------------------------------------------------------------------------------------------+
-  vehicles   | CREATE TABLE vehicles (
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     city STRING NOT NULL,
-             |     type STRING NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     status STRING NULL,
-             |     current_location STRING NULL,
-             |     ext JSONB NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-             |     INVERTED INDEX ix_vehicle_ext (ext),
-             |     CONSTRAINT fk_owner_id_ref_users FOREIGN KEY (owner_id) REFERENCES users(id) ON DELETE CASCADE,
-             |     INDEX vehicles_auto_index_fk_owner_id_ref_users (owner_id ASC),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-             | )
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users (name, dl) VALUES ('Annika', 'ABC-123');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users;
-~~~
-
-~~~
-                   id                  | city |  name  | address | credit_card |   dl
-+--------------------------------------+------+--------+---------+-------------+---------+
-  26da1fce-59e1-4290-a786-9068242dd195 | NULL | Annika | NULL    | NULL        | ABC-123
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO vehicles (city, owner_id) VALUES ('seattle', '26da1fce-59e1-4290-a786-9068242dd195');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM vehicles;
-~~~
-
-~~~
-                   id                  |  city   | type |               owner_id               | creation_time | status | current_location | ext
-+--------------------------------------+---------+------+--------------------------------------+---------------+--------+------------------+------+
-  fc6f7a8c-4ba9-42e1-9c37-7be3c906050c | seattle | NULL | 26da1fce-59e1-4290-a786-9068242dd195 | NULL          | NULL   | NULL             | NULL
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM users WHERE id = '26da1fce-59e1-4290-a786-9068242dd195';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM vehicles;
-~~~
-~~~
-  id | city | type | owner_id | creation_time | status | current_location | ext
-+----+------+------+----------+---------------+--------+------------------+-----+
-(0 rows)
-~~~
-
-
-### Create a table with a check constraint
-
-In this example, we create the `users` table, but with some column [constraints](constraints.html). One column is the [primary key](primary-key.html), and another column is given a [unique constraint](unique.html) and a [check constraint](check.html) that limits the length of the string. Primary key columns and columns with unique constraints are automatically indexed.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-        id UUID PRIMARY KEY,
-        city STRING,
-        name STRING,
-        address STRING,
-        credit_card STRING,
-        dl STRING UNIQUE CHECK (LENGTH(dl) < 8)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |        indices         | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+------------------------+-----------+
-  id          | UUID      |    false    | NULL           |                       | {primary,users_dl_key} |   false
-  city        | STRING    |    true     | NULL           |                       | {}                     |   false
-  name        | STRING    |    true     | NULL           |                       | {}                     |   false
-  address     | STRING    |    true     | NULL           |                       | {}                     |   false
-  credit_card | STRING    |    true     | NULL           |                       | {}                     |   false
-  dl          | STRING    |    true     | NULL           |                       | {users_dl_key}         |   false
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM users;
-~~~
-
-~~~
-  table_name |  index_name  | non_unique | seq_in_index | column_name | direction | storing | implicit
-+------------+--------------+------------+--------------+-------------+-----------+---------+----------+
-  users      | primary      |   false    |            1 | id          | ASC       |  false  |  false
-  users      | users_dl_key |   false    |            1 | dl          | ASC       |  false  |  false
-  users      | users_dl_key |   false    |            2 | id          | ASC       |  false  |   true
-(3 rows)
-~~~
-
-### Create a table that mirrors key-value storage
-
-{% include {{ page.version.version }}/faq/simulate-key-value-store.html %}
-
-### Create a table from a `SELECT` statement
-
-You can use the [`CREATE TABLE AS`](create-table-as.html) statement to create a new table from the results of a `SELECT` statement. For example, suppose you have a number of rows of user data in the `users` table, and you want to create a new table from the subset of users that are located in New York.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users WHERE city = 'new york';
-~~~
-
-~~~
-                   id                  |   city   |       name       |           address           | credit_card
-+--------------------------------------+----------+------------------+-----------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills        | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57 | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61 | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8   | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley              | 0792553487
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users_ny AS SELECT * FROM users WHERE city = 'new york';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users_ny;
-~~~
-
-~~~
-                   id                  |   city   |       name       |           address           | credit_card
-+--------------------------------------+----------+------------------+-----------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills        | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57 | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61 | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8   | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley              | 0792553487
-(5 rows)
-~~~
-
-### Create a table with a computed column
-
-{% include {{ page.version.version }}/computed-columns/simple.md %}
-
-### Create a table with partitions
-
-{{site.data.alerts.callout_info}}
-The primary key required for partitioning is different from the conventional primary key. To define the primary key for partitioning, prefix the unique identifier(s) in the primary key with all columns you want to partition and subpartition the table on, in the order in which you want to nest your subpartitions. See [Partition using Primary Key](partitioning.html#partition-using-primary-key) for more details.
-{{site.data.alerts.end}}
-
-#### Create a table with partitions by list
-
-In this example, we create a table and [define partitions by list](partitioning.html#partition-by-list).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE rides (
-        id UUID NOT NULL,
-        city STRING NOT NULL,
-        vehicle_city STRING,
-        rider_id UUID,
-        vehicle_id UUID,
-        start_address STRING,
-        end_address STRING,
-        start_time TIMESTAMP,
-        end_time TIMESTAMP,
-        revenue DECIMAL(10,2),
-        CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-        INDEX rides_auto_index_fk_city_ref_users (city ASC, rider_id ASC),
-        INDEX rides_auto_index_fk_vehicle_city_ref_vehicles (vehicle_city ASC, vehicle_id ASC),
-        FAMILY "primary" (id, city, vehicle_city, rider_id, vehicle_id, start_address, end_address, start_time, end_time, revenue),
-        CONSTRAINT check_vehicle_city_city CHECK (vehicle_city = city))
-        PARTITION BY LIST (city)
-          (PARTITION new_york VALUES IN ('new york'),
-          PARTITION chicago VALUES IN ('chicago'),
-          PARTITION seattle VALUES IN ('seattle'));
-~~~
-
-#### Create a table with partitions by range
-
-In this example, we create a table and [define partitions by range](partitioning.html#partition-by-range).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE rides (
-        id UUID NOT NULL,
-        city STRING NOT NULL,
-        vehicle_city STRING,
-        rider_id UUID,
-        vehicle_id UUID,
-        start_address STRING,
-        end_address STRING,
-        start_time TIMESTAMP,
-        end_time TIMESTAMP,
-        ride_length INTERVAL as (start_time - end_time) STORED,
-        revenue DECIMAL(10,2),
-        CONSTRAINT "primary" PRIMARY KEY (ride_length ASC, city ASC, id ASC),
-        INDEX rides_auto_index_fk_city_ref_users (city ASC, rider_id ASC),
-        INDEX rides_auto_index_fk_vehicle_city_ref_vehicles (vehicle_city ASC, vehicle_id ASC),
-        FAMILY "primary" (id, city, vehicle_city, rider_id, vehicle_id, start_address, end_address, start_time, end_time, revenue),
-        CONSTRAINT check_vehicle_city_city CHECK (vehicle_city = city))
-        PARTITION BY RANGE (ride_length)
-          (PARTITION short_rides VALUES FROM ('0 seconds') TO ('30 minutes'),
-          PARTITION long_rides VALUES FROM ('30 minutes') TO (MAXVALUE));
-~~~
-
-### Show the definition of a table
-
-To show the definition of a table, use the [`SHOW CREATE`](show-create.html) statement. The contents of the `create_statement` column in the response is a string with embedded line breaks that, when echoed, produces formatted output.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE rides;
-~~~
-
-~~~
-  table_name |                                                               create_statement
-+------------+----------------------------------------------------------------------------------------------------------------------------------------------+
-  rides      | CREATE TABLE rides (
-             |     id UUID NOT NULL,
-             |     city STRING NOT NULL,
-             |     vehicle_city STRING NULL,
-             |     rider_id UUID NULL,
-             |     vehicle_id UUID NULL,
-             |     start_address STRING NULL,
-             |     end_address STRING NULL,
-             |     start_time TIMESTAMP NULL,
-             |     end_time TIMESTAMP NULL,
-             |     ride_length INTERVAL NOT NULL AS (start_time - end_time) STORED,
-             |     revenue DECIMAL(10,2) NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (ride_length ASC, city ASC, id ASC),
-             |     INDEX rides_auto_index_fk_city_ref_users (city ASC, rider_id ASC),
-             |     INDEX rides_auto_index_fk_vehicle_city_ref_vehicles (vehicle_city ASC, vehicle_id ASC),
-             |     FAMILY "primary" (id, city, vehicle_city, rider_id, vehicle_id, start_address, end_address, start_time, end_time, revenue, ride_length),
-             |     CONSTRAINT check_vehicle_city_city CHECK (vehicle_city = city)
-             | ) PARTITION BY RANGE (ride_length) (
-             |     PARTITION short_rides VALUES FROM ('00:00:00') TO ('00:30:00'),
-             |     PARTITION long_rides VALUES FROM ('00:30:00') TO (MAXVALUE)
-             | )
-(1 row)
-~~~
-
-### Create a table with a hash-sharded primary index
-
-{% include {{page.version.version}}/performance/use-hash-sharded-indexes.md %}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET experimental_enable_hash_sharded_indexes=on;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE events (
-    ts DECIMAL PRIMARY KEY USING HASH WITH BUCKET_COUNT=8,
-    product_id INT8
-    );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM events;
-~~~
-
-~~~
-        column_name        | data_type | is_nullable | column_default |       generation_expression       |  indices  | is_hidden
----------------------------+-----------+-------------+----------------+-----------------------------------+-----------+------------
-  crdb_internal_ts_shard_8 | INT4      |    false    | NULL           | mod(fnv32(CAST(ts AS STRING)), 8) | {primary} |   true
-  ts                       | DECIMAL   |    false    | NULL           |                                   | {primary} |   false
-  product_id               | INT8      |    true     | NULL           |                                   | {}        |   false
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM events;
-~~~
-
-~~~
-  table_name | index_name | non_unique | seq_in_index |       column_name        | direction | storing | implicit
--------------+------------+------------+--------------+--------------------------+-----------+---------+-----------
-  events     | primary    |   false    |            1 | crdb_internal_ts_shard_8 | ASC       |  false  |  false
-  events     | primary    |   false    |            2 | ts                       | ASC       |  false  |  false
-(2 rows)
-~~~
-
-### Create a table with a hash-sharded secondary index
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET experimental_enable_hash_sharded_indexes=on;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE events (
-    product_id INT8,
-    owner UUID,
-    serial_number VARCHAR,
-    event_id UUID,
-    ts TIMESTAMP,
-    data JSONB,
-    PRIMARY KEY (product_id, owner, serial_number, ts, event_id),
-    INDEX (ts) USING HASH WITH BUCKET_COUNT=8
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM events;
-~~~
-
-~~~
-  table_name |               index_name               | non_unique | seq_in_index |       column_name        | direction | storing | implicit
--------------+----------------------------------------+------------+--------------+--------------------------+-----------+---------+-----------
-  events     | primary                                |   false    |            1 | product_id               | ASC       |  false  |  false
-  events     | primary                                |   false    |            2 | owner                    | ASC       |  false  |  false
-  events     | primary                                |   false    |            3 | serial_number            | ASC       |  false  |  false
-  events     | primary                                |   false    |            4 | ts                       | ASC       |  false  |  false
-  events     | primary                                |   false    |            5 | event_id                 | ASC       |  false  |  false
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            1 | crdb_internal_ts_shard_8 | ASC       |  false  |  false
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            2 | ts                       | ASC       |  false  |  false
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            3 | product_id               | ASC       |  false  |   true
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            4 | owner                    | ASC       |  false  |   true
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            5 | serial_number            | ASC       |  false  |   true
-  events     | events_crdb_internal_ts_shard_8_ts_idx |    true    |            6 | event_id                 | ASC       |  false  |   true
-(11 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM events;
-~~~
-
-~~~
-        column_name        | data_type | is_nullable | column_default |       generation_expression       |                     indices                      | is_hidden
----------------------------+-----------+-------------+----------------+-----------------------------------+--------------------------------------------------+------------
-  product_id               | INT8      |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  owner                    | UUID      |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  serial_number            | VARCHAR   |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  event_id                 | UUID      |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  ts                       | TIMESTAMP |    false    | NULL           |                                   | {primary,events_crdb_internal_ts_shard_8_ts_idx} |   false
-  data                     | JSONB     |    true     | NULL           |                                   | {}                                               |   false
-  crdb_internal_ts_shard_8 | INT4      |    false    | NULL           | mod(fnv32(CAST(ts AS STRING)), 8) | {events_crdb_internal_ts_shard_8_ts_idx}         |   true
-(7 rows)
-~~~
-
-### Create a new table from an existing one
-
-#### Create a table including all supported source specifiers
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE vehicles;
-~~~
-
-~~~
-  table_name |                                              create_statement
--------------+-------------------------------------------------------------------------------------------------------------
-  vehicles   | CREATE TABLE public.vehicles (
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     city STRING NOT NULL,
-             |     type STRING NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     status STRING NULL,
-             |     current_location STRING NULL,
-             |     ext JSONB NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     CONSTRAINT fk_owner_id_ref_users FOREIGN KEY (owner_id) REFERENCES public.users(id) ON DELETE CASCADE,
-             |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-             |     INVERTED INDEX ix_vehicle_ext (ext),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-             | )
-(1 row
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE vehicles2 (
-        LIKE vehicles INCLUDING ALL
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE vehicles2;
-~~~
-
-~~~
-  table_name |                                       create_statement
--------------+------------------------------------------------------------------------------------------------
-  vehicles2  | CREATE TABLE public.vehicles2 (
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     city STRING NOT NULL,
-             |     type STRING NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     status STRING NULL,
-             |     current_location STRING NULL,
-             |     ext JSONB NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-             |     INVERTED INDEX ix_vehicle_ext (ext),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-             | )
-(1 row)
-~~~
-
-Note that the foreign key constraint `fk_owner_id_ref_users` in the source table is not included in the new table.
-
-#### Create a table with some source specifiers and a foreign key constraint
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE vehicles3 (
-        LIKE vehicles INCLUDING DEFAULTS INCLUDING INDEXES,
-        CONSTRAINT fk_owner_id_ref_users FOREIGN KEY (owner_id) REFERENCES public.users(id) ON DELETE CASCADE
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE vehicles3;
-~~~
-
-~~~
-  table_name |                                              create_statement
--------------+-------------------------------------------------------------------------------------------------------------
-  vehicles3  | CREATE TABLE public.vehicles3 (
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     city STRING NOT NULL,
-             |     type STRING NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     status STRING NULL,
-             |     current_location STRING NULL,
-             |     ext JSONB NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     CONSTRAINT fk_owner_id_ref_users FOREIGN KEY (owner_id) REFERENCES public.users(id) ON DELETE CASCADE,
-             |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-             |     INVERTED INDEX ix_vehicle_ext (ext),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-             | )
-(1 row)
-~~~
-
-## See also
-
-- [`INSERT`](insert.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`DELETE`](delete.html)
-- [`DROP TABLE`](drop-table.html)
-- [`RENAME TABLE`](rename-table.html)
-- [`SHOW TABLES`](show-tables.html)
-- [`SHOW COLUMNS`](show-columns.html)
-- [Column Families](column-families.html)
-- [Table-Level Replication Zones](configure-replication-zones.html#create-a-replication-zone-for-a-table)
-- [Define Table Partitions](partitioning.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/create-type.md b/src/current/v20.2/create-type.md
deleted file mode 100644
index a8c181b23cf..00000000000
--- a/src/current/v20.2/create-type.md
+++ /dev/null
@@ -1,114 +0,0 @@
----
-title: CREATE TYPE
-summary: The CREATE TYPE statement creates a new, enumerated data type in a database.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `CREATE TYPE` [statement](sql-statements.html) creates a new, [enumerated data type](enum.html) in a database.
-
-{{site.data.alerts.callout_info}}
-CockroachDB currently only supports [enumerated user-defined types](enum.html).
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/create_type.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`type_name` | The name of the type. You can qualify the name with a [database and schema name](sql-name-resolution.html) (e.g., `db.typename`), but after the type is created, it can only be referenced from the database that contains the type.
-`opt_enum_val_list` | A list of values that make up the type's enumerated set.
-
-## Required privileges
-
-- To create a type, the user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the parent database.
-- To use a user-defined type in a table (e.g., when defining a column's type), the user must have the `USAGE` privilege on the type.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE status AS ENUM ('open', 'closed', 'inactive');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema |  name  |        value
----------+--------+-----------------------
-  public | status | open|closed|inactive
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE accounts (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        balance DECIMAL,
-        status status
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO accounts(balance,status) VALUES (500.50,'open'), (0.00,'closed'), (1.25,'inactive');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-                   id                  | balance |  status
----------------------------------------+---------+-----------
-  3848e36d-ebd4-44c6-8925-8bf24bba957e |  500.50 | open
-  60928059-ef75-47b1-81e3-25ec1fb6ff10 |    0.00 | closed
-  71ae151d-99c3-4505-8e33-9cda15fce302 |    1.25 | inactive
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE accounts;
-~~~
-
-~~~
-  table_name |                create_statement
--------------+--------------------------------------------------
-  accounts   | CREATE TABLE public.accounts (
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     balance DECIMAL NULL,
-             |     status public.status NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     FAMILY "primary" (id, balance, status)
-             | )
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts WHERE status='open';
-~~~
-
-~~~
-                   id                  | balance | status
----------------------------------------+---------+---------
-  3848e36d-ebd4-44c6-8925-8bf24bba957e |  500.50 | open
-(1 row)
-~~~
-
-## See also
-
-- [`ENUM`](enum.html)
-- [`ALTER TYPE`](alter-type.html)
-- [Data types](data-types.html)
-- [`SHOW ENUMS`](show-enums.html)
-- [`DROP TYPE`](drop-type.html)
diff --git a/src/current/v20.2/create-user.md b/src/current/v20.2/create-user.md
deleted file mode 100644
index 5aeae0aaf17..00000000000
--- a/src/current/v20.2/create-user.md
+++ /dev/null
@@ -1,322 +0,0 @@
----
-title: CREATE USER
-summary: The CREATE USER statement creates SQL roles that are preconfigured with the necessary login permission to act as database users.
-toc: true
----
-
-The `CREATE USER` [statement](sql-statements.html) creates a SQL role that can be used to log in to a database.
-
- There is no distinct "user" entity in CockroachDB. A role with the [`LOGIN`](#parameters) option enabled can log in to the SQL shell and is often called a user.
-
- You can [assign privileges](authorization.html#assign-privileges) to the user and [set it as a member](grant-roles.html) of other roles, inheriting their privileges.
-
-{{site.data.alerts.callout_info}}
- `CREATE USER` is equivalent to the statement `CREATE ROLE`, with one exception: `CREATE ROLE` sets the [`NOLOGIN`](#parameters) option by default, preventing the new role from being used to log in to the database. You can use `CREATE ROLE` and specify the [`LOGIN`](#parameters) option to achieve the same result as `CREATE USER`.
-{{site.data.alerts.end}}
-
-See [Authorization](authorization.html) for more information on privilege management and role membership.
-
-## Considerations
-
-{% include {{ page.version.version }}/sql/role-considerations.md %}
-
-## Required privileges
-
-Unless a role is a member of the admin role, additional [privileges](#parameters) are required to manage other roles.
-
-- To create other roles, a role must have the [`CREATEROLE`](#create-a-user-that-can-create-other-users-and-manage-authentication-methods-for-the-new-users) parameter set.
-- To add the `LOGIN` capability for other roles so that they may log in as users, a role must also have the [`CREATELOGIN`](#create-a-user-that-can-create-other-users-and-manage-authentication-methods-for-the-new-users) parameter set.
-- To be able to grant or revoke membership to a role for additional roles, a member of the role must be set as a [role admin](authorization.html#role-admin) for that role.
-
-## Synopsis
-
-<section>{% include {{ page.version.version }}/sql/diagrams/create_user.html %}</section>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
- Parameter | Description
------------|-------------
-`user_name` | The name of the user you want to create. See the [Considerations](#considerations) section for important naming guidelines.
-`CREATELOGIN`/`NOCREATELOGIN` | Allow or disallow the user to manage authentication using the `WITH PASSWORD`, `VALID UNTIL`, and `LOGIN/NOLOGIN` parameters. <br><br>By default, the parameter is set to `NOCREATELOGIN` for all non-admin users.
-`LOGIN`/`NOLOGIN` | The `LOGIN` parameter allows a user to login with one of the [client authentication methods](authentication.html#client-authentication). Setting the parameter to `NOLOGIN` prevents the user from logging in using any authentication method.
-`password` | Let the user [authenticate their access to a secure cluster](authentication.html#client-authentication) using this password. Passwords should be entered as a [string literal](sql-constants.html#string-literals). For compatibility with PostgreSQL, a password can also be entered as an identifier. <br><br>To prevent a user from using [password authentication](authentication.html#client-authentication) and to mandate [certificate-based client authentication](authentication.html#client-authentication), [set the password as `NULL`](#prevent-a-user-from-using-password-authentication).
-`VALID UNTIL` |  The date and time (in the [`timestamp`](timestamp.html) format) after which the password is not valid.
-`CREATEROLE`/`NOCREATEROLE` |  Allow or disallow the new user to create, [alter](alter-user.html), and [drop](drop-user.html) other non-admin users. <br><br>By default, the parameter is set to `NOCREATEROLE` for all non-admin users.
-`CREATEDB`/`NOCREATEDB` | Allow or disallow the user to [create](create-database.html) or [rename](rename-database.html) a database. The user is assigned as the owner of the database. <br><br>By default, the parameter is set to `NOCREATEDB` for all non-admin users.
-`CONTROLJOB`/`NOCONTROLJOB` | Allow or disallow the user to [pause](pause-job.html), [resume](resume-job.html), and [cancel](cancel-job.html) jobs. Non-admin users cannot control jobs created by admins. <br><br>By default, the parameter is set to `NOCONTROLJOB` for all non-admin users.
-`CANCELQUERY`/`NOCANCELQUERY` | Allow or disallow the user to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) of other users. Without this privilege, users can only cancel their own queries and sessions. Even with this privilege, non-admins cannot cancel admin queries or sessions. This option should usually be combined with `VIEWACTIVITY` so that the user can view other users' query and session information. <br><br>By default, the parameter is set to `NOCANCELQUERY` for all non-admin users.
-`VIEWACTIVITY`/`NOVIEWACTIVITY` | Allow or disallow a role to see other users' [queries](show-queries.html) and [sessions](show-sessions.html) using `SHOW QUERIES`, `SHOW SESSIONS`, and the [**Statements**](ui-statements-page.html) and **Transactions** pages in the DB Console. Without this privilege, the `SHOW` commands only show the user's own data and the DB Console pages are unavailable. <br><br>By default, the parameter is set to `NOVIEWACTIVITY` for all non-admin users.
-`CONTROLCHANGEFEED`/`NOCONTROLCHANGEFEED` | Allow or disallow the user to run [`CREATE CHANGEFEED`](create-changefeed.html) on tables they have `SELECT` privileges on. <br><br>By default, the parameter is set to `NOCONTROLCHANGEFEED` for all non-admin users.
-`MODIFYCLUSTERSETTING`/`NOMODIFYCLUSTERSETTING` | Allow or disallow the user to modify the [cluster settings](cluster-settings.html) with the `sql.defaults` prefix. <br><br>By default, the parameter is set to `NOMODIFYCLUSTERSETTING` for all non-admin users.
-
-## Examples
-
-To run the following examples, [start a secure single-node cluster](cockroach-start-single-node.html) and use the built-in SQL shell:
-
-~~~ shell
-$ cockroach sql --certs-dir=certs
-~~~
-
-~~~ sql
-> SHOW USERS;
-~~~
-
-~~~
-username | options | member_of
----------+---------+------------
-admin    |         | {}
-root     |         | {admin}
-(2 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-The following statements are run by the `root` user that is a member of the `admin` role and has `ALL` privileges.
-{{site.data.alerts.end}}
-
-### Create a user
-
-Note the [considerations](#considerations) for role names.
-
-~~~ sql
-root@:26257/defaultdb> CREATE USER no_options;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
- username  | options | member_of
--------------+---------+------------
-admin      |         | {}
-no_options |         | {}
-root       |         | {admin}
-(3 rows)
-~~~
-
-After creating users, you must:
-
-- [Grant them privileges to databases](grant.html).
-- For secure clusters, you must also [create their client certificates](cockroach-cert.html#create-the-certificate-and-key-pair-for-a-client).
-
-### Create a user with a password
-
-~~~ sql
-root@:26257/defaultdb> CREATE USER with_password WITH LOGIN PASSWORD '$tr0nGpassW0rD' VALID UNTIL '2021-10-10';
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
-  username    |                options                | member_of
---------------+---------------------------------------+------------
-admin         |                                       | {}
-no_options    |                                       | {}
-root          |                                       | {admin}
-with_password | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-(4 rows)
-~~~
-
-### Prevent a user from using password authentication
-
-The following statement prevents the user from using password authentication and mandates certificate-based client authentication:
-
-{% include copy-clipboard.html %}
-~~~ sql
-root@:26257/defaultdb> CREATE USER no_password WITH PASSWORD NULL;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
-  username    |                options                | member_of
---------------+---------------------------------------+------------
-admin         |                                       | {}
-no_options    |                                       | {}
-no_password   |                                       | {}
-root          |                                       | {admin}
-with_password | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-(5 rows)
-~~~
-
-### Create a user that can create other users and manage authentication methods for the new users
-
-The following example allows the user to [create other users](create-user.html) and [manage authentication methods](authentication.html#client-authentication) for them:
-
-~~~ sql
-root@:26257/defaultdb> CREATE USER can_create_users WITH CREATEROLE CREATELOGIN;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
-    username     |                options                | member_of
------------------+---------------------------------------+------------
-admin            |                                       | {}
-can_create_users | CREATELOGIN, CREATEROLE               | {}
-no_options       |                                       | {}
-no_password      |                                       | {}
-root             |                                       | {admin}
-with_password    | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-(6 rows)
-~~~
-
-### Create a user that can create and rename databases
-
-The following example allows the user to [create](create-database.html) or [rename](rename-database.html) databases:
-
-~~~ sql
-root@:26257/defaultdb> CREATE USER can_create_db WITH CREATEDB;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
-      username        |                options                | member_of
-----------------------+---------------------------------------+------------
-admin                 |                                       | {}
-can_create_db         | CREATEDB                              | {}
-can_create_users      | CREATELOGIN, CREATEROLE               | {}
-no_options            |                                       | {}
-no_password           |                                       | {}
-root                  |                                       | {admin}
-with_password         | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-(7 rows)
-~~~
-
-### Create a user that can pause, resume, and cancel non-admin jobs
-
-The following example allows the user to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) for other non-admin roles:
-
-The following example allows the user to [pause](pause-job.html), [resume](resume-job.html), and [cancel](cancel-job.html) jobs:
-
-~~~ sql
-root@:26257/defaultdb> CREATE USER can_control_job WITH CONTROLJOB;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
-      username        |                options                | member_of
-----------------------+---------------------------------------+------------
-admin                 |                                       | {}
-can_control_job       | CONTROLJOB                            | {}
-can_create_db         | CREATEDB                              | {}
-can_create_users      | CREATELOGIN, CREATEROLE               | {}
-no_options            |                                       | {}
-no_password           |                                       | {}
-root                  |                                       | {admin}
-with_password         | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-(8 rows)
-~~~
-
-### Create a user that can see and cancel non-admin queries and sessions
-
-The following example allows the user to cancel [queries](cancel-query.html) and [sessions](cancel-session.html) for other non-admin roles:
-
-~~~ sql
-root@:26257/defaultdb> CREATE USER can_manage_queries WITH CANCELQUERY VIEWACTIVITY;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
-      username        |                options                | member_of
-----------------------+---------------------------------------+------------
-admin                 |                                       | {}
-can_control_job       | CONTROLJOB                            | {}
-can_create_db         | CREATEDB                              | {}
-can_create_users      | CREATELOGIN, CREATEROLE               | {}
-can_manage_queries    | CANCELQUERY, VIEWACTIVITY             | {}
-no_options            |                                       | {}
-no_password           |                                       | {}
-root                  |                                       | {admin}
-with_password         | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-(9 rows)
-~~~
-
-### Create a user that can control changefeeds
-
-The following example allows the user to run [`CREATE CHANGEFEED`](create-changefeed.html):
-
-~~~ sql
-root@:26257/defaultdb> CREATE USER can_control_changefeed WITH CONTROLCHANGEFEED;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
-       username        |                options                | member_of
------------------------+---------------------------------------+------------
-admin                  |                                       | {}
-can_control_changefeed | CONTROLCHANGEFEED                     | {}
-can_control_job        | CONTROLJOB                            | {}
-can_create_db          | CREATEDB                              | {}
-can_create_users       | CREATELOGIN, CREATEROLE               | {}
-can_manage_queries     | CANCELQUERY, VIEWACTIVITY             | {}
-no_options             |                                       | {}
-no_password            |                                       | {}
-root                   |                                       | {admin}
-with_password          | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-(10 rows)
-~~~
-
-### Create a user that can modify cluster settings
-
-The following example allows the user to modify [cluster settings](cluster-settings.html):
-
-~~~ sql
-root@:26257/defaultdb> CREATE USER can_modify_cluster_setting WITH MODIFYCLUSTERSETTING;
-~~~
-
-~~~ sql
-root@:26257/defaultdb> SHOW USERS;
-~~~
-
-~~~
-         username          |                options                | member_of
----------------------------+---------------------------------------+------------
-admin                      |                                       | {}
-can_control_changefeed     | CONTROLCHANGEFEED                     | {}
-can_control_job            | CONTROLJOB                            | {}
-can_create_db              | CREATEDB                              | {}
-can_create_users           | CREATELOGIN, CREATEROLE               | {}
-can_manage_queries         | CANCELQUERY, VIEWACTIVITY             | {}
-can_modify_cluster_setting | MODIFYCLUSTERSETTING                  | {}
-no_options                 |                                       | {}
-no_password                |                                       | {}
-root                       |                                       | {admin}
-with_password              | VALID UNTIL=2021-10-10 00:00:00+00:00 | {}
-(11 rows)
-~~~
-
-## See also
-
-- [Authorization](authorization.html)
-- [`ALTER USER`](alter-user.html)
-- [`DROP USER`](drop-user.html)
-- [`SHOW USERS`](show-users.html)
-- [`GRANT`](grant.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [Create Security Certificates](cockroach-cert.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/create-view.md b/src/current/v20.2/create-view.md
deleted file mode 100644
index 1d1c232d008..00000000000
--- a/src/current/v20.2/create-view.md
+++ /dev/null
@@ -1,154 +0,0 @@
----
-title: CREATE VIEW
-summary: The CREATE VIEW statement creates a view of a table
-toc: true
----
-
-The `CREATE VIEW` statement creates a new [view](views.html), which is a stored query represented as a virtual table.
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> By default, views created in a database cannot reference objects in a different database. To enable cross-database references for views, set the `sql.cross_db_views.enabled` [cluster setting](cluster-settings.html) to `true`.
-{{site.data.alerts.end}}
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the parent database and the `SELECT` privilege on any table(s) referenced by the view.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/create_view.html %}</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`MATERIALIZED` | <span class="version-tag">New in v20.2:</span> Create a [materialized view](views.html#materialized-views).
-`IF NOT EXISTS` |  Create a new view only if a view of the same name does not already exist. If one does exist, do not return an error.<br><br>Note that `IF NOT EXISTS` checks the view name only. It does not check if an existing view has the same columns as the new view.
-`OR REPLACE`  |  <span class="version-tag">New in v20.2:</span> Create a new view if a view of the same name does not already exist. If a view of the same name already exists, replace that view.<br><br>In order to replace an existing view, the new view must have the same columns as the existing view, or more. If the new view has additional columns, the old columns must be a prefix of the new columns. For example, if the existing view has columns `a, b`, the new view can have an additional column `c`, but must have columns `a, b` as a prefix. In this case, `CREATE OR REPLACE VIEW myview (a, b, c)` would be allowed, but `CREATE OR REPLACE VIEW myview (b, a, c)` would not.
-`view_name` | The name of the view to create, which must be unique within its database and follow these [identifier rules](keywords-and-identifiers.html#identifiers). When the parent database is not set as the default, the name must be formatted as `database.name`.
-`name_list` | An optional, comma-separated list of column names for the view. If specified, these names will be used in the response instead of the columns specified in `AS select_stmt`.
-`AS select_stmt` | The [selection query](selection-queries.html) to execute when the view is requested.<br><br>Note that it is not currently possible to use `*` to select all columns from a referenced table or view; instead, you must specify specific columns.
-`opt_temp` |  Defines the view as a session-scoped temporary view. For more information, see [Temporary Views](views.html#temporary-views).<br><br>**Support for temporary views is [experimental](experimental-features.html#temporary-objects)**.
-
-## Example
-
-{{site.data.alerts.callout_success}}
-This example highlights one key benefit to using views: simplifying complex queries. For additional benefits and examples, see [Views](views.html).
-{{site.data.alerts.end}}
-
-### Setup
-
-The following examples use the [`startrek` demo database schema](cockroach-demo.html#datasets).
-
-To follow along, run [`cockroach demo startrek`](cockroach-demo.html) to start a temporary, in-memory cluster with the `startrek` schema and dataset preloaded:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo startrek
-~~~
-
-### Create a view
-
-The sample `startrek` database contains two tables, `episodes` and `quotes`. The table also contains a foreign key constraint, between the `episodes.id` column and the `quotes.episode` column. To count the number of famous quotes per season, you could run the following join:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT startrek.episodes.season, count(*)
-  FROM startrek.quotes
-  JOIN startrek.episodes
-  ON startrek.quotes.episode = startrek.episodes.id
-  GROUP BY startrek.episodes.season;
-~~~
-
-~~~
-  season | count
----------+--------
-       1 |    78
-       2 |    76
-       3 |    46
-(3 rows)
-~~~
-
-Alternatively, to make it much easier to run this complex query, you could create a view:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE VIEW startrek.quotes_per_season (season, quotes)
-  AS SELECT startrek.episodes.season, count(*)
-  FROM startrek.quotes
-  JOIN startrek.episodes
-  ON startrek.quotes.episode = startrek.episodes.id
-  GROUP BY startrek.episodes.season;
-~~~
-
-The view is then represented as a virtual table alongside other tables in the database:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM startrek;
-~~~
-
-~~~
-  schema_name |    table_name     | type  | estimated_row_count
---------------+-------------------+-------+----------------------
-  public      | episodes          | table |                  79
-  public      | quotes            | table |                 200
-  public      | quotes_per_season | view  |                   3
-(3 rows)
-~~~
-
-Executing the query is as easy as `SELECT`ing from the view, as you would from a standard table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM startrek.quotes_per_season;
-~~~
-
-~~~
-  season | quotes
----------+---------
-       3 |     46
-       1 |     78
-       2 |     76
-(3 rows)
-~~~
-
-### Replace an existing view
-
-<span class="version-tag">New in v20.2:</span> You can create a new view, or replace an existing view, with `CREATE OR REPLACE VIEW`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE OR REPLACE VIEW startrek.quotes_per_season (season, quotes)
-  AS SELECT startrek.episodes.season, count(*)
-  FROM startrek.quotes
-  JOIN startrek.episodes
-  ON startrek.quotes.episode = startrek.episodes.id
-  GROUP BY startrek.episodes.season
-  ORDER BY startrek.episodes.season;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM startrek.quotes_per_season;
-~~~
-
-~~~
-  season | quotes
----------+---------
-       3 |     46
-       1 |     78
-       2 |     76
-(3 rows)
-~~~
-
-## See also
-
-- [Selection Queries](selection-queries.html)
-- [Views](views.html)
-- [`SHOW CREATE`](show-create.html)
-- [`ALTER VIEW`](alter-view.html)
-- [`DROP VIEW`](drop-view.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/data-types.md b/src/current/v20.2/data-types.md
deleted file mode 100644
index ab868f199a7..00000000000
--- a/src/current/v20.2/data-types.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-title: Data Types
-summary: Learn about the data types supported by CockroachDB.
-toc: true
----
-
-## Supported types
-
-CockroachDB supports the following data types. Click a type for more details.
-
-Type | Description | Example
------|-------------|---------
-[`ARRAY`](array.html) | A 1-dimensional, 1-indexed, homogeneous array of any non-array data type. | `{"sky","road","car"}`
-[`BIT`](bit.html) | A string of binary digits (bits).  | `B'10010101'`
-[`BOOL`](bool.html) | A Boolean value. | `true`
-[`BYTES`](bytes.html) | A string of binary characters. | `b'\141\061\142\062\143\063'`
-[`COLLATE`](collate.html) | The `COLLATE` feature lets you sort [`STRING`](string.html) values according to language- and country-specific rules, known as collations.  | `'a1b2c3' COLLATE en`
-[`DATE`](date.html) | A date.  | `DATE '2016-01-25'`
-[`ENUM`](enum.html) | <span class="version-tag">New in v20.2:</span> A user-defined data type comprised of a set of static values. | `ENUM ('club, 'diamond', 'heart', 'spade')`
-[`DECIMAL`](decimal.html) | An exact, fixed-point number.  | `1.2345`
-[`FLOAT`](float.html) | A 64-bit, inexact, floating-point number.  | `1.2345`
-[`INET`](inet.html) | An IPv4 or IPv6 address.  | `192.168.0.1`
-[`INT`](int.html) | A signed integer, up to 64 bits. | `12345`
-[`INTERVAL`](interval.html) | A span of time.  | `INTERVAL '2h30m30s'`
-[`JSONB`](jsonb.html) | JSON (JavaScript Object Notation) data.  | `'{"first_name": "Lola", "last_name": "Dog", "location": "NYC", "online" : true, "friends" : 547}'`
-[`SERIAL`](serial.html) | A pseudo-type that combines an [integer type](int.html) with a [`DEFAULT` expression](default-value.html).  | `148591304110702593`
-[`STRING`](string.html) | A string of Unicode characters. | `'a1b2c3'`
-[`TIME`<br>`TIMETZ`](time.html) | `TIME` stores a time of day in UTC.<br> `TIMETZ` converts `TIME` values with a specified time zone offset from UTC. | `TIME '01:23:45.123456'`<br> `TIMETZ '01:23:45.123456-5:00'`
-[`TIMESTAMP`<br>`TIMESTAMPTZ`](timestamp.html) | `TIMESTAMP` stores a date and time pairing in UTC.<br>`TIMESTAMPTZ` converts `TIMESTAMP` values with a specified time zone offset from UTC. | `TIMESTAMP '2016-01-25 10:10:10'`<br>`TIMESTAMPTZ '2016-01-25 10:10:10-05:00'`
-[`UUID`](uuid.html) | A 128-bit hexadecimal value. | `7f9c24e8-3b12-4fef-91e0-56a2d5a246ec`
-
-## Data type conversions and casts
-
-CockroachDB supports explicit type conversions using the following methods:
-
-- `<type> 'string literal'`, to convert from the literal representation of a value to a value of that type. For example:
-  `DATE '2008-12-21'`, `INT '123'`, or `BOOL 'true'`.
-
-- `<value>::<data type>`, or its equivalent longer form `CAST(<value> AS <data type>)`, which converts an arbitrary expression of one built-in type to another (this is also known as type coercion or "casting"). For example:
-  `NOW()::DECIMAL`, `VARIANCE(a+2)::INT`.
-
-    {{site.data.alerts.callout_success}}
-    To create constant values, consider using a
-    <a href="scalar-expressions.html#explicitly-typed-expressions">type annotation</a>
-    instead of a cast, as it provides more predictable results.
-    {{site.data.alerts.end}}
-
-- Other [built-in conversion functions](functions-and-operators.html) when the type is not a SQL type, for example `from_ip()`, `to_ip()` to convert IP addresses between `STRING` and `BYTES` values.
-
-CockroachDB also supports implicit casting from string literals to arrays of all data types except the following:
-
-  - [`BYTES`](bytes.html)
-  - [`ENUM`](enum.html)
-  - [`JSONB`](jsonb.html)
-  - [`SERIAL`](serial.html)
-  - `Box2D` [(spatial type)](spatial-glossary.html#data-types)
-  - `GEOGRAPHY` [(spatial type)](spatial-glossary.html#data-types)
-  - `GEOMETRY` [(spatial type)](spatial-glossary.html#data-types)
-
-For an example, see [Implicit casting to `ARRAY`s](array.html#implicit-casting).
-
-You can find each data type's supported conversion and casting on its
-respective page in its section **Supported casting & conversion**.
diff --git a/src/current/v20.2/date.md b/src/current/v20.2/date.md
deleted file mode 100644
index cdd6122faf8..00000000000
--- a/src/current/v20.2/date.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: DATE
-summary: CockroachDB's DATE data type stores a year, month, and day.
-toc: true
----
-
-The `DATE` [data type](data-types.html) stores a year, month, and day.
-
-## Syntax
-
-A constant value of type `DATE` can be expressed using an
-[interpreted literal](sql-constants.html#interpreted-literals), or a
-string literal
-[annotated with](scalar-expressions.html#explicitly-typed-expressions)
-type `DATE` or
-[coerced to](scalar-expressions.html#explicit-type-coercions) type
-`DATE`.
-
-The string format for dates is `YYYY-MM-DD`. For example: `DATE '2016-12-23'`.
-
-CockroachDB also supports using uninterpreted
-[string literals](sql-constants.html#string-literals) in contexts
-where a `DATE` value is otherwise expected.
-
-{{site.data.alerts.callout_info}}
-`DATE` values in CockroachDB are fully [PostgreSQL-compatible](https://www.postgresql.org/docs/current/datatype-datetime.html), including support for special values (e.g., `+/- infinity`). Existing dates outside of the PostgreSQL date range (`4714-11-24 BC` to `5874897-12-31`) are converted to `+/- infinity` dates.
-{{site.data.alerts.end}}
-
-## Size
-
-A `DATE` column supports values up to 16 bytes in width, but the total storage size is likely to be larger due to CockroachDB metadata.
-
-## Examples
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE dates (a DATE PRIMARY KEY, b INT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM dates;
-~~~
-
-~~~
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-| column_name | data_type | is_nullable | column_default | generation_expression |   indices   |
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-| a           | DATE      |    false    | NULL           |                       | {"primary"} |
-| b           | INT       |    true     | NULL           |                       | {}          |
-+-------------+-----------+-------------+----------------+-----------------------+-------------+
-(2 rows)
-~~~
-
-Explicitly typed `DATE` literal:
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO dates VALUES (DATE '2016-03-26', 12345);
-~~~
-
-String literal implicitly typed as `DATE`:
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO dates VALUES ('2016-03-27', 12345);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM dates;
-~~~
-
-~~~
-+---------------------------+-------+
-|             a             |   b   |
-+---------------------------+-------+
-| 2016-03-26 00:00:00+00:00 | 12345 |
-| 2016-03-27 00:00:00+00:00 | 12345 |
-+---------------------------+-------+
-~~~
-
-## Supported casting and conversion
-
-`DATE` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`DECIMAL` | Converts to number of days since the Unix epoch (Jan. 1, 1970).
-`FLOAT` | Converts to number of days since the Unix epoch (Jan. 1, 1970).
-`TIMESTAMP` | Sets the time to 00:00 (midnight) in the resulting timestamp.
-`INT` | Converts to number of days since the Unix epoch (Jan. 1, 1970).
-`STRING` | ––
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/dbeaver.md b/src/current/v20.2/dbeaver.md
deleted file mode 100644
index cee6f7b2f7d..00000000000
--- a/src/current/v20.2/dbeaver.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: Visualize CockroachDB Schemas with DBeaver
-summary: The DBeaver database tool completely integrates with CockroachDB to provide a GUI for managing your database.
-toc: true
----
-
-The [DBeaver database tool][dbeaver] is a tool that completely integrates with CockroachDB to provide a GUI for managing your database.
-
-According to the [DBeaver website][dbeaver]:
-
-> DBeaver is a cross-platform Database GUI tool for developers, SQL programmers, database administrators, and analysts.
-
-In this tutorial, you'll work through the process of using DBeaver with a secure CockroachDB cluster.
-
-{{site.data.alerts.callout_success}}
-For more information about using DBeaver, see the [DBeaver documentation](https://dbeaver.io/docs/).
-
-If you run into problems, please file an issue on the [DBeaver issue tracker](https://github.com/dbeaver/dbeaver/issues).
-
-For information on using DBeaver with CockroachDB {{ site.data.products.cloud }}, see [this blog post](https://paul-logston.medium.com/setting-up-a-sql-gui-with-cockroachdb-a9fd5fe15d9d).
-{{site.data.alerts.end}}
-
-## Before You Begin
-
-To work through this tutorial, take the following steps:
-
-- [Install CockroachDB](install-cockroachdb.html) and [start a secure cluster](secure-a-cluster.html).
-- Download a copy of [DBeaver](https://dbeaver.io/download/) version 5.2.3 or greater.
-
-## Step 1. Start DBeaver and connect to CockroachDB
-
-Start DBeaver, and select **Database > New Connection** from the menu.  In the dialog that appears, select **CockroachDB** from the list.
-
-<img src="{{ 'images/v2.1/dbeaver-01-select-cockroachdb.png' | relative_url }}" alt="DBeaver - Select CockroachDB" style="border:1px solid #eee;max-width:100%" />
-
-## Step 2. Update the connection settings
-
-On the **Create new connection** dialog that appears, click **Network settings**.
-
-<img src="{{ 'images/v2.1/dbeaver-02-cockroachdb-connection-settings.png' | relative_url }}" alt="DBeaver - CockroachDB connection settings" style="border:1px solid #eee;max-width:100%" />
-
-From the network settings, click the **SSL** tab.  It will look like the screenshot below.
-
-<img src="{{ 'images/v2.1/dbeaver-03-ssl-tab.png' | relative_url }}" alt="DBeaver - SSL tab" style="border:1px solid #eee;max-width:100%" />
-
-Check the **Use SSL** checkbox as shown, and fill in the text areas as follows:
-
-- **Root certificate**: Use the `ca.crt` file you generated for your secure cluster.
-- **SSL certificate**: Use a client certificate generated from your cluster's root certificate.  For the root user, this will be named `client.root.crt`.  For additional security, you may want to create a new database user and client certificate just for use with DBeaver.
-- **SSL certificate key**: Because DBeaver is a Java application, you will need to transform your key file to the `*.pk8` format using an [OpenSSL command](https://wiki.openssl.org/index.php/Command_Line_Utilities#pkcs8_.2F_pkcs5) like the one shown below.  Once you have created the file, enter its location here.  In this example, the filename is `client.root.pk8`.
-    {% include copy-clipboard.html %}
-    ~~~ console
-    $ openssl pkcs8 -topk8 -inform PEM -outform DER -in client.root.key -out client.root.pk8 -nocrypt
-    ~~~
-
-Select **require** from the **SSL mode** dropdown.  There is no need to set the **SSL Factory**, you can let DBeaver use the default.
-
-## Step 3. Test the connection settings
-
-Click **Test Connection ...**.  If everything worked, you will see a **Success** dialog like the one shown below.
-
-<img src="{{ 'images/v2.1/dbeaver-04-connection-success-dialog.png' | relative_url }}" alt="DBeaver - connection success dialog" style="border:1px solid #eee;max-width:100%" />
-
-## Step 4. Start using DBeaver
-
-Click **Finish** to get started using DBeaver with CockroachDB.
-
-<img src="{{ 'images/v2.1/dbeaver-05-movr.png' | relative_url }}" alt="DBeaver - CockroachDB with the movr database" style="max-width:100%" />
-
-For more information about using DBeaver, see the [DBeaver documentation](https://dbeaver.io/docs/).
-
-## Report Issues with DBeaver & CockroachDB
-
-If you run into problems, please file an issue on the [DBeaver issue tracker](https://github.com/dbeaver/dbeaver/issues), including the following details about the environment where you encountered the issue:
-
-- CockroachDB version ([`cockroach version`](cockroach-version.html))
-- DBeaver version
-- Operating system
-- Steps to reproduce the behavior
-- If possible, a trace of the SQL statements sent to CockroachDB while the error is being reproduced using [SQL query logging](query-behavior-troubleshooting.html#sql-logging).
-
-## See Also
-
-+ [DBeaver documentation](https://dbeaver.io/docs/)
-+ [DBeaver issue tracker](https://github.com/dbeaver/dbeaver/issues)
-+ [Client connection parameters](connection-parameters.html)
-+ [Third-Party Database Tools](third-party-database-tools.html)
-+ [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
-
-<!-- Reference Links -->
-
-[dbeaver]: https://dbeaver.io
diff --git a/src/current/v20.2/debug-and-error-logs.md b/src/current/v20.2/debug-and-error-logs.md
deleted file mode 100644
index 888542e02e5..00000000000
--- a/src/current/v20.2/debug-and-error-logs.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Understand Debug & Error Logs
-summary: CockroachDB logs include details about certain node-level and range-level events, such as errors.
-toc: true
----
-
-If you need to [troubleshoot](troubleshooting-overview.html) issues with your cluster, you can check a node's logs, which include details about certain node-level and range-level events, such as errors. For example, if CockroachDB crashes, it normally logs a stack trace to what caused the problem.
-
-{{site.data.alerts.callout_success}}
-CockroachDB also generates secondary logs for queries being executed against your system. See [SQL logging](query-behavior-troubleshooting.html#sql-logging) for details on obtaining these logs.
-{{site.data.alerts.end}}
-
-
-## Details
-
-When a node processes a [`cockroach` command](cockroach-commands.html), it produces a stream of messages about the command's activities. Each message's body describes the activity, and its envelope contains metadata such as the message's severity level.
-
-As a command generates messages, CockroachDB uses the [command](#commands)'s [logging flags](#flags) and the message's [severity level](#severity-levels) to determine the appropriate [location](#output-locations) for it.
-
-Each node's logs detail only the internal activity of that node without visibility into the behavior of other nodes in the cluster. When troubleshooting, this means that you must identify the node where the problem occurred or [collect the logs from all active nodes in your cluster](cockroach-debug-zip.html).
-
-### Commands
-
-All [`cockroach` commands](cockroach-commands.html) support logging. However, it's important to note:
-
-- `cockroach start` generates most messages related to the operation of your cluster.
-- Other commands do generate messages, but they're typically only interesting in troubleshooting scenarios.
-
-### Severity levels
-
-CockroachDB identifies each message with a severity level, letting operators know if they need to intercede:
-
-1. `INFO` *(lowest severity; no action necessary)*
-2. `WARNING`
-3. `ERROR`
-4. `FATAL` *(highest severity; requires operator attention)*
-
-**Default behavior by severity level**
-
-Command | `INFO` messages | `WARNING` and above messages
---------|--------|--------------------
-[`cockroach start`](cockroach-start.html) | Write to file | Write to file
-[All other commands](cockroach-commands.html) | Discard | Print to `stderr`
-
-### Output locations
-
-Based on the command's flags and the message's [severity level](#severity-levels), CockroachDB does one of the following:
-
-- [Writes the message to a file](#write-to-file)
-- [Prints it to `stderr`](#print-to-stderr)
-- [Discards the message entirely](#discard-message)
-
-#### Write to file
-
-CockroachDB can write messages to log files. The files are named using the following format:
-
-~~~
-cockroach.[host].[user].[start timestamp in UTC].[process ID].log
-~~~
-
-For example:
-
-~~~
-cockroach.richards-mbp.rloveland.2018-03-15T15_24_10Z.024338.log
-~~~
-
-To make it easier to watch a log without knowing the full filename, a [symlink](https://en.wikipedia.org/wiki/Symbolic_link) with the short filename `cockroach.log` is also created. This symlink points to the most recent log.
-
-{{site.data.alerts.callout_info}}
-All log file timestamps are in UTC because CockroachDB is designed to be deployed in a distributed cluster.  Nodes may be located in different time zones, and using UTC makes it easy to correlate log messages from those nodes no matter where they are located.
-{{site.data.alerts.end}}
-
-Property | `cockroach start` | All other commands
----------|-------------------|-------------------
-Enabled by | Default<sup>1</sup> | Explicit `--log-dir` flag
-Default File Destination | `[first `[`store`](cockroach-start.html#store)` dir]/logs` | *N/A*
-Change File Destination | `--log-dir=[destination]` | `--log-dir=[destination]`
-Default Severity Level Threshold | `INFO` | *N/A*
-Change Severity Threshold | `--log-file-verbosity=[severity level]` | `--log-file-verbosity=[severity level]`
-Disabled by | `--log-dir=`<sup>1</sup> | Default
-
-{{site.data.alerts.callout_info}}
-<sup>1</sup> If the `cockroach` process does not have access to on-disk storage, `cockroach start` does not write messages to log files; instead it prints all messages to `stderr`.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-{% include {{ page.version.version }}/ui/ui-log-files.md %}
-{{site.data.alerts.end}}
-
-#### Print to `stderr`
-
-CockroachDB can print messages to `stderr`, which normally prints them to the machine's terminal but does not store them.
-
-Property | `cockroach start` | All other commands
----------|-------------------|-------------------
-Enabled by | Explicit `--logtostderr` flag<sup>2</sup> | Default
-Default Severity Level Threshold | *N/A* | `WARNING`
-Change Severity Threshold | `--logtostderr=[severity level]` | `--logtostderr=[severity level]`
-Disabled by | Default<sup>2</sup> | `--logtostderr=NONE`
-
-{{site.data.alerts.callout_info}}<sup>2</sup> <code>cockroach start</code> does not print any messages to <code>stderr</code> unless the <code>cockroach</code> process does not have access to on-disk storage, in which case it defaults to <code>--logtostderr=INFO</code> and prints all messages to <code>stderr</code>.{{site.data.alerts.end}}
-
-#### Discard message
-
-Messages with severity levels below the `--logtostderr` and `--log-file-verbosity` flag's values are neither written to files nor printed to `stderr`, so they are discarded.
-
-By default, commands besides `cockroach start` discard messages with the `INFO` [severity level](#severity-levels).
-
-## Flags
-
-These logging flags are used with [`cockroach` commands](cockroach-commands.html).
-
-{% include {{ page.version.version }}/misc/logging-flags.md %}
-
-## Redacted logs
-
-If you contact CockroachDB Support for troubleshooting help, you might be asked to run [`cockroach debug zip`](cockroach-debug-zip.html) and share the resulting file with the CockroachDB team. The log files created by `cockroach debug zip` may contain highly sensitive, identifiable information, such as usernames, hashed passwords, and possibly your table's data.
-
-<span class="version-tag">New in v20.2</span> You can run `cockroach debug zip` with the [`redact-logs` flag](cockroach-debug-zip.html#redact-sensitive-information-from-the-logs) to redact the sensitive data out of log files and crash reports before sharing them with Cockroach Labs. Redactable sensitive data includes but is not limited to:
-
-- Stored values
-- Text of SQL statements, especially the values embedded therein
-- Result rows
-- The dynamic part of error messages that includes application-provided parameters.
-- IP addresses or hostnames
-- Database, schema, table, or column names
-- Cluster IDs
-- File names of stored data or log files
-- User/role names
-- Hashed passwords
-
-## See also
-
-- [SQL logging](query-behavior-troubleshooting.html#sql-logging)
-- [Troubleshooting Overview](troubleshooting-overview.html)
-- [Support Resources](support-resources.html)
diff --git a/src/current/v20.2/decimal.md b/src/current/v20.2/decimal.md
deleted file mode 100644
index ee22f97c576..00000000000
--- a/src/current/v20.2/decimal.md
+++ /dev/null
@@ -1,110 +0,0 @@
----
-title: DECIMAL
-summary: The DECIMAL data type stores exact, fixed-point numbers.
-toc: true
----
-
-The `DECIMAL` [data type](data-types.html) stores exact, fixed-point numbers. This type is used when it is important to preserve exact precision, for example, with monetary data.
-
-## Aliases
-
-In CockroachDB, the following are aliases for `DECIMAL`:
-
-- `DEC`
-- `NUMERIC`
-
-## Precision and scale
-
-To limit a decimal column, use `DECIMAL(precision, scale)`, where `precision` is the **maximum** count of digits both to the left and right of the decimal point and `scale` is the **exact** count of digits to the right of the decimal point. The `precision` must not be smaller than the `scale`. Also note that using `DECIMAL(precision)` is equivalent to `DECIMAL(precision, 0)`.
-
-When inserting a decimal value:
-
-- If digits to the right of the decimal point exceed the column's `scale`, CockroachDB rounds to the scale.
-- If digits to the right of the decimal point are fewer than the column's `scale`, CockroachDB pads to the scale with `0`s.
-- If digits to the left and right of the decimal point exceed the column's `precision`, CockroachDB gives an error.  
-- If the column's `precision` and `scale` are identical, the inserted value must round to less than 1.
-
-## Syntax
-
-A constant value of type `DECIMAL` can be entered as a [numeric literal](sql-constants.html#numeric-literals).
-For example: `1.414` or `-1234`.
-
-The special IEEE754 values for positive infinity, negative infinity
-and [NaN (Not-a-Number)](https://en.wikipedia.org/wiki/NaN) cannot be
-entered using numeric literals directly and must be converted using an
-[interpreted literal](sql-constants.html#interpreted-literals) or an
-[explicit conversion](scalar-expressions.html#explicit-type-coercions)
-from a string literal instead.
-
-The following values are recognized:
-
- Syntax                                 | Value                                           
-----------------------------------------|------------------------------------------------
- `inf`, `infinity`, `+inf`, `+infinity` | +&#8734;                                                
- `-inf`, `-infinity`                    | -&#8734;                                                
- `nan`                                  | [NaN (Not-a-Number)](https://en.wikipedia.org/wiki/NaN)
-
-For example:
-
-- `DECIMAL '+Inf'`
-- `'-Inf'::DECIMAL`
-- `CAST('NaN' AS DECIMAL)`
-
-## Size
-
-The size of a `DECIMAL` value is variable, starting at 9 bytes. It's recommended to keep values under 64 kilobytes to ensure performance. Above that threshold, [write amplification](https://en.wikipedia.org/wiki/Write_amplification) and other considerations may cause significant performance degradation.  
-
-## Examples
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE decimals (a DECIMAL PRIMARY KEY, b DECIMAL(10,5), c NUMERIC);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM decimals;
-~~~
-
-~~~
-  column_name |   data_type   | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+---------------+-------------+----------------+-----------------------+-----------+------------
-  a           | DECIMAL       |    false    | NULL           |                       | {primary} |   false
-  b           | DECIMAL(10,5) |    true     | NULL           |                       | {}        |   false
-  c           | DECIMAL       |    true     | NULL           |                       | {}        |   false
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO decimals VALUES (1.01234567890123456789, 1.01234567890123456789, 1.01234567890123456789);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM decimals;
-~~~
-
-~~~
-            a            |    b    |           c
--------------------------+---------+-------------------------
-  1.01234567890123456789 | 1.01235 | 1.01234567890123456789
-(1 row)
-~~~
-
-The value in column `a` matches what was inserted exactly. The value in column `b` has been rounded to the column's scale. The value in column `c` is handled like the value in column `a` because `NUMERIC` is an alias for `DECIMAL`.
-
-## Supported casting and conversion
-
-`DECIMAL` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`INT` | Truncates decimal precision
-`FLOAT` | Loses precision and may round up to +/- infinity if the value is too large in magnitude, or to +/-0 if the value is too small in magnitude
-`BOOL` |  **0** converts to `false`; all other values convert to `true`
-`STRING` | ––
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/default-value.md b/src/current/v20.2/default-value.md
deleted file mode 100644
index 1c47170cb78..00000000000
--- a/src/current/v20.2/default-value.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Default Value Constraint
-summary: The Default Value constraint specifies a value to populate a column with if none is provided.
-toc: true
----
-
-The `DEFAULT` value [constraint](constraints.html) specifies a value to write into the constrained column if one is not defined in an `INSERT` statement. The value may be either a hard-coded literal or an expression that is evaluated at the time the row is created.
-
-
-## Details
-
-- The [data type](data-types.html) of the Default Value must be the same as the data type of the column.
-- The `DEFAULT` value constraint only applies if the column does not have a value specified in the [`INSERT`](insert.html) statement. You can still insert a *NULL* into an optional (nullable) column by explicitly inserting *NULL*. For example, `INSERT INTO foo VALUES (1, NULL);`.
-
-## Syntax
-
-You can only apply the `DEFAULT` value constraint to individual columns.
-
-{{site.data.alerts.callout_info}}
-You can also add the `DEFAULT` value constraint to an existing table through [`ALTER COLUMN`](alter-column.html#set-or-change-a-default-value).
-{{site.data.alerts.end}}
-
-<div>{% include {{ page.version.version }}/sql/diagrams/default_value_column_level.html %}</div>
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table you're creating.
- `column_name` | The name of the constrained column.
- `column_type` | The constrained column's [data type](data-types.html).
- `default_value` | The value you want to insert by default, which must evaluate to the same [data type](data-types.html) as the `column_type`.
- `column_constraints` | Any other column-level [constraints](constraints.html) you want to apply to this column.
- `column_def` | Definitions for any other columns in the table.
- `table_constraints` | Any table-level [constraints](constraints.html) you want to apply.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE inventories (
-    product_id        INT,
-    warehouse_id      INT,
-    quantity_on_hand  INT DEFAULT 100,
-    PRIMARY KEY (product_id, warehouse_id)
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO inventories (product_id, warehouse_id) VALUES (1,20);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO inventories (product_id, warehouse_id, quantity_on_hand) VALUES (2,30, NULL);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM inventories;
-~~~
-~~~
-+------------+--------------+------------------+
-| product_id | warehouse_id | quantity_on_hand |
-+------------+--------------+------------------+
-|          1 |           20 |              100 |
-|          2 |           30 | NULL             |
-+------------+--------------+------------------+
-~~~
-
-If the `DEFAULT` value constraint is not specified and an explicit value is not given, a value of *NULL* is assigned to the column.
-
-## See also
-
-- [Constraints](constraints.html)
-- [`ALTER COLUMN`](alter-column.html)
-- [`CHECK` constraint](check.html)
-- [`REFERENCES` constraint (Foreign Key)](foreign-key.html)
-- [`NOT NULL` constraint](not-null.html)
-- [`PRIMARY KEY` constraint](primary-key.html)
-- [`UNIQUE` constraint](unique.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
diff --git a/src/current/v20.2/delete-data.md b/src/current/v20.2/delete-data.md
deleted file mode 100644
index b527e7526f2..00000000000
--- a/src/current/v20.2/delete-data.md
+++ /dev/null
@@ -1,261 +0,0 @@
----
-title: Delete Data
-summary: How to delete data from CockroachDB during application development
-toc: true
----
-
-This page has instructions for deleting rows of data from CockroachDB, using the [`DELETE`](delete.html) [SQL statement](sql-statements.html).
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Install a Postgres client](install-client-drivers.html).
-- [Connect to the database](connect-to-the-database.html).
-- [Create a database schema](schema-design-overview.html).
-- [Insert data](insert-data.html) that you now want to delete.
-
-    In the examples on this page, we use sample [`movr`](movr.html) data imported with the [`cockroach workload` command](cockroach-workload.html).
-
-## Use `DELETE`
-
-To delete rows in a table, use a [`DELETE` statement](update.html) with a `WHERE` clause that filters on the columns that identify the rows that you want to delete.
-
-### SQL syntax
-
-In SQL, `DELETE` statements generally take the following form:
-
-~~~
-DELETE FROM {table} WHERE {filter_column} {comparison_operator} {filter_value}
-~~~
-
-Where:
-
-- `{table}` is a table with rows that you want to delete.
-- `{filter_column}` is the column to filter on.
-- `{comparison_operator}` is a [comparison operator](functions-and-operators.html#operators) that resolves to `TRUE` or `FALSE` (e.g., `=`).
-- `{filter_value}` is the matching value for the filter.
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `DELETE` statement, including additional examples, see the [`DELETE` syntax page](delete.html).
-{{site.data.alerts.end}}
-
-### Best practices
-
-Here are some best practices to follow when deleting rows:
-
-- Limit the number of `DELETE` statements that you execute. It's more efficient to delete multiple rows with a single statement than to execute multiple `DELETE` statements that each delete a single row.
-- Always specify a `WHERE` clause in `DELETE` queries. If no `WHERE` clause is specified, CockroachDB will delete all of the rows in the specified table.
-- To delete all of the rows in a table, use a [`TRUNCATE` statement](truncate.html) instead of a `DELETE` statement.
-- To delete a large number of rows (i.e., tens of thousands of rows or more), use a [batch-delete loop](bulk-delete-data.html#batch-delete-on-an-indexed-column).
-- When executing `DELETE` statements from an application, make sure that you wrap the SQL-executing functions in [a retry loop that handles transaction errors](error-handling-and-troubleshooting.html#transaction-retry-errors) that can occur under contention.
-- Review the [performance considerations below](#performance-considerations).
-
-### Examples
-
-#### Delete rows filtered on a non-unique column
-
-Suppose that you want to delete the vehicle location history data recorded during a specific hour of a specific day. To delete all of the rows in the `vehicle_location_histories` table where the `timestamp` is between two [`TIMESTAMP`](timestamp.html) values:
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go (lib/pq)</button>
-  <button class="filter-button" data-scope="java">Java (jdbc)</button>
-  <button class="filter-button" data-scope="python">Python (psycopg2)</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ sql
-DELETE FROM vehicle_location_histories WHERE timestamp BETWEEN '2021-03-17 14:00:00' AND '2021-03-17 15:00:00';
-~~~
-
-For more information about how to use the built-in SQL client, see the [`cockroach sql`](cockroach-sql.html) reference docs.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-// 'db' is an open database connection
-
-tsOne := "2021-03-17 14:00:00"
-tsTwo := "2021-03-17 15:00:00"
-
-if _, err := db.Exec("DELETE FROM vehicle_location_histories WHERE timestamp BETWEEN $1 AND $2", tsOne, tsTwo); err != nil {
-  return err
-}
-return nil
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-// ds is an org.postgresql.ds.PGSimpleDataSource
-
-String tsOne = "2021-03-17 14:00:00";
-String tsTwo = "2021-03-17 15:00:00";
-
-try (Connection connection = ds.getConnection()) {
-    PreparedStatement p = connection.prepareStatement("DELETE FROM vehicle_location_histories WHERE timestamp BETWEEN ? AND ?");
-    p.setString(1, tsOne);
-    p.setString(2, tsTwo);
-    p.executeUpdate();
-
-} catch (SQLException e) {
-    System.out.printf("sql state = [%s]\ncause = [%s]\nmessage = [%s]\n", e.getSQLState(), e.getCause(),
-            e.getMessage());
-}
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-# conn is a psycopg2 connection
-
-tsOne = '2021-03-17 14:00:00'
-tsTwo = '2021-03-17 15:00:00'
-
-with conn.cursor() as cur:
-    cur.execute(
-        "DELETE FROM vehicle_location_histories WHERE timestamp BETWEEN %s AND %s", (tsOne, tsTwo))
-~~~
-
-</section>
-
-{{site.data.alerts.callout_success}}
-If the `WHERE` clause evaluates to `TRUE` for a large number of rows (i.e., tens of thousands of rows), use a [batch-delete loop](bulk-delete-data.html#batch-delete-on-an-indexed-column) instead of executing a simple `DELETE` query.
-{{site.data.alerts.end}}
-
-#### Delete rows filtered on a unique column
-
-Suppose that you want to delete the promo code data for a specific set of codes. To delete the rows in the `promo_codes` table where the `code` matches a string in a set of string values:
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go (lib/pq)</button>
-  <button class="filter-button" data-scope="java">Java (jdbc)</button>
-  <button class="filter-button" data-scope="python">Python (psycopg2)</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ sql
-DELETE from promo_codes WHERE code IN ('0_explain_theory_something', '100_address_garden_certain', '1000_do_write_words');
-~~~
-
-For more information about how to use the built-in SQL client, see the [`cockroach sql`](cockroach-sql.html) reference docs.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-// 'db' is an open database connection
-
-codeOne := "0_explain_theory_something"
-codeTwo := "100_address_garden_certain"
-codeThree := "1000_do_write_words"
-
-if _, err := db.Exec("DELETE from promo_codes WHERE code IN ($1, $2, $3)", codeOne, codeTwo, codeThree); err != nil {
-  return err
-}
-return nil
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-// ds is an org.postgresql.ds.PGSimpleDataSource
-
-String codeOne = "0_explain_theory_something";
-String codeTwo = "100_address_garden_certain";
-String codeThree = "1000_do_write_words";
-
-try (Connection connection = ds.getConnection()) {
-    PreparedStatement p = connection.prepareStatement("DELETE from promo_codes WHERE code IN(?, ?, ?)");
-    p.setString(1, codeOne);
-    p.setString(2, codeTwo);
-    p.setString(3, codeThree);
-    p.executeUpdate();
-
-} catch (SQLException e) {
-    System.out.printf("sql state = [%s]\ncause = [%s]\nmessage = [%s]\n", e.getSQLState(), e.getCause(),
-            e.getMessage());
-}
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-# conn is a psycopg2 connection
-
-codeOne = '0_explain_theory_something'
-codeTwo = '100_address_garden_certain'
-codeThree = '1000_do_write_words'
-
-with conn.cursor() as cur:
-    cur.execute("DELETE from promo_codes WHERE code IN (%s, %s, %s)", (codeOne, codeTwo, codeThree)),
-~~~
-
-</section>
-
-## Performance considerations
-
-Because of the way CockroachDB works under the hood, deleting data from the database does not immediately reduce disk usage.  Instead, records are marked as "deleted" and processed asynchronously by a background garbage collection process.  This process runs every 25 hours by default to allow sufficient time for running [backups](take-full-and-incremental-backups.html) and running [time travel queries using `AS OF SYSTEM TIME`](as-of-system-time.html).  The garbage collection interval is controlled by the [`gc.ttlseconds`](configure-replication-zones.html#replication-zone-variables) setting.
-
-The practical implications of the above are:
-
-- Deleting data will not immediately decrease disk usage.
-- If you issue multiple [`DELETE`](delete.html) statements in sequence that each delete large amounts of data, each subsequent `DELETE` statement will run more slowly. For details, see [Preserving `DELETE` performance over time](delete.html#preserving-delete-performance-over-time).
-
-For more information about how the storage layer of CockroachDB works, see the [storage layer reference documentation](architecture/storage-layer.html).
-
-## See also
-
-Reference information related to this task:
-
-- [`DELETE`](delete.html)
-- [Bulk-delete data](bulk-delete-data.html)
-- [Disk space usage after deletes](delete.html#disk-space-usage-after-deletes)
-- [`TRUNCATE`](truncate.html)
-- [`DROP TABLE`](drop-table.html)
-- [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention)
-
-Other common tasks:
-
-- [Connect to the Database](connect-to-the-database.html)
-- [Insert Data](insert-data.html)
-- [Query Data](query-data.html)
-- [Update Data](update-data.html)
-- [Run Multi-Statement Transactions](run-multi-statement-transactions.html)
-- [Error Handling and Troubleshooting](error-handling-and-troubleshooting.html)
-- [Optimize Query Performance][fast]
-- [Hello World Example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[selection]: selection-queries.html
-[manual]: manual-deployment.html
-[orchestrated]: orchestration.html
-[fast]: make-queries-fast.html
-[paginate]: pagination.html
-[joins]: joins.html
diff --git a/src/current/v20.2/delete.md b/src/current/v20.2/delete.md
deleted file mode 100644
index 4318bdd453c..00000000000
--- a/src/current/v20.2/delete.md
+++ /dev/null
@@ -1,342 +0,0 @@
----
-title: DELETE
-summary: The DELETE statement deletes one or more rows from a table.
-toc: true
----
-
-The `DELETE` [statement](sql-statements.html) deletes rows from a table.
-
-{{site.data.alerts.callout_danger}}If you delete a row that is referenced by a <a href="foreign-key.html">foreign key constraint</a> and has an <a href="foreign-key.html#foreign-key-actions"><code>ON DELETE</code> action</a>, all of the dependent rows will also be deleted or updated.{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}To delete columns, see <a href="drop-column.html"><code>DROP COLUMN</code></a>.{{site.data.alerts.end}}
-
-## Required privileges
-
-The user must have the `DELETE` and `SELECT` [privileges](authorization.html#assign-privileges) on the table.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/delete.html %}
-</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
- Parameter | Description
------------|-------------
- `common_table_expr` | See [Common Table Expressions](common-table-expressions.html).
- `table_name` | The name of the table that contains the rows you want to update.
- `AS table_alias_name` | An alias for the table name. When an alias is provided, it completely hides the actual table name.
-`WHERE a_expr`| `a_expr` must be an expression that returns Boolean values using columns (e.g., `<column> = <value>`). Delete rows that return   `TRUE`.<br><br/>__Without a `WHERE` clause in your statement, `DELETE` removes all rows from the table. To delete all rows in a table, we recommend using [`TRUNCATE`](truncate.html) instead of `DELETE`.__
- `sort_clause` | An `ORDER BY` clause. <br /><br />See [Ordering of rows in DML statements](order-by.html#ordering-rows-in-dml-statements) for more details.
- `limit_clause` | A `LIMIT` clause. See [Limiting Query Results](limit-offset.html) for more details.
- `RETURNING target_list` | Return values based on rows deleted, where `target_list` can be specific column names from the table, `*` for all columns, or computations using [scalar expressions](scalar-expressions.html). <br><br>To return nothing in the response, not even the number of rows updated, use `RETURNING NOTHING`.
- `ONLY ... *` | <span class="version-tag">New in v20.2:</span> Supported for compatibility with PostgreSQL table inheritance syntax. This clause is a no-op, as CockroachDB does not currently support table inheritance.
-
-## Success responses
-
-Successful `DELETE` statements return one of the following:
-
- Response | Description
------------|-------------
-`DELETE` _`int`_ | _int_ rows were deleted.<br><br>`DELETE` statements that do not delete any rows respond with `DELETE 0`. When `RETURNING NOTHING` is used, this information is not included in the response.
-Retrieved table | Including the `RETURNING` clause retrieves the deleted rows, using the columns identified by the clause's parameters.<br><br>[See an example.](#return-deleted-rows)
-
-## Disk space usage after deletes
-
-Deleting a row does not immediately free up the disk space. This is
-due to the fact that CockroachDB retains [the ability to query tables
-historically](https://www.cockroachlabs.com/blog/time-travel-queries-select-witty_subtitle-the_future/).
-
-If disk usage is a concern, the solution is to
-[reduce the time-to-live](configure-replication-zones.html) (TTL) for
-the zone by setting `gc.ttlseconds` to a lower value, which will cause
-garbage collection to clean up deleted objects (rows, tables) more
-frequently.
-
-## Select performance on deleted rows
-
-Queries that scan across tables that have lots of deleted rows will
-have to scan over deletions that have not yet been garbage
-collected. Certain database usage patterns that frequently scan over
-and delete lots of rows will want to reduce the
-[time-to-live](configure-replication-zones.html) values to clean up
-deleted rows more frequently.
-
-## Sorting the output of deletes
-
-{% include {{page.version.version}}/misc/sorting-delete-output.md %}
-
-For more information about ordering query results in general, see
-[Ordering Query Results](order-by.html) and [Ordering of rows in
-DML statements](order-by.html#ordering-rows-in-dml-statements).
-
-## Force index selection for deletes
-
-By using the explicit index annotation (also known as "index hinting"), you can override [CockroachDB's index selection](https://www.cockroachlabs.com/blog/index-selection-cockroachdb-2/) and use a specific [index](indexes.html) for deleting rows of a named table.
-
-{{site.data.alerts.callout_info}}
-Index selection can impact [performance](performance-best-practices-overview.html), but does not change the result of a query.
-{{site.data.alerts.end}}
-
-The syntax to force a specific index for a delete is:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM table@my_idx;
-~~~
-
-This is equivalent to the longer expression:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM table@{FORCE_INDEX=my_idx};
-~~~
-
-To view how the index hint modifies the query plan that CockroachDB follows for deleting rows, use an [`EXPLAIN`](explain.html#opt-option) statement. To see all indexes available on a table, use [`SHOW INDEXES`](show-index.html).
-
-For examples, see [Delete with index hints](#delete-with-index-hints).
-
-### Preserving `DELETE` performance over time
-
-CockroachDB relies on [multi-version concurrency control (MVCC)](architecture/storage-layer.html#mvcc) to process concurrent requests while guaranteeing [strong consistency](frequently-asked-questions.html#how-is-cockroachdb-strongly-consistent). As such, when you delete a row, it is not immediately removed from disk. The MVCC values for the row will remain until the garbage collection period defined by the [`gc.ttlseconds`](configure-replication-zones.html#gc-ttlseconds) variable in the applicable [zone configuration](show-zone-configurations.html) has passed. By default, this period is 25 hours.
-
-This means that with the default settings, each iteration of your `DELETE` statement must scan over all of the rows previously marked for deletion within the last 25 hours. If you try to delete 10,000 rows 10 times within the same 25 hour period, the 10th command will have to scan over the 90,000 rows previously marked for deletion.
-
-To preserve performance over iterative `DELETE` queries, we recommend taking one of the following approaches:
-
-- At each iteration, update the `WHERE` clause to filter only the rows that have not yet been marked for deletion. For an example, see [Batch-delete on an indexed filter](bulk-delete-data.html) above.
-- At each iteration, first use a `SELECT` statement to return primary key values on rows that are not yet deleted. Rows marked for deletion will not be returned. Then, use a nested `DELETE` loop over a smaller batch size, filtering on the primary key values. For an example, see [Batch delete on a non-indexed column](bulk-delete-data.html) above.
-- To iteratively delete rows in constant time, using a simple `DELETE` loop, you can [alter your zone configuration](configure-replication-zones.html#overview) and change `gc.ttlseconds` to a low value like 5 minutes (i.e., `300`), and then run your `DELETE` statement once per GC interval.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Delete rows using Primary Key/unique columns
-
-Using columns with the [Primary Key](primary-key.html) or [Unique](unique.html) constraints to delete rows ensures your statement is unambiguous&mdash;no two rows contain the same column value, so it's less likely to delete data unintentionally.
-
-In this example, `code` is our primary key and we want to delete the row where the code equals "about_stuff_city". Because we're positive no other rows have that value in the `code` column, there's no risk of accidentally removing another row.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM promo_codes WHERE code = 'about_stuff_city';
-~~~
-~~~
-DELETE 1
-~~~
-
-### Delete rows using non-unique columns
-
-Deleting rows using non-unique columns removes _every_ row that returns `TRUE` for the `WHERE` clause's `a_expr`. This can easily result in deleting data you didn't intend to.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM promo_codes WHERE creation_time > '2019-01-30 00:00:00+00:00';
-~~~
-~~~
-DELETE 4
-~~~
-
-The example statement deleted four rows, which might be unexpected.
-
-### Return deleted rows
-
-To see which rows your statement deleted, include the `RETURNING` clause to retrieve them using the columns you specify.
-
-#### Use all columns
-
-By specifying `*`, you retrieve all columns of the delete rows.
-
-#### Use specific columns
-
-To retrieve specific columns, name them in the `RETURNING` clause.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM promo_codes WHERE creation_time > '2019-01-29 00:00:00+00:00' RETURNING code, rules;
-~~~
-~~~
-           code          |                    rules
-+------------------------+----------------------------------------------+
-  box_investment_stuff   | {"type": "percent_discount", "value": "10%"}
-  energy_newspaper_field | {"type": "percent_discount", "value": "10%"}
-  simple_guy_theory      | {"type": "percent_discount", "value": "10%"}
-  study_piece_war        | {"type": "percent_discount", "value": "10%"}
-  tv_this_list           | {"type": "percent_discount", "value": "10%"}
-(5 rows)
-
-~~~
-
-#### Change column labels
-
-When `RETURNING` specific columns, you can change their labels using `AS`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM promo_codes WHERE creation_time > '2019-01-28 00:00:00+00:00' RETURNING code, rules AS discount;
-~~~
-~~~
-         code         |                   discount
-+---------------------+----------------------------------------------+
-  chair_company_state | {"type": "percent_discount", "value": "10%"}
-  view_reveal_radio   | {"type": "percent_discount", "value": "10%"}
-(2 rows)
-~~~
-
-#### Sort and return deleted rows
-
-To sort and return deleted rows, use a statement like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH a AS (DELETE FROM promo_codes WHERE creation_time > '2019-01-27 00:00:00+00:00' RETURNING *)
-  SELECT * FROM a ORDER BY expiration_time;
-~~~
-
-~~~
-             code            |                                                                                                  description                                                                                                   |       creation_time       |      expiration_time      |                    rules
-+----------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------+---------------------------+----------------------------------------------+
-  often_thing_hair           | Society right wish face see if pull. Great generation social bar read budget wonder natural. Somebody dark field economic material. Nature nature paper law worry common. Serious activity hospital wide none. | 2019-01-27 03:04:05+00:00 | 2019-01-29 03:04:05+00:00 | {"type": "percent_discount", "value": "10%"}
-  step_though_military       | Director middle summer most create any.                                                                                                                                                                        | 2019-01-27 03:04:05+00:00 | 2019-01-29 03:04:05+00:00 | {"type": "percent_discount", "value": "10%"}
-  own_whose_economy          | Social participant order this. Guy toward nor indeed police player inside nor. Model education voice several college art on. Start listen their maybe.                                                         | 2019-01-27 03:04:05+00:00 | 2019-01-30 03:04:05+00:00 | {"type": "percent_discount", "value": "10%"}
-  crime_experience_certainly | Prepare right teacher mouth student. Trouble condition weight during scene something stand.                                                                                                                    | 2019-01-27 03:04:05+00:00 | 2019-01-31 03:04:05+00:00 | {"type": "percent_discount", "value": "10%"}
-  policy_its_wife            | Player either she something good minute or. Nearly policy player receive. Somebody mean book store fire realize.                                                                                               | 2019-01-27 03:04:05+00:00 | 2019-01-31 03:04:05+00:00 | {"type": "percent_discount", "value": "10%"}
-(5 rows)
-~~~
-
-### Delete with index hints
-
-Suppose you create a multi-column index on the `users` table with the `name` and `city` columns.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (name, city);
-~~~
-
-Now suppose you want to delete the two users named "Jon Snow". You can use the [`EXPLAIN (OPT)`](explain.html#opt-option) command to see how the [cost-based optimizer](cost-based-optimizer.html) decides to perform the delete:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (OPT) DELETE FROM users WHERE name='Jon Snow';
-~~~
-
-~~~
-                                        text
-------------------------------------------------------------------------------------
-  delete users
-   ├── scan users@users_name_city_idx
-   │    └── constraint: /10/9/8: [/'Jon Snow' - /'Jon Snow']
-   └── f-k-checks
-        ├── f-k-checks-item: vehicles(city,owner_id) -> users(city,id)
-        │    └── semi-join (lookup vehicles@vehicles_auto_index_fk_city_ref_users)
-        │         ├── with-scan &1
-        │         └── filters (true)
-        ├── f-k-checks-item: rides(city,rider_id) -> users(city,id)
-        │    └── semi-join (lookup rides@rides_auto_index_fk_city_ref_users)
-        │         ├── with-scan &1
-        │         └── filters (true)
-        └── f-k-checks-item: user_promo_codes(city,user_id) -> users(city,id)
-             └── semi-join (lookup user_promo_codes)
-                  ├── with-scan &1
-                  └── filters (true)
-(16 rows)
-~~~
-
-The output of the `EXPLAIN` statement shows that the optimizer scans the newly-created `users_name_city_idx` index when performing the delete. This makes sense, as you are performing a delete based on the `name` column.
-
-Now suppose that instead you want to perform a delete, but using the `id` column instead.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (OPT) DELETE FROM users WHERE id IN ('70a3d70a-3d70-4400-8000-000000000016', '3d70a3d7-0a3d-4000-8000-00000000000c');
-~~~
-
-~~~
-                                                     text
----------------------------------------------------------------------------------------------------------------
-  delete users
-   ├── select
-   │    ├── scan users@users_name_city_idx
-   │    └── filters
-   │         └── users.id IN ('3d70a3d7-0a3d-4000-8000-00000000000c', '70a3d70a-3d70-4400-8000-000000000016')
-   └── f-k-checks
-        ├── f-k-checks-item: vehicles(city,owner_id) -> users(city,id)
-        │    └── semi-join (hash)
-        │         ├── with-scan &1
-        │         ├── scan vehicles@vehicles_auto_index_fk_city_ref_users
-        │         └── filters
-        │              ├── city = vehicles.city
-        │              └── id = owner_id
-        ├── f-k-checks-item: rides(city,rider_id) -> users(city,id)
-        │    └── semi-join (lookup rides@rides_auto_index_fk_city_ref_users)
-        │         ├── with-scan &1
-        │         └── filters (true)
-        └── f-k-checks-item: user_promo_codes(city,user_id) -> users(city,id)
-             └── semi-join (hash)
-                  ├── with-scan &1
-                  ├── scan user_promo_codes
-                  └── filters
-                       ├── city = user_promo_codes.city
-                       └── id = user_id
-(24 rows)
-~~~
-
-The optimizer still scans the newly-created `users_name_city_idx` index when performing the delete. Although scanning the table on this index could still be the most efficient, you may want to assess the performance difference between using `users_name_city_idx` and an index on the `id` column, as you are performing a delete with a filter on the `id` column.
-
-If you provide an index hint (i.e., force the index selection) to use the primary index on the column instead, the CockroachDB will scan the users table using the primary index, on `city`, and `id`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (OPT) DELETE FROM users@primary WHERE id IN ('70a3d70a-3d70-4400-8000-000000000016', '3d70a3d7-0a3d-4000-8000-00000000000c');
-~~~
-
-~~~
-                                                     text
----------------------------------------------------------------------------------------------------------------
-  delete users
-   ├── select
-   │    ├── scan users
-   │    │    └── flags: force-index=primary
-   │    └── filters
-   │         └── users.id IN ('3d70a3d7-0a3d-4000-8000-00000000000c', '70a3d70a-3d70-4400-8000-000000000016')
-   └── f-k-checks
-        ├── f-k-checks-item: vehicles(city,owner_id) -> users(city,id)
-        │    └── semi-join (hash)
-        │         ├── with-scan &1
-        │         ├── scan vehicles@vehicles_auto_index_fk_city_ref_users
-        │         └── filters
-        │              ├── city = vehicles.city
-        │              └── id = owner_id
-        ├── f-k-checks-item: rides(city,rider_id) -> users(city,id)
-        │    └── semi-join (lookup rides@rides_auto_index_fk_city_ref_users)
-        │         ├── with-scan &1
-        │         └── filters (true)
-        └── f-k-checks-item: user_promo_codes(city,user_id) -> users(city,id)
-             └── semi-join (hash)
-                  ├── with-scan &1
-                  ├── scan user_promo_codes
-                  └── filters
-                       ├── city = user_promo_codes.city
-                       └── id = user_id
-(25 rows)
-~~~
-
-## See also
-
-- [`INSERT`](insert.html)
-- [`UPDATE`](update.html)
-- [`UPSERT`](upsert.html)
-- [`TRUNCATE`](truncate.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`DROP TABLE`](drop-table.html)
-- [`DROP DATABASE`](drop-database.html)
-- [Other SQL Statements](sql-statements.html)
-- [Limiting Query Results](limit-offset.html)
diff --git a/src/current/v20.2/demo-automatic-cloud-migration.md b/src/current/v20.2/demo-automatic-cloud-migration.md
deleted file mode 100644
index fcfe5ba2d9e..00000000000
--- a/src/current/v20.2/demo-automatic-cloud-migration.md
+++ /dev/null
@@ -1,274 +0,0 @@
----
-title: Cross-Cloud Migration
-summary: Use a local cluster to simulate migrating from one cloud platform to another.
-toc: true
----
-
-CockroachDB's flexible [replication controls](configure-replication-zones.html) make it trivially easy to run a single CockroachDB cluster across cloud platforms and to migrate data from one cloud to another without any service interruption. This page walks you through a local simulation of the process.
-
-## Watch the demo
-
-{% include_cached youtube.html video_id="cCJkgZy6s2Q" %}
-
-## Step 1. Install prerequisites
-
-In this tutorial, you'll use CockroachDB, its built-in `ycsb` workload, and the HAProxy load balancer. Before you begin, make sure these applications are installed:
-
-- Install the latest version of [CockroachDB](install-cockroachdb.html).
-- Install [HAProxy](http://www.haproxy.org/). If you're on a Mac and using Homebrew, use `brew install haproxy`.
-
-Also, to keep track of the data files and logs for your cluster, you may want to create a new directory (e.g., `mkdir cloud-migration`) and start all your nodes in that directory.
-
-## Step 2. Start a 3-node cluster on "cloud 1"
-
-If you've already [started a local cluster](start-a-local-cluster.html), the commands for starting nodes should be familiar to you. The new flag to note is [`--locality`](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes), which accepts key-value pairs that describe the topography of a node. In this case, you're using the flag to specify that the first 3 nodes are running on cloud 1.
-
-In a new terminal, start node 1 on cloud 1:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---locality=cloud=1 \
---store=cloud1node1 \
---listen-addr=localhost:26257 \
---http-addr=localhost:8080 \
---cache=100MB \
---join=localhost:26257,localhost:26258,localhost:26259
-~~~~
-
-In a new terminal, start node 2 on cloud 1:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---locality=cloud=1 \
---store=cloud1node2 \
---listen-addr=localhost:26258 \
---http-addr=localhost:8081 \
---cache=100MB \
---join=localhost:26257,localhost:26258,localhost:26259
-~~~
-
-In a new terminal, start node 3 on cloud 1:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---locality=cloud=1 \
---store=cloud1node3 \
---listen-addr=localhost:26259 \
---http-addr=localhost:8082 \
---cache=100MB \
---join=localhost:26257,localhost:26258,localhost:26259
-~~~
-
-## Step 3. Initialize the cluster
-
-In a new terminal, use the [`cockroach init`](cockroach-init.html) command to perform a one-time initialization of the cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach init \
---insecure \
---host=localhost:26257
-~~~
-
-## Step 4. Set up HAProxy load balancing
-
-You're now running 3 nodes in a simulated cloud. Each of these nodes is an equally suitable SQL gateway to your cluster, but to ensure an even balancing of client requests across these nodes, you can use a TCP load balancer. Let's use the open-source [HAProxy](http://www.haproxy.org/) load balancer that you installed earlier.
-
-In a new terminal, run the [`cockroach gen haproxy`](cockroach-gen.html) command, specifying the port of any node:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen haproxy \
---insecure \
---host=localhost:26257
-~~~
-
-This command generates an `haproxy.cfg` file automatically configured to work with the 3 nodes of your running cluster. In the file, change `bind :26257` to `bind :26000`. This changes the port on which HAProxy accepts requests to a port that is not already in use by a node and that will not be used by the nodes you'll add later.
-
-~~~
-global
-  maxconn 4096
-
-defaults
-    mode                tcp
-    # Timeout values should be configured for your specific use.
-    # See: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-timeout%20connect
-    timeout connect     10s
-    timeout client      1m
-    timeout server      1m
-    # TCP keep-alive on client side. Server already enables them.
-    option              clitcpka
-
-listen psql
-    bind :26000
-    mode tcp
-    balance roundrobin
-    option httpchk GET /health?ready=1
-    server cockroach1 localhost:26257 check port 8080
-    server cockroach2 localhost:26258 check port 8081
-    server cockroach3 localhost:26259 check port 8082
-~~~
-
-Start HAProxy, with the `-f` flag pointing to the `haproxy.cfg` file:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ haproxy -f haproxy.cfg
-~~~
-
-## Step 5. Run a sample workload
-
-Now that you have a load balancer running in front of your cluster, lets use the YCSB workload built into CockroachDB to simulate multiple client connections, each performing mixed read/write workloads.
-
-1. In a new terminal, load the initial `ycsb` schema and data, pointing it at HAProxy's port:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init ycsb \
-    'postgresql://root@localhost:26000?sslmode=disable'
-    ~~~
-
-2. Run the `ycsb` workload, pointing it at HAProxy's port:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run ycsb \
-    --duration=20m \
-    --concurrency=10 \
-    --max-rate=1000
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    This command initiates 10 concurrent client workloads for 20 minutes, but limits the total load to 1000 operations per second (since you're running everything on a single machine).
-
-    You'll soon see per-operation statistics print to standard output every second:
-
-    ~~~
-    _elapsed___errors__ops/sec(inst)___ops/sec(cum)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)
-          1s        0         9258.1         9666.6      0.7      1.3      2.0      8.9 read
-          1s        0          470.1          490.9      1.7      2.9      4.1      5.0 update
-          2s        0        10244.6         9955.6      0.7      1.2      2.0      6.6 read
-          2s        0          559.0          525.0      1.6      3.1      6.0      7.3 update
-          3s        0         9870.8         9927.4      0.7      1.4      2.4     10.0 read
-          3s        0          500.0          516.6      1.6      4.2      7.9     15.2 update
-          4s        0         9847.2         9907.3      0.7      1.4      2.4     23.1 read
-          4s        0          506.8          514.2      1.6      3.7      7.6     17.8 update
-          5s        0        10084.4         9942.6      0.7      1.3      2.1      7.1 read
-          5s        0          537.2          518.8      1.5      3.5     10.0     15.2 update
-    ...
-    ~~~
-
-## Step 6. Watch data balance across all 3 nodes
-
-Now open the DB Console at `http://localhost:8080` and click **Metrics** in the left-hand navigation bar. The **Overview** dashboard is displayed. Hover over the **SQL Queries** graph at the top. After a minute or so, you'll see that the load generator is executing approximately 95% reads and 5% writes across all nodes:
-
-<img src="{{ 'images/v20.2/ui_sql_queries.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-Scroll down a bit and hover over the **Replicas per Node** graph. Because CockroachDB replicates each piece of data 3 times by default, the replica count on each of your 3 nodes should be identical:
-
-<img src="{{ 'images/v20.2/ui_replicas_migration.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-## Step 7. Add 3 nodes on "cloud 2"
-
-At this point, you're running three nodes on cloud 1. But what if you'd like to start experimenting with resources provided by another cloud vendor? Let's try that by adding three more nodes to a new cloud platform. Again, the flag to note is [`--locality`](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes), which you're using to specify that these next 3 nodes are running on cloud 2.
-
-In a new terminal, start node 4 on cloud 2:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---locality=cloud=2 \
---store=cloud2node4 \
---listen-addr=localhost:26260 \
---http-addr=localhost:8083 \
---cache=100MB \
---join=localhost:26257,localhost:26258,localhost:26259
-~~~
-
-In a new terminal, start node 5 on cloud 2:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---locality=cloud=2 \
---store=cloud2node5 \
---advertise-addr=localhost:26261 \
---http-addr=localhost:8084 \
---cache=100MB \
---join=localhost:26257,localhost:26258,localhost:26259
-~~~
-
-In a new terminal, start node 6 on cloud 2:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---locality=cloud=2 \
---store=cloud2node6 \
---advertise-addr=localhost:26262 \
---http-addr=localhost:8085 \
---cache=100MB \
---join=localhost:26257,localhost:26258,localhost:26259
-~~~
-
-## Step 8. Watch data balance across all 6 nodes
-
-Back on the **Overview** dashboard in DB Console, hover over the **Replicas per Node** graph again. Because you used [`--locality`](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes) to specify that nodes are running on 2 clouds, you'll see an approximately even number of replicas on each node, indicating that CockroachDB has automatically rebalanced replicas across both simulated clouds:
-
-<img src="{{ 'images/v20.2/ui_replicas_migration2.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-Note that it takes a few minutes for the DB Console to show accurate per-node replica counts on hover. This is why the new nodes in the screenshot above show 0 replicas. However, the graph lines are accurate, and you can click **View node list** in the **Summary** area for accurate per-node replica counts as well.
-
-## Step 9. Migrate all data to "cloud 2"
-
-So your cluster is replicating across two simulated clouds. But let's say that after experimentation, you're happy with cloud vendor 2, and you decide that you'd like to move everything there. Can you do that without interruption to your live client traffic? Yes, and it's as simple as running a single command to add a [hard constraint](configure-replication-zones.html#replication-constraints) that all replicas must be on nodes with `--locality=cloud=2`.
-
-In a new terminal, [edit the default replication zone](configure-zone.html):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --execute="ALTER RANGE default CONFIGURE ZONE USING constraints='[+cloud=2]';" --insecure --host=localhost:26257
-~~~
-
-## Step 10. Verify the data migration
-
-Back on the **Overview** dashboard in the DB Console, hover over the **Replicas per Node** graph again. Very soon, you'll see the replica count double on nodes 4, 5, and 6 and drop to 0 on nodes 1, 2, and 3:
-
-<img src="{{ 'images/v20.2/ui_replicas_migration3.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-This indicates that all data has been migrated from cloud 1 to cloud 2. In a real cloud migration scenario, at this point you would update the load balancer to point to the nodes on cloud 2 and then stop the nodes on cloud 1. But for the purpose of this local simulation, there's no need to do that.
-
-## Step 11. Stop the cluster
-
-Once you're done with your cluster, stop YCSB by switching into its terminal and pressing **CTRL-C**. Then do the same for HAProxy and each CockroachDB node.
-
-{{site.data.alerts.callout_success}}For the last node, the shutdown process will take longer (about a minute) and will eventually force stop the node. This is because, with only 1 node still online, a majority of replicas are no longer available (2 of 3), and so the cluster is not operational. To speed up the process, press <strong>CTRL-C</strong> a second time.{{site.data.alerts.end}}
-
-If you do not plan to restart the cluster, you may want to remove the nodes' data stores and the HAProxy config file:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ rm -rf cloud1node1 cloud1node2 cloud1node3 cloud2node4 cloud2node5 cloud2node6 haproxy.cfg
-~~~
-
-## What's next?
-
-Explore other core CockroachDB benefits and features:
-
-{% include {{ page.version.version }}/misc/explore-benefits-see-also.md %}
-
-You may also want to learn other ways to control the location and number of replicas in a cluster:
-
-- [Even Replication Across Datacenters](configure-replication-zones.html#even-replication-across-availability-zones)
-- [Multiple Applications Writing to Different Databases](configure-replication-zones.html#multiple-applications-writing-to-different-databases)
-- [Stricter Replication for a Table and Its Indexes](configure-replication-zones.html#stricter-replication-for-a-table-and-its-secondary-indexes)
-- [Tweaking the Replication of System Ranges](configure-replication-zones.html#tweaking-the-replication-of-system-ranges)
diff --git a/src/current/v20.2/demo-fault-tolerance-and-recovery.md b/src/current/v20.2/demo-fault-tolerance-and-recovery.md
deleted file mode 100644
index 7040a4c5f12..00000000000
--- a/src/current/v20.2/demo-fault-tolerance-and-recovery.md
+++ /dev/null
@@ -1,401 +0,0 @@
----
-title: Fault Tolerance & Recovery
-summary: Use a local cluster to explore how CockroachDB remains available during, and recovers after, failure.
-toc: true
----
-
-This page walks you through a simple demonstration of how CockroachDB remains available during, and recovers after, failure. Starting with a 6-node local cluster with the default 3-way replication, you'll run a sample workload, terminate a node to simulate failure, and see how the cluster continues uninterrupted. You'll then leave that node offline for long enough to watch the cluster repair itself by re-replicating missing data to other nodes. You'll then prepare the cluster for 2 simultaneous node failures by increasing to 5-way replication, then take two nodes offline at the same time, and again see how the cluster continues uninterrupted.
-
-## Before you begin
-
-Make sure you have already [installed CockroachDB](install-cockroachdb.html).
-
-## Step 1. Start a 6-node cluster
-
-1. Use the [`cockroach start`](cockroach-start.html) command to start 6 nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=fault-node1 \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=fault-node2 \
-    --listen-addr=localhost:26258 \
-    --http-addr=localhost:8081 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=fault-node3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=fault-node4 \
-    --listen-addr=localhost:26260 \
-    --http-addr=localhost:8083 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=fault-node5 \
-    --listen-addr=localhost:26261 \
-    --http-addr=localhost:8084 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=fault-node6 \
-    --listen-addr=localhost:26262 \
-    --http-addr=localhost:8085 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-2. Use the [`cockroach init`](cockroach-init.html) command to perform a one-time initialization of the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init \
-    --insecure \
-    --host=localhost:26257
-    ~~~
-
-## Step 2. Set up load balancing
-
-In this module, you'll run a sample workload to simulate multiple client connections. Each node is an equally suitable SQL gateway for the load, but it's always recommended to [spread requests evenly across nodes](recommended-production-settings.html#load-balancing). You'll use the open-source [HAProxy](http://www.haproxy.org/) load balancer to do that here.
-
-1. Install HAProxy.
-
-    <div class="filters clearfix">
-      <button style="width: 15%" class="filter-button" data-scope="mac">Mac</button>
-      <button style="width: 15%" class="filter-button" data-scope="linux">Linux</button>
-    </div>
-    <p></p>
-
-    <div class="filter-content" markdown="1" data-scope="mac">
-    If you're on a Mac and use Homebrew, run:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ brew install haproxy
-    ~~~
-    </div>
-
-    <div class="filter-content" markdown="1" data-scope="linux">
-    If you're using Linux and use apt-get, run:
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo apt-get install haproxy
-    ~~~
-    </div>
-
-2. Run the [`cockroach gen haproxy`](cockroach-gen.html) command, specifying the port of any node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach gen haproxy \
-    --insecure \
-    --host=localhost \
-    --port=26257
-    ~~~
-
-    This command generates an `haproxy.cfg` file automatically configured to work with the nodes of your running cluster.
-
-3. In `haproxy.cfg`, change `bind :26257` to `bind :26000`. This changes the port on which HAProxy accepts requests to a port that is not already in use by a node.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    sed -i.saved 's/^    bind :26257/    bind :26000/' haproxy.cfg
-    ~~~
-
-4. Start HAProxy, with the `-f` flag pointing to the `haproxy.cfg` file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ haproxy -f haproxy.cfg &
-    ~~~
-
-## Step 3. Run a sample workload
-
-Now that you have a load balancer running in front of your cluster, use the [`cockroach workload`](cockroach-workload.html) command to run CockroachDB's built-in version of the YCSB benchmark, simulating multiple client connections, each performing mixed read/write operations.
-
-1. Load the initial `ycsb` schema and data, pointing it at HAProxy's port:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init ycsb --splits=50 \
-    'postgresql://root@localhost:26000?sslmode=disable'
-    ~~~
-
-    The `--splits` flag tells the workload to manually split ranges a number of times. This is not something you'd normally do, but for the purpose of this tutorial, it makes it easier to visualize the movement of data in the cluster.
-
-2. Run the `ycsb` workload, pointing it at HAProxy's port:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run ycsb \
-    --duration=20m \
-    --concurrency=3 \
-    --max-rate=1000 \
-    --tolerate-errors \
-    'postgresql://root@localhost:26000?sslmode=disable'
-    ~~~
-
-    This command initiates 3 concurrent client workloads for 20 minutes, but limits the total load to 1000 operations per second (since you're running everything on a single machine).
-
-    You'll see per-operation statistics print to standard output every second:
-
-    ~~~
-    _elapsed___errors__ops/sec(inst)___ops/sec(cum)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)
-        1.0s        0          902.8          930.9      1.1      2.1      4.1     62.9 read
-        1.0s        0           46.5           48.0      3.4      4.7      6.0      6.0 update
-        2.0s        0          923.3          926.9      1.0      2.9      5.5      8.9 read
-        2.0s        0           38.0           43.0      3.0      6.0      7.6      7.6 update
-        3.0s        0          901.1          918.3      1.1      2.5      5.0      6.6 read
-        3.0s        0           55.0           47.0      3.4      7.9      9.4     11.5 update
-        4.0s        0          948.9          926.0      1.0      1.6      2.6      5.0 read
-        4.0s        0           46.0           46.7      3.1      5.2     16.8     16.8 update
-        5.0s        0          932.0          927.2      1.1      1.8      2.9     13.6 read
-        5.0s        0           56.0           48.6      3.0      4.2      5.2      5.5 update
-    ...
-    ~~~
-
-    After the specified duration (20 minutes in this case), the workload will stop and you'll see totals printed to standard output.
-
-## Step 4. Check the workload
-
-Initially, the workload creates a new database called `ycsb`, creates a `usertable` table in that database, and inserts a bunch of rows into the table. Soon, the load generator starts executing approximately 95% reads and 5% writes.
-
-1. Go to the DB Console at <a href="http://localhost:8080" data-proofer-ignore>http://localhost:8080</a>.
-
-2. To check the SQL queries getting executed, click **Metrics** on the left, and hover over the **SQL Queries** graph at the top:
-
-    <img src="{{ 'images/v20.2/fault-tolerance-1.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-3. To check the client connections from the load generator, select the **SQL** dashboard and hover over the **SQL Connections** graph:
-
-    <img src="{{ 'images/v20.2/fault-tolerance-2.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    You'll notice 3 client connections from the load generator. If you want to check that HAProxy balanced each connection to a different node, you can change the **Graph** dropdown from **Cluster** to specific nodes.
-
-4. To see more details about the `ycsb` database and `usertable` table, click **Databases** in the upper left and then scroll down until you see **ycsb**:
-
-    <img src="{{ 'images/v20.2/fault-tolerance-3.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    You can also view the schema of the `usertable` by clicking the table name:
-
-    <img src="{{ 'images/v20.2/fault-tolerance-4.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />    
-
-5. By default, CockroachDB replicates all data 3 times and balances it across all nodes. To see this balance, click **Overview** and check the replica count across all nodes:
-
-    <img src="{{ 'images/v20.2/fault-tolerance-6.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-## Step 5. Simulate a single node failure
-
-When a node fails, the cluster waits for the node to remain offline for 5 minutes by default before considering it dead, at which point the cluster automatically repairs itself by re-replicating any of the replicas on the down nodes to other available nodes.
-
-1. In a new terminal, [edit the default replication zone](configure-replication-zones.html) to reduce the amount of time the cluster waits before considering a node dead to the minimum allowed of 1 minute and 15 seconds:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --insecure \
-    --host=localhost:26000 \
-    --execute="SET CLUSTER SETTING server.time_until_store_dead = '1m15s';"
-    ~~~
-
-2. Then use the [`cockroach quit`](cockroach-quit.html) command to terminate a node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit \
-    --insecure \
-    --host=localhost:26261
-    ~~~
-
-## Step 6. Check load continuity and cluster health
-
-Go back to the DB Console, click **Metrics** on the left, and verify that the cluster as a whole continues serving data, despite one of the nodes being unavailable and marked as **Suspect**:
-
-<img src="{{ 'images/v20.2/fault-tolerance-7.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-This shows that when all ranges are replicated 3 times (the default), the cluster can tolerate a single node failure because the surviving nodes have a majority of each range's replicas (2/3).
-
-## Step 7. Watch the cluster repair itself
-
-Click **Overview** on the left:
-
-<img src="{{ 'images/v20.2/fault-tolerance-5.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-Because you reduced the time it takes for the cluster to consider the down node dead, after 1 minute or so, the cluster will consider the down node "dead", and you'll see the replica count on the remaining nodes increase and the number of under-replicated ranges decrease to 0. This shows the cluster repairing itself by re-replicating missing replicas.
-
-## Step 8. Prepare for two simultaneous node failures
-
-At this point, the cluster has recovered and is ready to handle another failure. However, the cluster cannot handle two _near-simultaneous_ failures in this configuration. Failures are "near-simultaneous" if they are closer together than the `server.time_until_store_dead` [cluster setting](cluster-settings.html) plus the time taken for the number of replicas on the dead node to drop to zero. If two failures occurred in this configuration, some ranges would become unavailable until one of the nodes recovers.
-
-To be able to tolerate 2 of 5 nodes failing simultaneously without any service interruption, ranges must be replicated 5 times.
-
-1. Restart the dead node, using the same command you used to start the node initially:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=fault-node5 \
-    --listen-addr=localhost:26261 \
-    --http-addr=localhost:8084 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-2. Use the [`ALTER RANGE ... CONFIGURE ZONE`](configure-zone.html) command to change the cluster's `default` replication factor to 5:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --execute="ALTER RANGE default CONFIGURE ZONE USING num_replicas=5;" --insecure --host=localhost:26000
-    ~~~
-
-3. Back in the DB Console **Overview** dashboard, watch the replica count increases and even out across all 6 nodes:
-
-    <img src="{{ 'images/v20.2/fault-tolerance-8.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    This shows the cluster up-replicating so that each range has 5 replicas, one on each node.
-
-## Step 9. Simulate two simultaneous node failures
-
-Use the [`cockroach quit`](cockroach-quit.html) command to stop two nodes:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach quit --insecure --host=localhost:26260
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach quit --insecure --host=localhost:26261
-~~~
-
-## Step 10. Check load continuity and cluster health
-
-1. Like before, go to the DB Console, click **Metrics** on the left, and verify that the cluster as a whole continues serving data, despite 2 nodes being offline:
-
-    <img src="{{ 'images/v20.2/fault-tolerance-9.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    This shows that when all ranges are replicated 5 times, the cluster can tolerate 2 simultaneous node outages because the surviving nodes have a majority of each range's replicas (3/5).
-
-2. To verify this further, use the `cockroach sql` command to count the number of rows in the `ycsb.usertable` table and verify that it is still serving reads:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --insecure \
-    --host=localhost:26257 \
-    --execute="SELECT count(*) FROM ycsb.usertable;"
-    ~~~
-
-    ~~~
-      count
-    +-------+
-      10000
-    (1 row)
-    ~~~
-
-    And writes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --insecure \
-    --host=localhost:26257 \
-    --execute="INSERT INTO ycsb.usertable VALUES ('asdf', NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL);"
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --insecure \
-    --host=localhost:26257 \
-    --execute="SELECT count(*) FROM ycsb.usertable;"
-    ~~~
-
-    ~~~
-      count
-    +-------+
-      10001
-    (1 row)
-    ~~~
-
-## Step 11. Clean up
-
-1. In the terminal where the YCSB workload is running, press CTRL + c.
-
-2. Terminate HAProxy:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ pkill haproxy
-    ~~~
-
-3. Use the [`cockroach quit`](cockroach-quit.html) command to shut down the remaining 4 nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26257
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    For the final 2 nodes, the shutdown process will take longer (about a minute each) and will eventually force the nodes to stop. This is because, with only 2 of 5 nodes left, a majority of replicas are not available, and so the cluster is no longer operational.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26258
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26259
-    ~~~
-
-4. To restart the cluster at a later time, run the same `cockroach start` commands as earlier from the directory containing the nodes' data stores.  
-
-    If you do not plan to restart the cluster, you may want to remove the nodes' data stores and the HAProxy config files:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -rf fault-node1 fault-node2 fault-node3 fault-node4 fault-node5 fault-node6 haproxy.cfg haproxy.cfg.saved
-    ~~~
-
-## What's next?
-
-Explore other core CockroachDB benefits and features:
-
-{% include {{ page.version.version }}/misc/explore-benefits-see-also.md %}
diff --git a/src/current/v20.2/demo-json-support.md b/src/current/v20.2/demo-json-support.md
deleted file mode 100644
index 81c35ab6414..00000000000
--- a/src/current/v20.2/demo-json-support.md
+++ /dev/null
@@ -1,274 +0,0 @@
----
-title: JSON Support
-summary: Use a local cluster to explore how CockroachDB can store and query unstructured JSONB data.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-This page walks you through a simple demonstration of how CockroachDB can store and query unstructured [`JSONB`](jsonb.html) data from a third-party API, as well as how a [GIN index](inverted-indexes.html) can optimize your queries.
-
-## Step 1. Install prerequisites
-
-<div class="filters clearfix">
-    <button class="filter-button page-level" data-scope="python">Python</button>
-    <button class="filter-button page-level " data-scope="go">Go</button>
-</div>
-
-<div class="filter-content" markdown="1" data-scope="go">
-- Install the latest version of [CockroachDB](install-cockroachdb.html).
-- Install the latest version of [Go](https://golang.org/dl/): `brew install go`
-- Install the [PostgreSQL driver](https://github.com/lib/pq): `go get github.com/lib/pq`
-</div>
-
-<div class="filter-content" markdown="1" data-scope="python">
-- Install the latest version of [CockroachDB](install-cockroachdb.html).
-- Install the [Python psycopg2 driver](http://initd.org/psycopg/docs/install.html): `pip install psycopg2`
-- Install the [Python Requests library](https://requests.readthedocs.io/en/latest/): `pip install requests`
-</div>
-
-## Step 2. Start a single-node cluster
-
-For the purpose of this tutorial, you need only one CockroachDB node running in insecure mode, so use the [`cockroach start-single-node`](cockroach-start-single-node.html) command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start-single-node \
---insecure \
---store=json-test \
---listen-addr=localhost:26257 \
---http-addr=localhost:8080 \
---background
-~~~
-
-## Step 3. Create a user
-
-Open the [built-in SQL shell](cockroach-sql.html) as the `root` user and create a new user, `maxroach`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --host=localhost:26257
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE USER maxroach;
-~~~
-
-## Step 4. Create a database and grant privileges
-
-Next, create a database called `jsonb_test`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE jsonb_test;
-~~~
-
-Set the database as the default:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET DATABASE = jsonb_test;
-~~~
-
-Then [grant privileges](grant.html) to the `maxroach` user:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON DATABASE jsonb_test TO maxroach;
-~~~
-
-## Step 5. Create a table
-
-Still in the SQL shell, create a table called `programming`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE programming (
-    id UUID DEFAULT uuid_v4()::UUID PRIMARY KEY,
-    posts JSONB
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE programming;
-~~~
-
-~~~
-  table_name  |                create_statement
-+-------------+------------------------------------------------+
-  programming | CREATE TABLE programming (
-              |     id UUID NOT NULL DEFAULT uuid_v4()::UUID,
-              |     posts JSONB NULL,
-              |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-              |     FAMILY "primary" (id, posts)
-              | )
-(1 row)
-~~~
-
-## Step 6. Run the code
-
-Now that you have a database, user, and a table, let's run code to insert rows into the table.
-
-<div class="filters clearfix">
-    <button class="filter-button page-level" data-scope="python">Python</button>
-    <button class="filter-button page-level " data-scope="go">Go</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="go">
-Download the <a href="https://raw.githubusercontent.com/cockroachdb/docs/master/_includes/{{ page.version.version }}/json/json-sample.go" download><code>json-sample.go</code></a> file, or create the file yourself and copy the code into it:
-
-{% include copy-clipboard.html %}
-~~~ go
-{% include {{ page.version.version }}/json/json-sample.go %}
-~~~
-
-In a new terminal window, navigate to your sample code file and run it:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ go run json-sample.go
-~~~
-
-The code queries the [Reddit API](https://www.reddit.com/dev/api/) for posts in [/r/programming](https://www.reddit.com/r/programming/). The Reddit API only returns 25 results per page; however, each page returns an `"after"` string that tells you how to get the next page. Therefore, the program does the following in a loop:
-
-1. Makes a request to the API.
-2. Inserts the results into the table and grabs the `"after"` string.
-3. Uses the new `"after"` string as the basis for the next request.
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-Download the <a href="https://raw.githubusercontent.com/cockroachdb/docs/master/_includes/{{ page.version.version }}/json/json-sample.py" download><code>json-sample.py</code></a> file, or create the file yourself and copy the code into it:
-
-{% include copy-clipboard.html %}
-~~~ python
-{% include {{ page.version.version }}/json/json-sample.py %}
-~~~
-
-In a new terminal window, navigate to your sample code file and run it:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ python json-sample.py
-~~~
-
-The code queries the [Reddit API](https://www.reddit.com/dev/api/) for posts in [/r/programming](https://www.reddit.com/r/programming/). The Reddit API only returns 25 results per page; however, each page returns an `"after"` string that tells you how to get the next page. Therefore, the program does the following in a loop:
-
-1. Makes a request to the API.
-2. Grabs the `"after"` string.
-3. Inserts the results into the table.
-4. Uses the new `"after"` string as the basis for the next request.
-</section>
-
-The program will loop through that 40 times, but you can start querying the data right away.
-
-## Step 7. Query the data
-
-Back in the terminal where the SQL shell is running, verify that rows of data are being inserted into your table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT count(*) FROM programming;
-~~~
-
-~~~
-  count
-+-------+
-    675
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT count(*) FROM programming;
-~~~
-
-~~~
-  count
-+-------+
-    825
-(1 row)
-~~~
-
-You should see the count increasing. Keep checking until you see 1000 rows.
-
-Now, retrieve all the current entries where the link is pointing to somewhere on GitHub:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id FROM programming \
-WHERE posts @> '{"data": {"domain": "github.com"}}';
-~~~
-
-~~~
-                   id
-+--------------------------------------+
-  05348629-d8f1-4c90-99cc-11e8ab313edb
-  059a1562-0054-49ff-adc7-aec82c6f74fb
-  1b5ea86d-c892-43ba-b40a-c63761aff3ea
-  25ac5bfe-44e2-4c6a-892c-959f859ee4e7
-  2ab49796-3e55-4a33-8a83-9decef9fbccc
-  2df2e3ac-757b-4689-844d-935876df75e9
-  4506e0b8-a572-499c-a9c1-2a5075a021f8
-  5209ce99-2253-4490-bceb-fd881ff6d962
-  56cf90cd-43a9-49e9-a078-3e28c115232f
-  57f287a3-d396-460a-a649-9fa41c4315e4
-  ...
-(90 rows)
-
-Time: 103.748ms
-~~~
-
-{{site.data.alerts.callout_info}}
-Since you are querying live data, your results for this and the following steps may vary from the results documented in this tutorial.
-{{site.data.alerts.end}}
-
-## Step 8. Create a GIN index to optimize performance
-
-The query in the previous step took 103.748ms. To optimize the performance of queries that filter on the `JSONB` column, let's create a [GIN index](inverted-indexes.html) on the column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INVERTED INDEX ON programming(posts);
-~~~
-
-## Step 9. Run the query again
-
-Now that there is a GIN index, the same query will run much faster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id FROM programming \
-WHERE posts @> '{"data": {"domain": "github.com"}}';
-~~~
-~~~
-(109 rows)
-
-Time: 6.862ms
-~~~
-
-Instead of 103.748ms, the query now takes 6.862ms.
-
-## Step 10. Clean up
-
-If the program is still running, press CTRL + c to terminate it and then use [`cockroach quit`](cockroach-quit.html) to stop the single-node CockroachDB cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach quit --insecure --host=localhost:26257
-~~~
-
-If you do not plan to restart the cluster, remove the node's data store:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ rm -rf json-test
-~~~
-
-## What's next?
-
-Explore other core CockroachDB benefits and features:
-
-{% include {{ page.version.version }}/misc/explore-benefits-see-also.md %}
-
-You may also want to learn more about the [`JSONB`](jsonb.html) data type and [GIN indexes](inverted-indexes.html).
diff --git a/src/current/v20.2/demo-low-latency-multi-region-deployment.md b/src/current/v20.2/demo-low-latency-multi-region-deployment.md
deleted file mode 100644
index a1adb1283d7..00000000000
--- a/src/current/v20.2/demo-low-latency-multi-region-deployment.md
+++ /dev/null
@@ -1,1151 +0,0 @@
----
-title: Low Latency Reads and Writes in a Multi-Region Cluster
-summary: Use data topologies to get low-latency reads and writes in a multi-region CockroachDB cluster.
-toc: true
-toc_not_nested: true
-key: demo-geo-partitioning.html
----
-
-In CockroachDB, data is replicated and distributed across the nodes of a cluster for consistency and resiliency, and [read and write requests are automatically routed between nodes](architecture/reads-and-writes-overview.html) as appropriate. In a single-region cluster, this behavior doesn't affect performance because network latency between nodes is sub-millisecond. In a cluster spread across multiple geographic regions, however, the distribution of data becomes a key performance bottleneck, and for that reason, it is important to think about the latency requirements of each table and then use the appropriate [data topologies](topology-patterns.html) to locate data for optimal performance.
-
-This tutorial walks you through the process of deploying a 9-node CockroachDB cluster across 3 US regions, 3 AZs per region, with a fictional vehicle-sharing application called [MovR](movr.html) running concurrently in each region. Initially, you'll see the effect of network latency when requests must move back and forth across the US. Then you'll use two important multi-region data topologies, [Geo-Partitioned Replicas](topology-geo-partitioned-replicas.html) and [Duplicate Indexes](topology-duplicate-indexes.html), to remove this bottleneck and dramatically lower latency, with the majority of reads and writes executing in 2 milliseconds or less. Finally, you'll experience the cluster's resiliency to AZ-level failure.
-
-## See it in action
-
-### Watch a demo
-
-Watch [this webinar recording](https://www.cockroachlabs.com/webinars/implementation-topologies-for-distributed-sql/) to see a demonstration of the concepts and features in this tutorial.
-
-### Read a case study
-
-Read about how an [electronic lock manufacturer](https://www.cockroachlabs.com/case-studies/european-electronic-lock-manufacturer-modernizes-iam-system-with-managed-cockroachdb/) and [multi-national bank](https://www.cockroachlabs.com/case-studies/top-five-multinational-bank-modernizes-its-european-core-banking-services-migrating-from-oracle-to-cockroachdb/) are using the Geo-Partitioned Replicas topology in production for improved performance and regulatory compliance.
-
-## Before you begin
-
-- [Request a trial license](#request-a-trial-license)
-- [Review important concepts](#review-important-concepts)
-- [Review the cluster setup](#review-the-cluster-setup)
-- [Review the MovR application](#review-the-movr-application)
-
-### Request a trial license
-
-Some CockroachDB features used in this tutorial require an Enterprise license, so [request a 30-day trial license](https://www.cockroachlabs.com/get-cockroachdb/enterprise/) before you get started.
-
-You should receive your trial license via email within a few minutes. You'll enable your license once your cluster is up-and-running.
-
-### Review important concepts
-
-To understand performance in a geographically distributed CockroachDB cluster, it's important to first review [how reads and writes work in CockroachDB](architecture/reads-and-writes-overview.html).
-
-### Review the cluster setup
-
-You'll deploy a 9-node CockroachDB cluster across 3 GCE regions, with each node on a VM in a distinct availability zone for optimal resiliency:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_multi-region_hardware.png' | relative_url }}" alt="Multi-region hardware setup" style="max-width:100%" />
-
-A few notes:
-
-- For each CockroachDB node, you'll use the [`n2-standard-4`](https://cloud.google.com/compute/docs/machine-types#standard_machine_types) machine type (4 vCPUs, 16 GB memory) with the Ubuntu 16.04 OS image and a [local SSD](https://cloud.google.com/compute/docs/disks/local-ssd#create_local_ssd) disk.
-- You'll start each node with the [`--locality` flag](cockroach-start.html#locality) describing the node's region and availability zone. Initially, this locality information will lead CockroachDB to evenly distribute data across the 3 regions. Then, it will be used to apply data topologies for lower latency.
-- There will be an extra VM in each region for an instance of the MovR application and the open-source HAProxy load balancer. The application in each region will be pointed at the local load balancer, which will direct connections only to the CockroachDB nodes in the same region.
-
-### Review the MovR application
-
-For your application, you'll use our open-source, fictional, peer-to-peer vehicle-sharing app, [MovR](movr.html). You'll run 3 instances of MovR, one in each US region, with each instance representing users in a specific city: New York, Chicago, or Seattle.
-
-#### The schema
-
-{% include {{ page.version.version }}/misc/movr-schema.md %}
-
-All of the tables except `promo_codes` have a multi-column primary key of `city` and `id`, with `city` being the first in the key. As such, the rows in these tables are geographically specific and ordered by geography. These tables are read and updated very frequently, and so to keep read and write latency low, you'll use the [Geo-Partitioned Replicas](topology-geo-partitioned-replicas.html) topology for these tables.
-
-In contrast, the data in the `promo_codes` table is not tied to geography, and the data is read frequently but rarely updated. This type of table is often referred to as a "reference table" or "lookup table". In this case, you'll use the [Duplicate Indexes](topology-duplicate-indexes.html) topology to keep just read latency very low, since that's primary.
-
-#### The workflow
-
-{% include {{ page.version.version }}/misc/movr-workflow.md %}
-
-## Step 1. Set up the environment
-
-- [Configure your network](#configure-your-network)
-- [Provision VMs](#provision-vms)
-
-### Configure your network
-
-{% include {{ page.version.version }}/performance/configure-network.md %}
-
-### Provision VMs
-
-You need 9 VMs across 3 GCE regions, 3 per region with each VM in a distinct availability zone. You also need 3 extra VMs, 1 per region, for a region-specific version of MovR and the HAProxy load balancer.
-
-1. [Create 9 VMs](https://cloud.google.com/compute/docs/instances/create-start-instance) for CockroachDB nodes.
-
-    When creating each VM:
-    - Use the [`n2-standard-4`](https://cloud.google.com/compute/docs/machine-types#standard_machine_types) machine type (4 vCPUs, 16 GB memory) and the Ubuntu 16.04 OS image.
-    - Select one of the following [region and availability zone](https://cloud.google.com/compute/docs/regions-zones/) configurations. Be sure to use each region/availability combination only once.
-
-        VM | Region | Availability Zone
-        ---|--------|------------------
-        1 | `us-east1` | `us-east1-b`
-        2 | `us-east1` | `us-east1-c`
-        3 | `us-east1` | `us-east1-d`
-        4 | `us-central1` | `us-central1-a`
-        5 | `us-central1` | `us-central1-b`
-        6 | `us-central1` | `us-central1-c`
-        7 | `us-west1` | `us-west1-a`
-        8 | `us-west1` | `us-west1-b`
-        9 | `us-west1` | `us-west1-c`
-    - [Create and mount a local SSD](https://cloud.google.com/compute/docs/disks/local-ssd#create_local_ssd).
-    - To apply the DB Console firewall rule you created earlier, click **Management, disk, networking, SSH keys**, select the **Networking** tab, and then enter `cockroachdb` in the **Network tags** field.
-
-2. [Create 3 VMs](https://cloud.google.com/compute/docs/instances/create-start-instance) for the region-specific versions of MovR and HAProxy, one in each of the regions mentioned above, using same machine types and OS image as mentioned above.
-
-3. Note the internal IP address of each VM. You'll need these addresses when starting the CockroachDB nodes, configuring HAProxy, and running the MovR application.
-
-## Step 2. Start CockroachDB
-
-Now that you have VMs in place, start your CockroachDB cluster across the three US regions.
-
-- [Start nodes in US East](#start-nodes-in-us-east)
-- [Start nodes in US Central](#start-nodes-in-us-central)
-- [Start nodes in US West](#start-nodes-in-us-west)
-- [Initialize the cluster](#initialize-the-cluster)
-
-### Start nodes in US East
-
-1. SSH to the first VM in the US East region where you want to run a CockroachDB node.
-
-2. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-3. Run the [`cockroach start`](cockroach-start.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --advertise-addr=<node1 internal address> \
-    --join=<node1 internal address>:26257,<node2 internal address>:26257,<node3 internal address>:26257 \
-    --locality=cloud=gce,region=us-east1,zone=<relevant zone> \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --background
-    ~~~
-
-4. Repeat steps 1 - 3 for the other two CockroachDB nodes in the region. Each time, be sure to:
-    - Adjust the `--advertise-addr` flag.
-    - Use the appropriate availability zone of the VM in the `zone` portion of the `--locality` flag.
-
-### Start nodes in US Central
-
-1. SSH to the first VM in the US Central region where you want to run a CockroachDB node.
-
-2. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-3. Run the [`cockroach start`](cockroach-start.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --advertise-addr=<node1 internal address> \
-    --join=<node1 internal address>:26257,<node2 internal address>:26257,<node3 internal address>:26257 \
-    --locality=cloud=gce,region=us-central1,zone=<relevant zone> \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --background
-    ~~~
-
-4. Repeat steps 1 - 3 for the other two CockroachDB nodes in the region. Each time, be sure to:
-    - Adjust the `--advertise-addr` flag.
-    - Use the appropriate availability zone of the VM in the `zone` portion of the `--locality` flag.
-
-### Start nodes in US West
-
-1. SSH to the first VM in the US West region where you want to run a CockroachDB node.
-
-2. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-3. Run the [`cockroach start`](cockroach-start.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --advertise-addr=<node1 internal address> \
-    --join=<node1 internal address>:26257,<node2 internal address>:26257,<node3 internal address>:26257 \
-    --locality=cloud=gce,region=us-west1,zone=<relevant zone> \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --background
-    ~~~
-
-4. Repeat steps 1 - 3 for the other two CockroachDB nodes in the region. Each time, be sure to:
-    - Adjust the `--advertise-addr` flag.
-    - Use the appropriate availability zone of the VM in the `zone` portion of the `--locality` flag.
-
-### Initialize the cluster
-
-On any of the VMs, run the one-time [`cockroach init`](cockroach-init.html) command to join the first nodes into a cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach init --insecure --host=<address of any node>
-~~~
-
-## Step 3. Start MovR
-
-- [Set up the client VMs](#set-up-the-client-vms)
-- [Configure the cluster for MovR](#configure-the-cluster-for-movr)
-- [Start MovR in US East](#start-movr-in-us-east)
-- [Start MovR in US Central](#start-movr-in-us-central)
-- [Start MovR in US West](#start-movr-in-us-west)
-
-### Set up the client VMs
-
-Next, install Docker and HAProxy on each client VM. Docker is required so you can later run MovR from a Docker image, and HAProxy will serve as the region-specific load balancer for MovR in each region.
-
-1. SSH to the VM in the US East region where you want to run MovR and HAProxy.
-
-2. Install Docker:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo apt-get update && \
-    sudo apt-get install -y apt-transport-https ca-certificates curl gnupg-agent software-properties-common && \
-    curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - && \
-    sudo apt-key fingerprint 0EBFCD88 && \
-    sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" && \
-    sudo apt-get update && \
-    sudo apt-get install -y docker-ce docker-ce-cli containerd.io
-    ~~~
-
-    If you get an error, run one command at a time or follow the [official Docker instructions](https://docs.docker.com/install/linux/docker-ce/ubuntu/#install-using-the-repository).
-
-3. Install HAProxy:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo apt-get update
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo apt-get install haproxy
-    ~~~
-
-4. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-    The `cockroach` binary needs to be on these VMs so you can run some client commands built into the binary, such as the command in the next step and the command for starting the built-in SQL shell.
-
-5. Run the [`cockroach gen haproxy`](cockroach-gen.html) command to generate an HAProxy config file, specifying the address of any CockroachDB node and the `--locality` of nodes in the US East region:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach gen haproxy \
-    --insecure \
-    --host=<address of any node> \
-    --locality=region=us-east1
-    ~~~
-
-    The generated configuration file is called `haproxy.cfg` and looks as follows, with the `server` addresses pre-populated with just the nodes in US East based on the `--locality` flag used:
-
-    ~~~
-    global
-      maxconn 4096
-
-    defaults
-        mode                tcp
-        # Timeout values should be configured for your specific use.
-        # See: https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#4-timeout%20connect
-        timeout connect     10s
-        timeout client      1m
-        timeout server      1m
-        # TCP keep-alive on client side. Server already enables them.
-        option              clitcpka
-
-    listen psql
-        bind :26257
-        mode tcp
-        balance roundrobin
-        option httpchk GET /health?ready=1
-        server cockroach1 <node1 address>:26257 check port 8080
-        server cockroach2 <node2 address>:26257 check port 8080
-        server cockroach3 <node3 address>:26257 check port 8080
-    ~~~
-
-6. Start HAProxy, with the `-f` flag pointing to the `haproxy.cfg` file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ haproxy -f haproxy.cfg &
-    ~~~
-
-7. Repeat the steps above for the client VMs in the other two regions. For each region, be sure to adjust the `--locality` flag when running the `cockroach gen haproxy` command.
-
-### Configure the cluster for MovR
-
-Before you can run MovR against the cluster, you must create a `movr` database and enable an Enterprise license.
-
-1. SSH to the client VM in the US East region.
-
-2. Use the [`cockroach sql`](cockroach-sql.html) command to start the built-in SQL shell, specifying the address of the HAProxy load balancer in the region:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=<address of HAProxy in US East>
-    ~~~
-
-3. In the SQL shell, create the `movr` database:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE movr;
-    ~~~
-
-4. Enable the trial license you requested earlier:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING cluster.organization = '<your organization>';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING enterprise.license = '<your license key>';
-    ~~~
-
-5. Set the longitude and latitude of the regions where you are running CockroachDB nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT into system.locations VALUES
-        ('region', 'us-east1', 33.836082, -81.163727),
-        ('region', 'us-central1', 42.032974, -93.581543),
-        ('region', 'us-west1', 43.804133, -120.554201);
-    ~~~
-
-    Inserting these coordinates enables you to visualize your cluster on the [**Node Map**](enable-node-map.html) feature of the DB Console.
-
-6. Exit the SQL shell:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    \q
-    ~~~
-
-### Start MovR in US East
-
-{{site.data.alerts.callout_info}}
-Be sure to use the exact version of MovR specified in the commands: `movr:19.09.2`. This tutorial relies on the SQL schema in this specific version.
-{{site.data.alerts.end}}
-
-1. Still on the client VM in the US East region, load the MovR schema and initial data for the cities of New York, Chicago, and Seattle, pointing at the address of the US East load balancer:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker run --rm cockroachdb/movr:19.09.2 \
-    --app-name "movr-load" \
-    --url "postgres://root@<address of HAProxy in US East>:26257/movr?sslmode=disable" \
-    load \
-    --num-users 100 \
-    --num-rides 100 \
-    --num-vehicles 10 \
-    --city "new york" \
-    --city "chicago" \
-    --city "seattle"
-    ~~~
-
-    After the Docker image downloads, you'll see data being generated for the specified cities:
-
-    ~~~
-    ...
-    [INFO] (MainThread) initializing tables
-    [INFO] (MainThread) loading cities ['new york', 'chicago', 'seattle']
-    [INFO] (MainThread) loading movr data with ~100 users, ~10 vehicles, and ~100 rides
-    [INFO] (MainThread) Only using 3 of 5 requested threads, since we only create at most one thread per city
-    [INFO] (Thread-1  ) Generating user data for new york...
-    [INFO] (Thread-2  ) Generating user data for chicago...
-    [INFO] (Thread-3  ) Generating user data for seattle...
-    [INFO] (Thread-2  ) Generating vehicle data for chicago...
-    [INFO] (Thread-3  ) Generating vehicle data for seattle...
-    [INFO] (Thread-1  ) Generating vehicle data for new york...
-    [INFO] (Thread-2  ) Generating ride data for chicago...
-    [INFO] (Thread-3  ) Generating ride data for seattle...
-    [INFO] (Thread-1  ) Generating ride data for new york...
-    [INFO] (Thread-2  ) populated chicago in 9.173931 seconds
-    [INFO] (Thread-3  ) populated seattle in 9.257723 seconds
-    [INFO] (Thread-1  ) populated new york in 9.386243 seconds
-    [INFO] (MainThread) populated 3 cities in 20.587325 seconds
-    [INFO] (MainThread) - 4.954505 users/second
-    [INFO] (MainThread) - 4.954505 rides/second
-    [INFO] (MainThread) - 0.582883 vehicles/second
-    ~~~
-
-2. Start MovR in the US East region, representing users in New York. Be sure to point at the address of the US East load balancer:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker run -it --rm cockroachdb/movr:19.09.2 \
-    --app-name "movr-east" \
-    --url "postgres://root@<address of HAProxy in US East>:26257/movr?sslmode=disable" \
-    --num-threads=15 \
-    run \
-    --city="new york"
-    ~~~
-
-### Start MovR in US Central
-
-1. SSH to the client VM in the US Central region.
-
-2. Start MovR in the US Central region, representing users in Chicago. Be sure to point at the address of the US Central load balancer:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker run -it --rm cockroachdb/movr:19.09.2 \
-    --app-name "movr-central" \
-    --url "postgres://root@<address of HAProxy in US Central>:26257/movr?sslmode=disable" \
-    --num-threads=15 \
-    run \
-    --city="chicago"
-    ~~~
-
-### Start MovR in US West
-
-1. SSH to the client VM in the US West region.
-
-2. Start MovR in the US West region, representing users in Seattle. Be sure to point at the address of the US West load balancer:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker run -it --rm cockroachdb/movr:19.09.2 \
-    --app-name "movr-west" \
-    --url "postgres://root@<address of HAProxy in US West>:26257/movr?sslmode=disable" \
-    --num-threads=15 \
-    run \
-    --city="seattle"
-    ~~~
-
-## Step 4. Access the DB Console
-
-Now that you've deployed and configured your cluster, take a look at it in the DB Console:
-
-1. Open a browser and go to `http://<external address of any node>:8080`.
-
-2. On the **Cluster Overview** page, select **View: Node Map** to access the [Node Map](enable-node-map.html), which visualizes your CockroachDB cluster on a map of the US:
-
-    <img src="{{ 'images/v20.2/geo-partitioning-node-map-1.png' | relative_url }}" alt="Geo-partitioning node map" style="max-width:100%" />
-
-3. Drill down one level to see your nodes across 3 regions:
-
-    <img src="{{ 'images/v20.2/geo-partitioning-node-map-2.png' | relative_url }}" alt="Geo-partitioning node map" style="max-width:100%" />
-
-4. Drill into a region to see that each node is in a distinct availability zone:
-
-    <img src="{{ 'images/v20.2/geo-partitioning-node-map-3.png' | relative_url }}" alt="Geo-partitioning node map" style="max-width:100%" />
-
-## Step 5. Check latency
-
-Use the DB Console to see the effect of network latency before applying multi-region data topologies.
-
-1. Still in the DB Console, click **Metrics** on the left and hover over the **Service Latency: SQL, 99th percentile** timeseries graph:
-
-    <img src="{{ 'images/v20.2/geo-partitioning-sql-latency-before.png' | relative_url }}" alt="Geo-partitioning SQL latency" style="max-width:100%" />
-
-    For each node, you'll see that the max latency of 99% of queries is in the 100s of milliseconds. To understand why SQL latency is so high, it's important to first look at how long it takes requests to physically travel between the nodes in your cluster.
-
-2. Click **Network Latency** in the left-hand navigation:
-
-    <img src="{{ 'images/v20.2/geo-partitioning-network-latency.png' | relative_url }}" alt="Geo-partitioning network latency" style="max-width:100%" />
-
-    The **Network Latency** page shows the round-trip latency between any two nodes in your cluster. Here's a node/region mapping:
-
-    Nodes | Region
-    ------|-------
-    1 - 3 | `us-east1`
-    4 - 6 | `us-central1`
-    7 - 9 | `us-west1`
-
-    As you can see, within a single region, round-trip latency is sub-millisecond. For example, between nodes 5 and 6 in the `us-central1` region, round-trip latency is 0.56ms. However, between nodes in different regions, round-trip latency is significantly higher. For example, between node 2 in `us-east1` and node 7 in `us-west`, round-trip latency is 66.43ms.
-
-## Step 6. Check replica distribution
-
-With network latency in mind, now use the built-in SQL shell to check the distribution of replicas. This will help us understand how SQL queries are moving between the nodes of the cluster and, thus, incurring latency.
-
-1. SSH to the client VM in any region.
-
-2. Use the [`cockroach sql`](cockroach-sql.html) command to start the built-in SQL shell, specifying the address of the HAProxy load balancer in the region:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --database=movr --host=<address of HAProxy in region>
-    ~~~
-
-3. In the SQL shell, use the [`SHOW RANGES`](show-ranges.html) statement to view the location of replicas for the tables and their secondary indexes:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW RANGES FROM TABLE users;
-    SHOW RANGES FROM TABLE vehicles;
-    SHOW RANGES FROM INDEX vehicles_auto_index_fk_city_ref_users;
-    SHOW RANGES FROM TABLE rides;
-    SHOW RANGES FROM INDEX rides_auto_index_fk_city_ref_users;
-    SHOW RANGES FROM INDEX rides_auto_index_fk_vehicle_city_ref_vehicles;
-    SHOW RANGES FROM TABLE user_promo_codes;
-    SHOW RANGES FROM TABLE vehicle_location_histories;
-    ~~~
-
-    ~~~
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       85 |      0.158604 |            1 | cloud=gce,region=us-east1,zone=us-east1-b | {1,6,8}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-b"}
-    (1 row)
-
-    Time: 750.045316ms
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       37 |      0.298143 |            3 | cloud=gce,region=us-east1,zone=us-east1-d | {3,6,7}  | {"cloud=gce,region=us-east1,zone=us-east1-d","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-a"}
-    (1 row)
-
-    Time: 473.718371ms
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       37 |      0.302683 |            3 | cloud=gce,region=us-east1,zone=us-east1-d | {3,6,7}  | {"cloud=gce,region=us-east1,zone=us-east1-d","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-a"}
-    (1 row)
-
-    Time: 2.556900719s
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       39 |      0.563349 |            7 | cloud=gce,region=us-west1,zone=us-west1-a | {3,6,7}  | {"cloud=gce,region=us-east1,zone=us-east1-d","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-a"}
-    (1 row)
-
-    Time: 673.337559ms
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       39 |      0.571556 |            7 | cloud=gce,region=us-west1,zone=us-west1-a | {3,6,7}  | {"cloud=gce,region=us-east1,zone=us-east1-d","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-a"}
-    (1 row)
-
-    Time: 3.184113514s
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       39 |       0.57792 |            7 | cloud=gce,region=us-west1,zone=us-west1-a | {3,6,7}  | {"cloud=gce,region=us-east1,zone=us-east1-d","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-a"}
-    (1 row)
-
-    Time: 2.812128768s
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       38 |      0.054887 |            9 | cloud=gce,region=us-west1,zone=us-west1-c | {2,6,9}  | {"cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (1 row)
-
-    Time: 896.010317ms
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       86 |      2.197216 |            6 | cloud=gce,region=us-central1,zone=us-central1-c | {2,6,7}  | {"cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-a"}
-    (1 row)
-
-    Time: 708.643369ms
-    ~~~
-
-    Here's the node/region mapping again:
-
-    Nodes | Region
-    ------|-------
-    1 - 3 | `us-east1`
-    4 - 6 | `us-central1`
-    7 - 9 | `us-west1`
-
-    You'll see that most tables and indexes map to a single range, and each range has 3 replicas spread across regions with one replica identified as `lease_holder`.
-
-    Thinking back to [how reads and writes work in CockroachDB](architecture/reads-and-writes-overview.html), this tells you that many reads are leaving their region to reach the relevant leaseholder replica, and all writes are spanning regions to achieve Raft consensus. This explains the currently high latencies.
-
-    For example, based on the output above, the replicas for the `users` table are on nodes 1, 6, and 8, with the leaseholder on node 1. This means that when a user in Seattle registers for the MovR service:
-
-    1. A request to write a row to the `users` table goes through the load balancer in US west to a gateway node in US west.
-    2. The request is routed to the leaseholder on node 1 in US east.
-    3. The leaseholder waits for consensus from a replica in US central or US west.
-    4. The leaseholder returns acknowledgement to the gateway node in the US west.
-    5. The gateway node responds to the client.
-
-## Step 7. Apply data topologies
-
-- [Partition geo-specific tables](#partition-geo-specific-tables)
-- [Duplicate the reference table](#duplicate-the-reference-table)
-
-### Partition geo-specific tables
-
-As mentioned earlier, all of the tables except `promo_codes` are geographically specific, ordered by `city`, and read and updated very frequently. For these tables, the most effective way to prevent the high latency resulting from cross-region operations is to apply the [Geo-Partitioned Replicas](topology-geo-partitioned-replicas.html) data topology. In practice, you will tell CockroachDB to partition these tables and their secondary indexes by `city`, each partition becoming its own range of 3 replicas. You will then tell CockroachDB to pin each partition (all of its replicas) to the relevant region. This means that reads and writes on these tables will always have access to the relevant replicas in each region and, therefore, will have low, intra-region latencies.
-
-1. Back in the SQL shell on one of your client VMs, use [`ALTER TABLE/INDEX ... PARTITION BY`](partition-by.html) statements to define partitions by `city` for the geo-specific tables and their secondary indexes:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE users PARTITION BY LIST (city) (
-        PARTITION new_york VALUES IN ('new york'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION seattle VALUES IN ('seattle')
-      );
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE vehicles PARTITION BY LIST (city) (
-        PARTITION new_york VALUES IN ('new york'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION seattle VALUES IN ('seattle')
-      );
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX vehicles_auto_index_fk_city_ref_users PARTITION BY LIST (city) (
-        PARTITION new_york VALUES IN ('new york'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION seattle VALUES IN ('seattle')
-      );
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE rides PARTITION BY LIST (city) (
-        PARTITION new_york VALUES IN ('new york'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION seattle VALUES IN ('seattle')
-      );
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX rides_auto_index_fk_city_ref_users PARTITION BY LIST (city) (
-        PARTITION new_york VALUES IN ('new york'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION seattle VALUES IN ('seattle')
-      );
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX rides_auto_index_fk_vehicle_city_ref_vehicles PARTITION BY LIST (vehicle_city) (
-        PARTITION new_york VALUES IN ('new york'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION seattle VALUES IN ('seattle')
-      );
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE user_promo_codes PARTITION BY LIST (city) (
-        PARTITION new_york VALUES IN ('new york'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION seattle VALUES IN ('seattle')
-      );
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE vehicle_location_histories PARTITION BY LIST (city) (
-        PARTITION new_york VALUES IN ('new york'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION seattle VALUES IN ('seattle')
-      );
-    ~~~
-
-2. Use the [`SHOW CREATE TABLE`](show-create.html) statement to review the partition definition for one of the geo-specific tables:
-
-    {{site.data.alerts.callout_success}}
-    The warning at the bottom tells you that partitions are not yet applied because corresponding replication zones still need to be created.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW CREATE TABLE vehicles;
-    ~~~
-
-    ~~~
-      table_name |                                          create_statement
-    +------------+-----------------------------------------------------------------------------------------------------+
-      vehicles   | CREATE TABLE vehicles (
-                 |     id UUID NOT NULL,
-                 |     city VARCHAR NOT NULL,
-                 |     type VARCHAR NULL,
-                 |     owner_id UUID NULL,
-                 |     creation_time TIMESTAMP NULL,
-                 |     status VARCHAR NULL,
-                 |     current_location VARCHAR NULL,
-                 |     ext JSONB NULL,
-                 |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-                 |     CONSTRAINT fk_city_ref_users FOREIGN KEY (city, owner_id) REFERENCES users(city, id),
-                 |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC) PARTITION BY LIST (city) (
-                 |         PARTITION new_york VALUES IN (('new york')),
-                 |         PARTITION chicago VALUES IN (('chicago')),
-                 |         PARTITION seattle VALUES IN (('seattle'))
-                 |     ),
-                 |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-                 | ) PARTITION BY LIST (city) (
-                 |     PARTITION new_york VALUES IN (('new york')),
-                 |     PARTITION chicago VALUES IN (('chicago')),
-                 |     PARTITION seattle VALUES IN (('seattle'))
-                 | )
-                 | -- Warning: Partitioned table with no zone configurations.
-    (1 row)
-    ~~~
-
-3. Use [`ALTER PARTITION ... CONFIGURE ZONE`](configure-zone.html) statements to create replication zones that pin each partition to nodes in the relevant region, using the localities specified when nodes were started:
-
-    {{site.data.alerts.callout_success}}
-    The `<table>@*` syntax lets you create zone configurations for all identically named partitions of a table, saving you multiple steps.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION new_york OF INDEX movr.users@*
-        CONFIGURE ZONE USING constraints='[+region=us-east1]';
-      ALTER PARTITION chicago OF INDEX movr.users@*
-        CONFIGURE ZONE USING constraints='[+region=us-central1]';
-      ALTER PARTITION seattle OF INDEX movr.users@*
-        CONFIGURE ZONE USING constraints='[+region=us-west1]';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION new_york OF INDEX movr.vehicles@*
-        CONFIGURE ZONE USING constraints='[+region=us-east1]';
-      ALTER PARTITION chicago OF INDEX movr.vehicles@*
-        CONFIGURE ZONE USING constraints='[+region=us-central1]';
-      ALTER PARTITION seattle OF INDEX movr.vehicles@*
-        CONFIGURE ZONE USING constraints='[+region=us-west1]';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION new_york OF INDEX movr.rides@*
-        CONFIGURE ZONE USING constraints='[+region=us-east1]';
-      ALTER PARTITION chicago OF INDEX movr.rides@*
-        CONFIGURE ZONE USING constraints='[+region=us-central1]';
-      ALTER PARTITION seattle OF INDEX movr.rides@*
-        CONFIGURE ZONE USING constraints='[+region=us-west1]';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION new_york OF INDEX movr.user_promo_codes@*
-        CONFIGURE ZONE USING constraints='[+region=us-east1]';
-      ALTER PARTITION chicago OF INDEX movr.user_promo_codes@*
-        CONFIGURE ZONE USING constraints='[+region=us-central1]';
-      ALTER PARTITION seattle OF INDEX movr.user_promo_codes@*
-        CONFIGURE ZONE USING constraints='[+region=us-west1]';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION new_york OF INDEX movr.vehicle_location_histories@*
-        CONFIGURE ZONE USING constraints='[+region=us-east1]';
-      ALTER PARTITION chicago OF INDEX movr.vehicle_location_histories@*
-        CONFIGURE ZONE USING constraints='[+region=us-central1]';
-      ALTER PARTITION seattle OF INDEX movr.vehicle_location_histories@*
-        CONFIGURE ZONE USING constraints='[+region=us-west1]';
-    ~~~
-
-3. At this point, you can use the [`SHOW CREATE TABLE`](show-create.html) statement to confirm that partitions are in effect:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW CREATE TABLE vehicles;
-    ~~~
-
-    ~~~
-      table_name |                                                 create_statement
-    +------------+-------------------------------------------------------------------------------------------------------------------+
-      vehicles   | CREATE TABLE vehicles (
-                 |     id UUID NOT NULL,
-                 |     city VARCHAR NOT NULL,
-                 |     type VARCHAR NULL,
-                 |     owner_id UUID NULL,
-                 |     creation_time TIMESTAMP NULL,
-                 |     status VARCHAR NULL,
-                 |     current_location VARCHAR NULL,
-                 |     ext JSONB NULL,
-                 |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-                 |     CONSTRAINT fk_city_ref_users FOREIGN KEY (city, owner_id) REFERENCES users(city, id),
-                 |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC) PARTITION BY LIST (city) (
-                 |         PARTITION new_york VALUES IN (('new york')),
-                 |         PARTITION chicago VALUES IN (('chicago')),
-                 |         PARTITION seattle VALUES IN (('seattle'))
-                 |     ),
-                 |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-                 | ) PARTITION BY LIST (city) (
-                 |     PARTITION new_york VALUES IN (('new york')),
-                 |     PARTITION chicago VALUES IN (('chicago')),
-                 |     PARTITION seattle VALUES IN (('seattle'))
-                 | );
-                 | ALTER PARTITION chicago OF INDEX movr.public.vehicles@primary CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-central1]';
-                 | ALTER PARTITION new_york OF INDEX movr.public.vehicles@primary CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-east1]';
-                 | ALTER PARTITION seattle OF INDEX movr.public.vehicles@primary CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-west1]';
-                 | ALTER PARTITION chicago OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-central1]';
-                 | ALTER PARTITION new_york OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-east1]';
-                 | ALTER PARTITION seattle OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-west1]'
-    (1 row)
-    ~~~
-
-    In contrast to the last time you ran this statement, you can now see the commands for re-creating the replication zone for each partition of the `vehicles` table and its secondary index.
-
-    The [`SHOW PARTITIONS`](show-partitions.html) statement is another way to confirm that partitions are in effect:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW PARTITIONS FROM TABLE vehicles;
-    ~~~
-
-    ~~~
-      database_name | table_name | partition_name | parent_partition | column_names |                   index_name                   | partition_value |              zone_config              |            full_zone_config
-    +---------------+------------+----------------+------------------+--------------+------------------------------------------------+-----------------+---------------------------------------+----------------------------------------+
-      movr          | vehicles   | new_york       | NULL             | city         | vehicles@primary                               | ('new york')    | constraints = '[+region=us-east1]'    | range_min_bytes = 134217728,
-                    |            |                |                  |              |                                                |                 |                                       | range_max_bytes = 536870912,
-                    |            |                |                  |              |                                                |                 |                                       | gc.ttlseconds = 90000,
-                    |            |                |                  |              |                                                |                 |                                       | num_replicas = 3,
-                    |            |                |                  |              |                                                |                 |                                       | constraints = '[+region=us-east1]',
-                    |            |                |                  |              |                                                |                 |                                       | lease_preferences = '[]'
-      movr          | vehicles   | new_york       | NULL             | city         | vehicles@vehicles_auto_index_fk_city_ref_users | ('new york')    | constraints = '[+region=us-east1]'    | range_min_bytes = 134217728,
-                    |            |                |                  |              |                                                |                 |                                       | range_max_bytes = 536870912,
-                    |            |                |                  |              |                                                |                 |                                       | gc.ttlseconds = 90000,
-                    |            |                |                  |              |                                                |                 |                                       | num_replicas = 3,
-                    |            |                |                  |              |                                                |                 |                                       | constraints = '[+region=us-east1]',
-                    |            |                |                  |              |                                                |                 |                                       | lease_preferences = '[]'
-      movr          | vehicles   | chicago        | NULL             | city         | vehicles@primary                               | ('chicago')     | constraints = '[+region=us-central1]' | range_min_bytes = 134217728,
-                    |            |                |                  |              |                                                |                 |                                       | range_max_bytes = 536870912,
-                    |            |                |                  |              |                                                |                 |                                       | gc.ttlseconds = 90000,
-                    |            |                |                  |              |                                                |                 |                                       | num_replicas = 3,
-                    |            |                |                  |              |                                                |                 |                                       | constraints = '[+region=us-central1]',
-                    |            |                |                  |              |                                                |                 |                                       | lease_preferences = '[]'
-      movr          | vehicles   | chicago        | NULL             | city         | vehicles@vehicles_auto_index_fk_city_ref_users | ('chicago')     | constraints = '[+region=us-central1]' | range_min_bytes = 134217728,
-                    |            |                |                  |              |                                                |                 |                                       | range_max_bytes = 536870912,
-                    |            |                |                  |              |                                                |                 |                                       | gc.ttlseconds = 90000,
-                    |            |                |                  |              |                                                |                 |                                       | num_replicas = 3,
-                    |            |                |                  |              |                                                |                 |                                       | constraints = '[+region=us-central1]',
-                    |            |                |                  |              |                                                |                 |                                       | lease_preferences = '[]'
-      movr          | vehicles   | seattle        | NULL             | city         | vehicles@primary                               | ('seattle')     | constraints = '[+region=us-west1]'    | range_min_bytes = 134217728,
-                    |            |                |                  |              |                                                |                 |                                       | range_max_bytes = 536870912,
-                    |            |                |                  |              |                                                |                 |                                       | gc.ttlseconds = 90000,
-                    |            |                |                  |              |                                                |                 |                                       | num_replicas = 3,
-                    |            |                |                  |              |                                                |                 |                                       | constraints = '[+region=us-west1]',
-                    |            |                |                  |              |                                                |                 |                                       | lease_preferences = '[]'
-      movr          | vehicles   | seattle        | NULL             | city         | vehicles@vehicles_auto_index_fk_city_ref_users | ('seattle')     | constraints = '[+region=us-west1]'    | range_min_bytes = 134217728,
-                    |            |                |                  |              |                                                |                 |                                       | range_max_bytes = 536870912,
-                    |            |                |                  |              |                                                |                 |                                       | gc.ttlseconds = 90000,
-                    |            |                |                  |              |                                                |                 |                                       | num_replicas = 3,
-                    |            |                |                  |              |                                                |                 |                                       | constraints = '[+region=us-west1]',
-                    |            |                |                  |              |                                                |                 |                                       | lease_preferences = '[]'
-    (6 rows)
-    ~~~
-
-      {% include {{page.version.version}}/sql/crdb-internal-partitions.md %}
-
-### Duplicate the reference table
-
-In contrast to the other tables, the `promo_codes` table is not tied to geography, and its data is read frequently but rarely updated. This type of table is often referred to as a "reference table" or "lookup table". For this table, you'll keep read latency low by applying the [Duplicate Indexes](topology-duplicate-indexes.html) data topology. In practice, you will put the leaseholder for the table itself (also called the primary index) in one region, create two secondary indexes on the table, and tell CockroachDB to put the leaseholder for each secondary index in one of the other regions. CockroachDB's [cost-based optimizer](cost-based-optimizer.html) will then make sure that reads from `promo_codes` access the local leaseholder (either for the table itself or for one of the secondary indexes). Writes, however, will still leave the region to get consensus for the table and its secondary indexes, but writes are so rare that this will not impact overall performance.
-
-1. Create two indexes on the `promo_codes` table, and make them complete copies of the primary index:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE INDEX promo_codes_idx_east ON promo_codes (code)
-        STORING (description, creation_time, expiration_time, rules);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE INDEX promo_codes_idx_west ON promo_codes (code)
-        STORING (description, creation_time, expiration_time, rules);
-    ~~~
-
-2. Use [`ALTER TABLE/INDEX ... CONFIGURE ZONE`](configure-zone.html) statements to create replication zones for the primary index and each secondary index, in each case setting a leaseholder preference telling CockroachDB to put the leaseholder for the index in a distinct region:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE promo_codes
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-central1": 1}',
-          lease_preferences = '[[+region=us-central1]]';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX promo_codes@promo_codes_idx_east
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-east1": 1}',
-          lease_preferences = '[[+region=us-east1]]';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX promo_codes@promo_codes_idx_west
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-west1": 1}',
-          lease_preferences = '[[+region=us-west1]]';
-    ~~~
-
-## Step 8. Re-check replica distribution
-
-1. Still in the SQL shell on one of your client VMs, use the [`SHOW RANGES`](show-ranges.html) statement to check replica placement of the geo-specific tables after partitioning:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM [SHOW RANGES FROM TABLE users]
-        WHERE "start_key" NOT LIKE '%Prefix%';
-      SELECT * FROM [SHOW RANGES FROM TABLE vehicles]
-        WHERE "start_key" NOT LIKE '%Prefix%';
-      SELECT * FROM [SHOW RANGES FROM INDEX vehicles_auto_index_fk_city_ref_users]
-        WHERE "start_key" NOT LIKE '%Prefix%';
-      SELECT * FROM [SHOW RANGES FROM TABLE rides]
-        WHERE "start_key" NOT LIKE '%Prefix%';
-      SELECT * FROM [SHOW RANGES FROM INDEX rides_auto_index_fk_city_ref_users]
-        WHERE "start_key" NOT LIKE '%Prefix%';
-      SELECT * FROM [SHOW RANGES FROM INDEX rides_auto_index_fk_vehicle_city_ref_vehicles]
-        WHERE "start_key" NOT LIKE '%Prefix%';
-      SELECT * FROM [SHOW RANGES FROM TABLE user_promo_codes]
-        WHERE "start_key" NOT LIKE '%Prefix%';
-      SELECT * FROM [SHOW RANGES FROM TABLE vehicle_location_histories]
-        WHERE "start_key" NOT LIKE '%Prefix%';
-    ~~~
-
-    ~~~
-       start_key  |        end_key        | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                                   replica_localities
-    +-------------+-----------------------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
-      /"new york" | /"new york"/PrefixEnd |      105 |      0.933453 |            3 | cloud=gce,region=us-east1,zone=us-east1-d       | {1,2,3}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-east1,zone=us-east1-d"}
-      /"chicago"  | /"chicago"/PrefixEnd  |      107 |      0.860034 |            6 | cloud=gce,region=us-central1,zone=us-central1-c | {4,5,6}  | {"cloud=gce,region=us-central1,zone=us-central1-a","cloud=gce,region=us-central1,zone=us-central1-b","cloud=gce,region=us-central1,zone=us-central1-c"}
-      /"seattle"  | /"seattle"/PrefixEnd  |      109 |      0.895921 |            7 | cloud=gce,region=us-west1,zone=us-west1-a       | {7,8,9}  | {"cloud=gce,region=us-west1,zone=us-west1-a","cloud=gce,region=us-west1,zone=us-west1-b","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (3 rows)
-
-    Time: 1.645458616s
-
-       start_key  |        end_key        | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                                   replica_localities
-    +-------------+-----------------------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
-      /"new york" | /"new york"/PrefixEnd |      125 |       2.11175 |            2 | cloud=gce,region=us-east1,zone=us-east1-c       | {1,2,3}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-east1,zone=us-east1-d"}
-      /"chicago"  | /"chicago"/PrefixEnd  |      129 |        1.9099 |            5 | cloud=gce,region=us-central1,zone=us-central1-b | {4,5,6}  | {"cloud=gce,region=us-central1,zone=us-central1-a","cloud=gce,region=us-central1,zone=us-central1-b","cloud=gce,region=us-central1,zone=us-central1-c"}
-      /"seattle"  | /"seattle"/PrefixEnd  |       56 |       2.04172 |            9 | cloud=gce,region=us-west1,zone=us-west1-c       | {7,8,9}  | {"cloud=gce,region=us-west1,zone=us-west1-a","cloud=gce,region=us-west1,zone=us-west1-b","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (3 rows)
-
-    Time: 1.260863914s
-
-       start_key  |        end_key        | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                                   replica_localities
-    +-------------+-----------------------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
-      /"new york" | /"new york"/PrefixEnd |      127 |      0.119543 |            1 | cloud=gce,region=us-east1,zone=us-east1-b       | {1,2,3}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-east1,zone=us-east1-d"}
-      /"chicago"  | /"chicago"/PrefixEnd  |      130 |      0.106442 |            5 | cloud=gce,region=us-central1,zone=us-central1-b | {4,5,6}  | {"cloud=gce,region=us-central1,zone=us-central1-a","cloud=gce,region=us-central1,zone=us-central1-b","cloud=gce,region=us-central1,zone=us-central1-c"}
-      /"seattle"  | /"seattle"/PrefixEnd  |       46 |      0.110188 |            9 | cloud=gce,region=us-west1,zone=us-west1-c       | {7,8,9}  | {"cloud=gce,region=us-west1,zone=us-west1-a","cloud=gce,region=us-west1,zone=us-west1-b","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (3 rows)
-
-    Time: 3.392228893s
-
-       start_key  |        end_key        | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                                   replica_localities
-    +-------------+-----------------------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
-      /"new york" | /"new york"/PrefixEnd |       76 |      2.498621 |            2 | cloud=gce,region=us-east1,zone=us-east1-c       | {1,2,3}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-east1,zone=us-east1-d"}
-      /"chicago"  | /"chicago"/PrefixEnd  |       83 |      2.243434 |            5 | cloud=gce,region=us-central1,zone=us-central1-b | {4,5,6}  | {"cloud=gce,region=us-central1,zone=us-central1-a","cloud=gce,region=us-central1,zone=us-central1-b","cloud=gce,region=us-central1,zone=us-central1-c"}
-      /"seattle"  | /"seattle"/PrefixEnd  |      148 |       2.39411 |            7 | cloud=gce,region=us-west1,zone=us-west1-a       | {7,8,9}  | {"cloud=gce,region=us-west1,zone=us-west1-a","cloud=gce,region=us-west1,zone=us-west1-b","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (3 rows)
-
-    Time: 1.294584902s
-
-       start_key  |        end_key        | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                                   replica_localities
-    +-------------+-----------------------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
-      /"new york" | /"new york"/PrefixEnd |       78 |      0.533722 |            1 | cloud=gce,region=us-east1,zone=us-east1-b       | {1,2,3}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-east1,zone=us-east1-d"}
-      /"chicago"  | /"chicago"/PrefixEnd  |       82 |      0.477912 |            4 | cloud=gce,region=us-central1,zone=us-central1-a | {4,5,6}  | {"cloud=gce,region=us-central1,zone=us-central1-a","cloud=gce,region=us-central1,zone=us-central1-b","cloud=gce,region=us-central1,zone=us-central1-c"}
-      /"seattle"  | /"seattle"/PrefixEnd  |      149 |      0.505345 |            7 | cloud=gce,region=us-west1,zone=us-west1-a       | {7,8,9}  | {"cloud=gce,region=us-west1,zone=us-west1-a","cloud=gce,region=us-west1,zone=us-west1-b","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (3 rows)
-
-    Time: 3.346661477s
-
-       start_key  |        end_key        | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                                   replica_localities
-    +-------------+-----------------------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
-      /"new york" | /"new york"/PrefixEnd |       80 |       0.61871 |            2 | cloud=gce,region=us-east1,zone=us-east1-c       | {1,2,3}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-east1,zone=us-east1-d"}
-      /"chicago"  | /"chicago"/PrefixEnd  |       84 |      0.547892 |            6 | cloud=gce,region=us-central1,zone=us-central1-c | {4,5,6}  | {"cloud=gce,region=us-central1,zone=us-central1-a","cloud=gce,region=us-central1,zone=us-central1-b","cloud=gce,region=us-central1,zone=us-central1-c"}
-      /"seattle"  | /"seattle"/PrefixEnd  |      150 |      0.579083 |            7 | cloud=gce,region=us-west1,zone=us-west1-a       | {7,8,9}  | {"cloud=gce,region=us-west1,zone=us-west1-a","cloud=gce,region=us-west1,zone=us-west1-b","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (3 rows)
-
-    Time: 3.341758512s
-
-       start_key  |        end_key        | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                                   replica_localities
-    +-------------+-----------------------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
-      /"new york" | /"new york"/PrefixEnd |      133 |      0.365143 |            1 | cloud=gce,region=us-east1,zone=us-east1-b       | {1,2,3}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-east1,zone=us-east1-d"}
-      /"chicago"  | /"chicago"/PrefixEnd  |      135 |      0.313355 |            6 | cloud=gce,region=us-central1,zone=us-central1-c | {4,5,6}  | {"cloud=gce,region=us-central1,zone=us-central1-a","cloud=gce,region=us-central1,zone=us-central1-b","cloud=gce,region=us-central1,zone=us-central1-c"}
-      /"seattle"  | /"seattle"/PrefixEnd  |      137 |      0.343468 |            9 | cloud=gce,region=us-west1,zone=us-west1-c       | {7,8,9}  | {"cloud=gce,region=us-west1,zone=us-west1-a","cloud=gce,region=us-west1,zone=us-west1-b","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (3 rows)
-
-    Time: 1.105110359s
-
-       start_key  |        end_key        | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                                   replica_localities
-    +-------------+-----------------------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------+
-      /"new york" | /"new york"/PrefixEnd |      112 |     20.852122 |            3 | cloud=gce,region=us-east1,zone=us-east1-d       | {1,2,3}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-east1,zone=us-east1-c","cloud=gce,region=us-east1,zone=us-east1-d"}
-      /"chicago"  | /"chicago"/PrefixEnd  |      114 |     17.631255 |            4 | cloud=gce,region=us-central1,zone=us-central1-a | {4,5,6}  | {"cloud=gce,region=us-central1,zone=us-central1-a","cloud=gce,region=us-central1,zone=us-central1-b","cloud=gce,region=us-central1,zone=us-central1-c"}
-      /"seattle"  | /"seattle"/PrefixEnd  |      116 |     19.677135 |            8 | cloud=gce,region=us-west1,zone=us-west1-b       | {7,8,9}  | {"cloud=gce,region=us-west1,zone=us-west1-a","cloud=gce,region=us-west1,zone=us-west1-b","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (3 rows)
-
-    Time: 1.612425537s
-    ~~~
-
-    You'll see that the replicas for each partition are now located on nodes in the relevant region:
-    - New York partitions are on nodes 1 - 3
-    - Chicago partitions are on nodes 4 - 6
-    - Seattle partitions are on nodes 7 - 9
-
-    This means that requests from users in a city no longer leave the region, thus removing all cross-region latencies.
-
-2. Now use the [`SHOW RANGES`](show-ranges.html) statement to check replica placement of the `promo_codes` reference table and indexes:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW RANGES FROM TABLE promo_codes;
-      SHOW RANGES FROM INDEX promo_codes_idx_east;
-      SHOW RANGES FROM INDEX promo_codes_idx_west;
-    ~~~
-
-    ~~~
-      start_key | end_key | range_id | range_size_mb | lease_holder |              lease_holder_locality              | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       87 |      0.835044 |            6 | cloud=gce,region=us-central1,zone=us-central1-c | {1,6,9}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (1 row)
-
-    Time: 517.443988ms
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       89 |       0.83622 |            1 | cloud=gce,region=us-east1,zone=us-east1-b | {1,6,9}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (1 row)
-
-    Time: 2.449771429s
-
-      start_key | end_key | range_id | range_size_mb | lease_holder |           lease_holder_locality           | replicas |                                                             replica_localities
-    +-----------+---------+----------+---------------+--------------+-------------------------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------+
-      NULL      | NULL    |       90 |      0.836372 |            9 | cloud=gce,region=us-west1,zone=us-west1-c | {1,6,9}  | {"cloud=gce,region=us-east1,zone=us-east1-b","cloud=gce,region=us-central1,zone=us-central1-c","cloud=gce,region=us-west1,zone=us-west1-c"}
-    (1 row)
-
-    Time: 2.621930607s
-    ~~~
-
-    You'll see that the replicas for each index are spread across regions, with the leaseholders each in a distinct region:
-    - The leaseholder for the `promo_codes` primary index is on node 6 in US Central
-    - The leaseholder for the `promo_codes_idx_east` secondary index is on node 1 in US East
-    - The leaseholder for the `promo_codes_idx_west` secondary index is on node 9 in US West
-
-    As you'll see in a just a bit, with one leaseholder in each region, CockroachDB's cost-based optimizer will make sure that reads always access the local leaseholder, keeping reads from this table very fast.
-
-## Step 9. Re-check latency
-
-1. Now that you've verified that replicas are located properly, go back to the DB Console, click **Metrics** on the left, and hover over the **Service Latency: SQL, 99th percentile** timeseries graph:
-
-    <img src="{{ 'images/v20.2/geo-partitioning-sql-latency-after-1.png' | relative_url }}" alt="Geo-partitioning SQL latency" style="max-width:100%" />
-
-    For each node, you'll see that **99% of all queries are now under 4 milliseconds**.
-
-2. 99th percentile latency can be influenced by occasional slow queries. For a more accurate sense of typical SQL latency, go to the following URL to view a custom graph for 90th percentile latency:
-
-    ~~~
-    http://<external address of any node>:8080/#/debug/chart?charts=%5B%7B%22metrics%22%3A%5B%7B%22downsampler%22%3A3%2C%22aggregator%22%3A3%2C%22derivative%22%3A0%2C%22perNode%22%3Atrue%2C%22source%22%3A%22%22%2C%22metric%22%3A%22cr.node.sql.exec.latency-p90%22%7D%5D%2C%22axisUnits%22%3A2%7D%5D
-    ~~~
-
-    <img src="{{ 'images/v20.2/geo-partitioning-sql-latency-after-2.png' | relative_url }}" alt="Geo-partitioning SQL latency" style="max-width:100%" />
-
-    As you can see, **90% of all SQL queries execute in less than 2 milliseconds**. In some cases, latency is even sub-millisecond.
-
-3. Most of the latency reduction is due to the geo-partitioned tables. However, the duplicate indexes approach for the `promo_codes` table is also relevant. To validate that the cost-based optimizer is picking the appropriate leaseholder from reads from `promo_codes` in each region, click **Statements** on the left, select **APP > MOVR-EAST**, and then click the `SELECT FROM promo_codes` statement:
-
-    <img src="{{ 'images/v20.2/geo-partitioning-sql-latency-after-3.png' | relative_url }}" alt="Geo-partitioning SQL latency" style="max-width:100%" />
-
-    In the "Logical Plan" area, note the `table = promo_codes@promo_codes_idx_east` scan. This proves that the cost-based optimizer used the leaseholder for that index and, thus, didn't leave the region for the instance of MovR running in US East.
-
-    To validate this behavior in the other regions, click **Statements** again on the left and follow the same steps for the other apps instances.
-
-## Step 10. Test resiliency
-
-There are various resiliency levels in your cluster:
-
-- For the [geo-partitioned data](topology-geo-partitioned-replicas.html#resiliency), each partition is constrained to a specific region and balanced across the 3 AZs in the region, so one AZ can fail per region without interrupting access to the partitions in that region.
-- For the [duplicated reference data](topology-duplicate-indexes.html#resiliency), replicas are balanced across regions, so one entire region can fail without interrupting access.
-
-Given that most of the data in your cluster is geo-partitioned, let's focus on AZ-level failure.
-
-1. SSH to the client VM in the US East region.
-
-2. Use the [`cockroach quit`](cockroach-quit.html) command to stop one node, effectively simulating one of the 3 AZ's failing:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=<address of one node in US East>
-    ~~~
-
-3. Back in the DB Console, click **Overview** and note that the cluster now considers that node "suspect":
-
-    <img src="{{ 'images/v20.2/geo-partitioning-resiliency-1.png' | relative_url }}" alt="Geo-partitioning resiliency" style="max-width:100%" />
-
-4. Despite the node being unavailable, the MovR instance in US East continues to make progress because the other 2 nodes, each in a distinct AZ, remain available, and all partitions in the region therefore remain available. To verify this, click **Metrics**, select node 1 or 2 from the **Graph** menu, and check that SQL traffic continues on the node:
-
-    <img src="{{ 'images/v20.2/geo-partitioning-resiliency-2.png' | relative_url }}" alt="Geo-partitioning resiliency" style="max-width:100%" />
-
-## See also
-
-- Related Topology Patterns
-    - [Geo-Partitioned Replicas Topology](topology-geo-partitioned-replicas.html)
-    - [Duplicate Indexes Topology](topology-duplicate-indexes.html)
-
-- Related Case Studies
-    - [Electronic lock manufacturer](https://www.cockroachlabs.com/case-studies/european-electronic-lock-manufacturer-modernizes-iam-system-with-managed-cockroachdb/)
-    - [Multi-national bank](https://www.cockroachlabs.com/case-studies/top-five-multinational-bank-modernizes-its-european-core-banking-services-migrating-from-oracle-to-cockroachdb/)
-
-- [Reads and Writes in CockroachDB](architecture/reads-and-writes-overview.html)
diff --git a/src/current/v20.2/demo-replication-and-rebalancing.md b/src/current/v20.2/demo-replication-and-rebalancing.md
deleted file mode 100644
index ce0d7530674..00000000000
--- a/src/current/v20.2/demo-replication-and-rebalancing.md
+++ /dev/null
@@ -1,308 +0,0 @@
----
-title: Replication and Rebalancing
-summary: Use a local cluster to explore how CockroachDB replicates and rebalances data.
-toc: true
----
-
-This page walks you through a simple demonstration of how CockroachDB replicates, distributes, and rebalances data. Starting with a 3-node local cluster, you'll write some data and verify that it replicates in triplicate by default. You'll then add 2 more nodes and watch how CockroachDB automatically rebalances replicas to efficiently use all available capacity.
-
-## Before you begin
-
-Make sure you have already [installed CockroachDB](install-cockroachdb.html).
-
-## Step 1. Generate certificates
-
-1. Create two directories:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs my-safe-directory
-    ~~~
-
-2. Create the CA (Certificate Authority) certificate and key pair:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-ca \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-3. Create the certificate and key pair for your nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    localhost \
-    $(hostname) \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    Because you're running a local cluster and all nodes use the same hostname (`localhost`), you only need a single node certificate. Note that this is different than running a production cluster, where you would need to generate a certificate and key for each node, issued to all common names and IP addresses you might use to refer to the node as well as to any load balancer instances.
-
-4. Create a client certificate and key pair for the `root` user:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-client \
-    root \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-## Step 2. Start a 3-node cluster
-
-1. Use the [`cockroach start`](cockroach-start.html) command to start node 1:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=rep-node1 \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-2. In a new terminal, start node 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=rep-node2 \
-    --listen-addr=localhost:26258 \
-    --http-addr=localhost:8081 \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-3. In a new terminal, start node 3:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=rep-node3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-4. In a new terminal, use the [`cockroach init`](cockroach-init.html) command to perform a one-time initialization of the cluster, sending the request to any node on the `--join` list:
-
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --certs-dir=certs --host=localhost:26257
-    ~~~
-
-    You'll see the following message:
-
-    ~~~
-    Cluster successfully initialized
-    ~~~
-
-    At this point, each node also prints helpful [startup details](cockroach-start.html#standard-output) to its log.
-
-## Step 3. Create a SQL user
-
-You'll use a non-`root` user for running a client workload and accessing the DB Console.
-
-1. In the same terminal, as the `root` user, open the [built-in SQL shell](cockroach-sql.html) against any node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --certs-dir=certs \
-    --host=localhost:26257
-    ~~~
-
-2. Create the `maxroach` user with a password:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER maxroach WITH PASSWORD '<your password>';
-    ~~~
-
-3. Assign the `maxroach` user to the `admin` role:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT admin TO maxroach;
-    ~~~
-
-    This role assignment is for convenience for this tutorial; it gives the user access to all data without the need for additional privileges. For more details, see [Authorization](authorization.html#admin-role).
-
-4. Exit the SQL shell:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-## Step 4. Write data
-
-1. In the same terminal, run the [`cockroach workload`](cockroach-workload.html) command to generate an example `intro` database. In the connection string, replace `<password>` with the password you created earlier for `maxroach`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init intro \
-    'postgres://maxroach:<password>@localhost:26257?sslmode=verify-full&sslrootcert=certs/ca.crt'
-    ~~~
-
-    ~~~
-    I200925 17:34:51.380259 1 workload/workloadsql/dataload.go:140  imported mytable (0s, 42 rows)
-    ~~~
-
-2. Re-open the SQL shell, this time as the `maxroach` user:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --user=maxroach \
-    --certs-dir=certs \
-    --host=localhost:26257
-    ~~~
-
-    Enter the user's password when prompted.
-
-3. Verify that the new `intro` database was added with one table, `mytable`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW DATABASES;
-    ~~~
-
-    ~~~
-      database_name
-    +---------------+
-      defaultdb
-      intro
-      postgres
-      system
-    (4 rows)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TABLES FROM intro;
-    ~~~
-
-    ~~~
-      table_name
-    --------------
-      mytable
-    (1 row)    
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM intro.mytable WHERE (l % 2) = 0;
-    ~~~
-
-    ~~~
-      l  |                          v
-    +----+------------------------------------------------------+
-       0 | !__aaawwmqmqmwwwaas,,_        .__aaawwwmqmqmwwaaa,,
-       2 | !"VT?!"""^~~^"""??T$Wmqaa,_auqmWBT?!"""^~~^^""??YV^
-       4 | !                    "?##mW##?"-
-       6 | !  C O N G R A T S  _am#Z??A#ma,           Y
-       8 | !                 _ummY"    "9#ma,       A
-      10 | !                vm#Z(        )Xmms    Y
-      12 | !              .j####mmm#####mm#m##6.
-      14 | !   W O W !    jmm###mm######m#mmm##6
-      16 | !             ]#me*Xm#m#mm##m#m##SX##c
-      18 | !             dm#||+*$##m#mm#m#Svvn##m
-      20 | !            :mmE=|+||S##m##m#1nvnnX##;     A
-      22 | !            :m#h+|+++=Xmm#m#1nvnnvdmm;     M
-      24 | ! Y           $#m>+|+|||##m#1nvnnnnmm#      A
-      26 | !  O          ]##z+|+|+|3#mEnnnnvnd##f      Z
-      28 | !   U  D       4##c|+|+|]m#kvnvnno##P       E
-      30 | !       I       4#ma+|++]mmhvnnvq##P`       !
-      32 | !        D I     ?$#q%+|dmmmvnnm##!
-      34 | !           T     -4##wu#mm#pw##7'
-      36 | !                   -?$##m####Y'
-      38 | !             !!       "Y##Y"-
-      40 | !
-    (21 rows)
-    ~~~
-
-3. Exit the SQL shell:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-## Step 5. Verify replication
-
-1. To understand replication in CockroachDB, it's important to review a few concepts from the [architecture](architecture/overview.html):
-
-
-    Concept | Description
-    --------|------------
-    **Range** | CockroachDB stores all user data (tables, indexes, etc.) and almost all system data in a giant sorted map of key-value pairs. This keyspace is divided into "ranges", contiguous chunks of the keyspace, so that every key can always be found in a single range.<br><br>From a SQL perspective, a table and its secondary indexes initially map to a single range, where each key-value pair in the range represents a single row in the table (also called the primary index because the table is sorted by the primary key) or a single row in a secondary index. As soon as that range reaches 512 MiB in size, it splits into two ranges. This process continues for these new ranges as the table and its indexes continue growing.
-    **Replica** | CockroachDB replicates each range (3 times by default) and stores each replica on a different node.
-
-2. With those concepts in mind, open the DB Console at <a href="http://localhost:8080" data-proofer-ignore>http://localhost:8080</a> and log in with the `maxroach` user.
-
-3. On the **Overview** page, note that the **Replicas** count is the same on all three nodes. This indicates:
-    - There are this many "ranges" of data in the cluster. These are mostly internal "system" ranges since you haven't added much table data.
-    - Each range has been replicated 3 times (according to the CockroachDB default).
-    - For each range, each replica is stored on different nodes.
-
-## Step 6. Add two more nodes
-
-1. Back in the terminal, add a fourth node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=rep-node4 \
-    --listen-addr=localhost:26260 \
-    --http-addr=localhost:8083 \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-3. In a new terminal, add a fifth node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=rep-node5 \
-    --listen-addr=localhost:26261 \
-    --http-addr=localhost:8084 \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-## Step 7. Watch data rebalance
-
-Back in the DB Console, you'll see that there are now 5 nodes listed.
-
-At first, the replica count will be lower for nodes 4 and 5. Very soon, however, you'll see those numbers even out across all nodes, indicating that data is being automatically rebalanced to utilize the additional capacity of the new nodes.
-
-## Step 8. Stop the cluster
-
-1. When you're done with your test cluster, press `ctrl-c` in each terminal where a node is running.
-
-    {{site.data.alerts.callout_info}}
-    For the last 2 nodes, the shutdown process will take longer (about a minute each) and will eventually force the nodes to stop. This is because, with only 2 of 5 nodes left, a majority of replicas are not available, and so the cluster is no longer operational. To speed up this process, you can press `ctrl-c` a second time.
-    {{site.data.alerts.end}}
-
-2. To restart the cluster at a later time, run the same `cockroach start` commands as earlier from the directory containing the nodes' data stores.  
-
-    If you do not plan to restart the cluster, you may want to remove the cluster's certificates and data stores:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -rf certs my-safe-directory rep-node1 rep-node2 rep-node3 rep-node4 rep-node5
-    ~~~
-
-## What's next?
-
-Explore other core CockroachDB benefits and features:
-
-{% include {{ page.version.version }}/misc/explore-benefits-see-also.md %}
diff --git a/src/current/v20.2/demo-serializable.md b/src/current/v20.2/demo-serializable.md
deleted file mode 100644
index 2c1db7e7262..00000000000
--- a/src/current/v20.2/demo-serializable.md
+++ /dev/null
@@ -1,532 +0,0 @@
----
-title: Serializable Transactions
-summary: Walk through a demonstration of the importance of SERIALIZABLE isolation for data correctness
-toc: true
-toc_not_nested: true
----
-
-In contrast to most databases, CockroachDB always uses `SERIALIZABLE` isolation, which is the strongest of the four [transaction isolation levels](https://en.wikipedia.org/wiki/Isolation_(database_systems)) defined by the SQL standard and is stronger than the `SNAPSHOT` isolation level developed later. `SERIALIZABLE` isolation guarantees that even though transactions may execute in parallel, the result is the same as if they had executed one at a time, without any concurrency. This ensures data correctness by preventing all "anomalies" allowed by weaker isolation levels.
-
-In this tutorial, you'll work through a hypothetical scenario that demonstrates the importance of `SERIALIZABLE` isolation for data correctness.
-
-1. You'll start by reviewing the scenario and its schema.
-2. You'll then execute the scenario at one of the weaker isolation levels, `READ COMMITTED`, observing the write skew anomaly and its implications. Because CockroachDB always uses `SERIALIZABLE` isolation, you'll run this portion of the tutorial on Postgres, which defaults to `READ COMMITTED`.
-3. You'll finish by executing the scenario at `SERIALIZABLE` isolation, observing how it guarantees correctness. You'll use CockroachDB for this portion.
-
-{{site.data.alerts.callout_info}}
-For a deeper discussion of transaction isolation and the write skew anomaly, see the [Real Transactions are Serializable](https://www.cockroachlabs.com/blog/acid-rain/) and [What Write Skew Looks Like](https://www.cockroachlabs.com/blog/what-write-skew-looks-like/) blog posts.
-{{site.data.alerts.end}}
-
-## Overview
-
-### Scenario
-
-- A hospital has an application for doctors to manage their on-call shifts.
-- The hospital has a rule that at least one doctor must be on call at any one time.
-- Two doctors are on-call for a particular shift, and both of them try to request leave for the shift at approximately the same time.
-- In Postgres, with the default `READ COMMITTED` isolation level, the [write skew](#write-skew) anomaly results in both doctors successfully booking leave and the hospital having no doctors on call for that particular shift.
-- In CockroachDB, with the `SERIALIZABLE` isolation level, write skew is prevented, one doctor is allowed to book leave and the other is left on-call, and lives are saved.
-
-#### Write skew
-
-When write skew happens, a transaction reads something, makes a decision based on the value it saw, and writes the decision to the database. However, by the time the write is made, the premise of the decision is no longer true. Only `SERIALIZABLE` and some implementations of `REPEATABLE READ` isolation prevent this anomaly.  
-
-### Schema
-
-<img src="{{ 'images/v20.2/serializable_schema.png' | relative_url }}" alt="Schema for serializable transaction tutorial" style="max-width:100%" />
-
-## Step 1. Set up the scenario on Postgres
-
-1. If you haven't already, install Postgres locally. On Mac, you can use [Homebrew](https://brew.sh/):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ brew install postgres
-    ~~~
-
-1. [Start Postgres](https://www.postgresql.org/docs/10/static/server-start.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ postgres -D /usr/local/var/postgres &
-    ~~~
-
-1. Open a SQL connection to Postgres:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ psql
-    ~~~
-
-1. Create the `doctors` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE doctors (
-        id INT PRIMARY KEY,
-        name TEXT
-    );
-    ~~~
-
-1. Create the `schedules` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE schedules (
-        day DATE,
-        doctor_id INT REFERENCES doctors (id),
-        on_call BOOL,
-        PRIMARY KEY (day, doctor_id)
-    );
-    ~~~
-
-1. Add two doctors to the `doctors` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO doctors VALUES
-        (1, 'Abe'),
-        (2, 'Betty');
-    ~~~
-
-1. Insert one week's worth of data into the `schedules` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO schedules VALUES
-        ('2018-10-01', 1, true),
-        ('2018-10-01', 2, true),
-        ('2018-10-02', 1, true),
-        ('2018-10-02', 2, true),
-        ('2018-10-03', 1, true),
-        ('2018-10-03', 2, true),
-        ('2018-10-04', 1, true),
-        ('2018-10-04', 2, true),
-        ('2018-10-05', 1, true),
-        ('2018-10-05', 2, true),
-        ('2018-10-06', 1, true),
-        ('2018-10-06', 2, true),
-        ('2018-10-07', 1, true),
-        ('2018-10-07', 2, true);
-    ~~~
-
-1. Confirm that at least one doctor is on call each day of the week:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT day, count(*) AS doctors_on_call FROM schedules
-      WHERE on_call = true
-      GROUP BY day
-      ORDER BY day;
-    ~~~
-
-    ~~~
-        day     | doctors_on_call
-    ------------+-----------------
-     2018-10-01 |               2
-     2018-10-02 |               2
-     2018-10-03 |               2
-     2018-10-04 |               2
-     2018-10-05 |               2
-     2018-10-06 |               2
-     2018-10-07 |               2
-    (7 rows)
-    ~~~
-
-## Step 2. Run the scenario on Postgres
-
-1. Doctor 1, Abe, starts to request leave for 10/5/18 using the hospital's schedule management application. The application starts a transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    ~~~
-
-1. The application checks to make sure at least one other doctor is on call for the requested date:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT count(*) FROM schedules
-      WHERE on_call = true
-      AND day = '2018-10-05'
-      AND doctor_id != 1;
-    ~~~
-
-    ~~~
-     count
-    -------
-         1
-    (1 row)
-    ~~~
-
-1. Around the same time, doctor 2, Betty, starts to request leave for the same day using the hospital's schedule management application. In a new terminal, start a second SQL session:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ psql
-    ~~~
-
-1. The application starts a transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    ~~~
-
-1. The application checks to make sure at least one other doctor is on call for the requested date:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT count(*) FROM schedules
-      WHERE on_call = true
-      AND day = '2018-10-05'
-      AND doctor_id != 2;
-    ~~~
-
-    ~~~
-     count
-    -------
-         1
-    (1 row)
-    ~~~
-
-1. In the terminal for doctor 1, since the previous check confirmed that another doctor is on call for 10/5/18, the application tries to update doctor 1's schedule:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > UPDATE schedules SET on_call = false
-      WHERE day = '2018-10-05'
-      AND doctor_id = 1;
-    ~~~
-
-2. In the terminal for doctor 2, since the previous check confirmed the same thing, the application tries to update doctor 2's schedule:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > UPDATE schedules SET on_call = false
-      WHERE day = '2018-10-05'
-      AND doctor_id = 2;
-    ~~~
-
-3. In the terminal for doctor 1, the application commits the transaction, despite the fact that the previous check (the `SELECT` query) is no longer true:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > COMMIT;
-    ~~~
-
-4. In the terminal for doctor 2, the application commits the transaction, despite the fact that the previous check (the `SELECT` query) is no longer true:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > COMMIT;
-    ~~~
-
-## Step 3. Check data correctness on Postgres
-
-So what just happened? Each transaction started by reading a value that, before the end of the transaction, became incorrect. Despite that fact, each transaction was allowed to commit. This is known as write skew, and the result is that 0 doctors are scheduled to be on call on 10/5/18.  
-
-To check this, in either terminal, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM schedules WHERE day = '2018-10-05';
-~~~
-
-~~~
-    day     | doctor_id | on_call
-------------+-----------+---------
- 2018-10-05 |         1 | f
- 2018-10-05 |         2 | f
-(2 rows)
-~~~
-
-Again, this anomaly is the result of Postgres' default isolation level of `READ COMMITTED`, but note that this would happen with any isolation level except `SERIALIZABLE` and some implementations of `REPEATABLE READ`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TRANSACTION_ISOLATION;
-~~~
-
-~~~
- transaction_isolation
------------------------
- read committed
-(1 row)
-~~~
-
-Exit each SQL shell with `\q` and then stop the Postgres server:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pkill -9 postgres
-~~~
-
-## Step 4. Set up the scenario on CockroachDB
-
-When you repeat the scenario on CockroachDB, you'll see that the anomaly is prevented by CockroachDB's `SERIALIZABLE` transaction isolation.
-
-1. If you haven't already, [install CockroachDB](install-cockroachdb.html) locally.
-
-1. Use the [`cockroach start-single-node`](cockroach-start-single-node.html) command to start a one-node CockroachDB cluster in insecure mode:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start-single-node \
-    --insecure \
-    --store=serializable-demo \
-    --listen-addr=localhost \
-    --background
-    ~~~
-
-1. As the `root` user, open the [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=localhost
-    ~~~
-
-1. Create the `doctors` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE doctors (
-        id INT PRIMARY KEY,
-        name TEXT
-    );
-    ~~~
-
-1. Create the `schedules` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE schedules (
-        day DATE,
-        doctor_id INT REFERENCES doctors (id),
-        on_call BOOL,
-        PRIMARY KEY (day, doctor_id)
-    );
-    ~~~
-
-1. Add two doctors to the `doctors` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO doctors VALUES
-        (1, 'Abe'),
-        (2, 'Betty');
-    ~~~
-
-1. Insert one week's worth of data into the `schedules` table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO schedules VALUES
-        ('2018-10-01', 1, true),
-        ('2018-10-01', 2, true),
-        ('2018-10-02', 1, true),
-        ('2018-10-02', 2, true),
-        ('2018-10-03', 1, true),
-        ('2018-10-03', 2, true),
-        ('2018-10-04', 1, true),
-        ('2018-10-04', 2, true),
-        ('2018-10-05', 1, true),
-        ('2018-10-05', 2, true),
-        ('2018-10-06', 1, true),
-        ('2018-10-06', 2, true),
-        ('2018-10-07', 1, true),
-        ('2018-10-07', 2, true);
-    ~~~
-
-1. Confirm that at least one doctor is on call each day of the week:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT day, count(*) AS on_call FROM schedules
-      WHERE on_call = true
-      GROUP BY day
-      ORDER BY day;  
-    ~~~
-
-    ~~~
-                 day            | on_call
-    +---------------------------+---------+
-      2018-10-01 00:00:00+00:00 |       2
-      2018-10-02 00:00:00+00:00 |       2
-      2018-10-03 00:00:00+00:00 |       2
-      2018-10-04 00:00:00+00:00 |       2
-      2018-10-05 00:00:00+00:00 |       2
-      2018-10-06 00:00:00+00:00 |       2
-      2018-10-07 00:00:00+00:00 |       2
-    (7 rows)
-    ~~~
-
-## Step 5. Run the scenario on CockroachDB
-
-1. Doctor 1, Abe, starts to request leave for 10/5/18 using the hospital's schedule management application. The application starts a transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    ~~~
-
-1. The application checks to make sure at least one other doctor is on call for the requested date:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT count(*) FROM schedules
-      WHERE on_call = true
-      AND day = '2018-10-05'
-      AND doctor_id != 1;
-    ~~~
-
-    Press enter a second time to have the server return the result:
-
-    ~~~
-      count
-    +-------+
-          1
-    (1 row)    
-    ~~~
-
-1. Around the same time, doctor 2, Betty, starts to request leave for the same day using the hospital's schedule management application. In a new terminal, start a second SQL session:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=localhost
-    ~~~
-
-1. The application starts a transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    ~~~
-
-1. The application checks to make sure at least one other doctor is on call for the requested date:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT count(*) FROM schedules
-      WHERE on_call = true
-      AND day = '2018-10-05'
-      AND doctor_id != 2;
-    ~~~
-
-    Press enter a second time to have the server return the result:
-
-    ~~~
-      count
-    +-------+
-          1
-    (1 row)    
-    ~~~
-
-1. In the terminal for doctor 1, since the previous check confirmed that another doctor is on call for 10/5/18, the application tries to update doctor 1's schedule:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > UPDATE schedules SET on_call = false
-      WHERE day = '2018-10-05'
-      AND doctor_id = 1;
-    ~~~
-
-1. In the terminal for doctor 2, since the previous check confirmed the same thing, the application tries to update doctor 2's schedule:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > UPDATE schedules SET on_call = false
-      WHERE day = '2018-10-05'
-      AND doctor_id = 2;
-    ~~~
-
-1. In the terminal for doctor 1, the application tries to commit the transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > COMMIT;
-    ~~~
-
-    Since CockroachDB uses `SERIALIZABLE` isolation, the database detects that the previous check (the `SELECT` query) is no longer true due to a concurrent transaction. It therefore prevents the transaction from committing, returning a retry error that indicates that the transaction must be attempted again:
-
-    ~~~
-    pq: restart transaction: TransactionRetryWithProtoRefreshError: TransactionRetryError: retry txn (RETRY_SERIALIZABLE): id=373bbefe key=/Table/53/1/17809/1/0 rw=true pri=0.03885012 stat=PENDING epo=0 ts=1569638527.268184000,1 orig=1569638507.593587000,0 min=1569638507.593587000,0 max=1569638507.593587000,0 wto=false seq=2
-    ~~~
-
-    {{site.data.alerts.callout_success}}
-    For this kind of error, CockroachDB recommends a [client-side transaction retry loop](transactions.html#client-side-intervention) that would transparently observe that the one doctor cannot take time off because the other doctor already succeeded in asking for it. You can find generic transaction retry functions for various languages in our [Build an App](example-apps.html) tutorials.
-    {{site.data.alerts.end}}
-
-1. In the terminal for doctor 2, the application tries to commit the transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > COMMIT;
-    ~~~
-
-    Since the transaction for doctor 1 failed, the transaction for doctor 2 can commit without causing any data correctness problems.
-
-## Step 6. Check data correctness on CockroachDB
-
-1. In either terminal, confirm that one doctor is still on call for 10/5/18:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM schedules WHERE day = '2018-10-05';
-    ~~~
-
-    ~~~
-                 day            | doctor_id | on_call
-    +---------------------------+-----------+---------+
-      2018-10-05 00:00:00+00:00 |         1 |  true
-      2018-10-05 00:00:00+00:00 |         2 |  false
-    (2 rows)
-    ~~~
-
-1. Again, the write skew anomaly was prevented by CockroachDB using the `SERIALIZABLE` isolation level:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TRANSACTION_ISOLATION;
-    ~~~
-
-    ~~~
-      transaction_isolation
-    +-----------------------+
-      serializable
-    (1 row)
-    ~~~
-
-1. Exit the SQL shell in each terminal:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-
-1. Exit each SQL shell with `\q` and then stop the node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost
-    ~~~
-
-    If you do not plan to restart the cluster, you may want to remove the node's data store:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -rf serializable-demo
-    ~~~
-
-## What's next?
-
-Explore other core CockroachDB benefits and features:
-
-{% include {{ page.version.version }}/misc/explore-benefits-see-also.md %}
-
-You might also want to learn more about how transactions work in CockroachDB and in general:
-
-- [Transactions Overview](transactions.html)
-- [Real Transactions are Serializable](https://www.cockroachlabs.com/blog/acid-rain/)
-- [What Write Skew Looks Like](https://www.cockroachlabs.com/blog/what-write-skew-looks-like/)
diff --git a/src/current/v20.2/deploy-app-gcr.md b/src/current/v20.2/deploy-app-gcr.md
deleted file mode 100644
index e6579ca101d..00000000000
--- a/src/current/v20.2/deploy-app-gcr.md
+++ /dev/null
@@ -1,339 +0,0 @@
----
-title: Deploy a CockroachDB Cloud Application with Google Cloud Run
-summary: Learn how to use Google Cloud Run (GCR) and CockroachDB Serverless to deploy a serverless application.
-toc: true
-twitter: false
-referral_id: docs_gcr_django
----
-
-This tutorial shows you how to use Google Cloud Run to deploy a containerized Django application that communicates with a CockroachDB {{ site.data.products.serverless }} cluster.
-
-## Prerequisites
-
-Before starting the tutorial, do the following:
-
-1. Create a [CockroachDB {{ site.data.products.cloud }}](https://cockroachlabs.cloud/signup?referralId={{page.referral_id}}) account.
-1. Create a [Google Cloud](https://cloud.google.com/) account.
-1. Install the [Google Cloud SDK](https://cloud.google.com/sdk).
-1. Install [Docker Desktop](https://www.docker.com/products/docker-desktop).
-
-## Step 1. Create a CockroachDB {{ site.data.products.serverless }} cluster
-
-{% include cockroachcloud/quickstart/create-a-free-cluster.md %}
-
-## Step 2. Set up your cluster connection
-
-{% include cockroachcloud/quickstart/set-up-your-cluster-connection.md %}
-
-## Step 3. Create a database
-
-1. If you haven't already, [download the CockroachDB binary](install-cockroachdb.html).
-1. Start the [built-in SQL shell](cockroach-sql.html) using the connection string you got from the CockroachDB {{ site.data.products.cloud }} Console earlier:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql \
-    --url='postgres://<username>:<password>@<global host>:26257/<cluster_name>.defaultdb?sslmode=verify-full&sslrootcert=<certs_dir>/cc-ca.crt'
-    ~~~
-
-    In the connection string copied from the CockroachDB {{ site.data.products.cloud }} Console, your username, password and cluster name are pre-populated. Replace the `<certs_dir>` placeholder with the path to the `certs` directory that you created earlier.
-
-1. In the SQL shell, create the `bank` database that your application will use:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE bank;
-    ~~~
-
-1. Exit the SQL shell:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-## Step 4. Get the application code
-
-1. Clone the code's GitHub repo:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ git clone https://github.com/cockroachlabs/example-app-python-django/
-    ~~~
-
-1. Create a new folder named `certs` at the top level of the `example-app-python-django` project, and then copy the root certificate that you downloaded for your cluster to the new folder.
-
-    The project directory structure should look like this:
-
-    ~~~
-    ├── Dockerfile
-    ├── README.md
-    ├── certs
-    │   └── root.crt
-    ├── cockroach_example
-    │   ├── cockroach_example
-    │   │   ├── __init__.py
-    │   │   ├── asgi.py
-    │   │   ├── migrations
-    │   │   │   ├── 0001_initial.py
-    │   │   │   └── __init__.py
-    │   │   ├── models.py
-    │   │   ├── settings.py
-    │   │   ├── urls.py
-    │   │   ├── views.py
-    │   │   └── wsgi.py
-    │   └── manage.py
-    └── requirements.txt
-    ~~~
-
-## Step 5. Initialize the database and test the app locally
-
-1. At the top level of the app's project directory, create and then activate a virtual environment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ virtualenv env
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ source env/bin/activate
-    ~~~
-
-1. Install the required modules to the virtual environment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ pip install -r requirements.txt
-    ~~~
-
-1. Set the `DATABASE_URL` environment variable to the connection string provided in the **Connection info** window of the CockroachDB {{ site.data.products.cloud }} Console, but with the root certificate located in the local `certs` directory:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ export DATABASE_URL="postgresql://user:password@free-tier.gcp-us-central1.cockroachlabs.cloud:26257/defaultdb?sslmode=verify-full&sslrootcert=certs/root.crt&options=--cluster%3Dcluster-name"
-    ~~~
-
-    This Django app uses the `dj_database_url` module to configure the database connection from a connection URL. The module uses the value assigned to the `DATABASE_URL` environment variable for the connection.
-
-    {{site.data.alerts.callout_info}}
-    In the Cloud Run deployment, we use the Google Cloud Secret Manager to define the `DATABASE_URL` environment variable for the deployment.
-    {{site.data.alerts.end}}
-
-1. Execute the initial database schema migration:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ python3 cockroach_example/manage.py migrate
-    ~~~
-
-    This migration initializes the `bank` database with the tables defined in `models.py`, in addition to some other tables for the admin functionality included with Django's starter application.
-
-1. Run the app:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ python3 cockroach_example/manage.py runserver 0.0.0.0:8000
-    ~~~
-
-    The output should look like this:
-
-    ~~~
-    ...
-    Starting development server at http://0.0.0.0:8000/
-    Quit the server with CONTROL-C.
-    ~~~
-
-    To perform simple reads and writes to the database, you can send HTTP requests to the application at http://0.0.0.0:8000/.
-
-1. In a new terminal, use `curl` to send a POST request to the application:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ curl --header "Content-Type: application/json" \
-    --request POST \
-    --data '{"name":"Carl"}' http://0.0.0.0:8000/customer/
-    ~~~
-
-    This request inserts a new row into the `cockroach_example_customers` table.
-
-1. Send a GET request to read from the `cockroach_example_customers` table:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ curl http://0.0.0.0:8000/customer/
-    ~~~
-
-    ~~~
-    [{"id": "bb7d6c4d-efb3-45f8-b790-9911aae7d8b2", "name": "Carl"}]
-    ~~~
-
-    You can also query the table directly in the [SQL shell](cockroach-sql.html) to see the changes:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.cockroach_example_customers;
-    ~~~
-
-    ~~~
-                       id                  | name
-    ---------------------------------------+-------
-      bb7d6c4d-efb3-45f8-b790-9911aae7d8b2 | Carl
-    (1 row)
-    ~~~
-
-1. Enter **Ctrl+C** to stop the application.
-
-## Step 6. Configure GCP
-
-1. In the terminal, authenticate the `gcloud` command-line tool with your Google Cloud account:
-
-    {{site.data.alerts.callout_info}}
-    `gcloud` is included with the [Google Cloud SDK](https://cloud.google.com/sdk) installation.
-    {{site.data.alerts.end}}
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud auth login
-    ~~~
-
-    Follow the prompts to authenticate.
-
-1. Create a Google Cloud project for the application deployment:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud projects create <gcp_project_id>
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    You can specify a location for the project within your Google Cloud resources with the `--organization` or `--folder` flags.
-    {{site.data.alerts.end}}
-
-1. Configure the CLI to use your Google Cloud account and the new project ID by default:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud init
-    ~~~
-
-1. Set the `PROJECT_ID` environment variable:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ export PROJECT_ID=<gcp_project_id>
-    ~~~
-
-    For the rest of the tutorial, we use `PROJECT_ID` to refer to the project ID.
-
-## Step 7. Containerize the application and push it to the registry
-
-1. Build the Docker image locally:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ docker build -t gcr.io/$PROJECT_ID/crdb-sample:v1 .
-    ~~~
-
-    If there are no errors, the container built successfully.
-
-1. Authenticate Docker with GCP's Container Registry:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud auth configure-docker
-    ~~~
-
-1. Enable the Container Registry API for the project:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud services enable containerregistry.googleapis.com
-    ~~~
-
-1. Push the Docker image to the project's registry.
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ docker push gcr.io/$PROJECT_ID/crdb-sample:v1
-    ~~~
-
-## Step 8. Create a secret for the database connection URI
-
-1. Create a service account to manage the secrets for your project:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud iam service-accounts create cockroach-labs
-    ~~~
-
-1. Enable the Secret Manager API for the project:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud services enable secretmanager.googleapis.com
-    ~~~
-
-1. Create a secret for the connection string stored locally in the `DATABASE_URL` environment variable, and bind the new service account to the secret.
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ echo $DATABASE_URL | gcloud secrets create cockroach-connection-uri --data-file=- --replication-policy=automatic
-    ~~~
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud secrets add-iam-policy-binding cockroach-connection-uri \
-        --member=serviceAccount:cockroach-labs@${PROJECT_ID}.iam.gserviceaccount.com \
-        --role=roles/secretmanager.secretAccessor
-    ~~~
-
-## Step 9. Deploy the application on Cloud Run
-
-1. Enable the Cloud Run API for the project:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud services enable run.googleapis.com
-    ~~~
-
-1. Create a [Cloud Run](https://console.cloud.google.com/run/) service for the application:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud alpha run deploy crl-app --region us-central1 --allow-unauthenticated \
-     --service-account=cockroach-labs@${PROJECT_ID}.iam.gserviceaccount.com \
-       --set-secrets="DATABASE_URL=cockroach-connection-uri:latest" \
-       --image=gcr.io/${PROJECT_ID}/crdb-sample:v1
-    ~~~
-
-    Note the following:
-      - The `--region` flag specifies the region of the CockroachDB node targeted in the connection string.
-      - The `--service-account` flag specifies the `cockroach-labs` service account that you created earlier for the app deployment.
-      - The `--set-secrets` flag sets the `DATABASE_URL` environment variable to the `cockroach-connection-uri` secret that you created earlier.
-      - The `--image` flag specifies the container image URL for the `crdb-sample` image that you pushed to the container registry.
-
-    If prompted, select `Cloud Run (fully managed)`.
-
-After the revision is deployed, you should be able to send requests to the application from a browser, or using a REST client (e.g., `curl`). For example:
-
-{% include_cached copy-clipboard.html %}
-~~~ shell
-$ curl https://<GCR_HOST>/customer/
-~~~
-
-~~~
-[{"id": "bb7d6c4d-efb3-45f8-b790-9911aae7d8b2", "name": "Carl"}]
-~~~
-
-{{site.data.alerts.callout_danger}}
-By default, the sample application allows all hosts/domain names to serve the application.
-
-After testing, we recommend that you update the [`ALLOWED_HOSTS` property in `settings.py`](https://docs.djangoproject.com/en/3.2/ref/settings/#allowed-hosts) to allow only a local testing URL and the Cloud Run service URL to serve the application.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Build a Simple Django App with CockroachDB](build-a-python-app-with-cockroachdb-django.html)
-
-{% include {{page.version.version}}/app/see-also-links.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-aws-insecure.md b/src/current/v20.2/deploy-cockroachdb-on-aws-insecure.md
deleted file mode 100644
index 5aa09e11456..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-aws-insecure.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: Deploy CockroachDB on AWS EC2 (Insecure)
-summary: Learn how to deploy CockroachDB on Amazon's AWS EC2 platform.
-toc: true
-toc_not_nested: true
-ssh-link: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html
----
-
-<div class="filters filters-big clearfix">
-  <a href="deploy-cockroachdb-on-aws.html"><button class="filter-button">Secure</button>
-  <button class="filter-button current"><strong>Insecure</strong></button></a>
-</div>
-
-This page shows you how to manually deploy an insecure multi-node CockroachDB cluster on Amazon's AWS EC2 platform, using AWS's managed load balancing service to distribute client traffic.
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/insecure-requirements.md %}
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/insecure-recommendations.md %}
-
-- All Amazon EC2 instances running CockroachDB should be members of the same [security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html).
-
-## Step 1. Create instances
-
-Open the [Amazon EC2 console](https://console.aws.amazon.com/ec2/) and [launch an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html#launch-instance-console) for each node you plan to have in your cluster. If you plan to [run our sample workload](#step-8-run-a-sample-workload) against the cluster, create a separate instance for that workload.
-
-- Run at least 3 nodes to ensure survivability.
-
-- Your instances will rely on Amazon Time Sync Service for clock synchronization. When choosing an AMI, note that some machines are preconfigured to use Amazon Time Sync Service (e.g., Amazon Linux AMIs) and others are not.
-
-- Use `m` (general purpose), `c` (compute-optimized), or `i` (storage-optimized) instance types, with SSD-backed [EBS volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) or [Instance Store volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html). For example, Cockroach Labs has used `c5d.4xlarge` (16 vCPUs and 32 GiB of RAM per instance, EBS) for internal testing.
-
-	- **Do not** use ["burstable" `t2` instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html), which limit the load on a single core.
-
-- Note the ID of the VPC you select. You will need to look up its IP range when setting inbound rules for your security group.
-
-- Make sure all your instances are in the same security group.
-
-	- If you are creating a new security group, add the [inbound rules](#step-2-configure-your-network) from the next step. Otherwise note the ID of the security group.
-
-For more details, see [Hardware Recommendations](recommended-production-settings.html#hardware) and [Cluster Topology](recommended-production-settings.html#topology).
-
-## Step 2. Configure your network
-
-[Add Custom TCP inbound rules](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) to your security group to allow TCP communication on two ports:
-
-- `26257` for inter-node and client-node communication. This enables the nodes to work as a cluster, the load balancer to route traffic to the nodes, and applications to connect to the load balancer.
-- `8080` for exposing the DB Console to the user, and for routing the load balancer to the health check endpoint.
-
-{% include {{ page.version.version }}/prod-deployment/aws-inbound-rules.md %}
-
-## Step 3. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 4. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-
-AWS offers fully-managed load balancing to distribute traffic between instances.
-
-1. [Add AWS load balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html). Be sure to:
-	- Select a **Network Load Balancer** and use the ports we specify below.
-	- Select the VPC and *all* availability zones of your instances. This is important, as you cannot change the availability zones once the load balancer is created. The availability zone of an instance is determined by its subnet, found by inspecting the instance in the Amazon EC2 Console.
-	- Set the load balancer port to **26257**.
-    - Create a new target group that uses TCP port **26257**. Traffic from your load balancer is routed to this target group, which contains your instances.
-    - Configure health checks to use HTTP port **8080** and path `/health?ready=1`. This [health endpoint](monitoring-and-alerting.html#health-ready-1) ensures that load balancers do not direct traffic to nodes that are live but not ready to receive requests.
-    - Register your instances with the target group you created, specifying port **26257**. You can add and remove instances later.
-2. To test load balancing and connect your application to the cluster, you will need the provisioned internal (private) **IP address** for the load balancer. To find this, open the Network Interfaces section of the Amazon EC2 console and look up the load balancer by its name.
-
-{{site.data.alerts.callout_info}}If you would prefer to use HAProxy instead of AWS's managed load balancing, see the <a href="deploy-cockroachdb-on-premises-insecure.html">On-Premises</a> tutorial for guidance.{{site.data.alerts.end}}
-
-## Step 5. Start nodes
-
-{% include {{ page.version.version }}/prod-deployment/insecure-start-nodes.md %}
-
-## Step 6. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-initialize-cluster.md %}
-
-## Step 7. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-cluster.md %}
-
-## Step 8. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-load-balancing.md %}
-
-## Step 9. Monitor the cluster
-
-In the Target Groups section of the Amazon EC2 console, [check the health](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html) of your instances by inspecting your target group and opening the Targets tab.
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 10. Scale the cluster
-
-Before adding a new node, [create a new instance](#step-1-create-instances) as you did earlier.
-
-{% include {{ page.version.version }}/prod-deployment/insecure-scale-cluster.md %}
-
-## Step 11. Use the cluster
-
-Now that your deployment is working, you can:
-
-1. [Implement your data model](sql-statements.html).
-2. [Create users](authorization.html) and [grant them privileges](grant.html).
-3. [Connect your application](install-client-drivers.html). Be sure to connect your application to the AWS load balancer, not to a CockroachDB node.
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-aws.md b/src/current/v20.2/deploy-cockroachdb-on-aws.md
deleted file mode 100644
index 3269e7c06c0..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-aws.md
+++ /dev/null
@@ -1,136 +0,0 @@
----
-title: Deploy CockroachDB on AWS EC2
-summary: Learn how to deploy CockroachDB on Amazon's AWS EC2 platform.
-toc: true
-toc_not_nested: true
-ssh-link: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html
-
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Secure</strong></button>
-  <a href="deploy-cockroachdb-on-aws-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-This page shows you how to manually deploy a secure multi-node CockroachDB cluster on Amazon's AWS EC2 platform, using AWS's managed load balancing service to distribute client traffic.
-
-If you are only testing CockroachDB, or you are not concerned with protecting network communication with TLS encryption, you can use an insecure cluster instead. Select **Insecure** above for instructions.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/secure-requirements.md %}
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/secure-recommendations.md %}
-
-- All Amazon EC2 instances running CockroachDB should be members of the same [security group](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html).
-
-## Step 1. Create instances
-
-Open the [Amazon EC2 console](https://console.aws.amazon.com/ec2/) and [launch an instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/launching-instance.html#launch-instance-console) for each node you plan to have in your cluster. If you plan to [run our sample workload](#step-9-run-a-sample-workload) against the cluster, create a separate instance for that workload.
-
-- Run at least 3 nodes to ensure survivability.
-
-- Your instances will rely on Amazon Time Sync Service for clock synchronization. When choosing an AMI, note that some machines are preconfigured to use Amazon Time Sync Service (e.g., Amazon Linux AMIs) and others are not.
-
-- Use `m` (general purpose), `c` (compute-optimized), or `i` (storage-optimized) instance types, with SSD-backed [EBS volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html) or [Instance Store volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html). For example, Cockroach Labs has used `c5d.4xlarge` (16 vCPUs and 32 GiB of RAM per instance, EBS) for internal testing.
-
-	- **Do not** use ["burstable" `t2` instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html), which limit the load on a single core.
-
-- Note the ID of the VPC you select. You will need to look up its IP range when setting inbound rules for your security group.
-
-- Make sure all your instances are in the same security group.
-
-	- If you are creating a new security group, add the [inbound rules](#step-2-configure-your-network) from the next step. Otherwise note the ID of the security group.
-
-- When creating the instance, you will download a private key file used to securely connect to your instances. Decide where to place this file, and note the file path for later commands.
-
-For more details, see [Hardware Recommendations](recommended-production-settings.html#hardware) and [Cluster Topology](recommended-production-settings.html#topology).
-
-## Step 2. Configure your network
-
-[Add Custom TCP inbound rules](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) to your security group to allow TCP communication on two ports:
-
-- `26257` for inter-node and client-node communication. This enables the nodes to work as a cluster, the load balancer to route traffic to the nodes, and applications to connect to the load balancer.
-- `8080` for exposing the DB Console to the user, and for routing the load balancer to the health check endpoint.
-
-{% include {{ page.version.version }}/prod-deployment/aws-inbound-rules.md %}
-
-#### Load balancer-health check communication
-
- Field | Value
--------|-------------------
- Port Range | **8080**
- Source | The IP range of your VPC in CIDR notation (e.g., 10.12.0.0/16)
-
-To get the IP range of a VPC, open the [Amazon VPC console](https://console.aws.amazon.com/vpc/) and find the VPC listed in the section called Your VPCs.
-
-## Step 3. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 4. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-
-AWS offers fully-managed load balancing to distribute traffic between instances.
-
-1. [Add AWS load balancing](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/network-load-balancer-getting-started.html). Be sure to:
-	- Select a **Network Load Balancer** and use the ports we specify below.
-	- Select the VPC and *all* availability zones of your instances. This is important, as you cannot change the availability zones once the load balancer is created. The availability zone of an instance is determined by its subnet, found by inspecting the instance in the Amazon EC2 Console.
-	- Set the load balancer port to **26257**.
-    - Create a new target group that uses TCP port **26257**. Traffic from your load balancer is routed to this target group, which contains your instances.
-    - Configure health checks to use HTTP port **8080** and path `/health?ready=1`. This [health endpoint](monitoring-and-alerting.html#health-ready-1) ensures that load balancers do not direct traffic to nodes that are live but not ready to receive requests.
-    - Register your instances with the target group you created, specifying port **26257**. You can add and remove instances later.
-2. To test load balancing and connect your application to the cluster, you will need the provisioned internal (private) **IP address** for the load balancer. To find this, open the Network Interfaces section of the Amazon EC2 console and look up the load balancer by its name.
-
-{{site.data.alerts.callout_info}}If you would prefer to use HAProxy instead of AWS's managed load balancing, see the <a href="deploy-cockroachdb-on-premises.html">On-Premises</a> tutorial for guidance.{{site.data.alerts.end}}
-
-## Step 5. Generate certificates
-
-{% include {{ page.version.version }}/prod-deployment/secure-generate-certificates.md %}
-
-## Step 6. Start nodes
-
-{% include {{ page.version.version }}/prod-deployment/secure-start-nodes.md %}
-
-## Step 7. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-initialize-cluster.md %}
-
-## Step 8. Test your cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-cluster.md %}
-
-## Step 9. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-load-balancing.md %}
-
-## Step 10. Monitor the cluster
-
-In the Target Groups section of the Amazon EC2 console, [check the health](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-health-checks.html) of your instances by inspecting your target group and opening the Targets tab.
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 11. Scale the cluster
-
-Before adding a new node, [create a new instance](#step-1-create-instances) as you did earlier. Then [generate and upload a certificate and key](#step-5-generate-certificates) for the new node.
-
-{% include {{ page.version.version }}/prod-deployment/secure-scale-cluster.md %}
-
-## Step 12. Use the database
-
-{% include {{ page.version.version }}/prod-deployment/use-cluster.md %}
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-digital-ocean-insecure.md b/src/current/v20.2/deploy-cockroachdb-on-digital-ocean-insecure.md
deleted file mode 100644
index 3f7cec33365..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-digital-ocean-insecure.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Deploy CockroachDB on Digital Ocean (Insecure)
-summary: Learn how to deploy a CockroachDB cluster on Digital Ocean.
-toc: true
-toc_not_nested: true
-ssh-link: https://www.digitalocean.com/community/tutorials/how-to-connect-to-your-droplet-with-ssh
----
-
-<div class="filters filters-big clearfix">
-  <a href="deploy-cockroachdb-on-digital-ocean.html"><button class="filter-button">Secure</button>
-  <button class="filter-button current"><strong>Insecure</strong></button></a>
-</div>
-
-This page shows you how to deploy an insecure multi-node CockroachDB cluster on Digital Ocean, using Digital Ocean's managed load balancing service to distribute client traffic.
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/insecure-requirements.md %}
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/insecure-recommendations.md %}
-
-- If all of your CockroachDB nodes and clients will run on Droplets in a single region, consider using [private networking](https://docs.digitalocean.com/products/networking/vpc/how-to/create/).
-
-## Step 1. Create Droplets
-
-[Create Droplets](https://www.digitalocean.com/community/tutorials/how-to-create-your-first-digitalocean-droplet) for each node you plan to have in your cluster. If you plan to run a sample workload against the cluster, create a separate droplet for that workload.
-
-- Run at least 3 nodes to [ensure survivability](recommended-production-settings.html#topology).
-
-- Use any [droplets](https://www.digitalocean.com/pricing/) except standard droplets with only 1 GB of RAM, which is below our minimum requirement. All Digital Ocean droplets use SSD storage.
-
-For more details, see [Hardware Recommendations](recommended-production-settings.html#hardware) and [Cluster Topology](recommended-production-settings.html#topology).
-
-## Step 2. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 3. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-
-Digital Ocean offers fully-managed load balancers to distribute traffic between Droplets.
-
-1. [Create a Digital Ocean Load Balancer](https://www.digitalocean.com/community/tutorials/an-introduction-to-digitalocean-load-balancers). Be sure to:
-	- Set forwarding rules to route TCP traffic from the load balancer's port **26257** to port **26257** on the node Droplets.
-	- Configure health checks to use HTTP port **8080** and path `/health?ready=1`. This [health endpoint](monitoring-and-alerting.html#health-ready-1) ensures that load balancers do not direct traffic to nodes that are live but not ready to receive requests.
-2. Note the provisioned **IP Address** for the load balancer. You'll use this later to test load balancing and to connect your application to the cluster.
-
-{{site.data.alerts.callout_info}}If you would prefer to use HAProxy instead of Digital Ocean's managed load balancing, see the <a href="deploy-cockroachdb-on-premises-insecure.html">On-Premises</a> tutorial for guidance.{{site.data.alerts.end}}
-
-## Step 4. Configure your network
-
-Set up a firewall for each of your Droplets, allowing TCP communication on the following two ports:
-
-- **26257** (`tcp:26257`) for inter-node communication (i.e., working as a cluster), for applications to connect to the load balancer, and for routing from the load balancer to nodes
-- **8080** (`tcp:8080`) for exposing your DB Console
-
-For guidance, you can use Digital Ocean's guide to configuring firewalls based on the Droplet's OS:
-
-- Ubuntu and Debian can use [`ufw`](https://www.digitalocean.com/community/tutorials/how-to-setup-a-firewall-with-ufw-on-an-ubuntu-and-debian-cloud-server).
-- FreeBSD can use [`ipfw`](https://www.digitalocean.com/community/tutorials/recommended-steps-for-new-freebsd-10-1-servers).
-- Fedora can use [`iptables`](https://www.digitalocean.com/community/tutorials/initial-setup-of-a-fedora-22-server).
-- CoreOS can use [`iptables`](https://www.digitalocean.com/community/tutorials/how-to-secure-your-coreos-cluster-with-tls-ssl-and-firewall-rules).
-- CentOS can use [`firewalld`](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7).
-
-## Step 5. Start nodes
-
-{% include {{ page.version.version }}/prod-deployment/insecure-start-nodes.md %}
-
-## Step 6. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-initialize-cluster.md %}
-
-## Step 7. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-cluster.md %}
-
-## Step 8. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-load-balancing.md %}
-
-## Step 9. Monitor the cluster
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 10. Scale the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-scale-cluster.md %}
-
-## Step 11. Use the cluster
-
-Now that your deployment is working, you can:
-
-1. [Implement your data model](sql-statements.html).
-2. [Create users](authorization.html) and [grant them privileges](grant.html).
-3. [Connect your application](install-client-drivers.html). Be sure to connect your application to the Digital Ocean Load Balancer, not to a CockroachDB node.
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-digital-ocean.md b/src/current/v20.2/deploy-cockroachdb-on-digital-ocean.md
deleted file mode 100644
index f9d57ccef06..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-digital-ocean.md
+++ /dev/null
@@ -1,112 +0,0 @@
----
-title: Deploy CockroachDB on Digital Ocean
-summary: Learn how to deploy a CockroachDB cluster on Digital Ocean.
-toc: true
-toc_not_nested: true
-ssh-link: https://www.digitalocean.com/community/tutorials/how-to-connect-to-your-droplet-with-ssh
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Secure</strong></button>
-  <a href="deploy-cockroachdb-on-digital-ocean-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-This page shows you how to deploy a secure multi-node CockroachDB cluster on Digital Ocean, using Digital Ocean's managed load balancing service to distribute client traffic.
-
-If you are only testing CockroachDB, or you are not concerned with protecting network communication with TLS encryption, you can use an insecure cluster instead. Select **Insecure** above for instructions.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/secure-requirements.md %}
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/secure-recommendations.md %}
-
-- If all of your CockroachDB nodes and clients will run on Droplets in a single region, consider using [private networking](https://docs.digitalocean.com/products/networking/vpc/how-to/create/).
-
-## Step 1. Create Droplets
-
-[Create Droplets](https://www.digitalocean.com/community/tutorials/how-to-create-your-first-digitalocean-droplet) for each node you plan to have in your cluster. If you plan to run a sample workload against the cluster, create a separate Droplet for that workload.
-
-- Run at least 3 nodes to [ensure survivability](recommended-production-settings.html#topology).
-
-- Use any [droplets](https://www.digitalocean.com/pricing/) except standard droplets with only 1 GB of RAM, which is below our minimum requirement. All Digital Ocean droplets use SSD storage.
-
-For more details, see [Hardware Recommendations](recommended-production-settings.html#hardware) and [Cluster Topology](recommended-production-settings.html#topology).
-
-## Step 2. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 3. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-
-Digital Ocean offers fully-managed load balancers to distribute traffic between Droplets.
-
-1. [Create a Digital Ocean Load Balancer](https://www.digitalocean.com/community/tutorials/an-introduction-to-digitalocean-load-balancers). Be sure to:
-    - Set forwarding rules to route TCP traffic from the load balancer's port **26257** to port **26257** on the node Droplets.
-    - Configure health checks to use HTTP port **8080** and path `/health?ready=1`. This [health endpoint](monitoring-and-alerting.html#health-ready-1) ensures that load balancers do not direct traffic to nodes that are live but not ready to receive requests.
-2. Note the provisioned **IP Address** for the load balancer. You'll use this later to test load balancing and to connect your application to the cluster.
-
-{{site.data.alerts.callout_info}}If you would prefer to use HAProxy instead of Digital Ocean's managed load balancing, see the <a href="deploy-cockroachdb-on-premises.html">On-Premises</a> tutorial for guidance.{{site.data.alerts.end}}
-
-## Step 4. Configure your network
-
-Set up a firewall for each of your Droplets, allowing TCP communication on the following two ports:
-
-- **26257** (`tcp:26257`) for inter-node communication (i.e., working as a cluster), for applications to connect to the load balancer, and for routing from the load balancer to nodes
-- **8080** (`tcp:8080`) for exposing your DB Console
-
-For guidance, you can use Digital Ocean's guide to configuring firewalls based on the Droplet's OS:
-
-- Ubuntu and Debian can use [`ufw`](https://www.digitalocean.com/community/tutorials/how-to-setup-a-firewall-with-ufw-on-an-ubuntu-and-debian-cloud-server).
-- FreeBSD can use [`ipfw`](https://www.digitalocean.com/community/tutorials/recommended-steps-for-new-freebsd-10-1-servers).
-- Fedora can use [`iptables`](https://www.digitalocean.com/community/tutorials/initial-setup-of-a-fedora-22-server).
-- CoreOS can use [`iptables`](https://www.digitalocean.com/community/tutorials/how-to-secure-your-coreos-cluster-with-tls-ssl-and-firewall-rules).
-- CentOS can use [`firewalld`](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7).
-
-## Step 5. Generate certificates
-
-{% include {{ page.version.version }}/prod-deployment/secure-generate-certificates.md %}
-
-## Step 6. Start nodes
-
-{% include {{ page.version.version }}/prod-deployment/secure-start-nodes.md %}
-
-## Step 7. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-initialize-cluster.md %}
-
-## Step 8. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-cluster.md %}
-
-## Step 9. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-load-balancing.md %}
-
-## Step 10. Monitor the cluster
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 11. Scale the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-scale-cluster.md %}
-
-## Step 12. Use the database
-
-{% include {{ page.version.version }}/prod-deployment/use-cluster.md %}
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-google-cloud-platform-insecure.md b/src/current/v20.2/deploy-cockroachdb-on-google-cloud-platform-insecure.md
deleted file mode 100644
index 4f6ee59df2b..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-google-cloud-platform-insecure.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: Deploy CockroachDB on Google Cloud Platform GCE (Insecure)
-summary: Learn how to deploy CockroachDB on Google Cloud Platform's Compute Engine.
-toc: true
-toc_not_nested: true
-ssh-link: https://cloud.google.com/compute/docs/instances/connecting-to-instance
----
-
-<div class="filters filters-big clearfix">
-  <a href="deploy-cockroachdb-on-google-cloud-platform.html"><button class="filter-button">Secure</button>
-  <button class="filter-button current"><strong>Insecure</strong></button></a>
-</div>
-
-This page shows you how to manually deploy an insecure multi-node CockroachDB cluster on Google Cloud Platform's Compute Engine (GCE), using Google's TCP Proxy Load Balancing service to distribute client traffic.
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/insecure-requirements.md %}
-
-- This article covers the use of Linux instances with GCE. You may wish to review the instructions for [connecting to Windows instances](https://cloud.google.com/compute/docs/instances/connecting-to-instance#windows).
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/insecure-recommendations.md %}
-
-## Step 1. Configure your network
-
-CockroachDB requires TCP communication on two ports:
-
-- `26257` for inter-node communication (i.e., working as a cluster)
-- `8080` for exposing your DB Console
-
-To expose your DB Console and allow traffic from the TCP proxy load balancer and health checker to your instances, [create firewall rules](https://cloud.google.com/compute/docs/vpc/firewalls) for your project. When creating firewall rules, we recommend using Google Cloud Platform's **tag** feature to apply the rule only to instances with the same tag.
-
-#### DB Console
-
- Field | Recommended Value
--------|-------------------
- Name | **cockroachadmin**
- Source filter | IP ranges
- Source IP ranges | Your local network's IP ranges
- Allowed protocols... | **tcp:8080**
- Target tags | **cockroachdb**
-
-#### Application data
-
-Applications will not connect directly to your CockroachDB nodes. Instead, they'll connect to GCE's TCP Proxy Load Balancing service, which automatically routes traffic to the instances that are closest to the user. Because this service is implemented at the edge of the Google Cloud, you'll need to create a firewall rule to allow traffic from the load balancer and health checker to your instances. This is covered in [Step 4](#step-4-set-up-load-balancing).
-
-## Step 2. Create instances
-
-[Create an instance](https://cloud.google.com/compute/docs/instances/create-start-instance) for each node you plan to have in your cluster. If you plan to run a sample workload against the cluster, create a separate instance for that workload.
-
-- Run at least 3 nodes to [ensure survivability](recommended-production-settings.html#topology).
-
-- Use `n2-standard` or `n2-highcpu` [predefined VMs](https://cloud.google.com/compute/pricing#predefined_machine_types), or [custom VMs](https://cloud.google.com/compute/pricing#custommachinetypepricing), with [Local SSDs](https://cloud.google.com/compute/docs/disks/#localssds) or [SSD persistent disks](https://cloud.google.com/compute/docs/disks/#pdspecs). For example, Cockroach Labs has used `n2-standard-16` (16 vCPUs and 64 GiB of RAM per VM, local SSD) for internal testing.
-
-- **Do not** use `f1` or `g1` [shared-core machines](https://cloud.google.com/compute/docs/machine-types#sharedcore), which limit the load on a single core.
-
-- If you used a tag for your firewall rules, when you create the instance, click **Management, security, disks, networking, sole tenancy**. Under the **Networking** tab, in the **Network tags** field, enter **cockroachdb**.
-
-For more details, see [Hardware Recommendations](recommended-production-settings.html#hardware) and [Cluster Topology](recommended-production-settings.html#topology).
-
-## Step 3. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 4. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-
-GCE offers fully-managed [TCP Proxy Load Balancing](https://cloud.google.com/load-balancing/docs/tcp/). This service lets you use a single IP address for all users around the world, automatically routing traffic to the instances that are closest to the user.
-
-{{site.data.alerts.callout_danger}}
-When using TCP Proxy Load Balancing, you cannot use firewall rules to control access to the load balancer. If you need such control, consider using [Network TCP Load Balancing](https://cloud.google.com/compute/docs/load-balancing/network/) instead, but note that it cannot be used across regions. You might also consider using the HAProxy load balancer (see the [On-Premises](deploy-cockroachdb-on-premises-insecure.html) tutorial for guidance).
-{{site.data.alerts.end}}
-
-To use GCE's TCP Proxy Load Balancing service:
-
-1. For each zone in which you're running an instance, [create a distinct instance group](https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-unmanaged-instances).
-    - To ensure that the load balancer knows where to direct traffic, specify a port name mapping, with `tcp26257` as the **Port name** and `26257` as the **Port number**.
-2. [Add the relevant instances to each instance group](https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-unmanaged-instances#addinstances).
-3. [Configure Proxy Load Balancing](https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#configure_load_balancer).
-    - During backend configuration, create a health check, setting the **Protocol** to `HTTP`, the **Port** to `8080`, and the **Request path** to path `/health?ready=1`. This [health endpoint](monitoring-and-alerting.html#health-ready-1) ensures that load balancers do not direct traffic to nodes that are live but not ready to receive requests.
-        - If you want to maintain long-lived SQL connections that may be idle for more than tens of seconds, increase the backend timeout setting accordingly.
-    - During frontend configuration, reserve a static IP address and choose a port. Note this address/port combination, as you'll use it for all of you client connections.
-4. [Create a firewall rule](https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#config-hc-firewall) to allow traffic from the load balancer and health checker to your instances. This is necessary because TCP Proxy Load Balancing is implemented at the edge of the Google Cloud.
-    - Be sure to set **Source IP ranges** to `130.211.0.0/22` and `35.191.0.0/16` and set **Target tags** to `cockroachdb` (not to the value specified in the linked instructions).
-
-## Step 5. Start nodes
-
-{{site.data.alerts.callout_info}}
-By default, inter-node communication uses the internal IP addresses of your GCE instances.
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/prod-deployment/insecure-start-nodes.md %}
-
-## Step 6. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-initialize-cluster.md %}
-
-## Step 7. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-cluster.md %}
-
-## Step 8. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-load-balancing.md %}
-
-## Step 9. Monitor the cluster
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 10. Scale the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-scale-cluster.md %}
-
-## Step 11. Use the cluster
-
-Now that your deployment is working, you can:
-
-1. [Implement your data model](sql-statements.html).
-2. [Create users](create-user.html) and [grant them privileges](grant.html).
-3. [Connect your application](install-client-drivers.html). Be sure to connect your application to the GCE load balancer, not to a CockroachDB node.
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-google-cloud-platform.md b/src/current/v20.2/deploy-cockroachdb-on-google-cloud-platform.md
deleted file mode 100644
index 7e298df3aa5..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-google-cloud-platform.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: Deploy CockroachDB on Google Cloud Platform GCE
-summary: Learn how to deploy CockroachDB on Google Cloud Platform's Compute Engine.
-toc: true
-toc_not_nested: true
-ssh-link: https://cloud.google.com/compute/docs/instances/connecting-to-instance
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Secure</strong></button>
-  <a href="deploy-cockroachdb-on-google-cloud-platform-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-This page shows you how to manually deploy a secure multi-node CockroachDB cluster on Google Cloud Platform's Compute Engine (GCE), using Google's TCP Proxy Load Balancing service to distribute client traffic.
-
-If you are only testing CockroachDB, or you are not concerned with protecting network communication with TLS encryption, you can use an insecure cluster instead. Select **Insecure** above for instructions.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/secure-requirements.md %}
-
-- This article covers the use of Linux instances with GCE. You may wish to review the instructions for [connecting to Windows instances](https://cloud.google.com/compute/docs/instances/connecting-to-instance#windows).
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/secure-recommendations.md %}
-
-## Step 1. Configure your network
-
-CockroachDB requires TCP communication on two ports:
-
-- `26257` for inter-node communication (i.e., working as a cluster)
-- `8080` for exposing your DB Console
-
-To expose your DB Console and allow traffic from the TCP proxy load balancer and health checker to your instances, [create firewall rules](https://cloud.google.com/compute/docs/vpc/firewalls) for your project. When creating firewall rules, we recommend using Google Cloud Platform's **tag** feature to apply the rule only to instances with the same tag.
-
-#### DB Console
-
- Field | Recommended Value
--------|-------------------
- Name | **cockroachadmin**
- Source filter | IP ranges
- Source IP ranges | Your local network's IP ranges
- Allowed protocols... | **tcp:8080**
- Target tags | **cockroachdb**
-
-#### Application data
-
-Applications will not connect directly to your CockroachDB nodes. Instead, they'll connect to GCE's TCP Proxy Load Balancing service, which automatically routes traffic to the instances that are closest to the user. Because this service is implemented at the edge of the Google Cloud, you'll need to create a firewall rule to allow traffic from the load balancer and health checker to your instances. This is covered in [Step 4](#step-4-set-up-load-balancing).
-
-## Step 2. Create instances
-
-[Create an instance](https://cloud.google.com/compute/docs/instances/create-start-instance) for each node you plan to have in your cluster. If you plan to run a sample workload against the cluster, create a separate instance for that workload.
-
-- Run at least 3 nodes to [ensure survivability](recommended-production-settings.html#topology).
-
-- Use `n2-standard` or `n2-highcpu` [predefined VMs](https://cloud.google.com/compute/pricing#predefined_machine_types), or [custom VMs](https://cloud.google.com/compute/pricing#custommachinetypepricing), with [Local SSDs](https://cloud.google.com/compute/docs/disks/#localssds) or [SSD persistent disks](https://cloud.google.com/compute/docs/disks/#pdspecs). For example, Cockroach Labs has used `n2-standard-16` (16 vCPUs and 64 GiB of RAM per VM, local SSD) for internal testing.
-
-- **Do not** use `f1` or `g1` [shared-core machines](https://cloud.google.com/compute/docs/machine-types#sharedcore), which limit the load on a single core.
-
-- If you used a tag for your firewall rules, when you create the instance, click **Management, security, disks, networking, sole tenancy**. Under the **Networking** tab, in the **Network tags** field, enter **cockroachdb**.
-
-For more details, see [Hardware Recommendations](recommended-production-settings.html#hardware) and [Cluster Topology](recommended-production-settings.html#topology).
-
-## Step 3. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 4. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-
-GCE offers fully-managed [TCP Proxy Load Balancing](https://cloud.google.com/load-balancing/docs/tcp/). This service lets you use a single IP address for all users around the world, automatically routing traffic to the instances that are closest to the user.
-
-{{site.data.alerts.callout_danger}}
-When using TCP Proxy Load Balancing, you cannot use firewall rules to control access to the load balancer. If you need such control, consider using [Network TCP Load Balancing](https://cloud.google.com/compute/docs/load-balancing/network/) instead, but note that it cannot be used across regions. You might also consider using the HAProxy load balancer (see the [On-Premises](deploy-cockroachdb-on-premises.html) tutorial for guidance).
-{{site.data.alerts.end}}
-
-To use GCE's TCP Proxy Load Balancing service:
-
-1. For each zone in which you're running an instance, [create a distinct instance group](https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-unmanaged-instances).
-    - To ensure that the load balancer knows where to direct traffic, specify a port name mapping, with `tcp26257` as the **Port name** and `26257` as the **Port number**.
-2. [Add the relevant instances to each instance group](https://cloud.google.com/compute/docs/instance-groups/creating-groups-of-unmanaged-instances#addinstances).
-3. [Configure TCP Proxy Load Balancing](https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#configure_load_balancer).
-    - During backend configuration, create a health check, setting the **Protocol** to `HTTPS`, the **Port** to `8080`, and the **Request path** to path `/health?ready=1`. This [health endpoint](monitoring-and-alerting.html#health-ready-1) ensures that load balancers do not direct traffic to nodes that are live but not ready to receive requests.
-        - If you want to maintain long-lived SQL connections that may be idle for more than tens of seconds, increase the backend timeout setting accordingly.
-    - During frontend configuration, reserve a static IP address and note the IP address and the port you select. You'll use this address and port for all client connections.
-4. [Create a firewall rule](https://cloud.google.com/load-balancing/docs/tcp/setting-up-tcp#config-hc-firewall) to allow traffic from the load balancer and health checker to your instances. This is necessary because TCP Proxy Load Balancing is implemented at the edge of the Google Cloud.
-    - Be sure to set **Source IP ranges** to `130.211.0.0/22` and `35.191.0.0/16` and set **Target tags** to `cockroachdb` (not to the value specified in the linked instructions).
-
-## Step 5. Generate certificates
-
-{% include {{ page.version.version }}/prod-deployment/secure-generate-certificates.md %}
-
-## Step 6. Start nodes
-
-{{site.data.alerts.callout_info}}
-By default, inter-node communication uses the internal IP addresses of your GCE instances.
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/prod-deployment/secure-start-nodes.md %}
-
-## Step 7. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-initialize-cluster.md %}
-
-## Step 8. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-cluster.md %}
-
-## Step 9. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-load-balancing.md %}
-
-## Step 10. Monitor the cluster
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 11. Scale the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-scale-cluster.md %}
-
-## Step 12. Use the database
-
-{% include {{ page.version.version }}/prod-deployment/use-cluster.md %}
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-microsoft-azure-insecure.md b/src/current/v20.2/deploy-cockroachdb-on-microsoft-azure-insecure.md
deleted file mode 100644
index ef975976f1d..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-microsoft-azure-insecure.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: Deploy CockroachDB on Microsoft Azure (Insecure)
-summary: Learn how to deploy CockroachDB on Microsoft Azure.
-toc: true
-toc_not_nested: true
-ssh-link: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mac-create-ssh-keys
----
-
-<div class="filters filters-big clearfix">
-  <a href="deploy-cockroachdb-on-microsoft-azure.html"><button class="filter-button">Secure</button>
-  <button class="filter-button current"><strong>Insecure</strong></button></a>
-</div>
-
-This page shows you how to manually deploy an insecure multi-node CockroachDB cluster on Microsoft Azure, using Azure's managed load balancing service to distribute client traffic.
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/insecure-requirements.md %}
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/insecure-recommendations.md %}
-
-## Step 1. Configure your network
-
-CockroachDB requires TCP communication on two ports:
-
-- **26257** (`tcp:26257`) for inter-node communication (i.e., working as a cluster), for applications to connect to the load balancer, and for routing from the load balancer to nodes
-- **8080** (`tcp:8080`) for exposing your DB Console
-
-To enable this in Azure, you must create a Resource Group, Virtual Network, and Network Security Group.
-
-1. [Create a Resource Group](https://azure.microsoft.com/en-us/updates/create-empty-resource-groups/).
-
-2. [Create a Virtual Network](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-create-vnet-arm-pportal) that uses your **Resource Group**.
-
-3. [Create a Network Security Group](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-create-nsg-arm-pportal) that uses your **Resource Group**, and then add the following **inbound** rules to it:
-    - **DB Console support**:
-
-         Field | Recommended Value
-        -------|-------------------
-         Name | **cockroachadmin**
-         Source | **IP Addresses**
-         Source IP addresses/CIDR ranges | Your local network’s IP ranges
-         Source port ranges | *
-         Destination | **Any**
-         Destination port range | **8080**
-         Protocol | **TCP**
-         Action | **Allow**
-         Priority | Any value > 1000
-    - **Application support**:
-
-        {{site.data.alerts.callout_success}}If your application is also hosted on the same Azure     Virtual Network, you will not need to create a firewall rule for your application to communicate     with your load balancer.{{site.data.alerts.end}}
-
-         Field | Recommended Value
-        -------|-------------------
-         Name | **cockroachapp**
-         Source | **IP Addresses**
-         Source IP addresses/CIDR ranges | Your local network’s IP ranges
-         Source port ranges | *
-         Destination | **Any**
-         Destination port range | **26257**
-         Protocol | **TCP**
-         Action | **Allow**
-         Priority | Any value > 1000
-
-
-## Step 2. Create VMs
-
-[Create Linux VMs](https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/quick-create-portal) for each node you plan to have in your cluster. If you plan to run a sample workload against the cluster, create a separate VM for that workload.
-
-- Run at least 3 nodes to [ensure survivability](recommended-production-settings.html#topology).
-
-- Use compute-optimized [F-series](https://docs.microsoft.com/en-us/azure/virtual-machines/fsv2-series) VMs with [Premium Storage](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/premium-storage) or local SSD storage with a Linux filesystem such as `ext4` (not the Windows `ntfs` filesystem). For example, Cockroach Labs has used `Standard_F16s_v2` VMs (16 vCPUs and 32 GiB of RAM per VM) for internal testing.
-
-    - If you choose local SSD storage, on reboot, the VM can come back with the `ntfs` filesystem. Be sure your automation monitors for this and reformats the disk to the Linux filesystem you chose initially.
-
-- **Do not** use ["burstable" B-series](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/b-series-burstable) VMs, which limit the load on a single core. Also, Cockroach Labs has experienced data corruption issues on A-series VMs and irregular disk performance on D-series VMs, so we recommend avoiding those as well.
-
-- When creating the VMs, make sure to select the **Resource Group**, **Virtual Network**, and **Network Security Group** you created.
-
-For more details, see [Hardware Recommendations](recommended-production-settings.html#hardware) and [Cluster Topology](recommended-production-settings.html#topology).
-
-## Step 3. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 4. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-
-Microsoft Azure offers fully-managed load balancing to distribute traffic between instances.
-
-1. [Add Azure load balancing](https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview). Be sure to:
-    - Set forwarding rules to route TCP traffic from the load balancer's port **26257** to port **26257** on the nodes.
-    - Configure health checks to use HTTP port **8080** and path `/health?ready=1`. This [health endpoint](monitoring-and-alerting.html#health-ready-1) ensures that load balancers do not direct traffic to nodes that are live but not ready to receive requests.
-
-2. Note the provisioned **IP Address** for the load balancer. You'll use this later to test load balancing and to connect your application to the cluster.
-
-{{site.data.alerts.callout_info}}If you would prefer to use HAProxy instead of Azure's managed load balancing, see the <a href="deploy-cockroachdb-on-premises-insecure.html">On-Premises</a> tutorial for guidance.{{site.data.alerts.end}}
-
-## Step 5. Start nodes
-
-{% include {{ page.version.version }}/prod-deployment/insecure-start-nodes.md %}
-
-## Step 6. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-initialize-cluster.md %}
-
-## Step 7. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-cluster.md %}
-
-## Step 8. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-load-balancing.md %}
-
-## Step 9. Monitor the cluster
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 10. Scale the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-scale-cluster.md %}
-
-## Step 11. Use the cluster
-
-Now that your deployment is working, you can:
-
-1. [Implement your data model](sql-statements.html).
-2. [Create users](create-user.html) and [grant them privileges](grant.html).
-3. [Connect your application](install-client-drivers.html). Be sure to connect your application to the Azure load balancer, not to a CockroachDB node.
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-microsoft-azure.md b/src/current/v20.2/deploy-cockroachdb-on-microsoft-azure.md
deleted file mode 100644
index c1f89fc019f..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-microsoft-azure.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: Deploy CockroachDB on Microsoft Azure
-summary: Learn how to deploy CockroachDB on Microsoft Azure.
-toc: true
-toc_not_nested: true
-ssh-link: https://docs.microsoft.com/en-us/azure/virtual-machines/linux/mac-create-ssh-keys
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Secure</strong></button>
-  <a href="deploy-cockroachdb-on-microsoft-azure-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-This page shows you how to manually deploy a secure multi-node CockroachDB cluster on Microsoft Azure, using Azure's managed load balancing service to distribute client traffic.
-
-If you are only testing CockroachDB, or you are not concerned with protecting network communication with TLS encryption, you can use an insecure cluster instead. Select **Insecure** above for instructions.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/secure-requirements.md %}
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/secure-recommendations.md %}
-
-## Step 1. Configure your network
-
-CockroachDB requires TCP communication on two ports:
-
-- **26257** (`tcp:26257`) for inter-node communication (i.e., working as a cluster), for applications to connect to the load balancer, and for routing from the load balancer to nodes
-- **8080** (`tcp:8080`) for exposing your DB Console
-
-To enable this in Azure, you must create a Resource Group, Virtual Network, and Network Security Group.
-
-1. [Create a Resource Group](https://azure.microsoft.com/en-us/updates/create-empty-resource-groups/).
-2. [Create a Virtual Network](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-create-vnet-arm-pportal) that uses your **Resource Group**.
-3. [Create a Network Security Group](https://docs.microsoft.com/en-us/azure/virtual-network/virtual-networks-create-nsg-arm-pportal) that uses your **Resource Group**, and then add the following **inbound** rules to it:
-    - **DB Console support**:
-
-         Field | Recommended Value
-        -------|-------------------
-         Name | **cockroachadmin**
-         Source | **IP Addresses**
-         Source IP addresses/CIDR ranges | Your local network’s IP ranges
-         Source port ranges | *
-         Destination | **Any**
-         Destination port range | **8080**
-         Protocol | **TCP**
-         Action | **Allow**
-         Priority | Any value > 1000
-    - **Application support**:
-
-        {{site.data.alerts.callout_success}}If your application is also hosted on the same Azure     Virtual Network, you will not need to create a firewall rule for your application to communicate     with your load balancer.{{site.data.alerts.end}}
-
-         Field | Recommended Value
-        -------|-------------------
-         Name | **cockroachapp**
-         Source | **IP Addresses**
-         Source IP addresses/CIDR ranges | Your local network’s IP ranges
-         Source port ranges | *
-         Destination | **Any**
-         Destination port range | **26257**
-         Protocol | **TCP**
-         Action | **Allow**
-         Priority | Any value > 1000
-
-## Step 2. Create VMs
-
-[Create Linux VMs](https://docs.microsoft.com/en-us/azure/virtual-machine-scale-sets/quick-create-portal) for each node you plan to have in your cluster. If you plan to run a sample workload against the cluster, create a separate VM for that workload.
-
-- Run at least 3 nodes to [ensure survivability](recommended-production-settings.html#topology).
-
-- Use compute-optimized [F-series](https://docs.microsoft.com/en-us/azure/virtual-machines/fsv2-series) VMs with [Premium Storage](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/premium-storage) or local SSD storage with a Linux filesystem such as `ext4` (not the Windows `ntfs` filesystem). For example, Cockroach Labs has used `Standard_F16s_v2` VMs (16 vCPUs and 32 GiB of RAM per VM) for internal testing.
-
-    - If you choose local SSD storage, on reboot, the VM can come back with the `ntfs` filesystem. Be sure your automation monitors for this and reformats the disk to the Linux filesystem you chose initially.
-
-- **Do not** use ["burstable" B-series](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/b-series-burstable) VMs, which limit the load on a single core. Also, Cockroach Labs has experienced data corruption issues on A-series VMs and irregular disk performance on D-series VMs, so we recommend avoiding those as well.
-
-- When creating the VMs, make sure to select the **Resource Group**, **Virtual Network**, and **Network Security Group** you created.
-
-For more details, see [Hardware Recommendations](recommended-production-settings.html#hardware) and [Cluster Topology](recommended-production-settings.html#topology).
-
-## Step 3. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 4. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-
-Microsoft Azure offers fully-managed load balancing to distribute traffic between instances.
-
-1.  [Add Azure load balancing](https://docs.microsoft.com/en-us/azure/load-balancer/load-balancer-overview). Be sure to:
-  - Set forwarding rules to route TCP traffic from the load balancer's port **26257** to port **26257** on the nodes.
-  - Configure health checks to use HTTP port **8080** and path `/health?ready=1`. This [health endpoint](monitoring-and-alerting.html#health-ready-1) ensures that load balancers do not direct traffic to nodes that are live but not ready to receive requests.
-
-2.  Note the provisioned **IP Address** for the load balancer. You'll use this later to test load balancing and to connect your application to the cluster.
-
-{{site.data.alerts.callout_info}}If you would prefer to use HAProxy instead of Azure's managed load balancing, see the <a href="deploy-cockroachdb-on-premises.html">On-Premises</a> tutorial for guidance.{{site.data.alerts.end}}
-
-## Step 5. Generate certificates
-
-{% include {{ page.version.version }}/prod-deployment/secure-generate-certificates.md %}
-
-## Step 6. Start nodes
-
-{% include {{ page.version.version }}/prod-deployment/secure-start-nodes.md %}
-
-## Step 7. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-initialize-cluster.md %}
-
-## Step 8. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-cluster.md %}
-
-## Step 9. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-load-balancing.md %}
-
-## Step 10. Monitor the cluster
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 11. Scale the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-scale-cluster.md %}
-
-## Step 12. Use the database
-
-{% include {{ page.version.version }}/prod-deployment/use-cluster.md %}
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-premises-insecure.md b/src/current/v20.2/deploy-cockroachdb-on-premises-insecure.md
deleted file mode 100644
index 74e0b348aa9..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-premises-insecure.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: Deploy CockroachDB On-Premises (Insecure)
-summary: Learn how to manually deploy an insecure, multi-node CockroachDB cluster on multiple machines.
-toc: true
-ssh-link: https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2
----
-
-<div class="filters filters-big clearfix">
-  <a href="deploy-cockroachdb-on-premises.html"><button class="filter-button">Secure</button></a>
-  <a href="deploy-cockroachdb-on-premises-insecure.html"><button class="filter-button current"><strong>Insecure</strong></button></a>
-</div>
-
-This tutorial shows you how to manually deploy an insecure multi-node CockroachDB cluster on multiple machines, using [HAProxy](http://www.haproxy.org/) load balancers to distribute client traffic.
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/insecure-requirements.md %}
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/insecure-recommendations.md %}
-
-## Step 1. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 2. Start nodes
-
-{% include {{ page.version.version }}/prod-deployment/insecure-start-nodes.md %}
-
-## Step 3. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-initialize-cluster.md %}
-
-## Step 4. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-cluster.md %}
-
-## Step 5. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-  {{site.data.alerts.callout_success}}With a single load balancer, client connections are resilient to node failure, but the load balancer itself is a point of failure. It's therefore best to make load balancing resilient as well by using multiple load balancing instances, with a mechanism like floating IPs or DNS to select load balancers for clients.{{site.data.alerts.end}}
-
-[HAProxy](http://www.haproxy.org/) is one of the most popular open-source TCP load balancers, and CockroachDB includes a built-in command for generating a configuration file that is preset to work with your running cluster, so we feature that tool here.
-
-1. SSH to the machine where you want to run HAProxy.
-
-2. Install HAProxy:
-
-  {% include copy-clipboard.html %}
-  ~~~ shell
-  $ apt-get install haproxy
-  ~~~
-
-3. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, and extract the binary:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-4. Copy the binary into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-  If you get a permissions error, prefix the command with `sudo`.
-
-5. Run the [`cockroach gen haproxy`](cockroach-gen.html) command, specifying the address of any CockroachDB node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach gen haproxy --insecure \
-    --host=<address of any node> \
-    --port=26257
-    ~~~
-
-      {% include {{ page.version.version }}/misc/haproxy.md %}
-
-6. Start HAProxy, with the `-f` flag pointing to the `haproxy.cfg` file:
-
-  {% include copy-clipboard.html %}
-  ~~~ shell
-  $ haproxy -f haproxy.cfg
-  ~~~
-
-7. Repeat these steps for each additional instance of HAProxy you want to run.
-
-## Step 6. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/insecure-test-load-balancing.md %}
-
-## Step 7. Monitor the cluster
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 8. Scale the cluster
-
-{% include {{ page.version.version }}/prod-deployment/insecure-scale-cluster.md %}
-
-## Step 9. Use the cluster
-
-{% include {{ page.version.version }}/prod-deployment/use-cluster.md %}
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/deploy-cockroachdb-on-premises.md b/src/current/v20.2/deploy-cockroachdb-on-premises.md
deleted file mode 100644
index 94bf1c96c08..00000000000
--- a/src/current/v20.2/deploy-cockroachdb-on-premises.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: Deploy CockroachDB On-Premises
-summary: Learn how to manually deploy a secure, multi-node CockroachDB cluster on multiple machines.
-toc: true
-ssh-link: https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys--2
-
----
-
-<div class="filters filters-big clearfix">
-  <a href="deploy-cockroachdb-on-premises.html"><button class="filter-button current"><strong>Secure</strong></button></a>
-  <a href="deploy-cockroachdb-on-premises-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-This tutorial shows you how to manually deploy a secure multi-node CockroachDB cluster on multiple machines, using [HAProxy](http://www.haproxy.org/) load balancers to distribute client traffic.
-
-If you are only testing CockroachDB, or you are not concerned with protecting network communication with TLS encryption, you can use an insecure cluster instead. Select **Insecure** above for instructions.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-### Requirements
-
-{% include {{ page.version.version }}/prod-deployment/secure-requirements.md %}
-
-### Recommendations
-
-{% include {{ page.version.version }}/prod-deployment/secure-recommendations.md %}
-
-## Step 1. Synchronize clocks
-
-{% include {{ page.version.version }}/prod-deployment/synchronize-clocks.md %}
-
-## Step 2. Generate certificates
-
-{% include {{ page.version.version }}/prod-deployment/secure-generate-certificates.md %}
-
-## Step 3. Start nodes
-
-{% include {{ page.version.version }}/prod-deployment/secure-start-nodes.md %}
-
-## Step 4. Initialize the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-initialize-cluster.md %}
-
-## Step 5. Test the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-cluster.md %}
-
-## Step 6. Set up load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to your cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. In cases where a node fails, the load balancer redirects client traffic to available nodes.
-  {{site.data.alerts.callout_success}}With a single load balancer, client connections are resilient to node failure, but the load balancer itself is a point of failure. It's therefore best to make load balancing resilient as well by using multiple load balancing instances, with a mechanism like floating IPs or DNS to select load balancers for clients.{{site.data.alerts.end}}
-
-[HAProxy](http://www.haproxy.org/) is one of the most popular open-source TCP load balancers, and CockroachDB includes a built-in command for generating a configuration file that is preset to work with your running cluster, so we feature that tool here.
-
-1. On your local machine, run the [`cockroach gen haproxy`](cockroach-gen.html) command with the `--host` flag set to the address of any node and security flags pointing to the CA cert and the client cert and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach gen haproxy \
-    --certs-dir=certs \
-    --host=<address of any node>
-    ~~~
-
-      {% include {{ page.version.version }}/misc/haproxy.md %}
-
-2. Upload the `haproxy.cfg` file to the machine where you want to run HAProxy:
-
-  {% include copy-clipboard.html %}
-  ~~~ shell
-  $ scp haproxy.cfg <username>@<haproxy address>:~/
-  ~~~
-
-3. SSH to the machine where you want to run HAProxy.
-
-4. Install HAProxy:
-
-  {% include copy-clipboard.html %}
-  ~~~ shell
-  $ apt-get install haproxy
-  ~~~
-
-5. Start HAProxy, with the `-f` flag pointing to the `haproxy.cfg` file:
-
-  {% include copy-clipboard.html %}
-  ~~~ shell
-  $ haproxy -f haproxy.cfg
-  ~~~
-
-6. Repeat these steps for each additional instance of HAProxy you want to run.
-
-## Step 7. Run a sample workload
-
-{% include {{ page.version.version }}/prod-deployment/secure-test-load-balancing.md %}
-
-## Step 8. Monitor the cluster
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Step 9. Scale the cluster
-
-{% include {{ page.version.version }}/prod-deployment/secure-scale-cluster.md %}
-
-## Step 10. Use the cluster
-
-{% include {{ page.version.version }}/prod-deployment/use-cluster.md %}
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/developer-guide-overview.md b/src/current/v20.2/developer-guide-overview.md
deleted file mode 100644
index 5cce9854df6..00000000000
--- a/src/current/v20.2/developer-guide-overview.md
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: Developer Guide Overview
-summary: An overview of common tasks that come up when you build an application using CockroachDB
-toc: true
----
-
-This guide shows you how to develop an application on CockroachDB. After reading this page, we recommend [starting a CockroachDB cluster](secure-a-cluster.html), and then [installing a client library](install-client-drivers.html).
-
-## Guide contents
-
-- [Overview](#cockroachdb-basics)
-- [Connect to a Cluster](install-client-drivers.html)
-- [Design a Schema](schema-design-overview.html)
-- [Write Data](insert-data.html)
-- [Read Data](query-data.html)
-- [Debug Your Application](debug-and-error-logs.html)
-- [Optimize Performance](make-queries-fast.html)
-
-## CockroachDB basics
-
-Before you start using CockroachDB, you should understand a couple important mechanics of the database:
-
-- [Guide contents](#guide-contents)
-- [CockroachDB basics](#cockroachdb-basics)
-  - [How transactions work in CockroachDB](#how-transactions-work-in-cockroachdb)
-    - [Serializability and transaction contention](#serializability-and-transaction-contention)
-    - [Transaction retries](#transaction-retries)
-  - [How applications interact with CockroachDB](#how-applications-interact-with-cockroachdb)
-- [What's next?](#whats-next)
-
-Note that the sections that follow were written for the purposes of orienting application developers. For more detailed technical documentation on CockroachDB's architecture, see our [architecture documentation](architecture/overview.html).
-
-### How transactions work in CockroachDB
-
-CockroachDB is designed to make your data scalable and consistent. All stored records are replicated across a distributed deployment of database instances, and all database transactions committed in CockroachDB satisfy [ACID properties](https://en.wikipedia.org/wiki/ACID) and the [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem). This means that when you store data in CockroachDB, the data will be valid and anomaly-free, even in the event of a system error or power failure.
-
-To guarantee that database operations are [atomic](https://en.wikipedia.org/wiki/Atomicity_(database_systems)) (the "A" of the [ACID properties](https://en.wikipedia.org/wiki/ACID)), CockroachDB executes all statements in the context of an atomic [database transaction](https://en.wikipedia.org/wiki/Database_transaction). If a transaction succeeds, all data mutations are applied together simultaneously from the perspective of operations outside of the transaction. If any part of a transaction fails, the entire transaction is aborted, and the database is left unchanged.
-
-Managing transactions is an important part of CockroachDB application development. When creating your application's persistence layer, you must understand how CockroachDB interacts with your application framework's transaction management system. You should also have some knowledge of CockroachDB's [transaction syntax](transactions.html#syntax). We go into more detail about transaction management in [Manage Transactions](transactions.html).
-
-#### Serializability and transaction contention
-
-CockroachDB guarantees [`SERIALIZABLE`](https://en.wikipedia.org/wiki/Serializability) transaction [isolation](https://en.wikipedia.org/wiki/Isolation_(database_systems)) (the "I" of ACID semantics). If transactions are executed concurrently, the final state of the database will appear as if the transactions were executed serially. `SERIALIZABLE` isolation, the strictest level of isolation, provides the highest level of data consistency and protects against concurrency-based attacks and bugs.
-
-To guarantee `SERIALIZABLE` isolation, CockroachDB locks the data targeted by an open transaction. If a separate transaction attempts to modify data that are locked by an open transaction, the newest transaction will not succeed, as committing it could result in a violation of the `SERIALIZABLE` isolation level. This scenario is called *transaction contention*, and should be avoided when possible. For a more detailed explanation of transaction contention, and tips on how to avoid it, see [Understand and Avoid Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-
-#### Transaction retries
-
-In some cases, transaction contention is unavoidable. If a transaction fails due to contention, CockroachDB will automatically retry the transaction, or will return a [transaction retry error](transaction-retry-error-reference.html) to the client. Most [official CockroachDB client libraries](install-client-drivers.html) include a transaction-retrying wrapper function to make writing your persistence layer easier. If your framework's client library does not include a retry wrapper, you will need to write transaction retry logic in your application. We go into more detail about transaction retries later in the guide, in [Retry Transactions](advanced-client-side-transaction-retries.html).
-
-### How applications interact with CockroachDB
-
-CockroachDB supports the PostgreSQL wire protocol, and CockroachDB supports [most PostgreSQL syntax and features](postgresql-compatibility.html), making most PostgreSQL client libraries compatible with CockroachDB. Cockroach Labs also maintains official CockroachDB adapters for some of the most popular PostgreSQL drivers and ORMs. Using an official CockroachDB adapter can help simplify transaction management and performance optimization in your application. If an official CockroachDB adapter does not yet exist for your application's data framework, we recommend just using the PostgreSQL client library that works for your application.
-
-A growing number of popular third-party database tools offer full support for CockroachDB. Because CockroachDB uses the PostgreSQL wire protocol and supports PostgreSQL syntax, most PostgreSQL-compatible third-party tools are also compatible with CockroachDB. For a list of libraries and tools that we have tested against CockroachDB, see [Third-party Database Tools](third-party-database-tools.html).
-
-## What's next?
-
-- [Start a Local Cluster](secure-a-cluster.html)
-- [Install a Driver or ORM Framework](install-client-drivers.html)
-- [Connect to CockroachDB](connect-to-the-database.html)
-
-You might also be interested in the following pages:
-
-- [Architecture Overview](architecture/overview.html)
-- [Transactions](transactions.html)
-- [CockroachDB Migration](migration-overview.html)
-- [PostgreSQL Compatibility](postgresql-compatibility.html)
-- [Hello World Example Apps](example-apps.html)
-- [Build a Spring App with CockroachDB](build-a-spring-app-with-cockroachdb-jdbc.html)
-- [Develop and Deploy a Multi-Region Web Application](multi-region-overview.html)
-
-{% include cockroach_u_pydev.md %}
diff --git a/src/current/v20.2/diagnostics-reporting.md b/src/current/v20.2/diagnostics-reporting.md
deleted file mode 100644
index 3f18147f54e..00000000000
--- a/src/current/v20.2/diagnostics-reporting.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Diagnostics Reporting
-summary: Learn about the diagnostic details that get shared with CockroachDB and how to opt out of sharing.
-toc: true
----
-
-By default, the DB Console and each node of a CockroachDB cluster share anonymous usage details with Cockroach Labs. These details, which are completely scrubbed of identifiable information, greatly help us understand and improve how the system behaves in real-world scenarios.
-
-This page summarizes the details that get shared, how to view the details yourself, and how to opt out of sharing.
-
-{{site.data.alerts.callout_success}}
-For insights into your cluster's performance and health, use the built-in [DB Console](ui-overview.html) or a third-party monitoring tool like [Prometheus](monitor-cockroachdb-with-prometheus.html).
-{{site.data.alerts.end}}
-
-## What gets shared
-
-When diagnostics reporting is on, each node of a CockroachDB cluster shares anonymized details on an hourly basis, including (but not limited to):
-
-- Deployment and configuration characteristics, such as size of hardware, [cluster settings](cluster-settings.html) that have been altered from defaults, number of [replication zones](configure-replication-zones.html) configured, etc.
-- Usage and cluster health details, such as crashes, unexpected errors, attempts to use unsupported features, types of queries run and their execution characteristics as well as types of schemas used, etc.
-
-To view the full diagnostics details that a node reports to Cockroach Labs, use the `http://<node-address>:<http-port>/_status/diagnostics/local` JSON endpoint.
-
-{{site.data.alerts.callout_info}}
-In all cases, names and other string values are scrubbed and replaced with underscores. Also, the details that get shared may change over time, but as that happens, we will announce the changes in release notes.
-{{site.data.alerts.end}}
-
-## Opt out of diagnostics reporting
-
-### At cluster initialization
-
-To make sure that absolutely no diagnostic details are shared, you can set the environment variable `COCKROACH_SKIP_ENABLING_DIAGNOSTIC_REPORTING=true` before starting the first node of the cluster. Note that this works only when set before starting the first node of the cluster. Once the cluster is running, you need to use the `SET CLUSTER SETTING` method described below.
-
-### After cluster initialization
-
-To stop sending diagnostic details to Cockroach Labs once a cluster is running, [use the built-in SQL client](cockroach-sql.html) to execute the following [`SET CLUSTER SETTING`](set-cluster-setting.html) statement, which switches the `diagnostics.reporting.enabled` [cluster setting](cluster-settings.html) to `false`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING diagnostics.reporting.enabled = false;
-~~~
-
-This change will not be instantaneous, as it must be propagated to other nodes in the cluster.
-
-## Check the state of diagnostics reporting
-
-To check the state of diagnostics reporting, [use the built-in SQL client](cockroach-sql.html) to execute the following [`SHOW CLUSTER SETTING`](show-cluster-setting.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING diagnostics.reporting.enabled;
-~~~
-
-~~~
-  diagnostics.reporting.enabled
-+-------------------------------+
-              false
-(1 row)
-~~~
-
-If the setting is `false`, diagnostics reporting is off; if the setting is `true`, diagnostics reporting is on.
-
-## See also
-
-- [Cluster Settings](cluster-settings.html)
-- [Start a Node](cockroach-start.html)
diff --git a/src/current/v20.2/disaster-recovery.md b/src/current/v20.2/disaster-recovery.md
deleted file mode 100644
index cc79bf2432b..00000000000
--- a/src/current/v20.2/disaster-recovery.md
+++ /dev/null
@@ -1,360 +0,0 @@
----
-title: Disaster Recovery
-summary: Learn how about CockrachDB disaster recovery capabilities and what to do if you encounter an issue.
-toc: true
----
-
-CockroachDB is built to be [fault-tolerant and to recover automatically](demo-fault-tolerance-and-recovery.html), but sometimes disasters happen. A _disaster_ is any event that puts your cluster at risk, and usually means your cluster is experiencing [hardware failure](#hardware-failure), [data failure](#data-failure), or has [compromised security keys](#compromised-security-keys). Having a disaster recovery plan enables you to recover quickly, while limiting the consequences.
-
-## Hardware failure
-
-When planning to survive hardware failures, start by determining the minimum replication factor you need based on your fault tolerance goals:
-
-- [Single-region survivability planning](#single-region-survivability-planning)
-- [Multi-region survivability planning](#multi-region-survivability-planning)
-
-{{site.data.alerts.callout_danger}}
-Increasing the replication factor can impact write performance in that more replicas must agree to reach quorum. For more details about the mechanics of writes and the Raft protocol, see [Read and Writes Overview](architecture/reads-and-writes-overview.html).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-For the purposes of choosing a replication factor, disk failure is equivalent to node failure.
-{{site.data.alerts.end}}
-
-If you experience hardware failures in a cluster, the recovery actions you need to take will depend on the type of infrastructure and topology pattern used:
-
-- [Single-region recovery](#single-region-recovery)
-- [Multi-region recovery](#multi-region-recovery)
-
-### Single-region survivability planning
-
-The table below shows the replication factor (RF) needed to achieve the listed fault tolerance goals for a single region, cloud-deployed cluster with nodes spread as evenly as possible across 3 availability zones (AZs):
-
-{{site.data.alerts.callout_info}}
-See our [basic production topology](topology-basic-production.html#configuration) for configuration guidance.
-{{site.data.alerts.end}}
-
-<table>
-  <thead>
-    <tr>
-      <th>Fault Tolerance Goals</th>
-      <th>3 nodes</th>
-      <th>5 nodes</th>
-      <th>9 nodes</th>
-    </tr>
-  </thead>
-  <tbody>
-    <tr>
-      <td style="color:#46a417"><b>1 Node</b></td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 AZ</b></td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>2 Nodes</b></td>
-      <td>Not possible</td>
-      <td>RF = 5</td>
-      <td>RF = 5</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>AZ + Node</b></td>
-      <td>Not possible</td>
-      <td>Not possible</td>
-      <td>RF = 9</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>2 AZ</b></td>
-      <td>Not possible</td>
-      <td>Not possible</td>
-      <td>Not possible</td>
-    </tr>
-  </tbody>
-</table>
-
-To be able to survive 2+ availability zones failing, scale to a [multi-region](#multi-region-survivability-planning) deployment.
-
-### Single-region recovery
-
-For hardware failures in a single-region cluster, the recovery actions vary and depend on the type of infrastructure used.
-
-For example, consider a cloud-deployed CockroachDB cluster with the following setup:
-
-- Single-region
-- 3 nodes
-- A node in each availability zone (i.e., 3 AZs)
-- Replication factor of 3
-
-The table below describes what actions to take to recover from various hardware failures in this example cluster:
-
-<table>
-  <thead>
-    <tr>
-      <th>Failure</th>
-      <th>Availability</th>
-      <th>Consequence</th>
-      <th>Action to Take</th>
-    </tr>
-  </thead>
-  <tbody class=nohover>
-    <tr>
-      <td style="color:#46a417"><b>1 Disk</td>
-      <td style="color:#228B22"><b>√</b></td>
-      <td rowspan="3">Fewer resources are available. Some data will be under-replicated until the failed nodes are marked dead. <br><br>Once marked dead, data is replicated to other nodes and the cluster remains healthy.
-      </td>
-      <td><a href="cockroach-start.html">Restart the node</a> with a new disk.</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 Node</td>
-      <td style="color:#228B22"><b>√</b></td>
-      <td rowspan="2">If the node or AZ becomes unavailable, check the <a href="ui-overview-dashboard.html">Overview dashboard</a> on the DB Console:
-      <ul>
-      <li>If the down node is marked <b>Suspect</b>, try <a href="cockroach-start.html">restarting the node</a>.</li>
-      <li>If the down node is marked <b>Dead</b>, <a href="remove-nodes.html">decommission the node</a>, wipe the store path, and then <a href="cockroach-start.html">rejoin it back to the cluster</a>. If the node has additional hardware issues, decommission the node and <a href="cockroach-start.html">add a new node</a> to the cluster. Ensure that <a href="cockroach-start.html#locality">locality flags are set</a> correctly upon node startup.</li></ul></td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 AZ</td>
-      <td style="color:#228B22"><b>√</b></td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>2 Nodes</b></td>
-      <td style="color:#FF0000"><b>X</b></td>
-      <td>Cluster is unavailable.</td>
-      <td><a href="cockroach-start.html">Restart</a> 1 of the 2 nodes that are down to regain quorum. <br><br>If you can’t recover at least 1 node, <a href="https://support.cockroachlabs.com">contact Cockroach Labs support</a> for assistance.</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 AZ + 1 Node</b></td>
-      <td style="color:#FF0000"><b>X</b></td>
-      <td>Cluster is unavailable.</td>
-      <td><a href="cockroach-start.html">Restart</a> the node that is down to regain quorum. When the AZ comes back online, try restarting the node.<br><br>If you can’t recover at least 1 node, <a href="https://support.cockroachlabs.com">contact Cockroach Labs support</a> for assistance.</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>2 AZ</b></td>
-      <td style="color:#FF0000"><b>X</b></td>
-      <td>Cluster is unavailable.</td>
-      <td>When the AZ comes back online, try <a href="cockroach-start.html">restarting</a> at least 1 of the nodes.<br><br>You can also <a href="https://support.cockroachlabs.com">contact Cockroach Labs support</a> for assistance.</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>3 Nodes</b></td>
-      <td style="color:#FF0000"><b>X</b></td>
-      <td>Cluster is unavailable.</td>
-      <td><a href="cockroach-start.html">Restart</a> 2 of the 3 nodes that are down to regain quorum. <br><br>If you can’t recover 2 of the 3 failed nodes, <a href="https://support.cockroachlabs.com">contact Cockroach Labs support</a> for assistance.</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 Region</td>
-      <td style="color:#FF0000"><b>X</b></td>
-      <td>Cluster is unavailable. <br><br>Potential data loss between last backup and time of outage if the region and nodes did not come back online.</td>
-      <td>When the region comes back online, try <a href="cockroach-start.html">restarting the nodes</a> in the cluster. <br><br>If the region does not come back online and nodes are lost or destroyed, try <a href="restore.html">restoring the latest cluster backup</a> into a new cluster.<br><br>You can also <a href="https://support.cockroachlabs.com">contact Cockroach Labs support</a> for assistance.</td>
-    </tr>
-  </tbody>
-</table>
-
-{{site.data.alerts.callout_info}}
-When using Kubernetes, recovery actions happen automatically in many cases and no action needs to be taken.
-{{site.data.alerts.end}}
-
-### Multi-region survivability planning
-
-The table below shows the replication factor (RF) needed to achieve the listed fault tolerance (e.g., survive 1 failed node) for a multi-region, cloud-deployed cluster with 3 availability zones (AZ) per region and one node in each AZ:
-
-{{site.data.alerts.callout_danger}}
-The chart below describes the CockroachDB default behavior when locality flags are correctly set. It does not use geo-partitioning or a specific [topology pattern](topology-patterns.html). For a multi-region cluster in production, we do not recommend using the default behavior, as the cluster's performance will be negatively affected.
-{{site.data.alerts.end}}
-
-<table>
-  <thead>
-    <tr>
-      <th>Fault Tolerance Goals</th>
-      <th>3 Regions<br>(9 Nodes Total)</th>
-      <th>4 Regions<br>(12 Nodes Total)</th>
-      <th>5 Regions<br>(15 Nodes Total)</th>
-    </tr>
-  </thead>
-  <tbody>
-    <tr>
-      <td style="color:#46a417"><b>1 Node</b></td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 AZ</b></td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 Region</b></td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-      <td>RF = 3</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>2 Nodes</b></td>
-      <td>RF = 5</td>
-      <td>RF = 5</td>
-      <td>RF = 5</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 Region + 1 Node</b></td>
-      <td>RF = 9</td>
-      <td>RF = 7</td>
-      <td>RF = 5</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>2 Regions</b></td>
-      <td>Not possible</td>
-      <td>Not possible</td>
-      <td>RF = 5</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>2 Regions + 1 Node</b></td>
-      <td>Not possible</td>
-      <td>Not possible</td>
-      <td>RF = 15</td>
-    </tr>
-  </tbody>
-</table>
-
-### Multi-region recovery
-
-For hardware failures in a multi-region cluster, the actions taken to recover vary and depend on the type of infrastructure used.
-
-For example, consider a cloud-deployed CockroachDB cluster with the following setup:
-
-- 3 regions
-- 3 AZs per region
-- 9 nodes (1 node per AZ)
-- Replication factor of 3
-
-The table below describes what actions to take to recover from various hardware failures in this example cluster:
-
-<table>
-  <thead>
-    <tr>
-      <th>Failure</th>
-      <th>Availability</th>
-      <th>Consequence</th>
-      <th>Action to Take</th>
-    </tr>
-  </thead>
-  <tbody class=nohover>
-    <tr>
-      <td style="color:#46a417"><b>1 Disk</td>
-      <td style="color:#228B22"><b>√</b></td>
-      <td rowspan="4">Under-replicated data. Fewer resources for workload.</td>
-      <td><a href="cockroach-start.html">Restart the node</a> with a new disk.</td>
-    </tr>
-      <td style="color:#46a417"><b>1 Node</td>
-      <td style="color:#228B22"><b>√</b></td>
-      <td rowspan="2">If the node or AZ becomes unavailable check the <a href="ui-overview-dashboard.html">Overview dashboard</a> on the DB Console:
-      <ul>
-      <li>If the down node is marked <b>Suspect</b>, try <a href="cockroach-start.html">restarting the node</a>.</li>
-      <li>If the down node is marked <b>Dead</b>, <a href="remove-nodes.html">decommission the node</a>, wipe the store path, and then <a href="cockroach-start.html">rejoin it back to the cluster</a>. If the node has additional hardware issues, decommission the node and <a href="cockroach-start.html">add a new node</a> to the cluster. Ensure that <a href="cockroach-start.html#locality">locality flags are set</a> correctly upon node startup.</li>
-      </ul>
-      </td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 AZ</b></td>
-      <td style="color:#228B22"><b>√</b></td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>1 Region</b></td>
-      <td style="color:#228B22"><b>√</b></td>
-      <td>Check the <a href="ui-overview-dashboard.html">Overview dashboard</a> on the DB Console. If nodes are marked <b>Dead</b>, <a href="remove-nodes.html">decommission the nodes</a> and <a href="cockroach-start.html">add 3 new nodes</a> in a new region. Ensure that <a href="cockroach-start.html#locality">locality flags are set</a> correctly upon node startup.</td>
-    </tr>
-    <tr>
-      <td style="color:#46a417"><b>2 or More Regions</b></td>
-      <td style="color:#FF0000"><b>X</b></td>
-      <td>Cluster is unavailable. <br><br>Potential data loss between last backup and time of outage if the region and nodes did not come back online.</td>
-      <td>When the regions come back online, try <a href="cockroach-start.html">restarting the nodes</a> in the cluster. <br><br>If the regions do not come back online and nodes are lost or destroyed, try <a href="restore.html">restoring the latest cluster backup</a> into a new cluster.<br><br>You can also <a href="https://support.cockroachlabs.com">contact Cockroach Labs support</a> for assistance.</td>
-    </tr>
-  </tbody>
-</table>
-
-{{site.data.alerts.callout_info}}
-When using Kubernetes, recovery actions happen automatically in many cases and no action needs to be taken.
-{{site.data.alerts.end}}
-
-## Data failure
-
-When dealing with data failure due to bad actors, rogue applications, or data corruption, domain expertise is required to identify the affected rows and determine how to remedy the situation (e.g., remove the incorrectly inserted rows, insert deleted rows, etc.). However, there are a few actions that you can take for short-term remediation:
-
-- If you are within the garbage collection window, [run differentials](#run-differentials).
-- If you have a backup file, [restore to a point in time](#restore-to-a-point-in-time).
-- If your cluster is running and you do not have a backup with the data you need, [create a new backup](#create-a-new-backup).
-- To [recover from corrupted data in a database or table](#recover-from-corrupted-data-in-a-database-or-table), restore the corrupted object.
-
-{{site.data.alerts.callout_success}}
-To give yourself more time to recover and clean up the corrupted data, put your application in “read only” mode and only run [`AS OF SYSTEM TIME`](as-of-system-time.html) queries from the application.
-{{site.data.alerts.end}}
-
-### Run differentials
-
-If you are within the [garbage collection window](configure-replication-zones.html#replication-zone-variables) (default is 25 hours), run [`AS OF SYSTEM TIME`](as-of-system-time.html) queries and use [`CREATE TABLE AS … SELECT * FROM`](create-table-as.html) to create comparison data and run differentials to find the offending rows to fix.
-
-If you are outside of the garbage collection window, you will need to use a [backup](backup.html) to run comparisons.
-
-### Restore to a point in time
-
-- If you are a core user, use a [backup](backup.html) that was taken with [`AS OF SYSTEM TIME`](as-of-system-time.html) to restore to a specific point.
-- If you are an Enterprise user, use your [backup](backup.html) file to [restore to a point in time](take-backups-with-revision-history-and-restore-from-a-point-in-time.html) where you are certain there was no corruption. Note that the backup must have been taken with [revision history](backup.html#with-revision-history).
-
-### Create a new backup
-
-If your cluster is running, you do not have a backup that encapsulates the time you want to [restore](restore.html) to, and the data you want to recover is still in the [garbage collection window](configure-replication-zones.html#replication-zone-variables), there are two actions you can take:
-
-- If you are a core user, trigger a [backup](backup.html) using [`AS OF SYSTEM TIME`](as-of-system-time.html) to create a new backup that encapsulates the specific time. The `AS OF SYSTEM TIME` must be within the [garbage collection window](configure-replication-zones.html#replication-zone-variables) (default is 25 hours).
-- If you are an Enterprise user, trigger a new [backup `with_revision_history`](take-backups-with-revision-history-and-restore-from-a-point-in-time.html) and you will have a backup you can use to restore to the desired point in time within the [garbage collection window](configure-replication-zones.html#replication-zone-variables) (default is 25 hours).
-
-### Recover from corrupted data in a database or table
-
-If you have corrupted data in a database or table, [restore](restore.html) the object from a prior [backup](backup.html). If revision history is in the backup, you can restore from a [point in time](take-backups-with-revision-history-and-restore-from-a-point-in-time.html).
-
-Instead of dropping the corrupted table or database, we recommend [renaming the table](rename-table.html) or [renaming the database](rename-database.html) so you have historical data to compare to later. If you drop a database, the database cannot be referenced with `AS OF SYSTEM TIME` queries (see [#51380](https://github.com/cockroachdb/cockroach/issues/51380) for more information), and you will need to take a backup that is backdated to the system time when the database still existed.
-
-{{site.data.alerts.callout_info}}
-If the table you are restoring has foreign keys, [careful consideration](restore.html#remove-the-foreign-key-before-restore) should be applied to make sure data integrity is maintained during the restore process.
-{{site.data.alerts.end}}
-
-## Compromised security keys
-
-CockroachDB maintains a secure environment for your data. However, there are bad actors who may find ways to gain access or expose important security information. In the event that this happens, there are a few things you can do to get ahead of a security issue:
-
-- If you have [changefeeds to cloud storage sinks](#changefeeds-to-cloud-storage), cancel the changefeed job and restart it with new access credentials.
-- If you are using [encryption at rest](#encryption-at-rest), rotate the store key(s).
-- If you are using [wire encryption / TLS](#wire-encryption-tls), rotate your keys.
-
-### Changefeeds to cloud storage
-
-1. [Cancel the changefeed job](cancel-job.html) immediately and [record the high water timestamp](stream-data-out-of-cockroachdb-using-changefeeds.html#monitor-a-changefeed) for where the changefeed was stopped.
-2. Remove the access keys from the identity management system of your cloud provider and replace with a new set of access keys.
-3. [Create a new changefeed](create-changefeed.html#start-a-new-changefeed-where-another-ended) with the new access credentials using the last high water timestamp.
-
-### Encryption at rest
-
-If you believe the user-defined store keys have been compromised, quickly attempt to rotate your store keys that are being used for your encryption at rest setup. If this key has already been compromised and the store keys were rotated by a bad actor, the cluster should be wiped if possible and [restored](restore.html) from a prior backup.
-
-If the compromised keys were not rotated by a bad actor, quickly attempt to [rotate the store key](encryption.html#rotating-keys) by restarting each of the nodes with the old key and the new key. For an example on how to do this, see [Encryption](encryption.html#changing-encryption-algorithm-or-keys).
-
-Once all of the nodes are restarted with the new key, put in a request to revoke the old key from the Certificate Authority.
-
-{{site.data.alerts.callout_info}}
-CockroachDB does not allow prior store keys to be used again.
-{{site.data.alerts.end}}
-
-### Wire Encryption / TLS
-
-As a best practice, [keys should be rotated](rotate-certificates.html). In the event that keys have been compromised, quickly attempt to rotate your keys. This can include rotating node certificates, client certificates, and the CA certificate.
-
-## See also
-
-- [Fault Tolerance & Recovery](demo-fault-tolerance-and-recovery.html)
-- [Back up and Restore Data](take-full-and-incremental-backups.html)
-- [Topology Patterns](topology-patterns.html)
-- [Production Checklist](recommended-production-settings.html)
diff --git a/src/current/v20.2/drop-column.md b/src/current/v20.2/drop-column.md
deleted file mode 100644
index b8c13c92a7f..00000000000
--- a/src/current/v20.2/drop-column.md
+++ /dev/null
@@ -1,207 +0,0 @@
----
-title: DROP COLUMN
-summary: Use the ALTER COLUMN statement to remove columns from tables.
-toc: true
----
-
-The `DROP COLUMN` [statement](sql-statements.html) is part of `ALTER TABLE` and removes columns from a table.
-
-{{site.data.alerts.callout_danger}}
-When used in an explicit transaction combined with other schema changes to the same table, `DROP COLUMN` can result in data loss if one of the other schema changes fails or is canceled. To work around this, move the `DROP COLUMN` statement to its own explicit transaction or run it in a single statement outside the existing transaction.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> By default, `DROP COLUMN` drops any [indexes](indexes.html) on the column being dropped, and any indexes that reference the column, including [partial indexes](partial-indexes.html) with predicates that reference the column and indexes with [`STORING` clauses](create-index.html#store-columns) that reference the column.
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_column.html %}</div>
-
-## 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 with the column you want to drop.
- `name` | The name of the column you want to drop.<br><br>When a column with a `CHECK` constraint is dropped, the `CHECK` constraint is also dropped.
- `CASCADE` | Drop the column even if objects (such as [views](views.html)) depend on it; drop the dependent objects, as well. `CASCADE` will drop a column with a foreign key constraint if it is the only column in the reference.<br><br>`CASCADE` does not list the objects it drops, so should be used cautiously.<br><br><span class="version-tag">New in v20.2:</span> `CASCADE` is not required to drop an indexed column, or a column that is referenced by an index. By default, `DROP COLUMN` drops any indexes [indexes](indexes.html) on the column being dropped, and any indexes that reference the column, including [partial indexes](partial-indexes.html) with predicates that reference the column and indexes with [`STORING` clauses](create-index.html#store-columns) that reference the column.
- `RESTRICT` | *(Default)* Do not drop the column if any objects (such as [views](views.html)) depend on it.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Drop a column
-
-If you no longer want a column in a table, you can drop it.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  city        | VARCHAR   |    false    | NULL           |                       | {primary} |   false
-  name        | VARCHAR   |    true     | NULL           |                       | {}        |   false
-  address     | VARCHAR   |    true     | NULL           |                       | {}        |   false
-  credit_card | VARCHAR   |    true     | NULL           |                       | {}        |   false
-(5 rows)
-~~~
-
-If there is data in the table, the `sql_safe_updates` [session variable](set-vars.html) must be set to `false`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users DROP COLUMN credit_card;
-~~~
-
-~~~
-ERROR: rejected (sql_safe_updates = true): ALTER TABLE DROP COLUMN will remove all data in that column
-SQLSTATE: 01000
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET sql_safe_updates = false;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users DROP COLUMN credit_card;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  city        | VARCHAR   |    false    | NULL           |                       | {primary} |   false
-  name        | VARCHAR   |    true     | NULL           |                       | {}        |   false
-  address     | VARCHAR   |    true     | NULL           |                       | {}        |   false
-(4 rows)
-~~~
-
-### Prevent dropping columns with dependent objects (`RESTRICT`)
-
-If the column has dependent objects, such as [views](views.html), CockroachDB will not drop the column by default. However, if you want to be sure of the behavior you can include the `RESTRICT` clause.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE VIEW expensive_rides AS SELECT id, city FROM rides WHERE revenue > 90;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE rides DROP COLUMN revenue RESTRICT;
-~~~
-
-~~~
-ERROR: cannot drop column "revenue" because view "expensive_rides" depends on it
-SQLSTATE: 2BP01
-HINT: you can drop expensive_rides instead.
-~~~
-
-### Drop a column and its dependent objects (`CASCADE`)
-
-If you want to drop the column and all of its dependent options, include the `CASCADE` clause.
-
-{{site.data.alerts.callout_danger}}
-<code>CASCADE</code> does not list objects it drops, so should be used cautiously.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE expensive_rides;
-~~~
-
-~~~
-    table_name    |                                              create_statement
-------------------+-------------------------------------------------------------------------------------------------------------
-  expensive_rides | CREATE VIEW public.expensive_rides (id, city) AS SELECT id, city FROM movr.public.rides WHERE revenue > 90
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE rides DROP COLUMN revenue CASCADE;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE expensive_rides;
-~~~
-
-~~~
-ERROR: relation "expensive_rides" does not exist
-SQLSTATE: 42P01
-~~~
-
-### Drop an indexed column
-
-<span class="version-tag">New in v20.2:</span> `DROP COLUMN` drops a column and any indexes on the column being dropped.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX start_end_idx ON rides(start_time, end_time);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW INDEXES FROM rides] WHERE index_name='start_end_idx';
-~~~
-
-~~~
-  table_name |  index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+---------------+------------+--------------+-------------+-----------+---------+-----------
-  rides      | start_end_idx |    true    |            1 | start_time  | ASC       |  false  |  false
-  rides      | start_end_idx |    true    |            2 | end_time    | ASC       |  false  |  false
-  rides      | start_end_idx |    true    |            3 | city        | ASC       |  false  |   true
-  rides      | start_end_idx |    true    |            4 | id          | ASC       |  false  |   true
-(4 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE rides DROP COLUMN start_time;
-~~~
-
-~~~
-NOTICE: the data for dropped indexes is reclaimed asynchronously
-HINT: The reclamation delay can be customized in the zone configuration for the table.
-ALTER TABLE
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW INDEXES FROM rides] WHERE index_name='start_end_idx';
-~~~
-
-~~~
-  table_name | index_name | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+------------+------------+--------------+-------------+-----------+---------+-----------
-(0 rows)
-~~~
-
-## See also
-
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`DROP INDEX`](drop-index.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/drop-constraint.md b/src/current/v20.2/drop-constraint.md
deleted file mode 100644
index a45cfd9093a..00000000000
--- a/src/current/v20.2/drop-constraint.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: DROP CONSTRAINT
-summary: Use the ALTER CONSTRAINT statement to remove constraints from columns.
-toc: true
----
-
-The `DROP CONSTRAINT` [statement](sql-statements.html) is part of [`ALTER TABLE`](alter-table.html) and removes [`CHECK`](check.html) and [`FOREIGN KEY`](foreign-key.html) constraints from columns.
-
- [`PRIMARY KEY`](primary-key.html) constraints can be dropped with `DROP CONSTRAINT` if an [`ADD CONSTRAINT`](add-constraint.html) statement follows the `DROP CONSTRAINT` statement in the same transaction.
-
-{{site.data.alerts.callout_success}}
-When you change a primary key with [`ALTER TABLE ... ALTER PRIMARY KEY`](alter-primary-key.html), the old primary key index becomes a secondary index. If you do not want the old primary key to become a secondary index, use `DROP CONSTRAINT`/[`ADD CONSTRAINT`](add-constraint.html) to change the primary key.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-For information about removing other constraints, see [Constraints: Remove Constraints](constraints.html#remove-constraints).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_constraint.html %}</div>
-
-## 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 with the constraint you want to drop.
- `name` | The name of the constraint you want to drop.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Drop a foreign key constraint
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS FROM vehicles;
-~~~
-
-~~~
-  table_name |  constraint_name  | constraint_type |                         details                         | validated
--------------+-------------------+-----------------+---------------------------------------------------------+------------
-  vehicles   | fk_city_ref_users | FOREIGN KEY     | FOREIGN KEY (city, owner_id) REFERENCES users(city, id) |   true
-  vehicles   | primary           | PRIMARY KEY     | PRIMARY KEY (city ASC, id ASC)                          |   true
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE vehicles DROP CONSTRAINT fk_city_ref_users;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS FROM vehicles;
-~~~
-
-~~~
-  table_name | constraint_name | constraint_type |            details             | validated
--------------+-----------------+-----------------+--------------------------------+------------
-  vehicles   | primary         | PRIMARY KEY     | PRIMARY KEY (city ASC, id ASC) |   true
-(1 row)
-~~~
-
-### Drop and add a primary key constraint
-
-When you change a primary key with [`ALTER TABLE ... ALTER PRIMARY KEY`](alter-primary-key.html), the old primary key index becomes a secondary index. If you do not want the old primary key to become a secondary index when changing a primary key, you can use `DROP CONSTRAINT`/[`ADD CONSTRAINT`](add-constraint.html) instead.
-
-Suppose that you want to add `name` to the composite primary key of the `users` table.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                      create_statement
--------------+--------------------------------------------------------------
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | )
-(1 row)
-~~~
-
-First, add a [`NOT NULL`](not-null.html) constraint to the `name` column with [`ALTER COLUMN`](alter-column.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users ALTER COLUMN name SET NOT NULL;
-~~~
-
-Then, in the same transaction, `DROP` the old `"primary"` constraint and [`ADD`](add-constraint.html) the new one:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-> ALTER TABLE users DROP CONSTRAINT "primary";
-> ALTER TABLE users ADD CONSTRAINT "primary" PRIMARY KEY (city, name, id);
-> COMMIT;
-~~~
-
-~~~
-NOTICE: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                          create_statement
--------------+---------------------------------------------------------------------
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NOT NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, name ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | )
-(1 row)
-~~~
-
-Using [`ALTER PRIMARY KEY`](alter-primary-key.html) would have created a `UNIQUE` secondary index called `users_city_id_key`. Instead, there is just one index for the primary key constraint.
-
-## See also
-
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`RENAME CONSTRAINT`](rename-constraint.html)
-- [`VALIDATE CONSTRAINT`](validate-constraint.html)
-- [`DROP COLUMN`](drop-column.html)
-- [`DROP INDEX`](drop-index.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`SHOW JOBS`](show-jobs.html)
-- ['ALTER PRIMARY KEY'](alter-primary-key.html)
diff --git a/src/current/v20.2/drop-database.md b/src/current/v20.2/drop-database.md
deleted file mode 100644
index 79b2a25196c..00000000000
--- a/src/current/v20.2/drop-database.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: DROP DATABASE
-summary: The DROP DATABASE statement removes a database and all its objects from a CockroachDB cluster.
-toc: true
----
-
-The `DROP DATABASE` [statement](sql-statements.html) removes a database and all its objects from a CockroachDB cluster.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the database and on all tables in the database.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_database.html %}</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`IF EXISTS`   | Drop the database if it exists; if it does not exist, do not return an error.
-`name`  | The name of the database you want to drop. You cannot drop a database if it is set as the [current database](sql-name-resolution.html#current-database) or if [`sql_safe_updates = true`](set-vars.html).
-`CASCADE` | _(Default)_ Drop all tables and views in the database as well as all objects (such as [constraints](constraints.html) and [views](views.html)) that depend on those tables.<br><br>`CASCADE` does not list objects it drops, so should be used cautiously.
-`RESTRICT` | Do not drop the database if it contains any [tables](create-table.html) or [views](create-view.html).
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Drop a database and its objects (`CASCADE`)
-
-For non-interactive sessions (e.g., client applications), `DROP DATABASE` applies the `CASCADE` option by default, which drops all tables and views in the database as well as all objects (such as [constraints](constraints.html) and [views](views.html)) that depend on those tables.
-
-For interactive sessions from the [built-in SQL client](cockroach-sql.html), either the `CASCADE` option must be set explicitly or the `--unsafe-updates` flag must be set when starting the shell.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP DATABASE movr;
-~~~
-
-~~~
-ERROR: rejected (sql_safe_updates = true): DROP DATABASE on current database
-SQLSTATE: 01000
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> USE defaultdb;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP DATABASE movr;
-~~~
-
-~~~
-ERROR: rejected (sql_safe_updates = true): DROP DATABASE on non-empty database without explicit CASCADE
-SQLSTATE: 01000
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP DATABASE movr CASCADE;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-ERROR: target database or schema does not exist
-SQLSTATE: 3F000
-~~~
-
-### Prevent dropping a non-empty database (`RESTRICT`)
-
-When a database is not empty, the `RESTRICT` option prevents the database from being dropped:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> USE defaultdb;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP DATABASE movr RESTRICT;
-~~~
-
-~~~
-ERROR: database "movr" is not empty and RESTRICT was specified
-SQLSTATE: 2BP01
-~~~
-
-## See also
-
-- [`CREATE DATABASE`](create-database.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`RENAME DATABASE`](rename-database.html)
-- [`SET DATABASE`](set-vars.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [Other SQL Statements](sql-statements.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/drop-index.md b/src/current/v20.2/drop-index.md
deleted file mode 100644
index ab8eaddef0f..00000000000
--- a/src/current/v20.2/drop-index.md
+++ /dev/null
@@ -1,176 +0,0 @@
----
-title: DROP INDEX
-summary: The DROP INDEX statement removes indexes from tables.
-toc: true
----
-
-The `DROP INDEX` [statement](sql-statements.html) removes indexes from tables.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_index.html %}</div>
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on each specified table.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `IF EXISTS`	| Drop the named indexes if they exist; if they do not exist, do not return an error.
- `table_name`	| The name of the table with the index you want to drop. Find table names with [`SHOW TABLES`](show-tables.html).
- `index_name`	| The name of the index you want to drop. Find index names with [`SHOW INDEX`](show-index.html).<br/><br/>You cannot drop a table's `primary` index.
- `CASCADE`	| Drop all objects (such as [constraints](constraints.html)) that depend on the indexes. `CASCADE` does not list objects it drops, so should be used cautiously.<br><br> To drop an index created with [`CREATE UNIQUE INDEX`](create-index.html#unique-indexes), you do not need to use `CASCADE`.
- `RESTRICT`	| _(Default)_ Do not drop the indexes if any objects (such as [constraints](constraints.html)) depend on them.
- `CONCURRENTLY` |  Optional, no-op syntax for PostgreSQL compatibility. All indexes are dropped concurrently in CockroachDB.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Remove an index with no dependencies
-
-Suppose you create an index on the `name` and `city` columns of the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (name, city);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM users;
-~~~
-
-~~~
-  table_name |     index_name      | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+---------------------+------------+--------------+-------------+-----------+---------+-----------
-  users      | primary             |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary             |   false    |            2 | id          | ASC       |  false  |  false
-  users      | users_name_city_idx |    true    |            1 | name        | ASC       |  false  |  false
-  users      | users_name_city_idx |    true    |            2 | city        | ASC       |  false  |  false
-  users      | users_name_city_idx |    true    |            3 | id          | ASC       |  false  |   true
-(5 rows)
-~~~
-
-You can drop this index with the `DROP INDEX` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP INDEX users@users_name_city_idx;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM users;
-~~~
-
-~~~
-  table_name | index_name | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+------------+------------+--------------+-------------+-----------+---------+-----------
-  users      | primary    |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary    |   false    |            2 | id          | ASC       |  false  |  false
-(2 rows)
-~~~
-
-### Remove an index and dependent objects with `CASCADE`
-
-{{site.data.alerts.callout_danger}}
-<code>CASCADE</code> drops <em>all</em> dependent objects without listing them, which can lead to inadvertent and difficult-to-recover losses. To avoid potential harm, we recommend dropping objects individually in most cases.
-{{site.data.alerts.end}}
-
-Suppose you create a [`UNIQUE`](unique.html) constraint on the `id` and `name` columns of the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users ADD CONSTRAINT id_name_unique UNIQUE (id, name);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS from users;
-~~~
-
-~~~
-  table_name | constraint_name | constraint_type |            details             | validated
--------------+-----------------+-----------------+--------------------------------+------------
-  users      | id_name_unique  | UNIQUE          | UNIQUE (id ASC, name ASC)      |   true
-  users      | primary         | PRIMARY KEY     | PRIMARY KEY (city ASC, id ASC) |   true
-(2 rows)
-~~~
-
-If no index exists on `id` and `name`, CockroachDB automatically creates an index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES from users;
-~~~
-
-~~~
-  table_name |   index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+----------------+------------+--------------+-------------+-----------+---------+-----------
-  users      | primary        |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary        |   false    |            2 | id          | ASC       |  false  |  false
-  users      | id_name_unique |   false    |            1 | id          | ASC       |  false  |  false
-  users      | id_name_unique |   false    |            2 | name        | ASC       |  false  |  false
-  users      | id_name_unique |   false    |            3 | city        | ASC       |  false  |   true
-(5 rows)
-~~~
-
-The `UNIQUE` constraint is dependent on the `id_name_unique` index, so you cannot drop the index with a simple `DROP INDEX` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP INDEX id_name_unique;
-~~~
-
-~~~
-ERROR: index "id_name_unique" is in use as unique constraint
-SQLSTATE: 2BP01
-HINT: use CASCADE if you really want to drop it.
-~~~
-
-To drop an index and its dependent objects, you can use `CASCADE`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP INDEX id_name_unique CASCADE;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES from users;
-~~~
-
-~~~
-  table_name | index_name | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+------------+------------+--------------+-------------+-----------+---------+-----------
-  users      | primary    |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary    |   false    |            2 | id          | ASC       |  false  |  false
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS from users;
-~~~
-
-~~~
-  table_name | constraint_name | constraint_type |            details             | validated
--------------+-----------------+-----------------+--------------------------------+------------
-  users      | primary         | PRIMARY KEY     | PRIMARY KEY (city ASC, id ASC) |   true
-(1 row)
-~~~
-
-## See Also
-
-- [Indexes](indexes.html)
-- [Online Schema Changes](online-schema-changes.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/drop-role.md b/src/current/v20.2/drop-role.md
deleted file mode 100644
index 46dc6588196..00000000000
--- a/src/current/v20.2/drop-role.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: DROP ROLE
-summary: The DROP ROLE statement removes one or more SQL roles.
-toc: true
----
-
-The `DROP ROLE` [statement](sql-statements.html) removes one or more SQL roles.
-
-{{site.data.alerts.callout_info}}
- <code>DROP ROLE</code> is no longer an Enterprise feature and is now freely available in the core version of CockroachDB. Also, since the keywords `ROLE` and `USER` can now be used interchangeably in SQL statements for enhanced Postgres compatibility, `DROP ROLE` is now an alias for [`DROP USER`](drop-user.html).
-{{site.data.alerts.end}}
-
-## Considerations
-
-- The `admin` role cannot be dropped, and `root` must always be a member of `admin`.
-- A role cannot be dropped if it has privileges. Use [`REVOKE`](revoke.html) to remove privileges.
-- Roles that [own objects](authorization.html#object-ownership) (such as databases, tables, schemas, and types) cannot be dropped until the [ownership is transferred to another role](owner-to.html#change-a-databases-owner).
-
-## Required privileges
-
-Non-admin roles cannot drop admin roles. To drop non-admin roles, the role must be a member of the `admin` role or have the [`CREATEROLE`](create-role.html#create-a-role-that-can-create-other-roles-and-manage-authentication-methods-for-the-new-roles) parameter set.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_role.html %}</div>
-
-## Parameters
-
- Parameter | Description
-------------|--------------
-`name` | The name of the role to remove. To remove multiple roles, use a comma-separate list of roles.<br><br>You can use [`SHOW ROLES`](show-roles.html) to find the names of roles.
-
-## Example
-
-In this example, first check a role's privileges. Then, revoke the role's privileges and remove the role.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON documents FOR dev_ops;
-~~~
-~~~
-+------------+--------+-----------+---------+------------+
-|  Database  | Schema |   Table   |  User   | Privileges |
-+------------+--------+-----------+---------+------------+
-| jsonb_test | public | documents | dev_ops | INSERT     |
-+------------+--------+-----------+---------+------------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE INSERT ON documents FROM dev_ops;
-~~~
-
-{{site.data.alerts.callout_info}}All of a role's privileges must be revoked before the role can be dropped.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP ROLE dev_ops;
-~~~
-
-## See also
-
-- [Authorization](authorization.html)
-- [`CREATE ROLE`](create-role.html)
-- [`SHOW ROLES`](show-roles.html)
-- [`GRANT`](grant.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/drop-schedules.md b/src/current/v20.2/drop-schedules.md
deleted file mode 100644
index 91e4c3bb6c0..00000000000
--- a/src/current/v20.2/drop-schedules.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: DROP SCHEDULES
-summary: The DROP SCHEDULES statement lets you remove specified backup schedules.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `DROP SCHEDULES` [statement](sql-statements.html) can be used to remove [backup schedules](create-schedule-for-backup.html).
-
-{{site.data.alerts.callout_danger}}
-`DROP SCHEDULE` does **not** cancel any in-progress jobs started by the schedule. Before you drop a schedule, [cancel any in-progress jobs](cancel-job.html) first, as you will not be able to look up the job ID once the schedule is dropped.
-{{site.data.alerts.end}}
-
-## Required privileges
-
-Only members of the [`admin` role](authorization.html#default-roles) can drop a schedule. By default, the `root` user belongs to the `admin` role.
-
-## Synopsis
-
-~~~
-DROP SCHEDULES <selectclause>
-  select clause: select statement returning schedule id to pause.
-DROP SCHEDULE <scheduleID>
-~~~
-
-## Parameters
-
- Parameter     | Description
----------------+------------
-`selectclause` | A [selection query](selection-queries.html) that returns `id`(s) to drop.
-`scheduleID`   | The `id` of the schedule you want to drop, which can be found with [`SHOW SCHEDULES`](show-schedules.html).
-
-## Examples
-
-### Drop a schedule
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP SCHEDULE 589963390487363585;
-~~~
-
-~~~
-DROP SCHEDULES 1
-~~~
-
-### Drop multiple schedules
-
-To drop multiple schedules, nest a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `DROP SCHEDULES` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'schedule_database';
-~~~
-
-~~~
-DROP SCHEDULES 4
-~~~
-
-In this example, all schedules with the label `schedule_database` are dropped.
-
-## See also
-
-- [Manage a Backup Schedule](manage-a-backup-schedule.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`SHOW BACKUP`](show-backup.html)
-- [`SHOW SCHEDULES`](show-schedules.html)
-- [`PAUSE SCHEDULES`](pause-schedules.html)
-- [`RESUME SCHEDULES`](resume-schedules.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`RESUME JOB`](pause-job.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/drop-schema.md b/src/current/v20.2/drop-schema.md
deleted file mode 100644
index 17820bc5b4c..00000000000
--- a/src/current/v20.2/drop-schema.md
+++ /dev/null
@@ -1,162 +0,0 @@
----
-title: DROP SCHEMA
-summary: The DROP SCHEMA statement removes a schema and all its objects from a CockroachDB cluster.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `DROP SCHEMA` [statement](sql-statements.html) removes a user-defined [schema](sql-name-resolution.html#naming-hierarchy) from the current database.
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the schema and on all tables in the schema. If the user is the owner of the schema, `DROP` privileges are not necessary.
-
-## Syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/drop_schema.html %}
-</div>
-
-### Parameters
-
-Parameter | Description
-----------|------------
-`IF EXISTS`   | Drop the schema if it exists. If it does not exist, do not return an error.
-`name_list`  | The schema, or a list of schemas, that you want to drop.
-`CASCADE` | Drop all tables and views in the schema as well as all objects (such as [constraints](constraints.html) and [views](views.html)) that depend on those tables.<br><br>`CASCADE` does not list objects it drops, so should be used cautiously.
-`RESTRICT` | _(Default)_ Do not drop the schema if it contains any [tables](create-table.html) or [views](create-view.html).
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Drop a schema
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_one;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_one
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP SCHEMA org_one;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  pg_catalog
-  pg_extension
-  public
-(5 rows)
-~~~
-
-### Drop a schema with tables
-
-To drop a schema that contains tables, you need to use the `CASCADE` keyword.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_two;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_two
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE org_two.users (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        city STRING,
-        name STRING,
-        address STRING
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM org_two;
-~~~
-
-~~~
-  schema_name | table_name | type  | estimated_row_count
---------------+------------+-------+----------------------
-  org_two     | users      | table |                   0
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP SCHEMA org_two;
-~~~
-
-~~~
-ERROR: schema "org_two" is not empty and CASCADE was not specified
-SQLSTATE: 2BP01
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP SCHEMA org_two CASCADE;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  pg_catalog
-  pg_extension
-  public
-(5 rows)
-~~~
-
-## See also
-
-- [`CREATE SCHEMA`](create-schema.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [Other SQL Statements](sql-statements.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/drop-sequence.md b/src/current/v20.2/drop-sequence.md
deleted file mode 100644
index dd68aa3a72d..00000000000
--- a/src/current/v20.2/drop-sequence.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: DROP SEQUENCE
-summary: The DROP SEQUENCE statement removes a sequence from a database.
-toc: true
----
-
-The `DROP SEQUENCE` [statement](sql-statements.html) removes a sequence from a database.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the specified sequence(s).
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_sequence.html %}</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
- Parameter | Description
------------|------------
-`IF EXISTS` |  Drop the sequence only if it exists; if it does not exist, do not return an error.
-`sequence_name` | The name of the sequence you want to drop. Find the sequence name with `SHOW CREATE` on the table that uses the sequence.
-`RESTRICT` | _(Default)_ Do not drop the sequence if any objects (such as [constraints](constraints.html) and tables) use it.
-`CASCADE` | Not yet implemented. Currently, you can only drop a sequence if nothing depends on it.
-
-<!-- `CASCADE` > Drop all objects (such as [constraints](constraints.html) and tables) that depend on the sequence.<br><br>`CASCADE` does not list objects it drops, so should be used cautiously. -->
-
-## Examples
-
-### Remove a sequence (no dependencies)
-
-In this example, other objects do not depend on the sequence being dropped.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE even_numbers INCREMENT 2 START 2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-  public          | even_numbers
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP SEQUENCE even_numbers;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-(0 rows)
-~~~
-
-<!-- ### Remove a Sequence and Dependent Objects with `CASCADE`
-
-In this example, a table depends on the sequence that's being dropped. Therefore, it's only possible to drop the sequence while simultaneously dropping the dependent table using `CASCADE`.
-
-{{site.data.alerts.callout_danger}}<code>CASCADE</code> drops <em>all</em> dependent objects without listing them, which can lead to inadvertent and difficult-to-recover losses. To avoid potential harm, we recommend dropping objects individually in most cases.{{site.data.alerts.end}}
-
-~~~ sql
-> DROP SEQUENCE customer_seq CASCADE;
-~~~
-~~~
-DROP SEQUENCE
-~~~ -->
-
-## See also
-- [`CREATE SEQUENCE`](create-sequence.html)
-- [`ALTER SEQUENCE`](alter-sequence.html)
-- [`RENAME SEQUENCE`](rename-sequence.html)
-- [`SHOW SEQUENCES`](show-sequences.html)
-- [Functions and Operators](functions-and-operators.html)
-- [Other SQL Statements](sql-statements.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/drop-table.md b/src/current/v20.2/drop-table.md
deleted file mode 100644
index d1b7a08b6e0..00000000000
--- a/src/current/v20.2/drop-table.md
+++ /dev/null
@@ -1,204 +0,0 @@
----
-title: DROP TABLE
-summary: The DROP TABLE statement removes a table and all its indexes from a database.
-toc: true
----
-
-The `DROP TABLE` [statement](sql-statements.html) removes a table and all its indexes from a database.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the specified table(s). If `CASCADE` is used, the user must have the privileges required to drop each dependent object as well.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_table.html %}</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`IF EXISTS`   | Drop the table if it exists; if it does not exist, do not return an error.
-`table_name`  | A comma-separated list of table names. To find table names, use [`SHOW TABLES`](show-tables.html).
-`CASCADE` | Drop all objects (such as [constraints](constraints.html) and [views](views.html)) that depend on the table.<br><br>`CASCADE` does not list objects it drops, so should be used cautiously.
-`RESTRICT`    | _(Default)_ Do not drop the table if any objects (such as [constraints](constraints.html) and [views](views.html)) depend on it.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Remove a table (no dependencies)
-
-In this example, other objects do not depend on the table being dropped.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TABLE promo_codes;
-~~~
-
-~~~
-DROP TABLE
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(5 rows)
-~~~
-
-### Remove a table and dependent objects with `CASCADE`
-
-In this example, a [foreign key](foreign-key.html) from a different table references the table being dropped. Therefore, it's only possible to drop the table while simultaneously dropping the dependent foreign key constraint using `CASCADE`.
-
-{{site.data.alerts.callout_danger}}<code>CASCADE</code> drops <em>all</em> dependent objects without listing them, which can lead to inadvertent and difficult-to-recover losses. To avoid potential harm, we recommend dropping objects individually in most cases.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TABLE users;
-~~~
-
-~~~
-pq: "users" is referenced by foreign key from table "vehicles"
-~~~
-
-To see how `users` is referenced from `vehicles`, you can use the [`SHOW CREATE`](show-create.html) statement. `SHOW CREATE` shows how the columns in a table are created, including data types, default values, indexes, and constraints.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE vehicles;
-~~~
-
-~~~
-  table_name |                                         create_statement
--------------+---------------------------------------------------------------------------------------------------
-  vehicles   | CREATE TABLE public.vehicles (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     type VARCHAR NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     status VARCHAR NULL,
-             |     current_location VARCHAR NULL,
-             |     ext JSONB NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     CONSTRAINT fk_city_ref_users FOREIGN KEY (city, owner_id) REFERENCES public.users(city, id),
-             |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-             | )
-(1 row)
-~~~
-
-
-{% include copy-clipboard.html %}
-~~~sql
-> DROP TABLE users CASCADE;
-~~~
-
-~~~
-DROP TABLE
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(4 rows)
-~~~
-
-Use a `SHOW CREATE TABLE` statement to verify that the foreign key constraint has been removed from `vehicles`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE vehicles;
-~~~
-
-~~~
-  table_name |                                       create_statement
--------------+------------------------------------------------------------------------------------------------
-  vehicles   | CREATE TABLE public.vehicles (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     type VARCHAR NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     status VARCHAR NULL,
-             |     current_location VARCHAR NULL,
-             |     ext JSONB NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time, status, current_location, ext)
-             | )
-(1 row)
-~~~
-
-## See also
-
-- [`ALTER TABLE`](alter-table.html)
-- [`CREATE TABLE`](create-table.html)
-- [`INSERT`](insert.html)
-- [`RENAME TABLE`](rename-table.html)
-- [`SHOW COLUMNS`](show-columns.html)
-- [`SHOW TABLES`](show-tables.html)
-- [`UPDATE`](update.html)
-- [`DELETE`](delete.html)
-- [`DROP INDEX`](drop-index.html)
-- [`DROP VIEW`](drop-view.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/drop-type.md b/src/current/v20.2/drop-type.md
deleted file mode 100644
index e5536a8fb97..00000000000
--- a/src/current/v20.2/drop-type.md
+++ /dev/null
@@ -1,140 +0,0 @@
----
-title: DROP TYPE
-summary: The DROP TYPE statement drops an enumerated data type from the database.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `DROP TYPE` [statement](sql-statements.html) drops a specified [enumerated data type](enum.html) from the current database.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/drop_type.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`IF EXISTS` | Drop the type if it exists. If it does not exist, do not return an error.
-`type_name_list` | A type name or a comma-separated list of type names to drop.
-
-## Required privileges
-
-The user must be the owner of the type.
-
-## Details
-
-- You cannot drop a type or view that is in use by a table.
-- You can only drop a user-defined type from the database that contains the type.
-
-## Example
-
-### Drop a single type
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE status AS ENUM ('open', 'closed', 'inactive');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema |  name  |        value
----------+--------+-----------------------
-  public | status | open|closed|inactive
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE accounts (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        balance DECIMAL,
-        status status
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TYPE status;
-~~~
-
-~~~
-ERROR: cannot drop type "status" because other objects ([bank.public.accounts]) still depend on it
-SQLSTATE: 2BP01
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TABLE accounts;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TYPE status;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema | name | value
----------+------+--------
-(0 rows)
-~~~
-
-### Drop multiple types
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE weekday AS ENUM ('monday', 'tuesday', 'wednesday', 'thursday', 'friday');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE weekend AS ENUM ('sunday', 'saturday');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema |  name   |                  value
----------+---------+-------------------------------------------
-  public | weekday | monday|tuesday|wednesday|thursday|friday
-  public | weekend | sunday|saturday
-(2 rows)
-~~~
-
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TYPE weekday, weekend;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema | name | value
----------+------+--------
-(0 rows)
-~~~
-
-## See also
-
-- [`ENUM`](enum.html)
-- [Data types](data-types.html)
-- [`CREATE TYPE`](create-type.html)
-- [`ALTER TYPE`](alter-type.html)
-- [`SHOW ENUMS`](show-enums.html)
diff --git a/src/current/v20.2/drop-user.md b/src/current/v20.2/drop-user.md
deleted file mode 100644
index 3c7c513b367..00000000000
--- a/src/current/v20.2/drop-user.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: DROP USER
-summary: The DROP USER statement removes one or more SQL users.
-toc: true
----
-
-The `DROP USER` [statement](sql-statements.html) removes one or more SQL users.
-
-{{site.data.alerts.callout_info}}
- Since the keywords `ROLE` and `USER` can now be used interchangeably in SQL statements for enhanced Postgres compatibility, `DROP USER` is now an alias for [`DROP ROLE`](drop-role.html).
-{{site.data.alerts.end}}
-
-## Consideration
-
-Users that [own objects](authorization.html#object-ownership) (such as databases, tables, schemas, and types) cannot be dropped until the [ownership is transferred to another user](owner-to.html#change-a-databases-owner).
-
-## Required privileges
-
-Non-admin users cannot drop admin users. To drop non-admin users, the user must be a member of the `admin` role or have the [`CREATEROLE`](create-user.html#create-a-user-that-can-create-other-users-and-manage-authentication-methods-for-the-new-users) parameter set.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_user.html %}</div>
-
-## Parameters
-
- Parameter | Description
------------|-------------
-`user_name` | The username of the user to remove. To remove multiple users, use a comma-separate list of usernames.<br><br>You can use [`SHOW USERS`](show-users.html) to find usernames.
-
-## Example
-
-All of a user's privileges must be revoked before the user can be dropped.
-
-In this example, first check a user's privileges. Then, revoke the user's privileges before removing the user.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON test.customers FOR mroach;
-~~~
-
-~~~
-+-----------+--------+------------+
-|   Table   |  User  | Privileges |
-+-----------+--------+------------+
-| customers | mroach | CREATE     |
-| customers | mroach | INSERT     |
-| customers | mroach | UPDATE     |
-+-----------+--------+------------+
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE CREATE,INSERT,UPDATE ON test.customers FROM mroach;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP USER mroach;
-~~~
-
-## See also
-
-- [`CREATE USER`](create-user.html)
-- [`ALTER USER`](alter-user.html)
-- [`SHOW USERS`](show-users.html)
-- [`GRANT`](grant.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [Create Security Certificates](cockroach-cert.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/drop-view.md b/src/current/v20.2/drop-view.md
deleted file mode 100644
index 76d5dcc3ca4..00000000000
--- a/src/current/v20.2/drop-view.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: DROP VIEW
-summary: The DROP VIEW statement removes a view from a database.
-toc: true
----
-
-The `DROP VIEW` [statement](sql-statements.html) removes a [view](views.html) from a database.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the specified view(s). If `CASCADE` is used to drop dependent views, the user must have the `DROP` privilege on each dependent view as well.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/drop_view.html %}</div>
-
-## Parameters
-
- Parameter | Description
-----------|-------------
-`MATERIALIZED` | <span class="version-tag">New in v20.2:</span> Drop a [materialized view](views.html#materialized-views).
- `IF EXISTS`   | Drop the view if it exists; if it does not exist, do not return an error.
- `table_name`  | A comma-separated list of view names. To find view names, use:<br><br>`SELECT * FROM information_schema.tables WHERE table_type = 'VIEW';`
- `CASCADE` | Drop other views that depend on the view being dropped.<br><br>`CASCADE` does not list views it drops, so should be used cautiously.
- `RESTRICT`    | _(Default)_ Do not drop the view if other views depend on it.
-
-## Examples
-
-### Remove a view (no dependencies)
-
-In this example, other views do not depend on the view being dropped.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.tables WHERE table_type = 'VIEW';
-~~~
-
-~~~
-+---------------+-------------------+--------------------+------------+---------+
-| TABLE_CATALOG |   TABLE_SCHEMA    |     TABLE_NAME     | TABLE_TYPE | VERSION |
-+---------------+-------------------+--------------------+------------+---------+
-| def           | bank              | user_accounts      | VIEW       |       1 |
-| def           | bank              | user_emails        | VIEW       |       1 |
-+---------------+-------------------+--------------------+------------+---------+
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP VIEW bank.user_emails;
-~~~
-
-~~~
-DROP VIEW
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.tables WHERE table_type = 'VIEW';
-~~~
-
-~~~
-+---------------+-------------------+--------------------+------------+---------+
-| TABLE_CATALOG |   TABLE_SCHEMA    |     TABLE_NAME     | TABLE_TYPE | VERSION |
-+---------------+-------------------+--------------------+------------+---------+
-| def           | bank              | user_accounts      | VIEW       |       1 |
-+---------------+-------------------+--------------------+------------+---------+
-(1 row)
-~~~
-
-### Remove a view (with dependencies)
-
-In this example, another view depends on the view being dropped. Therefore, it's only possible to drop the view while simultaneously dropping the dependent view using `CASCADE`.
-
-{{site.data.alerts.callout_danger}}<code>CASCADE</code> drops <em>all</em> dependent views without listing them, which can lead to inadvertent and difficult-to-recover losses. To avoid potential harm, we recommend dropping objects individually in most cases.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.tables WHERE table_type = 'VIEW';
-~~~
-
-~~~
-+---------------+-------------------+--------------------+------------+---------+
-| TABLE_CATALOG |   TABLE_SCHEMA    |     TABLE_NAME     | TABLE_TYPE | VERSION |
-+---------------+-------------------+--------------------+------------+---------+
-| def           | bank              | user_accounts      | VIEW       |       1 |
-| def           | bank              | user_emails        | VIEW       |       1 |
-+---------------+-------------------+--------------------+------------+---------+
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP VIEW bank.user_accounts;
-~~~
-
-~~~
-pq: cannot drop view "user_accounts" because view "user_emails" depends on it
-~~~
-
-{% include copy-clipboard.html %}
-~~~sql
-> DROP VIEW bank.user_accounts CASCADE;
-~~~
-
-~~~
-DROP VIEW
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.tables WHERE table_type = 'VIEW';
-~~~
-
-~~~
-+---------------+-------------------+--------------------+------------+---------+
-| TABLE_CATALOG |   TABLE_SCHEMA    |     TABLE_NAME     | TABLE_TYPE | VERSION |
-+---------------+-------------------+--------------------+------------+---------+
-| def           | bank              | create_test        | VIEW       |       1 |
-+---------------+-------------------+--------------------+------------+---------+
-(1 row)
-~~~
-
-## See also
-
-- [Views](views.html)
-- [`CREATE VIEW`](create-view.html)
-- [`SHOW CREATE`](show-create.html)
-- [`ALTER VIEW`](alter-view.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/enable-node-map.md b/src/current/v20.2/enable-node-map.md
deleted file mode 100644
index b185e6ff6f2..00000000000
--- a/src/current/v20.2/enable-node-map.md
+++ /dev/null
@@ -1,198 +0,0 @@
----
-title: Enable the Node Map
-summary: Learn how to enable the node map in the DB Console.
-toc: true
----
-
-The **Node Map** is useful for:
-
-- Visualizing the geographic configuration of a multi-region cluster on a world map.
-- Viewing real-time cluster metrics.
-- Drilling down to individual nodes for monitoring health and performance.
-
-This page walks you through the process of setting up and enabling the Node Map.
-
-{{site.data.alerts.callout_info}}
-On a secure cluster, this area of the DB Console can only be accessed by an `admin` user. See [DB Console access](ui-overview.html#db-console-access).
-{{site.data.alerts.end}}
-
-{% include enterprise-feature.md %}
-
-<img src="{{ 'images/v20.2/ui-node-map-navigation3.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-## Set up and enable the Node Map
-
-To enable the Node Map, you need to start the cluster with the correct [`--locality`](cockroach-start.html#locality) flags and assign the latitude and longitude for each locality.
-
-{{site.data.alerts.callout_info}}
-The Node Map will not be displayed until *all* nodes are started with the correct `--locality` flags and all localities are assigned the corresponding latitude and longitude.
-{{site.data.alerts.end}}
-
-Consider a four-node geo-distributed cluster with the following configuration:
-
-|  Node | Region | Datacenter |
-|  ------ | ------ | ------ |
-|  Node1 | us-east-1 | us-east-1a |
-|  Node2 | us-east-1 | us-east-1b |
-|  Node3 | us-west-1 | us-west-1a |
-|  Node4 | eu-west-1 | eu-west-1a |
-
-### Step 1. Start the nodes with the correct `--locality` flags
-
-To start a new cluster with the correct `--locality` flags:
-
-Start Node 1:
-
-{% include copy-clipboard.html %}
-~~~
-$ cockroach start \
---insecure \
---locality=region=us-east-1,datacenter=us-east-1a  \
---advertise-addr=<node1 address> \
---cache=.25 \
---max-sql-memory=.25 \
---join=<node1 address>,<node2 address>,<node3 address>,<node4 address>
-~~~
-
-Start Node 2:
-
-{% include copy-clipboard.html %}
-~~~
-$ cockroach start \
---insecure \
---locality=region=us-east-1,datacenter=us-east-1b \
---advertise-addr=<node2 address> \
---cache=.25 \
---max-sql-memory=.25 \
---join=<node1 address>,<node2 address>,<node3 address>,<node4 address>
-~~~
-
-Start Node 3:
-
-{% include copy-clipboard.html %}
-~~~
-$ cockroach start \
---insecure \
---locality=region=us-west-1,datacenter=us-west-1a \
---advertise-addr=<node3 address> \
---cache=.25 \
---max-sql-memory=.25 \
---join=<node1 address>,<node2 address>,<node3 address>,<node4 address>
-~~~
-
-Start Node 4:
-
-{% include copy-clipboard.html %}
-~~~
-$ cockroach start \
---insecure \
---locality=region=eu-west-1,datacenter=eu-west-1a \
---advertise-addr=<node4 address> \
---cache=.25 \
---max-sql-memory=.25 \
---join=<node1 address>,<node2 address>,<node3 address>,<node4 address>
-~~~
-
-Use the [`cockroach init`](cockroach-init.html) command to perform a one-time initialization of the cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach init --insecure --host=<address of any node>
-~~~
-
-[Access the DB Console](ui-overview.html#db-console-access). The following page is displayed:
-
-<img src="{{ 'images/v20.2/ui-node-map-before-license.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-### Step 2. Set the Enterprise license and refresh the DB Console
-
-After [setting the Enterprise license](enterprise-licensing.html), the Node Map should now be displaying the highest-level localities you defined:
-
-<img src="{{ 'images/v20.2/ui-node-map-after-license.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-{{site.data.alerts.callout_info}}
-To be displayed on the world map, localities must be assigned a corresponding latitude and longitude.
-{{site.data.alerts.end}}
-
-### Step 3. Set the latitudes and longitudes for the localities
-
-Launch the built-in SQL client:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure --host=<address of any node>
-~~~
-
-Insert the approximate latitude and longitude of each region into the `system.locations` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO system.locations VALUES
-  ('region', 'us-east-1', 37.478397, -76.453077),
-  ('region', 'us-west-1', 38.837522, -120.895824),
-  ('region', 'eu-west-1', 53.142367, -7.692054);
-~~~
-
-For the latitudes and longitudes of AWS, Azure, and Google Cloud regions, see [Location Coordinates for Reference](#location-coordinates).
-
-### Step 4. Refresh the Node Map
-
-Refresh the DB Console to see the updated Node Map:
-
-<img src="{{ 'images/v20.2/ui-node-map-complete.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-### Step 5. Navigate the Node Map
-
-Let's say you want to navigate to Node 2, which is in datacenter `us-east-1a` in the `us-east-1` region:
-
-1. Click on the map component marked as **region=us-east-1** on the Node Map. The [locality component](ui-cluster-overview-page.html#locality-component) for the datacenter is displayed.
-
-	<img src="{{ 'images/v20.2/ui-node-map-navigation1.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-1. Click on the datacenter component marked as **datacenter=us-east-1a**. The individual [node components](ui-cluster-overview-page.html#node-component) are displayed.
-
-	<img src="{{ 'images/v20.2/ui-node-map-navigation2.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-1. To navigate back to the cluster view, either click on **Cluster** in the breadcrumb trail at the top of the Node Map, or click **Up to REGION=US-EAST-1** and then click **Up to CLUSTER** in the lower left-hand side of the Node Map.
-
-## Troubleshoot the Node Map
-
-### Node Map not displayed
-
-The Node Map requires an [Enterprise license](enterprise-licensing.html).
-
-All nodes in the cluster must be assigned [localities](cockroach-start.html#locality). To be displayed on the world map, localities must be [assigned a corresponding latitude and longitude](#step-3-set-the-latitudes-and-longitudes-for-the-localities).
-
-To verify both of the above, navigate to the Localities debug page (`https://<address of any node>:8080/#/reports/localities`) in the DB Console.
-
-<img src="{{ 'images/v20.2/ui-localities-debug.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-The Localities debug page displays the following:
-
-- Localities configuration that you set up while starting the nodes with the `--locality` flags.
-- Nodes corresponding to each locality.
-- Latitude and longitude coordinates for each locality/node.
-
-### World Map not displayed for all locality levels
-
-The world map is displayed only when [localities are assigned latitude/longitude coordinates](#step-3-set-the-latitudes-and-longitudes-for-the-localities).
-
-If a locality (e.g., region) is not assigned latitude/longitude coordinates, it is displayed using the latitude/longitude of any lower-level localities it contains (e.g., datacenter). If no coordinates are available, localities are plotted in a circular layout.
-
-### Displayed **Used Capacity** value is more than configured Capacity
-
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-
-## Location coordinates
-
-### AWS locations
-
-{% include {{ page.version.version }}/misc/aws-locations.md %}
-
-### Azure locations
-
-{% include {{ page.version.version }}/misc/azure-locations.md %}
-
-### Google Cloud locations
-
-{% include {{ page.version.version }}/misc/gce-locations.md %}
diff --git a/src/current/v20.2/encryption.md b/src/current/v20.2/encryption.md
deleted file mode 100644
index 257ee0c23e7..00000000000
--- a/src/current/v20.2/encryption.md
+++ /dev/null
@@ -1,228 +0,0 @@
----
-title: Encryption
-summary: Learn about the encryption features for secure CockroachDB clusters.
-toc: true
----
-
-Data encryption and decryption is the process of transforming plaintext data to cipher-text and vice versa using a key or password.
-
-## Encryption in flight
-
-CockroachDB uses TLS 1.2 for inter-node and client-node [authentication](authentication.html) as well as setting up a secure communication channel. Once the secure channel is set up, all inter-node and client-node network communication is encrypted using a [shared encryption key](https://en.wikipedia.org/wiki/Transport_Layer_Security) as per the TLS 1.2 protocol. This feature is enabled by default for all secure clusters and needs no additional configuration.
-
-## Encryption at Rest (Enterprise)
-
-Encryption at Rest provides transparent encryption of a node's data on the local disk. It allows encryption of all files on disk using [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) in [counter mode](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)), with all key
-sizes allowed.
-
-Encryption is performed in the [storage layer](architecture/storage-layer.html) and configured per store.
-All files used by the store, regardless of contents, are encrypted with the desired algorithm.
-
-To allow arbitrary rotation schedules and ensure security of the keys, we use two layers of keys:
-
-- **Store keys** are provided by the user in a file. They are used to encrypt the list of data keys (see below). This is known as a **key encryption key**: its only purpose is to encrypt other keys. Store keys are never persisted by CockroachDB. Since very little data is encrypted using this key, it can have a very long lifetime without risk of reuse.
-
-- **Data keys** are automatically generated by CockroachDB. They are used to encrypt all files on disk. This is known as a **data encryption key**. Data keys are persisted in a key registry file, encrypted using the store key. The key has a short lifetime to avoid reuse.
-
-Store keys are specified at node startup by passing a path to a locally readable file. The file must contain 32 bytes (the key ID) followed by the key (16, 24, or 32 bytes). The size of the key dictates the version of AES to use (AES-128, AES-192, or AES-256). For an example showing how to create a store key, see [Generating key files](#generating-store-key-files) below.
-
-Also during node startup, CockroachDB uses a data key with the same length as the store key. If encryption has just been enabled,
-the key size has changed, or the data key is too old (default lifetime is one week), CockroachDB generates a new data key.
-
-Any new file created by the store uses the currently-active data key. All data keys (both active and previous) are stored in a key registry file and encrypted with the active store key.
-
-After startup, if the active data key is too old, CockroachDB generates a new data key and marks it as active, using it for all further encryption.
-
-CockroachDB does not currently force re-encryption of older files but instead relies on normal [storage engine](architecture/storage-layer.html) churn to slowly rewrite all data with the desired encryption.
-
-### Rotating keys
-
-Key rotation is necessary for Encryption at Rest for multiple reasons:
-
-- To prevent key reuse with the same encryption parameters (after encrypting many files).
-- To reduce the risk of key exposure.
-
-Store keys are specified by the user and must be rotated by specifying different keys.
-This is done by setting the `key` parameter of the `--enterprise-encryption` flag to the path to the new key,
-and `old-key` to the previously-used key.
-
-Data keys will automatically be rotated at startup if any of the following conditions are met:
-
-- The active store key has changed.
-- The encryption type has changed (different key size, or plaintext to/from encryption).
-- The current data key is `rotation-period` old or more.
-
-Data keys will automatically be rotated at runtime if the current data key is `rotation-period` old or more.
-
-Once rotated, an old store key cannot be made the active key again.
-
-Upon store key rotation the data keys registry is decrypted using the old key and encrypted with the new
-key. The newly-generated data key is used to encrypt all new data from this point on.
-
-### Changing encryption type
-
-The user can change the encryption type from plaintext to encryption, between different encryption algorithms (using various key sizes), or from encryption to plaintext.
-
-When changing the encryption type to plaintext, the data key registry is no longer encrypted and all previous data keys are readable by anyone. All data on the store is effectively readable.
-
-When changing from plaintext to encryption, it will take some time for all data to eventually be re-written and encrypted.
-
-### Recommendations
-
-There are a number of considerations to keep in mind when running with encryption.
-
-#### Deployment configuration
-
-To prevent key leakage, production deployments should:
-
-* Use encrypted swap, or disable swap entirely.
-* Disable core files.
-
-CockroachDB attempts to disable core files at startup when encryption is requested, but it may fail.
-
-#### Key handling
-
-Key management is the most dangerous aspect of encryption. The following rules should be kept in mind:
-
-* Make sure that only the UNIX user running the `cockroach` process has access to the keys.
-* Do not store the keys on the same partition/drive as the CockroachDB data. It is best to load keys at run time from a separate system (e.g., [Keywhiz](https://square.github.io/keywhiz/), <a href="https://www.hashicorp.com/product/vault" data-proofer-ignore>Vault</a>).
-* Rotate store keys frequently (every few weeks to months).
-* Keep the data key rotation period low (default is one week).
-
-#### Other recommendations
-
-A few other recommendations apply for best security practices:
-
-* Do not switch from encrypted to plaintext, this leaks data keys. When plaintext is selected, all previously encrypted data must be considered reachable.
-* Do not copy the encrypted files, as the data keys are not easily available.
-* If encryption is desired, start a node with it enabled from the first run, without ever running in plaintext.
-
-{{site.data.alerts.callout_danger}}
-Note that backups taken with the [`BACKUP`](backup.html) statement **are not encrypted** even if Encryption at Rest is enabled. Encryption at Rest only applies to the CockroachDB node's data on the local disk. If you want encrypted backups, you will need to encrypt your backup files using your preferred encryption method.
-{{site.data.alerts.end}}
-
-### Examples
-
-#### Generating store key files
-
-Cockroach determines which encryption algorithm to use based on the size of the key file.
-The key file must contain random data making up the key ID (32 bytes) and the actual key (16, 24, or 32
-bytes depending on the encryption algorithm).
-
-| Algorithm | Key size | Key file size |
-|-|-|-|
-| AES-128 | 128 bits (16 bytes) | 48 bytes |
-| AES-192 | 192 bits (24 bytes) | 56 bytes |
-| AES-256 | 256 bits (32 bytes) | 64 bytes |
-
-Generating a key file can be done using the `cockroach` CLI:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach gen encryption-key -s 128 /path/to/my/aes-128.key
-~~~
-
-Or the equivalent [openssl](https://www.openssl.org/docs/man1.1.1/man1/openssl.html) CLI command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ openssl rand -out /path/to/my/aes-128.key 48
-~~~
-
-#### Starting a node with encryption
-
-Encryption at Rest is configured at node start time using the `--enterprise-encryption` command line flag.
-The flag specifies the encryption options for one of the stores on the node. If multiple stores exist,
-the flag must be specified for each store.
-
-The flag takes the form: `--enterprise-encryption=path=<store path>,key=<key file>,old-key=<old key file>,rotation-period=<period>`.
-
-The allowed components in the flag are:
-
-| Component | Requirement | Description |
-|-|-|-|
-| `path`            | Required | Path of the store to apply encryption to. |
-| `key`             | Required | Path to the key file to encrypt data with, or `plain` for plaintext. |
-| `old-key`         | Required | Path to the key file the data is encrypted with, or `plain` for plaintext. |
-| `rotation-period` | Optional | How often data keys should be automatically rotated. Default: one week. |
-
-The `key` and `old-key` components must **always** be specified. They allow for transitions between
-encryption algorithms, and between plaintext and encrypted.
-
-Starting a node for the first time using AES-128 encryption can be done using:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start --store=cockroach-data --enterprise-encryption=path=cockroach-data,key=/path/to/my/aes-128.key,old-key=plain
-~~~
-
-{{site.data.alerts.callout_danger}}
-Once specified for a given store, the `--enterprise-encryption` flag must always be present.
-{{site.data.alerts.end}}
-
-#### Checking encryption status
-
-Encryption status can be seen on the node's stores report, reachable through: `http(s)://nodeaddress:8080/#/reports/stores/local` (or replace `local` with the node ID). For example, if you are running a [local cluster](secure-a-cluster.html), you can see the node's stores report at `https://localhost:8080/#/reports/stores/local`.
-
-The report shows encryption status for all stores on the selected node, including:
-
-* Encryption algorithm.
-* Active store key information.
-* Active data key information.
-* The fraction of files/bytes encrypted using the active data key.
-
-CockroachDB relies on [storage layer](architecture/storage-layer.html) compactions to write new files using the latest encryption key. It may take several days for all files to be replaced. Some files are only rewritten at startup, and some keep older copies around, requiring multiple restarts. You can force storage compaction with the `cockroach debug compact` command (the node must first be [stopped](cockroach-quit.html)).
-
-Information about keys is written to [the logs](debug-and-error-logs.html), including:
-
-* Active/old key information at startup.
-* New key information after data key rotation.
-
-Alternatively, you can use the [`cockroach debug encryption-active-key`](cockroach-debug-encryption-active-key.html) command to view information about a store's encryption algorithm and store key.
-
-#### Changing encryption algorithm or keys
-
-Encryption type and keys can be changed at any time by restarting the node.
-To change keys or encryption type, the `key` component of the `--enterprise-encryption` flag is set to the new key,
-while the key previously used must be specified in the `old-key` component.
-
-For example, we can switch from AES-128 to AES-256 using:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start --store=cockroach-data --enterprise-encryption=path=cockroach-data,key=/path/to/my/aes-256.key,old-key=/path/to/my/aes-128.key
-~~~
-
-Upon starting, the node will read the existing data keys using the old encryption key (`aes-128.key`), then rewrite
-the data keys using the new key (`aes-256.key`). A new data key will be generated to match the desired AES-256 algorithm.
-
-To check that the new key is active, use the stores report page in the DB Console to [check the encryption status](#checking-encryption-status).
-
-To disable encryption, specify `key=plain`. The data keys will be stored in plaintext and new data will not be encrypted.
-
-To rotate keys, specify `key=/path/to/my/new-aes-128.key` and `old-key=/path/to/my/old-aes-128.key`. The data keys
-will be decrypted using the old key and then encrypted using the new key. A new data key will also be generated.
-
-## Encrypted backups (Enterprise)
-
-{% include {{ page.version.version }}/backups/encrypted-backup-description.md %}
-
-## Encryption caveats
-
-### Higher CPU utilization
-
-Enabling Encryption at Rest might result in a higher CPU utilization. We estimate a 5-10% increase in CPU utilization.
-
-### Encryption for touchpoints with other services
-
-- S3 backup encryption
-- Encrypted comms with Kafka
-
-
-## See also
-
-- [Client Connection Parameters](connection-parameters.html)
-- [Manual Deployment](manual-deployment.html)
-- [Orchestrated Deployment](orchestration.html)
-- [Local Deployment](secure-a-cluster.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/enterprise-licensing.md b/src/current/v20.2/enterprise-licensing.md
deleted file mode 100644
index 5f3b0742216..00000000000
--- a/src/current/v20.2/enterprise-licensing.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: Enterprise Features
-summary: Learn about CockroachDB features that require an Enterprise license key.
-toc: true
----
-
-CockroachDB distributes a single binary that contains both core and Enterprise features. You can use core features without any license key. However, to use the Enterprise features, you need either a trial or an Enterprise license key.
-
-This page lists Enterprise features. For information on how to obtain and set trial and Enterprise license keys for CockroachDB, see the [Licensing FAQs](licensing-faqs.html#obtain-a-license).
-
-{% include {{ page.version.version }}/misc/enterprise-features.md %}
-
-## See also
-
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`SHOW CLUSTER SETTING`](show-cluster-setting.html)
-- [Enterprise Trial –– Get Started](get-started-with-enterprise-trial.html)
diff --git a/src/current/v20.2/enum.md b/src/current/v20.2/enum.md
deleted file mode 100644
index bad849d1c5d..00000000000
--- a/src/current/v20.2/enum.md
+++ /dev/null
@@ -1,226 +0,0 @@
----
-title: ENUM
-summary: CockroachDB's CockroachDB's ENUM data types comprise a set of values.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> User-defined `ENUM` [data types](data-types.html) consist of a set of enumerated, static values.
-
-{{site.data.alerts.callout_danger}}
-Clusters with `ENUM` types that are running alpha testing [releases](../releases/) of v20.2 will not be able to upgrade to beta testing releases or production releases of v20.2 due to internal representation changes.
-{{site.data.alerts.end}}
-
-## Syntax
-
-To declare a new `ENUM` data type, use [`CREATE TYPE`](create-type.html):
-
-~~~ sql
-> CREATE TYPE <name> AS ENUM ('<value1>', '<value2>', ...);
-~~~
-
-where `<name>` is the name of the new type, and `<value1>, <value2>, ...` are string literals that make up the type's set of static values.
-
-{{site.data.alerts.callout_info}}
-You can qualify the `<name>` of an enumerated type with a [database and schema name](sql-name-resolution.html) (e.g., `db.typename`). After the type is created, it can only be referenced from the database that contains the type.
-{{site.data.alerts.end}}
-
-To show all `ENUM` types in the database, including all `ENUMS` created implicitly for [multi-region databases](multi-region-overview.html), use [`SHOW ENUMS`](show-enums.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-To modify an `ENUM` type, use [`ALTER TYPE`](alter-type.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TYPE <name> ADD VALUE '<value>';
-~~~
-
-where `<value>` is a string literal to add to the existing list of type values. You can also use `ALTER TYPE` to rename types, rename type values, set a type's schema, or change the type owner's [role specification](grant-roles.html).
-
-To drop the type, use [`DROP TYPE`](drop-type.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TYPE <name>;
-~~~
-
-## Required privileges
-
-- To [create a type](create-type.html) in a database, a user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the database.
-- To [drop a type](drop-type.html), a user must be the owner of the type.
-- To [alter a type](alter-type.html), a user must be the owner of the type.
-- To [grant privileges](grant.html) on a type, a user must have the `GRANT` privilege and the privilege that they want to grant.
-- To create an object that depends on a type, a user must have the `USAGE` privilege on the type.
-
-## Known limitations
-
-[Partitions](partitioning.html) cannot be created on columns of type `ENUM`. See [tracking issue](https://github.com/cockroachdb/cockroach/issues/55342).
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE status AS ENUM ('open', 'closed', 'inactive');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema |  name  |        value
----------+--------+-----------------------
-  public | status | open|closed|inactive
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE accounts (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        balance DECIMAL,
-        status status
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO accounts(balance,status) VALUES (500.50,'open'), (0.00,'closed'), (1.25,'inactive');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-                   id                  | balance |  status
----------------------------------------+---------+-----------
-  3848e36d-ebd4-44c6-8925-8bf24bba957e |  500.50 | open
-  60928059-ef75-47b1-81e3-25ec1fb6ff10 |    0.00 | closed
-  71ae151d-99c3-4505-8e33-9cda15fce302 |    1.25 | inactive
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE accounts;
-~~~
-
-~~~
-  table_name |                create_statement
--------------+--------------------------------------------------
-  accounts   | CREATE TABLE public.accounts (
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     balance DECIMAL NULL,
-             |     status public.status NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     FAMILY "primary" (id, balance, status)
-             | )
-(1 row)
-~~~
-
-
-## Supported casting and conversion
-
-`ENUM` data type values can be [cast](data-types.html#data-type-conversions-and-casts) to [`STRING`s](string.html).
-
-Values can be cast explicitly or implicitly. For example, the following [`SELECT`](select-clause.html) statements are equivalent:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts WHERE status::STRING='open';
-~~~
-
-~~~
-                   id                  | balance | status
----------------------------------------+---------+---------
-  3848e36d-ebd4-44c6-8925-8bf24bba957e |  500.50 | open
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts WHERE status='open';
-~~~
-
-~~~
-                   id                  | balance | status
----------------------------------------+---------+---------
-  3848e36d-ebd4-44c6-8925-8bf24bba957e |  500.50 | open
-(1 row)
-~~~
-
-### Comparing enumerated types
-
-To compare two enumerated types, you must explicitly cast both types as `STRING`s. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE inaccessible AS ENUM ('closed', 'inactive');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE notifications (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        status inaccessible,
-        message STRING
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO notifications(status, message) VALUES ('closed', 'This account has been closed.'),('inactive', 'This account is on hold.');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT
-    accounts.id, notifications.message
-    FROM accounts JOIN notifications ON accounts.status = notifications.status;
-~~~
-
-~~~
-ERROR: unsupported comparison operator: <status> = <inaccessible>
-SQLSTATE: 22023
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT
-    accounts.id, notifications.message
-    FROM accounts JOIN notifications ON accounts.status::STRING = notifications.status;
-~~~
-
-~~~
-ERROR: unsupported comparison operator: <string> = <inaccessible>
-SQLSTATE: 22023
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT
-    accounts.id, notifications.message
-    FROM accounts JOIN notifications ON accounts.status::STRING = notifications.status::STRING;
-~~~
-
-~~~
-                   id                  |            message
----------------------------------------+--------------------------------
-  285336c4-ca1f-490d-b0df-146aae94f5aa | This account is on hold.
-  583157d5-4f34-43e5-a4d4-51db77feb391 | This account has been closed.
-(2 rows)
-~~~
-
-## See also
-
-- [Data Types](data-types.html)
-- [`CREATE TYPE`](create-type.html)
-- [`ALTER TYPE`](alter-type.html)
-- [`SHOW ENUMS`](show-enums.html)
-- [`DROP TYPE`](drop-type.html)
diff --git a/src/current/v20.2/error-handling-and-troubleshooting.md b/src/current/v20.2/error-handling-and-troubleshooting.md
deleted file mode 100644
index 457e9ea6c15..00000000000
--- a/src/current/v20.2/error-handling-and-troubleshooting.md
+++ /dev/null
@@ -1,98 +0,0 @@
----
-title: Error Handling and Troubleshooting
-summary: How to troubleshoot problems and handle transaction retry errors during application development
-toc: true
----
-
-This page has instructions for handling errors and troubleshooting problems that may arise during application development.
-
-## Troubleshooting query problems
-
-If you are not satisfied with your SQL query performance, follow the instructions in [Optimize Query Performance][fast] to be sure you are avoiding common performance problems like full table scans, missing indexes, etc.
-
-If you have already optimized your SQL queries as described in [Optimize Query Performance][fast] and are still having issues such as:
-
-- Hanging or "stuck" queries
-- Queries that are slow some of the time (but not always)
-- Low throughput of queries
-
-Take a look at [Troubleshoot SQL Behavior](query-behavior-troubleshooting.html).
-
-{{site.data.alerts.callout_info}}
-If you aren't sure whether SQL query performance needs to be improved on your cluster, see [Identify slow queries](query-behavior-troubleshooting.html#identify-slow-queries).
-{{site.data.alerts.end}}
-
-## Transaction retry errors
-
-Messages with the Postgres error code `40001` indicate that a transaction failed because it [conflicted with another concurrent or recent transaction accessing the same data](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). The transaction needs to be retried by the client.
-
-If your language's client driver or ORM implements transaction retry logic internally (e.g., if you are using Python and [SQLAlchemy with the CockroachDB dialect](build-a-python-app-with-cockroachdb-sqlalchemy.html)), then you do not need to handle this logic from your application.
-
-If your driver or ORM does not implement this logic, then you will need to implement a retry loop in your application.
-
-{% include {{page.version.version}}/misc/client-side-intervention-example.md %}
-
-{{site.data.alerts.callout_info}}
-If a consistently high percentage of your transactions are resulting in transaction retry errors, then you may need to evaluate your schema design and data access patterns to find and remove sources of contention. For more information about contention, see [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-
-For more information about what is causing a specific transaction retry error code, see the [Transaction Retry Error Reference](transaction-retry-error-reference.html).
-{{site.data.alerts.end}}
-
-For more information about transaction retry errors, see [Transaction retries](transactions.html#client-side-intervention).
-
-## Unsupported SQL features
-
-CockroachDB has support for [most SQL features](sql-feature-support.html).
-
-Additionally, CockroachDB supports [the PostgreSQL wire protocol and the majority of its syntax](postgresql-compatibility.html). This means that existing applications can often be migrated to CockroachDB without changing application code.
-
-However, you may encounter features of SQL or the Postgres dialect that are not supported by CockroachDB. For example, the following Postgres features are not supported:
-
-{% include {{page.version.version}}/sql/unsupported-postgres-features.md %}
-
-For more information about the differences between CockroachDB and Postgres feature support, see [PostgreSQL Compatibility](postgresql-compatibility.html).
-
-For more information about the SQL standard features supported by CockroachDB, see [SQL Feature Support](sql-feature-support.html)
-
-## Troubleshooting cluster problems
-
-As a developer, you will mostly be working with the CockroachDB [SQL API](sql-statements.html).
-
-However, you may need to access the underlying cluster to troubleshoot issues where the root cause is not your SQL, but something happening at the cluster level. Symptoms of cluster-level issues can include:
-
-- Cannot join a node to an existing cluster
-- Networking, client connection, or authentication issues
-- Clock sync, replication, or node liveness issues
-- Capacity planning, storage, or memory issues
-- Node decommissioning failures
-
-For more information about how to troubleshoot cluster-level issues, see [Troubleshoot Cluster Setup](cluster-setup-troubleshooting.html).
-
-## See also
-
-Reference information related to this page:
-
-- [Troubleshoot Query Behavior](query-behavior-troubleshooting.html)
-- [Troubleshoot Cluster Setup](cluster-setup-troubleshooting.html)
-- [Common errors](common-errors.html)
-- [Transactions](transactions.html)
-- [Transaction retries](transactions.html#client-side-intervention)
-- [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention)
-- [SQL Layer][sql]
-
-Other common tasks:
-
-- [Connect to the Database](connect-to-the-database.html)
-- [Insert Data](insert-data.html)
-- [Query Data](query-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-- [Run Multi-Statement Transactions](run-multi-statement-transactions.html)
-- [Identify slow queries](query-behavior-troubleshooting.html#identify-slow-queries)
-- [Optimize Query Performance][fast]
-- [Hello World Example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[sql]: architecture/sql-layer.html
-[fast]: make-queries-fast.html
diff --git a/src/current/v20.2/example-apps.md b/src/current/v20.2/example-apps.md
deleted file mode 100644
index 02fed587a89..00000000000
--- a/src/current/v20.2/example-apps.md
+++ /dev/null
@@ -1,96 +0,0 @@
----
-title: Example Apps
-summary: Examples that show you how to build simple applications with CockroachDB
-tags: golang, python, java
-toc: true
-key: build-an-app-with-cockroachdb.html
----
-
-The examples in this section show you how to build simple applications using CockroachDB.
-
-Click the links in the tables below to see simple but complete example applications for each supported language and library combination.
-
-If you are looking to do a specific task such as connect to the database, insert data, or run multi-statement transactions, see [this list of tasks](#tasks).
-
-{{site.data.alerts.callout_info}}
-Applications may encounter incompatibilities when using advanced or obscure features of a driver or ORM with **beta-level** support. If you encounter problems, please [open an issue](https://github.com/cockroachdb/cockroach/issues/new) with details to help us make progress toward full support.
-
-Note that tools with [**community-level** support](community-tooling.html) have been tested or developed by the CockroachDB community, but are not officially supported by Cockroach Labs. If you encounter problems with using these tools, please contact the maintainer of the tool with details.
-{{site.data.alerts.end}}
-
-## JavaScript/TypeScript
-
-| Driver/ORM Framework                                    | Support level  | Example apps                                            |
-|---------------------------------------------------------+----------------+--------------------------------------------------------|
-| [node-postgres](https://www.npmjs.com/package/pg)       | Full           | [Simple CRUD](build-a-nodejs-app-with-cockroachdb.html)
-| [Sequelize](https://www.npmjs.com/package/sequelize)    | Full           | [Simple CRUD](build-a-nodejs-app-with-cockroachdb-sequelize.html)
-| [TypeORM](https://www.npmjs.com/package/typeorm)        | Full           | [Simple CRUD](build-a-typescript-app-with-cockroachdb.html)
-
-## Python
-
-| Driver/ORM Framework                                            | Support level  | Example apps                                            |
-|-----------------------------------------------------------------+----------------+--------------------------------------------------------|
-| [psycopg2](https://www.psycopg.org/docs/install.html)           | Full           | [Simple CRUD](build-a-python-app-with-cockroachdb.html)
-| [SQLAlchemy](https://www.sqlalchemy.org/)                       | Full           | [Simple CRUD](build-a-python-app-with-cockroachdb-sqlalchemy.html)<br>[MovR-Flask (Global Web App)](multi-region-overview.html)
-| [Django](https://pypi.org/project/Django/)                      | Full           | [Simple CRUD](build-a-python-app-with-cockroachdb-django.html)
-| [PonyORM](https://ponyorm.org/)                                 | Full           | [Simple CRUD](build-a-python-app-with-cockroachdb-pony.html)
-
-## Go
-
-| Driver/ORM Framework                             | Support level  | Example apps                                            |
-|--------------------------------------------------+----------------+--------------------------------------------------------|
-| [pgx](https://github.com/jackc/pgx/releases)     | Full           | [Simple CRUD](build-a-go-app-with-cockroachdb.html)
-| [GORM](https://github.com/jinzhu/gorm/releases)  | Full           | [Simple CRUD](build-a-go-app-with-cockroachdb-gorm.html)
-| [pq](https://github.com/lib/pq)                  | Full           | [Simple CRUD](build-a-go-app-with-cockroachdb-pq.html)
-| [upper/db](https://github.com/upper/db)          | Full           | [Simple CRUD](build-a-go-app-with-cockroachdb-upperdb.html)
-
-## Java
-
-| Driver/ORM Framework                       | Support level  | Example apps                                            |
-|--------------------------------------------+----------------+--------------------------------------------------------|
-| [JDBC](https://jdbc.postgresql.org/)       | Full           | [Simple CRUD](build-a-java-app-with-cockroachdb.html)<br>[Roach Data (Spring Boot App)](build-a-spring-app-with-cockroachdb-jdbc.html)
-| [Hibernate](https://hibernate.org/orm/)    | Full           | [Simple CRUD](build-a-java-app-with-cockroachdb-hibernate.html)<br>[Roach Data (Spring Boot App)](build-a-spring-app-with-cockroachdb-jpa.html)
-| [jOOQ](https://www.jooq.org/)              | Full           | [Simple CRUD](build-a-java-app-with-cockroachdb-jooq.html)
-
-## Ruby
-
-| Driver/ORM Framework                                      | Support level  | Example apps                                            |
-|-----------------------------------------------------------+----------------+--------------------------------------------------------|
-| [pg](https://rubygems.org/gems/pg)                        | Full           | [Simple CRUD](build-a-ruby-app-with-cockroachdb.html)
-| [ActiveRecord](https://rubygems.org/gems/activerecord)    | Full           | [Simple CRUD](build-a-ruby-app-with-cockroachdb-activerecord.html)
-
-## C#
-
-| Driver/ORM Framework                                      | Support level  | Example apps                                           |
-|-----------------------------------------------------------+----------------+--------------------------------------------------------|
-| [Npgsql](https://www.npgsql.org/)                         | Beta           | [Simple CRUD](build-a-csharp-app-with-cockroachdb.html)
-
-## Rust
-
-| Driver/ORM Framework                           | Support level  | Example apps                                           |
-|------------------------------------------------+----------------+--------------------------------------------------------|
-| [Rust-Postgres](https://github.com/sfackler/rust-postgres) | Beta      | [Simple CRUD](build-a-rust-app-with-cockroachdb.html)
-
-## See also
-
-Reference information:
-
-- [Client drivers](install-client-drivers.html)
-- [Third-Party Tools Supported by Cockroach Labs](third-party-database-tools.html)
-- [Third-Party Tools Supported by the Community](community-tooling.html)
-- [Connection parameters](connection-parameters.html)
-- [Transactions](transactions.html)
-- [Performance best practices](performance-best-practices-overview.html)
-
-<a name="tasks"></a>
-
-Specific tasks:
-
-- [Connect to the Database](connect-to-the-database.html)
-- [Insert Data](insert-data.html)
-- [Query Data](query-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-- [Optimize Statement Performance](make-queries-fast.html)
-- [Run Multi-Statement Transactions](run-multi-statement-transactions.html)
-- [Error Handling and Troubleshooting](error-handling-and-troubleshooting.html)
diff --git a/src/current/v20.2/experimental-audit.md b/src/current/v20.2/experimental-audit.md
deleted file mode 100644
index 9d188d0282d..00000000000
--- a/src/current/v20.2/experimental-audit.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-title: EXPERIMENTAL_AUDIT
-summary: Use the EXPERIMENTAL_AUDIT subcommand to turn SQL audit logging on or off for a table.
-toc: true
----
-
-`EXPERIMENTAL_AUDIT` is a subcommand of [`ALTER TABLE`](alter-table.html) that is used to turn SQL audit logging on or off for a table.
-
-SQL audit logs contain detailed information about queries being executed against your system, including:
-
-- Full text of the query (which may include personally identifiable information (PII))
-- Date/Time
-- Client address
-- Application name
-
-For a detailed description of exactly what is logged, see the [Audit Log File Format](#audit-log-file-format) section below.
-
-CockroachDB stores audit log information in a way that ensures durability, but negatively impacts performance. As a result, we recommend using SQL audit logs for security purposes only. For more information, see [Performance considerations](#performance-considerations).
-
-{% include {{ page.version.version }}/misc/experimental-warning.md %}
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/experimental_audit.html %}
-</div>
-
-## Required privileges
-
-Only members of the `admin` role can enable audit logs on a table. By default, the `root` user belongs to the `admin` role.
-
-## Parameters
-
- Parameter    | Description                                              
---------------+----------------------------------------------------------
- `table_name` | The name of the table you want to create audit logs for.
- `READ`       | Log all table reads to the audit log file.               
- `WRITE`      | Log all table writes to the audit log file.              
- `OFF`        | Turn off audit logging.                                  
-
-{{site.data.alerts.callout_info}}
-This command logs all reads and writes, and both the <code>READ</code> and <code>WRITE</code> parameters are required (as shown in the <a href="#examples">examples</a> below). Logging for only reads or only writes is not supported.
-{{site.data.alerts.end}}
-
-## Audit log file format
-
-The audit log file format is as shown below.  The numbers above each column are not part of the format; they correspond to the descriptions that follow.
-
-~~~
-[1]     [2]             [3]   [4]                  [5]                                          [6] [7a]   [7b]                 [7c]                    [7d]                                 [7e] [7f] [7g] [7h]  [7i]
-I201028 16:09:42.905889 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 12 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ}› ‹"SELECT nonexistent FROM customers"› ‹{}› 0.206 0 ‹ERROR› 0
-~~~
-
-1. Log level (`INFO`, `WARN`, `ERROR`, or `FATAL`) and date (in YYMMDD format)
-2. Time (in UTC)
-3. Goroutine ID. This column is used for troubleshooting CockroachDB and may change its meaning at any time.
-4. Where the log line was generated
-5. Logging tags (the contents and order may vary)
-   - Client address
-   - Username
-   - Node ID
-6. Log entry counter
-7. Log message:
-   - a. Label indicating where the data was generated (useful for troubleshooting)
-   - b. Current value of the [`application_name`](set-vars.html) session setting
-   - c. Logging trigger:
-       - The list of triggering tables and access modes for audit logs, since only certain (read/write) activities are added to the audit log
-   - d. Full text of the query (Note: May contain PII)
-   - e. Placeholder values, if any
-   - f. Query execution time (in milliseconds)
-   - g. Number of rows produced (e.g., for `SELECT`) or processed (e.g., for `INSERT` or `UPDATE`).
-   - h. Status of the query
-       - `OK` for success
-       - `ERROR` otherwise
-   - i. Number of times the statement was [retried automatically](transactions.html#automatic-retries) by the server so far.
-
-## Audit log file storage location
-
-By default, audit logs are stored in the [same directory](debug-and-error-logs.html#write-to-file) as the other logs generated by CockroachDB.
-
-To store the audit log files in a specific directory, pass the `--sql-audit-dir` flag to [`cockroach start`](cockroach-start.html).
-
-{{site.data.alerts.callout_success}}
-If your deployment requires particular lifecycle and access policies for audit log files, point `--sql-audit-dir` at a directory that has permissions set so that only CockroachDB can create/delete files.
-{{site.data.alerts.end}}
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Performance considerations
-
-To ensure [non-repudiation](https://en.wikipedia.org/wiki/Non-repudiation) in audit logs, CockroachDB synchronously logs all of the activity of every user on a cluster in a way that is durable to system failures. Every query that causes a logging event must access the disk of the node on which audit logging is enabled. As a result, enabling SQL audit logs negatively impacts performance, and we recommend using SQL audit logs for security purposes only.
-
-For debugging and troubleshooting on production clusters, the most performant way to log all queries is to turn on the [cluster-wide setting](cluster-settings.html) `sql.trace.log_statement_execute`. For details, see [Troubleshoot Query Behavior](query-behavior-troubleshooting.html#cluster-wide-execution-logs).
-
-## Examples
-
-### Turn on audit logging
-
-Let's say you have a  `customers` table that contains personally identifiable information (PII). To turn on audit logs for that table, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE customers EXPERIMENTAL_AUDIT SET READ WRITE;
-~~~
-
-Now, every access of customer data is added to the audit log with a line that looks like the following:
-
-~~~
-I201028 16:09:18.076615 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 11 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ}› ‹"SELECT * FROM customers"› ‹{}› 0.447 2 ‹OK› 0
-I201028 16:09:42.905889 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 12 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ}› ‹"SELECT nonexistent FROM customers"› ‹{}› 0.206 0 ‹ERROR› 0
-~~~
-
-To turn on auditing for more than one table, issue a separate `ALTER` statement for each table.
-
-For a description of the log file format, see the [Audit Log File Format](#audit-log-file-format) section.
-
-{{site.data.alerts.callout_success}}
-For a more detailed example, see [SQL Audit Logging](sql-audit-logging.html).
-{{site.data.alerts.end}}
-
-### Turn off audit logging
-
-To turn off logging, issue the following command:
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE customers EXPERIMENTAL_AUDIT SET OFF;
-~~~
-
-## See also
-
-- [SQL Audit Logging](sql-audit-logging.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`cockroach start` logging flags](cockroach-start.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/experimental-features.md b/src/current/v20.2/experimental-features.md
deleted file mode 100644
index 4eb9824376c..00000000000
--- a/src/current/v20.2/experimental-features.md
+++ /dev/null
@@ -1,171 +0,0 @@
----
-title: Experimental Features
-summary: Learn about the experimental features available in CockroachDB
-toc: true
----
-
-This page lists the experimental features that are available in CockroachDB {{ page.version.version }}.
-
-{{site.data.alerts.callout_danger}}
-**This page describes experimental features.**  Their interfaces and outputs are subject to change, and there may be bugs.
-<br />
-<br />
-If you encounter a bug, please [file an issue](file-an-issue.html).
-{{site.data.alerts.end}}
-
-## Session variables
-
-The table below lists the experimental session settings that are available.  For a complete list of session variables, see [`SHOW` (session settings)](show-vars.html).
-
-| Variable                            | Default Value | Description                                                                                                                                                                                                                                                                                             |
-|-------------------------------------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `experimental_enable_hash_sharded_indexes`       | `'off'`       |  If set to `'on'`, enables [hash-sharded indexes](#hash-sharded-indexes) with `USING HASH`.                                                                                                                                                                                   |
-| `experimental_enable_temp_tables`       | `'off'`       |  If set to `'on'`, enables [temporary objects](#temporary-objects), including [temporary tables](temporary-tables.html), [temporary views](views.html#temporary-views), and [temporary sequences](create-sequence.html#temporary-sequences).                                                                                                                                                                                   |
-
-## SQL statements
-
-### Keep SQL audit logs
-
-Log all queries against a table to a file, for security purposes. For more information, see [`ALTER TABLE ... EXPERIMENTAL_AUDIT`](experimental-audit.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE t EXPERIMENTAL_AUDIT SET READ WRITE;
-~~~
-
-### Relocate leases and replicas
-
-You have the following options for controlling lease and replica location:
-
-1. Relocate leases and replicas using `EXPERIMENTAL_RELOCATE`
-2. Relocate just leases using `EXPERIMENTAL_RELOCATE LEASE`
-
-For example, to distribute leases and ranges for N primary keys across N stores in the cluster, run a statement with the following structure:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE t EXPERIMENTAL_RELOCATE SELECT ARRAY[<storeid1>, <storeid2>, ..., <storeidN>], <primarykeycol1>, <primarykeycol2>, ..., <primarykeycolN>;
-~~~
-
-To relocate just the lease without moving the replicas, run a statement like the one shown below, which moves the lease for the range containing primary key 'foo' to store 1.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE t EXPERIMENTAL_RELOCATE LEASE SELECT 1, 'foo';
-~~~
-
-### Show table fingerprints
-
-Table fingerprints are used to compute an identification string of an entire table, for the purpose of gauging whether two tables have the same data. This is useful, for example, when restoring a table from backup.
-
-Example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW EXPERIMENTAL_FINGERPRINTS FROM TABLE t;
-~~~
-
-~~~
- index_name |     fingerprint     
-------------+---------------------
- primary    | 1999042440040364641
-(1 row)
-~~~
-
-### Turn on KV event tracing
-
-Use session tracing (via [`SHOW TRACE FOR SESSION`](show-trace.html)) to report the replicas of all KV events that occur during its execution.
-
-Example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET tracing = on;
-> SELECT * from t;
-> SET tracing = off;
-> SHOW EXPERIMENTAL_REPLICA TRACE FOR SESSION;
-~~~
-
-~~~
-            timestamp             | node_id | store_id | replica_id
-----------------------------------+---------+----------+------------
- 2018-10-18 15:50:13.345879+00:00 |       3 |        3 |          7
- 2018-10-18 15:50:20.628383+00:00 |       2 |        2 |         26
-~~~
-
-### Check for constraint violations with `SCRUB`
-
-Checks the consistency of [`UNIQUE`](unique.html) indexes, [`CHECK`](check.html) constraints, and more.  Partially implemented; see [cockroachdb/cockroach#10425](https://github.com/cockroachdb/cockroach/issues/10425) for details.
-
-{{site.data.alerts.callout_info}}
-This example uses the `users` table from our open-source, fictional peer-to-peer vehicle-sharing application, [MovR](movr.html).
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
->  EXPERIMENTAL SCRUB table movr.users;
-~~~
-
-~~~
- job_uuid |        error_type        | database | table |                       primary_key                        |         timestamp         | repaired |                                                                                                                                                                         details                                                                                                                                                                         
-----------+--------------------------+----------+-------+----------------------------------------------------------+---------------------------+----------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-          | index_key_decoding_error | movr     | users | ('boston','0009eeb5-d779-4bf8-b1bd-8566533b105c')        | 2018-10-18 16:00:38.65916 | f        | {"error_message": "key ordering did not match datum ordering. IndexDescriptor=ASC", "index_name": "primary", "row_data": {"address": "e'06484 Christine Villages\\nGrantport, TN 01572'", "city": "'boston'", "credit_card": "'4634253150884'", "id": "'0009eeb5-d779-4bf8-b1bd-8566533b105c'", "name": "'Jessica Webb'"}}
-          | index_key_decoding_error | movr     | users | ('los angeles','0001252c-fc16-4006-b6dc-c6b1a0fd1f5b')   | 2018-10-18 16:00:38.65916 | f        | {"error_message": "key ordering did not match datum ordering. IndexDescriptor=ASC", "index_name": "primary", "row_data": {"address": "e'91309 Warner Springs\\nLake Danielmouth, PR 33400'", "city": "'los angeles'", "credit_card": "'3584736360686445'", "id": "'0001252c-fc16-4006-b6dc-c6b1a0fd1f5b'", "name": "'Rebecca Gibson'"}}
-          | index_key_decoding_error | movr     | users | ('new york','000169a5-e337-4441-b664-dae63e682980')      | 2018-10-18 16:00:38.65916 | f        | {"error_message": "key ordering did not match datum ordering. IndexDescriptor=ASC", "index_name": "primary", "row_data": {"address": "e'0787 Christopher Highway Apt. 363\\nHamptonmouth, TX 91864-2620'", "city": "'new york'", "credit_card": "'4578562547256688'", "id": "'000169a5-e337-4441-b664-dae63e682980'", "name": "'Christopher Johnson'"}}
-          | index_key_decoding_error | movr     | users | ('paris','00089fc4-e5b1-48f6-9f0b-409905f228c4')         | 2018-10-18 16:00:38.65916 | f        | {"error_message": "key ordering did not match datum ordering. IndexDescriptor=ASC", "index_name": "primary", "row_data": {"address": "e'46735 Martin Summit\\nMichaelview, OH 10906-5889'", "city": "'paris'", "credit_card": "'5102207609888778'", "id": "'00089fc4-e5b1-48f6-9f0b-409905f228c4'", "name": "'Nicole Fuller'"}}
-          | index_key_decoding_error | movr     | users | ('rome','000209fc-69a1-4dd5-8053-3b5e5769876d')          | 2018-10-18 16:00:38.65916 | f        | {"error_message": "key ordering did not match datum ordering. IndexDescriptor=ASC", "index_name": "primary", "row_data": {"address": "e'473 Barrera Vista Apt. 890\\nYeseniaburgh, CO 78087'", "city": "'rome'", "credit_card": "'3534605564661093'", "id": "'000209fc-69a1-4dd5-8053-3b5e5769876d'", "name": "'Sheryl Shea'"}}
-          | index_key_decoding_error | movr     | users | ('san francisco','00058767-1e83-4e18-999f-13b5a74d7225') | 2018-10-18 16:00:38.65916 | f        | {"error_message": "key ordering did not match datum ordering. IndexDescriptor=ASC", "index_name": "primary", "row_data": {"address": "e'5664 Acevedo Drive Suite 829\\nHernandezview, MI 13516'", "city": "'san francisco'", "credit_card": "'376185496850202'", "id": "'00058767-1e83-4e18-999f-13b5a74d7225'", "name": "'Kevin Turner'"}}
-          | index_key_decoding_error | movr     | users | ('seattle','0002e904-1256-4528-8b5f-abad16e695ff')       | 2018-10-18 16:00:38.65916 | f        | {"error_message": "key ordering did not match datum ordering. IndexDescriptor=ASC", "index_name": "primary", "row_data": {"address": "e'81499 Samuel Crescent Suite 631\\nLake Christopherborough, PR 50401'", "city": "'seattle'", "credit_card": "'38743493725890'", "id": "'0002e904-1256-4528-8b5f-abad16e695ff'", "name": "'Mark Williams'"}}
-          | index_key_decoding_error | movr     | users | ('washington dc','00007caf-2014-4696-85b0-840e7d8b6db9') | 2018-10-18 16:00:38.65916 | f        | {"error_message": "key ordering did not match datum ordering. IndexDescriptor=ASC", "index_name": "primary", "row_data": {"address": "e'4578 Holder Trafficway\\nReynoldsside, IL 23520-7418'", "city": "'washington dc'", "credit_card": "'30454993082943'", "id": "'00007caf-2014-4696-85b0-840e7d8b6db9'", "name": "'Marie Miller'"}}
-(8 rows)
-~~~
-
-### Show range information for a specific row
-
-The [`SHOW RANGE ... FOR ROW`](show-range-for-row.html) statement shows information about a [range](architecture/overview.html#glossary) for a particular row of data. This information is useful for verifying how SQL data maps to underlying ranges, and where the replicas for a range are located.
-
-## Functions and Operators
-
-The table below lists the experimental SQL functions and operators available in CockroachDB.  For more information, see each function's documentation at [Functions and Operators](functions-and-operators.html).
-
-| Function                                                                         | Description                                     |
-|----------------------------------------------------------------------------------+-------------------------------------------------|
-| [`experimental_strftime`](functions-and-operators.html#date-and-time-functions)  | Format time using standard `strftime` notation. |
-| [`experimental_strptime`](functions-and-operators.html#date-and-time-functions)  | Format time using standard `strptime` notation. |
-| [`experimental_uuid_v4()`](functions-and-operators.html#id-generation-functions) | Return a UUID.                                  |
-
-## Temporary objects
-
- Support for [temporary tables](temporary-tables.html), [temporary views](views.html#temporary-views), and [temporary sequences](create-sequence.html#temporary-sequences) is currently experimental in CockroachDB. If you create too many temporary objects in a session, the performance of DDL operations will degrade. Performance limitations could persist long after creating the temporary objects. For more details, see [cockroachdb/cockroach#46260](https://github.com/cockroachdb/cockroach/issues/46260).
-
-## Hash-sharded indexes
-
- CockroachDB supports hash-sharded indexes with the [`USING HASH`](create-index.html#parameters) keywords. Hash-sharded indexes distribute sequential traffic uniformly across ranges, eliminating single-range hotspots and improving write performance on sequentially-keyed indexes at a small cost to read performance. For more information, see [Hash-sharded indexes](hash-sharded-indexes.html).
-
-## Password authentication without TLS
-
-  <span class="version-tag">New in v20.2</span> For deployments where transport security is already handled at the infrastructure level (e.g., IPSec with DMZ), and TLS-based transport security is not possible or not desirable, CockroachDB now supports delegating transport security to the infrastructure with the new experimental flag `--accept-sql-without-tls` for [`cockroach start`](cockroach-start.html#security).
-
-  With this flag, SQL clients can establish a session over TCP without a TLS handshake. They still need to present valid authentication credentials, for example a password in the default configuration. Different authentication schemes can be further configured as per `server.host_based_authentication.configuration`.
-
-  Example:
-  {% include copy-clipboard.html %}
-  ~~~ shell
-  $ cockroach sql --user=jpointsman --insecure
-  ~~~
-
-  ~~~
-    # Welcome to the CockroachDB SQL shell.
-    # All statements must be terminated by a semicolon.
-    # To exit, type: \q.
-    #
-    Enter password:
-  ~~~
-
-## See Also
-
-- [`SHOW` (session)](show-vars.html)
-- [Functions and Operators](functions-and-operators.html)
-- [`ALTER TABLE ... EXPERIMENTAL_AUDIT`](experimental-audit.html)
-- [`SHOW TRACE FOR SESSION`](show-trace.html)
-- [`SHOW RANGE ... FOR ROW`](show-range-for-row.html)
diff --git a/src/current/v20.2/explain-analyze.md b/src/current/v20.2/explain-analyze.md
deleted file mode 100644
index 3129490ee3e..00000000000
--- a/src/current/v20.2/explain-analyze.md
+++ /dev/null
@@ -1,175 +0,0 @@
----
-title: EXPLAIN ANALYZE
-summary: The EXPLAIN ANALYZE statement executes a query and generates a physical query plan with execution statistics.
-toc: true
----
-
-The `EXPLAIN ANALYZE` [statement](sql-statements.html) **executes a SQL query** and generates a URL for a physical query plan with execution statistics, or a URL to download a bundle with more details about the query plan. Query plans provide information around SQL execution, which can be used to troubleshoot slow queries by figuring out where time is being spent, how long a processor (i.e., a component that takes streams of input rows and processes them according to a specification) is not doing work, etc. For more information about distributed SQL queries, see the [DistSQL section of our SQL Layer Architecture docs](architecture/sql-layer.html#distsql).
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/sql/physical-plan-url.md %}
-{{site.data.alerts.end}}
-
-## Aliases
-
-In CockroachDB, the following are aliases for `EXPLAIN ANALYZE`:
-
-- `EXPLAIN ANALYSE`
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/explain_analyze.html %}</div>
-
-## Parameters
-
-Parameter          | Description
--------------------|-----------
-`DISTSQL`          | _(Default)_ Generate a link to a distributed SQL physical query plan tree. For more information, see [Default option](#default-option).
-`DEBUG`            |  Generate a ZIP file containing files with detailed information about the query and the database objects referenced in the query. For more information, see [`DEBUG` option](#debug-option).
-`preparable_stmt`  | The [statement](sql-grammar.html#preparable_stmt) you want to execute and analyze. All preparable statements are explainable.
-
-## Required privileges
-
-The user requires the appropriate [privileges](authorization.html#assign-privileges) for the statement being explained.
-
-## Success responses
-
-Successful `EXPLAIN ANALYZE` (and `EXPLAIN ANALYZE (DISTSQL)`) statements return a table with the following columns:
-
- Column | Description
---------|------------
-**automatic** | If `true`, the query is distributed. For more information about distributed SQL queries, see the [DistSQL section of our SQL Layer Architecture docs](architecture/sql-layer.html#distsql).
-**url** | The URL generated for a physical query plan that provides high level information about how a query will be executed. For details about reading the physical query plan, see [DistSQL Plan Viewer](#distsql-plan-viewer).<br><br>{% include {{ page.version.version }}/sql/physical-plan-url.md %}
-
-If you use the [`DEBUG` option](#debug-option), the statement will return a single `text` column with a URL and instructions to download the `DEBUG` bundle, which includes the physical query plan.
-
-## Default option
-
-By default, `EXPLAIN ANALYZE` uses the `DISTQL` option, which generates a physical query plan diagram in the [DistSQL Plan Viewer](#distsql-plan-viewer). `EXPLAIN ANALYZE` and `EXPLAIN ANALYZE (DISTSQL)` produce the same output.
-
-### DistSQL Plan Viewer
-
-The DistSQL Plan Viewer displays the physical query plan, as well as execution statistics. The statistics listed depend on the query type and the [execution engine used](vectorized-execution.html).
-
-Field | Description | Execution engine
-------+-------------+----------------
-&lt;Processor&gt;/&lt;id&gt; | The processor and processor ID used to read data into the SQL execution engine.<br><br>A processor is a component that takes streams of input rows, processes them according to a specification, and outputs one stream of rows. For example, a "TableReader" processor reads in data, and an "Aggregator" aggregates input rows. | Both
-&lt;table&gt;@&lt;index&gt; | The index used by the processor. | Both
-Spans | The interval of the key space read by the processor. For example, `[/1 - /1]` indicates that only the key with value `1` is read by the processor. | Both
-Out | The output columns. | Both
-batches output | The number of batches of columnar data output. | Vectorized engine only
-tuples output | The number of rows output. | Vectorized engine only
-IO time | How long the TableReader processor spent reading data from disk. | Vectorized engine only
-stall time | How long the processor spent not doing work. This is aggregated into the stall time numbers as the query progresses down the tree (i.e., stall time is added up and overlaps with previous time). | Row-oriented engine only
-bytes read | The size of the data read by the processor. | Both
-rows read | The number of rows read by the processor. | Both
-@&lt;n&gt; | The index of the column relative to the input. | Both
-max memory used | How much memory (if any) is used to buffer rows. | Row-oriented engine only
-max disk used | How much disk (if any) is used to buffer data. Routers and processors will spill to disk buffering if there is not enough memory to buffer the data. | Row-oriented engine only
-execution time | How long the engine spent executing the processor. | Vectorized engine only
-max vectorized memory allocated | How much memory is allocated to the processor to buffer batches of columnar data. | Vectorized engine only
-max vectorized disk used | How much disk (if any) is used to buffer columnar data. Processors will spill to disk buffering if there is not enough memory to buffer the data. | Vectorized engine only
-left(@&lt;n&gt;)=right(@&lt;n&gt;) | The equality columns used in the join. | Both
-stored side | The smaller table that was stored as an in-memory hash table. | Both
-rows routed | How many rows were sent by routers, which can be used to understand network usage. | Row-oriented engine only
-bytes sent | The number of actual bytes sent (i.e., encoding of the rows). This is only relevant when doing network communication. | Both
-Render | The stage that renders the output. | Both
-by hash | _(Orange box)_ The router, which is a component that takes one stream of input rows and sends them to a node according to a routing algorithm.<br><br>For example, a hash router hashes columns of a row and sends the results to the node that is aggregating the result rows. | Both
-unordered / ordered | _(Blue box)_ A synchronizer that takes one or more output streams and merges them to be consumable by a processor. An ordered synchronizer is used to merge ordered streams and keeps the rows in sorted order. | Both
-&lt;data type&gt; |  If [`EXPLAIN(DISTSQL, TYPES)`](explain.html#distsql-option) is specified, lists the data types of the input columns. | Both
-Response | The response back to the client. | Both
-
-## `DEBUG` option
-
- `EXPLAIN ANALYZE (DEBUG)` executes a query and generates a link to a ZIP file that contains the [physical query plan](#distsql-plan-viewer), execution statistics, statement tracing, and other information about the query.
-
-        File        | Description
---------------------+-------------------
-`stats-<table>.sql` | Contains [statistics](create-statistics.html) for a table in the query.
-`schema.sql`        | Contains [`CREATE`](create-table.html) statements for objects in the query.
-`env.sql`           | Contains information about the CockroachDB environment.
-`trace.txt`         | Contains [statement traces](show-trace.html) in plaintext format.
-`trace.json`        | Contains [statement traces](show-trace.html) in JSON format.
-`trace-jaeger.json` | Contains [statement traces](show-trace.html) in JSON format that can be [imported to Jaeger](query-behavior-troubleshooting.html#visualize-statement-traces-in-jaeger).
-`distsql.html`      | The query's [physical query plan](#distsql-plan-viewer). This diagram is identical to the one generated by [`EXPLAIN(DISTSQL)`](explain.html#distsql-option)
-`plan.txt`          | The query execution plan. This is identical to the output of [`EXPLAIN (VERBOSE)`](explain.html#verbose-option).
-`opt-vv.txt`        | The query plan tree generated by the [cost-based optimizer](cost-based-optimizer.html), with cost details and input column data types. This is identical to the output of [`EXPLAIN (OPT, TYPES)`](explain.html#opt-option).
-`opt-v.txt`         | The query plan tree generated by the [cost-based optimizer](cost-based-optimizer.html), with cost details. This is identical to the output of [`EXPLAIN (OPT, VERBOSE)`](explain.html#opt-option).
-`opt.txt`           | The query plan tree generated by the [cost-based optimizer](cost-based-optimizer.html). This is identical to the output of [`EXPLAIN (OPT)`](explain.html#opt-option).
-`statement.txt`     | The SQL statement for the query.
-
-You can obtain this ZIP file by following the link provided in the `EXPLAIN ANALYZE (DEBUG)` output, or by activating [statement diagnostics](ui-statements-page.html#diagnostics) in the DB Console.
-
-{% include {{ page.version.version }}/sql/statement-bundle-warning.md %}
-
-## Examples
-
-### `EXPLAIN ANALYZE`
-
-Use `EXPLAIN ANALYZE` without an option, or equivalently with the `DISTSQL` option, to execute a query and generate a link to a physical query plan with execution statistics.
-
-For example, the following `EXPLAIN ANALYZE` statement executes a simple query against the [TPC-H database](http://www.tpc.org/tpch/) loaded to a 3-node CockroachDB cluster, and then generates a link to a physical query plan with execution statistics:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN ANALYZE SELECT l_shipmode, AVG(l_extendedprice) FROM lineitem GROUP BY l_shipmode;
-~~~
-
-~~~
-  automatic |                      url
-------------+-----------------------------------------------
-    true    | https://cockroachdb.github.io/distsqlplan...
-~~~
-
-To view the [DistSQL Plan Viewer](#distsql-plan-viewer), point your browser to the URL provided:
-
-<img src="{{ 'images/v20.2/explain-analyze-distsql-plan.png' | relative_url }}" alt="EXPLAIN ANALYZE (DISTSQL)" style="border:1px solid #eee;max-width:100%" />
-
-
-### `EXPLAIN ANALYZE (DEBUG)`
-
-Use the [`DEBUG`](#debug-option) option to generate a ZIP file containing files with information about the query and the database objects referenced in the query. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN ANALYZE (DEBUG) SELECT l_shipmode, AVG(l_extendedprice) FROM lineitem GROUP BY l_shipmode;
-~~~
-
-~~~
-                                      text
---------------------------------------------------------------------------------
-  Statement diagnostics bundle generated. Download from the Admin UI (Advanced
-  Debug -> Statement Diagnostics History), via the direct link below, or using
-  the command line.
-  Admin UI: http://127.0.0.1:26258
-  Direct link: http://127.0.0.1:26258/_admin/v1/stmtbundle/...
-  Command line: cockroach statement-diag list / download
-(6 rows)
-~~~
-
-Navigating to the URL will automatically download the ZIP file. You can also obtain the bundle by activating [statement diagnostics](ui-statements-page.html#diagnostics) in the DB Console.
-
-## See also
-
-- [`ALTER TABLE`](alter-table.html)
-- [`ALTER SEQUENCE`](alter-sequence.html)
-- [`BACKUP`](backup.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [`CREATE DATABASE`](create-database.html)
-- [`DROP DATABASE`](drop-database.html)
-- [`EXPLAIN`](explain.html)
-- [`EXECUTE`](sql-grammar.html#execute_stmt)
-- [`IMPORT`](import.html)
-- [Indexes](indexes.html)
-- [`INSERT`](insert.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`RESET`](reset-vars.html)
-- [`RESTORE`](restore.html)
-- [`RESUME JOB`](resume-job.html)
-- [`SELECT`](select-clause.html)
-- [Selection Queries](selection-queries.html)
-- [`SET`](set-vars.html)
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`SHOW COLUMNS`](show-columns.html)
-- [`UPDATE`](update.html)
-- [`UPSERT`](upsert.html)
diff --git a/src/current/v20.2/explain.md b/src/current/v20.2/explain.md
deleted file mode 100644
index f1070d0a8ea..00000000000
--- a/src/current/v20.2/explain.md
+++ /dev/null
@@ -1,856 +0,0 @@
----
-title: EXPLAIN
-summary: The EXPLAIN statement provides information you can use to optimize SQL queries.
-toc: true
----
-
-The `EXPLAIN` [statement](sql-statements.html) returns CockroachDB's query plan for an [explainable statement](sql-grammar.html#preparable_stmt). You can then use this information to optimize the query.
-
-{{site.data.alerts.callout_success}}
-To actually execute a statement and return a physical query plan with execution statistics, use [`EXPLAIN ANALYZE`](explain-analyze.html).
-{{site.data.alerts.end}}
-
-## Query optimization
-
-Using `EXPLAIN`'s output, you can optimize your queries by taking the following points into consideration:
-
-- Queries with fewer levels execute more quickly. Restructuring queries to require fewer levels of processing will generally improve performance.
-
-- Avoid scanning an entire table, which is the slowest way to access data. You can avoid this by [creating indexes](indexes.html) that contain at least one of the columns that the query is filtering in its `WHERE` clause.
-
-    <span class="version-tag">New in v20.2</span>: You can disable query plans that perform full table scans with the `disallow_full_table_scans` [session variable](set-vars.html). When `disallow_full_table_scans=on`, attempting to execute a query with a plan that includes a full table scan will return an error.
-
-- By default, the [vectorized execution](vectorized-execution.html) engine is enabled for all [supported operations](vectorized-execution.html#disk-spilling-operations). If you are querying a table with a small number of rows, it might be more efficient to use row-oriented execution. The `vectorize_row_count_threshold` [cluster setting](cluster-settings.html) specifies the minimum number of rows required to use the vectorized engine to execute a query plan.
-
-You can find out if your queries are performing entire table scans by using `EXPLAIN` to see which:
-
-- Indexes the query uses; shown as the **Description** value of rows with the **Field** value of `table`
-
-- Key values in the index are being scanned; shown as the **Description** value of rows with the **Field** value of `spans`
-
-<span class="version-tag">New in v20.2</span>: You can also see the estimated number of rows that a scan will perform in the  **Description** of the `estimated row count` **Field**.
-
-For more information about indexing and table scans, see [Find the Indexes and Key Ranges a Query Uses](#find-the-indexes-and-key-ranges-a-query-uses).
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/explain.html %}</div>
-
-## Required privileges
-
-The user requires the appropriate [privileges](authorization.html#assign-privileges) for the statement being explained.
-
-## Parameters
-
- Parameter          | Description
---------------------+------------
- `VERBOSE`          | Show as much information as possible about the query plan.
- `TYPES`            | Include the intermediate [data types](data-types.html) CockroachDB chooses to evaluate intermediate SQL expressions.
- `OPT`              | Display the query plan tree generated by the [cost-based optimizer](cost-based-optimizer.html).<br/><br/>To include cost details used by the optimizer in planning the query, use `OPT, VERBOSE`. To include cost and type details, use `OPT, TYPES`. To include all details used by the optimizer, including statistics, use `OPT, ENV`.
- `VEC`              | Show detailed information about the [vectorized execution](vectorized-execution.html) plan for a query.
- `preparable_stmt`  | The [statement](sql-grammar.html#preparable_stmt) you want details about. All preparable statements are explainable.
- `DISTSQL`          | Generate a URL to a [distributed SQL physical query plan tree](explain-analyze.html#distsql-plan-viewer).<br><br>{% include {{ page.version.version }}/sql/physical-plan-url.md %}
-
-{{site.data.alerts.callout_danger}}
-`EXPLAIN` also includes other modes besides query plans that are useful only to CockroachDB developers, which are not documented here.
-{{site.data.alerts.end}}
-
-## Success responses
-
-Successful `EXPLAIN` statements return tables with the following columns:
-
- Column | Description
------------|-------------
-**Tree** | A tree representation of the hierarchy of the query plan.
-**Field** | The name of a property for the query plan.<br><br>The `distribution` and `vectorized` properties apply to the entire query plan. All other properties apply to the query plan node in the **Tree** column.
-**Description** | Additional information about the parameter in  **Field**.
-**Columns** | The columns provided to the processes at lower levels of the hierarchy. Included in `TYPES` and `VERBOSE` output.
-**Ordering** | The order in which results are presented to the processes at each level of the hierarchy, as well as other properties of the result set at each level. Included in `TYPES` and `VERBOSE` output.
-
-## Examples
-
-The following examples use the [`movr` example dataset](cockroach-demo.html#datasets). To follow along:
-
-1. Start a [single-node cluster](cockroach-start-single-node.html):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start-single-node --insecure
-~~~
-
-2. Load the `movr` database and some [workload data](cockroach-workload.html) to the cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach workload init movr --num-histories 250000 --num-promo-codes 250000 --num-rides 125000 --num-users 12500 --num-vehicles 3750
-~~~
-
-### Default query plans
-
-By default, `EXPLAIN` includes the least detail about the query plan but can be useful to find out which indexes and index key ranges are used by a query. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM rides WHERE revenue > 90 ORDER BY revenue ASC;
-~~~
-
-~~~
-       tree      |        field        |  description
------------------+---------------------+----------------
-                 | distribution        | full
-                 | vectorized          | true
-  sort           |                     |
-   │             | order               | +revenue
-   └── filter    |                     |
-        │        | filter              | revenue > 90
-        └── scan |                     |
-                 | estimated row count | 125000
-                 | table               | rides@primary
-                 | spans               | FULL SCAN
-(10 rows)
-~~~
-
-The `tree` column of the output shows the tree structure of the query plan, in this case a `sort`, a `filter`, and then a `scan`.
-
-The `field` and `description` columns describe a set of properties, some global to the query, and some specific to an operation listed in the `tree` column (in this case, `sort`, `filter`, or `scan`):
-
-- `distribution`:`full`
-  <br>The planner chose a distributed execution plan, where execution of the query is performed by multiple nodes in parallel, then the final results are returned by the gateway node. An execution plan with `full` distribution doesn't process on all nodes in the cluster. It is executed simultaneously on multiple nodes.
-  <br>An execution plan with `local` distribution, on the other hand, is performed only on the gateway node. Even if the execution plan is `local`, row data may be fetched from remote nodes, but the processing of the data is performed by the local node.
-- `vectorized`:`false`
-  <br>The plan will be executed with the [vectorized execution engine](vectorized-execution.html).
-- `order`:`+revenue`
-  <br>The sort will be ordered ascending on the `revenue` column.
-- `filter`: `revenue > 90`
-  <br>The scan filters on the `revenue` column.
-- <span class="version-tag">New in v20.2:</span> `estimated row count`:`125000`
-  <br>The estimated number of rows scanned by the query, in this case, `125000` rows of data.
-- `table`:`rides@primary`
-  <br>The table is scanned on the `primary` index.
-- `spans`:`FULL SCAN`
-  <br>The table is scanned on all key ranges of the `primary` index (i.e., a full table scan). For more information on indexes and key ranges, see the [example](#find-the-indexes-and-key-ranges-a-query-uses) below.
-
-If you run `EXPLAIN` on a [join](joins.html) query, the output will display which type of join will be executed. For example, the following `EXPLAIN` output shows that the query will perform a [hash join](joins.html#hash-joins):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM rides AS r
-JOIN users AS u ON r.rider_id = u.id;
-~~~
-
-~~~
-    tree    |        field        |    description
-------------+---------------------+--------------------
-            | distribution        | full
-            | vectorized          | true
-  hash join |                     |
-   │        | equality            | (rider_id) = (id)
-   ├── scan |                     |
-   │        | estimated row count | 125000
-   │        | table               | rides@primary
-   │        | spans               | FULL SCAN
-   └── scan |                     |
-            | estimated row count | 12500
-            | table               | users@primary
-            | spans               | FULL SCAN
-(12 rows)
-~~~
-
-And the following output shows that the query will perform a cross join:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM rides AS r
-JOIN users AS u ON r.city = 'new york';
-~~~
-
-~~~
-     tree    |        field        |         description
--------------+---------------------+------------------------------
-             | distribution        | full
-             | vectorized          | true
-  cross join |                     |
-   ├── scan  |                     |
-   │         | estimated row count | 14050
-   │         | table               | rides@primary
-   │         | spans               | [/'new york' - /'new york']
-   └── scan  |                     |
-             | estimated row count | 12500
-             | table               | users@primary
-             | spans               | FULL SCAN
-(11 rows)
-~~~
-
-`EXPLAIN` output for [`INSERT`](insert.html) queries is similar to the output for standard `SELECT` queries. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN INSERT INTO users(id, city, name) VALUES ('c28f5c28-f5c2-4000-8000-000000000026', 'new york', 'Petee');
-~~~
-
-~~~
-     tree     |    field     |                 description
---------------+--------------+----------------------------------------------
-              | distribution | local
-              | vectorized   | false
-  insert      |              |
-   │          | into         | users(id, city, name, address, credit_card)
-   │          | auto commit  |
-   └── values |              |
-              | size         | 4 columns, 1 row
-(7 rows)
-~~~
-
-The output for this `INSERT` lists the primary operation under `tree` (i.e., `insert`), and the table and columns affected by the operation under the `description` of the `into` field (i.e., the `id`, `city`, `name`, `address`, and `credit_card` columns of the `users` table). The output also includes the size of the `INSERT` in the `description` of the `size` field (i.e., a single row).
-
-`EXPLAIN` output can include more information, for more complex types of `INSERT` queries. For example, suppose that you create a `UNIQUE` index on the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE UNIQUE INDEX ON users(city, id, name);
-~~~
-
-And then you want the `EXPLAIN` output for an [`INSERT ... ON CONFLICT` statement](insert.html#on-conflict-clause) that inserts some data that might conflict with the `UNIQUE` constraint imposed on the `name`, `city`, and `id` columns:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN INSERT INTO users(id, city, name) VALUES ('c28f5c28-f5c2-4000-8000-000000000026', 'new york', 'Petee') ON CONFLICT DO NOTHING;
-~~~
-
-~~~
-                     tree                     |         field         |                                                description
-----------------------------------------------+-----------------------+------------------------------------------------------------------------------------------------------------
-                                              | distribution          | local
-                                              | vectorized            | false
-  insert                                      |                       |
-   │                                          | into                  | users(id, city, name, address, credit_card)
-   │                                          | auto commit           |
-   │                                          | arbiter indexes       | primary, users_city_id_name_key
-   └── filter                                 |                       |
-        │                                     | filter                | city IS NULL
-        └── lookup join (left outer)          |                       |
-             │                                | table                 | users@users_name_idx
-             │                                | equality              | (column3, column2, column1) = (name,city,id)
-             │                                | equality cols are key |
-             └── filter                       |                       |
-                  │                           | filter                | city IS NULL
-                  └── cross join (left outer) |                       |
-                       ├── values             |                       |
-                       │                      | size                  | 4 columns, 1 row
-                       └── scan               |                       |
-                                              | estimated row count   | 1
-                                              | table                 | users@users_city_id_name_key
-                                              | spans                 | [/'new york'/'c28f5c28-f5c2-4000-8000-000000000026' - /'new york'/'c28f5c28-f5c2-4000-8000-000000000026']
-(21 rows)
-~~~
-
-Because the `INSERT` includes an `ON CONFLICT` clause, the query requires more than a simple `insert` operation. CockroachDB must check the provided values against the values in the database, to ensure that the `UNIQUE` constraint on `name`, `city`, and `id` is not violated. Note that the output also lists the indexes available to detect conflicts (i.e., the `arbiter indexes`), including the `users_city_id_name_key` index.
-
-### `VERBOSE` option
-
-The `VERBOSE` option:
-
-- Includes SQL expressions that are involved in each processing stage, providing more granular detail about which portion of your query is represented at each level.
-- Includes detail about which columns are being used by each level, as well as properties of the result set on that level.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (VERBOSE) SELECT * FROM rides AS r
-JOIN users AS u ON r.rider_id = u.id
-WHERE r.city = 'new york'
-ORDER BY r.revenue ASC;
-~~~
-
-~~~
-           tree          |        field        |            description            |                                                                     columns                                                                     | ordering
--------------------------+---------------------+-----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------+-----------
-                         | distribution        | full                              |                                                                                                                                                 |
-                         | vectorized          | true                              |                                                                                                                                                 |
-  sort                   |                     |                                   | (id, city, vehicle_city, rider_id, vehicle_id, start_address, end_address, start_time, end_time, revenue, id, city, name, address, credit_card) | +revenue
-   │                     | estimated row count | 14050                             |                                                                                                                                                 |
-   │                     | order               | +revenue                          |                                                                                                                                                 |
-   └── hash join (inner) |                     |                                   | (id, city, vehicle_city, rider_id, vehicle_id, start_address, end_address, start_time, end_time, revenue, id, city, name, address, credit_card) |
-        │                | estimated row count | 14050                             |                                                                                                                                                 |
-        │                | equality            | (rider_id) = (id)                 |                                                                                                                                                 |
-        ├── scan         |                     |                                   | (id, city, vehicle_city, rider_id, vehicle_id, start_address, end_address, start_time, end_time, revenue)                                       |
-        │                | estimated row count | 14050                             |                                                                                                                                                 |
-        │                | table               | rides@primary                     |                                                                                                                                                 |
-        │                | spans               | /"new york"-/"new york"/PrefixEnd |                                                                                                                                                 |
-        └── scan         |                     |                                   | (id, city, name, address, credit_card)                                                                                                          |
-                         | estimated row count | 12500                             |                                                                                                                                                 |
-                         | table               | users@primary                     |                                                                                                                                                 |
-                         | spans               | FULL SCAN                         |                                                                                                                                                 |
-(16 rows)
-~~~
-
-### `TYPES` option
-
-The `TYPES` mode includes the types of the values used in the query plan. It also includes the SQL expressions that were involved in each processing stage, and includes the columns used by each level.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (TYPES) SELECT * FROM rides WHERE revenue > 90 ORDER BY revenue ASC;
-~~~
-
-~~~
-       tree      |        field        |                description                 |                                                                                       columns                                                                                        | ordering
------------------+---------------------+--------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------
-                 | distribution        | full                                       |                                                                                                                                                                                      |
-                 | vectorized          | true                                       |                                                                                                                                                                                      |
-  sort           |                     |                                            | (id uuid, city varchar, vehicle_city varchar, rider_id uuid, vehicle_id uuid, start_address varchar, end_address varchar, start_time timestamp, end_time timestamp, revenue decimal) | +revenue
-   │             | estimated row count | 12527                                      |                                                                                                                                                                                      |
-   │             | order               | +revenue                                   |                                                                                                                                                                                      |
-   └── filter    |                     |                                            | (id uuid, city varchar, vehicle_city varchar, rider_id uuid, vehicle_id uuid, start_address varchar, end_address varchar, start_time timestamp, end_time timestamp, revenue decimal) |
-        │        | estimated row count | 12527                                      |                                                                                                                                                                                      |
-        │        | filter              | ((revenue)[decimal] > (90)[decimal])[bool] |                                                                                                                                                                                      |
-        └── scan |                     |                                            | (id uuid, city varchar, vehicle_city varchar, rider_id uuid, vehicle_id uuid, start_address varchar, end_address varchar, start_time timestamp, end_time timestamp, revenue decimal) |
-                 | estimated row count | 125000                                     |                                                                                                                                                                                      |
-                 | table               | rides@primary                              |                                                                                                                                                                                      |
-                 | spans               | FULL SCAN                                  |                                                                                                                                                                                      |
-(12 rows)
-~~~
-
-### `OPT` option
-
-The `OPT` option displays the query plan tree generated by the [cost-based optimizer](cost-based-optimizer.html). For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (OPT) SELECT * FROM rides WHERE revenue > 90 ORDER BY revenue ASC;
-~~~
-
-~~~
-             text
--------------------------------
-  sort
-   └── select
-        ├── scan rides
-        └── filters
-             └── revenue > 90
-(5 rows)
-~~~
-
-<a name="opt-verbose-option"></a>
-
-To include cost details used by the optimizer in planning the query, use `OPT, VERBOSE`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (OPT, VERBOSE) SELECT * FROM rides WHERE revenue > 90 ORDER BY revenue ASC;
-~~~
-
-~~~
-                                                                                                                                                                      text
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  sort
-   ├── columns: id:1 city:2 vehicle_city:3 rider_id:4 vehicle_id:5 start_address:6 end_address:7 start_time:8 end_time:9 revenue:10
-   ├── immutable
-   ├── stats: [rows=12526.8275, distinct(10)=9.90909091, null(10)=0]
-   │   histogram(10)=  0  0   11115 1412
-   │                 <--- 90 ------- 99
-   ├── cost: 154915.074
-   ├── key: (1,2)
-   ├── fd: (1,2)-->(3-10)
-   ├── ordering: +10
-   ├── prune: (1-9)
-   ├── interesting orderings: (+2,+1) (+2,+4,+1) (+3,+5,+2,+1)
-   └── select
-        ├── columns: id:1 city:2 vehicle_city:3 rider_id:4 vehicle_id:5 start_address:6 end_address:7 start_time:8 end_time:9 revenue:10
-        ├── immutable
-        ├── stats: [rows=12526.8275, distinct(10)=9.90909091, null(10)=0]
-        │   histogram(10)=  0  0   11115 1412
-        │                 <--- 90 ------- 99
-        ├── cost: 151254.04
-        ├── key: (1,2)
-        ├── fd: (1,2)-->(3-10)
-        ├── prune: (1-9)
-        ├── interesting orderings: (+2,+1) (+2,+4,+1) (+3,+5,+2,+1)
-        ├── scan rides
-        │    ├── columns: id:1 city:2 vehicle_city:3 rider_id:4 vehicle_id:5 start_address:6 end_address:7 start_time:8 end_time:9 revenue:10
-        │    ├── stats: [rows=125000, distinct(1)=125000, null(1)=0, distinct(2)=9, null(2)=0, distinct(10)=100, null(10)=0]
-        │    │   histogram(1)=  0                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12
-        │    │                <--- '00000000-0000-4000-8000-000000000000' ----- '012d7731-8fc5-4480-8000-00000000023f' ----- '022f6a50-d6b2-48e0-8000-00000000042b' ----- '03a8e714-76af-49c0-8000-0000000006fb' ----- '04f97edc-7ef1-47c0-8000-00000000097d' ----- '06466b1e-5c0b-4980-8000-000000000bf8' ----- '07442c7f-bacb-4280-8000-000000000ddc' ----- '08a3f898-2cb2-4f80-8000-00000000107b' ----- '09a4df47-f993-4500-8000-000000001265' ----- '0b020c49-ba5e-4500-8000-0000000014ff' ----- '0c508b32-ce89-4580-8000-00000000177d' ----- '0db7281f-d9ba-4b00-8000-000000001a29' ----- '0f00ef13-48b2-4080-8000-000000001c9e' ----- '106e5cd4-ed2c-4f00-8000-000000001f57' ----- '1184c271-fff7-4d00-8000-00000000216a' ----- '1301eabb-cb1c-4900-8000-000000002441' ----- '144ed6fd-a836-4b00-8000-0000000026bc' ----- '15781c71-4fce-4400-8000-0000000028f3' ----- '16c3fc43-b2dd-4700-8000-000000002b6c' ----- '1810e885-8ff7-4900-8000-000000002de7' ----- '19274e22-a2c2-4700-8000-000000002ffa' ----- '1a4f8726-d04e-4200-8000-00000000322f' ----- '1bb83cf2-cf95-4500-8000-0000000034df' ----- '1d0f1f57-b41b-4c00-8000-00000000376d' ----- '1e6ab9b2-3dd5-4e00-8000-000000003a04' ----- '1fd04a2f-cefa-4400-8000-000000003cae' ----- '211ec918-e325-4400-8000-000000003f2c' ----- '226b2f23-033a-4800-8000-0000000041a6' ----- '23875925-3543-4e00-8000-0000000043c4' ----- '2516db0d-d82f-4800-8000-0000000046be' ----- '26634117-f844-4a00-8000-000000004938' ----- '279ee02a-77a2-4e00-8000-000000004b92' ----- '291fb3fa-6def-4800-8000-000000004e70' ----- '2a771c97-0f7b-4e00-8000-0000000050ff' ----- '2b66b617-7ea1-4600-8000-0000000052c8' ----- '2cd53048-9d27-4400-8000-000000005583' ----- '2e22a2c2-3747-4400-8000-0000000057ff' ----- '2f80dc33-721d-4400-8000-000000005a9b' ----- '313cee9d-d7ec-4c00-8000-000000005dea' ----- '32d234eb-9a17-4e00-8000-0000000060ef' ----- '349c6f36-ef80-4600-8000-000000006459' ----- '36188b11-409a-4400-8000-00000000672e' ----- '37a46173-b85e-4000-8000-000000006a21' ----- '38b47c73-eee5-4600-8000-000000006c28' ----- '3a11a975-afaf-4600-8000-000000006ec2' ----- '3bbf93ff-25e5-4c00-8000-0000000071f6' ----- '3d41fa76-5343-4400-8000-0000000074d7' ----- '3eb18116-ebd4-4000-8000-000000007794' ----- '3fed2029-6b33-4400-8000-0000000079ee' ----- '415a8deb-0fad-4400-8000-000000007ca7' ----- '428dc981-beb1-4000-8000-000000007ef1' ----- '43d89ce4-a7b4-4400-8000-000000008168' ----- '4522ea0f-d3b2-4c00-8000-0000000083de' ----- '4676a726-4a16-4400-8000-000000008666' ----- '47bc3c5b-d0e1-4000-8000-0000000088d3' ----- '49036438-8ebc-4800-8000-000000008b43' ----- '4a12f901-083d-4c00-8000-000000008d49' ----- '4b923a29-c779-4800-8000-000000009024' ----- '4d06fef7-c243-4c00-8000-0000000092eb' ----- '4e46cfc8-29cf-4c00-8000-00000000954d' ----- '4f922962-cfd8-4000-8000-0000000097c5' ----- '508dd1e5-3a81-4c00-8000-0000000099a5' ----- '51d041cc-532a-4800-8000-000000009c0c' ----- '52e83a10-9d06-4400-8000-000000009e22' ----- '53fe1975-f2cb-4400-8000-00000000a034' ----- '554195cc-857f-4000-8000-00000000a29d' ----- '5634549b-62c7-4400-8000-00000000a46c' ----- '5776c482-7b6f-4400-8000-00000000a6d3' ----- '58aa8650-e779-4000-8000-00000000a91e' ----- '59d2bf55-1505-4c00-8000-00000000ab53' ----- '5aecd078-52f7-4400-8000-00000000ad6d' ----- '5c23315d-701d-4000-8000-00000000afbd' ----- '5d4cfd08-d4ba-4800-8000-00000000b1f5' ----- '5ed84d33-8f79-4400-8000-00000000b4e7' ----- '60221426-fe71-4c00-8000-00000000b75c' ----- '615b9a5a-89b9-4000-8000-00000000b9b2' ----- '62b302f7-2b45-4800-8000-00000000bc41' ----- '63e29307-af20-4c00-8000-00000000be84' ----- '6539756c-93a7-4000-8000-00000000c112' ----- '664cb5bb-384f-4400-8000-00000000c31f' ----- '67653437-3f31-4000-8000-00000000c536' ----- '689d27c3-9368-4800-8000-00000000c789' ----- '69ce4a7b-4e54-4800-8000-00000000c9cf' ----- '6b324851-a869-4000-8000-00000000cc76' ----- '6c5436b8-f9b1-4000-8000-00000000ce9f' ----- '6d9d7774-aba3-4800-8000-00000000d113' ----- '6e99a62e-d352-4400-8000-00000000d2f4' ----- '6fb6dca0-7f66-4800-8000-00000000d514' ----- '711b60ae-9680-4000-8000-00000000d7bc' ----- '72a51e32-1a2e-4000-8000-00000000daab' ----- '7415b142-2ccb-4c00-8000-00000000dd6a' ----- '756b00ff-da40-4400-8000-00000000dff5' ----- '76da0168-b5cc-4000-8000-00000000e2b1' ----- '77d41743-e963-4c00-8000-00000000e48e' ----- '7938151a-4378-4400-8000-00000000e735' ----- '7aa71583-1f03-4000-8000-00000000e9f1' ----- '7c219eb6-390c-4000-8000-00000000ecc3' ----- '7d7cb2d9-05c0-4400-8000-00000000ef59' ----- '7ec7863b-eec3-4800-8000-00000000f1d0' ----- '7fd8adab-9f55-4c00-8000-00000000f3d9' ----- '81333b96-af03-4000-8000-00000000f66e' ----- '8270f388-2278-4000-8000-00000000f8cc' ----- '836b0963-5610-4000-8000-00000000faa9' ----- '849667b5-f1be-4800-8000-00000000fce4' ----- '85efe931-8761-4800-8000-00000000ff77' ----- '877ab324-851a-4800-8000-000000010268' ----- '88dd1e53-a81d-4000-8000-00000001050c' ----- '8a361997-80ba-4800-8000-00000001079e' ----- '8b81f969-e3c9-4800-8000-000000010a17' ----- '8cb20fb2-24aa-4800-8000-000000010c5b' ----- '8e264e48-626f-4000-8000-000000010f21' ----- '8f9b994e-1a3f-4800-8000-0000000111e9' ----- '90c026cc-1ca3-4800-8000-000000011417' ----- '91ab0856-e696-4000-8000-0000000115d7' ----- '92dfd694-ccab-4000-8000-000000011824' ----- '94794ea0-7703-4000-8000-000000011b31' ----- '957928e0-c9d9-4000-8000-000000011d19' ----- '96bb98c7-e282-4000-8000-000000011f80' ----- '97e1b8ed-1bf7-4000-8000-0000000121b1' ----- '993037d6-3022-4000-8000-00000001242f' ----- '9ac03ff6-9014-4800-8000-00000001272a' ----- '9c4e2f37-fbef-4000-8000-000000012a21' ----- '9d9d3458-cd20-4000-8000-000000012ca0' ----- '9ec2ce46-4990-4000-8000-000000012ed0' ----- 'a01d5c31-593e-4000-8000-000000013165' ----- 'a155d5f5-6a7a-4800-8000-0000000133b9' ----- 'a2df9378-ee28-4800-8000-0000000136a8' ----- 'a468448c-f7ca-4800-8000-000000013995' ----- 'a5931ca7-d673-4000-8000-000000013bcf' ----- 'a73b42cc-2d6a-4000-8000-000000013ef8' ----- 'a8e92d55-a3a0-4000-8000-00000001422c' ----- 'aa222d51-71e2-4800-8000-000000014481' ----- 'ab2fa93a-f74c-4000-8000-000000014683' ----- 'ac28b2a6-b0d9-4000-8000-00000001485e' ----- 'ad234eb9-a176-4000-8000-000000014a3c' ----- 'ae392e1e-f73c-4000-8000-000000014c4e' ----- 'af6be37d-e939-4800-8000-000000014e97' ----- 'b10d38cd-a6e7-4000-8000-0000000151b3' ----- 'b210be94-24e5-4000-8000-0000000153a2' ----- 'b34ce3de-6149-4800-8000-0000000155fd' ----- 'b48f53c5-79f2-4800-8000-000000015864' ----- 'b631b584-b1ab-4800-8000-000000015b82' ----- 'b76c4827-b6fe-4000-8000-000000015dda' ----- 'b8d716d2-aa5c-4000-8000-00000001608e' ----- 'ba240314-8776-4000-8000-000000016309' ----- 'bb70ef56-6490-4000-8000-000000016584' ----- 'bcb70ac3-a860-4000-8000-0000000167f2' ----- 'be0589ac-bc8c-4000-8000-000000016a70' ----- 'bf601797-cc3a-4000-8000-000000016d05' ----- 'c055fbb5-17a4-4000-8000-000000016eda' ----- 'c195cc85-7f30-4000-8000-00000001713c' ----- 'c2ef4e01-14d2-4800-8000-0000000173cf' ----- 'c44f1a19-86b9-4000-8000-00000001766e' ----- 'c576cce5-f740-4000-8000-0000000178a2' ----- 'c6dbd72b-cb5f-4800-8000-000000017b4b' ----- 'c835dedf-1e08-4800-8000-000000017ddf' ----- 'c9795b35-b0bb-4800-8000-000000018048' ----- 'caaeafab-53d6-4000-8000-000000018296' ----- 'cbc51548-66a1-4000-8000-0000000184a9' ----- 'cd0dcfcc-5b8d-4800-8000-00000001871c' ----- 'ce2089e3-4330-4800-8000-000000018928' ----- 'cf6e8294-9a56-4800-8000-000000018ba5' ----- 'd0b06c43-f5f9-4800-8000-000000018e0b' ----- 'd1c4b902-14ad-4800-8000-00000001901a' ----- 'd2f1a9fb-e76c-4800-8000-000000019258' ----- 'd40357a3-5504-4000-8000-000000019462' ----- 'd52220bc-382a-4000-8000-000000019685' ----- 'd65b20b8-066c-4800-8000-0000000198da' ----- 'd7aa25d8-d79d-4800-8000-000000019b59' ----- 'd8bef8ce-b356-4800-8000-000000019d69' ----- 'da06a6e3-2e38-4000-8000-000000019fda' ----- 'db4916ca-46e0-4000-8000-00000001a241' ----- 'dc6b0531-9828-4000-8000-00000001a46a' ----- 'dd7342ed-bb59-4000-8000-00000001a662' ----- 'deda6612-8390-4000-8000-00000001a90f' ----- 'e09aaa3a-d18d-4800-8000-00000001ac66' ----- 'e1f85d74-4f5d-4800-8000-00000001af01' ----- 'e30d306a-2b17-4800-8000-00000001b111' ----- 'e44d013a-92a3-4800-8000-00000001b373' ----- 'e5d63886-594a-4800-8000-00000001b661' ----- 'e6a44417-8705-4000-8000-00000001b7ea' ----- 'e82e87d2-c7b8-4000-8000-00000001bada' ----- 'e9717df1-9d66-4000-8000-00000001bd42' ----- 'eb04ab60-6b7a-4000-8000-00000001c043' ----- 'ec3c18b5-02ab-4800-8000-00000001c295' ----- 'ed8904f6-dfc5-4000-8000-00000001c510' ----- 'eef0281b-a7fc-4000-8000-00000001c7bd' ----- 'f0489d27-c393-4800-8000-00000001ca4e' ----- 'f19934ef-cbd5-4800-8000-00000001ccd0' ----- 'f352a843-8088-4000-8000-00000001d01a' ----- 'f4a66559-f6ec-4800-8000-00000001d2a2' ----- 'f595feda-6612-4000-8000-00000001d46b' ----- 'f6e696a2-6e54-4000-8000-00000001d6ed' ----- 'f8244e93-e1c9-4800-8000-00000001d94b' ----- 'f9b77c02-afdd-4800-8000-00000001dc4c' ----- 'fac57e23-f24d-4000-8000-00000001de4f' ----- 'fc0980b2-4207-4800-8000-00000001e0b9' ----- 'fd75e204-6c76-4800-8000-00000001e370' ----- 'feacc921-46a1-4800-8000-00000001e5c1' ----- 'fffe6d58-c8ee-4000-8000-00000001e845'
-        │    │   histogram(2)=  0     14225     0   12875    0      13362      0    14050     0   14900   0  13725   0       13475       0    14637    0       13750
-        │    │                <--- 'amsterdam' --- 'boston' --- 'los angeles' --- 'new york' --- 'paris' --- 'rome' --- 'san francisco' --- 'seattle' --- 'washington dc'
-        │    │   histogram(10)=  0 1325 1.2226e+05 1412
-        │    │                 <--- 0 ------------- 99
-        │    ├── cost: 150004.02
-        │    ├── key: (1,2)
-        │    ├── fd: (1,2)-->(3-10)
-        │    ├── prune: (1-10)
-        │    └── interesting orderings: (+2,+1) (+2,+4,+1) (+3,+5,+2,+1)
-        └── filters
-             └── revenue:10 > 90 [outer=(10), immutable, constraints=(/10: (/90 - ]; tight)]
-(39 rows)
-~~~
-
-<a name="opt-types-option"></a>
-
-To include cost and type details, use `OPT, TYPES`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (OPT, TYPES) SELECT * FROM rides WHERE revenue > 90 ORDER BY revenue ASC;
-~~~
-
-~~~
-                                                                                                                                                                      text
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  sort
-   ├── columns: id:1(uuid!null) city:2(varchar!null) vehicle_city:3(varchar) rider_id:4(uuid) vehicle_id:5(uuid) start_address:6(varchar) end_address:7(varchar) start_time:8(timestamp) end_time:9(timestamp) revenue:10(decimal!null)
-   ├── immutable
-   ├── stats: [rows=12526.8275, distinct(10)=9.90909091, null(10)=0]
-   │   histogram(10)=  0  0   11115 1412
-   │                 <--- 90 ------- 99
-   ├── cost: 154915.074
-   ├── key: (1,2)
-   ├── fd: (1,2)-->(3-10)
-   ├── ordering: +10
-   ├── prune: (1-9)
-   ├── interesting orderings: (+2,+1) (+2,+4,+1) (+3,+5,+2,+1)
-   └── select
-        ├── columns: id:1(uuid!null) city:2(varchar!null) vehicle_city:3(varchar) rider_id:4(uuid) vehicle_id:5(uuid) start_address:6(varchar) end_address:7(varchar) start_time:8(timestamp) end_time:9(timestamp) revenue:10(decimal!null)
-        ├── immutable
-        ├── stats: [rows=12526.8275, distinct(10)=9.90909091, null(10)=0]
-        │   histogram(10)=  0  0   11115 1412
-        │                 <--- 90 ------- 99
-        ├── cost: 151254.04
-        ├── key: (1,2)
-        ├── fd: (1,2)-->(3-10)
-        ├── prune: (1-9)
-        ├── interesting orderings: (+2,+1) (+2,+4,+1) (+3,+5,+2,+1)
-        ├── scan rides
-        │    ├── columns: id:1(uuid!null) city:2(varchar!null) vehicle_city:3(varchar) rider_id:4(uuid) vehicle_id:5(uuid) start_address:6(varchar) end_address:7(varchar) start_time:8(timestamp) end_time:9(timestamp) revenue:10(decimal)
-        │    ├── stats: [rows=125000, distinct(1)=125000, null(1)=0, distinct(2)=9, null(2)=0, distinct(10)=100, null(10)=0]
-        │    │   histogram(1)=  0                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    612                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12                    625                    12
-        │    │                <--- '00000000-0000-4000-8000-000000000000' ----- '012d7731-8fc5-4480-8000-00000000023f' ----- '022f6a50-d6b2-48e0-8000-00000000042b' ----- '03a8e714-76af-49c0-8000-0000000006fb' ----- '04f97edc-7ef1-47c0-8000-00000000097d' ----- '06466b1e-5c0b-4980-8000-000000000bf8' ----- '07442c7f-bacb-4280-8000-000000000ddc' ----- '08a3f898-2cb2-4f80-8000-00000000107b' ----- '09a4df47-f993-4500-8000-000000001265' ----- '0b020c49-ba5e-4500-8000-0000000014ff' ----- '0c508b32-ce89-4580-8000-00000000177d' ----- '0db7281f-d9ba-4b00-8000-000000001a29' ----- '0f00ef13-48b2-4080-8000-000000001c9e' ----- '106e5cd4-ed2c-4f00-8000-000000001f57' ----- '1184c271-fff7-4d00-8000-00000000216a' ----- '1301eabb-cb1c-4900-8000-000000002441' ----- '144ed6fd-a836-4b00-8000-0000000026bc' ----- '15781c71-4fce-4400-8000-0000000028f3' ----- '16c3fc43-b2dd-4700-8000-000000002b6c' ----- '1810e885-8ff7-4900-8000-000000002de7' ----- '19274e22-a2c2-4700-8000-000000002ffa' ----- '1a4f8726-d04e-4200-8000-00000000322f' ----- '1bb83cf2-cf95-4500-8000-0000000034df' ----- '1d0f1f57-b41b-4c00-8000-00000000376d' ----- '1e6ab9b2-3dd5-4e00-8000-000000003a04' ----- '1fd04a2f-cefa-4400-8000-000000003cae' ----- '211ec918-e325-4400-8000-000000003f2c' ----- '226b2f23-033a-4800-8000-0000000041a6' ----- '23875925-3543-4e00-8000-0000000043c4' ----- '2516db0d-d82f-4800-8000-0000000046be' ----- '26634117-f844-4a00-8000-000000004938' ----- '279ee02a-77a2-4e00-8000-000000004b92' ----- '291fb3fa-6def-4800-8000-000000004e70' ----- '2a771c97-0f7b-4e00-8000-0000000050ff' ----- '2b66b617-7ea1-4600-8000-0000000052c8' ----- '2cd53048-9d27-4400-8000-000000005583' ----- '2e22a2c2-3747-4400-8000-0000000057ff' ----- '2f80dc33-721d-4400-8000-000000005a9b' ----- '313cee9d-d7ec-4c00-8000-000000005dea' ----- '32d234eb-9a17-4e00-8000-0000000060ef' ----- '349c6f36-ef80-4600-8000-000000006459' ----- '36188b11-409a-4400-8000-00000000672e' ----- '37a46173-b85e-4000-8000-000000006a21' ----- '38b47c73-eee5-4600-8000-000000006c28' ----- '3a11a975-afaf-4600-8000-000000006ec2' ----- '3bbf93ff-25e5-4c00-8000-0000000071f6' ----- '3d41fa76-5343-4400-8000-0000000074d7' ----- '3eb18116-ebd4-4000-8000-000000007794' ----- '3fed2029-6b33-4400-8000-0000000079ee' ----- '415a8deb-0fad-4400-8000-000000007ca7' ----- '428dc981-beb1-4000-8000-000000007ef1' ----- '43d89ce4-a7b4-4400-8000-000000008168' ----- '4522ea0f-d3b2-4c00-8000-0000000083de' ----- '4676a726-4a16-4400-8000-000000008666' ----- '47bc3c5b-d0e1-4000-8000-0000000088d3' ----- '49036438-8ebc-4800-8000-000000008b43' ----- '4a12f901-083d-4c00-8000-000000008d49' ----- '4b923a29-c779-4800-8000-000000009024' ----- '4d06fef7-c243-4c00-8000-0000000092eb' ----- '4e46cfc8-29cf-4c00-8000-00000000954d' ----- '4f922962-cfd8-4000-8000-0000000097c5' ----- '508dd1e5-3a81-4c00-8000-0000000099a5' ----- '51d041cc-532a-4800-8000-000000009c0c' ----- '52e83a10-9d06-4400-8000-000000009e22' ----- '53fe1975-f2cb-4400-8000-00000000a034' ----- '554195cc-857f-4000-8000-00000000a29d' ----- '5634549b-62c7-4400-8000-00000000a46c' ----- '5776c482-7b6f-4400-8000-00000000a6d3' ----- '58aa8650-e779-4000-8000-00000000a91e' ----- '59d2bf55-1505-4c00-8000-00000000ab53' ----- '5aecd078-52f7-4400-8000-00000000ad6d' ----- '5c23315d-701d-4000-8000-00000000afbd' ----- '5d4cfd08-d4ba-4800-8000-00000000b1f5' ----- '5ed84d33-8f79-4400-8000-00000000b4e7' ----- '60221426-fe71-4c00-8000-00000000b75c' ----- '615b9a5a-89b9-4000-8000-00000000b9b2' ----- '62b302f7-2b45-4800-8000-00000000bc41' ----- '63e29307-af20-4c00-8000-00000000be84' ----- '6539756c-93a7-4000-8000-00000000c112' ----- '664cb5bb-384f-4400-8000-00000000c31f' ----- '67653437-3f31-4000-8000-00000000c536' ----- '689d27c3-9368-4800-8000-00000000c789' ----- '69ce4a7b-4e54-4800-8000-00000000c9cf' ----- '6b324851-a869-4000-8000-00000000cc76' ----- '6c5436b8-f9b1-4000-8000-00000000ce9f' ----- '6d9d7774-aba3-4800-8000-00000000d113' ----- '6e99a62e-d352-4400-8000-00000000d2f4' ----- '6fb6dca0-7f66-4800-8000-00000000d514' ----- '711b60ae-9680-4000-8000-00000000d7bc' ----- '72a51e32-1a2e-4000-8000-00000000daab' ----- '7415b142-2ccb-4c00-8000-00000000dd6a' ----- '756b00ff-da40-4400-8000-00000000dff5' ----- '76da0168-b5cc-4000-8000-00000000e2b1' ----- '77d41743-e963-4c00-8000-00000000e48e' ----- '7938151a-4378-4400-8000-00000000e735' ----- '7aa71583-1f03-4000-8000-00000000e9f1' ----- '7c219eb6-390c-4000-8000-00000000ecc3' ----- '7d7cb2d9-05c0-4400-8000-00000000ef59' ----- '7ec7863b-eec3-4800-8000-00000000f1d0' ----- '7fd8adab-9f55-4c00-8000-00000000f3d9' ----- '81333b96-af03-4000-8000-00000000f66e' ----- '8270f388-2278-4000-8000-00000000f8cc' ----- '836b0963-5610-4000-8000-00000000faa9' ----- '849667b5-f1be-4800-8000-00000000fce4' ----- '85efe931-8761-4800-8000-00000000ff77' ----- '877ab324-851a-4800-8000-000000010268' ----- '88dd1e53-a81d-4000-8000-00000001050c' ----- '8a361997-80ba-4800-8000-00000001079e' ----- '8b81f969-e3c9-4800-8000-000000010a17' ----- '8cb20fb2-24aa-4800-8000-000000010c5b' ----- '8e264e48-626f-4000-8000-000000010f21' ----- '8f9b994e-1a3f-4800-8000-0000000111e9' ----- '90c026cc-1ca3-4800-8000-000000011417' ----- '91ab0856-e696-4000-8000-0000000115d7' ----- '92dfd694-ccab-4000-8000-000000011824' ----- '94794ea0-7703-4000-8000-000000011b31' ----- '957928e0-c9d9-4000-8000-000000011d19' ----- '96bb98c7-e282-4000-8000-000000011f80' ----- '97e1b8ed-1bf7-4000-8000-0000000121b1' ----- '993037d6-3022-4000-8000-00000001242f' ----- '9ac03ff6-9014-4800-8000-00000001272a' ----- '9c4e2f37-fbef-4000-8000-000000012a21' ----- '9d9d3458-cd20-4000-8000-000000012ca0' ----- '9ec2ce46-4990-4000-8000-000000012ed0' ----- 'a01d5c31-593e-4000-8000-000000013165' ----- 'a155d5f5-6a7a-4800-8000-0000000133b9' ----- 'a2df9378-ee28-4800-8000-0000000136a8' ----- 'a468448c-f7ca-4800-8000-000000013995' ----- 'a5931ca7-d673-4000-8000-000000013bcf' ----- 'a73b42cc-2d6a-4000-8000-000000013ef8' ----- 'a8e92d55-a3a0-4000-8000-00000001422c' ----- 'aa222d51-71e2-4800-8000-000000014481' ----- 'ab2fa93a-f74c-4000-8000-000000014683' ----- 'ac28b2a6-b0d9-4000-8000-00000001485e' ----- 'ad234eb9-a176-4000-8000-000000014a3c' ----- 'ae392e1e-f73c-4000-8000-000000014c4e' ----- 'af6be37d-e939-4800-8000-000000014e97' ----- 'b10d38cd-a6e7-4000-8000-0000000151b3' ----- 'b210be94-24e5-4000-8000-0000000153a2' ----- 'b34ce3de-6149-4800-8000-0000000155fd' ----- 'b48f53c5-79f2-4800-8000-000000015864' ----- 'b631b584-b1ab-4800-8000-000000015b82' ----- 'b76c4827-b6fe-4000-8000-000000015dda' ----- 'b8d716d2-aa5c-4000-8000-00000001608e' ----- 'ba240314-8776-4000-8000-000000016309' ----- 'bb70ef56-6490-4000-8000-000000016584' ----- 'bcb70ac3-a860-4000-8000-0000000167f2' ----- 'be0589ac-bc8c-4000-8000-000000016a70' ----- 'bf601797-cc3a-4000-8000-000000016d05' ----- 'c055fbb5-17a4-4000-8000-000000016eda' ----- 'c195cc85-7f30-4000-8000-00000001713c' ----- 'c2ef4e01-14d2-4800-8000-0000000173cf' ----- 'c44f1a19-86b9-4000-8000-00000001766e' ----- 'c576cce5-f740-4000-8000-0000000178a2' ----- 'c6dbd72b-cb5f-4800-8000-000000017b4b' ----- 'c835dedf-1e08-4800-8000-000000017ddf' ----- 'c9795b35-b0bb-4800-8000-000000018048' ----- 'caaeafab-53d6-4000-8000-000000018296' ----- 'cbc51548-66a1-4000-8000-0000000184a9' ----- 'cd0dcfcc-5b8d-4800-8000-00000001871c' ----- 'ce2089e3-4330-4800-8000-000000018928' ----- 'cf6e8294-9a56-4800-8000-000000018ba5' ----- 'd0b06c43-f5f9-4800-8000-000000018e0b' ----- 'd1c4b902-14ad-4800-8000-00000001901a' ----- 'd2f1a9fb-e76c-4800-8000-000000019258' ----- 'd40357a3-5504-4000-8000-000000019462' ----- 'd52220bc-382a-4000-8000-000000019685' ----- 'd65b20b8-066c-4800-8000-0000000198da' ----- 'd7aa25d8-d79d-4800-8000-000000019b59' ----- 'd8bef8ce-b356-4800-8000-000000019d69' ----- 'da06a6e3-2e38-4000-8000-000000019fda' ----- 'db4916ca-46e0-4000-8000-00000001a241' ----- 'dc6b0531-9828-4000-8000-00000001a46a' ----- 'dd7342ed-bb59-4000-8000-00000001a662' ----- 'deda6612-8390-4000-8000-00000001a90f' ----- 'e09aaa3a-d18d-4800-8000-00000001ac66' ----- 'e1f85d74-4f5d-4800-8000-00000001af01' ----- 'e30d306a-2b17-4800-8000-00000001b111' ----- 'e44d013a-92a3-4800-8000-00000001b373' ----- 'e5d63886-594a-4800-8000-00000001b661' ----- 'e6a44417-8705-4000-8000-00000001b7ea' ----- 'e82e87d2-c7b8-4000-8000-00000001bada' ----- 'e9717df1-9d66-4000-8000-00000001bd42' ----- 'eb04ab60-6b7a-4000-8000-00000001c043' ----- 'ec3c18b5-02ab-4800-8000-00000001c295' ----- 'ed8904f6-dfc5-4000-8000-00000001c510' ----- 'eef0281b-a7fc-4000-8000-00000001c7bd' ----- 'f0489d27-c393-4800-8000-00000001ca4e' ----- 'f19934ef-cbd5-4800-8000-00000001ccd0' ----- 'f352a843-8088-4000-8000-00000001d01a' ----- 'f4a66559-f6ec-4800-8000-00000001d2a2' ----- 'f595feda-6612-4000-8000-00000001d46b' ----- 'f6e696a2-6e54-4000-8000-00000001d6ed' ----- 'f8244e93-e1c9-4800-8000-00000001d94b' ----- 'f9b77c02-afdd-4800-8000-00000001dc4c' ----- 'fac57e23-f24d-4000-8000-00000001de4f' ----- 'fc0980b2-4207-4800-8000-00000001e0b9' ----- 'fd75e204-6c76-4800-8000-00000001e370' ----- 'feacc921-46a1-4800-8000-00000001e5c1' ----- 'fffe6d58-c8ee-4000-8000-00000001e845'
-        │    │   histogram(2)=  0     14225     0   12875    0      13362      0    14050     0   14900   0  13725   0       13475       0    14637    0       13750
-        │    │                <--- 'amsterdam' --- 'boston' --- 'los angeles' --- 'new york' --- 'paris' --- 'rome' --- 'san francisco' --- 'seattle' --- 'washington dc'
-        │    │   histogram(10)=  0 1325 1.2226e+05 1412
-        │    │                 <--- 0 ------------- 99
-        │    ├── cost: 150004.02
-        │    ├── key: (1,2)
-        │    ├── fd: (1,2)-->(3-10)
-        │    ├── prune: (1-10)
-        │    └── interesting orderings: (+2,+1) (+2,+4,+1) (+3,+5,+2,+1)
-        └── filters
-             └── gt [type=bool, outer=(10), immutable, constraints=(/10: (/90 - ]; tight)]
-                  ├── variable: revenue:10 [type=decimal]
-                  └── const: 90 [type=decimal]
-(41 rows)
-~~~
-
-<a name="opt-env-option"></a>
-
-To include all details used by the optimizer, including statistics, use `OPT, ENV`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (OPT, ENV) SELECT * FROM rides WHERE revenue > 90 ORDER BY revenue ASC;
-~~~
-
-~~~
-                      text
------------------------------------------------------
-  https://cockroachdb.github.io/text/decode.html#....
-(1 row)
-~~~
-
-The output of `EXPLAIN (OPT, ENV)` is now a URL with the data encoded in the fragment portion. Opening the URL shows a page with the decoded data. This change makes it easier to share debugging information across different systems without encountering formatting issues.
-
-Note that the data is processed in the local browser session and is never sent out over the network. Keep in mind that if you are using any browser extensions, they may be able to access the data locally.
-
-When you visit the URL above you should see the following output in your browser.
-
-~~~
-
--- Version: CockroachDB CCL v20.2.0 (x86_64-apple-darwin19.6.0, built 2020/09/17 16:03:34, go1.14.3)
-
--- reorder_joins_limit has the default value: 8
--- enable_zigzag_join has the default value: on
--- optimizer_use_histograms has the default value: on
--- optimizer_use_multicol_stats has the default value: on
-
-CREATE TABLE public.rides (
-	id UUID NOT NULL,
-	city VARCHAR NOT NULL,
-	vehicle_city VARCHAR NULL,
-	rider_id UUID NULL,
-	vehicle_id UUID NULL,
-	start_address VARCHAR NULL,
-	end_address VARCHAR NULL,
-	start_time TIMESTAMP NULL,
-	end_time TIMESTAMP NULL,
-	revenue DECIMAL(10,2) NULL,
-	CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-	CONSTRAINT fk_city_ref_users FOREIGN KEY (city, rider_id) REFERENCES public.users(city, id),
-	CONSTRAINT fk_vehicle_city_ref_vehicles FOREIGN KEY (vehicle_city, vehicle_id) REFERENCES public.vehicles(city, id),
-	INDEX rides_auto_index_fk_city_ref_users (city ASC, rider_id ASC),
-	INDEX rides_auto_index_fk_vehicle_city_ref_vehicles (vehicle_city ASC, vehicle_id ASC),
-	FAMILY "primary" (id, city, vehicle_city, rider_id, vehicle_id, start_address, end_address, start_time, end_time, revenue),
-	CONSTRAINT check_vehicle_city_city CHECK (vehicle_city = city)
-);
-
-ALTER TABLE movr.public.rides INJECT STATISTICS '[
-    {
-        "columns": [
-            "city"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 9,
-        "histo_col_type": "STRING",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "id"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 125617,
-        "histo_col_type": "UUID",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "city",
-            "id"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 124937,
-        "histo_col_type": "",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "rider_id"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 12552,
-        "histo_col_type": "UUID",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "city",
-            "rider_id"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 12444,
-        "histo_col_type": "",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "vehicle_city"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 9,
-        "histo_col_type": "STRING",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "vehicle_id"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 3764,
-        "histo_col_type": "UUID",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "vehicle_city",
-            "vehicle_id"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 3717,
-        "histo_col_type": "",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "start_address"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 124678,
-        "histo_col_type": "STRING",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "end_address"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 126337,
-        "histo_col_type": "STRING",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "start_time"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 30,
-        "histo_col_type": "TIMESTAMP",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "end_time"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 756,
-        "histo_col_type": "TIMESTAMP",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    },
-    {
-        "columns": [
-            "revenue"
-        ],
-        "created_at": "2020-09-17 16:27:05.231123",
-        "distinct_count": 100,
-        "histo_col_type": "DECIMAL",
-        "name": "__auto__",
-        "null_count": 0,
-        "row_count": 125000
-    }
-]';
-
-EXPLAIN (OPT, ENV) SELECT * FROM rides WHERE revenue > 90 ORDER BY revenue ASC;
-----
-sort
- └── select
-      ├── scan rides
-      └── filters
-           └── revenue > 90
-~~~
-
-### `VEC` option
-
-The `VEC` option shows details about the [vectorized execution plan](vectorized-execution.html#how-vectorized-execution-works) for the query.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (VEC) SELECT * FROM rides WHERE revenue > 90 ORDER BY revenue ASC;
-~~~
-
-~~~
-                    text
----------------------------------------------
-  │
-  └ Node 1
-    └ *colexec.sortOp
-      └ *colexec.selGTDecimalDecimalConstOp
-        └ *colfetcher.ColBatchScan
-(5 rows)
-~~~
-
-The output shows the different internal functions that will be used to process each batch of column-oriented data.
-
-### `DISTSQL` option
-
-The `DISTSQL` option generates a URL for a physical query plan that provides high level information about how a query will be executed. For details about reading the physical query plan, see [DistSQL Plan Viewer](explain-analyze.html#distsql-plan-viewer). For more information about distributed SQL queries, see the [DistSQL section of our SQL Layer Architecture docs](architecture/sql-layer.html#distsql).
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/sql/physical-plan-url.md %}
-{{site.data.alerts.end}}
-
-For example, the following `EXPLAIN(DISTSQL)` statement generates a physical plan for a simple query against the [TPC-H database](http://www.tpc.org/tpch/) loaded to a 3-node CockroachDB cluster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (DISTSQL) SELECT l_shipmode, AVG(l_extendedprice) FROM lineitem GROUP BY l_shipmode;
-~~~
-
-~~~
- automatic |                      url
------------+----------------------------------------------
-   true    | https://cockroachdb.github.io/distsqlplan...
-~~~
-
-To view the [DistSQL Plan Viewer](explain-analyze.html#distsql-plan-viewer), point your browser to the URL provided:
-
-<img src="{{ 'images/v20.2/explain-distsql-plan.png' | relative_url }}" alt="EXPLAIN (DISTSQL)" style="border:1px solid #eee;max-width:100%" />
-
- To include the data types of the input columns in the physical plan, use `EXPLAIN(DISTSQL, TYPES)`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (DISTSQL, TYPES) SELECT l_shipmode, AVG(l_extendedprice) FROM lineitem GROUP BY l_shipmode;
-~~~
-
-~~~
- automatic |                      url
------------+----------------------------------------------
-   true    | https://cockroachdb.github.io/distsqlplan...
-~~~
-
-To view the [DistSQL Plan Viewer](explain-analyze.html#distsql-plan-viewer), point your browser to the URL provided:
-
-<img src="{{ 'images/v20.2/explain-distsql-types-plan.png' | relative_url }}" alt="EXPLAIN (DISTSQL)" style="border:1px solid #eee;max-width:100%" />
-
-
-### Find the indexes and key ranges a query uses
-
-You can use `EXPLAIN` to understand which indexes and key ranges queries use, which can help you ensure a query isn't performing a full table scan.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE kv (k INT PRIMARY KEY, v INT);
-~~~
-
-Because column `v` is not indexed, queries filtering on it alone scan the entire table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM kv WHERE v BETWEEN 4 AND 5;
-~~~
-
-~~~
-    tree    |     field     |      description
-------------+---------------+------------------------
-            | distribution  | full
-            | vectorized    | false
-  filter    |               |
-   │        | filter        | (v >= 4) AND (v <= 5)
-   └── scan |               |
-            | missing stats |
-            | table         | kv@primary
-            | spans         | FULL SCAN
-(8 rows)
-~~~
-
-<span class="version-tag">New in v20.2</span>: You can disable query plans that perform full table scans with the `disallow_full_table_scans` [session variable](set-vars.html).
-
-When `disallow_full_table_scans=on`, attempting to execute a query with a plan that includes a full table scan will return an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET disallow_full_table_scans=on;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM kv WHERE v BETWEEN 4 AND 5;
-~~~
-
-~~~
-ERROR: query `SELECT * FROM kv WHERE v BETWEEN 4 AND 5` contains a full table/index scan which is explicitly disallowed
-SQLSTATE: P0003
-HINT: try overriding the `disallow_full_table_scans` cluster/session setting
-~~~
-
-If there were an index on `v`, CockroachDB would be able to avoid scanning the entire table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX v ON kv (v);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM kv WHERE v BETWEEN 4 AND 5;
-~~~
-
-~~~
-  tree |     field     | description
--------+---------------+--------------
-       | distribution  | local
-       | vectorized    | false
-  scan |               |
-       | missing stats |
-       | table         | kv@v
-       | spans         | [/4 - /5]
-(6 rows)
-~~~
-
-Now, only part of the index `v` is getting scanned, specifically the key range starting at (and including) 4 and stopping before 6. Also note that this query plan is not distributed across nodes on the cluster.
-
-### Find out if a statement is using `SELECT FOR UPDATE` locking
-
- CockroachDB has support for ordering transactions by controlling concurrent access to one or more rows of a table using locks. This "`SELECT FOR UPDATE` locking" can result in improved performance for contended operations. It applies to the following statements:
-
-- [`SELECT FOR UPDATE`](select-for-update.html)
-- [`UPDATE`](update.html)
-
-To see whether a SQL query using one of these statements is using this feature, check the output of `EXPLAIN` for a `locking strength` field as shown below. If the `locking strength` field does not appear, then the statement is not using this feature.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS kv (k INT PRIMARY KEY, v INT);
-UPSERT INTO kv (k, v) VALUES (1, 5), (2, 10), (3, 15);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN UPDATE kv SET v = 100 WHERE k = 1;
-~~~
-
-~~~
-       tree      |      field       | description
------------------+------------------+--------------
-                 | distribution     | local
-                 | vectorized       | false
-  update         |                  |
-   │             | table            | kv
-   │             | set              | v
-   │             | auto commit      |
-   └── render    |                  |
-        └── scan |                  |
-                 | missing stats    |
-                 | table            | kv@primary
-                 | spans            | [/1 - /1]
-                 | locking strength | for update
-(12 rows)
-~~~
-
-By default, `SELECT FOR UPDATE` locking is enabled for the initial row scan of `UPDATE` and `UPSERT` statements.  To disable it, toggle the [`enable_implicit_select_for_update` session setting](show-vars.html#enable-implicit-select-for-update).
-
-## See also
-
-- [`ALTER TABLE`](alter-table.html)
-- [`ALTER SEQUENCE`](alter-sequence.html)
-- [`BACKUP`](backup.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [`CREATE DATABASE`](create-database.html)
-- [`DROP DATABASE`](drop-database.html)
-- [`EXECUTE`](sql-grammar.html#execute_stmt)
-- [`EXPLAIN ANALYZE`](explain-analyze.html)
-- [`IMPORT`](import.html)
-- [Indexes](indexes.html)
-- [`INSERT`](insert.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`RESET`](reset-vars.html)
-- [`RESTORE`](restore.html)
-- [`RESUME JOB`](resume-job.html)
-- [`SELECT`](select-clause.html)
-- [Selection Queries](selection-queries.html)
-- [`SET`](set-vars.html)
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`SHOW COLUMNS`](show-columns.html)
-- [`UPDATE`](update.html)
-- [`UPSERT`](upsert.html)
diff --git a/src/current/v20.2/export-spatial-data.md b/src/current/v20.2/export-spatial-data.md
deleted file mode 100644
index 31597a021c8..00000000000
--- a/src/current/v20.2/export-spatial-data.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: Export Spatial Data
-summary: Learn how to export spatial data from CockroachDB into various formats.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: CockroachDB supports efficiently storing and querying spatial data.
-
-This page has instructions for exporting spatial data from CockroachDB and converting it to other spatial formats using the [`ogr2ogr`](https://gdal.org/programs/ogr2ogr.html) command.
-
-{% include {{page.version.version}}/spatial/ogr2ogr-supported-version.md %}
-
-## Step 1. Export data to CSV
-
-First, use the [`EXPORT`](export.html) statement to export your data to a CSV file.
-
-In the example statement below, we export the tornadoes database used in [Working with spatial data](spatial-data.html).
-
-The statement will place the CSV file in the node's [store directory](cockroach-start.html#store), in a subdirectory named `extern/tornadoes`. The file's name is automatically generated, and will be displayed as output in the [SQL shell](cockroach-sql.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPORT INTO CSV 'nodelocal://self/tornadoes' WITH nullas = '' FROM SELECT * from "1950-2018-torn-initpoint";
-~~~
-
-~~~
-                     filename                     | rows  |  bytes
---------------------------------------------------+-------+-----------
-  export16467a35d30d25700000000000000001-n1.0.csv | 63645 | 16557064
-(1 row)
-~~~
-
-{{site.data.alerts.callout_info}}
-This example uses local file storage.  For more information about other locations where you can export your data (such as cloud storage), see [`EXPORT`](export.html).
-{{site.data.alerts.end}}
-
-## Step 2. Combine multiple CSV files into one, as needed
-
-You should now have one or more CSV files in the `extern/tornadoes` subdirectory of your node's [store directory](cockroach-start.html#store).  Depending on the size of the data set, there may be more than one CSV file.
-
-To combine multiple CSVs into one file:
-
-1. Open the CSV file where you will be storing the combined output in a text editor.  You will need to manually add the CSV header columns to that file so that the `ogr2ogr` output we generate below will have the proper column names.  Start by running the statement below on the table you are exporting to get the necessary column names:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    SELECT string_agg(column_name, ',') FROM [SHOW COLUMNS FROM "1950-2018-torn-initpoint"];
-    ~~~
-
-    ~~~
-                                                  string_agg
-    ------------------------------------------------------------------------------------------------------
-      gid,om,yr,mo,dy,date,time,tz,st,stf,stn,mag,inj,fat,loss,closs,slat,slon,elat,elon,len,wid,fc,geom
-    ~~~
-
-2. Add the column names output above to your target output CSV file (e.g., `tornadoes.csv`) as header columns.  For the tornadoes database, they should look like the following:
-
-    ~~~
-    gid, om, yr, mo, dy, date, time, tz, st, stf, stn, mag, inj, fat, loss, closs, slat, slon, elat, elon, len, wid, fc, geom
-    ~~~
-
-2. Concatenate the non-header data from all of the exported CSV files, and append the output to the target CSV file as shown below.  The node's store directory on this machine is `/tmp/node0`.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    cat /tmp/node0/extern/tornadoes/*.csv >> tornadoes.csv
-    ~~~
-
-## Step 3. Convert CSV to other formats using `ogr2ogr`
-
-Now that you have your data in CSV format, you can convert it to other spatial formats using [`ogr2ogr`](https://gdal.org/programs/ogr2ogr.html).
-
-For example, to convert the data to SQL, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-ogr2ogr -f PGDUMP tornadoes.sql -lco LAUNDER=NO -lco DROP_TABLE=OFF -oo GEOM_POSSIBLE_NAMES=geom -oo KEEP_GEOM_COLUMNS=off tornadoes.csv
-~~~
-
-Note that the options `-oo GEOM_POSSIBLE_NAMES=<geom_column_name> -oo KEEP_GEOM_COLUMNS=off` are required no matter what output format you are converting into.
-
-For more information about the formats supported by `ogr2ogr`, see the [`ogr2ogr` documentation](https://gdal.org/programs/ogr2ogr.html).
-
-{% include {{page.version.version}}/spatial/ogr2ogr-supported-version.md %}
-
-Finally, note that SQL type information is lost in the conversion to CSV, such that the `tornadoes.sql` file output by the `ogr2ogr` command above lists every non-geometry field as a [`VARCHAR`](string.html).
-
-This can be addressed in one of the following ways:
-
-- Modify the data definitions in the SQL output file to use the correct types.
-
-- Run [`ALTER TYPE`](alter-type.html) statements to restore the data's SQL types after loading this data into another database (including another CockroachDB instance).
-
-## See also
-
-- [`EXPORT`](export.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Spatial features](spatial-features.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Known Limitations](known-limitations.html#spatial-support-limitations)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Well known text](well-known-text.html)
-- [Well known binary](well-known-binary.html)
-- [GeoJSON](geojson.html)
-- [SRID 4326 - longitude and latitude](srid-4326.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_Union`](st_union.html)
-- [`ST_Within`](st_within.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/export.md b/src/current/v20.2/export.md
deleted file mode 100644
index 74ac823c7a1..00000000000
--- a/src/current/v20.2/export.md
+++ /dev/null
@@ -1,267 +0,0 @@
----
-title: EXPORT
-summary: Export tabular data from a CockroachDB cluster in CSV format.
-toc: true
----
-
-The `EXPORT` [statement](sql-statements.html) exports tabular data or the results of arbitrary `SELECT` statements to CSV files.
-
-Using the [CockroachDB distributed execution engine](architecture/sql-layer.html#distsql), `EXPORT` parallelizes CSV creation across all nodes in the cluster, making it possible to quickly get large sets of data out of CockroachDB in a format that can be ingested by downstream systems. If you do not need distributed exports, you can [export tabular data in CSV format](#non-distributed-export-using-the-sql-client).
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span>
-`EXPORT` no longer requires an Enterprise license.
-{{site.data.alerts.end}}
-
-## Cancelling export
-
-After the export has been initiated, you can cancel it with [`CANCEL QUERY`](cancel-query.html).
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/export.html %}</div>
-
-{{site.data.alerts.callout_info}}The <code>EXPORT</code> statement cannot be used within a <a href=transactions.html>transaction</a>.{{site.data.alerts.end}}
-
-## Required privileges
-
-Only members of the `admin` role can run `EXPORT`. By default, the `root` user belongs to the `admin` role.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `file_location` | Specify the [URL of the file location](#export-file-url) where you want to store the exported CSV data.<br><br>Note: It is best practice to use a unique destination for each export, to avoid mixing files from different exports in one directory.
- `WITH kv_option` | Control your export's behavior with [these options](#export-options).
- `select_stmt` | Specify the query whose result you want to export to CSV format.
- `table_name` | Specify the name of the table you want to export to CSV format.
-
-### Export file URL
-
-You can specify the base directory where you want to store the exported .csv files. CockroachDB will create the export file(s) in the specified directory with programmatically generated names (e.g., `exportabc123-n1.1.csv`, `exportabc123-n1.2.csv`, `exportabc123-n2.1.csv`, ...). Each export should use a unique destination directory to avoid collision with other exports.
-
-The `EXPORT` command [returns](#success-responses) the list of files to which the data was exported. You may wish to record these for use in subsequent imports.
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span>
-A hexadecimal hash code (`abc123...` in the file names above) uniquely identifies each export _run_; files sharing the same hash are part of the same export. If you see multiple hash codes within a single destination directory, then the directory contains multiple exports, which will likely cause confusion (duplication) on import. We recommend that you manually clean up the directory, to ensure that it contains only a single export run.
-{{site.data.alerts.end}}
-
-For more information, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-### Export options
-
-You can control the [`EXPORT`](export.html) process's behavior using any of the following key-value pairs as a `kv_option`.
-
-Key                 | <div style="width:130px">Context</div> | Value                                                                                                                             |
---------------------+-----------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------
-`delimiter`         |    `CSV DATA`   |  The ASCII character that delimits columns in your rows. If not using comma as your column delimiter, you can specify another ASCII character as the delimiter. **Default:** `,`. <br><br>To use tab-delimited values: `WITH delimiter = e'\t'`
-`nullas`            |    `CSV DATA`, `DELIMITED DATA`          |  The string that should be used to represent _NULL_ values. To avoid collisions, it is important to pick `nullas` values that do not appear in the exported data. <br><br>To use empty columns as _NULL_: `WITH nullas = ''`
-`compression`       |    `CSV DATA`   |  This instructs export to write `gzip` compressed CSV files to the specified destination. <br><br>See the [example](#export-gzip-compressed-csv-files) below.
-`chunk_rows`        |    `CSV DATA`   |  The number of rows to be converted to CSV and written to a single CSV file. **Default:** `100000`. <br><br>For example, `WITH chunk_rows = '5000'` for a table with 10,000 rows would produce two CSV files.
-
-## Success responses
-
-Successful `EXPORT` returns a table of (perhaps multiple) files to which the data was exported:
-
-| Response | Description |
-|-----------|-------------|
-`filename` | The file to which the data was exported.
-`rows` | The number of rows exported to this file.
-`bytes` | The file size in bytes.
-
-## Examples
-
-The following provide connection examples to cloud storage providers. For more information on connecting to different storage options, read [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html).
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="s3">Amazon S3</button>
-  <button class="filter-button" data-scope="azure">Azure Storage</button>
-  <button class="filter-button" data-scope="gcs">Google Cloud Storage</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="s3">
-
-{% include {{ page.version.version }}/backups/aws-auth-note.md %}
-
-Each of these examples use the `bank` database and the `customers` table; `customer-export-data` is the demonstration path to which we're exporting our customers' data in this example.
-
-### Export a table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  's3://{BUCKET NAME}/{customer-export-data}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-  WITH delimiter = '|' FROM TABLE bank.customers;
-~~~
-
-### Export using a `SELECT` statement
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  's3://{BUCKET NAME}/{customer-export-data}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-  FROM SELECT * FROM bank.customers WHERE id >= 100;
-~~~
-
-For more information, see [selection queries](selection-queries.html).
-
-### Non-distributed export using the SQL client
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql -e "SELECT * from bank.customers WHERE id>=100;" --format=csv > my.csv
-~~~
-
-For more information, about the SQL client, see [`cockroach sql`](cockroach-sql.html).
-
-### Export gzip compressed CSV files
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  's3://{BUCKET NAME}/{customer-export-data}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-  WITH compression = 'gzip' FROM TABLE bank.customers;
-~~~
-
-~~~
-filename                                           | rows | bytes
----------------------------------------------------+------+--------
-export16808a04292505c80000000000000001-n1.0.csv.gz |   17 |   824
-(1 row)
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="azure">
-
-Each of these examples use the `bank` database and the `customers` table; `customer-export-data` is the demonstration path to which we're exporting our customers' data in this example.
-
-### Export a table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  'azure://{CONTAINER NAME}/{customer-export-data}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-  WITH delimiter = '|' FROM TABLE bank.customers;
-~~~
-
-### Export using a `SELECT` statement
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  'azure://{CONTAINER NAME}/{customer-export-data}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-  FROM SELECT * FROM bank.customers WHERE id >= 100;
-~~~
-
-For more information, see [selection queries](selection-queries.html).
-
-### Non-distributed export using the SQL client
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql -e "SELECT * from bank.customers WHERE id>=100;" --format=csv > my.csv
-~~~
-
-For more information, about the SQL client, see [`cockroach sql`](cockroach-sql.html).
-
-### Export gzip compressed CSV files
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  'azure://{CONTAINER NAME}/{customer-export-data}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-  WITH compression = 'gzip' FROM TABLE bank.customers;
-~~~
-
-~~~
-filename                                           | rows | bytes
----------------------------------------------------+------+--------
-export16808a04292505c80000000000000001-n1.0.csv.gz |   17 |   824
-(1 row)
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="gcs">
-
-{% include {{ page.version.version }}/backups/gcs-auth-note.md %}
-
-Each of these examples use the `bank` database and the `customers` table; `customer-export-data` is the demonstration path to which we're exporting our customers' data in this example.
-
-### Export a table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  'gs://{BUCKET NAME}/{customer-export-data}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-  WITH delimiter = '|' FROM TABLE bank.customers;
-~~~
-
-### Export using a `SELECT` statement
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  'gs://{BUCKET NAME}/{customer-export-data}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-  FROM SELECT * FROM bank.customers WHERE id >= 100;
-~~~
-
-For more information, see [selection queries](selection-queries.html).
-
-### Non-distributed export using the SQL client
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql -e "SELECT * from bank.customers WHERE id>=100;" --format=csv > my.csv
-~~~
-
-For more information, about the SQL client, see [`cockroach sql`](cockroach-sql.html).
-
-### Export gzip compressed CSV files
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPORT INTO CSV
-  'gs://{BUCKET NAME}/{customer-export-data}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-  WITH compression = 'gzip' FROM TABLE bank.customers;
-~~~
-
-~~~
-filename                                           | rows | bytes
----------------------------------------------------+------+--------
-export16808a04292505c80000000000000001-n1.0.csv.gz |   17 |   824
-(1 row)
-~~~
-
-</section>
-
-### View a running export
-
-View running exports by using [`SHOW QUERIES`](show-queries.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW QUERIES;
-~~~
-
-### Cancel a running export
-
-Use [`SHOW QUERIES`](show-queries.html) to get a running export's `query_id`, which can be used to [cancel the export](cancel-query.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL QUERY '14dacc1f9a781e3d0000000000000001';
-~~~
-
-## Known limitation
-
-`EXPORT` may fail with an error if the SQL statements are incompatible with DistSQL. In that case, [export tabular data in CSV format](#non-distributed-export-using-the-sql-client).
-
-## See also
-
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
diff --git a/src/current/v20.2/file-an-issue.md b/src/current/v20.2/file-an-issue.md
deleted file mode 100644
index 065725484dd..00000000000
--- a/src/current/v20.2/file-an-issue.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: File an Issue
-summary: Learn how to file a GitHub issue with CockroachDB.
-toc: false
----
-
-If you've tried to [troubleshoot](troubleshooting-overview.html) an issue yourself, have [reached out for help](support-resources.html), and are still stumped, you can file an issue in GitHub.
-
-To file an issue in GitHub, we need the following information:
-
-1. A summary of the issue.
-
-2. The steps to reproduce the issue.
-
-3. The result you expected.
-
-4. The result that actually occurred.
-
-5. The first few lines of the log file from each node in the cluster in a timeframe as close as possible to reproducing the issue. On most Unix-based systems running with defaults, you can get this information using the following command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ grep -F '[config]' cockroach-data/logs/cockroach.log
-    ~~~
-    {{site.data.alerts.callout_info}}You might need to replace <code>cockroach-data/logs</code> with the location of your <a href="debug-and-error-logs.html">logs</a>.{{site.data.alerts.end}}
-    If the logs are not available, please include the output of `cockroach version` for each node in the cluster.
-
-### Template
-
-You can use this as a template for [filing an issue in GitHub](https://github.com/cockroachdb/cockroach/issues/new):
-
-~~~
-
-## Summary
-
-
-
-## Steps to reproduce
-
-1.
-2.
-3.
-
-## Expected Result
-
-
-
-## Actual Result
-
-
-
-## Log files/version
-
-### Node 1
-
-
-
-### Node 2
-
-
-
-### Node 3
-
-
-
-~~~
diff --git a/src/current/v20.2/float.md b/src/current/v20.2/float.md
deleted file mode 100644
index 8a1df115e63..00000000000
--- a/src/current/v20.2/float.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: FLOAT
-summary: The FLOAT data type stores inexact, floating-point numbers with up to 17 digits in total and at least one digit to the right of the decimal point.
-toc: true
----
-
-CockroachDB supports various inexact, floating-point number [data types](data-types.html) with up to 17 digits of decimal precision.
-
-They are handled internally using the [standard double-precision (64-bit binary-encoded) IEEE754 format](https://en.wikipedia.org/wiki/IEEE_floating_point).
-
-
-## Names and Aliases
-
-Name | Aliases
------|--------
-`FLOAT` | None
-`REAL` | `FLOAT4`
-`DOUBLE PRECISION` | `FLOAT8`
-
-## Syntax
-
-A constant value of type `FLOAT` can be entered as a [numeric literal](sql-constants.html#numeric-literals).
-For example: `1.414` or `-1234`.
-
-The special IEEE754 values for positive infinity, negative infinity
-and [NaN (Not-a-Number)](https://en.wikipedia.org/wiki/NaN) cannot be
-entered using numeric literals directly and must be converted using an
-[interpreted literal](sql-constants.html#interpreted-literals) or an
-[explicit conversion](scalar-expressions.html#explicit-type-coercions)
-from a string literal instead.
-
-The following values are recognized:
-
- Syntax                                 | Value
-----------------------------------------|------------------------------------------------
- `inf`, `infinity`, `+inf`, `+infinity` | +&#8734;                                                
- `-inf`, `-infinity`                    | -&#8734;                                                
- `nan`                                  | [NaN (Not-a-Number)](https://en.wikipedia.org/wiki/NaN)
-
-For example:
-
-- `FLOAT '+Inf'`
-- `'-Inf'::FLOAT`
-- `CAST('NaN' AS FLOAT)`
-
-## Size
-
-A `FLOAT` column supports values up to 8 bytes in width, but the total storage size is likely to be larger due to CockroachDB metadata.
-
-## Examples
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE floats (a FLOAT PRIMARY KEY, b REAL, c DOUBLE PRECISION);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM floats;
-~~~
-
-~~~
-+-------------+------------------+-------------+----------------+-----------------------+-------------+
-| column_name |    data_type     | is_nullable | column_default | generation_expression |   indices   |
-+-------------+------------------+-------------+----------------+-----------------------+-------------+
-| a           | FLOAT            |    false    | NULL           |                       | {"primary"} |
-| b           | REAL             |    true     | NULL           |                       | {}          |
-| c           | DOUBLE PRECISION |    true     | NULL           |                       | {}          |
-+-------------+------------------+-------------+----------------+-----------------------+-------------+
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO floats VALUES (1.012345678901, 2.01234567890123456789, CAST('+Inf' AS FLOAT));
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM floats;
-~~~
-
-~~~
-+----------------+--------------------+------+
-|       a        |         b          |  c   |
-+----------------+--------------------+------+
-| 1.012345678901 | 2.0123456789012346 | +Inf |
-+----------------+--------------------+------+
-(1 row)
-# Note that the value in "b" has been limited to 17 digits.
-~~~
-
-## Supported casting and conversion
-
-`FLOAT` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`INT` | Truncates decimal precision and requires values to be between -2^63 and 2^63-1
-`DECIMAL` | Causes an error to be reported if the value is NaN or +/- Inf.
-`BOOL` |  **0** converts to `false`; all other values convert to `true`
-`STRING` | --
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/flyway.md b/src/current/v20.2/flyway.md
deleted file mode 100644
index 03841fac012..00000000000
--- a/src/current/v20.2/flyway.md
+++ /dev/null
@@ -1,189 +0,0 @@
----
-title: Migrate CockroachDB Schemas with Flyway
-summary: This tutorial walks you through a series of simple database schema changes using Flyway, an open-source schema migration tool.
-toc: true
----
-
-This page walks you through a series of simple database schema changes using Flyway, an open-source schema migration tool. For detailed information about using Flyway, see the [Flyway documentation site](https://flywaydb.org/documentation/).
-
-## Watch the demo
-
-{% include_cached youtube.html video_id="xz4j5tU0ZRU" %}
-
-## Before You Begin
-
-Before you begin, do the following:
-
-1. [Install CockroachDB](install-cockroachdb.html) and [start a secure cluster](secure-a-cluster.html).    
-1. Download the latest version of the [Flyway command-line tool](https://flywaydb.org/documentation/commandline/#download-and-installation). CockroachDB v20.2 is fully compatible with Flyway versions 7.1.0 and greater.
-
-## Step 1. Configure Flyway connect to CockroachDB
-
-1. Extract the Flyway TAR file that you downloaded, and change directories to the extracted `flyway-x.x.x` folder. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ tar -xvf flyway-commandline-6.4.2-macosx-x64.tar.gz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cd flyway-6.4.2
-    ~~~
-
-1. Edit the `flyway-x.x.x/conf/flyway.conf` configuration file to specify the correct [connection parameters](connection-parameters.html) for your running, secure cluster. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ conf
-    ...
-    flyway.url=jdbc:postgresql://localhost:26257/bank?ssl=true&sslmode=require&sslrootcert=certs/ca.crt&sslkey=certs/client.max.key&sslcert=certs/client.max.crt
-    flyway.user=max
-    flyway.password=roach
-    ...
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    The SSL connection parameters in the connection URL must specify the full path to the certificates that you generated when you [started the secure cluster](secure-a-cluster.html). Also, the user that you specify (e.g., `max`) must also have [admin privileges](grant.html) on the database whose schema you want to change (e.g., `bank`).
-    {{site.data.alerts.end}}
-
-## Step 2. Create a schema migration
-
-Flyway executes SQL statements defined in `.sql` files located in the `flyway-x.x.x/sql` subdirectory. The schema changes defined in these `.sql` files are known as *migrations*.
-
-1. Create a `.sql` file with a name that follows the [Flyway naming conventions](https://flywaydb.org/documentation/migrations#naming). For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ touch sql/V1__Add_accounts_table.sql
-    ~~~
-
-1. Edit the `.sql` file, adding a [`CREATE TABLE IF NOT EXISTS`](create-table.html) statement for the table that you want to create, and a simple [`INSERT`](insert.html) statement to initialize the table with some data. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    /* Create accounts table */
-    CREATE TABLE IF NOT EXISTS accounts (
-      id INT PRIMARY KEY,
-      balance INT
-    );
-
-    /* Add initial data to accounts table */
-    INSERT INTO accounts (id, balance) VALUES (1, 1000), (2, 250);
-    ~~~
-
-## Step 3. Execute a schema migration
-
-To execute the migration, run the following command from the top of the `flyway-x.x.x` directory:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./flyway migrate
-~~~
-
-You should see output similar to the following:
-
-~~~
-Database: jdbc:postgresql://localhost:26257/bank (PostgreSQL 9.5)
-Successfully validated 1 migration (execution time 00:00.011s)
-Creating Schema History table "bank"."flyway_schema_history" ...
-Current version of schema "bank": << Empty Schema >>
-Migrating schema "bank" to version 1 - Add accounts table [non-transactional]
-Successfully applied 1 migration to schema "bank" (execution time 00:00.081s)
-~~~
-
-The schema `"bank"` is now on version 1.
-
-## Step 4. Add additional migrations
-
-Suppose that you want to change the primary key of the `accounts` table from a simple, incrementing [integer](int.html) (in this case, `id`) to an auto-generated [UUID](uuid.html), to follow some [CockroachDB best practices](performance-best-practices-overview.html#unique-id-best-practices). You can make these changes to the schema by creating and executing an additional migration:
-
-1. Create a second `.sql` schema migration file, and name the file following the [Flyway naming conventions](https://flywaydb.org/documentation/migrations#naming), to specify a new migration version. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ touch sql/V2__Alter_accounts_pk.sql
-    ~~~
-
-    This file will create a version 2 of the `"bank"` schema.
-
-1. Edit the `V2__Alter_accounts_pk.sql` migration file, adding some SQL statements that will add a new column to the `accounts` table, and alter the table's primary key. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    /* Add new UUID-typed column */
-    ALTER TABLE accounts ADD COLUMN unique_id UUID NOT NULL DEFAULT gen_random_uuid();
-
-    /* Change primary key */
-    ALTER TABLE accounts ALTER PRIMARY KEY USING COLUMNS (unique_id);
-    ~~~
-
-1. Execute the migration by running the `flyway migrate` command from the top of the `flyway-x.x.x` directory:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./flyway migrate
-    ~~~
-
-    You should see output similar to the following:
-
-    ~~~
-    Flyway Community Edition 6.4.2 by Redgate
-    Database: jdbc:postgresql://localhost:26257/bank (PostgreSQL 9.5)
-    Successfully validated 2 migrations (execution time 00:00.016s)
-    Current version of schema "bank": 1
-    Migrating schema "bank" to version 2 - Alter accounts pk [non-transactional]
-    DB: primary key changes are finalized asynchronously; further schema changes on this table may be restricted until the job completes
-    Successfully applied 1 migration to schema "bank" (execution time 00:00.508s)
-    ~~~
-
-    The schema `"bank"` is now on version 2.
-
-1. Check the complete and pending Flyway migrations with the `flyway info` command:
-
-    ~~~ shell
-    $ ./flyway info
-    ~~~
-
-    ~~~
-    Flyway Community Edition 6.4.2 by Redgate
-    Database: jdbc:postgresql://localhost:26257/bank (PostgreSQL 9.5)
-    Schema version: 2
-
-    +-----------+---------+--------------------+------+---------------------+---------+
-    | Category  | Version | Description        | Type | Installed On        | State   |
-    +-----------+---------+--------------------+------+---------------------+---------+
-    | Versioned | 1       | Add accounts table | SQL  | 2020-05-13 17:16:54 | Success |
-    | Versioned | 2       | Alter accounts pk  | SQL  | 2020-05-14 13:27:27 | Success |
-    +-----------+---------+--------------------+------+---------------------+---------+
-    ~~~
-
-## Flyway and Transactions
-
-When used with most databases, [Flyway wraps the statements in a migration within a single transaction](https://flywaydb.org/documentation/migrations#transactions). When used with CockroachDB, Flyway does *not* wrap schema migrations in transactions. [Transaction boundaries](transactions.html) are instead handled by CockroachDB.
-
-### Transaction retries
-
-When multiple, concurrent transactions or statements are issued to a single CockroachDB cluster, [transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention) can cause schema migrations to fail. In the event of transaction contention, CockroachDB returns a `40001 SQLSTATE` (i.e., a serialization failure), and Flyway automatically retries the migration. For more information about client-side transaction retries in CockroachDB, see [Transaction Retries](transactions.html#transaction-retries).
-
-### Transactional schema changes
-
-Support for [transactional schema changes](online-schema-changes.html) is limited in CockroachDB. As a result, if a migration with multiple schema changes fails at any point, the partial migration could leave the database schema in an incomplete state. If this happens, manual intervention will be required to determine the state of the schema, in addition to any possible fixes.
-
-Note that this limitation also applies to single [`ALTER TABLE`](alter-table.html) statements that include multiple schema changes (e.g., `ALTER TABLE ... ALTER COLUMN ... RENAME ..., ADD COLUMN ...`).
-
-## Report Issues with Flyway and CockroachDB
-
-If you run into problems, please file an issue on the [Flyway issue tracker](https://github.com/flyway/flyway/issues), including the following details about the environment where you encountered the issue:
-
-- CockroachDB version ([`cockroach version`](cockroach-version.html))
-- Flyway version
-- Operating system
-- Steps to reproduce the behavior
-
-## See Also
-
-+ [Flyway documentation](https://flywaydb.org/documentation/)
-+ [Flyway issue tracker](https://github.com/flyway/flyway/issues)
-+ [Client connection parameters](connection-parameters.html)
-+ [Third-Party Database Tools](third-party-database-tools.html)
-+ [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
diff --git a/src/current/v20.2/follower-reads.md b/src/current/v20.2/follower-reads.md
deleted file mode 100644
index 1b1a47dd204..00000000000
--- a/src/current/v20.2/follower-reads.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: Follower Reads
-summary: To reduce latency for read queries, you can choose to have the closest node serve the request using the follower reads feature.
-toc: true
----
-
-Follower reads are a mechanism that CockroachDB uses to provide faster reads in situations where you can afford to read data that may be slightly less than current (using [`AS OF SYSTEM TIME`](as-of-system-time.html)). Normally, reads have to be serviced by a replica's [leaseholder](architecture/overview.html#architecture-leaseholder). This can be slow, since the leaseholder may be geographically distant from the gateway node that is issuing the query.
-
-A follower read is a read taken from the closest [replica](architecture/overview.html#architecture-replica), regardless of the replica's leaseholder status. This can result in much better latency in [geo-distributed, multi-region deployments](topology-patterns.html#multi-region-patterns).
-
- The shortest interval at which [`AS OF SYSTEM TIME`](as-of-system-time.html) can serve follower reads is 4.8 seconds. In prior versions of CockroachDB, the interval was 48 seconds.
-
-For instructions showing how to use follower reads to get low latency, historical reads in multi-region deployments, see the [Follower Reads Topology Pattern](topology-follower-reads.html).
-
-{{site.data.alerts.callout_info}}
-This is an [Enterprise feature](enterprise-licensing.html).
-{{site.data.alerts.end}}
-
-## Watch the demo
-
-{% include_cached youtube.html video_id="V--skgN_JMo" %}
-
-## How follower reads work
-
-Each CockroachDB node tracks a property called its "closed timestamp", which means that no new writes can ever be introduced below that timestamp. The closed timestamp advances forward by some target interval behind the current time. If the replica receives a write at a timestamp less than its closed timestamp, it rejects the write.
-
-With [follower reads enabled](#enable-disable-follower-reads), any replica on a node can serve a read for a key as long as the time at which the operation is performed (i.e., the [`AS OF SYSTEM TIME`](as-of-system-time.html) value) is less or equal to the node's closed timestamp.
-
-When a gateway node in a cluster with follower reads enabled receives a request to read a key with a sufficiently old [`AS OF SYSTEM TIME`](as-of-system-time.html) value, it forwards the request to the closest node that contains a replica of the data–– whether it be a follower or the leaseholder.
-
-## When to use follower reads
-
-As long as your [`SELECT` operations](select-clause.html) can tolerate reading data that was current as of the [follower read timestamp](#run-queries-that-use-follower-reads), follower reads can reduce read latencies and increase throughput.
-
-You should not use follower reads when your application cannot tolerate reading data that was current as of the [follower read timestamp](#run-queries-that-use-follower-reads), since the results of follower reads may not reflect the latest writes against the tables you are querying.
-
-In addition, follower reads are "read-only" operations; they cannot be used in any way in read-write transactions.
-
-## Using follower reads
-
-### Enable/disable follower reads
-
-Use [`SET CLUSTER SETTING`](set-cluster-setting.html) to set `kv.closed_timestamp.follower_reads_enabled` to:
-
-- `true` to enable follower reads _(default)_
-- `false` to disable follower reads
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING kv.closed_timestamp.follower_reads_enabled = false;
-~~~
-
-If you have follower reads enabled, you may want to [verify that follower reads are happening](#verify-that-follower-reads-are-happening).
-
-{{site.data.alerts.callout_info}}
-If follower reads are enabled, but the time-travel query is not using [`AS OF SYSTEM TIME`](as-of-system-time.html) far enough in the past (as defined by the [follower read timestamp](#run-queries-that-use-follower-reads)), CockroachDB does not perform a follower read. Instead, the read accesses the [leaseholder replica](architecture/overview.html#architecture-leaseholder). This adds network latency if the leaseholder is not the closest replica to the gateway node.
-{{site.data.alerts.end}}
-
-### Verify that follower reads are happening
-
-To verify that your cluster is performing follower reads:
-
-1. Make sure that [follower reads are enabled](#enable-disable-follower-reads).
-2. Go to the [Custom Chart Debug Page in the DB Console](ui-custom-chart-debug-page.html) and add the metric `follower_read.success_count` to the time series graph you see there. The number of follower reads performed by your cluster will be shown.
-
-### Run queries that use follower reads
-
-Any [`SELECT` statement](select-clause.html) with an [`AS OF SYSTEM TIME`](as-of-system-time.html) value at least 4.8 seconds in the past can be a follower read (i.e., served by any replica).
-
-To simplify this calculation, we've added the convenience [function](functions-and-operators.html) `follower_read_timestamp()`. `follower_read_timestamp()` returns the [`TIMESTAMP`](timestamp.html) `statement_timestamp() - 4.8s` (known as the [follower read timestamp](follower-reads.html#run-queries-that-use-follower-reads)). Using this function in an `AS OF SYSTEM TIME` statement will set the time as close as possible to the present time while remaining safe for [follower reads](follower-reads.html):
-
-``` sql
-SELECT ... FROM ... AS OF SYSTEM TIME follower_read_timestamp();
-```
-
-### Run read-only transactions that use follower reads
-
-You can set the [`AS OF SYSTEM TIME`](as-of-system-time.html) value for all operations in a read-only transaction:
-
-```sql
-BEGIN;
-
-SET TRANSACTION AS OF SYSTEM TIME follower_read_timestamp();
-SELECT ...
-SELECT ...
-
-COMMIT;
-```
-
-Note that follower reads are "read-only" operations; they cannot be used in any way in read-write transactions.
-
-{{site.data.alerts.callout_success}}
-Using the [`SET TRANSACTION`](set-transaction.html#use-the-as-of-system-time-option) statement as shown in the example above will make it easier to use the follower reads feature from [drivers and ORMs](install-client-drivers.html).
-{{site.data.alerts.end}}
-
-## Follower reads and long-running writes
-
-Long-running write transactions will create write intents with a timestamp near when the transaction began. When a follower read encounters a write intent, it will often end up in a "transaction wait queue", waiting for the operation to complete; however, this runs counter to the benefit follower reads provides.
-
-To counteract this, you can issue all follower reads in explicit transactions set with `HIGH` priority:
-
-```sql
-BEGIN PRIORITY HIGH AS OF SYSTEM TIME follower_read_timestamp();
-SELECT ...
-SELECT ...
-COMMIT;
-```
-
-## See Also
-
-- [Cluster Settings Overview](cluster-settings.html)
-- [Load-Based Splitting](load-based-splitting.html)
-- [Network Latency Page](ui-network-latency-page.html)
-- [Enterprise Features](enterprise-licensing.html)
-- [Follower Reads Topology Pattern](topology-follower-reads.html)
diff --git a/src/current/v20.2/foreign-key.md b/src/current/v20.2/foreign-key.md
deleted file mode 100644
index 4ae12b69dc5..00000000000
--- a/src/current/v20.2/foreign-key.md
+++ /dev/null
@@ -1,927 +0,0 @@
----
-title: Foreign Key Constraint
-summary: The `FOREIGN KEY` constraint specifies a column can contain only values exactly matching existing values from the column it references.
-toc: true
----
-
-A foreign key is a column (or combination of columns) in a table whose values must match values of a column in some other table. `FOREIGN KEY` constraints enforce [referential integrity](https://en.wikipedia.org/wiki/Referential_integrity), which essentially says that if column value A refers to column value B, then column value B must exist.
-
-For example, given an `orders` table and a `customers` table, if you create a column `orders.customer_id` that references the `customers.id` primary key:
-
-- Each value inserted or updated in `orders.customer_id` must exactly match a value in `customers.id`, or be `NULL`.
-- Values in `customers.id` that are referenced by `orders.customer_id` cannot be deleted or updated, unless you have [cascading actions](#use-a-foreign-key-constraint-with-cascade). However, values of `customers.id` that are _not_ present in `orders.customer_id` can be deleted or updated.
-
-To learn more about the basics of foreign keys, watch the video below:
-
-{% include_cached youtube.html video_id="5kiMg7GXAsY" widescreen=true %}
-
-{{site.data.alerts.callout_success}}
-To read more about how foreign keys work, see our [What is a Foreign Key? (With SQL Examples)](https://www.cockroachlabs.com/blog/what-is-a-foreign-key/) blog post.
-{{site.data.alerts.end}}
-
-## Details
-
-### Rules for creating foreign keys
-
-**Foreign Key Columns**
-
-- Foreign key columns must use their referenced column's [type](data-types.html).
-- A foreign key column cannot be a [computed column](computed-columns.html).
-- A single column can have multiple foreign key constraints. For an example, see [Add multiple foreign key constraints to a single column](#add-multiple-foreign-key-constraints-to-a-single-column).
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> CockroachDB no longer requires an index on foreign key columns.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-To improve query performance on tables with foreign keys, we recommend indexing all foreign key columns.
-{{site.data.alerts.end}}
-
-**Referenced Columns**
-
-- Referenced columns must contain only unique sets of values. This means the `REFERENCES` clause must use exactly the same columns as a [`UNIQUE`](unique.html) or [`PRIMARY KEY`](primary-key.html) constraint on the referenced table, in the same order as they are defined in the referenced table. For example, the clause `REFERENCES tbl (C, D)` requires `tbl` to have either the constraint `UNIQUE (C, D)` or `PRIMARY KEY (C, D)`.
-- In the `REFERENCES` clause, if you specify a table but no columns, CockroachDB references the table's primary key. In these cases, the `FOREIGN KEY` constraint and the referenced table's primary key must contain the same number of columns.
-- <span class="version-tag">New in v20.2:</span> By default, referenced columns must be in the same database as the referencing foreign key column. To enable cross-database foreign key references, set the `sql.cross_db_fks.enabled` [cluster setting](cluster-settings.html) to `true`.
-
-### Null values
-
-Single-column foreign keys accept null values.
-
-Multiple-column (composite) foreign keys only accept null values in the following scenarios:
-
-- The write contains null values for all foreign key columns (if `MATCH FULL` is specified).
-- The write contains null values for at least one foreign key column (if `MATCH SIMPLE` is specified).
-
-For more information about composite foreign keys, see the [composite foreign key matching](#composite-foreign-key-matching) section.
-
-Note that allowing null values in either your foreign key or referenced columns can degrade their referential integrity, since any key with a null value is never checked against the referenced table. To avoid this, you can use a [`NOT NULL` constraint](not-null.html) on foreign keys when [creating your tables](create-table.html).
-
-{{site.data.alerts.callout_info}}
-A `NOT NULL` constraint cannot be added to existing tables.
-{{site.data.alerts.end}}
-
-### Composite foreign key matching
-
-By default, composite foreign keys are matched using the `MATCH SIMPLE` algorithm (which is the same default as Postgres). `MATCH FULL` is available if specified. You can specify both `MATCH FULL` and `MATCH SIMPLE`.
-
-All composite key matches defined prior to version 19.1 use the `MATCH SIMPLE` comparison method. If you had a composite foreign key constraint and have just upgraded to version 19.1, then please check that `MATCH SIMPLE` works for your schema and consider replacing that foreign key constraint with a `MATCH FULL` one.
-
-#### How it works
-
-For matching purposes, composite foreign keys can be in one of three states:
-
-- **Valid**: Keys that can be used for matching foreign key relationships.
-
-- **Invalid**: Keys that will not be used for matching (including for any cascading operations).
-
-- **Unacceptable**: Keys that cannot be inserted at all (an error is signalled).
-
-`MATCH SIMPLE` stipulates that:
-
-- **Valid** keys may not contain any null values.
-
-- **Invalid** keys contain one or more null values.
-
-- **Unacceptable** keys do not exist from the point of view of `MATCH SIMPLE`; all composite keys are acceptable.
-
-`MATCH FULL` stipulates that:
-
-- **Valid** keys may not contain any null values.
-
-- **Invalid** keys must have all null values.
-
-- **Unacceptable** keys have any combination of both null and non-null values. In other words, `MATCH FULL` requires that if any column of a composite key is `NULL`, then all columns of the key must be `NULL`.
-
-For examples showing how these key matching algorithms work, see [Match composite foreign keys with `MATCH SIMPLE` and `MATCH FULL`](#match-composite-foreign-keys-with-match-simple-and-match-full).
-
-{{site.data.alerts.callout_info}}
-CockroachDB does not support `MATCH PARTIAL`. For more information, see issue [#20305](https://github.com/cockroachdb/cockroach/issues/20305).
-{{site.data.alerts.end}}
-
-### Foreign key actions
-
-When you set a foreign key constraint, you can control what happens to the constrained column when the column it's referencing (the foreign key) is deleted or updated.
-
-Parameter | Description
-----------|------------
-`ON DELETE NO ACTION` | _Default action._ If there are any existing references to the key being deleted, the transaction will fail at the end of the statement. The key can be updated, depending on the `ON UPDATE` action. <br><br>Alias: `ON DELETE RESTRICT`
-`ON UPDATE NO ACTION` | _Default action._ If there are any existing references to the key being updated, the transaction will fail at the end of the statement. The key can be deleted, depending on the `ON DELETE` action. <br><br>Alias: `ON UPDATE RESTRICT`
-`ON DELETE RESTRICT` / `ON UPDATE RESTRICT` | `RESTRICT` and `NO ACTION` are currently equivalent until options for deferring constraint checking are added. To set an existing foreign key action to `RESTRICT`, the foreign key constraint must be dropped and recreated.
-`ON DELETE CASCADE` / `ON UPDATE CASCADE` | When a referenced foreign key is deleted or updated, all rows referencing that key are deleted or updated, respectively. If there are other alterations to the row, such as a `SET NULL` or `SET DEFAULT`, the delete will take precedence. <br><br>Note that `CASCADE` does not list objects it drops or updates, so it should be used cautiously.
-`ON DELETE SET NULL` / `ON UPDATE SET NULL` | When a referenced foreign key is deleted or updated, respectively, the columns of all rows referencing that key will be set to `NULL`. The column must allow `NULL` or this update will fail.
-`ON DELETE SET DEFAULT` / `ON UPDATE SET DEFAULT` | When a referenced foreign key is deleted or updated, the columns of all rows referencing that key are set to the default value for that column. <br/><br/> If the default value for the column is null, or if no default value is provided and the column does not have a [`NOT NULL`](not-null.html) constraint, this will have the same effect as `ON DELETE SET NULL` or `ON UPDATE SET NULL`. The default value must still conform with all other constraints, such as `UNIQUE`.
-
-{{site.data.alerts.callout_info}}
- If a foreign key column has multiple constraints that reference the same column, the foreign key action that is specified by the first foreign key takes precedence. For an example, see [Add multiple foreign key constraints to a single column](#add-multiple-foreign-key-constraints-to-a-single-column).
-{{site.data.alerts.end}}
-
-### Performance
-
-Because the foreign key constraint requires per-row checks on two tables, statements involving foreign key or referenced columns can take longer to execute.
-
-To improve query performance, we recommend doing the following:
-
-- Create a secondary index on all referencing foreign key columns that are not already indexed.
-
-- For bulk inserts into new tables with foreign key or referenced columns, use the [`IMPORT`](import.html) statement instead of [`INSERT`](insert.html).
-
-    {{site.data.alerts.callout_danger}}
-    Using [`IMPORT INTO`](import-into.html) will invalidate foreign keys without a [`VALIDATE CONSTRAINT`](validate-constraint.html) statement.
-    {{site.data.alerts.end}}
-
-## Syntax
-
-Foreign key constraints can be defined at the [table level](#table-level). However, if you only want the constraint to apply to a single column, it can be applied at the [column level](#column-level).
-
-{{site.data.alerts.callout_info}}
-You can also add the `FOREIGN KEY` constraint to existing tables through [`ADD CONSTRAINT`](add-constraint.html#add-the-foreign-key-constraint-with-cascade).
-{{site.data.alerts.end}}
-
-### Column level
-
-<div>{% include {{ page.version.version }}/sql/diagrams/foreign_key_column_level.html %}</div>
-
-| Parameter | Description |
-|-----------|-------------|
-| `table_name` | The name of the table you're creating. |
-| `column_name` | The name of the foreign key column. |
-| `column_type` | The foreign key column's [data type](data-types.html). |
-| `parent_table` | The name of the table the foreign key references. |
-| `ref_column_name` | The name of the column the foreign key references. <br/><br/>If you do not include the `ref_column_name` you want to reference from the `parent_table`, CockroachDB uses the first column of `parent_table`'s primary key.
-| `column_constraints` | Any other column-level [constraints](constraints.html) you want to apply to this column. |
-| `column_def` | Definitions for any other columns in the table. |
-| `table_constraints` | Any table-level [constraints](constraints.html) you want to apply. |
-
-**Example**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS orders (
-    id INT PRIMARY KEY,
-    customer INT NOT NULL REFERENCES customers (id) ON DELETE CASCADE,
-    orderTotal DECIMAL(9,2),
-    INDEX (customer)
-  );
-~~~
-{{site.data.alerts.callout_danger}}
-`CASCADE` does not list objects it drops or updates, so it should be used cautiously.
-{{site.data.alerts.end}}
-
-### Table level
-
-<div>{% include {{ page.version.version }}/sql/diagrams/foreign_key_table_level.html %}</div>
-
-| Parameter | Description |
-|-----------|-------------|
-| `table_name` | The name of the table you're creating. |
-| `column_def` | Definitions for the table's columns. |
-| `name` | The name of the constraint. |
-| `fk_column_name` | The name of the foreign key column. |
-| `parent_table` | The name of the table the foreign key references. |
-| `ref_column_name` | The name of the column the foreign key references. <br/><br/>If you do not include the `column_name` you want to reference from the `parent_table`, CockroachDB uses the first column of `parent_table`'s primary key.
-| `table_constraints` | Any other table-level [constraints](constraints.html) you want to apply. |
-
-**Example**
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE packages (
-    customer INT,
-    "order" INT,
-    id INT,
-    address STRING(50),
-    delivered BOOL,
-    delivery_date DATE,
-    PRIMARY KEY (customer, "order", id),
-    CONSTRAINT fk_order FOREIGN KEY (customer, "order") REFERENCES orders
-    );
-~~~
-
-## Usage examples
-
-### Use a foreign key constraint with default actions
-
-In this example, we'll create a table with a foreign key constraint with the default [actions](#foreign-key-actions) (`ON UPDATE NO ACTION ON DELETE NO ACTION`).
-
-First, create the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers (id INT PRIMARY KEY, email STRING UNIQUE);
-~~~
-
-Next, create the referencing table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS orders (
-    id INT PRIMARY KEY,
-    customer INT NOT NULL REFERENCES customers (id),
-    orderTotal DECIMAL(9,2),
-    INDEX (customer)
-  );
-~~~
-
-Let's insert a record into each table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers VALUES (1001, 'a@co.tld'), (1234, 'info@cockroachlabs.com');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders VALUES (1, 1002, 29.99);
-~~~
-~~~
-pq: foreign key violation: value [1002] not found in customers@primary [id]
-~~~
-
-The second record insertion returns an error because the customer `1002` doesn't exist in the referenced table.
-
-Let's insert a record into the referencing table and try to update the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders VALUES (1, 1001, 29.99);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE customers SET id = 1002 WHERE id = 1001;
-~~~
-~~~
-pq: foreign key violation: value(s) [1001] in columns [id] referenced in table "orders"
-~~~
-
-The update to the referenced table returns an error because `id = 1001` is referenced and the default [foreign key action](#foreign-key-actions) is enabled (`ON UPDATE NO ACTION`). However, `id = 1234` is not referenced and can be updated:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE customers SET id = 1111 WHERE id = 1234;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers;
-~~~
-~~~
-   id  |         email
-+------+------------------------+
-  1001 | a@co.tld
-  1111 | info@cockroachlabs.com
-(2 rows)
-~~~
-
-Now let's try to delete a referenced row:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM customers WHERE id = 1001;
-~~~
-~~~
-pq: foreign key violation: value(s) [1001] in columns [id] referenced in table "orders"
-~~~
-
-Similarly, the deletion returns an error because `id = 1001` is referenced and the default [foreign key action](#foreign-key-actions) is enabled (`ON DELETE NO ACTION`). However, `id = 1111` is not referenced and can be deleted:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM customers WHERE id = 1111;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers;
-~~~
-~~~
-   id  |  email
-+------+----------+
-  1001 | a@co.tld
-(1 row)
-~~~
-
-### Use a Foreign Key Constraint with `CASCADE`
-
-In this example, we'll create a table with a foreign key constraint with the [foreign key actions](#foreign-key-actions) `ON UPDATE CASCADE` and `ON DELETE CASCADE`.
-
-First, create the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers_2 (
-    id INT PRIMARY KEY
-  );
-~~~
-
-Then, create the referencing table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders_2 (
-    id INT PRIMARY KEY,
-    customer_id INT REFERENCES customers_2(id) ON UPDATE CASCADE ON DELETE CASCADE
-  );
-~~~
-
-Insert a few records into the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers_2 VALUES (1), (2), (3);
-~~~
-
-Insert some records into the referencing table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders_2 VALUES (100,1), (101,2), (102,3), (103,1);
-~~~
-
-Now, let's update an `id` in the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE customers_2 SET id = 23 WHERE id = 1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers_2;
-~~~
-~~~
-  id
-+----+
-   2
-   3
-  23
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_2;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  100 |          23
-  101 |           2
-  102 |           3
-  103 |          23
-(4 rows)
-~~~
-
-When `id = 1` was updated to `id = 23` in `customers_2`, the update propagated to the referencing table `orders_2`.
-
-Similarly, a deletion will cascade. Let's delete `id = 23` from `customers_2`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM customers_2 WHERE id = 23;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers_2;
-~~~
-~~~
-  id
-+----+
-   2
-   3
-(2 rows)
-~~~
-
-Let's check to make sure the rows in `orders_2` where `customers_id = 23` were also deleted:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_2;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  101 |           2
-  102 |           3
-(2 rows)
-~~~
-
-### Use a Foreign Key Constraint with `SET NULL`
-
-In this example, we'll create a table with a foreign key constraint with the [foreign key actions](#foreign-key-actions) `ON UPDATE SET NULL` and `ON DELETE SET NULL`.
-
-First, create the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers_3 (
-    id INT PRIMARY KEY
-  );
-~~~
-
-Then, create the referencing table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders_3 (
-    id INT PRIMARY KEY,
-    customer_id INT REFERENCES customers_3(id) ON UPDATE SET NULL ON DELETE SET NULL
-  );
-~~~
-
-Insert a few records into the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers_3 VALUES (1), (2), (3);
-~~~
-
-Insert some records into the referencing table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders_3 VALUES (100,1), (101,2), (102,3), (103,1);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_3;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  100 |           1
-  101 |           2
-  102 |           3
-  103 |           1
-(4 rows)
-~~~
-
-Now, let's update an `id` in the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE customers_3 SET id = 23 WHERE id = 1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers_3;
-~~~
-~~~
-  id
-+----+
-   2
-   3
-  23
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_3;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  100 |        NULL
-  101 |           2
-  102 |           3
-  103 |        NULL
-(4 rows)
-~~~
-
-When `id = 1` was updated to `id = 23` in `customers_3`, the referencing `customer_id` was set to `NULL`.
-
-Similarly, a deletion will set the referencing `customer_id` to `NULL`. Let's delete `id = 2` from `customers_3`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM customers_3 WHERE id = 2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers_3;
-~~~
-~~~
-  id
-+----+
-   3
-  23
-(2 rows)
-~~~
-
-Let's check to make sure the row in `orders_3` where `customers_id = 2` was updated to `NULL`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_3;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  100 |        NULL
-  101 |        NULL
-  102 |           3
-  103 |        NULL
-(4 rows)
-~~~
-
-### Use a Foreign Key Constraint with `SET DEFAULT`
-
-In this example, we'll create a table with a `FOREIGN` constraint with the [foreign key actions](#foreign-key-actions) `ON UPDATE SET DEFAULT` and `ON DELETE SET DEFAULT`.
-
-First, create the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers_4 (
-    id INT PRIMARY KEY
-  );
-~~~
-
-Then, create the referencing table with the `DEFAULT` value for `customer_id` set to `9999`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders_4 (
-    id INT PRIMARY KEY,
-    customer_id INT DEFAULT 9999 REFERENCES customers_4(id) ON UPDATE SET DEFAULT ON DELETE SET DEFAULT
-  );
-~~~
-
-Insert a few records into the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers_4 VALUES (1), (2), (3), (9999);
-~~~
-
-Insert some records into the referencing table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders_4 VALUES (100,1), (101,2), (102,3), (103,1);
-~~~
-
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_4;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  100 |           1
-  101 |           2
-  102 |           3
-  103 |           1
-(4 rows)
-~~~
-
-Now, let's update an `id` in the referenced table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE customers_4 SET id = 23 WHERE id = 1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers_4;
-~~~
-~~~
-   id
-+------+
-     2
-     3
-    23
-  9999
-(4 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_4;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  100 |        9999
-  101 |           2
-  102 |           3
-  103 |        9999
-(4 rows)
-~~~
-
-When `id = 1` was updated to `id = 23` in `customers_4`, the referencing `customer_id` was set to `DEFAULT` (i.e., `9999`). You can see this in the first and last rows of `orders_4`, where `id = 100` and the `customer_id` is now `9999`
-
-Similarly, a deletion will set the referencing `customer_id` to the `DEFAULT` value. Let's delete `id = 2` from `customers_4`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM customers_4 WHERE id = 2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers_4;
-~~~
-~~~
-   id
-+------+
-     3
-    23
-  9999
-(3 rows)
-~~~
-
-Let's check to make sure the corresponding `customer_id` value to `id = 101`, was updated to the `DEFAULT` value (i.e., `9999`) in `orders_4`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_4;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  100 |        9999
-  101 |        9999
-  102 |           3
-  103 |        9999
-(4 rows)
-~~~
-
-If the default value for the `customer_id` column is not set, and the column does not have a [`NOT NULL`](not-null.html) constraint, `ON UPDATE SET DEFAULT` and `ON DELETE SET DEFAULT` actions set referenced column values to `NULL`.
-
-For example, let's create a new `customers_5` table and insert some values:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers_5 (
-    id INT PRIMARY KEY
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers_5 VALUES (1), (2), (3), (4);
-~~~
-
-Then we can create a new `orders_5` table that references the `customers_5` table, but with no default value specified for the `ON UPDATE SET DEFAULT` and `ON DELETE SET DEFAULT` actions:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders_5 (
-    id INT PRIMARY KEY,
-    customer_id INT REFERENCES customers_5(id) ON UPDATE SET DEFAULT ON DELETE SET DEFAULT
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders_5 VALUES (200,1), (201,2), (202,3), (203,4);
-~~~
-
-Deleting and updating values in the `customers_5` table sets the referenced values in `orders_5` to `NULL`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM customers_5 WHERE id = 3;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE customers_5 SET id = 0 WHERE id = 1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders_5;
-~~~
-~~~
-  id  | customer_id
-+-----+-------------+
-  200 |        NULL
-  201 |           2
-  202 |        NULL
-  203 |           4
-(4 rows)
-~~~
-
-### Add multiple foreign key constraints to a single column
-
- You can add more than one foreign key constraint to a single column.
-
-For example, if you create the following tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers (
-    id INT PRIMARY KEY,
-    name STRING,
-    email STRING
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders (
-    id INT PRIMARY KEY,
-    customer_id INT UNIQUE,
-    item_number INT
- );
-~~~
-
-You can create a table with a column that references columns in both the `customers` and `orders` tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE shipments (
-    tracking_number UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-    carrier STRING,
-    status STRING,
-    customer_id INT,
-    CONSTRAINT fk_customers FOREIGN KEY (customer_id) REFERENCES customers(id),
-    CONSTRAINT fk_orders FOREIGN KEY (customer_id) REFERENCES orders(customer_id)
-  );
-~~~
-
-Inserts into the `shipments` table must fulfill both foreign key constraints on `customer_id` (`fk_customers` and `fk_customers_2`).
-
-Let's insert a record into each table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers VALUES (1001, 'Alexa', 'a@co.tld'), (1234, 'Evan', 'info@cockroachlabs.com');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders VALUES (1, 1001, 25), (2, 1234, 15), (3, 2000, 5);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO shipments (carrier, status, customer_id) VALUES ('USPS', 'Out for delivery', 1001);
-~~~
-
-The last statement succeeds because `1001` matches a unique `id` value in the `customers` table and a unique `customer_id` value in the `orders` table. If `1001` was in neither of the referenced columns, or in just one of them, the statement would return an error.
-
-For instance, the following statement fulfills just one of the foreign key constraints and returns an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO shipments (carrier, status, customer_id) VALUES ('DHL', 'At facility', 2000);
-~~~
-
-~~~
-ERROR: insert on table "shipments" violates foreign key constraint "fk_customers"
-SQLSTATE: 23503
-DETAIL: Key (customer_id)=(2000) is not present in table "customers".
-~~~
-
-CockroachDB allows you to add multiple foreign key constraints on the same column, that reference the same column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE shipments ADD CONSTRAINT fk_customers_2 FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS FROM shipments;
-~~~
-
-~~~
-  table_name | constraint_name | constraint_type |                               details                                | validated
--------------+-----------------+-----------------+----------------------------------------------------------------------+------------
-  shipments  | fk_customers    | FOREIGN KEY     | FOREIGN KEY (customer_id) REFERENCES customers(id)                   |   true
-  shipments  | fk_customers_2  | FOREIGN KEY     | FOREIGN KEY (customer_id) REFERENCES customers(id) ON DELETE CASCADE |   true
-  shipments  | fk_orders       | FOREIGN KEY     | FOREIGN KEY (customer_id) REFERENCES orders(customer_id)             |   true
-  shipments  | primary         | PRIMARY KEY     | PRIMARY KEY (tracking_number ASC)                                    |   true
-(4 rows)
-~~~
-
-There are now two foreign key constraints on `customer_id` that reference the `customers(id)` column (i.e., `fk_customers` and `fk_customers_2`).
-
-In the event of a `DELETE` or `UPDATE` to the referenced column (`customers(id)`), the action for the first foreign key specified takes precedence. In this case, that will be the default [action](#foreign-key-actions) (`ON UPDATE NO ACTION ON DELETE NO ACTION`) on the first foreign key constraint (`fk_customers`). This means that `DELETE`s on referenced columns will fail, even though the second foreign key constraint (`fk_customer_2`) is defined with the `ON DELETE CASCADE` action.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM orders WHERE customer_id = 1001;
-~~~
-
-~~~
-ERROR: delete on table "orders" violates foreign key constraint "fk_orders" on table "shipments"
-SQLSTATE: 23503
-DETAIL: Key (customer_id)=(1001) is still referenced from table "shipments".
-~~~
-
-### Match composite foreign keys with `MATCH SIMPLE` and `MATCH FULL`
-
-The examples in this section show how composite foreign key matching works for both the `MATCH SIMPLE` and `MATCH FULL` algorithms. For a conceptual overview, see [Composite foreign key matching](#composite-foreign-key-matching).
-
-First, let's create some tables. `parent` is a table with a composite key:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE parent (x INT, y INT,  z INT, UNIQUE (x, y, z));
-~~~
-
-`full_test` has a foreign key on `parent` that uses the `MATCH FULL` algorithm:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE full_test (
-    x INT,
-    y INT,
-    z INT,
-    FOREIGN KEY (x, y, z) REFERENCES parent (x, y, z) MATCH FULL ON DELETE CASCADE ON UPDATE CASCADE
-  );
-~~~
-
-`simple_test` has a foreign key on `parent` that uses the `MATCH SIMPLE` algorithm (the default):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE simple_test (
-    x INT,
-    y INT,
-    z INT,
-    FOREIGN KEY (x, y, z) REFERENCES parent (x, y, z) ON DELETE CASCADE ON UPDATE CASCADE
-  );
-~~~
-
-Next, we populate `parent` with some values:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT
-    INTO parent
-  VALUES (1, 1, 1),
-         (2, 1, 1),
-         (1, 2, 1),
-         (1, 1, 2),
-         (NULL, NULL, NULL),
-         (1, NULL, NULL),
-         (NULL, 1, NULL),
-         (NULL, NULL, 1),
-         (1, 1, NULL),
-         (1, NULL, 1),
-         (NULL, 1, 1);
-~~~
-
-Now let's look at some `INSERT` statements to see how the different key matching algorithms work.
-
-- [MATCH SIMPLE](#match-simple)
-- [MATCH FULL](#match-full)
-
-#### MATCH SIMPLE
-
-Inserting values into the table using the `MATCH SIMPLE` algorithm (described [above](#composite-foreign-key-matching)) gives the following results:
-
-| Statement                                         | Can insert? | Throws error? | Notes                         |
-|---------------------------------------------------+-------------+---------------+-------------------------------|
-| `INSERT INTO simple_test VALUES (1,1,1)`          | Yes         | No            | References `parent (1,1,1)`.  |
-| `INSERT INTO simple_test VALUES (NULL,NULL,NULL)` | Yes         | No            | Does not reference `parent`.  |
-| `INSERT INTO simple_test VALUES (1,NULL,NULL)`    | Yes         | No            | Does not reference `parent`.  |
-| `INSERT INTO simple_test VALUES (NULL,1,NULL)`    | Yes         | No            | Does not reference `parent`.  |
-| `INSERT INTO simple_test VALUES (NULL,NULL,1)`    | Yes         | No            | Does not reference `parent`.  |
-| `INSERT INTO simple_test VALUES (1,1,NULL)`       | Yes         | No            | Does not reference `parent`.  |
-| `INSERT INTO simple_test VALUES (1,NULL,1)`       | Yes         | No            | Does not reference `parent`.  |
-| `INSERT INTO simple_test VALUES (NULL,1,1)`       | Yes         | No            | Does not reference `parent`.  |
-| `INSERT INTO simple_test VALUES (2,2,NULL)`       | Yes         | No            | Does not reference `parent`.  |
-| `INSERT INTO simple_test VALUES (2,2,2)`          | No          | Yes           | No `parent` reference exists. |
-
-#### MATCH FULL
-
-Inserting values into the table using the `MATCH FULL` algorithm (described [above](#composite-foreign-key-matching)) gives the following results:
-
-| Statement                                       | Can insert? | Throws error? | Notes                                               |
-|-------------------------------------------------+-------------+---------------+-----------------------------------------------------|
-| `INSERT INTO full_test VALUES (1,1,1)`          | Yes         | No            | References `parent(1,1,1)`.                         |
-| `INSERT INTO full_test VALUES (NULL,NULL,NULL)` | Yes         | No            | Does not reference `parent`.                        |
-| `INSERT INTO full_test VALUES (1,NULL,NULL)`    | No          | Yes           | Can't mix null and non-null values in `MATCH FULL`. |
-| `INSERT INTO full_test VALUES (NULL,1,NULL)`    | No          | Yes           | Can't mix null and non-null values in `MATCH FULL`. |
-| `INSERT INTO full_test VALUES (NULL,NULL,1)`    | No          | Yes           | Can't mix null and non-null values in `MATCH FULL`. |
-| `INSERT INTO full_test VALUES (1,1,NULL)`       | No          | Yes           | Can't mix null and non-null values in `MATCH FULL`. |
-| `INSERT INTO full_test VALUES (1,NULL,1)`       | No          | Yes           | Can't mix null and non-null values in `MATCH FULL`. |
-| `INSERT INTO full_test VALUES (NULL,1,1)`       | No          | Yes           | Can't mix null and non-null values in `MATCH FULL`. |
-| `INSERT INTO full_test VALUES (2,2,NULL)`       | No          | Yes           | Can't mix null and non-null values in `MATCH FULL`. |
-| `INSERT INTO full_test VALUES (2,2,2)`          | No          | Yes           | No `parent` reference exists.                       |
-
-## See also
-
-- [Constraints](constraints.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`CHECK` constraint](check.html)
-- [`DEFAULT` constraint](default-value.html)
-- [`NOT NULL` constraint](not-null.html)
-- [`PRIMARY KEY` constraint](primary-key.html)
-- [`UNIQUE` constraint](unique.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [What is a Foreign Key? (With SQL Examples)](https://www.cockroachlabs.com/blog/what-is-a-foreign-key/)
diff --git a/src/current/v20.2/frequently-asked-questions.md b/src/current/v20.2/frequently-asked-questions.md
deleted file mode 100644
index 3b2ee614d89..00000000000
--- a/src/current/v20.2/frequently-asked-questions.md
+++ /dev/null
@@ -1,184 +0,0 @@
----
-title: Frequently Asked Questions
-summary: CockroachDB frequently asked questions - What is CockroachDB? How does it work? What makes it different from other databases?
-tags: postgres, cassandra, google cloud spanner
-toc: true
----
-
-## What is CockroachDB?
-
-CockroachDB is a [distributed SQL](https://www.cockroachlabs.com/blog/what-is-distributed-sql/) database built on a transactional and strongly-consistent key-value store. It **scales** horizontally; **survives** disk, machine, rack, and even datacenter failures with minimal latency disruption and no manual intervention; supports **strongly-consistent** ACID transactions; and provides a familiar **SQL** API for structuring, manipulating, and querying data.
-
-CockroachDB is inspired by Google's [Spanner](http://research.google.com/archive/spanner.html) and [F1](http://research.google.com/pubs/pub38125.html) technologies, and the [source code](https://github.com/cockroachdb/cockroach) is freely available.
-
-## When is CockroachDB a good choice?
-
-CockroachDB is well suited for applications that require reliable, available, and correct data, and millisecond response times, regardless of scale. It is built to automatically replicate, rebalance, and recover with minimal configuration and operational overhead. Specific use cases include:
-
-- Distributed or replicated OLTP
-- Multi-datacenter deployments
-- Multi-region deployments
-- Cloud migrations
-- Infrastructure initiatives built for the cloud
-
-CockroachDB returns single-row reads in 2ms or less and single-row writes in 4ms or less, and supports a variety of [SQL and operational tuning practices](performance-tuning.html) for optimizing query performance. However, CockroachDB is not yet suitable for heavy analytics / OLAP.
-
-## How easy is it to install CockroachDB?
-
-It's as easy as downloading a binary or running our official Kubernetes configurations or Docker image. There are other simple install methods as well, such as running our Homebrew recipe on OS X or building from source files on both OS X and Linux.
-
-For more details, see [Install CockroachDB](install-cockroachdb.html).
-
-## How does CockroachDB scale?
-
-CockroachDB scales horizontally with minimal operator overhead. You can run it on your local computer, a single server, a corporate development cluster, or a private or public cloud. [Adding capacity](cockroach-start.html) is as easy as pointing a new node at the running cluster.
-
-At the key-value level, CockroachDB starts off with a single, empty range. As you put data in, this single range eventually reaches a threshold size (512 MiB by default). When that happens, the data splits into two ranges, each covering a contiguous segment of the entire key-value space. This process continues indefinitely; as new data flows in, existing ranges continue to split into new ranges, aiming to keep a relatively small and consistent range size.
-
-When your cluster spans multiple nodes (physical machines, virtual machines, or containers), newly split ranges are automatically rebalanced to nodes with more capacity. CockroachDB communicates opportunities for rebalancing using a peer-to-peer [gossip protocol](https://en.wikipedia.org/wiki/Gossip_protocol) by which nodes exchange network addresses, store capacity, and other information.
-
-## How does CockroachDB survive failures?
-
-CockroachDB is designed to survive software and hardware failures, from server restarts to datacenter outages. This is accomplished without confusing artifacts typical of other distributed systems (e.g., stale reads) using strongly-consistent replication as well as automated repair after failures.
-
-**Replication**
-
-CockroachDB replicates your data for availability and guarantees consistency between replicas using the [Raft consensus algorithm](https://raft.github.io/), a popular alternative to <a href="https://www.microsoft.com/en-us/research/publication/paxos-made-simple/" data-proofer-ignore>Paxos</a>. You can [define the location of replicas](configure-replication-zones.html) in various ways, depending on the types of failures you want to secure against and your network topology. You can locate replicas on:
-
-- Different servers within a rack to tolerate server failures
-- Different servers on different racks within a datacenter to tolerate rack power/network failures
-- Different servers in different datacenters to tolerate large scale network or power outages
-
-In a CockroachDB cluster spread across multiple geographic regions, the round-trip latency between regions will have a direct effect on your database's performance. In such cases, it is important to think about the latency requirements of each table and then use the appropriate [data topologies](topology-patterns.html) to locate data for optimal performance and resiliency. For a step-by-step demonstration, see [Low Latency Multi-Region Deployment](demo-low-latency-multi-region-deployment.html).
-
-**Automated Repair**
-
-For short-term failures, such as a server restart, CockroachDB uses Raft to continue seamlessly as long as a majority of replicas remain available. Raft makes sure that a new “leader” for each group of replicas is elected if the former leader fails, so that transactions can continue and affected replicas can rejoin their group once they’re back online. For longer-term failures, such as a server/rack going down for an extended period of time or a datacenter outage, CockroachDB automatically rebalances replicas from the missing nodes, using the unaffected replicas as sources. Using capacity information from the gossip network, new locations in the cluster are identified and the missing replicas are re-replicated in a distributed fashion using all available nodes and the aggregate disk and network bandwidth of the cluster.
-
-## How is CockroachDB strongly-consistent?
-
-CockroachDB guarantees [serializable SQL transactions](demo-serializable.html), the highest isolation level defined by the SQL standard. It does so by combining the Raft consensus algorithm for writes and a custom time-based synchronization algorithms for reads.
-
-- Stored data is versioned with MVCC, so [reads simply limit their scope to the data visible at the time the read transaction started](architecture/transaction-layer.html#time-and-hybrid-logical-clocks).
-
-- Writes are serviced using the [Raft consensus algorithm](https://raft.github.io/), a popular alternative to <a href="https://www.microsoft.com/en-us/research/publication/paxos-made-simple/" data-proofer-ignore>Paxos</a>. A consensus algorithm guarantees that any majority of replicas together always agree on whether an update was committed successfully. Updates (writes) must reach a majority of replicas (2 out of 3 by default) before they are considered committed.
-
-  To ensure that a write transaction does not interfere with read transactions that start after it, CockroachDB also uses a [timestamp cache](architecture/transaction-layer.html#timestamp-cache) which remembers when data was last read by ongoing transactions.
-
-  This ensures that clients always observe serializable consistency with regards to other concurrent transactions.
-
-## How is CockroachDB both highly available and strongly consistent?
-
-The [CAP theorem](https://en.wikipedia.org/wiki/CAP_theorem) states that it is impossible for a distributed system to simultaneously provide more than two out of the following three guarantees:
-
-- Consistency
-- Availability
-- Partition Tolerance
-
-CockroachDB is a CP (consistent and partition tolerant) system. This means
-that, in the presence of partitions, the system will become unavailable rather than do anything which might cause inconsistent results. For example, writes require acknowledgements from a majority of replicas, and reads require a lease, which can only be transferred to a different node when writes are possible.
-
-Separately, CockroachDB is also Highly Available, although "available" here means something different than the way it is used in the CAP theorem. In the CAP theorem, availability is a binary property, but for High Availability, we talk about availability as a spectrum (using terms like "five nines" for a system that is available 99.999% of the time).
-
-Being both CP and HA means that whenever a majority of replicas can talk to each other, they should be able to make progress. For example, if you deploy CockroachDB to three datacenters and the network link to one of them fails, the other two datacenters should be able to operate normally with only a few seconds' disruption. We do this by attempting to detect partitions and failures quickly and efficiently, transferring leadership to nodes that are able to communicate with the majority, and routing internal traffic away from nodes that are partitioned away.
-
-## Why is CockroachDB SQL?
-
-At the lowest level, CockroachDB is a distributed, strongly-consistent, transactional key-value store, but the external API is Standard SQL with extensions. This provides developers familiar relational concepts such as schemas, tables, columns, and indexes and the ability to structure, manipulate, and query data using well-established and time-proven tools and processes. Also, since CockroachDB supports the PostgreSQL wire protocol, it’s simple to get your application talking to Cockroach; just find your [PostgreSQL language-specific driver](install-client-drivers.html) and start building.
-
-For more details, learn our [basic CockroachDB SQL statements](learn-cockroachdb-sql.html), explore the [full SQL grammar](sql-grammar.html), and try it out via our [built-in SQL client](cockroach-sql.html). Also, to understand how CockroachDB maps SQL table data to key-value storage and how CockroachDB chooses the best index for running a query, see [SQL in CockroachDB](https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-table-data-to-key-value-storage/) and [Index Selection in CockroachDB](https://www.cockroachlabs.com/blog/index-selection-cockroachdb-2/).
-
-## Does CockroachDB support distributed transactions?
-
-Yes. CockroachDB distributes transactions across your cluster, whether it’s a few servers in a single location or many servers across multiple datacenters. Unlike with sharded setups, you do not need to know the precise location of data; you just talk to any node in your cluster and CockroachDB gets your transaction to the right place seamlessly. Distributed transactions proceed without downtime or additional latency while rebalancing is underway. You can even move tables – or entire databases – between data centers or cloud infrastructure providers while the cluster is under load.
-
-## Do transactions in CockroachDB guarantee ACID semantics?
-
-Yes. Every [transaction](transactions.html) in CockroachDB guarantees [ACID semantics](https://en.wikipedia.org/wiki/ACID) spanning arbitrary tables and rows, even when data is distributed.
-
-- **Atomicity:** Transactions in CockroachDB are “all or nothing.” If any part of a transaction fails, the entire transaction is aborted, and the database is left unchanged. If a transaction succeeds, all mutations are applied together with virtual simultaneity. For a detailed discussion of atomicity in CockroachDB transactions, see [How CockroachDB Distributes Atomic Transactions](https://www.cockroachlabs.com/blog/how-cockroachdb-distributes-atomic-transactions/).
-- **Consistency:** SQL operations never see any intermediate states and move the database from one valid state to another, keeping indexes up to date. Operations always see the results of previously completed statements on overlapping data and maintain specified constraints such as unique columns. For a detailed look at how we've tested CockroachDB for correctness and consistency, see [CockroachDB Beta Passes Jepsen Testing](https://www.cockroachlabs.com/blog/cockroachdb-beta-passes-jepsen-testing/).
-- **Isolation:** Transactions in CockroachDB implement the strongest ANSI isolation level: serializable (`SERIALIZABLE`). This means that transactions will never result in anomalies. For more information about transaction isolation in CockroachDB, see [Transactions: Isolation Levels](transactions.html#isolation-levels).
-- **Durability:** In CockroachDB, every acknowledged write has been persisted consistently on a majority of replicas (by default, at least 2) via the [Raft consensus algorithm](https://raft.github.io/). Power or disk failures that affect only a minority of replicas (typically 1) do not prevent the cluster from operating and do not lose any data.
-
-## Since CockroachDB is inspired by Spanner, does it require atomic clocks to synchronize time?
-
-No. CockroachDB was designed to work without atomic clocks or GPS clocks. It’s a database intended to be run on arbitrary collections of nodes, from physical servers in a corp development cluster to public cloud infrastructure using the flavor-of-the-month virtualization layer. It’d be a showstopper to require an external dependency on specialized hardware for clock synchronization. However, CockroachDB does require moderate levels of clock synchronization for correctness. If clocks drift past a maximum threshold, nodes will be taken offline. It's therefore highly recommended to run [NTP](http://www.ntp.org/) or other clock synchronization software on each node.
-
-For more details on how CockroachDB handles unsynchronized clocks, see [Clock Synchronization](recommended-production-settings.html#clock-synchronization). And for a broader discussion of clocks, and the differences between clocks in Spanner and CockroachDB, see [Living Without Atomic Clocks](https://www.cockroachlabs.com/blog/living-without-atomic-clocks/).
-
-## What languages can I use to work with CockroachDB?
-
-CockroachDB supports the PostgreSQL wire protocol, so you can use any available PostgreSQL client drivers. We've tested it from the following languages:
-
-- Go
-- Python
-- Ruby
-- Java
-- JavaScript (node.js)
-- C++/C
-- Clojure
-- PHP
-- Rust
-
-See [Install Client Drivers](install-client-drivers.html) for more details.
-
-## Why does CockroachDB use the PostgreSQL wire protocol instead of the MySQL protocol?
-
-CockroachDB uses the PostgreSQL wire protocol because it is better documented than the MySQL protocol, and because PostgreSQL has a liberal Open Source license, similar to BSD or MIT licenses, whereas MySQL has the more restrictive GNU General Public License.
-
-Note, however, that the protocol used doesn't significantly impact how easy it is to port applications. Swapping out SQL network drivers is rather straightforward in nearly every language. What makes it hard to move from one database to another is the dialect of SQL in use. CockroachDB's dialect is based on PostgreSQL as well.
-
-## What is CockroachDB’s security model?
-
-You can run a secure or insecure CockroachDB cluster. When secure, client/node and inter-node communication is encrypted, and SSL certificates authenticate the identity of both clients and nodes. When insecure, there's no encryption or authentication.
-
-Also, CockroachDB supports common SQL privileges on databases and tables. The `root` user has privileges for all databases, while unique users can be granted privileges for specific statements at the database and table-levels.
-
-For more details, see our [Security Overview](security-overview.html).
-
-## How does CockroachDB compare to MySQL or PostgreSQL?
-
-While all of these databases support SQL syntax, CockroachDB is the only one that scales easily (without the manual complexity of sharding), rebalances and repairs itself automatically, and distributes transactions seamlessly across your cluster.
-
-For more insight, see [CockroachDB in Comparison](cockroachdb-in-comparison.html).
-
-## How does CockroachDB compare to Cassandra, HBase, MongoDB, or Riak?
-
-While all of these are distributed databases, only CockroachDB supports distributed transactions and provides strong consistency. Also, these other databases provide custom APIs, whereas CockroachDB offers standard SQL with extensions.
-
-For more insight, see [CockroachDB in Comparison](cockroachdb-in-comparison.html).
-
-## Can a PostgreSQL or MySQL application be migrated to CockroachDB?
-
-Yes. Most users should be able to follow the instructions in [Migrate from Postgres](migrate-from-postgres.html) or [Migrate from MySQL](migrate-from-mysql.html). Due to differences in available features and syntax, some features supported by these databases may require manual effort to port to CockroachDB. Check those pages for details.
-
-We also fully support [importing your data via CSV](migrate-from-csv.html).
-
-## Does Cockroach Labs offer a cloud database as a service?
-
-Yes. The CockroachDB {{ site.data.products.cloud }} offering is currently in Limited Availability and accepting customers on a qualified basis. The offering provides a running CockroachDB cluster suitable to your needs, fully managed by Cockroach Labs on GCP or AWS. Benefits include:
-
-- No provisioning or deployment efforts for you
-- Daily full backups and hourly incremental backups of your data
-- Upgrades to the latest stable release of CockroachDB
-- Monitoring to provide SLA-level support
-
-For more details, see the [CockroachDB {{ site.data.products.cloud }}](../cockroachcloud/quickstart.html) docs.
-
-## Why did Cockroach Labs change the license for CockroachDB?
-
-Our past outlook on the right business model relied on a crucial norm in the OSS world: that companies could build a business around a strong open source core product without a much larger technology platform company coming along and offering the same product as a service.
-
-Recently, however, OSS companies have seen the rise of highly-integrated providers take advantage of their unique position to offer “as-a-service” versions of OSS products, and offer a superior user experience as a consequence of their integrations. We’ve most recently seen it happen with Amazon’s forked version of ElasticSearch.
-
-To respond to this breed of competitor, we changed our software licensing terms. To learn more about our motivations, see the [Licensing FAQs](licensing-faqs.html) as well as our [blog post](https://www.cockroachlabs.com/blog/oss-relicensing-cockroachdb/) about the license change.
-
-## Have questions that weren’t answered?
-
-Try searching the rest of our docs for answers or using our other [support resources](support-resources.html), including:
-
-- [CockroachDB Community Forum](https://forum.cockroachlabs.com)
-- [CockroachDB Community Slack](https://cockroachdb.slack.com)
-- [StackOverflow](http://stackoverflow.com/questions/tagged/cockroachdb)
-- [CockroachDB Support Portal](https://support.cockroachlabs.com)
diff --git a/src/current/v20.2/functions-and-operators.md b/src/current/v20.2/functions-and-operators.md
deleted file mode 100644
index d765e8bed2d..00000000000
--- a/src/current/v20.2/functions-and-operators.md
+++ /dev/null
@@ -1,123 +0,0 @@
----
-title: Functions and Operators
-summary: CockroachDB supports many built-in functions, aggregate functions, and operators.
-toc: true
----
-
-CockroachDB supports the following SQL functions and operators for use in [scalar expressions](scalar-expressions.html).
-
-{{site.data.alerts.callout_success}}In the <a href="cockroach-sql.html#help">built-in SQL shell</a>, use <code>\hf [function]</code> to get inline help about a specific function.{{site.data.alerts.end}}
-
-## Special syntax forms
-
-The following syntax forms are recognized for compatibility with the
-SQL standard and PostgreSQL, but are equivalent to regular built-in
-functions:
-
-{% include {{ page.version.version }}/sql/function-special-forms.md %}
-
-## Conditional and function-like operators
-
-The following table lists the operators that look like built-in
-functions but have special evaluation rules:
-
- Operator | Description
-----------|-------------
- `ANNOTATE_TYPE(...)` | [Explicitly Typed Expression](scalar-expressions.html#explicitly-typed-expressions)
- `ARRAY(...)` | [Conversion of Subquery Results to An Array](scalar-expressions.html#conversion-of-subquery-results-to-an-array)
- `ARRAY[...]` | [Conversion of Scalar Expressions to An Array](scalar-expressions.html#array-constructors)
- `CAST(...)` | [Type Cast](scalar-expressions.html#explicit-type-coercions)
- `COALESCE(...)` | [First non-NULL expression with Short Circuit](scalar-expressions.html#coalesce-and-ifnull-expressions)
- `EXISTS(...)` | [Existence Test on the Result of Subqueries](scalar-expressions.html#existence-test-on-the-result-of-subqueries)
- `IF(...)` | [Conditional Evaluation](scalar-expressions.html#if-expressions)
- `IFNULL(...)` | Alias for `COALESCE` restricted to two operands
- `NULLIF(...)` | [Return `NULL` conditionally](scalar-expressions.html#nullif-expressions)
- `ROW(...)` | [Tuple Constructor](scalar-expressions.html#tuple-constructor)
-
-## Built-in functions
-
-{% remote_include https://raw.githubusercontent.com/cockroachdb/cockroach/{{ page.release_info.crdb_branch_name }}/docs/generated/sql/functions.md %}
-
-## Aggregate functions
-
-For examples showing how to use aggregate functions, see [the `SELECT` clause documentation](select-clause.html#aggregate-functions).
-
-{{site.data.alerts.callout_info}}
-Non-commutative aggregate functions are sensitive to the order in which the rows are processed in the surrounding [`SELECT` clause](select-clause.html#aggregate-functions). To specify the order in which input rows are processed, you can add an [`ORDER BY`](order-by.html) clause within the function argument list. For examples, see the [`SELECT` clause](select-clause.html#order-aggregate-function-input-rows-by-column) documentation.
-{{site.data.alerts.end}}
-
-{% remote_include https://raw.githubusercontent.com/cockroachdb/cockroach/{{ page.release_info.crdb_branch_name }}/docs/generated/sql/aggregates.md %}
-
-## Window functions
-
-{% remote_include https://raw.githubusercontent.com/cockroachdb/cockroach/{{ page.release_info.crdb_branch_name }}/docs/generated/sql/window_functions.md %}
-
-## Operators
-
-The following table lists all CockroachDB operators from highest to lowest precedence, i.e., the order in which they will be evaluated within a statement. Operators with the same precedence are left associative. This means that those operators are grouped together starting from the left and moving right.
-
-| Order of Precedence | Operator | Name | Operator Arity |
-| ------------------- | -------- | ---- | -------------- |
-| 1 | `.` | Member field access operator | binary |
-| 2 | `::` | [Type cast](scalar-expressions.html#explicit-type-coercions) | binary |
-| 3 | `-` | Unary minus | unary (prefix) |
-|  | `~` | Bitwise not | unary (prefix) |
-| 4 | `^` | Exponentiation | binary |
-| 5 | `*` | Multiplication | binary |
-|  | `/` | Division | binary |
-|  | `//` | Floor division | binary |
-|  | `%` | Modulo | binary |
-| 6 | `+` | Addition | binary |
-|  | `-` | Subtraction | binary |
-| 7 | `<<` | Bitwise left-shift | binary |
-|  | `>>` | Bitwise right-shift | binary |
-| 8 | `&` | Bitwise AND | binary |
-| 9 | `#` | Bitwise XOR | binary |
-| 10 | <code>&#124;</code> | Bitwise OR | binary |
-| 11 | <code>&#124;&#124;</code> | Concatenation | binary |
-|    | `< ANY`, ` SOME`, ` ALL` | [Multi-valued] "less than" comparison | binary |
-|    | `> ANY`, ` SOME`, ` ALL` | [Multi-valued] "greater than" comparison | binary |
-|    | `= ANY`, ` SOME`, ` ALL` | [Multi-valued] "equal" comparison | binary |
-|    | `<= ANY`, ` SOME`, ` ALL` | [Multi-valued] "less than or equal" comparison | binary |
-|    | `>= ANY`, ` SOME`, ` ALL` | [Multi-valued] "greater than or equal" comparison | binary |
-|    | `<> ANY` / `!= ANY`, `<> SOME` / `!= SOME`, `<> ALL` / `!= ALL` | [Multi-valued] "not equal" comparison | binary |
-|    | `[NOT] LIKE ANY`, `[NOT] LIKE SOME`, `[NOT] LIKE ALL` | [Multi-valued] `LIKE` comparison | binary |
-|    | `[NOT] ILIKE ANY`, `[NOT] ILIKE SOME`, `[NOT] ILIKE ALL` | [Multi-valued] `ILIKE` comparison | binary |
-| 12 | `[NOT] BETWEEN` | Value is [not] within the range specified | binary |
-|  | `[NOT] BETWEEN SYMMETRIC` | Like `[NOT] BETWEEN`, but in non-sorted order. For example, whereas `a BETWEEN b AND c` means `b <= a <= c`, `a BETWEEN SYMMETRIC b AND c` means `(b <= a <= c) OR (c <= a <= b)`. | binary |
-|  | `[NOT] IN` | Value is [not] in the set of values specified | binary |
-|  | `[NOT] LIKE` | Matches [or not] LIKE expression, case sensitive  | binary |
-|  | `[NOT] ILIKE` | Matches [or not] LIKE expression, case insensitive | binary |
-|  | `[NOT] SIMILAR` | Matches [or not] SIMILAR TO regular expression | binary |
-|  | `~` | Matches regular expression, case sensitive | binary |
-|  | `!~` | Does not match regular expression, case sensitive | binary |
-|  | `~*` | Matches regular expression, case insensitive | binary |
-|  | `!~*` | Does not match regular expression, case insensitive | binary |
-| 13 | `=` | Equal | binary |
-|  | `<` | Less than | binary |
-|  | `>` | Greater than | binary |
-|  | `<=` | Less than or equal to | binary |
-|  | `>=` | Greater than or equal to | binary |
-|  | `!=`, `<>` | Not equal | binary |
-| 14 | `IS [DISTINCT FROM]` | Equal, considering `NULL` as value | binary |
-|  | `IS NOT [DISTINCT FROM]` | `a IS NOT b` equivalent to `NOT (a IS b)` | binary |
-|  | `ISNULL`, `IS UNKNOWN` , `NOTNULL`, `IS NOT UNKNOWN` | Equivalent to `IS NULL` / `IS NOT NULL` | unary (postfix) |
-|  | `IS NAN`, `IS NOT NAN` | [Comparison with the floating-point NaN value](scalar-expressions.html#comparison-with-nan) | unary (postfix) |
-|  | `IS OF(...)` | Type predicate | unary (postfix)
-| 15 | `NOT` | [Logical NOT](scalar-expressions.html#logical-operators) | unary |
-| 16 | `AND` | [Logical AND](scalar-expressions.html#logical-operators) | binary |
-| 17 | `OR` | [Logical OR](scalar-expressions.html#logical-operators) | binary |
-
-[Multi-valued]: scalar-expressions.html#multi-valued-comparisons
-
-### Supported operations
-
-{% remote_include https://raw.githubusercontent.com/cockroachdb/cockroach/{{ page.release_info.crdb_branch_name }}/docs/generated/sql/operators.md %}
-
-<!--
-## `CAST()`
-
-there are three syntaxes for dates: `'2016-01-01'::date`, `CAST('2016-01-01' AS DATE)`, and `DATE '2016-01-01'`. the docs should probably prefer the latter form
-
-the `CAST()` function should get its own documentation somewhere; I’m not sure if it needs to be mentioned again in the date section. The `::` form should probably only be mentioned as an alternative to `CAST()`
--->
diff --git a/src/current/v20.2/geojson.md b/src/current/v20.2/geojson.md
deleted file mode 100644
index 64ea6b7ba9f..00000000000
--- a/src/current/v20.2/geojson.md
+++ /dev/null
@@ -1,202 +0,0 @@
----
-title: GeoJSON
-summary: The GeoJSON data format for representing spatial information is based on JavaScript Object Notation (JSON).
-toc: true
----
-
-GeoJSON is a textual data format for representing spatial information.  It is based on [JavaScript Object Notation (JSON)](https://www.json.org).
-
-GeoJSON can be used to represent the following spatial objects, which also have [Well Known Text (WKT)](well-known-text.html) and [Well Known Binary (WKB)](well-known-binary.html) representations:
-
-- Point
-- LineString
-- Polygon
-- MultiPoint
-- MultiLineString
-- MultiPolygon
-- GeometryCollection
-
-GeoJSON introduces the following additional concepts, which are not part of WKT or WKB:
-
-- A "Feature" object that can contain a geometric shape and some additional properties that describe that shape.  This is useful, for example, when drawing maps on the internet in color, such as on [geojson.io](http://geojson.io).  For an example showing how to add color to a GeoJSON feature, [see below](#geojson-features-example).
-- Features can additionally be grouped together into a "FeatureCollection".
-
-{{site.data.alerts.callout_success}}
-For more detailed information, see the [GeoJSON RFC](https://www.rfc-editor.org/rfc/rfc7946.txt).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-GeoJSON should only be used for spatial data that uses the [WGS84](spatial-glossary.html) geographic spatial reference system.  For more information, see [SRID 4326](srid-4326.html).
-{{site.data.alerts.end}}
-
-## Example
-
-In the example below, we will convert a shape represented in [Well Known Text](well-known-text.html) to GeoJSON using the `ST_AsGeoJSON` [function](functions-and-operators.html#spatial-functions).
-
-Here is the WKT:
-
-~~~
-SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902), (-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))
-~~~
-
-Convert it to GeoJSON using the `ST_AsGeoJSON` function:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_AsGeoJSON('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902), (-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))');
-~~~
-
-This is the JSON output of the above, but formatted:
-
-{% include copy-clipboard.html %}
-~~~ json
-{
-    "type": "Polygon",
-    "coordinates": [
-        [
-            [
-                -87.906471,
-                43.038902
-            ],
-            [
-                -95.992775,
-                36.15398
-            ],
-            [
-                -75.704722,
-                36.076944
-            ],
-            [
-                -87.906471,
-                43.038902
-            ]
-        ],
-        [
-            [
-                -87.623177,
-                41.881832
-            ],
-            [
-                -90.199402,
-                38.627003
-            ],
-            [
-                -82.446732,
-                38.413651
-            ],
-            [
-                -87.623177,
-                41.881832
-            ]
-        ]
-    ]
-}
-~~~
-
-<a name="geojson-features-example"></a>
-
-The JSON below is modified from the output above: it is grouped into a GeoJSON `FeatureCollection` in which each `Feature` has additional styling information (in the `properties` field) that can be used in visualization tools such as [geojson.io](http://geojson.io):
-
-{% include copy-clipboard.html %}
-~~~ json
-{
-    "type": "FeatureCollection",
-    "features": [
-        {
-            "properties": {
-                "fill-opacity": 0.3,
-                "stroke": "#30D5C8",
-                "stroke-width": 5,
-                "fill": "#30D5C8"
-            },
-            "geometry": {
-                "coordinates": [
-                    [
-                        [
-                            -87.906471,
-                            43.038902
-                        ],
-                        [
-                            -95.992775,
-                            36.15398
-                        ],
-                        [
-                            -75.704722,
-                            36.076944
-                        ],
-                        [
-                            -87.906471,
-                            43.038902
-                        ]
-                    ],
-                    [
-                        [
-                            -87.623177,
-                            41.881832
-                        ],
-                        [
-                            -90.199402,
-                            38.627003
-                        ],
-                        [
-                            -82.446732,
-                            38.413651
-                        ],
-                        [
-                            -87.623177,
-                            41.881832
-                        ]
-                    ]
-                ],
-                "type": "Polygon"
-            },
-            "type": "Feature"
-        },
-        {
-            "properties": {
-                "stroke": "yellow",
-                "fill-opacity": 0.3,
-                "stroke-width": 9,
-                "fill": "yellow"
-            },
-            "geometry": {
-                "type": "LineString",
-                "coordinates": [
-                    [
-                        -87.623177,
-                        41.881832
-                    ],
-                    [
-                        -90.199402,
-                        38.627003
-                    ],
-                    [
-                        -82.446732,
-                        38.413651
-                    ],
-                    [
-                        -87.623177,
-                        41.881832
-                    ]
-                ]
-            },
-            "type": "Feature"
-        }
-    ]
-}
-~~~
-
-Here is the geometry described above as shown on [geojson.io](http://geojson.io):
-
-<img src="{{ 'images/v20.2/geospatial/geojson_example.png' | relative_url }}" alt="GeoJSON.io output" style="max-width: 100%" >
-
-## See also
-
-- [GeoJSON RFC](https://www.rfc-editor.org/rfc/rfc7946.txt)
-- [Spatial features](spatial-features.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Well known text](well-known-text.html)
-- [Well known binary](well-known-binary.html)
-- [SRID 4326 - longitude and latitude](srid-4326.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/geometrycollection.md b/src/current/v20.2/geometrycollection.md
deleted file mode 100644
index c8a960be508..00000000000
--- a/src/current/v20.2/geometrycollection.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: GEOMETRYCOLLECTION
-summary: A GEOMETRYCOLLECTION is used for gathering one or more of the spatial object types into a group.
-toc: true
----
-
-A `GEOMETRYCOLLECTION` is a collection of heterogeneous [spatial objects](spatial-features.html#spatial-objects), such as [Points](point.html), [LineStrings](linestring.html), [Polygons](polygon.html), or other `GEOMETRYCOLLECTION`s.  It provides a way of referring to a group of spatial objects as one "thing" so that you can operate on it/them more conveniently using various SQL functions.
-
-## Examples
-
-A GeometryCollection can be created from SQL by calling the `st_geomfromtext` function on a GeometryCollection definition expressed in the [Well Known Text (WKT)](spatial-glossary.html#wkt) format as shown below.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeomFromText('GEOMETRYCOLLECTION(POINT(0 0), LINESTRING(0 0, 1440 900), POLYGON((0 0, 0 1024, 1024 1024, 1024 0, 0 0)))');
-~~~
-
-~~~
-                                                                                                                                                              st_geomfromtext
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  0107000000030000000101000000000000000000000000000000000000000102000000020000000000000000000000000000000000000000000000008096400000000000208C40010300000001000000050000000000000000000000000000000000000000000000000000000000000000009040000000000000904000000000000090400000000000009040000000000000000000000000000000000000000000000000
-(1 row)
-~~~
-
-## See also
-
-- [Spatial objects](spatial-features.html#spatial-objects)
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/get-started-with-enterprise-trial.md b/src/current/v20.2/get-started-with-enterprise-trial.md
deleted file mode 100644
index 1a8e070e24a..00000000000
--- a/src/current/v20.2/get-started-with-enterprise-trial.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: Enterprise Trial –– Get Started
-summary: Check out this page to get started with your CockroachDB Enterprise Trial
-toc: true
-license: true
----
-
-Congratulations on starting your CockroachDB Enterprise Trial! With it, you'll not only get access to CockroachDB's core capabilities like [high availability](frequently-asked-questions.html#how-does-cockroachdb-survive-failures) and [`SERIALIZABLE` isolation](frequently-asked-questions.html#how-is-cockroachdb-strongly-consistent), but also our Enterprise-only features like distributed [`BACKUP`](backup.html) &amp; [`RESTORE`](restore.html), [geo-partitioning](partitioning.html), and [cluster visualization](enable-node-map.html).
-
-## Install CockroachDB
-
-If you haven't already, you'll need to [locally install](install-cockroachdb.html), [remotely deploy](manual-deployment.html), or [orchestrate](orchestration.html) CockroachDB.
-
-## Enable Enterprise features
-
-As the CockroachDB `root` user, open the [built-in SQL shell](cockroach-sql.html) in insecure or secure mode, as per your CockroachDB setup. In the following example, we assume that CockroachDB is running in insecure mode.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure
-~~~
-
-{{site.data.alerts.callout_info}}
-If you've secured your deployment, you'll need to [include the flags for your certificates](cockroach-cert.html) instead of the `--insecure` flag.
-{{site.data.alerts.end}}
-
-Now, use the `SET CLUSTER SETTING` command to set the name of your organization and the license key:
-
-{% include copy-clipboard.html %}
-~~~ sql
->  SET CLUSTER SETTING cluster.organization = 'Acme Company'; SET CLUSTER SETTING enterprise.license = 'xxxxxxxxxxxx';
-~~~
-
-Then verify your organization in response to the following query:
-
-{% include copy-clipboard.html %}
-~~~ sql
->  SHOW CLUSTER SETTING cluster.organization;
-~~~
-
-## Use Enterprise features
-
-Your cluster now has access to all of CockroachDB's Enterprise features for the length of the trial:
-
-{% include {{ page.version.version }}/misc/enterprise-features.md %}
-
-## Getting help
-
-If you or your team need any help during your trial, our engineers are available on [CockroachDB Community Slack](https://cockroachdb.slack.com), [our forum](https://forum.cockroachlabs.com/), or [GitHub](https://github.com/cockroachdb/cockroach).</p>
-
-## See also
-
-- [Enterprise Licensing](enterprise-licensing.html)
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`SHOW CLUSTER SETTING`](show-cluster-setting.html)
diff --git a/src/current/v20.2/grant-roles.md b/src/current/v20.2/grant-roles.md
deleted file mode 100644
index 3db6c01a3cd..00000000000
--- a/src/current/v20.2/grant-roles.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: GRANT &lt;roles&gt;
-summary: The GRANT <roles> statement grants user privileges for interacting with specific databases and tables.
-toc: true
----
-
-The `GRANT <roles>` [statement](sql-statements.html) lets you add a [role](authorization.html#create-and-manage-roles) or [user](authorization.html#create-and-manage-users) as a member to a role.
-
-{{site.data.alerts.callout_info}}
- <code>GRANT &lt;roles&gt;</code> is no longer an Enterprise feature and is now freely available in the core version of CockroachDB.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/grant_roles.html %}</div>
-
-## Required privileges
-
-The user granting role membership must be a role admin (i.e., members with the `WITH ADMIN OPTION`) or a member of the `admin` role.
-
-To grant membership to the `admin` role, the user must have `WITH ADMIN OPTION` on the `admin` role.
-
-## Considerations
-
-- Users and roles can be members of roles.
-- The `root` user is automatically created as an `admin` role and assigned the `ALL` privilege for new databases.
-- All privileges of a role are inherited by all its members.
-- Membership loops are not allowed (direct: `A is a member of B is a member of A` or indirect: `A is a member of B is a member of C ... is a member of A`).
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`role_name` | The name of the role to which you want to add members. To add members to multiple roles, use a comma-separated list of role names.
-`user_name` | The name of the [user](authorization.html#create-and-manage-users) or [role](authorization.html#create-and-manage-roles) to whom you want to grant membership. To add multiple members, use a comma-separated list of user and/or role names.
-`WITH ADMIN OPTION` | Designate the user as an role admin. Role admins can grant or revoke membership for the specified role.
-
-## Examples
-
-### Grant role membership
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT design TO ernie;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON ROLE design;
-~~~
-~~~
-+--------+---------+---------+
-|  role  | member  | isAdmin |
-+--------+---------+---------+
-| design | barkley | false   |
-| design | ernie   | false   |
-| design | lola    | false   |
-| design | lucky   | false   |
-+--------+---------+---------+
-~~~
-
-### Grant the admin option
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT design TO ERNIE WITH ADMIN OPTION;
-~~~
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON ROLE design;
-~~~
-~~~
-+--------+---------+---------+
-|  role  | member  | isAdmin |
-+--------+---------+---------+
-| design | barkley | false   |
-| design | ernie   | true    |
-| design | lola    | false   |
-| design | lucky   | false   |
-+--------+---------+---------+
-~~~
-
-## See also
-
-- [Authorization](authorization.html)
-- [`REVOKE <roles>`](revoke-roles.html)
-- [`GRANT <privileges>`](grant.html)
-- [`REVOKE <privileges>`](revoke.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [`SHOW ROLES`](show-roles.html)
-- [Manage Users](authorization.html#create-and-manage-users)
diff --git a/src/current/v20.2/grant.md b/src/current/v20.2/grant.md
deleted file mode 100644
index 7c2819ea105..00000000000
--- a/src/current/v20.2/grant.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: GRANT &lt;privileges&gt;
-summary: The GRANT statement grants user privileges for interacting with specific database objects
-toc: true
----
-
-The `GRANT <privileges>` [statement](sql-statements.html) lets you control each [role](authorization.html#create-and-manage-roles) or [user's](authorization.html#create-and-manage-users) SQL [privileges](authorization.html#assign-privileges) for interacting with specific [databases](create-database.html), [schemas](create-schema.html), [tables](create-table.html), or [user-defined types](enum.html).
-
-For privileges required by specific statements, see the documentation for the respective [SQL statement](sql-statements.html).
-
-## Syntax
-
-~~~
-GRANT {ALL | <privileges...>} ON {DATABASE | SCHEMA | TABLE | TYPE} <targets...> TO <users...>
-~~~
-
-## Parameters
-
-Parameter       | Description
-----------------|------------
-`ALL`           | Grant all [privileges](#supported-privileges).
-`privileges`    | A comma-separated list of privileges to grant. For a list of supported privileges, see [Supported privileges](#supported-privileges).
-`targets`       | A comma-separated list of database, schema, table, or user-defined type names.<br><br>{{site.data.alerts.callout_info}}To grant privileges on all tables in a database or schema, you can use `GRANT ... ON TABLE *`. For an example, see [Grant privileges on all tables in a database or schema](#grant-privileges-on-all-tables-in-a-database-or-schema).{{site.data.alerts.end}}
-`users`         | A comma-separated list of [users](authorization.html#create-and-manage-users) and/or [roles](authorization.html#create-and-manage-roles) to whom you want to grant privileges.
-
-## Supported privileges
-
-Roles and users can be granted the following privileges:
-
-{% include {{ page.version.version }}/sql/privileges.md %}
-
-## Required privileges
-
-The user granting privileges must also have the privilege being granted on the target database or tables. For example, a user granting the `SELECT` privilege on a table to another user must have the `GRANT` and `SELECT` privileges on that table.
-
-## Details
-
-- When a role or user is granted privileges for a database, new tables created in the database will inherit the privileges, but the privileges can then be changed.
-
-    {{site.data.alerts.callout_info}}
-    The user does not get privileges to existing tables in the database. To grant privileges to a user on all existing tables in a database, see [Grant privileges on all tables in a database](#grant-privileges-on-all-tables-in-a-database-or-schema)
-    {{site.data.alerts.end}}
-
-- When a role or user is granted privileges for a table, the privileges are limited to the table.
-- The `root` user automatically belongs to the `admin` role and has the `ALL` privilege for new databases.
-- For privileges required by specific statements, see the documentation for the respective [SQL statement](sql-statements.html).
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Grant privileges on databases
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE USER max WITH PASSWORD roach;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON DATABASE movr TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON DATABASE movr;
-~~~
-
-~~~
-  database_name |    schema_name     | grantee | privilege_type
-----------------+--------------------+---------+-----------------
-  movr          | cockroach_labs     | admin   | ALL
-  movr          | cockroach_labs     | max     | ALL
-  movr          | cockroach_labs     | root    | ALL
-  movr          | crdb_internal      | admin   | ALL
-  movr          | crdb_internal      | max     | ALL
-  movr          | crdb_internal      | root    | ALL
-  movr          | information_schema | admin   | ALL
-  movr          | information_schema | max     | ALL
-  movr          | information_schema | root    | ALL
-  movr          | pg_catalog         | admin   | ALL
-  movr          | pg_catalog         | max     | ALL
-  movr          | pg_catalog         | root    | ALL
-  movr          | pg_extension       | admin   | ALL
-  movr          | pg_extension       | max     | ALL
-  movr          | pg_extension       | root    | ALL
-  movr          | public             | admin   | ALL
-  movr          | public             | max     | ALL
-  movr          | public             | root    | ALL
-(18 rows)
-~~~
-
-### Grant privileges on specific tables in a database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT DELETE ON TABLE rides TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE rides;
-~~~
-
-~~~
-  database_name | schema_name | table_name | grantee | privilege_type
-----------------+-------------+------------+---------+-----------------
-  movr          | public      | rides      | admin   | ALL
-  movr          | public      | rides      | max     | DELETE
-  movr          | public      | rides      | root    | ALL
-(3 rows)
-~~~
-
-### Grant privileges on all tables in a database or schema
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT SELECT ON TABLE movr.public.* TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE movr.public.*;
-~~~
-
-~~~
-  database_name | schema_name |         table_name         | grantee | privilege_type
-----------------+-------------+----------------------------+---------+-----------------
-  movr          | public      | promo_codes                | admin   | ALL
-  movr          | public      | promo_codes                | max     | SELECT
-  movr          | public      | promo_codes                | root    | ALL
-  movr          | public      | rides                      | admin   | ALL
-  movr          | public      | rides                      | max     | DELETE
-  movr          | public      | rides                      | max     | SELECT
-  movr          | public      | rides                      | root    | ALL
-  movr          | public      | user_promo_codes           | admin   | ALL
-  movr          | public      | user_promo_codes           | max     | SELECT
-  movr          | public      | user_promo_codes           | root    | ALL
-  movr          | public      | users                      | admin   | ALL
-  movr          | public      | users                      | max     | ALL
-  movr          | public      | users                      | root    | ALL
-  movr          | public      | vehicle_location_histories | admin   | ALL
-  movr          | public      | vehicle_location_histories | max     | SELECT
-  movr          | public      | vehicle_location_histories | root    | ALL
-  movr          | public      | vehicles                   | admin   | ALL
-  movr          | public      | vehicles                   | max     | SELECT
-  movr          | public      | vehicles                   | root    | ALL
-(19 rows)
-~~~
-
-### Make a table readable to every user in the system
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT SELECT ON TABLE vehicles TO public;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE vehicles;
-~~~
-
-~~~
-  database_name | schema_name | table_name | grantee | privilege_type
-----------------+-------------+------------+---------+-----------------
-  movr          | public      | vehicles   | admin   | ALL
-  movr          | public      | vehicles   | max     | SELECT
-  movr          | public      | vehicles   | public  | SELECT
-  movr          | public      | vehicles   | root    | ALL
-(4 rows)
-~~~
-
-### Grant privileges on schemas
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA cockroach_labs;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON SCHEMA cockroach_labs TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON SCHEMA cockroach_labs;
-~~~
-
-~~~
-  database_name |  schema_name   | grantee | privilege_type
-----------------+----------------+---------+-----------------
-  movr          | cockroach_labs | admin   | ALL
-  movr          | cockroach_labs | max     | ALL
-  movr          | cockroach_labs | root    | ALL
-(3 rows)
-~~~
-
-### Grant privileges on user-defined types
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE status AS ENUM ('available', 'unavailable');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON TYPE status TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TYPE status;
-~~~
-
-~~~
-  database_name | schema_name | type_name | grantee | privilege_type
-----------------+-------------+-----------+---------+-----------------
-  movr          | public      | status    | admin   | ALL
-  movr          | public      | status    | max     | ALL
-  movr          | public      | status    | public  | USAGE
-  movr          | public      | status    | root    | ALL
-(4 rows)
-~~~
-
-### Grant the privilege to manage the replication zones for a database or table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ZONECONFIG ON TABLE rides TO max;
-~~~
-
-The user `max` can then use the [`CONFIGURE ZONE`](configure-zone.html) statement to add, modify, reset, or remove replication zones for the table `rides`.
-
-## See also
-
-- [Authorization](authorization.html)
-- [`REVOKE <roles>`](revoke-roles.html)
-- [`GRANT <roles>`](grant-roles.html)
-- [`REVOKE <privileges>`](revoke.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [`SHOW ROLES`](show-roles.html)
-- [`CONFIGURE ZONE`](configure-zone.html)
-- [Manage Users](authorization.html#create-and-manage-users)
diff --git a/src/current/v20.2/gssapi_authentication.md b/src/current/v20.2/gssapi_authentication.md
deleted file mode 100644
index 7ce4e6d6bcf..00000000000
--- a/src/current/v20.2/gssapi_authentication.md
+++ /dev/null
@@ -1,244 +0,0 @@
----
-title: GSSAPI Authentication (Enterprise)
-summary: Learn about the GSSAPI authentication features for secure CockroachDB clusters.
-toc: true
----
-
-CockroachDB supports the Generic Security Services API (GSSAPI) with Kerberos authentication.
-
-{% include enterprise-feature.md %}
-
-## Requirements
-
-- A working Active Directory or Kerberos environment
-- A Service Principal
-- A GSSAPI-compatible Postgres Client (psql, etc.)
-- A client machine with a Kerberos client installed and configured
-
-## Configuring KDC for CockroachDB
-
-To use Kerberos authentication with CockroachDB, configure a Kerberos service principal name (SPN) for CockroachDB and generate a valid keytab file with the following specifications:
-
-- Set the SPN to the name specified by your client driver. For example, if you use the psql client, set SPN to `postgres`.
-- Create SPNs for all DNS addresses that a user would use to connect to your CockroachDB cluster (including any TCP load balancers between the user and the CockroachDB node) and ensure that the keytab contains the keys for every SPN you create.
-
-### Active Directory
-
-For Active Directory, the client syntax for generating a keytab that maps a service principal to the SPN is as follows:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ktpass -out {keytab_filename} -princ {Client_SPN}/{NODE/LB_FQDN}@{DOMAIN} -mapUser {Service_Principal}@{DOMAIN} -mapOp set -pType KRB5_NT_PRINCIPAL +rndPass -crypto AES256-SHA1
-~~~
-
-Example:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ktpass -out postgres.keytab -princ postgres/loadbalancer1.cockroach.industries@COCKROACH.INDUSTRIES -mapUser pguser@COCKROACH.INDUSTRIES -mapOp set -pType KRB5_NT_PRINCIPAL +rndPass -crypto AES256-SHA1
-~~~
-
-Copy the resulting keytab to the database nodes. If clients are connecting to multiple addresses (more than one load balancer, or clients connecting directly to nodes), you will need to generate a keytab for each client endpoint.  You may want to merge your keytabs together for easier management.  You can do this using the `ktpass` command, using the following syntax:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ktpass -out {new_keytab_filename} -in {old_keytab_filename} -princ {Client_SPN}/{NODE/LB_FQDN}@{DOMAIN} -mapUser {Service_Principal}@{DOMAIN} -mapOp add -pType KRB5_NT_PRINCIPAL +rndPass -crypto AES256-SHA1
-~~~
-
-Example (adds `loadbalancer2` to the above example):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ktpass -out postgres_2lb.keytab -in postgres.keytab -princ postgres/loadbalancer2.cockroach.industries@COCKROACH.INDUSTRIES -mapUser pguser@COCKROACH.INDUSTRIES -mapOp add  -pType KRB5_NT_PRINCIPAL +rndPass -crypto AES256-SHA1
-~~~
-
-### MIT KDC
-
-In MIT KDC, you cannot map a service principal to an SPN with a different username, so you will need to create a service principal that includes the SPN for your client.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ create-user: kadmin.local -q "addprinc {SPN}/{CLIENT_FQDN}@{DOMAIN}" -pw "{initial_password}"
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ create-keytab: kadmin.local -q "ktadd -k keytab {SPN}/{CLIENT_FQDN}@{DOMAIN}"
-~~~
-
-Example:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kadmin.local -q "addprinc postgres/client2.cockroach.industries@COCKROACH.INDUSTRIES" -pw "testing12345!"
-$ kadmin.local -q "ktadd -k keytab postgres/client2.cockroach.industries@COCKROACH.INDUSTRIES"
-~~~
-
-Copy the resulting keytab to the database nodes. If clients are connecting to multiple addresses (more than one load balancer, or clients connecting directly to nodes), you will need to generate a keytab for each client endpoint.  You may want to merge your keytabs together for easier management.  The `ktutil` command can be used to read multiple keytab files and output them into a single output [here](https://web.mit.edu/kerberos/krb5-devel/doc/admin/admin_commands/ktutil.html).
-
-
-## Configuring the CockroachDB node
-1. Copy the keytab file to a location accessible by the `cockroach` binary.
-
-2. [Create certificates](cockroach-cert.html) for inter-node and `root` user authentication:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs my-safe-directory
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-ca \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    localhost \
-    $(hostname) \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-client \
-    root \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-3. Provide the path to the keytab in the `KRB5_KTNAME` environment variable.
-
-    Example: `export KRB5_KTNAME=/home/cockroach/postgres.keytab`
-
-4. Start a CockroachDB node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --listen-addr=0.0.0.0
-    ~~~
-
-5. Connect to CockroachDB as `root` using the `root` client certificate generated above:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs
-    ~~~
-
-6. [Enable an Enterprise license](licensing-faqs.html#obtain-a-license).
-    {{site.data.alerts.callout_info}} You need the Enterprise license if you want to use the GSSAPI feature. However, if you only want to test that the GSSAPI setup is working, you do not need to enable an Enterprise license. {{site.data.alerts.end}}
-
-7. Enable GSSAPI authentication:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET cluster setting server.host_based_authentication.configuration = 'host all all all gss include_realm=0';
-    ~~~
-
-      Setting the `server.host_based_authentication.configuration` [cluster setting](cluster-settings.html) to this particular value makes it mandatory for all non-`root` users to authenticate using GSSAPI. The `root` user is always an exception and remains able to authenticate using a valid client cert or a user password.
-
-      The `include_realm=0` option is required to tell CockroachDB to remove the `@DOMAIN.COM` realm information from the username. We do not support any advanced mapping of GSSAPI usernames to CockroachDB usernames right now. If you want to limit which realms' users can connect, you can also add one or more `krb_realm` parameters to the end of the line as an allowlist, as follows: `host all all all gss include_realm=0 krb_realm=domain.com krb_realm=corp.domain.com`
-
-      The syntax is based on the `pg_hba.conf` standard for PostgreSQL which is documented [here](https://www.postgresql.org/docs/current/auth-pg-hba-conf.html). It can be used to exclude other users from Kerberos authentication.
-
-8. Create CockroachDB users for every Kerberos user. Ensure the username does not have the `DOMAIN.COM` realm information. For example, if one of your Kerberos users has a username `carl@realm.com`, then you need to create a CockroachDB user with the username `carl`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER carl;
-    ~~~
-
-    Grant privileges to the user:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT ALL ON DATABASE defaultdb TO carl;
-    ~~~
-
-## Configuring the client
-
-{{site.data.alerts.callout_info}}
-The `cockroach sql` shell does not yet support GSSAPI authentication. You need to use a GSSAPI-compatible Postgres client, such as Postgres's `psql` client.
-{{site.data.alerts.end}}
-
-1. Install and configure your Kerberos client:
-
-    For CentOS/RHEL systems, run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ yum install krb5-user
-    ~~~
-
-    For Ubuntu/Debian systems, run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ apt-get install krb5-user
-    ~~~
-
-    Edit the `/etc/krb5.conf` file to include:
-
-    {% include copy-clipboard.html %}
-    ~~~
-           [libdefaults]
-    		 default_realm = {REALM}
-
-    	   [realms]
-    		 {REALM} = {
-    		  kdc = {fqdn-kdc-server or ad-server}
-    		  admin_server = {fqdn-kdc-server or ad-server}
-    		  default_domain = {realm-lower-case}
-    		}
-    ~~~
-
-    Example:
-
-    {% include copy-clipboard.html %}
-    ~~~
-
-           [libdefaults]
-    		 default_realm = COCKROACH.INDUSTRIES
-
-    	   [realms]
-    		 COCKROACH.INDUSTRIES = {
-    		  kdc = ad.cockroach.industries
-    		  admin_server = ad.cockroach.industries
-    		  default_domain = cockroach.industries
-    		}
-    ~~~
-
-2. Get a ticket for the db user:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kinit carl
-    ~~~
-
-3. Verify if a valid ticket has been generated:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ klist
-    ~~~
-
-4. Install the Postgres client (for example, postgresql-client-10 Debian package from postgresql.org).
-5. Use the `psql` client, which supports GSSAPI authentication, to connect to CockroachDB:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ psql "postgresql://localhost:26257/defaultdb?sslmode=verify-full&sslrootcert=/certs/ca.crt" -U carl
-    ~~~
-
-4. If you specified an Enterprise license earlier, you should now have a Postgres shell in CockroachDB, indicating that the GSSAPI authentication was successful. If you did not specify an Enterprise license, you'll see a message like this: `psql: ERROR:  use of GSS authentication requires an Enterprise license.` If you see this message, GSSAPI authentication is set up correctly.
-
-## See also
-
-- [Authentication](authentication.html)
-- [Create Security Certificates](cockroach-cert.html)
diff --git a/src/current/v20.2/hash-sharded-indexes.md b/src/current/v20.2/hash-sharded-indexes.md
deleted file mode 100644
index cbb5c20f2a0..00000000000
--- a/src/current/v20.2/hash-sharded-indexes.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: Hash-sharded Indexes
-summary: Hash-sharded indexes can eliminate single-range hotspots and improve write performance on sequentially-keyed indexes at a small cost to read performance
-toc: true
----
-
-If you are working with a table that must be indexed on sequential keys, you should use **hash-sharded indexes**. Hash-sharded indexes distribute sequential traffic uniformly across ranges, eliminating single-range hotspots and improving write performance on sequentially-keyed indexes at a small cost to read performance.
-
-{% include {{ page.version.version }}/misc/experimental-warning.md %}
-
-## How hash-sharded indexes work
-
- CockroachDB automatically splits ranges of data in [the key-value store](architecture/storage-layer.html) based on [the size of the range](architecture/distribution-layer.html#range-splits), and on [the load streaming to the range](load-based-splitting.html). To split a range based on load, the system looks for a point in the range that evenly divides incoming traffic. If the range is indexed on a column of data that is sequential in nature (e.g., [an ordered sequence](sql-faqs.html#what-are-the-differences-between-uuid-sequences-and-unique_rowid), or a series of increasing, non-repeating [`TIMESTAMP`s](timestamp.html)), then all incoming writes to the range will be the last (or first) item in the index and appended to the end of the range. As a result, the system cannot find a point in the range that evenly divides the traffic, and the range cannot benefit from load-based splitting, creating a hotspot on the single range.
-
-For details about the mechanics and performance improvements of hash-sharded indexes in CockroachDB, see our [Hash Sharded Indexes Unlock Linear Scaling for Sequential Workloads](https://www.cockroachlabs.com/blog/hash-sharded-indexes-unlock-linear-scaling-for-sequential-workloads/) blog post.
-
-## How to create a hash-sharded index
-
-To create a hash-sharded index, set the `experimental_enable_hash_sharded_indexes` [session variable](set-vars.html) to `on`. Then, add the optional [`USING HASH WITH BUCKET_COUNT = n_buckets` clause](sql-grammar.html#opt_hash_sharded) to a [`CREATE INDEX`](create-index.html) statement, to an [`INDEX` definition](sql-grammar.html#index_def) in a [`CREATE TABLE`](create-table.html) statement, or to an [`ALTER PRIMARY KEY`](alter-primary-key.html) statement. When this clause is used, CockroachDB creates `n_buckets` computed columns, shards the index into `n_buckets` shards, and then stores each index shard in the underlying key-value store with one of the computed column's hash as its prefix.
-
-To change the bucket size of an existing hash-sharded primary key index, use an [`ALTER PRIMARY KEY`](alter-primary-key.html) statement with a [`USING HASH WITH BUCKET_COUNT = n_buckets` clause](sql-grammar.html#opt_hash_sharded) that specifies the new bucket size and the existing primary key columns.
-
-{{site.data.alerts.callout_info}}
-Hash-sharded indexes cannot be [interleaved](interleave-in-parent.html).
-{{site.data.alerts.end}}
-
-## Examples
-
-For an example of a hash-sharded index, see [Create a hash-sharded secondary index](create-index.html#create-a-hash-sharded-secondary-index).
-
-## See also
-
-- [Indexes](indexes.html)
-- [`CREATE INDEX`](create-index.html)
diff --git a/src/current/v20.2/import-into.md b/src/current/v20.2/import-into.md
deleted file mode 100644
index b47a25cb5fa..00000000000
--- a/src/current/v20.2/import-into.md
+++ /dev/null
@@ -1,471 +0,0 @@
----
-title: IMPORT INTO
-summary: Import CSV data into an existing CockroachDB table.
-toc: true
----
-
-The `IMPORT INTO` [statement](sql-statements.html) imports CSV, Avro, or delimited data into an [existing table](create-table.html), by appending new rows into the table.
-
-## Considerations
-
-- `IMPORT INTO` works for existing tables. To import data into new tables, read the following [Import into a new table from a CSV file](#import-into-a-new-table-from-a-csv-file) example.
-- `IMPORT INTO` cannot be used within a [transaction](transactions.html) or during a [rolling upgrade](upgrade-cockroach-version.html).
-- `IMPORT INTO` takes the table **offline** before importing the data. The table will be online again once the job has completed successfully.
-- `IMPORT INTO` invalidates all [foreign keys](foreign-key.html) on the target table. To validate the foreign key(s), use the [`VALIDATE CONSTRAINT`](validate-constraint.html) statement.
-- `IMPORT INTO` is an insert-only statement; it cannot be used to update existing rows—see [`UPDATE`](update.html). Imported rows cannot conflict with primary keys in the existing table, or any other [`UNIQUE`](unique.html) constraint on the table.
-- `IMPORT INTO` does not offer `SELECT` or `WHERE` clauses to specify subsets of rows. To do this, use [`INSERT`](insert.html#insert-from-a-select-statement).
-
-{{site.data.alerts.callout_info}}
-Optimize import operations in your applications by following our [Import Performance Best Practices](import-performance-best-practices.html).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-#### Table privileges
-
-The user must have the `INSERT` and `DROP` [privileges](authorization.html#assign-privileges) on the specified table. (`DROP` is required because the table is taken offline during the `IMPORT INTO`.)
-
-#### Source privileges
-
-The source file URL does _not_ require the `ADMIN` role in the following scenarios:
-
-- S3 and GS using `SPECIFIED` (and not `IMPLICIT`) credentials. Azure is always `SPECIFIED` by default.
-- [Userfile](use-userfile-for-bulk-operations.html)
-
-The source file URL _does_ require the `ADMIN` role in the following scenarios:
-
-- S3 or GS using `IMPLICIT` credentials
-- Use of a [custom endpoint](https://docs.aws.amazon.com/sdk-for-go/api/aws/endpoints/) on S3
-- [Nodelocal](cockroach-nodelocal-upload.html), [HTTP](use-a-local-file-server-for-bulk-operations.html), or [HTTPS](use-a-local-file-server-for-bulk-operations.html)
-
-Learn more about [cloud storage for bulk operations](use-cloud-storage-for-bulk-operations.html).
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/import_into.html %}
-</div>
-
-{{site.data.alerts.callout_info}}
-While importing into an existing table, the table is taken offline.
-{{site.data.alerts.end}}
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table you want to import into.
-`column_name` | The table columns you want to import.<br><br>Note: Currently, target columns are not enforced.
-`file_location` | The [URL](#import-file-location) of a CSV or Avro file containing the table data. This can be a comma-separated list of URLs. For an example, see [Import into an existing table from multiple CSV files](#import-into-an-existing-table-from-multiple-csv-files) below.
-`<option> [= <value>]` | Control your import's behavior with [import options](#import-options).
-
-#### Delimited data files
-
-<span class="version-tag">New in v20.2:</span> The `DELIMITED DATA` format can be used to import delimited data from any text file type, while ignoring characters that need to be escaped, like the following:
-
-- The file's delimiter (`\t` by default)
-- Double quotes (`"`)
-- Newline (`\n`)
-- Carriage return (`\r`)
-
-For examples showing how to use the `DELIMITED DATA` format, see the [Examples](#import-into-an-existing-table-from-a-delimited-data-file) section below.
-
-### Import options
-
-You can control the `IMPORT` process's behavior using any of the following key-value pairs as a `<option>  [= <value>]`.
-
-Key                 | <div style="width:130px">Context</div> | Value                                                                                                                             
---------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-`delimiter`            | `CSV DATA `     | The unicode character that delimits columns in your rows. **Default: `,`**. <br><br> Example: To use tab-delimited values: `IMPORT INTO foo (..) CSV DATA ('file.csv') WITH delimiter = e'\t';`
-`comment`              | `CSV DATA `     | The unicode character that identifies rows to skip. <br><br> Example: `IMPORT INTO foo (..) CSV DATA ('file.csv') WITH comment = '#';`
-`nullif`               | `CSV DATA `, [`DELIMITED DATA`](#delimited-data-files) | The string that should be converted to *NULL*. <br><br> Example: To use empty columns as *NULL*: `IMPORT INTO foo (..) CSV DATA ('file.csv') WITH nullif = '';`
-`skip`                 | `CSV DATA `, [`DELIMITED DATA`](#delimited-data-files) | The number of rows to be skipped while importing a file. **Default: `'0'`**. <br><br> Example: To import CSV files with column headers: `IMPORT INTO ... CSV DATA ('file.csv') WITH skip = '1';`
-`decompress`           | General         | The decompression codec to be used: `gzip`, `bzip`, `auto`, or `none`.  **Default: `'auto'`**, which guesses based on file extension (`.gz`, `.bz`, `.bz2`). `none` disables decompression. <br><br> Example: `IMPORT INTO ... WITH decompress = 'bzip';`
-`rows_terminated_by`   | [`DELIMITED DATA`](#delimited-data-files)  | The unicode character to indicate new lines in the input file. **Default:** `\n` <br><br> Example: `IMPORT INTO ... WITH rows_terminated_by='\m';`
-`fields_terminated_by` | [`DELIMITED DATA`](#delimited-data-files)  | The unicode character used to separate fields in each input line. **Default:** `\t` <br><br> Example: `IMPORT INTO ... WITH fields_terminated_by=".";`
-`fields_enclosed_by`   | [`DELIMITED DATA`](#delimited-data-files)  | The unicode character that encloses fields. **Default:** `"` <br><br> Example: `IMPORT INTO ... WITH fields_enclosed_by='"';`
-`fields_escaped_by`    | [`DELIMITED DATA`](#delimited-data-files)  | The unicode character, when preceding one of the above `DELIMITED DATA` options, to be interpreted literally. <br><br> Example: `IMPORT INTO ... WITH fields_escaped_by='\';`
-`strict_validation`    | `AVRO DATA`    | Rejects Avro records that do not have a one-to-one mapping between Avro fields to the target CockroachDB schema. By default, CockroachDB ignores unknown Avro fields and sets missing SQL fields to `NULL`. CockroachDB will also attempt to convert the Avro field to the CockroachDB [data type][datatypes]; otherwise, it will report an error. <br><br> Example: `IMPORT INTO foo (..) AVRO DATA ('file.avro') WITH strict_validation;`
-`records_terminated_by` | `AVRO DATA`   | The unicode character to indicate new lines in the input binary or JSON file. This is not needed for Avro OCF. **Default:** `\n` <br><br> Example: To use tab-terminated records: `IMPORT INTO foo (..) AVRO DATA ('file.csv') WITH records_terminated_by = e'\t';`
-`data_as_binary_records` | `AVRO DATA`  | Use when [importing a binary file containing Avro records](migrate-from-avro.html#import-binary-or-json-records).  The schema is not included in the file, so you need to specify the schema with either the `schema` or `schema_uri` option. <br><br> Example: `IMPORT INTO foo (..) AVRO DATA ('file.bjson') WITH data_as_binary_records, schema_uri='..';`
-`data_as_json_records` | `AVRO DATA`    | Use when [importing a JSON file containing Avro records](migrate-from-avro.html#import-binary-or-json-records). The schema is not included in the file, so you need to specify the schema with either the `schema` or `schema_uri` option. <br><br> Example: `IMPORT INTO foo (..) AVRO DATA ('file.bjson') WITH data_as_json_records, schema='{ "type": "record",..}';`
-`schema`               | `AVRO DATA`    | The schema of the Avro records included in the binary or JSON file. This is not needed for Avro OCF. <br> See `data_as_json_records` example above.
-`schema_uri`           | `AVRO DATA`    | The URI of the file containing the schema of the Avro records include in the binary or JSON file. This is not needed for Avro OCF. <br> See `data_as_binary_records` example above.
-
-For examples showing how to use these options, see the [`IMPORT` - Examples section](import.html#examples).
-
-For instructions and working examples showing how to migrate data from other databases and formats, see the [Migration Overview](migration-overview.html). For information on how to import data into new tables, see [`IMPORT`](import.html).
-
-## Requirements
-
-### Prerequisites
-
-Before using `IMPORT INTO`, you should have:
-
-- An existing table to import into (use [`CREATE TABLE`](create-table.html)).
-
-    <span class="version-tag">New in v20.2:</span> `IMPORT INTO` supports [computed columns](computed-columns.html) and the [`DEFAULT` expressions listed below](#supported-default-expressions).
-
-- The CSV or Avro data you want to import, preferably hosted on cloud storage. This location must be equally accessible to all nodes using the same import file location. This is necessary because the `IMPORT INTO` statement is issued once by the client, but is executed concurrently across all nodes of the cluster. For more information, see the [Import file location](#import-file-location) section below.
-
-#### Supported `DEFAULT` expressions
-
-<span class="version-tag">New in v20.2:</span> `IMPORT INTO` supports [computed columns](computed-columns.html) and the following [`DEFAULT`](default-value.html) expressions:
-
-- Constant `DEFAULT` expressions, which are expressions that return the same value in different statements. Examples include:
-
-    - Literals (booleans, strings, integers, decimals, dates)
-    - Functions where each argument is a constant expression and the functions themselves depend solely on their arguments (e.g., arithmetic operations, boolean logical operations, string operations).
-
-- Current [`TIMESTAMP`](timestamp.html) functions that record the transaction timestamp, which include:
-
-    - `current_date()`
-    - `current_timestamp()`
-    - `localtimestamp()`
-    - `now()`
-    - `statement_timestamp()`
-    - `timeofday()`
-    - `transaction_timestamp()`
-
-- `random()`
-- `gen_random_uuid()`
-- `unique_rowid()`
-
-### Available storage
-
-Each node in the cluster is assigned an equal part of the imported data, and so must have enough temp space to store it. In addition, data is persisted as a normal table, and so there must also be enough space to hold the final, replicated data. The node's first-listed/default [`store`](cockroach-start.html#store) directory must have enough available storage to hold its portion of the data.
-
-On [`cockroach start`](cockroach-start.html), if you set `--max-disk-temp-storage`, it must also be greater than the portion of the data a node will store in temp space.
-
-### Import file location
-
-CockroachDB uses the URL provided to construct a secure API call to the service you specify. The URL structure depends on the type of file storage you are using. For more information, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- <span class="version-tag">New in v20.2:</span> [Use `userfile` for Bulk Operations](use-userfile-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-## Performance
-
-All nodes are used during the import job, which means all nodes' CPU and RAM will be partially consumed by the `IMPORT` task in addition to serving normal traffic.
-
-## Viewing and controlling import jobs
-
-After CockroachDB successfully initiates an import into an existing table, it registers the import as a job, which you can view with [`SHOW JOBS`](show-jobs.html).
-
-After the import has been initiated, you can control it with [`PAUSE JOB`](pause-job.html), [`RESUME JOB`](resume-job.html), and [`CANCEL JOB`](cancel-job.html).
-
-If initiated correctly, the statement returns when the import is finished or if it encounters an error. In some cases, the import can continue after an error has been returned (the error message will tell you that the import has resumed in background).
-
-{{site.data.alerts.callout_danger}}
-Pausing and then resuming an `IMPORT INTO` job will cause it to restart from the beginning.
-{{site.data.alerts.end}}
-
-## Examples
-
-The following provide connection examples to cloud storage providers. For more information on connecting to different storage options, read [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html).
-
-We recommend reading the [Considerations](#considerations) section for important details when working with `IMPORT INTO`.
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="s3">Amazon S3</button>
-  <button class="filter-button" data-scope="azure">Azure Storage</button>
-  <button class="filter-button" data-scope="gcs">Google Cloud Storage</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="s3">
-
-{% include {{ page.version.version }}/backups/aws-auth-note.md %}
-
-### Import into a new table from a CSV file
-
-To import into a new table, use [`CREATE TABLE`](create-table.html) followed by `IMPORT INTO`.
-
-First, create the new table with the necessary columns and data types:
-
-{% include copy-clipboard.html %}
-~~~sql
-CREATE TABLE users (
-        id UUID PRIMARY KEY,
-        city STRING,
-        name STRING,
-        address STRING,
-        credit_card STRING
-      );
-~~~
-
-Next, use `IMPORT INTO` to import the data into the new table:
-
-{% include copy-clipboard.html %}
-~~~sql
-IMPORT INTO users (id, city, name, address, credit_card)
-     CSV DATA (
-       's3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-     );
-~~~
-
-### Import into an existing table from a CSV file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers (id, name)
-    CSV DATA (
-      's3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-    );
-~~~
-
-{{site.data.alerts.callout_info}}
-The column order in your `IMPORT` statement must match the column order in the CSV being imported, regardless of the order in the existing table's schema.
-{{site.data.alerts.end}}
-
-### Import into an existing table from multiple CSV files
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers (id, name)
-    CSV DATA (
-      's3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}',
-      's3://{BUCKET NAME}/{customers2.csv}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}',
-      's3://{BUCKET NAME}/{customers3.csv}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}',
-      's3://{BUCKET NAME}/{customers4.csv}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}',
-    );
-~~~
-
-### Import into an existing table from an Avro file
-
- [Avro OCF data](migrate-from-avro.html#import-an-object-container-file), [JSON records, or binary records](migrate-from-avro.html#import-binary-or-json-records) can be imported. The following are examples of importing Avro OCF data.
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers
-    AVRO DATA (
-      's3://{BUCKET NAME}/{customers.avro}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-    );
-~~~
-
-For more information about importing data from Avro, including examples, see [Migrate from Avro](migrate-from-avro.html).
-
-### Import into an existing table from a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers
-    DELIMITED DATA (
-      's3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={KEY ID}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-    )
-    WITH
-      fields_terminated_by='|',
-      fields_enclosed_by='"',
-      fields_escaped_by='\';
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="azure">
-
-### Import into a new table from a CSV file
-
-To import into a new table, use [`CREATE TABLE`](create-table.html) followed by `IMPORT INTO`.
-
-{{site.data.alerts.callout_info}}
-Note that as of v21.2 [`IMPORT TABLE`](import.html) will be deprecated; therefore, we recommend using the following example to import data into a new table.
-{{site.data.alerts.end}}
-
-First, create the new table with the necessary columns and data types:
-
-{% include copy-clipboard.html %}
-~~~sql
-CREATE TABLE users (
-        id UUID PRIMARY KEY,
-        city STRING,
-        name STRING,
-        address STRING,
-        credit_card STRING
-      );
-~~~
-
-Next, use `IMPORT INTO` to import the data into the new table:
-
-{% include copy-clipboard.html %}
-~~~sql
-IMPORT INTO users (id, city, name, address, credit_card)
-     CSV DATA (
-       'azure://{CONTAINER NAME}/{customers.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-     );
-~~~
-
-### Import into an existing table from a CSV file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers (id, name)
-    CSV DATA (
-      'azure://{CONTAINER NAME}/{customers.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-    );
-~~~
-
-{{site.data.alerts.callout_info}}
-The column order in your `IMPORT` statement must match the column order in the CSV being imported, regardless of the order in the existing table's schema.
-{{site.data.alerts.end}}
-
-### Import into an existing table from multiple CSV files
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers (id, name)
-    CSV DATA (
-      'azure://{CONTAINER NAME}/{customers.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',
-      'azure://{CONTAINER NAME}/{customers2.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',
-      'azure://{CONTAINER NAME}/{customers3.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',
-      'azure://{CONTAINER NAME}/{customers4.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',
-      'azure://{CONTAINER NAME}/{customers5.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',    
-    );
-~~~
-
-### Import into an existing table from an Avro file
-
- [Avro OCF data](migrate-from-avro.html#import-an-object-container-file), [JSON records, or binary records](migrate-from-avro.html#import-binary-or-json-records) can be imported. The following are examples of importing Avro OCF data.
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers
-    AVRO DATA (
-      'azure://{CONTAINER NAME}/{customers.avro}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-    );
-~~~
-
-For more information about importing data from Avro, including examples, see [Migrate from Avro](migrate-from-avro.html).
-
-### Import into an existing table from a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers
-    DELIMITED DATA (
-      'azure://{CONTAINER NAME}/{customers.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-    )
-    WITH
-      fields_terminated_by='|',
-      fields_enclosed_by='"',
-      fields_escaped_by='\';
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="gcs">
-
-{% include {{ page.version.version }}/backups/gcs-auth-note.md %}
-
-### Import into a new table from a CSV file
-
-To import into a new table, use [`CREATE TABLE`](create-table.html) followed by `IMPORT INTO`.
-
-{{site.data.alerts.callout_info}}
-Note that as of v21.2 [`IMPORT TABLE`](import.html) will be deprecated; therefore, we recommend using the following example to import data into a new table.
-{{site.data.alerts.end}}
-
-First, create the new table with the necessary columns and data types:
-
-{% include copy-clipboard.html %}
-~~~sql
-CREATE TABLE users (
-        id UUID PRIMARY KEY,
-        city STRING,
-        name STRING,
-        address STRING,
-        credit_card STRING
-      );
-~~~
-
-Next, use `IMPORT INTO` to import the data into the new table:
-
-{% include copy-clipboard.html %}
-~~~sql
-IMPORT INTO users (id, city, name, address, credit_card)
-     CSV DATA (
-       'gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-     );
-~~~
-
-### Import into an existing table from a CSV file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers (id, name)
-    CSV DATA (
-      'gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-    );
-~~~
-
-{{site.data.alerts.callout_info}}
-The column order in your `IMPORT` statement must match the column order in the CSV being imported, regardless of the order in the existing table's schema.
-{{site.data.alerts.end}}
-
-### Import into an existing table from multiple CSV files
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers (id, name)
-    CSV DATA (
-      'gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}',
-      'gs://{BUCKET NAME}/{customers2.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}',
-      'gs://{BUCKET NAME}/{customers3.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}',
-      'gs://{BUCKET NAME}/{customers4.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}',
-    );
-~~~
-
-### Import into an existing table from an Avro file
-
- [Avro OCF data](migrate-from-avro.html#import-an-object-container-file), [JSON records, or binary records](migrate-from-avro.html#import-binary-or-json-records) can be imported. The following are examples of importing Avro OCF data.
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers
-    AVRO DATA (
-      'gs://{BUCKET NAME}/{customers.avro}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-    );
-~~~
-
-For more information about importing data from Avro, including examples, see [Migrate from Avro](migrate-from-avro.html).
-
-### Import into an existing table from a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT INTO customers
-    DELIMITED DATA (
-      'gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-    )
-    WITH
-      fields_terminated_by='|',
-      fields_enclosed_by='"',
-      fields_escaped_by='\';
-~~~
-
-</section>
-
-## Known limitations
-
-- You cannot import into a table with [partial indexes](partial-indexes.html).
-- While importing into an existing table, the table is taken offline.
-- After importing into an existing table, [constraints](constraints.html) will be un-validated and need to be [re-validated](validate-constraint.html).
-- Imported rows must not conflict with existing rows in the table or any unique secondary indexes.
-- `IMPORT INTO` works for only a single existing table, and the table must not be [interleaved](interleave-in-parent.html).
-- `IMPORT INTO` cannot be used within a [transaction](transactions.html).
-- `IMPORT INTO` can sometimes fail with a "context canceled" error, or can restart itself many times without ever finishing. If this is happening, it is likely due to a high amount of disk contention. This can be mitigated by setting the `kv.bulk_io_write.max_rate` [cluster setting](cluster-settings.html) to a value below your max disk write speed. For example, to set it to 10MB/s, execute:
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING kv.bulk_io_write.max_rate = '10MB';
-    ~~~
-
-## See also
-
-- [`IMPORT`](import.html)
-- [Migration Overview](migration-overview.html)
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
diff --git a/src/current/v20.2/import-performance-best-practices.md b/src/current/v20.2/import-performance-best-practices.md
deleted file mode 100644
index 3a884f27574..00000000000
--- a/src/current/v20.2/import-performance-best-practices.md
+++ /dev/null
@@ -1,132 +0,0 @@
----
-title: Import Performance Best Practices
-summary: Best practices for optimizing import performance in CockroachDB.
-toc: true
----
-
-This page provides best practices for optimizing [import](import.html) performance in CockroachDB.
-
-Import speed primarily depends on the amount of data that you want to import. However, there are two main factors that have can have a large impact on the amount of time it will take to run an import:
-
-- [Splitting data](#split-your-data-into-multiple-files)
-- [Import format](#choose-a-performant-import-format)
-
-{{site.data.alerts.callout_info}}
-If the import size is small, then you do not need to do anything to optimize performance. In this case, the import should run quickly, regardless of the settings.
-{{site.data.alerts.end}}
-
-## Split your data into multiple files
-
-Splitting the import data into multiple files can have a large impact on the import performance. The following formats support multi-file import:
-
-- `CSV`
-- `DELIMITED DATA`
-- `AVRO`, when the [schema is provided in-line](#provide-the-table-schema-in-line)
-
-For these formats, we recommend splitting your data into as many files as there are nodes.
-
-For example, if you have a 3-node cluster, split your data into 3 files and [import](import.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-        id UUID PRIMARY KEY,
-        name TEXT,
-        INDEX name_idx (name)
-)
-CSV DATA (
-    'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/customers.csv',
-    'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/customers_2.csv',
-    'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/customers_3.csv',
-);
-~~~
-
-CockroachDB imports the files that you give it, and does not further split them. For example, if you import one large file for all of your data, CockroachDB will process that file on one node– even if you have more nodes available. However, if you import two files (and your cluster has at least two nodes), each node will process a file in parallel. This is why splitting your data into as many files as you have nodes will dramatically decrease the time it takes to import data.
-
-{{site.data.alerts.callout_info}}
-If you split the data into _more_ files than you have nodes, it will not have a large impact on performance.
-{{site.data.alerts.end}}
-
-## Choose a performant import format
-
-Import formats do not have the same performance because of the way they are processed. Below, import formats are listed from fastest to slowest:
-
-1. [`CSV`](migrate-from-csv.html) or [`DELIMITED DATA`](import.html#delimited-data-files) (both have about the same import performance)
-1. [`AVRO`](migrate-from-avro.html)
-1. [`MYSQLDUMP`](migrate-from-mysql.html)
-1. [`PGDUMP`](migrate-from-postgres.html)
-
-We recommend formatting your import files as `CSV`, `DELIMITED DATA`, or `AVRO`. These formats can be processed in parallel by multiple threads, which increases performance.
-
-However, `MYSQLDUMP` and `PGDUMP` run a single thread to parse their data, and therefore have substantially slower performance.
-
-`MYSQLDUMP` and `PGDUMP` are two examples of "bundled" data. This means that the dump file contains both the table schema and the data to import. These formats are the slowest to import, with `PGDUMP` being the slower of the two. This is because CockroachDB has to first load the whole file, read the whole file to get the schema, create the table with that schema, and then import the data. While these formats are slow, there are a couple of things you can do to speed up a bundled data import:
-
-- [Provide the table schema in-line](#provide-the-table-schema-in-line)
-- [Import the schema separately from the data](#import-the-schema-separately-from-the-data)
-
-### Provide the table schema in-line
-
-When importing bundled data formats, it is often faster to provide schema for the imported table in-line. For example, instead of importing both the table schema and data from the same file:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees
-FROM PGDUMP
-    'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/employees-full.sql'
-;
-~~~
-
-You can dump the table data into a CSV file and provide the table schema in the statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-        id UUID PRIMARY KEY,
-        name STRING
-)
-CSV DATA (
-    'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/employees-full.csv'
-);
-~~~
-
-{{site.data.alerts.callout_success}}
-If you need to import multiple tables, you can start multiple [`IMPORT`](import.html) jobs to import tables in parallel from the same import file.
-{{site.data.alerts.end}}
-
-### Import the schema separately from the data
-
-For single-table `MYSQLDUMP` or `PGDUMP` imports, split your dump data into two files:
-
-1. A SQL file containing the table schema
-1. A CSV file containing the table data
-
-Then, import the schema-only file:
-
-~~~ sql
-> IMPORT TABLE customers
-FROM PGDUMP
-    'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/customers.sql'
-;
-~~~
-
-And use the [`IMPORT INTO`](import-into.html) statement to import the CSV data into the newly created table:
-
-~~~ sql
-> IMPORT INTO customers (id, name)
-CSV DATA (
-    'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/customers.csv'
-);
-~~~
-
-This method has the added benefit of alerting on potential issues with the import sooner; that is, you will not have to wait for the file to load both the schema and data just to find an error in the schema.
-
-## See also
-
-- [`IMPORT`](import.html)
-- [Migration Overview](migration-overview.html)
-- [Migrate from Oracle](migrate-from-oracle.html)
-- [Migrate from Postgres](migrate-from-postgres.html)
-- [Migrate from MySQL](migrate-from-mysql.html)
-- [Migrate from CSV](migrate-from-csv.html)
-- [Migrate from Avro](migrate-from-avro.html)
diff --git a/src/current/v20.2/import.md b/src/current/v20.2/import.md
deleted file mode 100644
index 95d471c1af2..00000000000
--- a/src/current/v20.2/import.md
+++ /dev/null
@@ -1,1197 +0,0 @@
----
-title: IMPORT
-summary: The IMPORT statement imports various types of data into CockroachDB.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-The `IMPORT` [statement](sql-statements.html) imports the following types of data into CockroachDB:
-
-- [Avro][avro]
-- [CSV/TSV][csv]
-- [Postgres dump files][postgres]
-- [MySQL dump files][mysql]
-- [CockroachDB dump files](cockroach-dump.html)
-- [Delimited data files](#delimited-data-files)
-
-## Considerations
-
-- `IMPORT` only works for creating new tables. For information on how to import into existing tables, see [`IMPORT INTO`](import-into.html). Also, for instructions and working examples on how to migrate data from other databases, see the [Migration Overview](migration-overview.html).
-- `IMPORT` is a blocking statement and cannot be used within a [transaction](transactions.html).
-- `IMPORT` cannot be used during a [rolling upgrade](upgrade-cockroach-version.html).
-- <span class="version-tag">New in v20.2:</span> `IMPORT` cannot be used with [user-defined types](create-type.html). Use [`IMPORT INTO`](import-into.html) instead.
-
-{{site.data.alerts.callout_info}}
-Optimize import operations in your applications by following our [Import Performance Best Practices](import-performance-best-practices.html).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-#### Table privileges
-
-The user must have the `CREATE` [privileges](authorization.html#assign-privileges) on the target database.
-
-#### Source privileges
-
-{% include {{ page.version.version }}/misc/source-privileges.md %}
-
-## Synopsis
-
-**Import a table from CSV or Avro**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/import_csv.html %}
-</div>
-
-**Import a database or table from dump file**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/import_dump.html %}
-</div>
-
-## Parameters
-
-### For import from CSV or Avro
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table you want to import/create.
-`table_elem_list` | The table schema you want to use.  
-`CREATE USING file_location` | If not specifying the table schema inline via `table_elem_list`, this is the [URL](#import-file-location) of a SQL file containing the table schema.
-`file_location` | The [URL](#import-file-location) of a CSV file containing the table data. This can be [a comma-separated list of URLs to CSV files](#using-a-comma-separated-list) or [specified by a `*` wildcard character](#using-a-wildcard) to include matching files under the specified path.
-`WITH kv_option_list` | Control your import's behavior with [these options](#import-options).
-
-### For import from dump file
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table you want to import/create. Use this when the dump file contains a specific table. Leave out `TABLE table_name FROM` when the dump file contains an entire database.
-`import_format` | [`PGDUMP`](#import-a-postgres-database-dump), [`MYSQLDUMP`](#import-a-mysql-database-dump), or [`DELIMITED DATA`](#delimited-data-files)
-`file_location` | The [URL](#import-file-location) of a dump file you want to import.
-`WITH kv_option_list` | Control your import's behavior with [these options](#import-options).
-
-#### Delimited data files
-
-The `DELIMITED DATA` format can be used to import delimited data from any text file type, while ignoring characters that need to be escaped, like the following:
-
-- The file's delimiter (`\t` by default)
-- Double quotes (`"`)
-- Newline (`\n`)
-- Carriage return (`\r`)
-
-For examples showing how to use the `DELIMITED DATA` format, see the [Examples](#import-a-delimited-data-file) section below.
-
-### Import options
-
-You can control the `IMPORT` process's behavior using any of the following optional key-value pairs as a `kv_option`. To set multiple import options, use a comma-separated list ([see examples](#import-a-delimited-data-file)).
-
-<a name="delimiter"></a>
-
-Key                 | <div style="width:130px">Context</div> | Value                                                                                                                             |
---------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-`delimiter`            | `CSV DATA `     | The unicode character that delimits columns in your rows. **Default: `,`**.
-`comment`              | `CSV DATA `     | The unicode character that identifies rows to skip.
-`strict_quotes`        | `CSV DATA`      | Use if CSV import files have quotes (`""`) within rows to prevent multiple rows from being treated as single rows. **Default:** Off
-`nullif`               | `CSV DATA `, [`DELIMITED DATA`](#delimited-data-files) | The string that should be converted to *NULL*.
-`skip`                 | `CSV DATA `, [`DELIMITED DATA`](#delimited-data-files) | The number of rows to be skipped while importing a file. **Default: `'0'`**.
-`decompress`           | General         | The decompression codec to be used: `gzip`, `bzip`, `auto`, or `none`.  **Default: `'auto'`**, which guesses based on file extension (`.gz`, `.bz`, `.bz2`). `none` disables decompression.
-`skip_foreign_keys`    | `PGDUMP`, `MYSQLDUMP` | Ignore foreign key constraints in the dump file's DDL. **Default:** Off.  May be necessary to import a table with unsatisfied foreign key constraints from a full database dump.
-`max_row_size`         | `PGDUMP`        | Override limit on line size. **Default: 0.5MB**.  This setting may need to be tweaked if your Postgres dump file has extremely long lines, for example as part of a `COPY` statement.
-`rows_terminated_by`   | [`DELIMITED DATA`](#delimited-data-files)  | The unicode character to indicate new lines in the input file. **Default:** `\n`
-`fields_terminated_by` | [`DELIMITED DATA`](#delimited-data-files)  | The unicode character used to separate fields in each input line. **Default:** `\t`
-`fields_enclosed_by`   | [`DELIMITED DATA`](#delimited-data-files)  | The unicode character that encloses fields. **Default:** `"`
-`fields_escaped_by`    | [`DELIMITED DATA`](#delimited-data-files)  | The unicode character, when preceding one of the above `DELIMITED DATA` options, to be interpreted literally.
-`strict_validation`    | `AVRO DATA`    | Rejects Avro records that do not have a one-to-one mapping between Avro fields to the target CockroachDB schema. By default, CockroachDB ignores unknown Avro fields and sets missing SQL fields to `NULL`. CockroachDB will also attempt to convert the Avro field to the CockroachDB [data type][datatypes]; otherwise, it will report an error.
-`records_terminated_by` | `AVRO DATA`   | The unicode character to indicate new lines in the input binary or JSON file. This is not needed for Avro OCF. <br><br>**Default:** `\n`
-`data_as_binary_records` | `AVRO DATA`  | Use when [importing a binary file containing Avro records](migrate-from-avro.html#import-binary-or-json-records).  The schema is not included in the file, so you need to specify the schema with either the `schema` or `schema_uri` option.
-`data_as_json_records` | `AVRO DATA`    | Use when [importing a JSON file containing Avro records](migrate-from-avro.html#import-binary-or-json-records). The schema is not included in the file, so you need to specify the schema with either the `schema` or `schema_uri` option.
-`schema`               | `AVRO DATA`    | The schema of the Avro records included in the binary or JSON file. This is not needed for Avro OCF.
-`schema_uri`           | `AVRO DATA`    | The URI of the file containing the schema of the Avro records include in the binary or JSON file. This is not needed for Avro OCF.
-
-For examples showing how to use these options, see the [Examples](#examples) section below.
-
-For instructions and working examples showing how to migrate data from other databases and formats, see the [Migration Overview](migration-overview.html).
-
-## Requirements
-
-### Prerequisites
-
-Before using `IMPORT`, you should have:
-
-- The schema of the table you want to import.
-- The data you want to import, preferably hosted on cloud storage. This location must be equally accessible to all nodes using the same import file location.  This is necessary because the `IMPORT` statement is issued once by the client, but is executed concurrently across all nodes of the cluster.  For more information, see the [Import file location](#import-file-location) section below.
-
-For more information on details to consider when running an IMPORT, see [Considerations](#considerations).
-
-### Import targets
-
-Imported tables must not exist and must be created in the `IMPORT` statement. If the table you want to import already exists, you must drop it with [`DROP TABLE`](drop-table.html) or use [`IMPORT INTO`](import-into.html).
-
-You can specify the target database in the table name in the `IMPORT` statement. If it's not specified there, the active database in the SQL session is used.
-
-### Create table
-
-Your `IMPORT` statement must reference a `CREATE TABLE` statement representing the schema of the data you want to import.  You have several options:
-
-- Specify the table's columns explicitly from the [SQL client](cockroach-sql.html). For an example, see [Import a table from a CSV file](#import-a-table-from-a-csv-file) below.
-
-- Load a file that already contains a `CREATE TABLE` statement. For an example, see [Import a Postgres database dump](#import-a-postgres-database-dump) below.
-
-We also recommend [specifying all secondary indexes you want to use in the `CREATE TABLE` statement](create-table.html#create-a-table-with-secondary-and-gin-indexes). It is possible to [add secondary indexes later](create-index.html), but it is significantly faster to specify them during import.
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> `IMPORT` supports [computed columns](computed-columns.html) for Avro and Postgres dump files only. To import CSV data to a table with a computed column or `DEFAULT` expression, use [`IMPORT INTO`](import-into.html).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-By default, the [Postgres][postgres] and [MySQL][mysql] import formats support foreign keys. However, the most common dependency issues during import are caused by unsatisfied foreign key relationships that cause errors like `pq: there is no unique constraint matching given keys for referenced table tablename`. You can avoid these issues by adding the [`skip_foreign_keys`](#import-options) option to your `IMPORT` statement as needed. Ignoring foreign constraints will also speed up data import.
-{{site.data.alerts.end}}
-
-### Available storage
-
-Each node in the cluster is assigned an equal part of the imported data, and so must have enough temp space to store it. In addition, data is persisted as a normal table, and so there must also be enough space to hold the final, replicated data. The node's first-listed/default [`store`](cockroach-start.html#store) directory must have enough available storage to hold its portion of the data.
-
-On [`cockroach start`](cockroach-start.html), if you set `--max-disk-temp-storage`, it must also be greater than the portion of the data a node will store in temp space.
-
-### Import file location
-
-CockroachDB uses the URL provided to construct a secure API call to the service you specify. The URL structure depends on the type of file storage you are using. For more information, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- <span class="version-tag">New in v20.2:</span> [Use `userfile` for Bulk Operations](use-userfile-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-### Table users and privileges
-
-Imported tables are treated as new tables, so you must [`GRANT`](grant.html) privileges to them.
-
-## Performance
-
-- All nodes are used during the import job, which means all nodes' CPU and RAM will be partially consumed by the `IMPORT` task in addition to serving normal traffic.
-- To improve performance, import at least as many files as you have nodes (i.e., there is at least one file for each node to import) to increase parallelism.
-- To further improve performance, order the data in the imported files by [primary key](primary-key.html) and ensure the primary keys do not overlap between files.
-
-## Viewing and controlling import jobs
-
-After CockroachDB initiates an import, you can view its progress with [`SHOW JOBS`](show-jobs.html) and on the [**Jobs** page](ui-jobs-page.html) of the DB Console, and you can control it with [`PAUSE JOB`](pause-job.html), [`RESUME JOB`](resume-job.html), and [`CANCEL JOB`](cancel-job.html).
-
-{{site.data.alerts.callout_info}}
-If initiated correctly, the statement returns when the import is finished or if it encounters an error. In some cases, the import can continue after an error has been returned (the error message will tell you that the import has resumed in the background).
-
- When [resumed](resume-job.html), [paused](pause-job.html) imports now continue from their internally recorded progress instead of starting over.
-{{site.data.alerts.end}}
-
-## Examples
-
-The following provide connection examples to cloud storage providers. For more information on connecting to different storage options, read [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html).
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="s3">Amazon S3</button>
-  <button class="filter-button" data-scope="azure">Azure Storage</button>
-  <button class="filter-button" data-scope="gcs">Google Cloud Storage</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="s3">
-
-{% include {{ page.version.version }}/backups/aws-auth-note.md %}
-
-### Import a table from a CSV file
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('s3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-;
-~~~
-
-To use a file to specify the table schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers
-CREATE USING 's3://{BUCKET NAME}/{customers-create-table.sql}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-CSV DATA ('s3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-;
-~~~
-
-{% include {{ page.version.version }}/misc/csv-import-callout.md %}
-
-### Import a table from multiple CSV files
-
-#### Using a comma-separated list
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA (
-    's3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}',
-    's3://{BUCKET NAME}/{customers2.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}',
-    's3://{BUCKET NAME}/{customers3.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}',
-    's3://{BUCKET NAME}/{customers4.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}',
-);
-~~~
-
-#### Using a wildcard
-
-You can specify [file patterns to match](https://golang.org/pkg/path/filepath/#Match) instead of explicitly listing every file. Paths are matched Use the `*` wildcard character to include matching files directly under the specified path. A wildcard can be used to include:
-
-- All files in a given directory (e.g.,`s3://bucket-name/path/to/data/*`)
-- All files in a given directory that end with a given string (e.g., `s3://bucket-name/files/*.csv`)
-- All files in a given directory that start with a given string (e.g., `s3://bucket-name/files/data*`)
-- All files in a given directory that start and end with a given string (e.g., `s3://bucket-name/files/data*.csv`)
-
-These only match files directly under the specified path and do not descend into additional directories recursively.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA (
-    's3://{BUCKET NAME}/*?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-);
-~~~
-
-### Import a table from a TSV file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('s3://{BUCKET NAME}/{customers.tsv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-WITH
-	delimiter = e'\t'
-;
-~~~
-
-### Skip commented lines
-
-The `comment` option determines which Unicode character marks the rows in the data to be skipped.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('s3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-WITH
-	comment = '#'
-;
-~~~
-
-### Skip first *n* lines
-
-The `skip` option determines the number of header rows to skip when importing a file.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('s3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-WITH
-	skip = '2'
-;
-~~~
-
-### Use blank characters as `NULL`
-
-The `nullif` option defines which string should be converted to `NULL`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('s3://{BUCKET NAME}/{customers.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-WITH
-	nullif = ''
-;
-~~~
-
-### Import a compressed CSV file
-
-CockroachDB chooses the decompression codec based on the filename (the common extensions `.gz` or `.bz2` and `.bz`) and uses the codec to decompress the file during import.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('s3://{BUCKET NAME}/{customers.csv.gz}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-;
-~~~
-
-Optionally, you can use the `decompress` option to specify the codec to be used for decompressing the file during import:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('s3://{BUCKET NAME}/{customers.csv.gz}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-WITH
-	decompress = 'gzip'
-;
-~~~
-
-### Import a Postgres database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT PGDUMP 's3://{BUCKET NAME}/{employees.sql}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}';
-~~~
-
-For the commands above to succeed, you need to have created the dump file with specific flags to `pg_dump`. For more information, see [Migrate from Postgres](migrate-from-postgres.html).
-
-### Import a table from a Postgres database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees FROM PGDUMP 's3://{BUCKET NAME}/{employees.sql}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}' WITH skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed. For more information, see the list of [import options](#import-options).
-
-For the command above to succeed, you need to have created the dump file with specific flags to `pg_dump`.  For more information, see [Migrate from Postgres](migrate-from-postgres.html).
-
-### Import a CockroachDB dump file
-
-Cockroach dump files can be imported using the `IMPORT PGDUMP` statement.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT PGDUMP 's3://{BUCKET NAME}/{employees.sql}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}';
-~~~
-
-`cockroach dump` is no longer recommended and has been deprecated in v20.2. For more information, see [SQL Dump (Export)](cockroach-dump.html).
-
-### Import a MySQL database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT MYSQLDUMP 's3://{BUCKET NAME}/{employees.sql}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}';
-~~~
-
-For more detailed information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Import a table from a MySQL database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees FROM MYSQLDUMP 's3://{BUCKET NAME}/{employees.sql}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}' WITH skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed.  For more information, see the list of [import options](#import-options).
-
-For more detailed information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Import a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT DELIMITED DATA 's3://{BUCKET NAME}/{employees.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-  WITH
-    fields_terminated_by='|',
-    fields_enclosed_by='"',
-    fields_escaped_by='"';
-~~~
-
-{{site.data.alerts.callout_info}}
-If you want to escape special symbols, use `fields_escaped_by`.
-{{site.data.alerts.end}}
-
-### Import a table from a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees
-    FROM DELIMITED DATA 's3://{BUCKET NAME}/{employees.csv}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-    WITH
-      skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed. For more information, see the list of [import options](#import-options).
-
-### Import a table from a local file
-
-You can import a file to `nodelocal`, which is the external IO directory on a node's local file system. To import to `nodelocal`,  a `nodeID` is required and the data files will be in the `extern` directory of the specified node.
-
-{{site.data.alerts.callout_info}}
-The file system backup location on the NFS drive is relative to the path specified by the `--external-io-dir` flag set while [starting the node](cockroach-start.html). If the flag is set to `disabled`, then imports from local directories and NFS drives are disabled. Use `self` if you do not want to specify a `nodeID`, and the individual data files will be in the `extern` directories of arbitrary nodes; however, to work correctly, each node must have the [`--external-io-dir` flag](cockroach-start.html#general) point to the same NFS mount or other network-backed, shared storage.
-{{site.data.alerts.end}}
-
-If a `nodeID` is provided, the data files to import will be in the `extern` directory of the specified node:
-
-~~~ shell
-cd /tmp/node2 && ls
-~~~
-
-~~~
-000355.log		      	cockroach-temp700212211
-000357.log		      	cockroach.advertise-addr
-000359.sst		      	cockroach.advertise-sql-addr
-COCKROACHDB_VERSION		cockroach.http-addr
-CURRENT			        	cockroach.listen-addr
-IDENTITY		        	cockroach.sql-addr
-LOCK		          		extern
-MANIFEST-000010		    logs
-OPTIONS-000005		  	temp-dirs-record.txt
-auxiliary
-~~~
-
-~~~ shell
-cd /tmp/node2/extern && ls
-~~~
-
-~~~
-customers.csv
-~~~
-
-Then, specify which node to access by including the `nodeID` in the `IMPORT` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name STRING,
-		INDEX name_idx (name)
-)
-CSV DATA ('nodelocal://2/customers.csv')
-;
-~~~
-
- You can also use the [`cockroach nodelocal upload`](cockroach-nodelocal-upload.html) command to upload a file to the external IO directory on a node's (the gateway node, by default) local file system.
-
-### Import a table from an Avro file
-
- [Avro OCF data](migrate-from-avro.html#import-an-object-container-file), [JSON records, or binary records](migrate-from-avro.html#import-binary-or-json-records) can be imported. The following are examples of importing Avro OCF data.
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-AVRO DATA ('s3://{BUCKET NAME}/{customers.avro}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-;
-~~~
-
-To use a file to specify the table schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers
-CREATE USING 's3://{BUCKET NAME}/{customers-create-table.sql}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}'
-AVRO DATA ('s3://{BUCKET NAME}/{customers.avro}?AWS_ACCESS_KEY_ID={ACCESS KEY}&AWS_SECRET_ACCESS_KEY={SECRET ACCESS KEY}')
-;
-~~~
-
-For more information about importing data from Avro, including examples, see [Migrate from Avro](migrate-from-avro.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="azure">
-
-### Import a table from a CSV file
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('azure://{CONTAINER NAME}/{customer-import-data.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-;
-~~~
-
-To use a file to specify the table schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers
-CREATE USING 'azure://{CONTAINER NAME}/{customer-create-table.sql}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-CSV DATA ('azure://{CONTAINER NAME}/{customer-import-data.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-;
-~~~
-
-{% include {{ page.version.version }}/misc/csv-import-callout.md %}
-
-### Import a table from multiple CSV files
-
-#### Using a comma-separated list
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA (
-    'azure://{CONTAINER NAME}/{customer-import-data.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',
-    'azure://{CONTAINER NAME}/{customer-import-data2.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',
-    'azure://{CONTAINER NAME}/{customer-import-data3.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',
-    'azure://{CONTAINER NAME}/{customer-import-data4.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',
-    'azure://{CONTAINER NAME}/{customer-import-data5.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}',    
-);
-~~~
-
-#### Using a wildcard
-
-You can specify [file patterns to match](https://golang.org/pkg/path/filepath/#Match) instead of explicitly listing every file. Paths are matched Use the `*` wildcard character to include matching files directly under the specified path. A wildcard can be used to include:
-
-- All files in a given directory (e.g.,`azure://container-name/path/to/data/*`)
-- All files in a given directory that end with a given string (e.g., `azure://container-name/files/*.csv`)
-- All files in a given directory that start with a given string (e.g., `azure://container-name/files/data*`)
-- All files in a given directory that start and end with a given string (e.g., `azure://container-name/files/data*.csv`)
-
-These only match files directly under the specified path and do not descend into additional directories recursively.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA (
-    'azure://{CONTAINER NAME}/{customer-import-data*}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'  
-);
-~~~
-
-### Import a table from a TSV file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('azure://{CONTAINER NAME}/{customer-import-data.tsv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-WITH
-	delimiter = e'\t'
-;
-~~~
-
-### Skip commented lines
-
-The `comment` option determines which Unicode character marks the rows in the data to be skipped.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('azure://{CONTAINER NAME}/{customer-import-data.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-WITH
-	comment = '#'
-;
-~~~
-
-### Skip first *n* lines
-
-The `skip` option determines the number of header rows to skip when importing a file.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('azure://{CONTAINER NAME}/{customer-import-data.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-WITH
-	skip = '2'
-;
-~~~
-
-### Use blank characters as `NULL`
-
-The `nullif` option defines which string should be converted to `NULL`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('azure://{CONTAINER NAME}/{customer-import-data.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-WITH
-	nullif = ''
-;
-~~~
-
-### Import a compressed CSV file
-
-CockroachDB chooses the decompression codec based on the filename (the common extensions `.gz` or `.bz2` and `.bz`) and uses the codec to decompress the file during import.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('azure://{CONTAINER NAME}/{customer-import-data.csv.gz}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-;
-~~~
-
-Optionally, you can use the `decompress` option to specify the codec to be used for decompressing the file during import:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('azure://{CONTAINER NAME}/{customer-import-data.csv.gz}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-WITH
-	decompress = 'gzip'
-;
-~~~
-
-### Import a Postgres database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT PGDUMP 'azure://{CONTAINER NAME}/{employees.sql}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}';
-~~~
-
-For the commands above to succeed, you need to have created the dump file with specific flags to `pg_dump`. For more information, see [Migrate from Postgres](migrate-from-postgres.html).
-
-### Import a table from a Postgres database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees FROM PGDUMP 'azure://{CONTAINER NAME}/{employees.sql}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}' WITH skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed. For more information, see the list of [import options](#import-options).
-
-For the command above to succeed, you need to have created the dump file with specific flags to `pg_dump`.  For more information, see [Migrate from Postgres](migrate-from-postgres.html).
-
-### Import a CockroachDB dump file
-
-Cockroach dump files can be imported using the `IMPORT PGDUMP` statement.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT PGDUMP 'azure://{CONTAINER NAME}/{employees.sql}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}';
-~~~
-
-`cockroach dump` is no longer recommended and has been deprecated in v20.2. For more information, see [SQL Dump (Export)](cockroach-dump.html).
-
-### Import a MySQL database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT MYSQLDUMP 'azure://{CONTAINER NAME}/{employees.sql}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}';
-~~~
-
-For more detailed information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Import a table from a MySQL database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees FROM MYSQLDUMP 'azure://{CONTAINER NAME}/{employees.sql}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}' WITH skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed.  For more information, see the list of [import options](#import-options).
-
-For more detailed information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Import a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT DELIMITED DATA 'azure://{CONTAINER NAME}/{employees.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-  WITH
-    fields_terminated_by='|',
-    fields_enclosed_by='"',
-    fields_escaped_by='"';
-~~~
-
-{{site.data.alerts.callout_info}}
-If you want to escape special symbols, use `fields_escaped_by`.
-{{site.data.alerts.end}}
-
-### Import a table from a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees
-    FROM DELIMITED DATA 'azure://{CONTAINER NAME}/{employees.csv}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-    WITH
-      skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed. For more information, see the list of [import options](#import-options).
-
-### Import a table from a local file
-
-You can import a file to `nodelocal`, which is the external IO directory on a node's local file system. To import to `nodelocal`,  a `nodeID` is required and the data files will be in the `extern` directory of the specified node.
-
-{{site.data.alerts.callout_info}}
-The file system backup location on the NFS drive is relative to the path specified by the `--external-io-dir` flag set while [starting the node](cockroach-start.html). If the flag is set to `disabled`, then imports from local directories and NFS drives are disabled. Use `self` if you do not want to specify a `nodeID`, and the individual data files will be in the `extern` directories of arbitrary nodes; however, to work correctly, each node must have the [`--external-io-dir` flag](cockroach-start.html#general) point to the same NFS mount or other network-backed, shared storage.
-{{site.data.alerts.end}}
-
-If a `nodeID` is provided, the data files to import will be in the `extern` directory of the specified node:
-
-~~~ shell
-cd /tmp/node2 && ls
-~~~
-
-~~~
-000355.log		      	cockroach-temp700212211
-000357.log		      	cockroach.advertise-addr
-000359.sst		      	cockroach.advertise-sql-addr
-COCKROACHDB_VERSION		cockroach.http-addr
-CURRENT			        	cockroach.listen-addr
-IDENTITY		        	cockroach.sql-addr
-LOCK		          		extern
-MANIFEST-000010		    logs
-OPTIONS-000005		  	temp-dirs-record.txt
-auxiliary
-~~~
-
-~~~ shell
-cd /tmp/node2/extern && ls
-~~~
-
-~~~
-customers.csv
-~~~
-
-Then, specify which node to access by including the `nodeID` in the `IMPORT` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name STRING,
-		INDEX name_idx (name)
-)
-CSV DATA ('nodelocal://2/customers.csv')
-;
-~~~
-
- You can also use the [`cockroach nodelocal upload`](cockroach-nodelocal-upload.html) command to upload a file to the external IO directory on a node's (the gateway node, by default) local file system.
-
-### Import a table from an Avro file
-
- [Avro OCF data](migrate-from-avro.html#import-an-object-container-file), [JSON records, or binary records](migrate-from-avro.html#import-binary-or-json-records) can be imported. The following are examples of importing Avro OCF data.
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-AVRO DATA ('azure://{CONTAINER NAME}/{customers.avro}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-;
-~~~
-
-To use a file to specify the table schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers
-CREATE USING 'azure://{CONTAINER NAME}/{customers-create-table.sql}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}'
-AVRO DATA ('azure://{CONTAINER NAME}/{customers.avro}?AZURE_ACCOUNT_NAME={ACCOUNT NAME}&AZURE_ACCOUNT_KEY={ENCODED KEY}')
-;
-~~~
-
-For more information about importing data from Avro, including examples, see [Migrate from Avro](migrate-from-avro.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="gcs">
-
-{% include {{ page.version.version }}/backups/gcs-auth-note.md %}
-
-### Import a table from a CSV file
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-;
-~~~
-
-To use a file to specify the table schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers
-CREATE USING 'gs://{BUCKET NAME}/{customers-create-table.sql}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-CSV DATA ('gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-;
-~~~
-
-{% include {{ page.version.version }}/misc/csv-import-callout.md %}
-
-### Import a table from multiple CSV files
-
-#### Using a comma-separated list
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA (
-    'gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}',
-    'gs://{BUCKET NAME}/{customers2.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}',
-    'gs://{BUCKET NAME}/{customers3.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}',
-    'gs://{BUCKET NAME}/{customers4.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}',
-);
-~~~
-
-#### Using a wildcard
-
-You can specify [file patterns to match](https://golang.org/pkg/path/filepath/#Match) instead of explicitly listing every file. Paths are matched Use the `*` wildcard character to include matching files directly under the specified path. A wildcard can be used to include:
-
-- All files in a given directory (e.g.,`gs://bucket-name/path/to/data/*`)
-- All files in a given directory that end with a given string (e.g., `gs://bucket-name/files/*.csv`)
-- All files in a given directory that start with a given string (e.g., `gs://bucket-name/files/data*`)
-- All files in a given directory that start and end with a given string (e.g., `gs://bucket-name/files/data*.csv`)
-
-These only match files directly under the specified path and do not descend into additional directories recursively.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA (
-    'gs://{BUCKET NAME}/*?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-);
-~~~
-
-### Import a table from a TSV file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('gs://{BUCKET NAME}/{customers.tsv}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-WITH
-	delimiter = e'\t'
-;
-~~~
-
-### Skip commented lines
-
-The `comment` option determines which Unicode character marks the rows in the data to be skipped.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-WITH
-	comment = '#'
-;
-~~~
-
-### Skip first *n* lines
-
-The `skip` option determines the number of header rows to skip when importing a file.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-WITH
-	skip = '2'
-;
-~~~
-
-### Use blank characters as `NULL`
-
-The `nullif` option defines which string should be converted to `NULL`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('gs://{BUCKET NAME}/{customers.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-WITH
-	nullif = ''
-;
-~~~
-
-### Import a compressed CSV file
-
-CockroachDB chooses the decompression codec based on the filename (the common extensions `.gz` or `.bz2` and `.bz`) and uses the codec to decompress the file during import.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('gs://{BUCKET NAME}/{customers.csv.gz}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-;
-~~~
-
-Optionally, you can use the `decompress` option to specify the codec to be used for decompressing the file during import:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-CSV DATA ('gs://{BUCKET NAME}/{customers.csv.gz}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-WITH
-	decompress = 'gzip'
-;
-~~~
-
-### Import a Postgres database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT PGDUMP 'gs://{BUCKET NAME}/{employees.sql}?AUTH=specified&CREDENTIALS={ENCODED KEY}';
-~~~
-
-For the commands above to succeed, you need to have created the dump file with specific flags to `pg_dump`. For more information, see [Migrate from Postgres](migrate-from-postgres.html).
-
-### Import a table from a Postgres database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees FROM PGDUMP 'gs://{BUCKET NAME}/{employees.sql}?AUTH=specified&CREDENTIALS={ENCODED KEY}' WITH skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed. For more information, see the list of [import options](#import-options).
-
-For the command above to succeed, you need to have created the dump file with specific flags to `pg_dump`.  For more information, see [Migrate from Postgres](migrate-from-postgres.html).
-
-### Import a CockroachDB dump file
-
-Cockroach dump files can be imported using the `IMPORT PGDUMP` statement.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT PGDUMP 'gs://{BUCKET NAME}/{employees.sql}?AUTH=specified&CREDENTIALS={ENCODED KEY}';
-~~~
-
-`cockroach dump` is no longer recommended and has been deprecated in v20.2. For more information, see [SQL Dump (Export)](cockroach-dump.html).
-
-### Import a MySQL database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT MYSQLDUMP 'gs://{BUCKET NAME}/{employees.sql}?AUTH=specified&CREDENTIALS={ENCODED KEY}';
-~~~
-
-For more detailed information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Import a table from a MySQL database dump
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees FROM MYSQLDUMP 'gs://{BUCKET NAME}/{employees.sql}?AUTH=specified&CREDENTIALS={ENCODED KEY}' WITH skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed.  For more information, see the list of [import options](#import-options).
-
-For more detailed information about importing data from MySQL, see [Migrate from MySQL](migrate-from-mysql.html).
-
-### Import a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT DELIMITED DATA 'gs://{BUCKET NAME}/{employees.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-  WITH
-    fields_terminated_by='|',
-    fields_enclosed_by='"',
-    fields_escaped_by='"';
-~~~
-
-{{site.data.alerts.callout_info}}
-If you want to escape special symbols, use `fields_escaped_by`.
-{{site.data.alerts.end}}
-
-### Import a table from a delimited data file
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees
-    FROM DELIMITED DATA 'gs://{BUCKET NAME}/{employees.csv}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-    WITH
-      skip_foreign_keys;
-~~~
-
-If the table schema specifies foreign keys into tables that do not exist yet, the `WITH skip_foreign_keys` shown may be needed. For more information, see the list of [import options](#import-options).
-
-### Import a table from a local file
-
-You can import a file from `nodelocal`, which is the external IO directory on a node's local file system. To import from `nodelocal`,  a `nodeID` is required and the data files will be in the `extern` directory of the specified node.
-
-{{site.data.alerts.callout_info}}
-The file system backup location on the NFS drive is relative to the path specified by the `--external-io-dir` flag set while [starting the node](cockroach-start.html). If the flag is set to `disabled`, then imports from local directories and NFS drives are disabled. Use `self` if you do not want to specify a `nodeID`, and the individual data files will be in the `extern` directories of arbitrary nodes; however, to work correctly, each node must have the [`--external-io-dir` flag](cockroach-start.html#general) point to the same NFS mount or other network-backed, shared storage.
-{{site.data.alerts.end}}
-
-If a `nodeID` is provided, the data files to import will be in the `extern` directory of the specified node:
-
-~~~ shell
-cd /tmp/node2 && ls
-~~~
-
-~~~
-000355.log		      	cockroach-temp700212211
-000357.log		      	cockroach.advertise-addr
-000359.sst		      	cockroach.advertise-sql-addr
-COCKROACHDB_VERSION		cockroach.http-addr
-CURRENT			        	cockroach.listen-addr
-IDENTITY		        	cockroach.sql-addr
-LOCK		          		extern
-MANIFEST-000010		    logs
-OPTIONS-000005		  	temp-dirs-record.txt
-auxiliary
-~~~
-
-~~~ shell
-cd /tmp/node2/extern && ls
-~~~
-
-~~~
-customers.csv
-~~~
-
-Then, specify which node to access by including the `nodeID` in the `IMPORT` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name STRING,
-		INDEX name_idx (name)
-)
-CSV DATA ('nodelocal://2/customers.csv')
-;
-~~~
-
- You can also use the [`cockroach nodelocal upload`](cockroach-nodelocal-upload.html) command to upload a file to the external IO directory on a node's (the gateway node, by default) local file system.
-
-### Import a table from an Avro file
-
- [Avro OCF data](migrate-from-avro.html#import-an-object-container-file), [JSON records, or binary records](migrate-from-avro.html#import-binary-or-json-records) can be imported. The following are examples of importing Avro OCF data.
-
-To specify the table schema in-line:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id UUID PRIMARY KEY,
-		name TEXT,
-		INDEX name_idx (name)
-)
-AVRO DATA ('gs://{BUCKET NAME}/{customers.avro}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-;
-~~~
-
-To use a file to specify the table schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers
-CREATE USING 'gs://{BUCKET NAME}/{customers-create-table.sql}?AUTH=specified&CREDENTIALS={ENCODED KEY}'
-AVRO DATA ('gs://{BUCKET NAME}/{customers.avro}?AUTH=specified&CREDENTIALS={ENCODED KEY}')
-;
-~~~
-
-For more information about importing data from Avro, including examples, see [Migrate from Avro](migrate-from-avro.html).
-
-</section>
-
-## Known limitation
-
-{% include {{ page.version.version }}/known-limitations/import-high-disk-contention.md %}
-
-## See also
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Migration Overview](migration-overview.html)
-- [Migrate from MySQL][mysql]
-- [Migrate from Postgres][postgres]
-- [Migrate from CSV][csv]
-- [Migrate from Avro][avro]
-- [`IMPORT INTO`](import-into.html)
-
-<!-- Reference Links -->
-
-[avro]: migrate-from-avro.html
-[postgres]: migrate-from-postgres.html
-[mysql]: migrate-from-mysql.html
-[csv]: migrate-from-csv.html
-[datatypes]: migrate-from-avro.html#data-type-mapping
diff --git a/src/current/v20.2/index.md b/src/current/v20.2/index.md
deleted file mode 100644
index 9e0a791be78..00000000000
--- a/src/current/v20.2/index.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: CockroachDB Docs
-summary: CockroachDB is the SQL database for building global, scalable cloud services that survive disasters.
-toc: false
-homepage: true
-contribute: false
-cta: false
----
-
-<div class="home-header mb-xl-5 bg-cover bg-cover__bg-3-1">
-  <div class="p-2 p-md-5">
-  <h1 class="m-0 text-white">CockroachDB Docs</h1>
-  <p class="mt-0 pb-4 text-white">CockroachDB is the SQL database for building global, scalable cloud services that survive disasters.</p>
-    <div class="row d-lg-flex mx-0 pt-lg-5">
-      <div class="col-lg-4 mb-3 mb-lg-0 pb-5">
-        <div class="card card-link h-100 d-flex">
-        <a href="secure-a-cluster.html" class="h-100">
-          <div class="card-body p-4 d-flex flex-column h-100 card-header-overlap-text">            
-            <h6 class="mt-2 mt-0 text-black">Start a local <br>cluster</h6>
-            <p class="text-black">Run a multi-node CockroachDB cluster locally</p>
-            <h4 class="mt-auto mb-0 text-electric-purple font-poppins-sb text-center">Learn more <img class="m-0 ml-2" src="{{ 'images/icon-arrow-right-purple.svg' | relative_url }}" alt="arrow right" /></h4>
-          </div>
-          </a>
-        </div>
-      </div>
-      <div class="col-lg-4 mb-3 mb-lg-0 pb-5">
-        <div class="card card-link h-100 d-flex">
-        <a href="example-apps.html" class="h-100">
-          <div class="card-body p-4 d-flex flex-column h-100 card-header-overlap-text">
-            <h6 class="mt-2 mt-0 text-black">Sample <br>apps</h6>
-            <p class="text-black">Examples that show you how to build a simple "Hello World" application with CockroachDB</p>
-            <h4 class="mt-auto mb-0 text-electric-purple font-poppins-sb text-center">Learn more <img class="m-0 ml-2" src="{{ 'images/icon-arrow-right-purple.svg' | relative_url }}" alt="arrow right" /></h4>
-          </div>
-          </a>
-        </div>
-        </div>
-      <div class="col-lg-4 mb-3 mb-lg-0 pb-5">
-        <div class="card card-link h-100 d-flex">
-        <a href="frequently-asked-questions.html" class="h-100">
-          <div class="card-body p-4 d-flex flex-column h-100 card-header-overlap-text">          
-            <h6 class="m-0 text-black">CockroachDB <br>FAQ</h6>
-            <p class="text-black">Answers to frequently asked questions</p>
-            <h4 class="mt-auto mb-0 text-electric-purple font-poppins-sb text-center">Learn more <img class="m-0 ml-2" src="{{ 'images/icon-arrow-right-purple.svg' | relative_url }}" alt="arrow right" /></h4>
-          </div>
-          </a>
-        </div>
-      </div>
-    </div>
-  </div>
-</div>
-
-<div class="container">
-
-  <div class="row pt-5 mt-5 pb-5 mb-5">
-    <div class="col-lg-12 text-center">
-      <a class="btn btn-redirect mt-3" href="install-cockroachdb.html">Get CockroachDB <img class="m-0" src="{{ 'images/arrow-left.svg' | relative_url }}" alt="arrow left" /></a>
-    </div>
-  </div>
-
-  <div class="row">
-    <div class="col-12">
-      <p class="overline">CockroachDB</p>
-      <h2 class="mt-2">Recommended articles</h2>
-    </div>
-  </div>
-
-  <div class="row display-flex">
-    <div class="col-xs-12 col-sm-6 col-lg-3">
-      <p class="landing-column-title">Get Started</p>
-      <ul>
-        <li><a href="install-cockroachdb.html">Install CockroachDB</a></li>
-        <li><a href="secure-a-cluster.html">Start a Local Cluster</a></li>
-        <li><a href="learn-cockroachdb-sql.html">Learn CockroachDB SQL</a></li>
-        <li><a href="example-apps.html">Hello, World!</a></li>
-        <li><a href="demo-fault-tolerance-and-recovery.html">Explore Capabilities</a></li>
-      </ul>
-    </div>
-    <div class="col-xs-12 col-sm-6 col-lg-3">
-      <p class="landing-column-title">Develop</p>
-      <ul>
-        <li><a href="developer-guide-overview.html">Common Dev Tasks</a></li>
-        <li><a href="example-apps.html">Sample Apps</a></li>
-        <li><a href="sql-feature-support.html">SQL Reference</a></li>
-        <li><a href="performance-best-practices-overview.html">SQL Best Practices</a></li>
-        <li><a href="error-handling-and-troubleshooting.html">SQL Troubleshooting</a></li>
-      </ul>
-    </div>
-    <div class="col-xs-12 col-sm-6 col-lg-3">
-      <p class="landing-column-title">Deploy</p>
-      <ul>
-        <li><a href="recommended-production-settings.html">Production Checklist</a></li>
-        <li><a href="../cockroachcloud/create-your-cluster.html">CockroachDB Cloud Deployment</a></li>
-        <li><a href="orchestration.html">Self-Managed Deployment</a></li>
-        <li><a href="performance.html">Performance Profiles</a></li>
-        <li><a href="upgrade-cockroach-version.html">Cluster Maintenance</a></li>
-      </ul>
-    </div>
-    <div class="col-xs-12 col-sm-6 col-lg-3">
-      <p class="landing-column-title">Migrate</p>
-      <ul>
-        <li><a href="migration-overview.html">Migration Overview</a></li>
-        <li><a href="migrate-from-oracle.html">Migrate from Oracle</a></li>
-        <li><a href="migrate-from-postgres.html">Migrate from Postgres</a></li>
-        <li><a href="migrate-from-mysql.html">Migrate from MySQL</a></li>
-        <li><a href="migrate-from-csv.html">Migrate from CSV</a></li>
-      </ul>
-    </div>
-    <div class="col-xs-12 col-sm-6 col-lg-3">
-      <p class="landing-column-title">Troubleshoot</p>
-      <ul>
-        <li><a href="troubleshooting-overview.html">Troubleshooting Overview</a></li>
-        <li><a href="common-errors.html">Common Errors</a></li>
-        <li><a href="cluster-setup-troubleshooting.html">Cluster Setup</a></li>
-        <li><a href="query-behavior-troubleshooting.html">Query Behavior</a></li>
-        <li><a href="support-resources.html">Support Resources</a></li>
-      </ul>
-    </div>
-    <div class="col-xs-12 col-sm-6 col-lg-3">
-      <p class="landing-column-title">Reference</p>
-      <ul>
-        <li><a href="architecture/overview.html">Architecture</a></li>
-        <li><a href="sql-feature-support.html">SQL</a></li>
-        <li><a href="cockroach-commands.html">CLI</a></li>
-        <li><a href="ui-overview.html">DB Console</a></li>
-        <li><a href="third-party-database-tools.html">Third-Party Tools</a></li>
-      </ul>
-    </div>
-    <div class="col-xs-12 col-sm-6 col-lg-3">
-      <p class="landing-column-title">FAQs</p>
-      <ul>
-        <li><a href="frequently-asked-questions.html">CockroachDB FAQs</a></li>
-        <li><a href="sql-faqs.html">SQL FAQs</a></li>
-        <li><a href="operational-faqs.html">Operational FAQs</a></li>
-        <li><a href="licensing-faqs.html">Licensing FAQs</a></li>
-        <li><a href="cockroachdb-in-comparison.html">DB Comparisons</a></li>
-      </ul>
-    </div>
-    <div class="col-xs-12 col-sm-6 col-lg-3">
-      <p class="landing-column-title">Releases</p>
-      <ul>
-        <li><a href="../releases/{{page.version.version}}.html">{{page.version.version}} Release</a></li>
-        <li><a href="../releases/index.html">All Releases</a></li>
-        <li><a href="../releases/release-support-policy.html">Release Support Policy</a></li>
-        <li><a href="known-limitations.html">Known Limitations</a></li>
-      </ul>
-    </div>
-  </div>
-
-</div>
diff --git a/src/current/v20.2/indexes.md b/src/current/v20.2/indexes.md
deleted file mode 100644
index b784bed4c01..00000000000
--- a/src/current/v20.2/indexes.md
+++ /dev/null
@@ -1,133 +0,0 @@
----
-title: Indexes
-summary: Indexes improve your database's performance by helping SQL locate data without having to look through every row of a table.
-toc: true
-toc_not_nested: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-Indexes improve your database's performance by helping SQL locate data without having to look through every row of a table.
-
-## How do indexes work?
-
-When you create an index, CockroachDB "indexes" the columns you specify, which creates a copy of the columns and then sorts their values (without sorting the values in the table itself).
-
-After a column is indexed, SQL can easily filter its values using the index instead of scanning each row one-by-one. On large tables, this greatly reduces the number of rows SQL has to use, executing queries exponentially faster.
-
-For example, if you index an `INT` column and then filter it <code>WHERE &lt;indexed column&gt; = 10</code>, SQL can use the index to find values starting at 10 but less than 11. In contrast, without an index, SQL would have to evaluate _every_ row in the table for values equaling 10.  This is also known as a "full table scan", and it can be very bad for query performance.
-
-<span class="version-tag">New in v20.2:</span> You can also create an index on a subset of rows. This type of index is called a partial index. For more information, see [Partial indexes](partial-indexes.html).
-
-<span class="version-tag">New in v20.2</span>: To index [spatial data](spatial-data.html), CockroachDB uses *spatial indexes*. For more information about spatial indexes, see [Spatial Indexes](spatial-indexes.html).
-
-### Creation
-
-Each table automatically has an index created called `primary`, which indexes either its [primary key](primary-key.html) or&mdash;if there is no primary key&mdash;a unique value for each row known as `rowid`. We recommend always defining a primary key because the index it creates provides much better performance than letting CockroachDB use `rowid`.
-
-The `primary` index helps filter a table's primary key but doesn't help SQL find values in any other columns. However, you can use secondary indexes to improve the performance of queries using columns not in a table's primary key. You can create them:
-
-<a name="unique-secondary-indexes"></a>
-
-- At the same time as the table with the `INDEX` clause of [`CREATE TABLE`](create-table.html#create-a-table-with-secondary-and-gin-indexes). In addition to explicitly defined indexes, CockroachDB automatically creates secondary indexes for columns with the [`UNIQUE` constraint](unique.html).
-- For existing tables with [`CREATE INDEX`](create-index.html).
-- By applying the `UNIQUE` constraint to columns with [`ALTER TABLE`](alter-table.html), which automatically creates an index of the constrained columns.
-
-To create the most useful secondary indexes, you should also check out our [best practices](#best-practices).
-
-### Selection
-
-Because each query can use only a single index, CockroachDB selects the index it calculates will scan the fewest rows (i.e., the fastest). For more detail, check out our blog post [Index Selection in CockroachDB](https://www.cockroachlabs.com/blog/index-selection-cockroachdb-2/), which will show you how to use the [`EXPLAIN`](explain.html) statement for your query to see which index is being used.
-
-To override CockroachDB's index selection, you can also force queries [to use a specific index](table-expressions.html#force-index-selection) (also known as "index hinting"). Index hinting is supported for [`SELECT`](select-clause.html#select-from-a-specific-index), [`DELETE`](delete.html#force-index-selection-for-deletes), and [`UPDATE`](update.html#force-index-selection-for-updates) statements.
-
-### Storage
-
-CockroachDB stores indexes directly in your key-value store. You can find more information in our blog post [Mapping Table Data to Key-Value Storage](https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-table-data-to-key-value-storage/).
-
-### Locking
-
-Tables are not locked during index creation thanks to CockroachDB's [schema change procedure](https://www.cockroachlabs.com/blog/how-online-schema-changes-are-possible-in-cockroachdb/).
-
-### Performance
-
-Indexes create a trade-off: they greatly improve the speed of queries, but may slightly slow down writes to an affected column (because new values have to be written for both the table _and_ the index).
-
-To maximize your indexes' performance, we recommend following the [secondary index best practices](schema-design-indexes.html#best-practices).
-
-{{site.data.alerts.callout_success}}
-For more information about how to tune CockroachDB's performance, see [SQL Performance Best Practices](performance-best-practices-overview.html) and the [Performance Tuning](performance-tuning.html) tutorial.
-{{site.data.alerts.end}}
-
-### Storing columns
-
-The `STORING` clause specifies columns which are not part of the index key but should be stored in the index. This optimizes queries which retrieve those columns without filtering on them, because it prevents the need to read the primary index.
-
-For example, say we have a table with three columns, two of which are indexed:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE tbl (col1 INT, col2 INT, col3 INT, INDEX (col1, col2));
-~~~
-
-If we filter on the indexed columns but retrieve the unindexed column, this requires reading `col3` from the primary index via an "index join."
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT col3 FROM tbl WHERE col1 = 10 AND col2 > 1;
-~~~
-
-~~~
-     tree    |     field     |      description
--------------+---------------+------------------------
-             | distribution  | local
-             | vectorized    | false
-  index join |               |
-   │         | table         | tbl@primary
-   └── scan  |               |
-             | missing stats |
-             | table         | tbl@tbl_col1_col2_idx
-             | spans         | [/10/2 - /10]
-(8 rows)
-~~~
-
-However, if we store `col3` in the index, the index join is no longer necessary. This means our query only needs to read from the secondary index, so it will be more efficient.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE tbl (col1 INT, col2 INT, col3 INT, INDEX (col1, col2) STORING (col3));
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT col3 FROM tbl WHERE col1 = 10 AND col2 > 1;
-~~~
-
-~~~
-  tree |     field     |      description
--------+---------------+------------------------
-       | distribution  | local
-       | vectorized    | false
-  scan |               |
-       | missing stats |
-       | table         | tbl@tbl_col1_col2_idx
-       | spans         | [/10/2 - /10]
-(6 rows)
-~~~
-
-## Best practices
-
-For best practices, see [Add a Secondary Index: Best Practices](schema-design-indexes.html#best-practices)
-
-## See also
-
-- [`CREATE INDEX`](create-index.html)
-- [Schema Design: Add Secondary Indexes](schema-design-indexes.html)
-- [GIN Indexes](inverted-indexes.html)
-- [Partial indexes](partial-indexes.html)
-- [Spatial Indexes](spatial-indexes.html)
-- [Hash-sharded Indexes](hash-sharded-indexes.html)
-- [Select from a specific index](select-clause.html#select-from-a-specific-index)
-- [`DROP INDEX`](drop-index.html)
-- [`RENAME INDEX`](rename-index.html)
-- [`SHOW INDEX`](show-index.html)
-- [SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/inet.md b/src/current/v20.2/inet.md
deleted file mode 100644
index b0935cff413..00000000000
--- a/src/current/v20.2/inet.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: INET
-summary: The INET data type stores an IPv4 or IPv6 address.
-toc: true
----
-The `INET` [data type](data-types.html) stores an IPv4 or IPv6 address.
-
-## Syntax
-
-A constant value of type `INET` can be expressed using an
-[interpreted literal](sql-constants.html#interpreted-literals), or a
-string literal
-[annotated with](scalar-expressions.html#explicitly-typed-expressions)
-type `INET` or
-[coerced to](scalar-expressions.html#explicit-type-coercions) type
-`INET`.
-
-`INET` constants can be expressed using the following formats:
-
-Format | Description
--------|-------------
-IPv4 | Standard [RFC791](https://tools.ietf.org/html/rfc791)-specified format of 4 octets expressed individually in decimal numbers and separated by periods. Optionally, the address can be followed by a subnet mask.<br><br>Examples: `'190.0.0.0'`, `'190.0.0.0/24'`
-IPv6 | Standard [RFC8200](https://tools.ietf.org/html/rfc8200)-specified format of 8 colon-separated groups of 4 hexadecimal digits. An IPv6 address can be mapped to an IPv4 address. Optionally, the address can be followed by a subnet mask.<br><br>Examples: `'2001:4f8:3:ba:2e0:81ff:fe22:d1f1'`, `'2001:4f8:3:ba:2e0:81ff:fe22:d1f1/120'`, `'::ffff:192.168.0.1/24'`
-
-{{site.data.alerts.callout_info}}IPv4 addresses will sort before IPv6 addresses, including IPv4-mapped IPv6 addresses.{{site.data.alerts.end}}
-
-## Size
-
-An `INET` value is 32 bits for IPv4 or 128 bits for IPv6.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE computers (
-    ip INET PRIMARY KEY,
-    user_email STRING,
-    registration_date DATE
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM computers;
-~~~
-
-~~~
-+-------------------+-----------+-------------+----------------+-----------------------+-------------+
-|    column_name    | data_type | is_nullable | column_default | generation_expression |   indices   |
-+-------------------+-----------+-------------+----------------+-----------------------+-------------+
-| ip                | INET      |    false    | NULL           |                       | {"primary"} |
-| user_email        | STRING    |    true     | NULL           |                       | {}          |
-| registration_date | DATE      |    true     | NULL           |                       | {}          |
-+-------------------+-----------+-------------+----------------+-----------------------+-------------+
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO computers
-  VALUES
-    ('192.168.0.1', 'info@cockroachlabs.com', '2018-01-31'),
-    ('192.168.0.2/10', 'lauren@cockroachlabs.com', '2018-01-31'),
-    ('2001:4f8:3:ba:2e0:81ff:fe22:d1f1/120', 'test@cockroachlabs.com', '2018-01-31');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM computers;
-~~~
-~~~
-+--------------------------------------+--------------------------+---------------------------+
-|                  ip                  |        user_email        |     registration_date     |
-+--------------------------------------+--------------------------+---------------------------+
-| 192.168.0.1                          | info@cockroachlabs.com   | 2018-01-31 00:00:00+00:00 |
-| 192.168.0.2/10                       | lauren@cockroachlabs.com | 2018-01-31 00:00:00+00:00 |
-| 2001:4f8:3:ba:2e0:81ff:fe22:d1f1/120 | test@cockroachlabs.com   | 2018-01-31 00:00:00+00:00 |
-+--------------------------------------+--------------------------+---------------------------+
-~~~
-
-## Supported casting and conversion
-
-`INET` values can be [cast](data-types.html#data-type-conversions-and-casts) to the following data type:
-
-- `STRING` - Converts to format `'Address/subnet'`.
-
-## See also
-
-- [Data Types](data-types.html)
-- [Functions and Operators](functions-and-operators.html)
diff --git a/src/current/v20.2/information-schema.md b/src/current/v20.2/information-schema.md
deleted file mode 100644
index d51bb7181f5..00000000000
--- a/src/current/v20.2/information-schema.md
+++ /dev/null
@@ -1,603 +0,0 @@
----
-title: information_schema
-summary: The information_schema schema contains read-only views that you can use for introspection into your database's tables, columns, indexes, and views.
-toc: true
----
-
-The `information_schema` [system catalog](system-catalogs.html) contains information about your database's tables, columns, indexes, and views. This information can be used for introspection and reflection.
-
-## Data exposed by `information_schema`
-
-To perform introspection on objects, you can either read from the related `information_schema` table or use one of CockroachDB's `SHOW` statements. `information_schema` tables are read-only.
-
-Object | `information_schema` Table | Corresponding `SHOW` Statement
--------|--------------|--------
-Columns | [`columns`](#columns) | [`SHOW COLUMNS`](show-columns.html)
-Constraints | [`check_constraints`](#check_constraints), [`key_column_usage`](#key_column_usage), [`referential_constraints`](#referential_constraints), [`table_constraints`](#table_constraints)| [`SHOW CONSTRAINTS`](show-constraints.html)
-Databases | [`schemata`](#schemata)| [`SHOW DATABASE`](show-vars.html)
-Indexes | [`statistics`](#statistics)| [`SHOW INDEX`](show-index.html)
-Privileges | [`schema_privileges`](#schema_privileges), [`table_privileges`](#table_privileges)| [`SHOW GRANTS`](show-grants.html)
-Roles | [`role_table_grants`](#role_table_grants) | [`SHOW ROLES`](show-roles.html)
-Sequences | [`sequences`](#sequences) | [`SHOW CREATE SEQUENCE`](show-create.html)
-Tables | [`tables`](#tables)| [`SHOW TABLES`](show-tables.html)
-Views | [`tables`](#tables), [`views`](#views)| [`SHOW CREATE`](show-create.html)
-
-## Tables in `information_schema`
-
-The virtual schema `information_schema` contains virtual tables, also called "system views," representing the database's objects, each of which is detailed below.
-
-These differ from regular [SQL views](views.html) in that they are
-not showing data created from the content of other tables. Instead,
-CockroachDB generates the data for virtual tables when they are accessed.
-
-Currently, there are some `information_schema` tables that are empty but provided for compatibility:
-
-- `routines`
-- `parameters`
-
-{{site.data.alerts.callout_info}}
-A query can specify a table name without a database name (e.g., `SELECT * FROM information_schema.sequences`). See [Name Resolution](sql-name-resolution.html) for more information.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-The virtual tables in `information_schema` contain useful comments with links to further documentation. To view these comments, use `SHOW TABLES FROM information_schema WITH COMMENT`:
-{{site.data.alerts.end}}
-
-### administrable_role_authorizations
-
-`administrable_role_authorizations` identifies all roles that the current user has the admin option for.
-
-Column | Description
--------|-----------
-`grantee` | The name of the user to which this role membership was granted (always the current user).
-
-### applicable_roles
-
-`applicable_roles` identifies all roles whose privileges the current user can use. This implies there is a chain of role grants from the current user to the role in question. The current user itself is also an applicable role, but is not listed.
-
-Column | Description
--------|-----------
-`grantee` | Name of the user to which this role membership was granted (always the current user).
-`role_name` | Name of a role.
-`is_grantable` | `YES` if the grantee has the admin option on the role; `NO` if not.
-
-### check_constraints
-
-`check_constraints` contains information about the [`CHECK`](check.html) constraints applied to columns in a database.
-
-Column | Description
--------|-----------
-`constraint_catalog` | Name of the database containing the constraint.
-`constraint_schema` | Name of the schema containing the constraint.
-`constraint_name` | Name of the constraint.
-`check_clause` | Definition of the `CHECK` constraint.
-
-### columns
-
-`columns` contains information about the columns in each table.
-
-Column | Description
--------|-----------
-`table_catalog` | Name of the database containing the table.
-`table_schema` | Name of the schema containing the table.
-`table_name` | Name of the table.
-`column_name` | Name of the column.
-`ordinal_position` | Ordinal position of the column in the table (begins at 1).
-`column_default` | Default value for the column.
-`is_nullable` | `YES` if the column accepts `NULL` values; `NO` if it doesn't (e.g., it has the [`NOT NULL` constraint](not-null.html)).
-`data_type` | [Data type](data-types.html) of the column.
-`character_maximum_length` |  If `data_type` is `STRING`, the maximum length in characters of a value; otherwise `NULL`.
-`character_octet_length` | If `data_type` is `STRING`, the maximum length in octets (bytes) of a value; otherwise `NULL`.
-`numeric_precision` | If `data_type` is numeric, the declared or implicit precision (i.e., number of significant digits); otherwise `NULL`.
-`numeric_precision_radix` | If `data_type` identifies a numeric type, the base in which the values in the columns `numeric_precision` and `numeric_scale` are expressed (either `2` or `10`). For all other data types, column is `NULL`.
-`numeric_scale` | If `data_type` is an exact numeric type, the scale (i.e., number of digits to the right of the decimal point); otherwise `NULL`.
-`datetime_precision` | <span class="version-tag">New in v20.2:</span> The precision level of columns with data type [`TIME`/`TIMETZ`](time.html), [`TIMESTAMP`/`TIMESTAMPTZ`](timestamp.html), or [`INTERVAL`](interval.html). For all other data types, this column is `NULL`.
-`interval_type` | If `data_type` is [`INTERVAL`](interval.html), the specified fields (e.g., `YEAR TO MONTH`); otherwise `NULL`.
-`interval_precision` | If `data_type` is [`INTERVAL`](interval.html), the declared or implicit precision (i.e., number of significant digits); otherwise `NULL`.
-`character_set_catalog` | Always `NULL` (unsupported by CockroachDB).
-`character_set_schema` | Always `NULL` (unsupported by CockroachDB).
-`character_set_name` | Always `NULL` (unsupported by CockroachDB).
-`collation_catalog` | Name of the database containing the collation (always the current database); `NULL` if the default collation is used, or if `data_type` is not collatable.
-`collation_schema` | Name of the schema containing the collation; `NULL` if the default collation is used, or if `data_type` is not collatable.
-`collation_name` | Name of the collation; `NULL` if the default collation is used, or if `data_type` is not collatable.
-`domain_catalog` | Always `NULL` (unsupported by CockroachDB).
-`domain_schema` | Always `NULL` (unsupported by CockroachDB).
-`domain_name` | Always `NULL` (unsupported by CockroachDB).
-`udt_catalog` | Name of the column data type's database (always the current database).
-`udt_schema` | Name of the column data type's schema.
-`udt_name` | Name of the column data type.
-`scope_catalog` | Always `NULL` (unsupported by CockroachDB).
-`scope_schema` | Always `NULL` (unsupported by CockroachDB).
-`scope_name` | Always `NULL` (unsupported by CockroachDB).
-`maximum_cardinality` | Always `NULL` (unsupported by CockroachDB).
-`dtd_identifier` | Always `NULL` (unsupported by CockroachDB).
-`is_self_referencing` | Always `NULL` (unsupported by CockroachDB).
-`is_identity` | Whether or not the column is an identity column (always `NO`).
-`identity_generation` | Always `NULL` (unsupported by CockroachDB).
-`identity_start` | If the column is an identity column, then the start value of the internal sequence, else `NULL`.
-`identity_increment` | If the column is an identity column, then the increment of the internal sequence, else `NULL`.
-`identity_maximum` | If the column is an identity column, then the maximum value of the internal sequence, else `NULL`.
-`identity_minimum` | If the column is an identity column, then the minimum value of the internal sequence, else `NULL`.
-`identity_cycle` | If the column is an identity column, then `YES` if the internal sequence cycles or `NO` if it does not; otherwise `NULL`.
-`is_generated` | Whether or not the column is generated (i.e., a [computed column](computed-columns.html)). Possible values: `YES` or `NO`.
-`generation_expression` | The expression used for computing the column value in a computed column.
-`is_updatable` | Whether or not the column is able to be updated. Possible values: `YES` or `NO`.
-`is_hidden` | Whether or not the column is hidden. Possible values: `YES` or `NO`.
-`crdb_sql_type` | [Data type](data-types.html) of the column.
-
-### column_privileges
-
-`column_privileges` identifies all privileges granted on columns to or by a currently enabled role. There is one row for each combination of `grantor`, `grantee`, and column (defined by `table_catalog`, `table_schema`, `table_name`, and `column_name`).
-
-Column | Description
--------|-----------
-`grantor` | Name of the role that granted the privilege.
-`grantee` | Name of the role that was granted the privilege.
-`table_catalog` | Name of the database containing the table that contains the column (always the current database).
-`table_schema` | Name of the schema containing the table that contains the column.
-`table_name` | Name of the table.
-`column_name` | Name of the column.
-`privilege_type` | Name of the [privilege](authorization.html#assign-privileges).
-`is_grantable` | Always `NULL` (unsupported by CockroachDB).
-
-### column_udt_usage
-
-<span class="version-tag">New in v20.2:</span> `column_udt_usage` identifies all columns that use data types owned by a currently-enabled role.
-
-Column | Description
--------|-----------
-`udt_catalog` | Name of the database in which the column data type is defined (always the current database).
-`udt_schema` | Name of the schema in which the column data type is defined.
-`udt_name` | Name of the column data type.
-`table_catalog` | Name of the database containing the table (always the current database).
-`table_schema` | Name of the schema containing the table.
-`table_name` | Name of the table.
-`column_name` | Name of the column.
-
-### constraint_column_usage
-
-`constraint_column_usage` identifies all columns in a database that are used by some [constraint](constraints.html).
-
-Column | Description
--------|-----------
-`table_catalog` | Name of the database that contains the table that contains the column that is used by some constraint.
-`table_schema` | Name of the schema that contains the table that contains the column that is used by some constraint.
-`table_name` | Name of the table that contains the column that is used by some constraint.
-`column_name` | Name of the column that is used by some constraint.
-`constraint_catalog` | Name of the database that contains the constraint.
-`constraint_schema` | Name of the schema that contains the constraint.
-`constraint_name` | Name of the constraint.
-
-### enabled_roles
-
-The `enabled_roles` view identifies enabled roles for the current user. This includes both direct and indirect roles.
-
-Column | Description
--------|-----------
-`role_name` | Name of a role.
-
-### key_column_usage
-
-`key_column_usage` identifies columns with [`PRIMARY KEY`](primary-key.html), [`UNIQUE`](unique.html), or [foreign key / `REFERENCES`](foreign-key.html) constraints.
-
-Column | Description
--------|-----------
-`constraint_catalog` | Name of the database containing the constraint.
-`constraint_schema` | Name of the schema containing the constraint.
-`constraint_name` | Name of the constraint.
-`table_catalog` | Name of the database containing the constrained table.
-`table_schema` | Name of the schema containing the constrained table.
-`table_name` | Name of the constrained table.
-`column_name` | Name of the constrained column.
-`ordinal_position` | Ordinal position of the column within the constraint (begins at 1).
-`position_in_unique_constraint` | For foreign key constraints, ordinal position of the referenced column within its uniqueness constraint (begins at 1).
-
-### parameters
-
-`parameters` is an empty view, provided for PostgreSQL compatibility.
-
-CockroachDB does not yet support stored procedures. For details, see the [GitHub tracking issue](https://github.com/cockroachdb/cockroach/issues/17511).
-
-Column | Description
--------|-----------
-`specific_catalog` | Always `NULL`.
-`specific_schema` | Always `NULL`.
-`specific_name` | Always `NULL`.
-`ordinal_position` | Always `NULL`.
-`parameter_mode` | Always `NULL`.
-`is_result` | Always `NULL`.
-`as_locator` | Always `NULL`.
-`parameter_name` | Always `NULL`.
-`data_type` | Always `NULL`.
-`character_maximum_length` |  Always `NULL`.
-`character_octet_length` | Always `NULL`.
-`character_set_catalog` | Always `NULL`.
-`character_set_schema` | Always `NULL`.
-`character_set_name` | Always `NULL`.
-`collation_catalog` | Always `NULL`.
-`collation_schema` | Always `NULL`.
-`collation_name` | Always `NULL`.
-`numeric_precision` | Always `NULL`.
-`numeric_precision_radix` | Always `NULL`.
-`numeric_scale` | Always `NULL`.
-`datetime_precision` | Always `NULL`.
-`interval_type` | Always `NULL`.
-`interval_precision` | Always `NULL`.
-`udt_catalog` | Always `NULL`.
-`udt_schema` | Always `NULL`.
-`udt_name` | Always `NULL`.
-`scope_catalog` | Always `NULL`.
-`scope_schema` | Always `NULL`.
-`scope_name` | Always `NULL`.
-`maximum_cardinality` | Always `NULL`.
-`dtd_identifier` | Always `NULL`.
-`parameter_default` | Always `NULL`.
-
-### referential_constraints
-
-`referential_constraints` identifies all referential ([Foreign Key](foreign-key.html)) constraints.
-
-Column | Description
--------|-----------
-`constraint_catalog` | Name of the database containing the constraint.
-`constraint_schema` | Name of the schema containing the constraint.
-`constraint_name` | Name of the constraint.
-`unique_constraint_catalog` | Name of the database containing the `UNIQUE` or `PRIMARY KEY` constraint that the foreign key constraint references (always the current database).
-`unique_constraint_schema` | Name of the schema containing the `UNIQUE` or `PRIMARY KEY` constraint that the foreign key constraint references.
-`unique_constraint_name` | Name of the `UNIQUE` or `PRIMARY KEY` constraint.
-`match_option` | Match option of the foreign key constraint: `FULL`, `PARTIAL`, or `NONE`.
-`update_rule` | Update rule of the foreign key constraint: `CASCADE`, `SET NULL`, `SET DEFAULT`, `RESTRICT`, or `NO ACTION`.
-`delete_rule` | Delete rule of the foreign key constraint: `CASCADE`, `SET NULL`, `SET DEFAULT`, `RESTRICT`, or `NO ACTION`.
-`table_name` | Name of the table containing the constraint.
-`referenced_table_name` | Name of the table containing the `UNIQUE` or `PRIMARY KEY` constraint that the foreign key constraint references.
-
-### role_table_grants
-
-`role_table_grants` identifies which [privileges](authorization.html#assign-privileges) have been granted on tables or views where the grantor
-or grantee is a currently enabled role. This table is identical to [`table_privileges`](#table_privileges).
-
-Column | Description
--------|-----------
-`grantor` | Name of the role that granted the privilege.
-`grantee` | Name of the role that was granted the privilege.
-`table_catalog` | Name of the database containing the table.
-`table_schema` | Name of the schema containing the table.
-`table_name` | Name of the table.
-`privilege_type` | Name of the [privilege](authorization.html#assign-privileges).
-`is_grantable` | Always `NULL` (unsupported by CockroachDB).
-`with_hierarchy` | Always `NULL` (unsupported by CockroachDB).
-
-### routines
-
-`routines` is an empty view, provided for PostgreSQL compatibility.
-
-CockroachDB does not yet support stored procedures. For details, see the [GitHub tracking issue](https://github.com/cockroachdb/cockroach/issues/17511).
-
-Column | Description
--------|-----------
-`specific_catalog` | Always `NULL`.
-`specific_schema` | Always `NULL`.
-`specific_name` | Always `NULL`.
-`routine_catalog` | Always `NULL`.
-`routine_schema` | Always `NULL`.
-`routine_name` | Always `NULL`.
-`routine_type` | Always `NULL`.
-`module_catalog` | Always `NULL`.
-`module_schema` | Always `NULL`.
-`module_name` | Always `NULL`.
-`udt_catalog` | Always `NULL`.
-`udt_schema` | Always `NULL`.
-`udt_name` | Always `NULL`.
-`data_type` | Always `NULL`.
-`character_maximum_length` | Always `NULL`.
-`character_octet_length` | Always `NULL`.
-`character_set_catalog` | Always `NULL`.
-`character_set_schema` | Always `NULL`.
-`character_set_name` | Always `NULL`.
-`collation_catalog` | Always `NULL`.
-`collation_schema` | Always `NULL`.
-`collation_name` | Always `NULL`.
-`numeric_precision` | Always `NULL`.
-`numeric_precision_radix` | Always `NULL`.
-`numeric_scale` | Always `NULL`.
-`datetime_precision` | Always `NULL`.
-`interval_type` | Always `NULL`.
-`interval_precision` | Always `NULL`.
-`type_udt_catalog` | Always `NULL`.
-`type_udt_schema` | Always `NULL`.
-`type_udt_name` | Always `NULL`.
-`scope_catalog` | Always `NULL`.
-`scope_name` | Always `NULL`.
-`maximum_cardinality` | Always `NULL`.
-`dtd_identifier` | Always `NULL`.
-`routine_body` | Always `NULL`.
-`routine_definition` | Always `NULL`.
-`external_name` | Always `NULL`.
-`external_language` | Always `NULL`.
-`parameter_style` | Always `NULL`.
-`is_deterministic` | Always `NULL`.
-`sql_data_access` | Always `NULL`.
-`is_null_call` | Always `NULL`.
-`sql_path` | Always `NULL`.
-`schema_level_routine` | Always `NULL`.
-`max_dynamic_result_sets` | Always `NULL`.
-`is_user_defined_cast` | Always `NULL`.
-`is_implicitly_invocable` | Always `NULL`.
-`security_type` | Always `NULL`.
-`to_sql_specific_catalog` | Always `NULL`.
-`to_sql_specific_schema` | Always `NULL`.
-`to_sql_specific_name` | Always `NULL`.
-`as_locator` | Always `NULL`.
-`created` | Always `NULL`.
-`last_altered` | Always `NULL`.
-`new_savepoint_level` | Always `NULL`.
-`is_udt_dependent` | Always `NULL`.
-`result_cast_from_data_type` | Always `NULL`.
-`result_cast_as_locator` | Always `NULL`.
-`result_cast_char_max_length` | Always `NULL`.
-`result_cast_char_octet_length` | Always `NULL`.
-`result_cast_char_set_catalog` | Always `NULL`.
-`result_cast_char_set_schema` | Always `NULL`.
-`result_cast_char_set_name` | Always `NULL`.
-`result_cast_collation_catalog` | Always `NULL`.
-`result_cast_collation_schema` | Always `NULL`.
-`result_cast_collation_name` | Always `NULL`.
-`result_cast_numeric_precision` | Always `NULL`.
-`result_cast_numeric_precision_radix` | Always `NULL`.
-`result_cast_numeric_scale` | Always `NULL`.
-`result_cast_datetime_precision` | Always `NULL`.
-`result_cast_interval_type` | Always `NULL`.
-`result_cast_interval_precision` | Always `NULL`.
-`result_cast_type_udt_catalog` | Always `NULL`.
-`result_cast_type_udt_schema` | Always `NULL`.
-`result_cast_type_udt_name` | Always `NULL`.
-`result_cast_scope_catalog` | Always `NULL`.
-`result_cast_scope_schema` | Always `NULL`.
-`result_cast_scope_name` | Always `NULL`.
-`result_cast_maximum_cardinality` | Always `NULL`.
-`result_cast_dtd_identifier` | Always `NULL`.
-
-### schema_privileges
-
-`schema_privileges` identifies which [privileges](authorization.html#assign-privileges) have been granted to each user at the database level.
-
-Column | Description
--------|-----------
-`grantee` | Username of user with grant.
-`table_catalog` | Name of the database containing the constrained table.
-`table_schema` | Name of the schema containing the constrained table.
-`privilege_type` | Name of the [privilege](authorization.html#assign-privileges).
-`is_grantable` | Always `NULL` (unsupported by CockroachDB).
-
-### schemata
-
-`schemata` identifies the database's schemas.
-
-Column | Description
--------|-----------
-`table_catalog` | Name of the database.
-`table_schema` | Name of the schema.
-`default_character_set_name` |  Always `NULL` (unsupported by CockroachDB).
-`sql_path` |  Always `NULL` (unsupported by CockroachDB).
-
-### sequences
-
-`sequences` identifies [sequences](create-sequence.html) defined in a database.
-
-Column | Description
--------|-----------
-`sequence_catalog` | Name of the database that contains the sequence.
-`sequence_schema` | Name of the schema that contains the sequence.
-`sequence_name` | Name of the sequence.
-`data_type` | The data type of the sequence.
-`numeric_precision` | The (declared or implicit) precision of the sequence `data_type`.
-`numeric_precision_radix` | The base of the values in which the columns `numeric_precision` and `numeric_scale` are expressed. The value is either `2` or `10`.
-`numeric_scale` | The (declared or implicit) scale of the sequence `data_type`. The scale indicates the number of significant digits to the right of the decimal point. It can be expressed in decimal (base 10) or binary (base 2) terms, as specified in the column `numeric_precision_radix`.
-`start_value` | The first value of the sequence.
-`minimum_value` | The minimum value of the sequence.
-`maximum_value` | The maximum value of the sequence.
-`increment` | The value by which the sequence is incremented. A negative number creates a descending sequence. A positive number creates an ascending sequence.
-`cycle_option` | Currently, all sequences are set to `NO CYCLE` and the sequence will not wrap.
-
-### statistics
-
-`statistics` identifies table [indexes](indexes.html).
-
-Column | Description
--------|-----------
-`table_catalog` | Name of the database that contains the constrained table.
-`table_schema` | Name of the schema that contains the constrained table.
-`table_name` | Name of the table.
-`non_unique` | `NO` if the index was created with the `UNIQUE` constraint; `YES` if the index was not created with `UNIQUE`.
-`index_schema` | Name of the database that contains the index.
-`index_name` | Name of the index.
-`seq_in_index` | Ordinal position of the column within the index (begins at 1).
-`column_name` | Name of the column being indexed.
-`collation` | Always `NULL` (unsupported by CockroachDB).
-`cardinality` | Always `NULL` (unsupported by CockroachDB).
-`direction` | `ASC` (ascending) or `DESC` (descending) order.
-`storing` | `YES` if column is [stored](create-index.html#store-columns); `NO` if it's indexed or implicit.
-`implicit` | `YES` if column is implicit (i.e., it is not specified in the index and not stored); `NO` if it's indexed or stored.
-
-### table_constraints
-
-`table_constraints` identifies [constraints](constraints.html) applied to tables.
-
-Column | Description
--------|-----------
-`constraint_catalog` | Name of the database containing the constraint.
-`constraint_schema` | Name of the schema containing the constraint.
-`constraint_name` | Name of the constraint.
-`table_catalog` | Name of the database containing the constrained table.
-`table_schema` | Name of the schema containing the constrained table.
-`table_name` | Name of the constrained table.
-`constraint_type` | Type of [constraint](constraints.html): `CHECK`, `FOREIGN KEY`, `PRIMARY KEY`, or `UNIQUE`.<br>`NOT NULL` constraints appear as `CHECK` constraints in this column.
-`is_deferrable` | `YES` if the constraint can be deferred; `NO` if not.
-`initially_deferred` | `YES` if the constraint is deferrable and initially deferred; `NO` if not.
-
-### table_privileges
-
-`table_privileges` identifies which [privileges](authorization.html#assign-privileges) have been granted to each user at the table level.
-
-Column | Description
--------|-----------
-`grantor` | Always `NULL` (unsupported by CockroachDB).
-`grantee` | Username of the user with grant.
-`table_catalog` | Name of the database that the grant applies to.
-`table_schema` | Name of the schema that the grant applies to.
-`table_name` | Name of the table that the grant applies to.
-`privilege_type` | Type of [privilege](authorization.html#assign-privileges): `SELECT`, `INSERT`, `UPDATE`, `DELETE`, `TRUNCATE`, `REFERENCES`, or `TRIGGER`.
-`is_grantable` | Always `NULL` (unsupported by CockroachDB).
-`with_hierarchy` | Always `NULL` (unsupported by CockroachDB).
-
-### tables
-
-`tables` identifies tables and views in the database.
-
-Column | Description
--------|-----------
-`table_catalog` | Name of the database that contains the table.
-`table_schema` | Name of the schema that contains the table.
-`table_name` | Name of the table.
-`table_type` | Type of the table: `BASE TABLE` for a normal table, `VIEW` for a view, or `SYSTEM VIEW` for a view created by CockroachDB.
-`version` | Version number of the table; versions begin at 1 and are incremented each time an `ALTER TABLE` statement is issued on the table. Note that this column is an experimental feature used for internal purposes inside CockroachDB and its definition is subject to change without notice.
-
-### type_privileges
-
-<span class="version-tag">New in v20.2:</span> `type_privileges` contains information about privileges on the user-defined types in the current database.
-
-Column | Description
--------|-----------
-`grantee` | Username of user with privilege grant.
-`type_catalog` | Name of the database that contains the type (always the current database).
-`type_schema` | Name of the schema that contains the type.
-`type_name` | Name of the type.
-`privilege_type` | Type of [privilege](authorization.html#assign-privileges).
-
-### user_privileges
-
-`user_privileges` identifies global [privileges](authorization.html#assign-privileges).
-
-Column | Description
--------|-----------
-`grantee` | Username of user with grant.
-`table_catalog` | Name of the database that the privilege applies to.
-`privilege_type` | Type of [privilege](authorization.html#assign-privileges).
-`is_grantable` | Always `NULL` (unsupported by CockroachDB).
-
-### views
-
-`views` identifies [views](views.html) in the database.
-
-Column | Description
--------|-----------
-`table_catalog` | Name of the database that contains the view.
-`table_schema` | Name of the schema that contains the view.
-`table_name` | Name of the view.
-`view_definition` | `AS` clause used to [create the view](views.html#creating-views).
-`check_option` | Always `NULL` (unsupported by CockroachDB).
-`is_updatable` | Always `NULL` (unsupported by CockroachDB).
-`is_insertable_into` | Always `NULL` (unsupported by CockroachDB).
-`is_trigger_updatable` | Always `NULL` (unsupported by CockroachDB).
-`is_trigger_deletable` | Always `NULL` (unsupported by CockroachDB).
-`is_trigger_insertable_into` | Always `NULL` (unsupported by CockroachDB).
-
-## Querying `information_schema` tables
-
-You can run [`SELECT` queries](selection-queries.html) on the tables in `information_schema`.
-
-{{site.data.alerts.callout_success}}
-The `information_schema` views typically represent objects that the current user has privilege to access. To ensure you can view all the objects in a database, access it as a user with [`admin` privileges](authorization.html#admin-role).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Unless specified otherwise, queries to `information_schema` assume the [current database](sql-name-resolution.html#current-database).
-{{site.data.alerts.end}}
-
-For example, to retrieve all columns from the `table_constraints` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM movr.information_schema.table_constraints;
-~~~
-
-~~~
-  constraint_catalog | constraint_schema |       constraint_name        | table_catalog | table_schema |         table_name         | constraint_type | is_deferrable | initially_deferred
----------------------+-------------------+------------------------------+---------------+--------------+----------------------------+-----------------+---------------+---------------------
-  movr               | public            | primary                      | movr          | public       | users                      | PRIMARY KEY     | NO            | NO
-  movr               | public            | 3426283741_53_1_not_null     | movr          | public       | users                      | CHECK           | NO            | NO
-  movr               | public            | 3426283741_53_2_not_null     | movr          | public       | users                      | CHECK           | NO            | NO
-  movr               | public            | primary                      | movr          | public       | vehicles                   | PRIMARY KEY     | NO            | NO
-  movr               | public            | fk_city_ref_users            | movr          | public       | vehicles                   | FOREIGN KEY     | NO            | NO
-  movr               | public            | 3426283741_54_1_not_null     | movr          | public       | vehicles                   | CHECK           | NO            | NO
-  movr               | public            | 3426283741_54_2_not_null     | movr          | public       | vehicles                   | CHECK           | NO            | NO
-  movr               | public            | primary                      | movr          | public       | rides                      | PRIMARY KEY     | NO            | NO
-  movr               | public            | fk_city_ref_users            | movr          | public       | rides                      | FOREIGN KEY     | NO            | NO
-  movr               | public            | fk_vehicle_city_ref_vehicles | movr          | public       | rides                      | FOREIGN KEY     | NO            | NO
-  movr               | public            | check_vehicle_city_city      | movr          | public       | rides                      | CHECK           | NO            | NO
-  movr               | public            | 3426283741_55_1_not_null     | movr          | public       | rides                      | CHECK           | NO            | NO
-  movr               | public            | 3426283741_55_2_not_null     | movr          | public       | rides                      | CHECK           | NO            | NO
-  movr               | public            | fk_city_ref_rides            | movr          | public       | vehicle_location_histories | FOREIGN KEY     | NO            | NO
-  movr               | public            | primary                      | movr          | public       | vehicle_location_histories | PRIMARY KEY     | NO            | NO
-  movr               | public            | 3426283741_56_1_not_null     | movr          | public       | vehicle_location_histories | CHECK           | NO            | NO
-  movr               | public            | 3426283741_56_2_not_null     | movr          | public       | vehicle_location_histories | CHECK           | NO            | NO
-  movr               | public            | 3426283741_56_3_not_null     | movr          | public       | vehicle_location_histories | CHECK           | NO            | NO
-  movr               | public            | primary                      | movr          | public       | promo_codes                | PRIMARY KEY     | NO            | NO
-  movr               | public            | 3426283741_57_1_not_null     | movr          | public       | promo_codes                | CHECK           | NO            | NO
-  movr               | public            | primary                      | movr          | public       | user_promo_codes           | PRIMARY KEY     | NO            | NO
-  movr               | public            | fk_city_ref_users            | movr          | public       | user_promo_codes           | FOREIGN KEY     | NO            | NO
-  movr               | public            | 3426283741_58_1_not_null     | movr          | public       | user_promo_codes           | CHECK           | NO            | NO
-  movr               | public            | 3426283741_58_2_not_null     | movr          | public       | user_promo_codes           | CHECK           | NO            | NO
-  movr               | public            | 3426283741_58_3_not_null     | movr          | public       | user_promo_codes           | CHECK           | NO            | NO
-(25 rows)
-~~~
-
-And to retrieve specific columns from the `table_constraints` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT table_name, constraint_name FROM movr.information_schema.table_constraints;
-~~~
-
-~~~
-          table_name         |       constraint_name
------------------------------+-------------------------------
-  users                      | primary
-  users                      | 3426283741_53_1_not_null
-  users                      | 3426283741_53_2_not_null
-  vehicles                   | primary
-  vehicles                   | fk_city_ref_users
-  vehicles                   | 3426283741_54_1_not_null
-  vehicles                   | 3426283741_54_2_not_null
-  rides                      | primary
-  rides                      | fk_city_ref_users
-  rides                      | fk_vehicle_city_ref_vehicles
-  rides                      | check_vehicle_city_city
-  rides                      | 3426283741_55_1_not_null
-  rides                      | 3426283741_55_2_not_null
-  vehicle_location_histories | fk_city_ref_rides
-  vehicle_location_histories | primary
-  vehicle_location_histories | 3426283741_56_1_not_null
-  vehicle_location_histories | 3426283741_56_2_not_null
-  vehicle_location_histories | 3426283741_56_3_not_null
-  promo_codes                | primary
-  promo_codes                | 3426283741_57_1_not_null
-  user_promo_codes           | fk_city_ref_users
-  user_promo_codes           | primary
-  user_promo_codes           | 3426283741_58_1_not_null
-  user_promo_codes           | 3426283741_58_2_not_null
-  user_promo_codes           | 3426283741_58_3_not_null
-(25 rows)
-~~~
-
-## See also
-
-- [System Catalogs](system-catalogs.html)
-- [`SHOW`](show-vars.html)
-- [`SHOW COLUMNS`](show-columns.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`SHOW CREATE`](show-create.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [`SHOW INDEX`](show-index.html)
-- [`SHOW TABLES`](show-tables.html)
diff --git a/src/current/v20.2/insert-data.md b/src/current/v20.2/insert-data.md
deleted file mode 100644
index 9eedd40f1a7..00000000000
--- a/src/current/v20.2/insert-data.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: Insert Data
-summary: How to insert data into CockroachDB during application development
-toc: true
----
-
-This page has instructions for getting data into CockroachDB with various programming languages, using the [`INSERT`](insert.html) SQL statement.
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Install a Postgres client](install-client-drivers.html).
-- [Connect to the database](connect-to-the-database.html).
-
-{% include {{page.version.version}}/app/retry-errors.md %}
-
-## Insert rows
-
-When inserting multiple rows, a single [multi-row insert statement](insert.html#insert-multiple-rows-into-an-existing-table) is faster than multiple single-row statements.
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go</button>
-  <button class="filter-button" data-scope="java">Java</button>
-  <button class="filter-button" data-scope="python">Python</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE IF NOT EXISTS accounts (id INT PRIMARY KEY, balance INT);
-INSERT INTO accounts (id, balance) VALUES (1, 1000), (2, 250);
-~~~
-
-For more information about how to use the built-in SQL client, see the [`cockroach sql`](cockroach-sql.html) reference docs.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-// 'db' is an open database connection
-
-// Insert two rows into the "accounts" table.
-if _, err := db.Exec(
-    "INSERT INTO accounts (id, balance) VALUES (1, 1000), (2, 250)"); err != nil {
-    log.Fatal(err)
-}
-~~~
-
-{% include {{page.version.version}}/app/for-a-complete-example-go.md %}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-// ds is an org.postgresql.ds.PGSimpleDataSource
-
-try (Connection connection = ds.getConnection()) {
-    connection.setAutoCommit(false);
-    PreparedStatement pstmt = connection.prepareStatement("INSERT INTO accounts (id, balance) VALUES (?, ?)");
-
-    pstmt.setInt(1, 1);
-    pstmt.setInt(2, 1000);
-    pstmt.addBatch();
-
-    pstmt.executeBatch();
-    connection.commit();
-} catch (SQLException e) {
-    System.out.printf("sql state = [%s]\ncause = [%s]\nmessage = [%s]\n",
-                      e.getSQLState(), e.getCause(), e.getMessage());
-}
-~~~
-
-{% include {{page.version.version}}/app/for-a-complete-example-java.md %}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-# conn is a psycopg2 connection
-
-with conn.cursor() as cur:
-    cur.execute('INSERT INTO accounts (id, balance) VALUES (1, 1000), (2, 250)')
-
-conn.commit()
-~~~
-
-{% include {{page.version.version}}/app/for-a-complete-example-python.md %}
-
-</section>
-
-## Bulk insert
-
-If you need to get a lot of data into a CockroachDB cluster quickly, use the [`IMPORT`](import.html) statement instead of sending SQL [`INSERT`s](insert.html) from application code. It will be much faster because it bypasses the SQL layer altogether and writes directly to the data store using low-level commands. For instructions, see the [Migration Overview](migration-overview.html).
-
-## See also
-
-Reference information related to this task:
-
-- [Migration Overview](migration-overview.html)
-- [`IMPORT`](import.html)
-- [Import performance](import.html#performance)
-- [`INSERT`](insert.html)
-- [`UPSERT`](upsert.html)
-- [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention)
-- [Multi-row DML best practices](performance-best-practices-overview.html#dml-best-practices)
-- [Insert Multiple Rows](insert.html#insert-multiple-rows-into-an-existing-table)
-
-Other common tasks:
-
-- [Connect to the Database](connect-to-the-database.html)
-- [Query Data](query-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-- [Run Multi-Statement Transactions](run-multi-statement-transactions.html)
-- [Error Handling and Troubleshooting](error-handling-and-troubleshooting.html)
-- [Optimize Query Performance](make-queries-fast.html)
-- [Hello World Example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[manual]: manual-deployment.html
-[orchestrated]: orchestration.html
-[local_secure]: secure-a-cluster.html
-[connection_params]: connection-parameters.html
diff --git a/src/current/v20.2/insert.md b/src/current/v20.2/insert.md
deleted file mode 100644
index 2083b0e14f7..00000000000
--- a/src/current/v20.2/insert.md
+++ /dev/null
@@ -1,739 +0,0 @@
----
-title: INSERT
-summary: The INSERT statement inserts one or more rows into a table.
-toc: true
----
-
-The `INSERT` [statement](sql-statements.html) inserts one or more rows into a table. In cases where inserted values conflict with uniqueness constraints, the `ON CONFLICT` clause can be used to update rather than insert rows.
-
-
-## Performance best practices
-
-- To bulk-insert data into an existing table, batch multiple rows in one [multi-row `INSERT`](#insert-multiple-rows-into-an-existing-table) statement. Experimentally determine the optimal batch size for your application by monitoring the performance for different batch sizes (10 rows, 100 rows, 1000 rows). Do not include multi-row `INSERT` statements within an explicit transaction.
-
-    {{site.data.alerts.callout_success}}
-    You can also use the [`IMPORT INTO`](import-into.html) statement to bulk-insert CSV data into an existing table.
-    {{site.data.alerts.end}}
-
-    {{site.data.alerts.callout_info}}
-    Large multi-row `INSERT` queries can lead to long-running transactions that result in [transaction retry errors](transaction-retry-error-reference.html). If a multi-row `INSERT` query results in an error code [`40001` with the message `"transaction deadline exceeded"`](transaction-retry-error-reference.html#retry_commit_deadline_exceeded), we recommend breaking up the query up into smaller batches of rows.
-    {{site.data.alerts.end}}
-
-- To bulk-insert data into a new table, the [`IMPORT`](import.html) statement performs better than `INSERT`.
-- In traditional SQL databases, generating and retrieving unique IDs involves using `INSERT` with `SELECT`. In CockroachDB, use `RETURNING` clause with `INSERT` instead. See [Insert and Return Values](#insert-and-return-values) for more details.
-
-## Required privileges
-
-The user must have the `INSERT` [privilege](authorization.html#assign-privileges) on the table.
-To use `ON CONFLICT`, the user must also have the `SELECT` privilege on the table.
-To use `ON CONFLICT DO UPDATE`, the user must additionally have the `UPDATE` privilege on the table.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/insert.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`common_table_expr` | See [Common Table Expressions](common-table-expressions.html).
-`table_name` | The table you want to write data to.|
-`AS table_alias_name` | An alias for the table name. When an alias is provided, it completely hides the actual table name.
-`column_name` | The name of a column to populate during the insert.
-`select_stmt` | A [selection query](selection-queries.html). Each value must match the [data type](data-types.html) of its column. Also, if column names are listed after `INTO`, values must be in corresponding order; otherwise, they must follow the declared order of the columns in the table.
-`DEFAULT VALUES` | To fill all columns with their [default values](default-value.html), use `DEFAULT VALUES` in place of `select_stmt`. To fill a specific column with its default value, leave the value out of the `select_stmt` or use `DEFAULT` at the appropriate position. See the [Insert Default Values](#insert-default-values) examples below.
-`RETURNING target_list` | Return values based on rows inserted, where `target_list` can be specific column names from the table, `*` for all columns, or computations using [scalar expressions](scalar-expressions.html). See the [Insert and Return Values](#insert-and-return-values) example below.
-
-### `ON CONFLICT` clause
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/on_conflict.html %}
-</div>
-
-Normally, when inserted values
-conflict with a `UNIQUE` constraint on one or more columns, CockroachDB
-returns an error. To update the affected rows instead, use an `ON
-CONFLICT` clause containing the column(s) with the unique constraint
-and the `DO UPDATE SET` expression set to the column(s) to be updated
-(any `SET` expression supported by the [`UPDATE`](update.html)
-statement is also supported here, including those with `WHERE`
-clauses). To prevent the affected rows from updating while allowing
-new rows to be inserted, set `ON CONFLICT` to `DO NOTHING`. See the
-[Update Values `ON CONFLICT`](#update-values-on-conflict) and [Do Not
-Update Values `ON CONFLICT`](#do-not-update-values-on-conflict)
-examples below.
-
-If the values in the `SET` expression cause uniqueness conflicts,
-CockroachDB will return an error.
-
-### `INSERT ON CONFLICT` vs. `UPSERT`
-
-As a short-hand alternative to the `ON
-CONFLICT` clause, you can use the [`UPSERT`](upsert.html)
-statement. However, `UPSERT` does not let you specify the column(s) with
-the unique constraint; it always uses the column(s) from the primary
-key. Using `ON CONFLICT` is therefore more flexible.
-
-When inserting/updating all columns of a table, and the table has no secondary
-indexes, we recommend using an [`UPSERT`](upsert.html) statement instead of the
-equivalent `INSERT ON CONFLICT` statement. Whereas `INSERT ON CONFLICT` always
-performs a read to determine the necessary writes, the `UPSERT` statement writes
-without reading, making it faster. For tables with secondary indexes, there is
-no performance difference between `UPSERT` and `INSERT ON CONFLICT`.
-
-This issue is particularly relevant when using a simple SQL table of two columns
-to [simulate direct KV access](sql-faqs.html#can-i-use-cockroachdb-as-a-key-value-store).
-In this case, be sure to use the `UPSERT` statement.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Insert a single row
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users (id, city, name, address, credit_card) VALUES
-    ('c28f5c28-f5c2-4000-8000-000000000026', 'new york', 'Petee', '101 5th Ave', '1234567890');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users WHERE city='new york';
-~~~
-
-~~~
-                   id                  |   city   |       name       |           address           | credit_card
-+--------------------------------------+----------+------------------+-----------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills        | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57 | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61 | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8   | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley              | 0792553487
-  c28f5c28-f5c2-4000-8000-000000000026 | new york | Petee            | 101 5th Ave                 | 1234567890
-(6 rows)
-~~~
-
-If you do not list column names, the statement will use the columns of the table in their declared order:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  city        | STRING    |    false    | NULL           |                       | {primary} |   false
-  name        | STRING    |    true     | NULL           |                       | {}        |   false
-  address     | STRING    |    true     | NULL           |                       | {}        |   false
-  credit_card | STRING    |    true     | NULL           |                       | {}        |   false
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users VALUES
-    ('1eb851eb-851e-4800-8000-000000000006', 'chicago', 'Adam Driver', '201 E Randolph St', '2468013579');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users WHERE city IN ('chicago', 'new york');
-~~~
-
-~~~
-                   id                  |   city   |       name       |            address             | credit_card
-+--------------------------------------+----------+------------------+--------------------------------+-------------+
-  1eb851eb-851e-4800-8000-000000000006 | chicago  | Adam Driver      | 201 E Randolph St              | 2468013579
-  80000000-0000-4000-8000-000000000019 | chicago  | Matthew Clay     | 49220 Lisa Junctions           | 9132291015
-  851eb851-eb85-4000-8000-00000000001a | chicago  | Samantha Coffey  | 6423 Jessica Underpass Apt. 87 | 9437219051
-  8a3d70a3-d70a-4000-8000-00000000001b | chicago  | Jessica Martinez | 96676 Jennifer Knolls Suite 91 | 1601930189
-  8f5c28f5-c28f-4000-8000-00000000001c | chicago  | John Hines       | 45229 Howard Manors Suite 22   | 7541086746
-  947ae147-ae14-4800-8000-00000000001d | chicago  | Kenneth Barnes   | 35627 Chelsey Tunnel Suite 94  | 2099932769
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills           | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57    | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61    | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8      | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley                 | 0792553487
-  c28f5c28-f5c2-4000-8000-000000000026 | new york | Petee            | 101 5th Ave                    | 1234567890
-(12 rows)
-~~~
-
-
-### Insert multiple rows into an existing table
-
-Multi-row inserts are faster than multiple single-row `INSERT` statements. As a performance best practice, we recommend batching multiple rows in one multi-row `INSERT` statement instead of using multiple single-row `INSERT` statements. Experimentally determine the optimal batch size for your application by monitoring the performance for different batch sizes (10 rows, 100 rows, 1000 rows).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users (id, city, name, address, credit_card) VALUES
-    ('8a3d70a3-d70a-4000-8000-00000000001b', 'seattle', 'Eric', '400 Broad St', '0987654321'),
-    ('9eb851eb-851e-4800-8000-00000000001f', 'new york', 'Harry Potter', '214 W 43rd St', '5678901234');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users WHERE city IN ('seattle', 'new york');
-~~~
-
-~~~
-                   id                  |   city   |       name       |            address            | credit_card
-+--------------------------------------+----------+------------------+-------------------------------+-------------+
-  00000000-0000-4000-8000-000000000000 | new york | Robert Murphy    | 99176 Anderson Mills          | 8885705228
-  051eb851-eb85-4ec0-8000-000000000001 | new york | James Hamilton   | 73488 Sydney Ports Suite 57   | 8340905892
-  0a3d70a3-d70a-4d80-8000-000000000002 | new york | Judy White       | 18580 Rosario Ville Apt. 61   | 2597958636
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan     | 81127 Angela Ferry Apt. 8     | 5614075234
-  147ae147-ae14-4b00-8000-000000000004 | new york | Catherine Nelson | 1149 Lee Alley                | 0792553487
-  9eb851eb-851e-4800-8000-00000000001f | new york | Harry Potter     | 214 W 43rd St                 | 5678901234
-  c28f5c28-f5c2-4000-8000-000000000026 | new york | Petee            | 101 5th Ave                   | 1234567890
-  428f5c28-f5c2-4000-8000-00000000000d | seattle  | Anita Atkinson   | 27684 Laura Villages Suite 80 | 9800065169
-  47ae147a-e147-4000-8000-00000000000e | seattle  | Patricia Herrera | 80588 Perez Camp              | 6812041796
-  4ccccccc-cccc-4c00-8000-00000000000f | seattle  | Holly Williams   | 95153 Harvey Street Suite 5   | 2165526885
-  51eb851e-b851-4c00-8000-000000000010 | seattle  | Ryan Hickman     | 21187 Dennis Village          | 1635328127
-  8a3d70a3-d70a-4000-8000-00000000001b | seattle  | Eric             | 400 Broad St                  | 0987654321
-(12 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-You can also use the [`IMPORT INTO`](import-into.html) statement to bulk-insert CSV data into an existing table.
-{{site.data.alerts.end}}
-
-### Insert multiple rows into a new table
-
-The [`IMPORT`](import.html) statement performs better than `INSERT` when inserting rows into a new table.
-
-### Insert from a `SELECT` statement
-
-Suppose that you want MovR to offer ride-sharing services, in addition to vehicle-sharing services. You can create a `drivers` table from a subset of the `users` table.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE drivers (
-    id UUID DEFAULT gen_random_uuid(),
-    city STRING,
-    name STRING,
-    dl STRING UNIQUE CHECK (LENGTH(dl) < 8),
-    address STRING,
-    CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (id, city, name, address)
-    SELECT id, city, name, address FROM users
-    WHERE name IN ('Anita Atkinson', 'Devin Jordan');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM drivers;
-~~~
-
-~~~
-                   id                  |   city   |      name      |  dl  |            address
-+--------------------------------------+----------+----------------+------+-------------------------------+
-  0f5c28f5-c28f-4c00-8000-000000000003 | new york | Devin Jordan   | NULL | 81127 Angela Ferry Apt. 8
-  428f5c28-f5c2-4000-8000-00000000000d | seattle  | Anita Atkinson | NULL | 27684 Laura Villages Suite 80
-(2 rows)
-~~~
-
-### Insert default values
-
-To check the [default values](default-value.html) for columns in a table, use the [`SHOW CREATE TABLE`](show-create.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE drivers;
-~~~
-
-~~~
-  table_name |                     create_statement
-+------------+----------------------------------------------------------+
-  drivers    | CREATE TABLE drivers (
-             |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-             |     city STRING NOT NULL,
-             |     name STRING NULL,
-             |     dl STRING NULL,
-             |     address STRING NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     UNIQUE INDEX drivers_dl_key (dl ASC),
-             |     FAMILY "primary" (id, city, name, dl, address),
-             |     CONSTRAINT check_dl CHECK (length(dl) < 8)
-             | )
-(1 row)
-~~~
-
-If the `DEFAULT` value constraint is not specified and an explicit value is not given, a value of *NULL* is assigned to the column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (city, name) VALUES ('seattle', 'Bobby');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (city, name, id) VALUES ('chicago', 'Terry', DEFAULT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM drivers WHERE name in ('Bobby', 'Terry');
-~~~
-
-~~~
-                   id                  |  city   | name  |  dl  | address
-+--------------------------------------+---------+-------+------+---------+
-  c8d36f0e-9eb4-439f-b3d0-029af184d24b | chicago | Terry | NULL | NULL
-  af2e8122-bf87-4736-bde9-a42ad0857351 | seattle | Bobby | NULL | NULL
-(2 rows)
-~~~
-
-To create a new row with only default values, use `INSERT INTO <table> DEFAULT VALUES`. Running this command on the `drivers` table results in an error because the `city` column in `drivers` cannot be *NULL*, and has no default value specified.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers DEFAULT VALUES;
-~~~
-
-~~~
-pq: null value in column "city" violates not-null constraint
-~~~
-
-### Insert and return values
-
-In this example, the `RETURNING` clause returns the `id` values of the rows inserted, which are generated server-side by the `gen_random_uuid()` function. The language-specific versions assume that you have installed the relevant [client drivers](install-client-drivers.html).
-
-{{site.data.alerts.callout_success}}This use of <code>RETURNING</code> mirrors the behavior of MySQL's <code>last_insert_id()</code> function.{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}When a driver provides a <code>query()</code> method for statements that return results and an <code>exec()</code> method for statements that do not (e.g., Go), it's likely necessary to use the <code>query()</code> method for <code>INSERT</code> statements with <code>RETURNING</code>.{{site.data.alerts.end}}
-
-<div class="filters clearfix">
-    <button class="filter-button" data-scope="shell">Shell</button>
-    <button class="filter-button" data-scope="python">Python</button>
-    <button class="filter-button" data-scope="ruby">Ruby</button>
-    <button class="filter-button" data-scope="go">Go</button>
-    <button class="filter-button" data-scope="js">Node.js</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="shell">
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (id, city)
-  VALUES (DEFAULT, 'seattle'), (DEFAULT, 'chicago')
-  RETURNING id;
-~~~
-
-~~~
-                   id
-+--------------------------------------+
-  b7750a60-91f2-404e-9cd1-5a3c310c1c9d
-  c85e637e-2b03-4a52-bc54-1e1f6d7fd89b
-(2 rows)
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-# Import the driver.
-import psycopg2
-
-# Connect to the "movr" database.
-conn = psycopg2.connect(
-    database='movr',
-    user='root',
-    host='localhost',
-    port=26257
-)
-
-# Make each statement commit immediately.
-conn.set_session(autocommit=True)
-
-# Open a cursor to perform database operations.
-cur = conn.cursor()
-
-# Insert two rows into the "drivers" table
-# and return the "id" values generated server-side.
-cur.execute(
-    "INSERT INTO drivers (id, city) "
-    "VALUES (DEFAULT, 'seattle'), (DEFAULT, 'chicago') "
-    "RETURNING id"
-)
-
-# Print out the returned values.
-rows = cur.fetchall()
-print('IDs:')
-for row in rows:
-    print([str(cell) for cell in row])
-
-# Close the database connection.
-cur.close()
-conn.close()
-~~~
-
-The printed values would look like:
-
-~~~
-IDs:
-['cdd379e3-2d0b-4622-8ba8-4f0a1edfbc8e']
-['4224b360-b1b0-4e4d-aba2-a35c64cdf404']
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="ruby">
-
-{% include copy-clipboard.html %}
-~~~ ruby
-# Import the driver.
-require 'pg'
-
-# Connect to the "movr" database.
-conn = PG.connect(
-    user: 'root',
-    dbname: 'movr',
-    host: 'localhost',
-    port: 26257
-)
-
-# Insert two rows into the "drivers" table
-# and return the "id" values generated server-side.
-conn.exec(
-    "INSERT INTO drivers (id, city) "\
-    "VALUES (DEFAULT, 'seattle'), (DEFAULT, 'chicago') "\
-    "RETURNING id"
-) do |res|
-
-# Print out the returned values.
-puts "IDs:"
-    res.each do |row|
-        puts row
-    end
-end
-
-# Close communication with the database.
-conn.close()
-~~~
-
-The printed values would look like:
-
-~~~
-IDs:
-{"id"=>"cdd379e3-2d0b-4622-8ba8-4f0a1edfbc8e"}
-{"id"=>"4224b360-b1b0-4e4d-aba2-a35c64cdf404"}
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-package main
-
-import (
-	"database/sql"
-	"fmt"
-	"log"
-
-	_ "github.com/lib/pq"
-)
-
-func main() {
-	//Connect to the "movr" database.
-	db, err := sql.Open(
-		"postgres",
-		"postgresql://root@localhost:26257/movr?sslmode=disable",
-	)
-	if err != nil {
-		log.Fatal("error connecting to the database: ", err)
-	}
-
-	// Insert two rows into the "drivers" table
-	// and return the "id" values generated server-side.
-	rows, err := db.Query(
-		"INSERT INTO drivers (id, city) " +
-			"VALUES (DEFAULT, 'seattle'), (DEFAULT, 'chicago') " +
-			"RETURNING id",
-	)
-	if err != nil {
-		log.Fatal(err)
-	}
-
-	// Print out the returned values.
-	defer rows.Close()
-	fmt.Println("IDs:")
-	for rows.Next() {
-		var id string
-		if err := rows.Scan(&id); err != nil {
-			log.Fatal(err)
-		}
-		fmt.Printf("%s\n", id)
-	}
-}
-~~~
-
-The printed values would look like:
-
-~~~
-IDs:
-cdd379e3-2d0b-4622-8ba8-4f0a1edfbc8e
-4224b360-b1b0-4e4d-aba2-a35c64cdf404
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="js">
-
-{% include copy-clipboard.html %}
-~~~ js
-var async = require('async')
-var pg = require('pg')
-
-// Config to connect to the "movr" database.
-var config = {
-    user: 'root',
-    host: 'localhost',
-    database: 'movr',
-    port: 26257
-  }
-
-// Create pool
-var pool = new pg.Pool(config)
-
-pool.connect(function (err, client, done) {
-
-    // Close communication with the database and exit.
-    var finish = function () {
-        done()
-        process.exit()
-    }
-
-    if (err) {
-        console.error('could not connect to cockroachdb', err)
-        finish()
-    }
-  async.waterfall([
-    function (next) {
-      // Insert two rows into the "drivers" table
-      // and return the "id" values generated server-side.
-      client.query(
-        `INSERT INTO drivers (id, city)
-         VALUES (DEFAULT, 'seattle'), (DEFAULT, 'chicago')
-         RETURNING id`,
-        next
-      )
-    }
-  ],
-  function (err, results) {
-    if (err) {
-      console.error('error inserting into and selecting from drivers', err)
-      finish()
-    }
-    // Print out the returned values.
-    console.log('IDs:')
-    results.rows.forEach(function (row) {
-      console.log(row)
-    })
-
-    finish()
-  })
-})
-~~~
-
-The printed values would look like:
-
-~~~
-IDs:
-{ id: 'cdd379e3-2d0b-4622-8ba8-4f0a1edfbc8e' }
-{ id: '4224b360-b1b0-4e4d-aba2-a35c64cdf404' }
-~~~
-
-</section>
-
-### Update values `ON CONFLICT`
-
-When a uniqueness conflict is detected, CockroachDB stores the row in a temporary table called `excluded`. This example demonstrates how you use the columns in the temporary `excluded` table to apply updates on conflict.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004', 'promo_code', now(), 1)
-    ON CONFLICT (city, user_id, code)
-    DO UPDATE SET usage_count = excluded.usage_count;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM user_promo_codes WHERE code = 'promo_code';
-~~~
-
-~~~
-    city   |               user_id                |    code    |            timestamp             | usage_count
-+----------+--------------------------------------+------------+----------------------------------+-------------+
-  new york | 147ae147-ae14-4b00-8000-000000000004 | promo_code | 2019-08-12 14:23:52.262849+00:00 |           1
-(1 row)
-~~~
-
-You can also update the row using an existing value:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004', 'promo_code', now(), 1)
-    ON CONFLICT (city, user_id, code)
-    DO UPDATE SET ("timestamp", usage_count) = (now(), user_promo_codes.usage_count + excluded.usage_count);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM user_promo_codes WHERE code = 'promo_code';
-~~~
-
-~~~
-    city   |               user_id                |    code    |            timestamp             | usage_count
-+----------+--------------------------------------+------------+----------------------------------+-------------+
-  new york | 147ae147-ae14-4b00-8000-000000000004 | promo_code | 2019-08-12 14:26:50.697382+00:00 |           2
-(1 row)
-~~~
-
-You can also use a `WHERE` clause to apply the `DO UPDATE SET` expression conditionally:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004', 'promo_code', now(), 3)
-    ON CONFLICT (city, user_id, code)
-    DO UPDATE SET ("timestamp", usage_count) = (now(), user_promo_codes.usage_count + excluded.usage_count)
-    WHERE excluded.usage_count = 1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM user_promo_codes WHERE code = 'promo_code';
-~~~
-
-~~~
-    city   |               user_id                |    code    |            timestamp             | usage_count
-+----------+--------------------------------------+------------+----------------------------------+-------------+
-  new york | 147ae147-ae14-4b00-8000-000000000004 | promo_code | 2019-08-12 14:26:50.697382+00:00 |           2
-(1 row)
-~~~
-
-### Do not update values `ON CONFLICT`
-
-In this example, we get an error from a uniqueness conflict.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004', 'promo_code', now(), 1);
-~~~
-
-~~~
-pq: duplicate key value (city,user_id,code)=('new york','147ae147-ae14-4b00-8000-000000000004','promo_code') violates unique constraint "primary"
-~~~
-
-In this example, we use `ON CONFLICT DO NOTHING` to ignore the uniqueness error and prevent the affected row from being updated:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004', 'promo_code', now(), 1)
-    ON CONFLICT (city, user_id, code)
-    DO NOTHING;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM user_promo_codes WHERE code = 'promo_code';
-~~~
-
-~~~
-    city   |               user_id                |    code    |            timestamp             | usage_count
-+----------+--------------------------------------+------------+----------------------------------+-------------+
-  new york | 147ae147-ae14-4b00-8000-000000000004 | promo_code | 2019-08-12 14:26:50.697382+00:00 |           2
-(1 row)
-~~~
-
-In this example, `ON CONFLICT DO NOTHING` prevents the first row from updating while allowing the second row to be inserted:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004', 'promo_code', now(), 1), ('new york', '147ae147-ae14-4b00-8000-000000000004', 'new_promo', now(), 1)
-    ON CONFLICT (city, user_id, code)
-    DO NOTHING;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM user_promo_codes WHERE code in ('promo_code', 'new_promo');
-~~~
-
-~~~
-    city   |               user_id                |    code    |            timestamp             | usage_count
-+----------+--------------------------------------+------------+----------------------------------+-------------+
-  new york | 147ae147-ae14-4b00-8000-000000000004 | new_promo  | 2019-08-12 14:30:16.666848+00:00 |           1
-  new york | 147ae147-ae14-4b00-8000-000000000004 | promo_code | 2019-08-12 14:26:50.697382+00:00 |           2
-(2 rows)
-~~~
-
-### Import data containing duplicate rows using `ON CONFLICT` and `DISTINCT ON`
-
-If the input data for `INSERT ON CONFLICT` contains duplicate rows,
-you must use [`DISTINCT
-ON`](select-clause.html#eliminate-duplicate-rows) to remove these
-duplicates.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH inputrows (city, user_id, code, "timestamp", usage_count)
-    AS (VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004'::uuid, 'promo_code', now()::timestamp, 0), ('new york', '147ae147-ae14-4b00-8000-000000000004'::uuid, 'new_promo', now()::timestamp, 2))
-    INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    (SELECT DISTINCT ON(city, user_id, code) * FROM inputrows)
-    ON CONFLICT (city, user_id, code)
-    DO NOTHING;
-~~~
-
-The `DISTINCT ON` clause does not guarantee which of the duplicates is
-considered. To force the selection of a particular duplicate, use an
-`ORDER BY` clause:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH inputrows (city, user_id, code, "timestamp", usage_count)
-    AS (VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004'::uuid, 'promo_code', now()::timestamp, 0), ('new york', '147ae147-ae14-4b00-8000-000000000004'::uuid, 'new_promo', now()::timestamp, 2))
-    INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    (SELECT DISTINCT ON(city, user_id, code) * FROM inputrows ORDER BY (city, user_id, code, usage_count))
-    ON CONFLICT (city, user_id, code)
-    DO NOTHING;
-~~~
-
-{{site.data.alerts.callout_info}}
-Using `DISTINCT ON` incurs a performance cost to search and eliminate duplicates.
-For best performance, avoid using it when the input is known to not contain duplicates.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Ordering of rows in DML statements](order-by.html#ordering-rows-in-dml-statements)
-- [Selection Queries](selection-queries.html)
-- [`DELETE`](delete.html)
-- [`UPDATE`](update.html)
-- [`UPSERT`](upsert.html)
-- [`TRUNCATE`](truncate.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`DROP TABLE`](drop-table.html)
-- [`DROP DATABASE`](drop-database.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/install-client-drivers.md b/src/current/v20.2/install-client-drivers.md
deleted file mode 100644
index 0bd98e9ae0e..00000000000
--- a/src/current/v20.2/install-client-drivers.md
+++ /dev/null
@@ -1,398 +0,0 @@
----
-title: Install a Driver or ORM Framework
-summary: CockroachDB supports both native drivers and the PostgreSQL wire protocol, so you can use most available PostgreSQL client drivers and ORM frameworks.
-toc: true
----
-
-CockroachDB supports both native drivers and the PostgreSQL wire protocol, so most available PostgreSQL client drivers and ORM frameworks should work with CockroachDB. Choose a language for supported clients, and follow the installation steps. After you install a client library, you can [connect to the database](connect-to-the-database.html).
-
-{{site.data.alerts.callout_info}}
-Applications may encounter incompatibilities when using advanced or obscure features of a driver or ORM framework with **beta-level** support. If you encounter problems, please [open an issue](https://github.com/cockroachdb/cockroach/issues/new) with details to help us make progress toward full support.
-{{site.data.alerts.end}}
-
-<div class="filters clearfix">
-  <button class="filter-button page-level" data-scope="python">Python</button>
-  <button class="filter-button page-level" data-scope="java">Java</button>
-  <button class="filter-button page-level" data-scope="go">Go</button>
-  <button class="filter-button page-level" data-scope="ruby">Ruby</button>
-  <button class="filter-button page-level" data-scope="js-ts">JavaScript/TypeScript</button>
-  <button class="filter-button page-level" data-scope="c">C</button>
-  <button class="filter-button page-level" data-scope="c-sharp">C# (.NET)</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-## Python Drivers
-
-### psycopg2
-
-**Support level:** Full
-
-To install the Python psycopg2 driver:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pip install psycopg2
-~~~
-
-For other ways to install psycopg2, see the [official documentation](http://initd.org/psycopg/docs/install.html).
-
-For a simple but complete example app, see [Build a Python App with CockroachDB and psycopg2](build-a-python-app-with-cockroachdb.html).
-
-## Python ORM frameworks
-
-### SQLAlchemy
-
-**Support level:** Full
-
-To install SQLAlchemy and a [CockroachDB Python package](https://github.com/cockroachdb/sqlalchemy-cockroachdb) that accounts for some differences between CockroachDB and PostgreSQL:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pip install sqlalchemy sqlalchemy-cockroachdb psycopg2
-~~~
-
-{{site.data.alerts.callout_success}}
-You can substitute psycopg2 for other alternatives that include the psycopg python package.
-{{site.data.alerts.end}}
-
-For other ways to install SQLAlchemy, see the [official documentation](http://docs.sqlalchemy.org/en/latest/intro.html#installation-guide).
-
-For a simple but complete example app, see [Build a Python App with CockroachDB and SQLAlchemy](build-a-python-app-with-cockroachdb-sqlalchemy.html).
-
-### Django
-
-**Support level:** Full
-
-CockroachDB supports Django versions 3.1+.
-
-To install [Django](https://docs.djangoproject.com/en/3.0/topics/install/):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pip install django==3.1.*
-~~~
-
-Before installing the [CockroachDB backend for Django](https://github.com/cockroachdb/django-cockroachdb), you must install one of the following psycopg2 prerequisites:
-
-- [psycopg2](https://pypi.org/project/psycopg2/), which has some
-  [prerequisites](https://www.psycopg.org/docs/install.html#prerequisites) of
-  its own. This package is recommended for production environments.
-
-- [psycopg2-binary](https://pypi.org/project/psycopg2-binary/). This package is recommended for development and testing.
-
-After you install the psycopg2 prerequisite, you can install the CockroachDB Django backend:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pip install django-cockroachdb==3.1.*
-~~~
-
-{{site.data.alerts.callout_info}}
-The major version of `django-cockroachdb` must correspond to the major version of `django`. The minor release numbers do not need to match.
-{{site.data.alerts.end}}
-
-For a simple but complete example app, see [Build a Python App with CockroachDB and Django](build-a-python-app-with-cockroachdb-django.html).
-
-### PonyORM
-
-**Support level:** Full
-
-To install PonyORM:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pip install pony
-~~~
-
-For a simple but complete example app, see [Build a Python App with CockroachDB and PonyORM](build-a-python-app-with-cockroachdb-pony.html).
-
-### peewee
-
-**Support level:** Full
-
-To install peewee:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pip install peewee
-~~~
-
-For instructions on using peewee with CockroachDB, see the [CockroachDatabase peewee extension documentation](http://docs.peewee-orm.com/en/latest/peewee/playhouse.html#cockroach-database).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include {{page.version.version}}/app/java-version-note.md %}
-
-{% include {{page.version.version}}/app/java-tls-note.md %}
-
-## Java Drivers
-
-### JDBC
-
-**Support level:** Full
-
-Download and set up the Java JDBC driver as described in the [official documentation](https://jdbc.postgresql.org/documentation/setup/). We recommend using the PostgreSQL JDBC 42.2.9 driver.
-
-For a simple but complete example app, see [Build a Java App with CockroachDB and JDBC](build-a-java-app-with-cockroachdb.html).
-
-## Java ORM frameworks
-
-### Hibernate
-
-**Support level:** Full
-
-You can use [Gradle](https://gradle.org/install) or [Maven](https://maven.apache.org/install.html) to get all dependencies for your application, including Hibernate. Only Hibernate versions 5.4.19 and later support the Hibernate CockroachDB dialect.
-
-If you are using Gradle, add the following to your `dependencies`:
-
-~~~ groovy
-implementation 'org.hibernate:hibernate-core:5.4.19.Final'
-implementation 'org.postgresql:postgresql:42.2.9'
-~~~
-
-For a simple but complete example app that uses Gradle for dependency management, see [Build a Java App with CockroachDB and Hibernate](build-a-java-app-with-cockroachdb-hibernate.html).
-
-If you are using Maven, add the following to your `<dependencies>`:
-
-~~~ xml
-<dependency>
-    <groupId>org.hibernate</groupId>
-    <artifactId>hibernate-core</artifactId>
-    <version>5.4.19.Final</version>
-</dependency>
-<dependency>
-    <groupId>org.postgresql</groupId>
-    <artifactId>postgresql</artifactId>
-</dependency>
-~~~
-
-For a complete example app that uses Maven for dependency management, see [Build a Spring App with CockroachDB and Spring Data JPA (Hibernate)](build-a-spring-app-with-cockroachdb-jpa.html).
-
-You will also need to specify the CockroachDB dialect in your [Hibernate configuration file](https://www.tutorialspoint.com/hibernate/hibernate_configuration.htm). Versions of the Hibernate CockroachDB dialect correspond to the version of CockroachDB installed on your machine. For example, `org.hibernate.dialect.CockroachDB201Dialect` corresponds to CockroachDB v20.1 and later, and `org.hibernate.dialect.CockroachDB192Dialect` corresponds to CockroachDB v19.2 and later.
-
-All dialect versions are forward-compatible (e.g., CockroachDB v20.1 is compatible with `CockroachDB192Dialect`), as long as your application is not affected by any backward-incompatible changes listed in your CockroachDB version's [release notes](../releases/index.html). In the event of a CockroachDB version upgrade, using a previous version of the CockroachDB dialect will not break an application, but, to enable all features available in your version of CockroachDB, we recommend keeping the dialect version in sync with the installed version of CockroachDB.
-
-Not all versions of CockroachDB have a corresponding dialect yet. Use the dialect number that is closest to your installed version of CockroachDB. For example, use `CockroachDB201Dialect` when using CockroachDB v21.1.
-
-### jOOQ
-
-**Support level:** Full
-
-You can use [Gradle](https://gradle.org/install) or [Maven](https://maven.apache.org/install.html) to get all dependencies for your application, including jOOQ.
-
-For a simple but complete example app that uses Maven for dependency management, see [Build a Java App with CockroachDB and jOOQ](build-a-java-app-with-cockroachdb-jooq.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-## Go Drivers
-
-### pgx
-
-**Support level:** Full
-
-To install the [Go pgx driver](https://pkg.go.dev/github.com/jackc/pgx):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ go get -u github.com/jackc/pgx
-~~~
-
-For a simple but complete example app, see [Build a Go App with CockroachDB and the Go pgx Driver](build-a-go-app-with-cockroachdb.html).
-
-### pq
-
-**Support level:** Full
-
-To install the [Go pq driver](https://godoc.org/github.com/lib/pq):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ go get -u github.com/lib/pq
-~~~
-
-For a simple but complete example app, see [Build a Go App with CockroachDB and the Go pq Driver](build-a-go-app-with-cockroachdb.html).
-
-## Go ORM frameworks
-
-### GORM
-
-**Support level:** Full
-
-To install [GORM](http://gorm.io):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ go get -u github.com/lib/pq # dependency
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ go get -u github.com/jinzhu/gorm
-~~~
-
-For a simple but complete example app, see [Build a Go App with CockroachDB and GORM](build-a-go-app-with-cockroachdb-gorm.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="ruby">
-
-## Ruby Drivers
-
-### pg
-
-**Support level:** Full
-
-To install the [Ruby pg driver](https://rubygems.org/gems/pg):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ gem install pg
-~~~
-
-For a simple but complete example app, see [Build a Ruby App with CockroachDB and the Ruby pg Driver](build-a-ruby-app-with-cockroachdb.html).
-
-## Ruby ORM frameworks
-
-### ActiveRecord
-
-**Support level:** Full (5.2), Beta (6.0)
-
-To install ActiveRecord, the [pg driver](https://rubygems.org/gems/pg), and a [CockroachDB Ruby package](https://github.com/cockroachdb/activerecord-cockroachdb-adapter) that accounts for some minor differences between CockroachDB and PostgreSQL:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ gem install activerecord pg activerecord-cockroachdb-adapter
-~~~
-
-{{site.data.alerts.callout_info}}
-The exact command above will vary depending on the desired version of ActiveRecord. Specifically, version 5.1.x of ActiveRecord requires version 0.2.x of the adapter; version 5.2.x of ActiveRecord requires version 5.2.x of the adapter; version 6.0.x of ActiveRecord requires version 6.0.0betax of the adapter.
-{{site.data.alerts.end}}
-
-For a simple but complete example app, see [Build a Ruby App with CockroachDB and ActiveRecord](build-a-ruby-app-with-cockroachdb-activerecord.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="js-ts">
-
-## JavaScript Drivers
-
-### pg
-
-**Support level:** Beta
-
-To install the [Node.js pg driver](https://www.npmjs.com/package/pg):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ npm install pg
-~~~
-
-Some apps might also require [`async`](https://www.npmjs.com/package/async):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ npm install async
-~~~
-
-For a simple but complete example app, see [Build a Node.js App with CockroachDB and the Node.js pg Driver](build-a-nodejs-app-with-cockroachdb.html).
-
-## JavaScript/TypeScript ORM frameworks
-
-### Sequelize
-
-**Support level:** Beta
-
-To install Sequelize and a [CockroachDB Node.js package](https://github.com/cockroachdb/sequelize-cockroachdb) that accounts for some minor differences between CockroachDB and PostgreSQL:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ npm install sequelize sequelize-cockroachdb
-~~~
-
-For a simple but complete example app, see [Build a Node.js App with CockroachDB and Sequelize](build-a-nodejs-app-with-cockroachdb-sequelize.html).
-
-### TypeORM
-
-**Support level:** Full
-
-Install TypeORM as described in the [official documentation](https://typeorm.io/#/).
-
-For a simple but complete example app, see [Build a TypeScript App with CockroachDB and TypeORM](build-a-typescript-app-with-cockroachdb.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="c">
-
-## C Drivers
-
-### libpq
-
-**Support level:** Beta
-
-Install the C libpq driver as described in the [official documentation](https://www.postgresql.org/docs/current/libpq.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="c-sharp">
-
-## C# Drivers
-
-### Npgsql
-
-**Support level:** Beta
-
-1. Create a .NET project:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ dotnet new console -o cockroachdb-test-app
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cd cockroachdb-test-app
-    ~~~
-
-    The `dotnet` command creates a new app of type `console`. The `-o` parameter creates a directory named `cockroachdb-test-app` where your app will be stored and populates it with the required files. The `cd cockroachdb-test-app` command puts you into the newly created app directory.
-
-2. Install the latest version of the [Npgsql driver](https://www.nuget.org/packages/Npgsql/) into the .NET project using the built-in nuget package manager:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ dotnet add package Npgsql
-    ~~~
-
-For a simple but complete example app, see [Build a C# App with CockroachDB and the .NET Npgsql Driver](build-a-csharp-app-with-cockroachdb.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="rust">
-
-## Rust Drivers
-
-### rust-postgres
-
-**Support level:** Beta
-
-Install the Rust Postgres driver as described in the [official documentation](https://crates.io/crates/postgres).
-
-For a simple but complete example app, see [Build a Rust App with CockroachDB and the Rust Postgres Driver](build-a-rust-app-with-cockroachdb.html).
-
-</section>
-
-## What's next?
-
-- [Connect to CockroachDB](connect-to-the-database.html)
-- [Design a Database Schema](schema-design-overview.html)
-
-You might also be interested in the following pages:
-
-- [Third party database tools](third-party-database-tools.html)
-- [Connection parameters](connection-parameters.html)
-- [Transactions](transactions.html)
-- [Performance best practices](performance-best-practices-overview.html)
diff --git a/src/current/v20.2/install-cockroachdb-linux.md b/src/current/v20.2/install-cockroachdb-linux.md
deleted file mode 100644
index a179ab2f7ed..00000000000
--- a/src/current/v20.2/install-cockroachdb-linux.md
+++ /dev/null
@@ -1,231 +0,0 @@
----
-title: Install CockroachDB on Linux
-summary: Install CockroachDB on Mac, Linux, or Windows. Sign up for product release notes.
-tags: download, binary, homebrew
-toc: true
-key: install-cockroachdb.html
----
-
-<div id="os-tabs" class="clearfix">
-  <a href="install-cockroachdb-mac.html"><button id="mac" data-eventcategory="buttonClick-doc-os" data-eventaction="mac">Mac</button></a>
-  <button id="linux" class="current" data-eventcategory="buttonClick-doc-os" data-eventaction="linux">Linux</button>
-  <a href="install-cockroachdb-windows.html"><button id="windows" data-eventcategory="buttonClick-doc-os" data-eventaction="windows">Windows</button></a>
-</div>
-
-<p>See <a href="../releases/{{page.version.version}}.html" class="mac-releasenotes-download" id="mac-releasenotes-download-{{page.version.version}}" data-eventcategory="mac-releasenotes-download">Release Notes</a> for what's new in the latest release, {{ page.release_info.version }}. To upgrade to this release from an older version, see <a href="upgrade-cockroach-version.html">Cluster Upgrade</a>.</p>
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-<h2>Install options</h2>
-
-Use one of the options below to install CockroachDB.
-
-<div id="download-the-binary-linux" class="install-option">
-  <h3>Download the binary</h3>
-  {% include {{ page.version.version }}/misc/linux-binary-prereqs.md %}
-  <ol>
-    <li>
-      <p>Download the <a href="https://binaries.cockroachdb.com/cockroach-{{page.release_info.version}}.linux-amd64.tgz" class="linux-binary-step1" id="linux-binary-step1-{{page.version.version}}" data-eventcategory="linux-binary-step1">CockroachDB archive</a> for Linux and the supporting libraries that are used to provide <a href="spatial-features.html">spatial features</a>, and extract the binary:</p>
-      <div class="copy-clipboard">
-        <svg data-eventcategory="linux-binary-step1-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-
-      <div class="highlight"><pre><code data-eventcategory="linux-binary-step1" data-lang="shell"><span class="nv language-shell linux-binary-step1" id="linux-binary-step1-{{ page.version.version }}" data-eventcategory="linux-binary-step1">$ </span>curl https://binaries.cockroachdb.com/cockroach-{{page.release_info.version}}.linux-amd64.tgz | tar -xz</code></pre></div>
-    </li>
-    <li>
-      <p>Copy the binary into your <code>PATH</code> so you can execute <a href="cockroach-commands.html">cockroach commands</a> from any shell:</p>
-
-      {% include copy-clipboard.html %}<div class="highlight"><pre class="highlight"><code><span class="nv language-shell"></span>cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/</code></pre></div>
-      <p>If you get a permissions error, prefix the command with <code>sudo</code>.</p>
-    </li>
-    <div class="bs-callout bs-callout--info"><div class="bs-callout__label">Note:</div>
-    <p>If you plan to use CockroachDB's <a href="spatial-features.html">spatial features</a>, you must complete the following steps. Otherwise, your installation is now complete.</p>
-    </div>
-    <li>
-      <p>CockroachDB uses custom-built versions of the <a href="spatial-glossary.html#geos">GEOS</a> libraries. Copy these libraries to one of the locations where CockroachDB expects to find them.</p>
-      <p>By default, CockroachDB looks for external libraries in <code>/usr/local/lib/cockroach</code> or a <code>lib</code> subdirectory of the CockroachDB binary&#39;s current directory. If you place these libraries in another location, you must pass the location in the <a href="cockroach-start.html#flags-spatial-libs"><code>--spatial-libs</code> flag to <code>cockroach start</code></a>. The instructions below assume the <code>/usr/local/lib/cockroach</code> location.</p>
-      <ol>
-        <li>Create the directory where the external libraries will be stored:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell"><span class="nb">mkdir</span> <span class="nt">-p</span> /usr/local/lib/cockroach</code></pre></div>
-        </li>
-        <li>Copy the library files to the directory:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell"><span class="nb">cp </span>-i cockroach-{{ page.release_info.version }}.linux-amd64/lib/libgeos.so /usr/local/lib/cockroach/</code></pre></div>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell"><span class="nb">cp </span>-i cockroach-{{ page.release_info.version }}.linux-amd64/lib/libgeos_c.so /usr/local/lib/cockroach/</code></pre></div>
-          <p>If you get a permissions error, prefix the command with <code>sudo</code>.</p>
-        </li>
-      </ol>
-    </li>
-    <li><p>Verify that CockroachDB can execute spatial queries.</p>
-      <ol>
-        <li><p>Make sure the <code>cockroach</code> binary you just installed is the one that runs when you type <code>cockroach</code> in your shell:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell">which cockroach</code></pre></div>
-          <div class="highlight"><pre><code class="language-" data-lang="">/usr/local/bin/cockroach</code></pre></div>
-        </li>
-        <li><p>Start a temporary, in-memory cluster using <a href="cockroach-demo.html"><code>cockroach demo</code></a>:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell">cockroach demo</code></pre></div>
-
-        <li><p>In the demo cluster's interactive SQL shell, run the following command to test that the spatial libraries have loaded properly:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-
-          <div class="highlight"><pre><code class="language-sql" data-lang="sql"><span class="o">&gt;</span> <span class="k">SELECT</span> <span class="n">ST_IsValid</span><span class="p">(</span><span class="n">ST_MakePoint</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span><span class="mi">2</span><span class="p">));</span></code></pre></div>
-          <p>You should see the following output:</p>
-          <div class="highlight"><pre><code class="language-" data-lang="">  st_isvalid
---------------
-true
-(1 row)</code></pre></div>
-          <p>If your <code>cockroach</code> binary is not properly accessing the dynamically linked C libraries in <code>/usr/local/lib/cockroach</code>, it will output an error message like the one below.</p>
-          <div class="highlight"><pre><code class="language-" data-lang="">ERROR: st_isvalid(): geos: error during GEOS init: geos: cannot load GEOS from dir "/usr/local/lib/cockroach": failed to execute dlopen
-          Failed running "sql"</code></pre></div>
-        </li>
-      </ol>
-    <li>
-      <p>Keep up-to-date with CockroachDB releases and best practices:</p>
-{% include marketo-install.html uid="1" %}
-    </li>
-  </ol>
-</div>
-
-<div id="use-kubernetes" class="install-option">
-  <h3>Use Kubernetes</h3>
-
-  <p>To orchestrate CockroachDB using <a href="https://kubernetes.io/">Kubernetes</a>, either with configuration files or the <a href="https://helm.sh/">Helm</a> package manager, use the following tutorials:</p>
-
-  <ul>
-  <li><a href="orchestrate-a-local-cluster-with-kubernetes.html">Orchestrate CockroachDB Locally with Minikube</a></li>
-  <li><a href="orchestrate-cockroachdb-with-kubernetes.html">Orchestrate CockroachDB in a Single Kubernetes Cluster</a></li>
-  <li><a href="orchestrate-cockroachdb-with-kubernetes-multi-cluster.html">Orchestrate CockroachDB Across Multiple Kubernetes Clusters</a></li>
-  </ul>
-</div>
-
-<div id="use-docker-linux" class="install-option">
-  <h3>Use Docker</h3>
-
-  {{site.data.alerts.callout_danger}}Running a stateful application like CockroachDB in Docker is more complex and error-prone than most uses of Docker. Unless you are very experienced with Docker, we recommend starting with a different installation and deployment method.{{site.data.alerts.end}}
-
-  <ol>
-    <li>
-      <p>Install <a href="https://docs.docker.com/engine/installation/linux/docker-ce/ubuntu/">Docker for Linux</a>. Please carefully check that you meet all prerequisites.</p>
-    </li>
-    <li>
-      <p>Confirm that the Docker daemon is running in the background:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="linux-docker-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code data-eventcategory="linux-docker-step2"><span class="nv language-shell linux-docker-step2" id="linux-docker-step2-{{ page.version.version }}" data-eventcategory="linux-docker-step2">$ </span>docker version</code></pre></div>
-      <p>If you do not see the server listed, start the <strong>Docker</strong> daemon.</p>
-
-      {{site.data.alerts.callout_info}}On Linux, Docker needs sudo privileges.{{site.data.alerts.end}}
-    </li>
-    <li>
-      <p>Pull the image for the {{page.release_info.version}} release of CockroachDB from <a href="https://hub.docker.com/r/{{page.release_info.docker_image}}/" class="linux-docker-step3" id="linux-docker-step3-{{page.version.version}}" data-eventcategory="linux-docker-step3">Docker Hub</a>:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="linux-docker-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code data-eventcategory="linux-docker-step3"><span class="nv language-shell linux-docker-step3" id="linux-docker-step3-{{ page.version.version }}" data-eventcategory="linux-docker-step3">$ </span>sudo docker pull {{page.release_info.docker_image}}:{{page.release_info.version}}</code></pre>
-      </div>
-    </li>
-    <li>
-      <p>Keep up-to-date with CockroachDB releases and best practices:</p>
-{% include marketo-install.html uid="2" %}
-    </li>
-  </ol>
-</div>
-
-<div id="build-from-source-linux" class="install-option">
-  <h3>Build from Source</h3>
-  <ol>
-    <li>
-      <p>Install the following prerequisites, as necessary:</p>
-
-      <table>
-        <tr>
-          <td>C++ compiler</td>
-          <td>Must support C++ 11. GCC prior to 6.0 does not work due to <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891">this issue</a>. On macOS, Xcode should suffice.</td>
-        </tr>
-        <tr>
-          <td>Go</td>
-          <td>Version 1.13.9+ is required, but 1.14 and above is not recommended. Older versions might work via <code>make build IGNORE_GOVERS=1</code>.</td>
-        </tr>
-        <tr>
-          <td>Bash</td>
-          <td>Versions 4+ are preferred, but later releases from the 3.x series are also known to work.</td>
-        </tr>
-        <tr>
-          <td>CMake</td>
-          <td>Versions 3.17.0+ are known to work.</td>
-        </tr>
-        <tr>
-          <td>Autoconf</td>
-          <td>Version 2.68 or higher is required.</td>
-        </tr>
-      </table>
-      <p>A 64-bit system is strongly recommended. Building or running CockroachDB on 32-bit systems has not been tested. You'll also need at least 2GB of RAM. If you plan to run our test suite, you'll need closer to 4GB of RAM.</p>
-    </li>
-    <li>
-      <p>Download the <a href="https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.src.tgz" class="linux-source-download" id="linux-source-download-{{page.version.version}}" data-eventcategory="linux-source-download">CockroachDB {{ page.release_info.version }} source archive</a>, and extract the sources:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="linux-source-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code data-eventcategory="linux-source-step1"><span class="nv language-shell linux-source-step1" id="linux-source-step1-{{ page.version.version }}" data-eventcategory="linux-source-step1">$ </span>curl https://binaries.cockroachdb.com/cockroach-{{page.release_info.version}}.src.tgz | tar -xz</code></pre></div>
-    </li>
-    <li><p>In the extracted directory, run <code>make build</code>:</p>
-
-      {% include copy-clipboard.html %}<div class="highlight"><pre class="highlight"><code><span class="nv language-shell"></span><span class="nb">cd </span>cockroach-{{ page.release_info.version }}</code></pre></div>
-
-      {% include copy-clipboard.html %}<div class="highlight"><pre class="highlight"><code><span class="nv language-shell"></span>make build</code></pre></div>
-
-      <p>The build process can take 10+ minutes, so please be patient.</p>
-    </li>
-    <li>
-
-    <p>Install the <code>cockroach</code> binary into <code>/usr/local/bin/</code> so it's easy to execute <a href="cockroach-commands.html">cockroach commands</a> from any directory:</p>
-
-    {% include copy-clipboard.html %}<div class="highlight"><pre class="highlight"><code><span class="nv language-shell"></span>make install</code></pre></div>
-    <p>If you get a permissions error, prefix the command with <code>sudo</code>.</p>
-
-    <p>You can also execute the <code>cockroach</code> binary directly from its built location, <code>./src/github.com/cockroachdb/cockroach/cockroach</code>, but the rest of the documentation assumes you have the binary on your <code>PATH</code>.</p>
-    </li>
-    <li>
-        <p>Keep up-to-date with CockroachDB releases and best practices:</p>
-{% include marketo-install.html uid="3" %}
-      </li>
-  </ol>
-</div>
-
-<h2 id="whats-next">What&#39;s next?</h2>
-
-{% include {{ page.version.version }}/misc/install-next-steps.html %}
-
-{% include {{ page.version.version }}/misc/diagnostics-callout.html %}
diff --git a/src/current/v20.2/install-cockroachdb-mac.md b/src/current/v20.2/install-cockroachdb-mac.md
deleted file mode 100644
index 3ac11f38bf2..00000000000
--- a/src/current/v20.2/install-cockroachdb-mac.md
+++ /dev/null
@@ -1,222 +0,0 @@
----
-title: Install CockroachDB on Mac
-summary: Install CockroachDB on Mac, Linux, or Windows. Sign up for product release notes.
-tags: download, binary, homebrew
-toc: true
-key: install-cockroachdb.html
----
-
-<div id="os-tabs" class="clearfix">
-  <button id="mac" class="current" data-eventcategory="buttonClick-doc-os" data-eventaction="mac">Mac</button>
-  <a href="install-cockroachdb-linux.html"><button id="linux" data-eventcategory="buttonClick-doc-os" data-eventaction="linux">Linux</button></a>
-  <a href="install-cockroachdb-windows.html"><button id="windows" data-eventcategory="buttonClick-doc-os" data-eventaction="windows">Windows</button></a>
-</div>
-
-<p>See <a href="../releases/{{page.version.version}}.html" class="mac-releasenotes-download" id="mac-releasenotes-download-{{page.version.version}}" data-eventcategory="mac-releasenotes-download">Release Notes</a> for what's new in the latest release, {{ page.release_info.version }}. To upgrade to this release from an older version, see <a href="upgrade-cockroach-version.html">Cluster Upgrade</a>.</p>
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-<h2>Install options</h2>
-
-Use one of the options below to install CockroachDB.
-
-<div id="download-the-binary" class="install-option">
-  <h3>Download the binary</h3>
-  <ol>
-    <li>
-      <p>Download the <a href="https://binaries.cockroachdb.com/cockroach-{{page.release_info.version}}.darwin-10.9-amd64.tgz" class="mac-binary-step1" id="mac-binary-step1-{{page.version.version}}" data-eventcategory="mac-binary-step1">CockroachDB archive</a> for OS X and the supporting libraries that are used to provide <a href="spatial-features.html">spatial features</a>, and extract the binary:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="mac-binary-step1-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code data-eventcategory="mac-binary-step1"><span class="nv language-shell mac-binary-step1" id="mac-binary-step1-{{ page.version.version }}" data-eventcategory="mac-binary-step1">$ </span>curl https://binaries.cockroachdb.com/cockroach-{{page.release_info.version}}.darwin-10.9-amd64.tgz | tar -xz</code></pre></div>
-    </li>
-    <li>
-      <p>Copy the binary into your <code>PATH</code> so you can execute <a href="cockroach-commands.html">cockroach commands</a> from any shell:</p>
-
-      {% include copy-clipboard.html %}<div class="highlight"><pre class="highlight"><code><span class="nv language-shell"></span>cp -i cockroach-{{ page.release_info.version }}.darwin-10.9-amd64/cockroach /usr/local/bin/</code></pre></div>
-      <p>If you get a permissions error, prefix the command with <code>sudo</code>.</p>
-    </li>
-    <div class="bs-callout bs-callout--info"><div class="bs-callout__label">Note:</div>
-    <p>If you plan to use CockroachDB's <a href="spatial-features.html">spatial features</a>, you must complete the following steps. Otherwise, your installation is now complete.</p>
-    </div>
-    <li>
-      <p>CockroachDB uses custom-built versions of the <a href="spatial-glossary.html#geos">GEOS</a> libraries. Copy these libraries to one of the locations where CockroachDB expects to find them.</p>
-      <p>By default, CockroachDB looks for external libraries in <code>/usr/local/lib/cockroach</code> or a <code>lib</code> subdirectory of the CockroachDB binary&#39;s current directory. If you place these libraries in another location, you must pass the location in the <a href="cockroach-start.html#flags-spatial-libs"><code>--spatial-libs</code> flag to <code>cockroach start</code></a>. The instructions below assume the <code>/usr/local/lib/cockroach</code> location.</p>
-      <ol>
-        <li><p>Create the directory where the external libraries will be stored:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell"><span class="nb">mkdir</span> <span class="nt">-p</span> /usr/local/lib/cockroach</code></pre></div>
-        </li>
-        <li><p>Copy the library files to the directory:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell"><span class="nb">cp </span>-i cockroach-{{ page.release_info.version }}.darwin-10.9-amd64/lib/libgeos.dylib /usr/local/lib/cockroach/</code></pre></div>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell"><span class="nb">cp </span>-i cockroach-{{ page.release_info.version }}.darwin-10.9-amd64/lib/libgeos_c.dylib /usr/local/lib/cockroach/</code></pre></div>
-          <p>If you get a permissions error, prefix the command with <code>sudo</code>.</p>
-        </li>
-      </ol>
-    </li>
-    <li><p>Verify that CockroachDB can execute spatial queries.</p>
-      <ol>
-        <li><p>Make sure the <code>cockroach</code> binary you just installed is the one that runs when you type <code>cockroach</code> in your shell:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell">which cockroach</code></pre></div>
-          <div class="highlight"><pre><code class="language-" data-lang="">/usr/local/bin/cockroach</code></pre></div>
-        </li>
-        <li><p>Start a temporary, in-memory cluster using <a href="cockroach-demo.html"><code>cockroach demo</code></a>:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-
-          <div class="highlight"><pre><code class="language-shell" data-lang="shell">cockroach demo</code></pre></div>
-
-        <li><p>In the demo cluster's interactive SQL shell, run the following command to test that the spatial libraries have loaded properly:</p>
-          <div class="copy-clipboard">
-            <svg id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-            <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-          </div>
-
-          <div class="highlight"><pre><code class="language-sql" data-lang="sql"><span class="o">&gt;</span><span class="k">SELECT</span> <span class="n">ST_IsValid</span><span class="p">(</span><span class="n">ST_MakePoint</span><span class="p">(</span><span class="mi">1</span><span class="p">,</span><span class="mi">2</span><span class="p">));</span></code></pre></div>
-          <p>You should see the following output:</p>
-          <div class="highlight"><pre><code class="language-" data-lang="">       st_isvalid
-    --------------
-    true
-    (1 row)</code></pre>
-          </div>
-          <p>If your <code>cockroach</code> binary is not properly accessing the dynamically linked C libraries in <code>/usr/local/lib/cockroach</code>, it will output an error message like the one below.</p>
-          <div class="highlight"><pre><code class="language-" data-lang="">ERROR: st_isvalid(): geos: error during GEOS init: geos: cannot load GEOS from dir "/usr/local/lib/cockroach": failed to execute dlopen
-          Failed running "sql"</code></pre></div>
-        </li>
-      </ol>
-    <li>
-      <p>Keep up-to-date with CockroachDB releases and best practices:</p>
-{% include marketo-install.html uid="2" %}
-    </li>
-  </ol>
-</div>
-
-<div id="use-kubernetes" class="install-option">
-  <h3>Use Kubernetes</h3>
-
-  <p>To orchestrate CockroachDB locally using <a href="https://kubernetes.io/">Kubernetes</a>, either with configuration files or the <a href="https://helm.sh/">Helm</a> package manager, see <a href="orchestrate-a-local-cluster-with-kubernetes.html">Orchestrate CockroachDB Locally with Minikube</a>.</p>
-</div>
-
-<div id="use-docker" class="install-option">
-  <h3>Use Docker</h3>
-
-  {{site.data.alerts.callout_danger}}Running a stateful application like CockroachDB in Docker is more complex and error-prone than most uses of Docker. Unless you are very experienced with Docker, we recommend starting with a different installation and deployment method.{{site.data.alerts.end}}
-
-  <ol>
-    <li>
-      <p>Install <a href="https://docs.docker.com/docker-for-mac/install/">Docker for Mac</a>. Please carefully check that you meet all prerequisites.</p>
-    </li>
-    <li>
-      <p>Confirm that the Docker daemon is running in the background:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="mac-docker-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code data-eventcategory="mac-docker-step2"><span class="nv language-shell mac-docker-step2" id="mac-docker-step2-{{ page.version.version }}" data-eventcategory="mac-docker-step2">$ </span>docker version</code></pre></div>
-      <p>If you do not see the server listed, start the <strong>Docker</strong> daemon.</p>
-    </li>
-    <li>
-      <p>Pull the image for the {{page.release_info.version}} release of CockroachDB from <a href="https://hub.docker.com/r/{{page.release_info.docker_image}}/" class="mac-docker-step3" id="mac-docker-step3-{{page.version.version}}" data-eventcategory="mac-docker-step3">Docker Hub</a>:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="mac-docker-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code data-eventcategory="mac-docker-step3"><span class="nv language-shell mac-docker-step3" id="mac-docker-step3-{{ page.version.version }}" data-eventcategory="mac-docker-step3">$ </span>docker pull {{page.release_info.docker_image}}:{{page.release_info.version}}</code></pre>
-      </div>
-    </li>
-    <li>
-      <p>Keep up-to-date with CockroachDB releases and best practices:</p>
-{% include marketo-install.html uid="3" %}
-    </li>
-  </ol>
-</div>
-
-<div id="build-from-source" class="install-option">
-  <h3>Build from source</h3>
-  <ol>
-    <li>
-      <p>Install the following prerequisites, as necessary:</p>
-
-      <table>
-        <tr>
-          <td>C++ compiler</td>
-          <td>Must support C++ 11. GCC prior to 6.0 does not work due to <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891">this issue</a>. On macOS, Xcode should suffice.</td>
-        </tr>
-        <tr>
-          <td>Go</td>
-          <td>Version 1.13.9+ is required, but 1.14 and above is not recommended. Older versions might work via <code>make build IGNORE_GOVERS=1</code>.</td>
-        </tr>
-        <tr>
-          <td>Bash</td>
-          <td>Versions 4+ are preferred, but later releases from the 3.x series are also known to work.</td>
-        </tr>
-        <tr>
-          <td>CMake</td>
-          <td>Versions 3.17.0+ are known to work.</td>
-        </tr>
-        <tr>
-          <td>Autoconf</td>
-          <td>Version 2.68 or higher is required.</td>
-        </tr>
-      </table>
-      <p>A 64-bit system is strongly recommended. Building or running CockroachDB on 32-bit systems has not been tested. You'll also need at least 2GB of RAM. If you plan to run our test suite, you'll need closer to 4GB of RAM.</p>
-    </li>
-    <li>
-      <p>Download the <a href="https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.src.tgz" class="mac-source-download" id="mac-source-download-{{page.version.version}}" data-eventcategory="mac-source-download">CockroachDB {{ page.release_info.version }} source archive</a>, and extract the sources:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="mac-source-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code data-eventcategory="mac-source-download"><span class="nv language-shell mac-source-download" id="mac-source-download-{{ page.version.version }}" data-eventcategory="mac-source-download">$ </span>curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.src.tgz | tar -xz</code></pre></div>
-    </li>
-    <li><p>In the extracted directory, run <code>make build</code>:</p>
-
-      {% include copy-clipboard.html %}<div class="highlight"><pre class="highlight"><code><span class="nv language-shell"></span><span class="nb">cd </span>cockroach-{{ page.release_info.version }}</code></pre></div>
-
-      {% include copy-clipboard.html %}<div class="highlight"><pre class="highlight"><code><span class="nv language-shell"></span>make build</code></pre></div>
-
-      <p>The build process can take 10+ minutes, so please be patient.</p>
-    </li>
-    <li>
-    <p>Install the <code>cockroach</code> binary into <code>/usr/local/bin/</code> so it's easy to execute <a href="cockroach-commands.html"><code>cockroach</code> commands</a> from any directory:</p>
-
-    {% include copy-clipboard.html %}<div class="highlight"><pre class="highlight"><code><span class="nv language-shell"></span>make install</code></pre></div>
-    <p>If you get a permissions error, prefix the command with <code>sudo</code>.</p>
-
-    <p>You can also execute the <code>cockroach</code> binary directly from its built location, <code>./src/github.com/cockroachdb/cockroach/cockroach</code>, but the rest of the documentation assumes you have the binary on your <code>PATH</code>.</p>
-    </li>
-    <li>
-      <p>Keep up-to-date with CockroachDB releases and best practices:</p>
-{% include marketo-install.html uid="4" %}
-    </li>
-  </ol>
-</div>
-
-<h2 id="whats-next">What&#39;s next?</h2>
-
-{% include {{ page.version.version }}/misc/install-next-steps.html %}
-
-{% include {{ page.version.version }}/misc/diagnostics-callout.html %}
diff --git a/src/current/v20.2/install-cockroachdb-windows.md b/src/current/v20.2/install-cockroachdb-windows.md
deleted file mode 100644
index 3600135f21d..00000000000
--- a/src/current/v20.2/install-cockroachdb-windows.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: Install CockroachDB on Windows
-summary: Install CockroachDB on Mac, Linux, or Windows. Sign up for product release notes.
-tags: download, binary, homebrew
-toc: true
-key: install-cockroachdb.html
----
-
-<div id="os-tabs" class="clearfix">
-    <a href="install-cockroachdb-mac.html"><button id="mac" data-eventcategory="buttonClick-doc-os" data-eventaction="mac">Mac</button></a>
-    <a href="install-cockroachdb-linux.html"><button id="linux" data-eventcategory="buttonClick-doc-os" data-eventaction="linux">Linux</button></a>
-    <button id="windows" class="current" data-eventcategory="buttonClick-doc-os" data-eventaction="windows">Windows</button>
-</div>
-
-<p>See <a href="../releases/{{page.version.version}}.html" class="mac-releasenotes-download" id="mac-releasenotes-download-{{page.version.version}}" data-eventcategory="mac-releasenotes-download">Release Notes</a> for what's new in the latest release, {{ page.release_info.version }}. To upgrade to this release from an older version, see <a href="upgrade-cockroach-version.html">Cluster Upgrade</a>.</p>
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-<h2>Install options</h2>
-
-Use one of the options below to install CockroachDB.
-
-<div id="download-the-binary-windows" class="install-option">
-  <h3>Download the executable</h3>
-
-  {% include windows_warning.md %}
-
-  <ol>
-    <li>
-      <p>Download and extract the <a href="https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.windows-6.2-amd64.zip" class="windows-binary-download" id="windows-binary-download-{{page.version.version}}" data-eventcategory="windows-binary-download">CockroachDB {{ page.release_info.version }} archive for Windows</a>.</p>
-    </li>
-    <li>
-      <p>To ensure that CockroachDB can use location-based names as time zone identifiers, download Go's official <a href="https://github.com/golang/go/raw/master/lib/time/zoneinfo.zip">zoneinfo.zip</a> and <a href="https://www.techjunkie.com/environment-variables-windows-10/">set the <code>ZONEINFO</code> environment variable</a> to point to the zip file.</p>
-    </li>
-    <li>
-      <p>Open PowerShell, navigate to the directory containing the executable, and make sure it works:</p>
-      <div class="copy-clipboard">
-        <svg data-eventcategory="windows-binary-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code><span class="nb">PS </span>C:\cockroach-{{ page.release_info.version }}.windows-6.2-amd64> .\cockroach.exe version</code></pre></div>
-    </li>
-    <li>
-      <p>Keep up-to-date with CockroachDB releases and best practices:</p>
-{% include marketo-install.html uid="1" %}
-    </li>
-  </ol>
-</div>
-
-<div id="use-kubernetes" class="install-option">
-  <h3>Use Kubernetes</h3>
-
-  <p>To orchestrate CockroachDB locally using <a href="https://kubernetes.io/">Kubernetes</a>, either with configuration files or the <a href="https://helm.sh/">Helm</a> package manager, see <a href="orchestrate-a-local-cluster-with-kubernetes.html">Orchestrate CockroachDB Locally with Minikube</a>.</p>
-</div>
-
-<div id="use-docker-windows" class="install-option">
-  <h3>Use Docker</h3>
-
-  {{site.data.alerts.callout_danger}}Running a stateful application like CockroachDB in Docker is more complex and error-prone than most uses of Docker. Unless you are very experienced with Docker, we recommend starting with a different installation and deployment method.{{site.data.alerts.end}}
-
-  <ol>
-    <li>
-      <p>Install <a href="https://docs.docker.com/docker-for-windows/install/">Docker for Windows</a>.</p>
-      <div class="bs-callout bs-callout-info">Docker for Windows requires 64bit Windows 10 Pro and Microsoft Hyper-V. Please see the <a href="https://docs.docker.com/docker-for-windows/install/#what-to-know-before-you-install">official documentation</a> for more details. Note that if your system does not satisfy the stated requirements, you can try using <a href="https://docs.docker.com/toolbox/overview/">Docker Toolbox</a>.</div>
-    </li>
-    <li>
-      <p>Open PowerShell and confirm that the Docker daemon is running in the background:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="windows-docker-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code><span class="nb">PS </span>C:\Users\username&gt; docker version</code></pre></div>
-
-      <p>If you do not see the server listed, start <strong>Docker for Windows</strong>.</p>
-    </li>
-    <li>
-      <p><a href="https://docs.docker.com/docker-for-windows/#/shared-drives">Share your local drives</a>. This makes it possible to mount local directories as data volumes to persist node data after containers are stopped or deleted.</p>
-    </li>
-    <li>
-      <p>Pull the image for the {{page.release_info.version}} release of CockroachDB from <a href="https://hub.docker.com/r/{{page.release_info.docker_image}}/" class="win-docker-step3" id="win-docker-step3-{{page.version.version}}" data-eventcategory="win-docker-step3">Docker Hub</a>:</p>
-
-      <div class="copy-clipboard">
-        <svg data-eventcategory="windows-docker-button" id="copy-icon" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 12"><style>.st0{fill:#A2A2A2;}</style><title>icon/buttons/copy</title><g id="Mask"><path id="path-1_1_" class="st0" d="M4.9 4.9v6h6v-6h-6zM3.8 3.8H12V12H3.8V3.8zM2.7 7.1v1.1H.1S0 5.5 0 0h8.2v2.7H7.1V1.1h-6v6h1.6z"/></g></svg>
-        <svg id="copy-check" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 12 10"><style>.st1{fill:#54B30E;}</style><path id="path-1_2_" class="st1" d="M3.8 9.1c-.3 0-.5-.1-.6-.2L.3 6C0 5.7-.1 5.2.2 4.8c.3-.4.9-.4 1.3-.1L3.8 7 10.6.2c.3-.3.9-.4 1.2 0 .3.3.3.9 0 1.2L4.4 8.9c-.2.1-.4.2-.6.2z"/></svg>
-      </div>
-      <div class="highlight"><pre class="highlight"><code data-eventcategory="win-docker-step3"><span class="nb win-docker-step3" id="win-docker-step3-{{ page.version.version }}" data-eventcategory="win-docker-step3">PS </span>C:\Users\username&gt; docker pull {{page.release_info.docker_image}}:{{page.release_info.version}}</code></pre></div>
-    </li>
-    <li>
-      <p>Keep up-to-date with CockroachDB releases and best practices:</p>
-{% include marketo-install.html uid="2" %}
-    </li>
-  </ol>
-</div>
-
-<h2 id="whats-next">What&#39;s next?</h2>
-
-{% include {{ page.version.version }}/misc/install-next-steps.html %}
-
-{% include {{ page.version.version }}/misc/diagnostics-callout.html %}
diff --git a/src/current/v20.2/install-cockroachdb.md b/src/current/v20.2/install-cockroachdb.md
deleted file mode 100644
index 6e742bb3164..00000000000
--- a/src/current/v20.2/install-cockroachdb.md
+++ /dev/null
@@ -1,19 +0,0 @@
----
-title: Install CockroachDB
-summary: Install CockroachDB on Mac, Linux, or Windows. Sign up for product release notes.
-toc: false
-feedback: false
----
-
-<script>
-$(document).ready(function(){
-    // Detect OS and redirect to corresponding install page by default.
-    if (navigator.userAgent.indexOf("Linux") !== -1) {
-        location = 'install-cockroachdb-linux.html';
-    } else if (navigator.userAgent.indexOf("Win") !== -1) {
-        location = 'install-cockroachdb-windows.html';
-    } else {
-        location = 'install-cockroachdb-mac.html';
-    }
-});
-</script>
diff --git a/src/current/v20.2/int.md b/src/current/v20.2/int.md
deleted file mode 100644
index 0ccd0d4b4b3..00000000000
--- a/src/current/v20.2/int.md
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: INT
-summary: CockroachDB supports various signed integer data types.
-toc: true
----
-
-CockroachDB supports various signed integer [data types](data-types.html).
-
-{{site.data.alerts.callout_info}}
-For instructions showing how to auto-generate integer values (e.g., to auto-number rows in a table), see [this FAQ entry](sql-faqs.html#how-do-i-auto-generate-unique-row-ids-in-cockroachdb).
-{{site.data.alerts.end}}
-
-## Names and Aliases
-
-| Name   | Allowed Width | Aliases                                          | Range                                        |
-|--------+---------------+--------------------------------------------------+----------------------------------------------|
-| `INT`  | 64-bit        | `INTEGER`<br />`INT8`<br />`INT64`<br />`BIGINT` | -9223372036854775807 to +9223372036854775807 |
-| `INT2` | 16-bit        | `SMALLINT`                                       | -32768 to +32767                             |
-| `INT4` | 32-bit        | None                                             | -2147483648 to +2147483647                   |
-| `INT8` | 64-bit        | `INT`                                            | -9223372036854775807 to +9223372036854775807 |
-
-## Syntax
-
-A constant value of type `INT` can be entered as a [numeric literal](sql-constants.html#numeric-literals).
-For example: `42`, `-1234`, or `0xCAFE`.
-
-## Size
-
-The different integer types place different constraints on the range of allowable values, but all integers are stored in the same way regardless of type. Smaller values take up less space than larger ones (based on the numeric value, not the data type).
-
-### Considerations for 64-bit signed integers
-
-By default, `INT` is an alias for `INT8`, which creates 64-bit signed integers. This differs from the Postgres default for `INT`, [which is 32 bits](https://www.postgresql.org/docs/9.6/datatype-numeric.html), and may cause issues for your application if it is not written to handle 64-bit integers, whether due to the language your application is written in, or the ORM/framework it uses to generate SQL (if any).
-
-For example, JavaScript language runtimes represent numbers as 64-bit floats, which means that the JS runtime [can only represent 53 bits of numeric accuracy](http://2ality.com/2012/04/number-encoding.html) and thus has a max safe value of 2<sup>53</sup>, or 9007199254740992.  This means that the maximum size of a default `INT` in CockroachDB is much larger than JavaScript can represent as an integer. Visually, the size difference is as follows:
-
-```
-9223372036854775807 # INT default max value
-   9007199254740991 # JS integer max value
-```
-
-Given the above, if a table contains a column with a default-sized `INT` value, and you are reading from it or writing to it via JavaScript, you will not be able to read and write values to that column correctly. This issue can pop up in a surprising way if you are using a framework that autogenerates both frontend and backend code (such as [twirp](https://github.com/twitchtv/twirp)). In such cases, you may find that your backend code can handle 64-bit signed integers, but the generated client/frontend code cannot.
-
-If your application needs to use an integer size that is different than the CockroachDB default (for these or other reasons), you can change one or both of the settings below. For example, you can set either of the below to `4` to cause `INT` and `SERIAL` to become aliases for `INT4` and `SERIAL4`, which use 32-bit integers.
-
-1. The `default_int_size` [session variable](set-vars.html).
-2. The `sql.defaults.default_int_size` [cluster setting](cluster-settings.html).
-
-{{site.data.alerts.callout_success}}
-If your application requires arbitrary precision numbers, use the [`DECIMAL`](decimal.html) data type.
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE ints (a INT PRIMARY KEY, b SMALLINT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM ints;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  a           | INT8      |    false    | NULL           |                       | {primary} |   false
-  b           | INT2      |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO ints VALUES (1, 32);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM ints;
-~~~
-
-~~~
-  a | b
-----+-----
-  1 | 32
-(1 row)
-~~~
-
-## Supported casting and conversion
-
-`INT` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`DECIMAL` | ––
-`FLOAT` | Loses precision if the `INT` value is larger than 2^53 in magnitude.
-`BIT` | Converts to the binary representation of the integer value. If the value is negative, the sign bit is replicated on the left to fill the entire bit array.
-`BOOL` | **0** converts to `false`; all other values convert to `true`.
-`DATE` | Converts to days since the Unix epoch (Jan. 1, 1970).
-`TIMESTAMP` | Converts to seconds since the Unix epoch (Jan. 1, 1970).
-`INTERVAL` | Converts to seconds.
-`STRING` | ––
-
-## See also
-
-- [Data Types](data-types.html)
-- [`FLOAT`](float.html)
-- [`DECIMAL`](decimal.html)
diff --git a/src/current/v20.2/intellij-idea.md b/src/current/v20.2/intellij-idea.md
deleted file mode 100644
index 34a045b49a3..00000000000
--- a/src/current/v20.2/intellij-idea.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: Use IntelliJ IDEA with CockroachDB
-summary: Learn how to use IntelliJ IDEA with a CockroachDB cluster.
-toc: true
----
-
-You can use CockroachDB in [IntelliJ IDEA](https://www.jetbrains.com/idea/) as a [database data source](https://www.jetbrains.com/help/idea/managing-data-sources.html#data_sources), which lets you accomplish tasks like managing your database's schema from within your IDE.
-
-## Support
-
-As of CockroachDB {{page.version.version}}, IntelliJ IDEA only has **partial support**. This means that the application is mostly functional, but its integration still has a few rough edges.
-
-### Versions
-
-The level of support in this document was tested as of the following versions:
-
-- CockroachDB v19.1.0-beta.20190225
-- IntelliJ IDEA Ultimate 18.1.3
-- PostgreSQL JDBC 41.1
-
-{{site.data.alerts.callout_info}}
-This feature should also work with other JetBrains IDEs, such as PyCharm, but Cockroach Labs has not yet tested its integration.
-{{site.data.alerts.end}}
-
-### Warnings & Errors
-
-Users can expect to encounter the following behaviors when using CockroachDB within IntelliJ IDEA.
-
-- **Warnings** do not require any action on the user's end and can be ignored. Note that even if a message indicates that it is an "error", it can still be treated as a warning by this definition.
-- **Errors** require the user to take action to resolve the problem and cannot be ignored.
-
-#### Warnings
-
-##### [XXUUU] ERROR: could not decorrelate subquery...
-
-<img src="{{ 'images/v2.1/intellij/XX000_error_could_not_decorrelate_subquery.png' | relative_url }}" alt="DBeaver - Select CockroachDB" style="border:1px solid #eee;max-width:100%" />
-
-Displays once per load of schema.
-
-<hr/>
-
-##### [42883] ERROR: unknown function: pg_function_is_visible() Failed to retrieve...
-
-<img src="{{ 'images/v2.1/intellij/42883_error_pg_function_is_visible.png' | relative_url }}" alt="DBeaver - Select CockroachDB" style="border:1px solid #eee;max-width:100%" />
-
-Display periodically. Does not impact functionality.
-
-#### Errors
-
-##### [42703] org.postgresql.util.PSQLException: ERROR: column "n.xmin" does not exist
-
-<img src="{{ 'images/v2.1/intellij/42073_error_column_n_xmin_does_not_exist.png' | relative_url }}" alt="DBeaver - Select CockroachDB" style="border:1px solid #eee;max-width:100%" />
-
-Requires setting **Introspect using JDBC metadata** ([details below](#set-cockroachdb-as-a-data-source-in-intellij)).
-
-<hr/>
-
-## Set CockroachDB as a Data Source in IntelliJ
-
-1. Launch the **Database** tool window. (**View** > **Tool Windows** > **Database**) <img src="{{ 'images/v2.1/intellij/01_database_tool_window.png' | relative_url }}" alt="DBeaver - Select CockroachDB" style="border:1px solid #eee;max-width:100%" />
-1. Add a PostgreSQL data source. (**New (+)** > **Data Source** > **PostgreSQL**)<img src="{{ 'images/v2.1/intellij/02_postgresql_data_source.png' | relative_url }}" alt="DBeaver - Select CockroachDB" style="border:1px solid #eee;max-width:100%" />
-1. On the **General** tab, enter your database's connection string:
-
-	Field | Value
-	------|-------
-	**Host** | Your CockroachDB cluster's hostname
-	**Port** | Your CockroachDB cluster's port. By default, CockroachDB uses port **26257**.
-	**Database** | The database you want to connect to. Note that CockroachDB's notion of database differs from PostgreSQL's; you can see your cluster's databases through the [`SHOW DATABASES`](show-databases.html) command.
-	**User** | The user to connect as. By default, you can use **root**.
-	**Password** | If your cluster uses password authentication, enter the password.
-	**Driver** | Select or install **PostgreSQL** using a version greater than or equal to 41.1. (Older drivers have not been tested.)
-
-	<img src="{{ 'images/v2.1/intellij/03_general_tab.png' | relative_url }}" alt="DBeaver - Select CockroachDB" style="border:1px solid #eee;max-width:100%" />
-1. Install or select a **PostgreSQL** driver. We recommend a version greater than or equal to 41.1.
-1. If your cluster uses SSL authentication, go to the **SSH/SSL** tab, select **Use SSL** and provide the location of your certificate files.
-1. Go to the **Options** tab, and then select **Introspect using JDBC metadata**.<img src="{{ 'images/v2.1/intellij/04_options_tab.png' | relative_url }}" alt="DBeaver - Select CockroachDB" style="border:1px solid #eee;max-width:100%" />
-1. Click **OK**.
-
-You can now use IntelliJ's [database tool window](https://www.jetbrains.com/help/idea/working-with-the-database-tool-window.html) to interact with your CockroachDB cluster.
-
-## Report Issues with IntelliJ IDEA & CockroachDB
-
-If you encounter issues other than those outlined above, please [file an issue on the `cockroachdb/cockroach` GitHub repo](https://github.com/cockroachdb/cockroach/issues/new?template=bug_report.md), including the following details about the environment where you encountered the issue:
-
-- CockroachDB version ([`cockroach version`](cockroach-version.html))
-- IntelliJ IDEA version
-- Operating system
-- Steps to reproduce the behavior
-- If possible, a trace of the SQL statements sent to CockroachDB while the error is being reproduced using [SQL query logging](query-behavior-troubleshooting.html#sql-logging).
-
-## See Also
-
-+ [Client connection parameters](connection-parameters.html)
-+ [Third-Party Database Tools](third-party-database-tools.html)
diff --git a/src/current/v20.2/interleave-in-parent.md b/src/current/v20.2/interleave-in-parent.md
deleted file mode 100644
index f47adfe5ac1..00000000000
--- a/src/current/v20.2/interleave-in-parent.md
+++ /dev/null
@@ -1,239 +0,0 @@
----
-title: INTERLEAVE IN PARENT
-summary: Interleaving tables improves query performance by optimizing the key-value structure of closely related table's data.
-toc: true
-toc_not_nested: true
----
-
-{{site.data.alerts.callout_danger}}
-`INTERLEAVE IN PARENT` was deprecated in CockroachDB v20.2, disabled by default in v21.1, and permanently removed in v21.2. We do not recommend interleaving tables or indexes in new clusters.
-
-For details, see [Deprecation](#deprecation).
-{{site.data.alerts.end}}
-
-## How interleaved tables work
-
-When tables are interleaved, data written to one table (known as the **child**) is inserted directly into another (known as the **parent**) in the key-value store. This is accomplished by matching the child table's Primary Key to the parent's.
-
-### Interleave prefix
-
-For interleaved tables to have Primary Keys that can be matched, the child table must use the parent table's entire Primary Key as a prefix of its own Primary Key––these matching columns are referred to as the **interleave prefix**. It's easiest to think of these columns as representing the same data, which is usually implemented with Foreign Keys.
-
-{{site.data.alerts.callout_success}}To formally enforce the relationship between each table's interleave prefix columns, we recommend using <a href="foreign-key.html">Foreign Key constraints</a>.{{site.data.alerts.end}}
-
-For example, if you want to interleave `orders` into `customers` and the Primary Key of customers is `id`, you need to create a column representing `customers.id` as the first column in the Primary Key of `orders`&mdash;e.g., with a column called `customer`. So the data representing `customers.id` is the interleave prefix, which exists in the `orders` table as the `customer` column.
-
-### Key-value structure
-
-When you write data into the child table, it is inserted into the key-value store immediately after the parent table's key matching the interleave prefix.
-
-For example, if you interleave `orders` into `customers`, the `orders` data is written directly within the `customers` table in the key-value store. The following is a crude, illustrative example of what the keys would look like in this structure:
-
-~~~
-/customers/1
-/customers/1/orders/1000
-/customers/1/orders/1002
-/customers/2
-/customers/2/orders/1001
-/customers/2/orders/1003
-...
-/customers/n/
-/customers/n/orders/<order belonging to n>
-~~~
-
-By writing data in this way, related data is more likely to remain on the same key-value range, which can make it much faster to read from and write to. Using the above example, all of customer 1's data is going to be written to the same range, including its representation in both the `customers` and `orders` tables.
-
-### Interleaved hierarchy
-
-Interleaved tables typically work best when the tables form a hierarchy. For example, you could interleave the table `orders` (as the child) into the table `customers` (as the parent, which represents the people who placed the orders). You can extend this example by also interleaving the tables `invoices` (as a child) and `packages` (as a child) into `orders` (as the parent).
-
-The entire set of these relationships is referred to as the **interleaved hierarchy**, which contains all of the tables related through [interleave prefixes](#interleave-prefix).
-
-## Syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/interleave.html %}
-</div>
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `CREATE TABLE ...` | For help with this section of the syntax, [`CREATE TABLE`](create-table.html).
- `opt_persistence_temp_table` |  Defines the table as a session-scoped temporary table. For more information, see [Temporary Tables](temporary-tables.html).<br><br>Note that the `LOCAL`, `GLOBAL`, and `UNLOGGED` options are no-ops, allowed by the parser for PostgresSQL compatibility.<br><br>**Support for temporary tables is [experimental](experimental-features.html#temporary-objects)**.
- `INTERLEAVE IN PARENT table_name` | The name of the parent table you want to interleave the new child table into.
- `name_list` | A comma-separated list of columns from the child table's Primary Key that represent the parent table's Primary Key (i.e., the interleave prefix).
- `opt_partition_by` | An [Enterprise-only](enterprise-licensing.html) option that lets you define table partitions at the row level. You can define table partitions by list or by range. See [Define Table Partitions](partitioning.html) for more information.
- `WITH storage_parameter` | <span class="version-tag">New in v20.2:</span> A comma-separated list of [spatial index tuning parameters](spatial-indexes.html#index-tuning-parameters). Supported parameters include `fillfactor`, `s2_max_level`, `s2_level_mod`, `s2_max_cells`, `geometry_min_x`, `geometry_max_x`, `geometry_min_y`, and `geometry_max_y`. The `fillfactor` parameter is a no-op, allowed for PostgreSQL-compatibility.<br><br>For details, see [Spatial index tuning parameters](spatial-indexes.html#index-tuning-parameters). For an example, see [Create a spatial index that uses all of the tuning parameters](spatial-indexes.html#create-a-spatial-index-that-uses-all-of-the-tuning-parameters).
- `ON COMMIT PRESERVE ROWS` | This clause is a no-op, allowed by the parser for PostgresSQL compatibility. CockroachDB only supports session-scoped [temporary tables](temporary-tables.html), and does not support the clauses `ON COMMIT DELETE ROWS` and `ON COMMIT DROP`, which are used to define transaction-scoped temporary tables in PostgreSQL.
-
-## Deprecation
-
-Interleaving tables and indexes is deprecated in CockroachDB v20.2 for the following reasons:
-
-- Scans over tables or indexes with interleaved, child objects (i.e., interleaved tables or indexes) are much slower than scans over tables and indexes with no child objects, as the scans must traverse the parent object and all of its child objects.
-- Database schema changes are slower for interleaved objects and their parents than they are for non-interleaved objects and objects with no interleaved children. For example, if you add or remove a column to a parent or child table, CockroachDB must rewrite the entire interleaved hierarchy for that table and its parents/children.
-- [Internal benchmarks](https://github.com/cockroachdb/cockroach/issues/53455) have shown the performance benefits of interleaving tables and indexes are limited to a small number of use cases.
-
-For more details, see the [GitHub tracking issue](https://github.com/cockroachdb/cockroach/issues/52009).
-
-After [upgrading to v20.2](upgrade-cockroach-version.html), we recommend that you do the following:
-
-- [Convert any existing interleaved tables to non-interleaved tables](#convert-interleaved-tables).
-- [Replace any existing interleaved secondary indexes with non-interleaved indexes](#replace-interleaved-indexes).
-
-{{site.data.alerts.callout_success}}
-Test your [schema changes](online-schema-changes.html) in a non-production environment before implementing them in production.
-{{site.data.alerts.end}}
-
-### Convert interleaved tables
-
-To convert an interleaved table to a non-interleaved table, issue an [`ALTER PRIMARY KEY`](alter-primary-key.html) statement on the table, specifying the existing primary key column(s) for the table, and no `INTERLEAVE IN PARENT` clause.
-
-When converting interleaved tables with `ALTER PRIMARY KEY`, note the following:
-
-- CockroachDB executes `ALTER PRIMARY KEY` statements as [online schema changes](online-schema-changes.html). This means that you can convert your interleaved tables to non-interleaved tables without experiencing any downtime.
-- `ALTER PRIMARY KEY` statements can only convert a child table if that table is not a parent. If your cluster has child tables that are also parents, you must start from the bottom of the interleaving hierarchy and work your way up (i.e., start with child tables that are not parents).
-
-For example, suppose you created an interleaved hierarchy between the `customers`, `orders`, and `packages` tables, using the following [`CREATE TABLE`](create-table.html) statements:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers (
-    id INT PRIMARY KEY,
-    name STRING(50)
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders (
-    customer INT,
-    id INT,
-    total DECIMAL(20, 5),
-    PRIMARY KEY (customer, id),
-    CONSTRAINT fk_customer FOREIGN KEY (customer) REFERENCES customers
-  ) INTERLEAVE IN PARENT customers (customer);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE packages (
-    customer INT,
-    "order" INT,
-    id INT,
-    address STRING(50),
-    delivered BOOL,
-    delivery_date DATE,
-    PRIMARY KEY (customer, "order", id),
-    CONSTRAINT fk_order FOREIGN KEY (customer, "order") REFERENCES orders
-  ) INTERLEAVE IN PARENT orders (customer, "order");
-~~~
-
-The `INTERLEAVE IN PARENT` clauses will appear in `SHOW CREATE` statements for the `packages` and `orders` tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE orders;
-~~~
-
-~~~
-  table_name |                                  create_statement
--------------+-------------------------------------------------------------------------------------
-  orders     | CREATE TABLE public.orders (
-             |     customer INT8 NOT NULL,
-             |     id INT8 NOT NULL,
-             |     total DECIMAL(20,5) NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (customer ASC, id ASC),
-             |     CONSTRAINT fk_customer FOREIGN KEY (customer) REFERENCES public.customers(id),
-             |     FAMILY "primary" (customer, id, total)
-             | ) INTERLEAVE IN PARENT public.customers (customer)
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE packages;
-~~~
-
-~~~
-  table_name |                                        create_statement
--------------+--------------------------------------------------------------------------------------------------
-  packages   | CREATE TABLE public.packages (
-             |     customer INT8 NOT NULL,
-             |     "order" INT8 NOT NULL,
-             |     id INT8 NOT NULL,
-             |     address STRING(50) NULL,
-             |     delivered BOOL NULL,
-             |     delivery_date DATE NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (customer ASC, "order" ASC, id ASC),
-             |     CONSTRAINT fk_order FOREIGN KEY (customer, "order") REFERENCES public.orders(customer, id),
-             |     FAMILY "primary" (customer, "order", id, address, delivered, delivery_date)
-             | ) INTERLEAVE IN PARENT public.orders (customer, "order")
-(1 row)
-~~~
-
-To convert these tables to non-interleaved tables, use `ALTER PRIMARY KEY` statements, starting at the bottom of the hierarchy (i.e., with `packages`):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE packages ALTER PRIMARY KEY USING COLUMNS (customer, "order", id);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE orders ALTER PRIMARY KEY USING COLUMNS (customer, id);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE orders;
-~~~
-
-~~~
-  table_name |                                  create_statement
--------------+-------------------------------------------------------------------------------------
-  orders     | CREATE TABLE public.orders (
-             |     customer INT8 NOT NULL,
-             |     id INT8 NOT NULL,
-             |     total DECIMAL(20,5) NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (customer ASC, id ASC),
-             |     CONSTRAINT fk_customer FOREIGN KEY (customer) REFERENCES public.customers(id),
-             |     UNIQUE INDEX orders_customer_id_key (customer ASC, id ASC),
-             |     FAMILY "primary" (customer, id, total)
-             | )
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE packages;
-~~~
-
-~~~
-  table_name |                                        create_statement
--------------+--------------------------------------------------------------------------------------------------
-  packages   | CREATE TABLE public.packages (
-             |     customer INT8 NOT NULL,
-             |     "order" INT8 NOT NULL,
-             |     id INT8 NOT NULL,
-             |     address STRING(50) NULL,
-             |     delivered BOOL NULL,
-             |     delivery_date DATE NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (customer ASC, "order" ASC, id ASC),
-             |     CONSTRAINT fk_order FOREIGN KEY (customer, "order") REFERENCES public.orders(customer, id),
-             |     UNIQUE INDEX packages_customer_order_id_key (customer ASC, "order" ASC, id ASC),
-             |     FAMILY "primary" (customer, "order", id, address, delivered, delivery_date)
-             | )
-(1 row)
-~~~
-
-### Replace interleaved indexes
-
-Interleaved [secondary indexes](indexes.html) cannot be converted to non-interleaved indexes. You must [drop the existing index](drop-index.html), and then [create a new index](create-index.html) without an `INTERLEAVE IN PARENT` clause.
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [Foreign Keys](foreign-key.html)
-- [Column Families](column-families.html)
diff --git a/src/current/v20.2/internal/version-switcher-page-data.json b/src/current/v20.2/internal/version-switcher-page-data.json
deleted file mode 100644
index db943397882..00000000000
--- a/src/current/v20.2/internal/version-switcher-page-data.json
+++ /dev/null
@@ -1,17 +0,0 @@
----
-layout: none
----
-
-{% capture page_folder %}/{{ page.version.version }}/{% endcapture %}
-{% assign pages = site.pages | where_exp: "pages", "pages.url contains page_folder" | where_exp: "pages", "pages.name != '404.md'" %}
-{
-{%- for x in pages -%}
-{%- assign key = x.url | replace: page_folder, "" -%}
-{%- if x.key -%}
-    {%- assign key = x.key -%}
-{%- endif %}
-  {{ key | jsonify }}: {
-    "url": {{ x.url | jsonify }}
-  }{% unless forloop.last %},{% endunless -%}
-{% endfor %}
-}
\ No newline at end of file
diff --git a/src/current/v20.2/interval.md b/src/current/v20.2/interval.md
deleted file mode 100644
index 2fda31e9c46..00000000000
--- a/src/current/v20.2/interval.md
+++ /dev/null
@@ -1,130 +0,0 @@
----
-title: INTERVAL
-summary: The INTERVAL data type stores a value that represents a span of time.
-toc: true
----
-
-The `INTERVAL` [data type](data-types.html) stores a value that represents a span of time.
-
-## Aliases
-
-CockroachDB supports using uninterpreted [string literals](sql-constants.html#string-literals) in contexts where an `INTERVAL` value is otherwise expected.
-
-## Syntax
-
-A constant value of type `INTERVAL` can be expressed using an
-[interpreted literal](sql-constants.html#interpreted-literals), or a
-string literal
-[annotated with](scalar-expressions.html#explicitly-typed-expressions)
-type `INTERVAL` or
-[coerced to](scalar-expressions.html#explicit-type-coercions) type
-`INTERVAL`.
-
-`INTERVAL` constants can be expressed using the following formats:
-
-Format | Description
--------|--------
-SQL Standard | `INTERVAL 'Y-M D H:M:S'`<br><br>Seconds and days can be expressed as integers or floats. All other input values must be expressed as integers.<br><br>For more details, see [Details on SQL Standard input](#details-on-sql-standard-input).
-ISO 8601 | `INTERVAL 'P1Y2M3DT4H5M6S'`
-Traditional PostgreSQL | `INTERVAL '1 year 2 months 3 days 4 hours 5 minutes 6 seconds'`
-Abbreviated PostgreSQL | `INTERVAL '1 yr 2 mons 3 d 4 hrs 5 mins 6 secs'`
-
-CockroachDB also supports using uninterpreted
-[string literals](sql-constants.html#string-literals) in contexts
-where an `INTERVAL` value is otherwise expected.
-
-### Details on SQL Standard input
-
-Without a [precision](#precision) or [duration field](#duration-fields) specified, expect the following behavior from SQL Standard input (`Y-M D H:M:S`):
-
-- Using a single value defines seconds only.
-  <br>For example, `INTERVAL '1'` is parsed as `00:00:01`.
-- Using two colon-separated integers defines hours and minutes.
-  <br>For example, `INTERVAL '1:2'` is parsed as `01:02:00`.
-- If the second of two colon-separated values is a float, the interval is parsed as minutes and seconds (`M:S.fff`).
-  <br>For example, `INTERVAL '1:2.345'` is parsed as `00:01:02.345`.
-- If the first element of the input directly preceding a colon is specified as a float, the interval is parsed as `D H:M`.
-  <br>For example, `INTERVAL '1.2:03:04'` is parsed as `1 day 07:52:00`.
-- If the day is omitted, no day value will be stored.
-  <br>For example, `INTERVAL '1-2 3:4:5'` is parsed as `1 year 2 mons 03:04:05`, and `INTERVAL 1-2` is parsed as `1 year 2 mons`.
-- If the year and month are omitted, no year or month value will be stored.
-  <br>For example, `INTERVAL '1 2:3:4` is parsed as `1 day 02:03:04`.
-
-## Size
-
-An `INTERVAL` column supports values up to 24 bytes in width, but the total storage size is likely to be larger due to CockroachDB metadata. Intervals are stored internally as months, days, and microseconds.
-
-## Precision
-
- CockroachDB supports precision levels from 0 (seconds) to 6 (microseconds) for `INTERVAL` values. Precision in time values specifies the number of fractional digits retained in the seconds field.  By default, `INTERVAL` values have a precision of 6 (microseconds).
-
-For example, specifying an `INTERVAL` value as `INTERVAL(3)` truncates the time precision to milliseconds.
-
-## Duration fields
-
- CockroachDB supports duration fields for `INTERVAL` values. You can specify `SECOND`, `MINUTE`, `HOUR`, or `DAY` units of duration in the form `INTERVAL ... <unit>` or `INTERVAL ... <unit> TO <unit>`.
-
-Specifying a single duration field truncates the interval at the unit specified, defining the interval as having the duration field unit as its least-significant unit. For example, `INTERVAL '1 2:03:04' HOUR` truncates the input to an exact hour, and parses the interval as `1 day 02:00:00`.
-
-A single duration field can also resolve ambiguity in the input. For example, `INTERVAL '1'` parses the interval as `00:00:01` (1 second). `INTERVAL '1' MINUTE` parses the interval as `00:01:00` (1 minute).
-
-If the interval input is ambiguous, specifying two duration fields stores the interval in the units specified. For example, `INTERVAL '02:03' MINUTE TO SECOND` parses the interval as `00:02:03` (in minutes and seconds). Without `MINUTE TO SECOND`, the input would be parsed as `02:03:00` (in hours and minutes).
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE intervals (a INT PRIMARY KEY, b INTERVAL);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM intervals;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  a           | INT8      |    false    | NULL           |                       | {primary} |   false
-  b           | INTERVAL  |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO
-    intervals
-    VALUES (1, INTERVAL '1 year 2 months 3 days 4 hours 5 minutes 6 seconds'),
-           (2, INTERVAL '1-2 3 4:5:6'),
-           (3, '1-2 3 4:5:6');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM intervals;
-~~~
-
-~~~
-  a |               b
-----+--------------------------------
-  1 | 1 year 2 mons 3 days 04:05:06
-  2 | 1 year 2 mons 3 days 04:05:06
-  3 | 1 year 2 mons 3 days 04:05:06
-(3 rows)
-~~~
-
-## Supported casting and conversion
-
-`INTERVAL` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`INT` | Converts to number of seconds (second precision)
-`DECIMAL` | Converts to number of seconds (microsecond precision)
-`FLOAT` | Converts to number of seconds (microsecond precision)
-`STRING` | Converts to `h-m-s` format (microsecond precision)
-`TIME` | Converts to `HH:MM:SS.SSSSSS`, the time equivalent to the interval after midnight (microsecond precision)
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/inverted-indexes.md b/src/current/v20.2/inverted-indexes.md
deleted file mode 100644
index aa7574d19d1..00000000000
--- a/src/current/v20.2/inverted-indexes.md
+++ /dev/null
@@ -1,306 +0,0 @@
----
-title: Generalized Inverted Indexes
-summary: Generalized inverted indexes (GIN) improve your database's performance and usefulness by helping SQL locate data in JSONB or ARRAY columns.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-Generalized inverted indexes, or GIN indexes, store mappings from values within a container column (such as a [`JSONB`](jsonb.html) document) to the row that holds that value. They are used to speed up containment searches, e.g., "show me all of the rows from this table which have a JSON column that contains the key-value pair `{"location":"NYC"}`". GIN indexes are commonly used in [document retrieval systems](https://en.wikipedia.org/wiki/Document_retrieval).
-
-CockroachDB stores the contents of the following data types in GIN indexes:
-
-- [JSONB](jsonb.html)
-- [Arrays](array.html)
-- [Spatial data (`GEOMETRY` and `GEOGRAPHY` types)](spatial-indexes.html)
-
-{{site.data.alerts.callout_success}}For a hands-on demonstration of using a GIN index to improve query performance on a <code>JSONB</code> column, see the <a href="demo-json-support.html">JSON tutorial</a>.{{site.data.alerts.end}}
-
-## How do GIN indexes work?
-
-Standard [indexes](indexes.html) work well for searches based on prefixes of sorted data. However, data types like [`JSONB`](jsonb.html) or [arrays](array.html) cannot be queried without a full table scan, since they do not adhere to ordinary value prefix comparison operators. `JSONB` in particular needs to be indexed in a more detailed way than what a standard index provides. This is where GIN indexes prove useful.
-
-GIN indexes filter on components of tokenizable data. The `JSONB` data type is built on two structures that can be tokenized:
-
-- **Objects** - Collections of key-value pairs where each key-value pair is a token.
-- **Arrays** - Ordered lists of values where every value in the array is a token.
-
-For example, take the following `JSONB` value in column `person`:
-
-~~~ json
-{
-  "firstName": "John",
-  "lastName": "Smith",
-  "age": 25,
-  "address": {
-    "state": "NY",
-    "postalCode": "10021"
-  },
-  "cars": [
-    "Subaru",
-    "Honda"
-  ]
-}
-~~~
-
-A GIN index for this object would have an entry per component, mapping it back to the original object:
-
-~~~
-"firstName": "John"
-"lastName": "Smith"
-"age": 25
-"address": "state": "NY"
-"address": "postalCode": "10021"
-"cars" : "Subaru"
-"cars" : "Honda"
-~~~
-
-This lets you search based on subcomponents.
-
-### Creation
-
-You can use GIN indexes to improve the performance of queries using `JSONB` or `ARRAY` columns. You can create them:
-
-- At the same time as the table with the `INVERTED INDEX` clause of [`CREATE TABLE`](create-table.html#create-a-table-with-secondary-and-gin-indexes).
-- For existing tables with [`CREATE INVERTED INDEX`](create-index.html).
-- Using the following PostgreSQL-compatible syntax:
-
-    ~~~ sql
-    > CREATE INDEX <optional name> ON <table> USING GIN (<column>);
-    ~~~
-
-### Selection
-
-If a query contains a filter against an indexed `JSONB` or `ARRAY` column that uses any of the supported operators, the GIN index is added to the set of index candidates.
-
-Because each query can use only a single index, CockroachDB selects the index it calculates will scan the fewest rows (i.e., the fastest). For more detail, check out our blog post [Index Selection in CockroachDB](https://www.cockroachlabs.com/blog/index-selection-cockroachdb-2/).
-
-To override CockroachDB's index selection, you can also force [queries to use a specific index](table-expressions.html#force-index-selection) (also known as "index hinting").
-
-### Storage
-
-CockroachDB stores indexes directly in your key-value store. You can find more information in our blog post [Mapping Table Data to Key-Value Storage](https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-table-data-to-key-value-storage/).
-
-### Locking
-
-Tables are not locked during index creation thanks to CockroachDB's [schema change procedure](https://www.cockroachlabs.com/blog/how-online-schema-changes-are-possible-in-cockroachdb/).
-
-### Performance
-
-Indexes create a trade-off: they greatly improve the speed of queries, but slightly slow down writes (because new values have to be copied and sorted). The first index you create has the largest impact, but additional indexes only introduce marginal overhead.
-
-### Comparisons
-
-#### JSONB
-
-GIN indexes on `JSONB` columns support the following comparison operators:
-
-- "is contained by": [`<@`](functions-and-operators.html#supported-operations)
-- "contains": [`@>`](functions-and-operators.html#supported-operations)
-- "equals": [`=`](functions-and-operators.html#supported-operations), but only when you've reached into the JSON document with the [`->`](functions-and-operators.html#supported-operations) operator.  For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM a WHERE j ->'foo' = '"1"';
-    ~~~
-
-    This is equivalent to using `@>`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM a WHERE j @> '{"foo": "1"}';
-    ~~~
-
-If you require comparisons using [`<`](functions-and-operators.html#supported-operations), [`<=`](functions-and-operators.html#supported-operations), etc., you can create an index on a computed column using your JSON payload, and then create a regular index on that. So if you wanted to write a query where the value of "foo" is greater than three, you would:
-
-1. Create your table with a computed column:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE test (
-        id INT,
-        data JSONB,
-        foo INT AS ((data->>'foo')::INT) STORED
-        );
-    ~~~
-
-2. Create an index on your computed column:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE INDEX test_idx ON test (foo);
-    ~~~
-
-3. Execute your query with your comparison:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM test where foo > 3;
-    ~~~
-
-#### Arrays
-
- GIN indexes on [`ARRAY`](array.html) columns support the following comparison operators:
-
-- "is contained by": [`<@`](functions-and-operators.html#supported-operations)
-- "contains": [`@>`](functions-and-operators.html#supported-operations)
-
-## Known limitations
-
-CockroachDB does not support partitioning GIN indexes. For details, see [tracking issue](https://github.com/cockroachdb/cockroach/issues/43643).
-
-## Example
-
-### Create a table with GIN index on a JSONB column
-
-In this example, let's create a table with a `JSONB` column and a GIN index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-    profile_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    last_updated TIMESTAMP DEFAULT now(),
-    user_profile JSONB,
-    INVERTED INDEX user_details (user_profile)
-  );
-~~~
-
-Then, insert a few rows of data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users (user_profile) VALUES
-    ('{"first_name": "Lola", "last_name": "Dog", "location": "NYC", "online" : true, "friends" : 547}'),
-    ('{"first_name": "Ernie", "status": "Looking for treats", "location" : "Brooklyn"}'),
-    ('{"first_name": "Carl", "last_name": "Kimball", "location": "NYC", "breed": "Boston Terrier"}'
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT *, jsonb_pretty(user_profile) FROM users;
-~~~
-~~~
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+------------------------------------+
-|              profile_id              |           last_updated           |                               user_profile                               |            jsonb_pretty            |
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+------------------------------------+
-| 81330a51-80b2-44aa-b793-1b8d84ba69c9 | 2018-03-13 18:26:24.521541+00:00 | {"breed": "Boston Terrier", "first_name": "Carl", "last_name":           | {                                  |
-|                                      |                                  | "Kimball", "location": "NYC"}                                            |                                    |
-|                                      |                                  |                                                                          |     "breed": "Boston Terrier",     |
-|                                      |                                  |                                                                          |     "first_name": "Carl",          |
-|                                      |                                  |                                                                          |     "last_name": "Kimball",        |
-|                                      |                                  |                                                                          |     "location": "NYC"              |
-|                                      |                                  |                                                                          | }                                  |
-| 81c87adc-a49c-4bed-a59c-3ac417756d09 | 2018-03-13 18:26:24.521541+00:00 | {"first_name": "Ernie", "location": "Brooklyn", "status": "Looking for   | {                                  |
-|                                      |                                  | treats"}                                                                 |                                    |
-|                                      |                                  |                                                                          |     "first_name": "Ernie",         |
-|                                      |                                  |                                                                          |     "location": "Brooklyn",        |
-|                                      |                                  |                                                                          |     "status": "Looking for treats" |
-|                                      |                                  |                                                                          | }                                  |
-| ec0a4942-b0aa-4a04-80ae-591b3f57721e | 2018-03-13 18:26:24.521541+00:00 | {"first_name": "Lola", "friends": 547, "last_name": "Dog", "location":   | {                                  |
-|                                      |                                  | "NYC", "online": true}                                                   |                                    |
-|                                      |                                  |                                                                          |     "first_name": "Lola",          |
-|                                      |                                  |                                                                          |     "friends": 547,                |
-|                                      |                                  |                                                                          |     "last_name": "Dog",            |
-|                                      |                                  |                                                                          |     "location": "NYC",             |
-|                                      |                                  |                                                                          |     "online": true                 |
-|                                      |                                  |                                                                          | }                                  |
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+------------------------------------+
-(3 rows)
-~~~
-
-Now, run a query that filters on the `JSONB` column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users where user_profile @> '{"location":"NYC"}';
-~~~
-~~~
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+
-|              profile_id              |           last_updated           |                               user_profile                               |
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+
-| 81330a51-80b2-44aa-b793-1b8d84ba69c9 | 2018-03-13 18:26:24.521541+00:00 | {"breed": "Boston Terrier", "first_name": "Carl", "last_name":           |
-|                                      |                                  | "Kimball", "location": "NYC"}                                            |
-| ec0a4942-b0aa-4a04-80ae-591b3f57721e | 2018-03-13 18:26:24.521541+00:00 | {"first_name": "Lola", "friends": 547, "last_name": "Dog", "location":   |
-|                                      |                                  | "NYC", "online": true}                                                   |
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+
-(2 rows)
-~~~
-
-### Add a GIN index to a table with an array column
-
-In this example, let's create a table with an `ARRAY` column first, and add the GIN index later:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE students (
-    student_id  UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    marks INT ARRAY
-  );
-~~~
-
-Insert a few rows of data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO students (marks) VALUES
-    (ARRAY[10,20,50]),
-    (ARRAY[20,40,100]),
-    (ARRAY[100,20,70]
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM students;
-~~~
-
-~~~
-+--------------------------------------+--------------+
-|              student_id              |    marks     |
-+--------------------------------------+--------------+
-| 11cdc77c-2f12-48d4-8bb4-ddee7c705e00 | {10,20,50}   |
-|                                      |              |
-| 2526c746-0b32-4f6b-a2b4-7ce6d411c1c2 | {20,40,100}  |
-|                                      |              |
-| eefdc32e-4485-45ca-9df1-80c0f42d73c0 | {100,20,70}  |
-|                                      |              |
-+--------------------------------------+--------------+
-(3 rows)
-~~~
-
-Now, let’s add a GIN index to the table and run a query that filters on the `ARRAY`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INVERTED INDEX student_marks ON students (marks);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM students where marks @> ARRAY[100];
-~~~
-
-~~~
-+--------------------------------------+--------------+
-|              student_id              |    marks     |
-+--------------------------------------+--------------+
-| 2526c746-0b32-4f6b-a2b4-7ce6d411c1c2 | {20,40,100}  |
-|                                      |              |
-| eefdc32e-4485-45ca-9df1-80c0f42d73c0 | {100,20,70}  |
-|                                      |              |
-+--------------------------------------+--------------+
-(2 rows)
-~~~
-
-## See also
-
-- [`JSONB`](jsonb.html)
-- [`ARRAY`](array.html)
-- [JSON tutorial](demo-json-support.html)
-- [Computed Columns](computed-columns.html)
-- [`CREATE INDEX`](create-index.html)
-- [`DROP INDEX`](drop-index.html)
-- [`RENAME INDEX`](rename-index.html)
-- [`SHOW INDEX`](show-index.html)
-- [Indexes](indexes.html)
-- [SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/joins.md b/src/current/v20.2/joins.md
deleted file mode 100644
index c22e99504da..00000000000
--- a/src/current/v20.2/joins.md
+++ /dev/null
@@ -1,175 +0,0 @@
----
-title: JOIN Expressions
-summary: JOIN expressions combine data from two or more table expressions.
-toc: true
----
-
-`JOIN` expressions, also called "joins", combine the results of two or more table expressions based on conditions on the values of particular columns (i.e., equality columns).
-
-`JOIN` expressions define a data source in the `FROM` sub-clause of [simple `SELECT` clauses](select-clause.html), or as parameter to [`TABLE`](selection-queries.html#table-clause). Joins are a particular kind of [table expression](table-expressions.html).
-
-{{site.data.alerts.callout_success}}
-The [cost-based optimizer](cost-based-optimizer.html) supports hint syntax to force the use of a specific join algorithm.  For more information, see [Join hints](cost-based-optimizer.html#join-hints).
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/joined_table.html %}
-</div>
-
-<div markdown="1"></div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`joined_table` | Another join expression.
-`table_ref` | A [table expression](table-expressions.html).
-`a_expr` | A [scalar expression](scalar-expressions.html) to use as [`ON` join condition](#supported-join-conditions).
-`name` | A column name to use as [`USING` join condition](#supported-join-conditions)
-
-## Supported join types
-
-CockroachDB supports the following join types:
-
-- [Inner joins](#inner-joins)
-- [Left outer joins](#left-outer-joins)
-- [Right outer joins](#right-outer-joins)
-- [Full outer joins](#full-outer-joins)
-
-### Inner joins
-
-Only the rows from the left and right operand that match the condition are returned.
-
-~~~
-<table expr> [ INNER ] JOIN <table expr> ON <val expr>
-<table expr> [ INNER ] JOIN <table expr> USING(<colname>, <colname>, ...)
-<table expr> NATURAL [ INNER ] JOIN <table expr>
-<table expr> CROSS JOIN <table expr>
-~~~
-
-### Left outer joins
-
-For every left row where there is no match on the right, `NULL` values are returned for the columns on the right.
-
-~~~
-<table expr> LEFT [ OUTER ] JOIN <table expr> ON <val expr>
-<table expr> LEFT [ OUTER ] JOIN <table expr> USING(<colname>, <colname>, ...)
-<table expr> NATURAL LEFT [ OUTER ] JOIN <table expr>
-~~~
-
-### Right outer joins
-
-For every right row where there is no match on the left, `NULL` values are returned for the columns on the left.
-
-~~~
-<table expr> RIGHT [ OUTER ] JOIN <table expr> ON <val expr>
-<table expr> RIGHT [ OUTER ] JOIN <table expr> USING(<colname>, <colname>, ...)
-<table expr> NATURAL RIGHT [ OUTER ] JOIN <table expr>
-~~~
-
-### Full outer joins
-
-For every row on one side of the join where there is no match on the other side, `NULL` values are returned for the columns on the non-matching side.
-
-~~~
-<table expr> FULL [ OUTER ] JOIN <table expr> ON <val expr>
-<table expr> FULL [ OUTER ] JOIN <table expr> USING(<colname>, <colname>, ...)
-<table expr> NATURAL FULL [ OUTER ] JOIN <table expr>
-~~~
-
-## Supported join conditions
-
-CockroachDB supports the following conditions to match rows in a join:
-
-- No condition with `CROSS JOIN`: each row on the left is considered
-  to match every row on the right.
-- `ON` predicates: a Boolean [scalar expression](scalar-expressions.html)
-  is evaluated to determine whether the operand rows match.
-- `USING`: the named columns are compared pairwise from the left and
-  right rows; left and right rows are considered to match if the
-  columns are equal pairwise.
-- `NATURAL`: generates an implicit `USING` condition using all the
-  column names that are present in both the left and right table
-  expressions.
-
-<section>{{site.data.alerts.callout_danger}}<code>NATURAL</code> is supported for compatibility with PostgreSQL; its use in new applications is discouraged because its results can silently change in unpredictable ways when new columns are added to one of the join operands.{{site.data.alerts.end}}</section>
-
-## Join algorithms
-
-CockroachDB supports the following algorithms for performing a join:
-
-- [Merge joins](#merge-joins)
-- [Hash joins](#hash-joins)
-- [Lookup joins](#lookup-joins)
-
-### Merge joins
-
-To perform a [merge join](https://en.wikipedia.org/wiki/Sort-merge_join) of two tables, both tables must be indexed on the equality columns, and any indexes must have the same ordering. Merge joins offer better computational performance and more efficient memory usage than [hash joins](#hash-joins). When tables and indexes are ordered for a merge, CockroachDB chooses to use merge joins over hash joins, by default. When merge conditions are not met, CockroachDB resorts to the slower hash joins. Merge joins can be used only with [distributed query processing](https://www.cockroachlabs.com/blog/local-and-distributed-processing-in-cockroachdb/).
-
-Merge joins are performed on the indexed columns of two tables as follows:
-
-1. CockroachDB checks for indexes on the equality columns and that they are ordered the same (i.e., `ASC` or `DESC`).
-2. CockroachDB takes one row from each table and compares them.  
-    - For inner joins:  
-        - If the rows are equal, CockroachDB returns the rows.
-        - If there are multiple matches, the cartesian product of the matches is returned.
-        - If the rows are not equal, CockroachDB discards the lower-value row and repeats the process with the next row until all rows are processed.
-    - For outer joins:
-        - If the rows are equal, CockroachDB returns the rows.
-        - If there are multiple matches, the cartesian product of the matches is returned.
-        - If the rows are not equal, CockroachDB returns `NULL` for the non-matching column and repeats the process with the next row until all rows are processed.
-
-### Hash joins
-
-If a merge join cannot be used, CockroachDB uses a [hash join](https://en.wikipedia.org/wiki/Hash_join). Hash joins are computationally expensive and require additional memory.
-
-Hash joins are performed on two tables as follows:
-
-1. CockroachDB reads both tables and attempts to pick the smaller table.
-2. CockroachDB creates an in-memory [hash table](https://en.wikipedia.org/wiki/Hash_table) on the smaller table. If the hash table is too large, it will spill over to disk storage (which could affect performance).
-3. CockroachDB then scans the large table, looking up each row in the hash table.
-
-### Lookup joins
-
-The [cost-based optimizer](cost-based-optimizer.html) decides when it would be beneficial to use a lookup join. Lookup joins are used when there is a large imbalance in size between the two tables, as it only reads the smaller table and then looks up matches in the larger table. A lookup join requires that the right-hand (i.e., larger) table be indexed on the equality column. A [partial index](partial-indexes.html) can only be used if it contains the subset of rows being looked up.
-
-Lookup joins are performed on two tables as follows:
-
-1. CockroachDB reads each row in the small table.
-2. CockroachDB then scans (or "looks up") the larger table for matches to the smaller table and outputs the matching rows.
-
-You can override the use of lookup joins using [join hints](cost-based-optimizer.html#join-hints).
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> To make the optimizer prefer lookup joins to merge joins when performing foreign key checks, set the `prefer_lookup_joins_for_fks` [session variable](set-vars.html) to `on`.
-{{site.data.alerts.end}}
-
-The output of [`EXPLAIN (VERBOSE)`](explain.html#verbose-option) shows whether `equality cols are key` for lookup joins, which means that the lookup columns form a key in the target table such that each lookup has at most one result.
-
-## `LATERAL` joins
-
-CockroachDB supports `LATERAL` subquery joins for `INNER` and `LEFT` cross joins. For more information about `LATERAL` subqueries, see [Lateral subqueries](subqueries.html#lateral-subqueries).
-
-## Performance best practices
-
-{{site.data.alerts.callout_info}}CockroachDB is currently undergoing major changes to evolve and improve the performance of queries using joins. The restrictions and workarounds listed in this section will be lifted or made unnecessary over time.{{site.data.alerts.end}}
-
-- When no indexes can be used to satisfy a join, CockroachDB may load all the rows in memory that satisfy the condition one of the join operands before starting to return result rows. This may cause joins to fail if the join condition or other `WHERE` clauses are insufficiently selective.
-- Outer joins (i.e., [left outer joins](#left-outer-joins), [right outer joins](#right-outer-joins), and [full outer joins](#full-outer-joins)) are generally processed less efficiently than [inner joins](#inner-joins). Use inner joins whenever possible. Full outer joins are the least optimized.
-- Use [`EXPLAIN`](explain.html) over queries containing joins to verify that indexes are used.
-- Use [indexes](indexes.html) for faster joins.
-
-## See also
-
-- [Cost-based Optimizer: Join Hints](cost-based-optimizer.html#join-hints)
-- [Scalar Expressions](scalar-expressions.html)
-- [Table Expressions](table-expressions.html)
-- [Simple `SELECT` Clause](select-clause.html)
-- [Selection Queries](selection-queries.html)
-- [`EXPLAIN`](explain.html)
-- [Performance Best Practices - Overview](performance-best-practices-overview.html)
-- [SQL join operation (Wikipedia)](https://en.wikipedia.org/wiki/Join_(SQL))
-- [CockroachDB's first implementation of SQL joins (CockroachDB Blog)](https://www.cockroachlabs.com/blog/cockroachdbs-first-join/)
-- [On the Way to Better SQL Joins in CockroachDB (CockroachDB Blog)](https://www.cockroachlabs.com/blog/better-sql-joins-in-cockroachdb/)
diff --git a/src/current/v20.2/jsonb.md b/src/current/v20.2/jsonb.md
deleted file mode 100644
index 9be345e1eb3..00000000000
--- a/src/current/v20.2/jsonb.md
+++ /dev/null
@@ -1,316 +0,0 @@
----
-title: JSONB
-summary: The JSONB data type stores JSON (JavaScript Object Notation) data.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-The `JSONB` [data type](data-types.html) stores JSON (JavaScript Object Notation) data as a binary representation of the `JSONB` value, which eliminates whitespace, duplicate keys, and key ordering. `JSONB` supports [GIN indexes](inverted-indexes.html).
-
-{{site.data.alerts.callout_success}}For a hands-on demonstration of storing and querying JSON data from a third-party API, see the <a href="demo-json-support.html">JSON tutorial</a>.{{site.data.alerts.end}}
-
-## Alias
-
-In CockroachDB, `JSON` is an alias for `JSONB`.
-
-{{site.data.alerts.callout_info}}In PostgreSQL, <code>JSONB</code> and <code>JSON</code> are two different data types. In CockroachDB, the <code>JSONB</code> / <code>JSON</code> data type is similar in behavior to the <a href="https://www.postgresql.org/docs/current/static/datatype-json.html"><code>JSONB</code> data type in PostgreSQL</a>.
-{{site.data.alerts.end}}
-
-## Considerations
-
-- The [primary key](primary-key.html), [foreign key](foreign-key.html), and [unique](unique.html) [constraints](constraints.html) cannot be used on `JSONB` values.
-- A standard [index](indexes.html) cannot be created on a `JSONB` column; you must use a [GIN index](inverted-indexes.html).
-- CockroachDB does not currently key-encode JSON values. As a result, tables cannot be [ordered by](order-by.html) `JSONB`/`JSON`-typed columns. For details, see [tracking issue](https://github.com/cockroachdb/cockroach/issues/35706).
-
-## Syntax
-
-The syntax for the `JSONB` data type follows the format specified in [RFC8259](https://tools.ietf.org/html/rfc8259). A constant value of type `JSONB` can be expressed using an
-[interpreted literal](sql-constants.html#interpreted-literals) or a
-string literal
-[annotated with](scalar-expressions.html#explicitly-typed-expressions)
-type `JSONB`.
-
-There are six types of `JSONB` values:
-
-- `null`
-- Boolean
-- String
-- Number (i.e., [`decimal`](decimal.html), **not** the standard `int64`)
-- Array (i.e., an ordered sequence of `JSONB` values)
-- Object (i.e., a mapping from strings to `JSONB` values)
-
-Examples:
-
-- `'{"type": "account creation", "username": "harvestboy93"}'`
-- `'{"first_name": "Ernie", "status": "Looking for treats", "location" : "Brooklyn"}'`
-
-{{site.data.alerts.callout_info}}If duplicate keys are included in the input, only the last value is kept.{{site.data.alerts.end}}
-
-## Size
-
-The size of a `JSONB` value is variable, but it's recommended to keep values under 1 MB to ensure performance. Above that threshold, [write amplification](https://en.wikipedia.org/wiki/Write_amplification) and other considerations may cause significant performance degradation.
-
-## Functions
-
-Function | Description | Example |
----------|-------------|---------|
-`jsonb_array_elements(<jsonb>)` | Expands a `JSONB` array to a set of `JSONB` values. | `SELECT jsonb_array_elements('[1,true, 2,false]');`
-`jsonb_build_object(<any_element>...)` | Builds a `JSONB` object out of a variadic argument list that alternates between keys and values. | `SELECT json_build_object('Zoo',1,'Enter',2);`
-`jsonb_each(<jsonb>)` | Expands the outermost `JSONB` object into a set of key-value pairs. | `SELECT * from json_each('{"a":"Apple", "b":"ball"}');`
-`jsonb_object_keys(<jsonb>)` | Returns sorted set of keys in the outermost `JSONB` object. | `SELECT * from jsonb_object_keys('{"fb1":"abc123","fb2":{"fb3":"ant", "f4":"ball"}}');`
-`jsonb_pretty(<jsonb>)` | Returns the given `JSONB` value as a `STRING` indented and with newlines. | See the [example](#retrieve-formatted-jsonb-data) below.
-
-For the full list of supported `JSONB` functions, see [Functions and Operators](functions-and-operators.html#jsonb-functions).
-
-## Operators
-
-Operator | Description | Example |
----------|-------------|---------|
-`->` | Access a `JSONB` field, returning a `JSONB` value. | `SELECT '[{"foo":"bar"}]'::JSONB->0->'foo' = '"bar"'::JSONB;`
-`->>` | Access a `JSONB` field, returning a string. | `SELECT '{"foo":"bar"}'::JSONB->>'foo' = 'bar'::STRING;`
-`@>` | Tests whether the left `JSONB` field contains the right `JSONB` field. | `SELECT ('{"foo": {"baz": 3}, "bar": 2}'::JSONB @> '{"foo": {"baz":3}}'::JSONB ) = true;`
-
-For the full list of supported `JSONB` operators, see [Functions and Operators](functions-and-operators.html).
-
-## Known limitations
-
-If the execution of a [join](joins.html) query exceeds the limit set for [memory-buffering operations](vectorized-execution.html#disk-spilling-operations) (i.e., the value set for the `sql.distsql.temp_storage.workmem` [cluster setting](cluster-settings.html)), CockroachDB will spill the intermediate results of computation to disk. If the join operation spills to disk, and at least one of the columns is of type `JSON`, CockroachDB returns the error `unable to encode table key: *tree.DJSON`. If the memory limit is not reached, then the query will be processed without error.
-
-For details, see [tracking issue](https://github.com/cockroachdb/cockroach/issues/35706).
-
-## Examples
-
-### Create a Table with a `JSONB` Column
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-    profile_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    last_updated TIMESTAMP DEFAULT now(),
-    user_profile JSONB
-  );
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users;
-~~~
-
-~~~
-+--------------+-----------+-------------+-------------------+-----------------------+-------------+
-| column_name  | data_type | is_nullable |  column_default   | generation_expression |   indices   |
-+--------------+-----------+-------------+-------------------+-----------------------+-------------+
-| profile_id   | UUID      |    false    | gen_random_uuid() |                       | {"primary"} |
-| last_updated | TIMESTAMP |    true     | now()             |                       | {}          |
-| user_profile | JSON      |    true     | NULL              |                       | {}          |
-+--------------+-----------+-------------+-------------------+-----------------------+-------------+
-(3 rows)
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users (user_profile) VALUES
-    ('{"first_name": "Lola", "last_name": "Dog", "location": "NYC", "online" : true, "friends" : 547}'),
-    ('{"first_name": "Ernie", "status": "Looking for treats", "location" : "Brooklyn"}');
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users;
-~~~
-~~~
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+
-|              profile_id              |           last_updated           |                               user_profile                               |
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+
-| 33c0a5d8-b93a-4161-a294-6121ee1ade93 | 2018-02-27 16:39:28.155024+00:00 | {"first_name": "Lola", "friends": 547, "last_name": "Dog", "location":   |
-|                                      |                                  | "NYC", "online": true}                                                   |
-| 6a7c15c9-462e-4551-9e93-f389cf63918a | 2018-02-27 16:39:28.155024+00:00 | {"first_name": "Ernie", "location": "Brooklyn", "status": "Looking for   |
-|                                      |                                  | treats"}                                                                 |
-+--------------------------------------+----------------------------------+--------------------------------------------------------------------------+
-~~~
-
-### Retrieve formatted `JSONB` data
-
-To retrieve `JSONB` data with easier-to-read formatting, use the `jsonb_pretty()` function. For example, retrieve data from the table you created in the [first example](#create-a-table-with-a-jsonb-column):
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT profile_id, last_updated, jsonb_pretty(user_profile) FROM users;
-~~~
-~~~
-+--------------------------------------+----------------------------------+------------------------------------+
-|              profile_id              |           last_updated           |            jsonb_pretty            |
-+--------------------------------------+----------------------------------+------------------------------------+
-| 33c0a5d8-b93a-4161-a294-6121ee1ade93 | 2018-02-27 16:39:28.155024+00:00 | {                                  |
-|                                      |                                  |     "first_name": "Lola",          |
-|                                      |                                  |     "friends": 547,                |
-|                                      |                                  |     "last_name": "Dog",            |
-|                                      |                                  |     "location": "NYC",             |
-|                                      |                                  |     "online": true                 |
-|                                      |                                  | }                                  |
-| 6a7c15c9-462e-4551-9e93-f389cf63918a | 2018-02-27 16:39:28.155024+00:00 | {                                  |
-|                                      |                                  |     "first_name": "Ernie",         |
-|                                      |                                  |     "location": "Brooklyn",        |
-|                                      |                                  |     "status": "Looking for treats" |
-|                                      |                                  | }                                  |
-+--------------------------------------+----------------------------------+------------------------------------+
-~~~
-
-### Retrieve specific fields from a `JSONB` value
-
-To retrieve a specific field from a `JSONB` value, use the `->` operator. For example, retrieve a field from the table you created in the [first example](#create-a-table-with-a-jsonb-column):
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT user_profile->'first_name',user_profile->'location' FROM users;
-~~~
-~~~
-+----------------------------+--------------------------+
-| user_profile->'first_name' | user_profile->'location' |
-+----------------------------+--------------------------+
-| "Lola"                     | "NYC"                    |
-| "Ernie"                    | "Brooklyn"               |
-+----------------------------+--------------------------+
-~~~
-
-You can also use the `->>` operator to return `JSONB` field values as `STRING` values:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT user_profile->>'first_name', user_profile->>'location' FROM users;
-~~~
-~~~
-+-----------------------------+---------------------------+
-| user_profile->>'first_name' | user_profile->>'location' |
-+-----------------------------+---------------------------+
-| Lola                        | NYC                       |
-| Ernie                       | Brooklyn                  |
-+-----------------------------+---------------------------+
-~~~
-
-You can use the `@>` operator to filter the values in key-value pairs to return `JSONB` field values:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT user_profile->'first_name', user_profile->'location' FROM users WHERE user_profile @> '{"location":"NYC"}';
-~~~
-~~~
-+-----------------------------+---------------------------+
-| user_profile->>'first_name' | user_profile->>'location' |
-+-----------------------------+---------------------------+
-| Lola                        | NYC                       |
-+-----------------------------+---------------------------+
-~~~
-
-For the full list of functions and operators we support, see [Functions and Operators](functions-and-operators.html).
-
-### Group and order `JSONB` values
-
-To organize your `JSONB` field values, use the `GROUP BY` and `ORDER BY` clauses with the `->>` operator. For example, organize the `first_name` values from the table you created in the [first example](#create-a-table-with-a-jsonb-column):
-
-For this example, we will add a few more records to the existing table. This will help us see clearly how the data is grouped.
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users (user_profile) VALUES
-    ('{"first_name": "Lola", "last_name": "Kim", "location": "Seoul", "online": false, "friends": 600}'),
-    ('{"first_name": "Parvati", "last_name": "Patil", "location": "London", "online": false, "friends": 500}');
-~~~
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT user_profile->>'first_name' AS first_name, user_profile->>'location' AS location FROM users;
-~~~
-
-~~~
-  first_name | location
--------------+-----------
-  Ernie      | Brooklyn
-  Lola       | NYC
-  Parvati    | London
-  Lola       | Seoul
-~~~
-
-Now let’s group and order the data.
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SELECT user_profile->>'first_name' first_name, count(*) total FROM users group by user_profile->>'first_name' order by total;
-~~~
-
-~~~
-  first_name | total
--------------+-------
-  Ernie      | 1
-  Parvati    | 1
-  Lola       | 2
-~~~
-
-The `->>` operator returns `STRING` and uses string comparison rules to order the data. If you want numeric ordering, cast the resulting data to `FLOAT`.
-
-For the full list of functions and operators we support, see [Functions and Operators](functions-and-operators.html).
-
-
-### Create a table with a `JSONB` column and a computed column
-
-{% include {{ page.version.version }}/computed-columns/jsonb.md %}
-
-## Supported casting and conversion
-
-`JSONB` values can be [cast](data-types.html#data-type-conversions-and-casts) to the following data type:
-
-- `STRING`
-
-The [`parse_timestamp` function](functions-and-operators.html) is used to parse strings in `TIMESTAMP` format.
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-SELECT parse_timestamp ('2021-09-28T10:53:25.160Z');
-~~~
-
-~~~
-      parse_timestamp
---------------------------
-2021-09-28 10:53:25.16
-(1 row)
-~~~
-
-The `parse_timestamp` function can be used to retrieve string representations of timestamp data within `JSONB` columns in `TIMESTAMP` format.
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-CREATE TABLE events (
-  raw JSONB,
-  event_created TIMESTAMP AS (parse_timestamp(raw->'event'->>'created')) STORED
-);
-INSERT INTO events (raw) VALUES ('{"event":{"created":"2021-09-28T10:53:25.160Z"}}');
-SELECT event_created FROM events;
-~~~
-
-~~~
-CREATE TABLE
-
-
-Time: 6ms total (execution 6ms / network 0ms)
-
-INSERT 1
-
-
-Time: 9ms total (execution 9ms / network 0ms)
-
-      event_created
---------------------------
-  2021-09-28 10:53:25.16
-(1 row)
-
-
-Time: 1ms total (execution 1ms / network 0ms)
-~~~
-
-## See also
-
-- [JSON tutorial](demo-json-support.html)
-- [GIN Indexes](inverted-indexes.html)
-- [Computed Columns](computed-columns.html)
-- [Data Types](data-types.html)
-- [Functions and Operators](functions-and-operators.html)
diff --git a/src/current/v20.2/keywords-and-identifiers.md b/src/current/v20.2/keywords-and-identifiers.md
deleted file mode 100644
index 4618f2da7df..00000000000
--- a/src/current/v20.2/keywords-and-identifiers.md
+++ /dev/null
@@ -1,48 +0,0 @@
----
-title: Keywords & Identifiers
-summary: Learn about SQL keywords and identifiers in CockroachDB.
-toc: true
----
-
-SQL statements consist of two fundamental components:
-
-- [__Keywords__](#keywords): Words with specific meaning in SQL like `CREATE`, `INDEX`, and `BOOL`
-- [__Identifiers__](#identifiers): Names for things like databases and some functions
-
-## Keywords
-
-Keywords make up SQL's vocabulary and can have specific meaning in statements. Each SQL keyword that CockroachDB supports is on one of four lists:
-
-- [Reserved Keywords](sql-grammar.html#reserved_keyword)
-- [Type Function Name Keywords](sql-grammar.html#type_func_name_keyword)
-- [Column Name Keywords](sql-grammar.html#col_name_keyword)
-- [Unreserved Keywords](sql-grammar.html#unreserved_keyword)
-
-Reserved keywords have fixed meanings and are not typically allowed as identifiers. All other types of keywords are considered non-reserved; they have special meanings in certain contexts and can be used as identifiers in other contexts.
-
-### Keyword uses
-
-Most users asking about keywords want to know more about them in terms of:
-
-- __Names of objects__, covered on this page in [Identifiers](#identifiers)
-- __Syntax__, covered in our pages [SQL Statements](sql-statements.html) and [SQL Grammar](sql-grammar.html)
-
-## Identifiers
-
-Identifiers are most commonly used as names of objects like databases, tables, or columns&mdash;because of this, the terms "name" and "identifier" are often used interchangeably. However, identifiers also have less-common uses, such as changing column labels with `SELECT`.
-
-### Rules for Identifiers
-
-In our [SQL grammar](sql-grammar.html), all values that accept an `identifier` must:
-
-- Begin with a Unicode letter or an underscore (_). Subsequent characters can be letters, underscores, digits (0-9), or dollar signs ($).
-- Not equal any [SQL keyword](#keywords) unless the keyword is accepted by the element's syntax. For example, [`name`](sql-grammar.html#name) accepts Unreserved or Column Name keywords.
-
-To bypass either of these rules, simply surround the identifier with double-quotes (&quot;). You can also use double-quotes to preserve case-sensitivity in database, table, view, and column names. However, all references to such identifiers must also include double-quotes.
-
-{{site.data.alerts.callout_info}}Some statements have additional requirements for identifiers. For example, each table in a database must have a unique name. These requirements are documented on <a href="sql-statements.html">each statement's page</a>.{{site.data.alerts.end}}
-
-## See also
-
-- [SQL Statements](sql-statements.html)
-- [Full SQL Grammar](sql-grammar.html)
diff --git a/src/current/v20.2/known-limitations.md b/src/current/v20.2/known-limitations.md
deleted file mode 100644
index 9ac8c47d320..00000000000
--- a/src/current/v20.2/known-limitations.md
+++ /dev/null
@@ -1,562 +0,0 @@
----
-title: Known Limitations in CockroachDB v20.2
-summary: Learn about newly identified limitations in CockroachDB as well as unresolved limitations identified in earlier releases.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-This page describes newly identified limitations in the CockroachDB {{page.release_info.version}} release as well as unresolved limitations identified in earlier releases.
-
-## New limitations
-
-### Partitioning on `ENUM` values
-
-[Partitions](partitioning.html) cannot be created on columns of type [`ENUM`](enum.html).
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/55342)
-
-### Multiple arbiter indexes for `INSERT ON CONFLICT DO UPDATE`
-
-CockroachDB does not currently support multiple arbiter indexes for [`INSERT ON CONFLICT DO UPDATE`](insert.html#on-conflict-clause), and will return an error if there are multiple unique or exclusion constraints matching the `ON CONFLICT DO UPDATE` specification.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/53170)
-
-### `IMPORT` into a table with partial indexes
-
-CockroachDB does not currently support [`IMPORT`s](import.html) into tables with partial indexes.
-
-To work around this limitation:
-
-1. Drop any partial indexes defined on the table.
-2. Perform the `IMPORT`.
-3. Recreate the partial indexes.
-
-If you are [performing an `IMPORT` of a `PGDUMP`](migrate-from-postgres.html) with partial indexes:
-
-1. Drop the partial indexes on the PostgreSQL server.
-2. Recreate the `PGDUMP`.
-3. `IMPORT` the `PGDUMP`.
-4. Add partial indexes on the CockroachDB server.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/50225)
-
-### Historical reads on restored objects
-
-{% include {{ page.version.version }}/known-limitations/restore-aost.md %}
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/53044)
-
-### Spatial support limitations
-
-CockroachDB supports efficiently storing and querying [spatial data](spatial-data.html), with the following limitations:
-
-- Not all [PostGIS spatial functions](https://postgis.net/docs/reference.html) are supported.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/49203)
-
-- The `AddGeometryColumn` [spatial function](functions-and-operators.html#spatial-functions) only allows constant arguments.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/49402)
-
-- The `AddGeometryColumn` spatial function only allows the `true` value for its `use_typmod` parameter.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/49448)
-
-- CockroachDB does not support the `@` operator. Instead of using `@` in spatial expressions, we recommend using the inverse, with `~`. For example, instead of `a @ b`, use `b ~ a`.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/56124)
-
-- CockroachDB does not yet support [`INSERT`](insert.html)s into the [`spatial_ref_sys` table](spatial-glossary.html#spatial-system-tables). This limitation also blocks the [`ogr2ogr -f PostgreSQL` file conversion command](https://gdal.org/programs/ogr2ogr.html#cmdoption-ogr2ogr-f).
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/55903)
-
-- CockroachDB does not yet support `DECLARE CURSOR`, which prevents the `ogr2ogr` conversion tool from exporting from CockroachDB to certain formats and prevents [QGIS](https://qgis.org/en/site/) from working with CockroachDB. To work around this limitation, [export data first to CSV](export-spatial-data.html) or GeoJSON format.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/41412)
-
-- CockroachDB does not yet support storing spatial objects of more than two dimensions.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/53091)
-
-- CockroachDB does not yet support Triangle or [`TIN`](https://en.wikipedia.org/wiki/Triangulated_irregular_network) spatial shapes.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/56196)
-
-- CockroachDB does not yet support Curve, MultiCurve, or CircularString spatial shapes.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/56199)
-
-- CockroachDB does not yet support [k-nearest neighbors](https://en.wikipedia.org/wiki/K-nearest_neighbors_algorithm).
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/55227)
-
-- CockroachDB does not support using [schema name prefixes](sql-name-resolution.html#how-name-resolution-works) to refer to [data types](data-types.html) with type modifiers (e.g., `public.geometry(linestring, 4326)`). Instead, use fully-unqualified names to refer to data types with type modifiers (e.g., `geometry(linestring,4326)`).
-
-    Note that, in [`IMPORT PGDUMP`](migrate-from-postgres.html) output, [`GEOMETRY` and `GEOGRAPHY`](spatial-data.html) data type names are prefixed by `public.`. If the type has a type modifier, you must remove the `public.` from the type name in order for the statements to work in CockroachDB.
-
-    [Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/56492)
-
-### `SET` does not `ROLLBACK` in a transaction
-
-{% include {{page.version.version}}/known-limitations/set-transaction-no-rollback.md %}
-
-## Unresolved limitations
-
-### Optimizer stale statistics deletion when columns are dropped
-
-* {% include {{page.version.version}}/known-limitations/old-multi-col-stats.md %}
-
-* {% include {{page.version.version}}/known-limitations/single-col-stats-deletion.md %}
-
-### Automatic statistics refresher may not refresh after upgrade
-
-{% include {{page.version.version}}/known-limitations/stats-refresh-upgrade.md %}
-
-### Differences in syntax and behavior between CockroachDB and PostgreSQL
-
-CockroachDB supports the [PostgreSQL wire protocol](https://www.postgresql.org/docs/current/protocol.html) and the majority of its syntax. However, CockroachDB does not support some of the PostgreSQL features or behaves differently from PostgreSQL because not all features can be easily implemented in a distributed system.
-
-For a list of known differences in syntax and behavior between CockroachDB and PostgreSQL, see [Features that differ from PostgreSQL](postgresql-compatibility.html#features-that-differ-from-postgresql).
-
-### Collation names that include upper-case or hyphens may cause errors
-
-Using a [collation](collate.html) name with upper-case letters or hyphens may result in errors.
-
-For example, the following SQL will result in an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE nocase_strings (s STRING COLLATE "en-US-u-ks-level2");
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO nocase_strings VALUES ('Aaa' COLLATE "en-US-u-ks-level2"), ('Bbb' COLLATE "en-US-u-ks-level2");
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT s FROM nocase_strings WHERE s = ('bbb' COLLATE "en-US-u-ks-level2");
-~~~
-
-~~~
-ERROR: internal error: "$0" = 'bbb' COLLATE en_us_u_ks_level2: unsupported comparison operator: <collatedstring{en-US-u-ks-level2}> = <collatedstring{en_us_u_ks_level2}>
-~~~
-
-As a workaround, only use collation names that have lower-case letters and underscores.
-
-[Tracking GitHub issue](https://github.com/cockroachdb/cockroach/issues/56335)
-
-### Subqueries in `SET` statements
-
-It is not currently possible to use a subquery in a [`SET`](set-vars.html) or [`SET CLUSTER SETTING`](set-cluster-setting.html) statement. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET application_name = (SELECT 'a' || 'b');
-~~~
-
-~~~
-ERROR: invalid value for parameter "application_name": "(SELECT 'a' || 'b')"
-SQLSTATE: 22023
-DETAIL: subqueries are not allowed in SET
-~~~
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/42896)
-
-### Enterprise `BACKUP` does not capture database/table/column comments
-
-The [`COMMENT ON`](comment-on.html) statement associates comments to databases, tables, or columns. However, the internal table (`system.comments`) in which these comments are stored is not captured by a [`BACKUP`](backup.html) of a table or database.
-
-As a workaround, take a cluster backup instead, as the `system.comments` table is included in cluster backups.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/44396)
-
-### Cold starts of large clusters may require manual intervention
-
-{{site.data.alerts.callout_info}}
-Resolved as of [v20.2.9](../releases/v20.2.html#v20-2-9). See [#64567](https://github.com/cockroachdb/cockroach/pull/64567).
-{{site.data.alerts.end}}
-
-If a cluster contains a large amount of data (>500GiB / node), and all nodes are stopped and then started at the same time, clusters can enter a state where they're unable to startup without manual intervention. In this state, logs fill up rapidly with messages like `refusing gossip from node x; forwarding to node y`, and data and metrics may become inaccessible.
-
-To exit this state, you should:
-
-1. Stop all nodes.
-2. Set the following environment variables: `COCKROACH_SCAN_INTERVAL=60m`, and `COCKROACH_SCAN_MIN_IDLE_TIME=1s`.
-3. Restart the cluster.
-
-Once restarted, monitor the Replica Quiescence graph on the [**Replication Dashboard**](ui-replication-dashboard.html). When >90% of the replicas have become quiescent, conduct a rolling restart and remove the environment variables. Make sure that under-replicated ranges do not increase between restarts.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/39117)
-
-### Requests to restarted node in need of snapshots may hang
-
-{{site.data.alerts.callout_info}}
-Resolved as of [v20.2.4](../releases/v20.2.html#v20-2-4). See [#57789](https://github.com/cockroachdb/cockroach/pull/57789).
-{{site.data.alerts.end}}
-
-When a node is offline, the [Raft logs](architecture/replication-layer.html#raft-logs) for the ranges on the node get truncated. When the node comes back online, it therefore often needs [Raft snapshots](architecture/replication-layer.html#snapshots) to get many of its ranges back up-to-date. While in this state, requests to a range will hang until its snapshot has been applied, which can take a long time.
-
-To work around this limitation, you can adjust the `kv.snapshot_recovery.max_rate` [cluster setting](cluster-settings.html) to temporarily relax the throughput rate limiting applied to snapshots. For example, changing the rate limiting from the default 8 MB/s, at which 1 GB of snapshots takes at least 2 minutes, to 64 MB/s can result in an 8x speedup in snapshot transfers and, therefore, a much shorter interruption of requests to an impacted node:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING kv.snapshot_recovery.max_rate = '64mb';
-~~~
-
-Before increasing this value, however, verify that you will not end up saturating your network interfaces, and once the problem has resolved, be sure to reset to the original value.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/37906)
-
-### Slow (or hung) backups and queries due to write intent buildup
-
-{% include {{ page.version.version }}/known-limitations/write-intent-buildup.md %}
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/59704)
-
-### Location-based time zone names
-
-Certain features of CockroachDB require time zone data, for example, to support using location-based names as time zone identifiers. When starting a CockroachDB node on a machine missing time zone data, the node will not start.
-
-To resolve this issue on Linux, install the [`tzdata`](https://www.iana.org/time-zones) library (sometimes called `tz` or `zoneinfo`).
-
-To resolve this issue on Windows, download Go's official [zoneinfo.zip](https://github.com/golang/go/raw/master/lib/time/zoneinfo.zip) and set the `ZONEINFO` environment variable to point to the zip file. For step-by-step guidance on setting environment variables on Windows, see this [external article](https://www.techjunkie.com/environment-variables-windows-10/).
-
-Make sure to do this across all nodes in the cluster and to keep this time zone data up-to-date.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/36864)
-
-### Change data capture
-
-Change data capture (CDC) provides efficient, distributed, row-level change feeds into Apache Kafka for downstream processing such as reporting, caching, or full-text indexing.
-
-{% include {{ page.version.version }}/known-limitations/cdc.md %}
-
-### DB Console may become inaccessible for secure clusters
-
-Accessing the DB Console for a secure cluster now requires login information (i.e., username and password). 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 DB Console.
-
-### `AS OF SYSTEM TIME` in `SELECT` statements
-
-`AS OF SYSTEM TIME` can only be used in a top-level `SELECT` statement. That is, we do not support statements like `INSERT INTO t SELECT * FROM t2 AS OF SYSTEM TIME <time>` or two subselects in the same statement with differing `AS OF SYSTEM TIME` arguments.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/30534)
-
-### Large index keys can impair performance
-
-The use of tables with very large primary or secondary index keys (>32KB) can result in excessive memory usage. Specifically, if the primary or secondary index key is larger than 32KB the default indexing scheme for [storage engine](cockroach-start.html#storage-engine) SSTables breaks down and causes the index to be excessively large. The index is pinned in memory by default for performance.
-
-To work around this issue, we recommend limiting the size of primary and secondary keys to 4KB, which you must account for manually. Note that most columns are 8B (exceptions being `STRING` and `JSON`), which still allows for very complex key structures.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/30515)
-
-### DB Console: Statements page latency reports
-
-The Statements page does not correctly report "mean latency" or "latency by phase" for statements that result in schema changes or other background jobs.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/30381)
-
-### Using `LIKE...ESCAPE` in `WHERE` and `HAVING` constraints
-
-CockroachDB tries to optimize most comparisons operators in `WHERE` and `HAVING` clauses into constraints on SQL indexes by only accessing selected rows. This is done for `LIKE` clauses when a common prefix for all selected rows can be determined in the search pattern (e.g., `... LIKE 'Joe%'`). However, this optimization is not yet available if the `ESCAPE` keyword is also used.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/30192)
-
-### Using SQLAlchemy with CockroachDB
-
-Users of the SQLAlchemy adapter provided by Cockroach Labs must [upgrade the adapter to the latest release](https://github.com/cockroachdb/sqlalchemy-cockroachdb) before upgrading to CockroachDB {{ page.version.version }}.
-
-### DB Console: CPU percentage calculation
-
-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).
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/28724)
-
-### DB Console: CPU count in containerized environments
-
-When CockroachDB is run in a containerized environment (e.g., Kubernetes), the DB Console does not detect CPU limits applied to a container. Instead, the UI displays the actual number of CPUs provisioned on a VM.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/34988)
-
-### `TRUNCATE` does not behave like `DELETE`
-
-`TRUNCATE` is not a DML statement, but instead works as a DDL statement. Its limitations are the same as other DDL statements, which are outlined in [Online Schema Changes: Limitations](online-schema-changes.html#limitations)
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/27953)
-
-### Ordering tables by `JSONB`/`JSON`-typed columns
-
-CockroachDB does not currently key-encode JSON values. As a result, tables cannot be [ordered by](order-by.html) [`JSONB`/`JSON`](jsonb.html)-typed columns.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/35706)
-
-### Current sequence value not checked when updating min/max value
-
-Altering the minimum or maximum value of a series does not check the current value of a series. This means that it is possible to silently set the maximum to a value less than, or a minimum value greater than, the current value.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/23719)
-
-### Using `default_int_size` session variable in batch of statements
-
-When setting the `default_int_size` [session variable](set-vars.html) in a batch of statements such as `SET default_int_size='int4'; SELECT 1::IN`, the `default_int_size` variable will not take affect until the next statement. This happens because statement parsing takes place asynchronously from statement execution.
-
-As a workaround, set `default_int_size` via your database driver, or ensure that `SET default_int_size` is in its own statement.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/32846)
-
-### `COPY FROM` statements are not supported in the CockroachDB SQL shell
-
-{% include {{ page.version.version }}/known-limitations/copy-from-clients.md %}
-
-### `COPY` syntax not supported by CockroachDB
-
-{% include {{ page.version.version }}/known-limitations/copy-syntax.md %}
-
-### Import with a high amount of disk contention
-
-{% include {{ page.version.version }}/known-limitations/import-high-disk-contention.md %}
-
-### Placeholders in `PARTITION BY`
-
-{% include {{ page.version.version }}/known-limitations/partitioning-with-placeholders.md %}
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/19464)
-
-### Adding a column with sequence-based `DEFAULT` values
-
-It is currently not possible to [add a column](add-column.html) to a table when the column uses a [sequence](create-sequence.html) as the [`DEFAULT`](default-value.html) value, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE t (x INT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t(x) VALUES (1), (2), (3);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE s;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE t ADD COLUMN y INT DEFAULT nextval('s');
-~~~
-
-~~~
-ERROR: nextval(): unimplemented: cannot evaluate scalar expressions containing sequence operations in this context
-SQLSTATE: 0A000
-~~~
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/42508)
-
-### Available capacity metric in the DB Console
-
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-
-### Schema changes within transactions
-
-{% include {{ page.version.version }}/known-limitations/schema-changes-within-transactions.md %}
-
-### Schema change DDL statements inside a multi-statement transaction can fail while other statements succeed
-
-{% include {{ page.version.version }}/known-limitations/schema-change-ddl-inside-multi-statement-transactions.md %}
-
-### Schema changes between executions of prepared statements
-
-{% include {{ page.version.version }}/known-limitations/schema-changes-between-prepared-statements.md %}
-
-### Size limits on statement input from SQL clients
-
-CockroachDB imposes a hard limit of 16MiB on the data input for a single statement passed to CockroachDB from a client (including the SQL shell). We do not recommend attempting to execute statements from clients with large input.
-
-### Using `\|` to perform a large input in the SQL shell
-
-In the [built-in SQL shell](cockroach-sql.html), using the [`\|`](cockroach-sql.html#commands) operator to perform a large number of inputs from a file can cause the server to close the connection. This is because `\|` sends the entire file as a single query to the server, which can exceed the upper bound on the size of a packet the server can accept from any client (16MB).
-
-As a workaround, [execute the file from the command line](cockroach-sql.html#execute-sql-statements-from-a-file) with `cat data.sql | cockroach sql` instead of from within the interactive shell.
-
-### New values generated by `DEFAULT` expressions during `ALTER TABLE ADD COLUMN`
-
-When executing an [`ALTER TABLE ADD COLUMN`](add-column.html) statement with a [`DEFAULT`](default-value.html) expression, new values generated:
-
-- use the default [search path](sql-name-resolution.html#search-path) regardless of the search path configured in the current session via `SET SEARCH_PATH`.
-- use the UTC time zone regardless of the time zone configured in the current session via [`SET TIME ZONE`](set-vars.html).
-- have no default database regardless of the default database configured in the current session via [`SET DATABASE`](set-vars.html), so you must specify the database of any tables they reference.
-- use the transaction timestamp for the `statement_timestamp()` function regardless of the time at which the `ALTER` statement was issued.
-
-### Load-based lease rebalancing in uneven latency deployments
-
-When nodes are started with the [`--locality`](cockroach-start.html#flags) flag, CockroachDB attempts to place the replica lease holder (the replica that client requests are forwarded to) on the node closest to the source of the request. This means as client requests move geographically, so too does the replica lease holder.
-
-However, you might see increased latency caused by a consistently high rate of lease transfers between datacenters in the following case:
-
-- Your cluster runs in datacenters which are very different distances away from each other.
-- Each node was started with a single tier of `--locality`, e.g., `--locality=datacenter=a`.
-- Most client requests get sent to a single datacenter because that's where all your application traffic is.
-
-To detect if this is happening, open the [DB Console](ui-overview.html), select the **Queues** dashboard, hover over the **Replication Queue** graph, and check the **Leases Transferred / second** data point. If the value is consistently larger than 0, you should consider stopping and restarting each node with additional tiers of locality to improve request latency.
-
-For example, let's say that latency is 10ms from nodes in datacenter A to nodes in datacenter B but is 100ms from nodes in datacenter A to nodes in datacenter C. To ensure A's and B's relative proximity is factored into lease holder rebalancing, you could restart the nodes in datacenter A and B with a common region, `--locality=region=foo,datacenter=a` and `--locality=region=foo,datacenter=b`, while restarting nodes in datacenter C with a different region, `--locality=region=bar,datacenter=c`.
-
-### Overload resolution for collated strings
-
-Many string operations are not properly overloaded for [collated strings](collate.html), for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT 'string1' || 'string2';
-~~~
-
-~~~
-     ?column?
-------------------
-  string1string2
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ('string1' collate en) || ('string2' collate en);
-~~~
-
-~~~
-pq: unsupported binary operator: <collatedstring{en}> || <collatedstring{en}>
-~~~
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/10679)
-
-### Max size of a single column family
-
-When creating or updating a row, if the combined size of all values in a single [column family](column-families.html) exceeds the max range size (512 MiB by default) for the table, the operation may fail, or cluster performance may suffer.
-
-As a workaround, you can either [manually split a table's columns into multiple column families](column-families.html#manual-override), or you can [create a table-specific zone configuration](configure-replication-zones.html#create-a-replication-zone-for-a-table) with an increased max range size.
-
-### Simultaneous client connections and running queries on a single node
-
-When a node has both a high number of client connections and running queries, the node may crash due to memory exhaustion. This is due to CockroachDB not accurately limiting the number of clients and queries based on the amount of available RAM on the node.
-
-To prevent memory exhaustion, monitor each node's memory usage and ensure there is some margin between maximum CockroachDB memory usage and available system RAM. For more details about memory usage in CockroachDB, see [this blog post](https://www.cockroachlabs.com/blog/memory-usage-cockroachdb/).
-
-### Privileges for `DELETE` and `UPDATE`
-
-Every [`DELETE`](delete.html) or [`UPDATE`](update.html) statement constructs a `SELECT` statement, even when no `WHERE` clause is involved. As a result, the user executing `DELETE` or `UPDATE` requires both the `DELETE` and `SELECT` or `UPDATE` and `SELECT` [privileges](authorization.html#assign-privileges) on the table.
-
-### Correlated common table expressions
-
-{% include {{ page.version.version }}/known-limitations/correlated-ctes.md %}
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/42540)
-
-### `ROLLBACK TO SAVEPOINT` in high-priority transactions containing DDL
-
-Transactions with [priority `HIGH`](transactions.html#transaction-priorities) that contain DDL and `ROLLBACK TO SAVEPOINT` are not supported, as they could result in a deadlock. For example:
-
-~~~ sql
-> BEGIN PRIORITY HIGH; SAVEPOINT s; CREATE TABLE t(x INT); ROLLBACK TO SAVEPOINT s;
-~~~
-
-~~~
-ERROR: unimplemented: cannot use ROLLBACK TO SAVEPOINT in a HIGH PRIORITY transaction containing DDL
-SQLSTATE: 0A000
-HINT: You have attempted to use a feature that is not yet implemented.
-See: https://github.com/cockroachdb/cockroach/issues/46414
-~~~
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/46414)
-
-### Concurrent SQL shells overwrite each other's history
-
-The [built-in SQL shell](cockroach-sql.html) stores its command history in a single file by default (`.cockroachsql_history`). When running multiple instances of the SQL shell on the same machine. Therefore, each shell's command history can get overwritten in unexpected ways.
-
-As a workaround, set the `COCKROACH_SQL_CLI_HISTORY` environment variable to different values for the two different shells, for example:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ export COCKROACH_SQL_CLI_HISTORY=.cockroachsql_history_shell_1
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ export COCKROACH_SQL_CLI_HISTORY=.cockroachsql_history_shell_2
-~~~
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/42027)
-
-### Passwords with special characters cannot be passed in connection parameter
-
-CockroachDB does not allow passwords with special characters to be passed as a [connection parameter](connection-parameters.html) to [`cockroach` commands](cockroach-commands.html).
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/35998)
-
-### CockroachDB does not test for all connection failure scenarios
-
-CockroachDB servers rely on the network to report when a TCP connection fails. In most scenarios when a connection fails, the network immediately reports a connection failure, resulting in a `Connection refused` error.
-
-However, if there is no host at the target IP address, or if a firewall rule blocks traffic to the target address and port, a TCP handshake can linger while the client network stack waits for a TCP packet in response to network requests. To work around this kind of scenario, we recommend the following:
-
-- When migrating a node to a new machine, keep the server listening at the previous IP address until the cluster has completed the migration.
-- Configure any active network firewalls to allow node-to-node traffic.
-- Verify that orchestration tools (e.g., Kubernetes) are configured to use the correct network connection information.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/53410)
-
-### Some column-dropping schema changes do not roll back properly
-
-Some [schema changes](online-schema-changes.html) that [drop columns](drop-column.html) cannot be [rolled back](rollback-transaction.html) properly.
-
-In some cases, the rollback will succeed, but the column data might be partially or totally missing, or stale due to the asynchronous nature of the schema change.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/46541)
-
-In other cases, the rollback will fail in such a way that will never be cleaned up properly, leaving the table descriptor in a state where no other schema changes can be run successfully.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/47712)
-
-To reduce the chance that a column drop will roll back incorrectly:
-
-- Perform column drops in transactions separate from other schema changes. This ensures that other schema change failures will not cause the column drop to be rolled back.
-
-- Drop all [constraints](constraints.html) (including [unique indexes](unique.html)) on the column in a separate transaction, before dropping the column.
-
-- Drop any [default values](default-value.html) or [computed expressions](computed-columns.html) on a column before attempting to drop the column. This prevents conflicts between constraints and default/computed values during a column drop rollback.
-
-If you think a rollback of a column-dropping schema change has occurred, check the [jobs table](show-jobs.html). Schema changes with an error prefaced by `cannot be reverted, manual cleanup may be required` might require manual intervention.
-
-### Disk-spilling on joins with `JSON` columns
-
-If the execution of a [join](joins.html) query exceeds the limit set for memory-buffering operations (i.e., the value set for the `sql.distsql.temp_storage.workmem` [cluster setting](cluster-settings.html)), CockroachDB will spill the intermediate results of computation to disk. If the join operation spills to disk, and at least one of the equality columns is of type [`JSON`](jsonb.html), CockroachDB returns the error `unable to encode table key: *tree.DJSON`. If the memory limit is not reached, then the query will be processed without error.
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/35706)
-
-### Disk-spilling not supported for unordered aggregation operations
-
-{% include {{ page.version.version }}/known-limitations/unordered-operations.md %}
-
-### GIN indexes cannot be partitioned
-
-CockroachDB does not support partitioning GIN indexes, including [spatial indexes](spatial-indexes.html).
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/43643)
-
-### GIN index scans can't be generated for some statement filters
-
-CockroachDB cannot generate [GIN index](inverted-indexes.html) scans for statements with filters that have both JSON fetch values and containment operators. For example the following statement won't be index-accelerated:
-
-~~~ sql
-SELECT * FROM mytable WHERE j->'a' @> '{"b": "c"}';
-~~~
-
-CockroachDB v20.1 and earlier would generate index scans for these filters, though it is not recommended as the normalization rules used to convert the filters into JSON containment expressions would sometimes produce inequivalent expressions.
-
-The workaround is to rewrite the statement filters to avoid using both JSON fetch values and containment operators. The following statement is index-accelerated and equivalent to the non-accelerated statement above:
-
-~~~ sql
-SELECT * FROM mytable WHERE j @> '{"a": {"b": "c"}}'
-~~~
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/55318)
diff --git a/src/current/v20.2/kubernetes-performance.md b/src/current/v20.2/kubernetes-performance.md
deleted file mode 100644
index 5d4403be687..00000000000
--- a/src/current/v20.2/kubernetes-performance.md
+++ /dev/null
@@ -1,601 +0,0 @@
----
-title: CockroachDB Performance on Kubernetes
-summary: How running CockroachDB in Kubernetes affects its performance and how to get the best possible performance when running in Kubernetes.
-toc: true
----
-
-Kubernetes provides many useful abstractions for deploying and operating distributed systems, but some of the abstractions come with a performance overhead and an increase in underlying system complexity. This page explains potential bottlenecks to be aware of when [running CockroachDB in Kubernetes](orchestrate-cockroachdb-with-kubernetes.html) and shows you how to optimize your deployment for better performance.
-
-<div id="toc"></div>
-
-## Prerequisites
-
-Before you focus on optimizing a Kubernetes-orchestrated CockroachDB cluster:
-
-1. Go through the documentation for [running a CockroachDB cluster on Kubernetes](orchestrate-cockroachdb-with-kubernetes.html) to familiarize yourself with the necessary Kubernetes terminology and deployment abstractions.
-2. Verify that CockroachDB performs up to your requirements for your workload on identical hardware without Kubernetes. You may find that you need to [modify your workload](performance-best-practices-overview.html) or use [different machine specs](recommended-production-settings.html#hardware) to achieve the performance you need, and it's better to determine that up front than after spending a bunch of time trying to optimize your Kubernetes deployment.
-
-## Performance factors
-
-There are a number of independent factors that affect the performance you observe when running CockroachDB on Kubernetes. Some are more significant than others or easier to fix than others, so feel free to pick and choose the improvements that best fit your situation. Note that most of these changes are easiest to make before you create your CockroachDB cluster. If you already have a running CockroachDB cluster in Kubernetes that you need to modify while keeping it running, extra work may be needed and extra care and testing is strongly recommended.
-
-In a number of the sections below, we have shown how to modify excerpts from our provided Kubernetes configuration YAML files. You can find the most up-to-date versions of these files on Github, [one for running CockroachDB in secure mode](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/cockroachdb-statefulset-secure.yaml) and one for [running CockroachDB in insecure mode](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/cockroachdb-statefulset.yaml).
-
-You can also use a [performance-optimized configuration file for secure mode](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/performance/cockroachdb-statefulset-secure.yaml) or [insecure mode](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/performance/cockroachdb-statefulset-insecure.yaml). Be sure to modify the file wherever there is a `TODO` comment.
-
-### Version of CockroachDB
-
-Because CockroachDB is under very active development, there are typically substantial performance gains in each release. If you aren't running the latest release and aren't getting the performance you desire, you should try the latest and see how much it helps.
-
-### Client workload
-
-Your workload is the single most important factor in database performance. Read through our [SQL performance best practices](performance-best-practices-overview.html) to determine whether there are any easy changes that you can make to speed up your application.
-
-### Machine size
-
-The size of the machines you're using isn't a Kubernetes-specific concern, but it's always a good place to start if you want more performance. See our [hardware recommendations](recommended-production-settings.html#hardware) for specific suggestions, but using machines with more CPU will almost always allow for greater throughput. Be aware that because Kubernetes runs a set of processes on every machine in a cluster, you typically will get more bang for your buck by using fewer large machines than more small machines.
-
-### Disk type
-
-CockroachDB makes heavy use of the disks you provide it, so using faster disks is an easy way to improve your cluster's performance. Our provided configuration does not specify what type of disks it wants, so in most environments Kubernetes will auto-provision disks of the default type. In the common cloud environments (AWS, GCP, Azure) this means you'll get slow disks that aren't optimized for database workloads (e.g.,HDDs on GCE, SSDs without provisioned IOPS on AWS). However, we [strongly recommend using SSDs](recommended-production-settings.html#hardware) for the best performance, and Kubernetes makes it relatively easy to use them.
-
-#### Creating a different disk type
-
-Kubernetes exposes the disk types used by its volume provisioner via its [`StorageClass` API object](https://kubernetes.io/docs/concepts/storage/storage-classes/). Each cloud environment has its own default `StorageClass`, but you can easily change the default or create a new named class which you can then ask for when asking for volumes. To do this, pick the type of volume provisioner you want to use from the list in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/storage-classes/), take the example YAML file they provide, modify it to have the disk type you want, then run `kubectl create -f <your-storage-class-file.yaml>`. For example, in order to use the `pd-ssd` disk type on Google Compute Engine or Google Kubernetes Engine, you can use a `StorageClass` file like this:
-
-~~~ yaml
-apiVersion: storage.k8s.io/v1
-kind: StorageClass
-metadata:
-  name: <your-ssd-class-name>
-provisioner: kubernetes.io/gce-pd
-parameters:
-  type: pd-ssd
-~~~
-
-You can then use this new disk type either by configuring the CockroachDB YAML file to request it or by making it the default. You may also want to set additional parameters as documented in the list of Kubernetes storage classes, such as configuring the `iopsPerGB` if you're creating a `StorageClass` for AWS's `io1` Provisioned IOPS volume type.
-
-#### Configuring the disk type used by CockroachDB
-
-To use a new `StorageClass` without making it the default in your cluster, you have to modify your application's YAML file to ask for it. In the CockroachDB `StatefulSet` configuration, that means adding a line to its `VolumeClaimTemplates` section. For example, that would mean taking these lines of the CockroachDB config file:
-
-~~~ yaml
-  volumeClaimTemplates:
-  - metadata:
-      name: datadir
-    spec:
-      accessModes:
-        - "ReadWriteOnce"
-      resources:
-        requests:
-          storage: 1Gi
-~~~
-
-And adding a `storageClassName` field to the `spec`, changing them to:
-
-~~~ yaml
-  volumeClaimTemplates:
-  - metadata:
-      name: datadir
-    spec:
-      accessModes:
-        - "ReadWriteOnce"
-      storageClassName: <your-ssd-class-name>
-      resources:
-        requests:
-          storage: 1Gi
-~~~
-
-If you make this change then run `kubectl create -f` on your YAML file, Kubernetes should create volumes for you using your new `StorageClass`.
-
-#### Changing the default disk type
-
-If you want your new `StorageClass` to be the default for all volumes in your cluster, you have to run a couple of commands to inform Kubernetes of what you want. First, get the names of your `StorageClass`es. Then remove the current default and add yours as the new default.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kubectl get storageclasses
-~~~
-
-~~~
-NAME                 PROVISIONER
-ssd                  kubernetes.io/gce-pd
-standard (default)   kubernetes.io/gce-pd
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'
-~~~
-
-~~~
-storageclass "standard" patched
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kubectl patch storageclass ssd -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
-~~~
-
-~~~
-storageclass "ssd" patched
-~~~
-
-Note that if you are running an older version of Kubernetes, you may need to use a beta version of the annotation instead of the form used above. In particular, on v1.8 of Kubernetes you need to use `storageclass.beta.kubernetes.io/is-default-class`. To determine for sure which to use, run `kubectl describe storageclass` and copy the annotation used by the current default.
-
-### Disk size
-
-On some cloud providers (notably including all GCP disks and the AWS io1 disk type), the number of IOPS available to a disk is directly correlated to the size of the disk. In such cases, increasing the size of your disks can make for significantly better CockroachDB performance, as well as less risk of filling them up. Doing so is easy -- before you create your CockroachDB cluster, modify the `VolumeClaimTemplate` in the CockroachDB YAML file to ask for more space. For example, to give each CockroachDB instance 1TB of disk space, you'd change:
-
-~~~ yaml
-  volumeClaimTemplates:
-  - metadata:
-      name: datadir
-    spec:
-      accessModes:
-        - "ReadWriteOnce"
-      resources:
-        requests:
-          storage: 1Gi
-~~~
-
-To instead be:
-
-~~~ yaml
-  volumeClaimTemplates:
-  - metadata:
-      name: datadir
-    spec:
-      accessModes:
-        - "ReadWriteOnce"
-      resources:
-        requests:
-          storage: 1024Gi
-~~~
-
-Since [GCE disk IOPS scale linearly with disk size](https://cloud.google.com/compute/docs/disks/performance#type_comparison), a 1TiB disk gives 1024 times as many IOPS as a 1GiB disk, which can make a very large difference for write-heavy workloads.
-
-### Local disks
-
-Up to this point, we have been assuming that you will be running CockroachDB in a `StatefulSet`, using auto-provisioned remotely attached disks. However, using local disks typically provides better performance than remotely attached disks, such as SSD Instance Store Volumes instead of EBS Volumes on AWS or Local SSDs instead of Persistent Disks on GCE. `StatefulSet`s have historically not supported using local disks, but [beta support for using "local" `PersistentVolume`s was added in Kubernetes v1.10](https://kubernetes.io/docs/concepts/storage/volumes/#local). We do not recommend using this for production data until the feature is more mature, but it's a promising development.
-
-There is also the option of using local disks if you do not run CockroachDB in a `StatefulSet`, but instead use a `DaemonSet`. For more details on what this entails, see the section on [Running in a DaemonSet](#running-in-a-daemonset).
-
-Note that when running with local disks, there is a greater chance of experiencing a disk failure than when using the cloud providers' network-attached disks that are often replicated underneath the covers. Consequently, you may want to [configure replication zones](configure-replication-zones.html) to increase the replication factor of your data to 5 from its default of 3 when using local disks.
-
-### Resource requests and limits
-
-When you ask Kubernetes to run a pod, either directly or indirectly through another resource type such as a `StatefulSet`, you can tell it to reserve certain amounts of CPU and/or memory for each container in the pod or to limit the CPU and/or memory of each container. Doing one or both of these can have different implications depending on how utilized your Kubernetes cluster is. For the authoritative information on this topic, see the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/).
-
-#### Resource requests
-
-Resource requests allow you to reserve a certain amount of CPU or memory for your container. If you add resource requests to your CockroachDB YAML file, Kubernetes will schedule each CockroachDB pod onto a node with sufficient unreserved resources and will ensure the pods are guaranteed the reserved resources using the applicable Linux container primitives. If you are running other workloads in your Kubernetes cluster, setting resource requests is very strongly recommended to ensure good performance, because if you do not set them then CockroachDB could be starved of CPU cycles or OOM stopped before less important processes.
-
-To determine how many resources are usable on your Kubernetes nodes, you can run:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kubectl describe nodes
-~~~
-
-~~~
-Name:               gke-perf-default-pool-aafee20c-k4t8
-[...]
-Capacity:
- cpu:     4
- memory:  15393536Ki
- pods:    110
-Allocatable:
- cpu:     3920m
- memory:  12694272Ki
- pods:    110
-[...]
-Non-terminated Pods:         (2 in total)
-  Namespace                  Name                                              CPU Requests  CPU Limits  Memory Requests  Memory Limits
-  ---------                  ----                                              ------------  ----------  ---------------  -------------
-  kube-system                kube-dns-778977457c-kqtlr                         260m (6%)     0 (0%)      110Mi (0%)       170Mi (1%)
-  kube-system                kube-proxy-gke-perf-default-pool-aafee20c-k4t8    100m (2%)     0 (0%)      0 (0%)           0 (0%)
-Allocated resources:
-  (Total limits may be over 100 percent, i.e., overcommitted.)
-  CPU Requests  CPU Limits  Memory Requests  Memory Limits
-  ------------  ----------  ---------------  -------------
-  360m (9%)     0 (0%)      110Mi (0%)       170Mi (1%)
-~~~
-
-This will output a lot of information for each of the nodes in your cluster, but if you focus in on the right parts you'll see how many "allocatable" resources are available on each node and how many resources are already being used by other pods. The "allocatable" resources are how much CPU and memory Kubernetes is willing to provide to pods running on the machine. The difference between the node's "capacity" and its "allocatable" resources is taken up by the operating system and Kubernetes' management processes. The "m" in "3920m" stands for "milli-CPUs", meaning "thousandths of a CPU".
-
-You'll also see a number of pods running here that you may not have realized were in your cluster. Kubernetes runs a handful of pods in the `kube-system` namespace that are part of the cluster infrastructure. These may make it tough to attempt to reserve all the allocatable space on your nodes for CockroachDB, since some of them are essential for the Kubernetes cluster's health. If you want to run CockroachDB on every node in your cluster, you'll have to leave room for these processes. If you are only running CockroachDB on a subset of the nodes in your cluster, you can choose to take up all the "allocatable" space other than what is being used by the `kube-system` pods that are on all the nodes in the cluster, such as `kube-proxy` or the `fluentd` logging agent.
-
-Note that it will be difficult to truly use up all of the allocatable space in the current versions of Kubernetes (v1.10 or older) because you'd have to manually preempt the `kube-system` pods that are already on the nodes you want CockroachDB to run on (by deleting them). This should become easier in future versions of Kubernetes when its [Pod Priority](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) feature gets promoted from alpha to beta. Once that feature is more widely available, you could set the CockroachDB pods to a higher priority, causing the Kubernetes scheduler to preempt and reschedule the `kube-system` pods onto other machines.
-
-Once you've picked out an amount of CPU and memory to reserve for Cockroach, you'll have to configure the resource request in your CockroachDB YAML file. They should go underneath the `containers` heading. For example, to use most of the available resources on the machines described above, you'd change these lines of your YAML config file:
-
-~~~ yaml
-      containers:
-      - name: cockroachdb
-        image: {{page.release_info.docker_image}}:{{page.release_info.version}}
-        imagePullPolicy: IfNotPresent
-        ports:
-        - containerPort: 26257
-          name: grpc
-        - containerPort: 8080
-          name: http
-~~~
-
-To be:
-
-~~~ yaml
-      containers:
-      - name: cockroachdb
-        image: {{page.release_info.docker_image}}:{{page.release_info.version}}
-        imagePullPolicy: IfNotPresent
-        resources:
-          requests:
-            cpu: "3500m"
-            memory: "12300Mi"
-        ports:
-        - containerPort: 26257
-          name: grpc
-        - containerPort: 8080
-          name: http
-~~~
-
-When you create the `StatefulSet`, you'll want to check to make sure that all the CockroachDB pods are scheduled successfully. If you see any get stuck in the pending state, run `kubectl describe pod <podname>` and check the `Events` for information about why they're still pending. You may need to manually preempt pods on one or more nodes by running `kubectl delete pod` on them to make room for the CockroachDB pods. As long as the pods you delete were created by a higher-level Kubernetes object such as a `Deployment` or a `StatefulSet`, they'll be safely recreated on another node.
-
-#### Resource limits
-
-Resource limits are conceptually similar to resource requests, but serve a different purpose. They let you cap the resources used by a pod to no more than the provided limit, which can have a couple of different uses. For one, it makes for more predictable performance because your pods will not be allowed to use any excess capacity on their machines, meaning that they will not have more resources available to them at some times (during lulls in traffic) than others (busy periods where the other pods on a machine are also fully utilizing their reserved resources). Secondly, it also increases the ["Quality of Service" guaranteed by the Kubernetes runtime](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/resource-qos.md) on Kubernetes versions 1.8 and below, making the pods less likely to be preempted when a machine is oversubscribed. Finally, memory limits in particular limit the amount of memory that the container knows is available to it, which help when you specify percentages for the CockroachDB `--cache` and `--max-sql-memory` flags, as our default configuration file does.
-
-Setting resource limits works about the same as setting resource requests. If you wanted to set resource limits in addition to requests on the config from the [Resource Requests](#resource-requests) section above, you'd change the config to:
-
-~~~ yaml
-      containers:
-      - name: cockroachdb
-        image: {{page.release_info.docker_image}}:{{page.release_info.version}}
-        imagePullPolicy: IfNotPresent
-        resources:
-          requests:
-            cpu: "3500m"
-            memory: "12300Mi"
-          limits:
-            cpu: "3500m"
-            memory: "12300Mi"
-        ports:
-        - containerPort: 26257
-          name: grpc
-        - containerPort: 8080
-          name: http
-~~~
-
-The pods would then be restricted to only use the resource they have reserved and guaranteed to not be preempted except in very exceptional circumstances. This typically will not give you better performance on an under-utilized Kubernetes cluster, but will give you more predictable performance as other workloads are run.
-
-{{site.data.alerts.callout_danger}}While setting memory limits is strongly recommended, <a href="https://github.com/kubernetes/kubernetes/issues/51135">setting CPU limits can hurt tail latencies as currently implemented by Kubernetes</a>. We recommend not setting CPU limits at all unless you have explicitly enabled the non-default <a href="https://kubernetes.io/docs/tasks/administer-cluster/cpu-management-policies/#static-policy">Static CPU Management Policy</a> when setting up your Kubernetes cluster, and even then only setting integer (non-fractional) CPU limits and memory limits exactly equal to the corresponding requests.{{site.data.alerts.end}}
-
-#### Default resource requests and limits
-
-Note that even if you do not manually set resource requests yourself, you're likely unknowingly using them anyways. In many installations of Kubernetes, a [`LimitRange`](https://kubernetes.io/docs/tasks/administer-cluster/cpu-default-namespace/) is preconfigured for the `default` namespace that applies a default CPU request of `100m`, or one-tenth of a CPU. You can see this configuration by running
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kubectl describe limitranges
-~~~
-
-~~~
-Name:       limits
-Namespace:  default
-Type        Resource  Min  Max  Default Request  Default Limit  Max Limit/Request Ratio
-----        --------  ---  ---  ---------------  -------------  -----------------------
-Container   cpu       -    -    100m             -              -
-~~~
-
-Experimentally, this does not appear to have a noticeable effect on CockroachDB's performance when a Kubernetes cluster isn't heavily utilized, but do not be surprised if you see CPU requests on your pods that you didn't set.
-
-### Other pods on the same machines as CockroachDB
-
-As discovered in the above section on [Resource Requests and Limits](#resource-requests-and-limits), there will always be pods other than just CockroachDB running in your Kubernetes cluster, even if you do not create any other pods of your own. You can see them at any time by running:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kubectl get pods --all-namespaces
-~~~
-
-~~~
-NAMESPACE     NAME                                             READY     STATUS    RESTARTS   AGE
-kube-system   event-exporter-v0.1.7-5c4d9556cf-6v7lf           2/2       Running   0          2m
-kube-system   fluentd-gcp-v2.0.9-6rvmk                         2/2       Running   0          2m
-kube-system   fluentd-gcp-v2.0.9-m2xgp                         2/2       Running   0          2m
-kube-system   fluentd-gcp-v2.0.9-sfgps                         2/2       Running   0          2m
-kube-system   fluentd-gcp-v2.0.9-szwwn                         2/2       Running   0          2m
-kube-system   heapster-v1.4.3-968544ffd-5tsb8                  3/3       Running   0          1m
-kube-system   kube-dns-778977457c-4s7vv                        3/3       Running   0          1m
-kube-system   kube-dns-778977457c-ls6fq                        3/3       Running   0          2m
-kube-system   kube-dns-autoscaler-7db47cb9b7-x2cc4             1/1       Running   0          2m
-kube-system   kube-proxy-gke-test-default-pool-828d39a7-dbn0   1/1       Running   0          2m
-kube-system   kube-proxy-gke-test-default-pool-828d39a7-nr06   1/1       Running   0          2m
-kube-system   kube-proxy-gke-test-default-pool-828d39a7-rc4m   1/1       Running   0          2m
-kube-system   kube-proxy-gke-test-default-pool-828d39a7-trd1   1/1       Running   0          2m
-kube-system   kubernetes-dashboard-768854d6dc-v7ng8            1/1       Running   0          2m
-kube-system   l7-default-backend-6497bcdb4d-2kbh4              1/1       Running   0          2m
-~~~
-
-These ["cluster add-ons"](https://github.com/kubernetes/kubernetes/tree/master/cluster/addons) provide a variety of basic services like managing DNS entries for services within the cluster, powering the Kubernetes dashboard UI, or collecting logs or metrics from all the pods running in the cluster. If you do not like having them take up space in your cluster, you can prevent some of them from running by configuring your Kubernetes cluster appropriately. For example, on GKE, you can create a cluster with the minimal set of addons by running:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ gcloud container clusters create <your-cluster-name> --no-enable-cloud-logging --no-enable-cloud-monitoring --addons=""
-~~~
-
-However, essentials like `kube-proxy` and `kube-dns` are effectively required to have a compliant Kubernetes cluster. This means that you'll always have some pods that aren't yours running in your cluster, so it's important to understand and account for the possible effects of CockroachDB having to share a machine with other processes. The more processes there are on the same machine as a CockroachDB pod, the worse and less predictable its performance will likely be. To protect against this, it's strongly recommended to run with [Resource Requests](#resource-requests) on your CockroachDB pods to provide some level of CPU and memory isolation.
-
-Setting resource requests isn't a panacea, though. There can still be contention for shared resources like network I/O or, in [exceptional](https://sysdig.com/blog/container-isolation-gone-wrong/) cases, internal kernel data structures. For these reasons and because of the Kubernetes infrastructure processes running on each machine, CockroachDB running on Kubernetes simply cannot reach quite the same levels of performance as running directly on dedicated machines. Thankfully, it can at least get quite close if you use Kubernetes wisely.
-
-If for some reason setting appropriate resource requests still isn't getting you the performance you expect, you might want to consider going all the way to [dedicated nodes](#dedicated-nodes).
-
-#### Client applications on the same machines as CockroachDB
-
-Running client applications such as benchmarking applications on the same machines as CockroachDB can be even worse than just having Kubernetes system pods on the same machines. They are very likely to end up competing for resources, because when the applications get more loaded than usual, so will the CockroachDB processes. The best way to avoid this is to [set resource requests and limits](#resource-requests-and-limits), but if you are unwilling or unable to do that for some reason, you can also set [anti-affinity scheduling policies](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) on your client applications. Anti-affinity policies are placed in the pod spec, so if you wanted to change our provided example load generator app, you'd change [these lines](https://github.com/cockroachdb/cockroach/blob/98c506c48f3517d1ac1aadb6a09e1b23ad672c37/cloud/kubernetes/example-app.yaml#L11-L12):
-
-~~~ yaml
-    spec:
-      containers:
-~~~
-
-To be:
-
-~~~ yaml
-    spec:
-      affinity:
-        podAntiAffinity:
-          preferredDuringSchedulingIgnoredDuringExecution:
-          - weight: 100
-            podAffinityTerm:
-              labelSelector:
-                matchExpressions:
-                - key: app
-                  operator: In
-                  values:
-                  - loadgen
-              topologyKey: kubernetes.io/hostname
-          - weight: 99
-            podAffinityTerm:
-              labelSelector:
-                matchExpressions:
-                - key: app
-                  operator: In
-                  values:
-                  - cockroachdb
-              topologyKey: kubernetes.io/hostname
-      containers:
-~~~
-
-This configuration will first prefer to put the `loadgen` pods on different nodes from each other, which is important for the fault tolerance of the `loadgen` pods themselves. As a secondary priority, it will attempt to put the pods on nodes that do not already have a running `CockroachDB` pod. This will ensure the best possible balance of fault tolerance and performance for the load generator and CockroachDB cluster.
-
-### Networking
-
-[Kubernetes asks a lot of the network that it runs on](https://kubernetes.io/docs/concepts/cluster-administration/networking/) in order to provide a routable IP address and an isolated Linux network namespace to each pod in the cluster, among its other requirements. While this document isn't nearly large enough to properly explain the details, and those details themselves can depend heavily on specifically how you have set up the network for your cluster, it suffices to say that Docker and Kubernetes' networking abstractions often come with a performance penalty for high-throughput distributed applications such as CockroachDB.
-
-If you really want to eke more performance out of your cluster, networking is a good target to at least experiment with. You can either replace your cluster's networking solution with a more performant one or bypass most of the networking overhead by using the host machines' networks directly.
-
-#### Networking solutions
-
-If you aren't using a hosted Kubernetes service, you'll typically have to choose how to set up the network when you're creating a Kubernetes cluster. There are [a lot of solutions out there](https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-achieve-this), and they can have significantly different performance characteristics and functionality. We do not endorse any networking software or configurations in particular, but want to call out that your choice can have a meaningful affect on performance compared to running CockroachDB outside of Kubernetes.
-
-#### Using the host's network
-
-If you are already content with your cluster's networking setup or do not want to have to mess with it, Kubernetes does offer an escape hatch for exceptional cases that lets you avoid network performance overhead -- the `hostNetwork` setting, which allows you to run pods using their host machine's network directly and bypass the layers of abstraction. This comes with a number of downsides, of course. For example, two pods using `hostNetwork` on the same machine cannot use the same ports, and it also can have serious security implications if your machines are reachable on the public Internet. If you want to give it a try, though, to see what effects it has for your workload, you just have to add two lines to the CockroachDB YAML configuration file and to any client applications that desperately need better performance, changing:
-
-~~~ yaml
-    spec:
-      affinity:
-~~~
-
-To be:
-
-~~~ yaml
-    spec:
-      hostNetwork: true
-      dnsPolicy: ClusterFirstWithHostNet
-      affinity:
-~~~
-
-`hostNetwork: true` tells Kubernetes to put the pods in the host machine's network namespace, using its IP address, hostname, and entire networking stack. The `dnsPolicy: ClusterFirstWithHostNet` line tells Kubernetes to configure the pods to still be able to use the cluster's DNS infrastructure for service discovery.
-
-This will not work miracles, so use it with caution. In our testing, it pretty reliably gives about a 6% improvement in database throughput when running [our `kv` load generator](https://hub.docker.com/r/cockroachdb/loadgen-kv/) against a 3-node cluster on GKE.
-
-### Running in a DaemonSet
-
-In all of the examples so far, we've been using the standard CockroachDB `StatefulSet` configuration file and tweaking it slightly. An alternative that comes with a different set of tradeoffs is to completely switch from using a `StatefulSet` for orchestration to using a `DaemonSet`. A [`DaemonSet`](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) is a Kubernetes type that runs a pod on all nodes matching some selection criteria.
-
-This comes with a few main benefits: It's a more natural abstraction for cordoning off onto [dedicated nodes](#dedicated-nodes), it naturally pairs with [using the host's network](#using-the-hosts-network) since you're already coupling CockroachDB processes one-to-one with nodes, and it allows you to use [local disks](#local-disks) without relying on the beta support for using local disks with `StatefulSets`. The biggest tradeoff is that you're limiting Kubernetes' ability to help your cluster recover from failures. It cannot create new pods to replace pods on nodes that fail because it's already running a CockroachDB pod on all the matching nodes. This matches the behavior of running CockroachDB directly on a set of physical machines that are only manually replaced by human operators.
-
-To set up a CockroachDB `DaemonSet`:
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="secure">
-
-1. [Start Kubernetes](orchestrate-cockroachdb-with-kubernetes.html#step-1-start-kubernetes), as described in the tutorial on using the `StatefulSet` feature.
-
-2. Download the [`cockroachdb-daemonset-secure.yaml`](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/performance/cockroachdb-daemonset-secure.yaml) configuration file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl -O https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/performance/cockroachdb-deamonset-secure.yaml
-    ~~~
-
-3. Modify the file wherever there is a `TODO` comment, for example:
-    - If you do CockroachDB running on every machine, remove the `nodeSelector` and `tolerations` sections. Otherwise, pick out which nodes you want to run CockroachDB on using either [node labels](#node-labels) or [node taints](#node-taints) and then configure them and the `DaemonSet` configuration file appropriately as described in the relevant [Dedicated Nodes](#dedicated-nodes) section.
-    - Set the addresses in the CockroachDB `--join` flag in the configuration file. The file defaults to [using the host's network](#using-the-hosts-network), so we need to use the host machines' IP addresses or hostnames as join addresses. Pick out two or three of them to include and replace the placeholder values in the configuration file. Be aware that if the machines you choose are removed from the Kubernetes cluster, you will need to update your `--join` flag values or else new CockroachDB instances will not be able to join the cluster.
-    - Pick out the directory from the host that you would like to store CockroachDB's data in and replace the `path: /tmp/cockroach-data` line in the configuration file with your desired directory. If you're using local SSD, this should be wherever the SSDs are mounted on the machines.
-
-4. Use the configuration file to create the `DaemonSet` and start the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create -f cockroachdb-daemonset-secure.yaml
-    ~~~
-
-5. [Manually check and approve each node's certificates](orchestrate-cockroachdb-with-kubernetes.html#step-2-start-cockroachdb), as described in the tutorial on using the `StatefulSet` feature.
-
-6. [Use the `cluster-init-secure.yaml` file to initialize the cluster](orchestrate-cockroachdb-with-kubernetes.html#step-2-start-cockroachdb), as described in the tutorial on using the `StatefulSet` feature.
-
-    For the initialization step to work, you will need to change the address on the `--host=cockroachdb-0.cockroach` line from `cockroachdb-0.cockroach` to the address of one of your nodes.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="insecure">
-
-1. [Start Kubernetes](orchestrate-cockroachdb-with-kubernetes-insecure.html#step-1-start-kubernetes) as described in the tutorial on using the `StatefulSet` feature.
-
-2. Download the [`cockroachdb-daemonset-insecure.yaml`](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/performance/cockroachdb-daemonset-insecure.yaml) configuration file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl -O https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/performance/cockroachdb-deamonset-insecure.yaml
-    ~~~
-
-3. Modify the file wherever there is a `TODO` comment, for example:
-    - If you do want CockroachDB running on every machine, just remove the `nodeSelector` and `tolerations` sections. Otherwise, pick out which nodes you want to run CockroachDB on using either [node labels](#node-labels) or [node taints](#node-taints) and then configure them and the `DaemonSet` configuration file appropriately as described in the relevant [Dedicated Nodes](#dedicated-nodes) section.
-    - Set the addresses in the CockroachDB `--join` flag in the configuration file. The file defaults to [using the host's network](#using-the-hosts-network), so we need to use the host machines' IP addresses or hostnames as join addresses. Pick out two or three of them to include and replace the placeholder values in the configuration file. Be aware that if the machines you choose are removed from the Kubernetes cluster, you will need to update your `--join` flag values or else new CockroachDB instances will not be able to join the cluster.
-    - Pick out the directory from the host that you would like to store CockroachDB's data in and replace the `path: /tmp/cockroach-data` line in the configuration file with your desired directory. If you're using local SSD, this should be wherever the SSDs are mounted on the machines.
-
-4. Use the configuration file to create the `DaemonSet` and start the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create -f cockroachdb-daemonset-insecure.yaml
-    ~~~
-
-5. Initialize the cluster, specifying any one of the pod names:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl exec -it <pod-name> -- ./cockroach init --insecure
-    ~~~
-
-</section>
-
-### Dedicated nodes
-
-If your Kubernetes cluster is made up of heterogeneous hardware, it's likely that you'd like to make sure CockroachDB only runs on certain machines. If you want to get as much performance as possible out of a set of machines, you might also want to make sure that nothing other than CockroachDB is run on them.
-
-#### Node labels
-
-Node labels and node selectors are a way to tell Kubernetes which nodes you want a pod to be allowed on. To label a node, you can just use the `kubectl label node` command as such, substituting in your node's name and your preferred key-value pair for the label:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kubectl label node <node-name> <key>=<value>
-~~~
-
-Some Kubernetes installation tools allow you to automatically apply labels to certain nodes. For example, when creating a new [GKE Node Pool](https://cloud.google.com/kubernetes-engine/docs/concepts/node-pools), you can use the `--node-labels` flag to the `gcloud container node-pools create` command.
-
-Once you do set up labels for all the nodes you want, you can then [use a `NodeSelector`](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector) to control where your pods are allowed to be scheduled. For example, in the `DaemonSet` file from the above example, you would change the lines:
-
-~~~ yaml
-    spec:
-      hostNetwork: true
-      containers:
-~~~
-
-To be:
-
-~~~ yaml
-    spec:
-      nodeSelector:
-        <key>: <value>
-      hostNetwork: true
-      containers:
-~~~
-
-#### Node taints
-
-Alternatively, if you want to make sure that CockroachDB is the only thing running on a set of machines, you're better off using a pair of complementary features called [`Taints` and `Tolerations`](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) to instruct Kubernetes not to schedule anything else on them. You can set them up in a very similar fashion to how you can set up node labels and node selectors:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ kubectl taint node <node-name> <key>=<value>:NoSchedule
-~~~
-
-Just like for [node labels](#node-labels), some Kubernetes installation tools allow you to automatically apply taints to certain nodes. For example, when creating a new [GKE Node Pool](https://cloud.google.com/kubernetes-engine/docs/concepts/node-pools), you can use the `--node-taints` flag to the `gcloud container node-pools create` command.
-
-Once you have applied the appropriate `Taint`s to each machine you want to only run CockroachDB, add the corresponding `Toleration`s to your CockroachDB config file. For example, in the `DaemonSet` file from the above example, you would change the lines:
-
-~~~ yaml
-    spec:
-      hostNetwork: true
-      containers:
-~~~
-
-To be:
-
-~~~ yaml
-    spec:
-      tolerations:
-      - key: <key>
-        operator: "Equal"
-        value: <value>
-        effect: "NoSchedule"
-      hostNetwork: true
-      containers:
-~~~
-
-Note that this will only prevent non-CockroachDB pods from running on these machines. It will not prevent CockroachDB from running on all the other machines, so in most cases you would also pair corresponding [node labels](#node-labels) and node selectors with them to create truly dedicated nodes, making for a resulting config file snippet that looks like:
-
-
-~~~ yaml
-    spec:
-      tolerations:
-      - key: <key>
-        operator: "Equal"
-        value: <value>
-        effect: "NoSchedule"
-      nodeSelector:
-        <key>: <value>
-      hostNetwork: true
-      containers:
-~~~
-
-## Modifying an existing CockroachDB cluster
-
-Kubernetes makes it easy to modify some, but not all, of an existing resource's configuration. Certain changes are easy, such as changing the CPU and memory requests, adding nodes to a cluster, or upgrading to a new CockroachDB Docker image. Others are very difficult and error prone to do in-place, such as changing from a `StatefulSet` to a `DaemonSet`. To update a resource's configuration, there are a few commands available to you.
-
-* If you have configuration files with the desired modifications in them, you can just run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl apply -f <your-file>.yaml
-    ~~~
-* If you want to open up a text editor and manually make the desired changes to your `StatefulSet`'s YAML configuration file, run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl edit statefulset cockroachdb
-    ~~~
-
-    For a `DaemonSet`, run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl edit daemonset cockroachdb
-    ~~~
-
-* If you want a one-liner, construct the appropriate JSON and run something like:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl patch statefulset cockroachdb --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"{{page.release_info.docker_image}}:VERSION"}]
-    ~~~
-
-See [the Kubernetes documentation on in-place updates](https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#in-place-updates-of-resources) or the `kubectl <command> --help` output for more information on these commands.
-
-
-## See also
-
-- [Orchestrate CockroachDB with Kubernetes](orchestrate-cockroachdb-with-kubernetes.html)
-- [Production Checklist](recommended-production-settings.html)
-- [SQL Performance Best Practices](performance-best-practices-overview.html)
-- [Troubleshooting Performance Issues](query-behavior-troubleshooting.html)
diff --git a/src/current/v20.2/learn-cockroachdb-sql.md b/src/current/v20.2/learn-cockroachdb-sql.md
deleted file mode 100644
index 4043bf1f1aa..00000000000
--- a/src/current/v20.2/learn-cockroachdb-sql.md
+++ /dev/null
@@ -1,351 +0,0 @@
----
-title: Learn CockroachDB SQL
-summary: Learn some of the most essential CockroachDB SQL statements on a local cluster.
-toc: true
----
-
-This tutorial walks you through some of the most essential CockroachDB SQL statements using an interactive SQL shell connected to a temporary, single-node CockroachDB cluster.
-
-For a complete list of supported SQL statements and related details, see [SQL Statements](sql-statements.html).
-
-## Start CockroachDB
-
-If you haven't already, [install CockroachDB](install-cockroachdb.html).
-
-Then run the [`cockroach demo`](cockroach-demo.html) command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo
-~~~
-
-This starts a single-node, temporary cluster with the [`movr`](movr.html) dataset pre-loaded.
-
-## Show tables
-
-To see all tables in the active database, use the [`SHOW TABLES`](show-tables.html) statement or the `\dt` [shell command](cockroach-sql.html#commands):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-## Create a table
-
-Suppose that you want MovR to offer ride-sharing services, in addition to vehicle-sharing services. You'll need to add a table for drivers to the `movr` database. To create a table, use [`CREATE TABLE`](create-table.html) followed by a table name, the column names, and the [data type](data-types.html) and [constraint](constraints.html), if any, for each column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE drivers (
-    id UUID NOT NULL,
-    city STRING NOT NULL,
-    name STRING,
-    dl STRING UNIQUE,
-    address STRING,
-    CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-Table and column names must follow [these rules](keywords-and-identifiers.html#identifiers). Also, when you do not explicitly define a [primary key](primary-key.html), CockroachDB will automatically add a hidden `rowid` column as the primary key.
-
-To avoid an error in case the table already exists, you can include `IF NOT EXISTS`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS drivers (
-    id UUID NOT NULL,
-    city STRING NOT NULL,
-    name STRING,
-    dl STRING UNIQUE,
-    address STRING,
-    CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-To show all of the columns from a table, use the [`SHOW COLUMNS FROM <table>`](show-columns.html) statement or the `\d <table>` [shell command](cockroach-sql.html#commands):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM drivers;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  city        | STRING    |    false    | NULL           |                       | {primary} |   false
-  name        | STRING    |    true     | NULL           |                       | {}        |   false
-  dl          | STRING    |    true     | NULL           |                       | {}        |   false
-  address     | STRING    |    true     | NULL           |                       | {}        |   false
-(5 rows)
-~~~
-
-
-## Insert rows
-
-To insert a row into a table, use [`INSERT INTO`](insert.html) followed by the table name and then the column values listed in the order in which the columns appear in the table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers VALUES
-    ('c28f5c28-f5c2-4000-8000-000000000026', 'new york', 'Petee', 'ABC-1234', '101 5th Ave');
-~~~
-
-If you want to pass column values in a different order, list the column names explicitly and provide the column values in the corresponding order:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (name, city, dl, address, id) VALUES
-    ('Adam Driver', 'chicago', 'DEF-5678', '201 E Randolph St', '1eb851eb-851e-4800-8000-000000000006');
-~~~
-
-To insert multiple rows into a table, use a comma-separated list of parentheses, each containing column values for one row:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers VALUES
-    ('8a3d70a3-d70a-4000-8000-00000000001b', 'seattle', 'Eric', 'GHI-9123', '400 Broad St'),
-    ('9eb851eb-851e-4800-8000-00000000001f', 'new york', 'Harry Potter', 'JKL-456', '214 W 43rd St');
-~~~
-
-[Default values](default-value.html) are used when you leave specific columns out of your statement, or when you explicitly request default values. For example, both of the following statements create a row where the `name`, `dl`, and `address` entries each contain their default value, in this case `NULL`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (id, city) VALUES
-    ('70a3d70a-3d70-4400-8000-000000000016', 'chicago');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (id, city, name, dl, address) VALUES
-    ('b851eb85-1eb8-4000-8000-000000000024', 'seattle', DEFAULT, DEFAULT, DEFAULT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM drivers WHERE id in ('70a3d70a-3d70-4400-8000-000000000016', 'b851eb85-1eb8-4000-8000-000000000024');
-~~~
-
-~~~
-                   id                  |  city   | name |  dl  | address
-+--------------------------------------+---------+------+------+---------+
-  70a3d70a-3d70-4400-8000-000000000016 | chicago | NULL | NULL | NULL
-  b851eb85-1eb8-4000-8000-000000000024 | seattle | NULL | NULL | NULL
-(2 rows)
-~~~
-
-## Create an index
-
-[Indexes](indexes.html) help locate data without having to look through every row of a table. They're automatically created for the [primary key](primary-key.html) of a table and any columns with a [`UNIQUE` constraint](unique.html).
-
-To create an index for non-unique columns, use [`CREATE INDEX`](create-index.html) followed by an optional index name and an `ON` clause identifying the table and column(s) to index.  For each column, you can choose whether to sort ascending (`ASC`) or descending (`DESC`).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX name_idx ON users (name DESC);
-~~~
-
-You can create indexes during table creation as well; just include the `INDEX` keyword followed by an optional index name and the column(s) to index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS drivers (
-    id UUID NOT NULL,
-    city STRING NOT NULL,
-    name STRING,
-    dl STRING,
-    address STRING,
-    INDEX name_idx (name),
-    CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-## Show indexes
-
-To show the indexes on a table, use [`SHOW INDEX FROM`](show-index.html) followed by the name of the table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM users;
-~~~
-
-~~~
-  table_name | index_name | non_unique | seq_in_index | column_name | direction | storing | implicit
-+------------+------------+------------+--------------+-------------+-----------+---------+----------+
-  users      | primary    |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary    |   false    |            2 | id          | ASC       |  false  |  false
-  users      | name_idx   |    true    |            1 | name        | DESC      |  false  |  false
-  users      | name_idx   |    true    |            2 | city        | ASC       |  false  |   true
-  users      | name_idx   |    true    |            3 | id          | ASC       |  false  |   true
-(5 rows)
-~~~
-
-
-## Query a table
-
-To query a table, use [`SELECT`](select-clause.html) followed by a comma-separated list of the columns to be returned and the table from which to retrieve the data. You can also use the [`LIMIT`](limit-offset.html) clause to restrict the number of rows retrieved:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name FROM users LIMIT 10;
-~~~
-
-~~~
-        name
-+-------------------+
-  William Wood
-  Victoria Jennings
-  Tyler Dalton
-  Tony Ortiz
-  Tina Miller
-  Taylor Cunningham
-  Susan Morse
-  Steven Lara
-  Stephen Diaz
-  Sarah Wang DDS
-(10 rows)
-~~~
-
-To retrieve all columns, use the `*` wildcard:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users LIMIT 10;
-~~~
-
-~~~
-                   id                  |   city    |        name        |            address             | credit_card
-+--------------------------------------+-----------+--------------------+--------------------------------+-------------+
-  c28f5c28-f5c2-4000-8000-000000000026 | amsterdam | Maria Weber        | 14729 Karen Radial             | 5844236997
-  c7ae147a-e147-4000-8000-000000000027 | amsterdam | Tina Miller        | 97521 Mark Extensions          | 8880478663
-  cccccccc-cccc-4000-8000-000000000028 | amsterdam | Taylor Cunningham  | 89214 Jennifer Well            | 5130593761
-  d1eb851e-b851-4800-8000-000000000029 | amsterdam | Kimberly Alexander | 48474 Alfred Hollow            | 4059628542
-  19999999-9999-4a00-8000-000000000005 | boston    | Nicole Mcmahon     | 11540 Patton Extensions        | 0303726947
-  1eb851eb-851e-4800-8000-000000000006 | boston    | Brian Campbell     | 92025 Yang Village             | 9016427332
-  23d70a3d-70a3-4800-8000-000000000007 | boston    | Carl Mcguire       | 60124 Palmer Mews Apt. 49      | 4566257702
-  28f5c28f-5c28-4600-8000-000000000008 | boston    | Jennifer Sanders   | 19121 Padilla Brooks Apt. 12   | 1350968125
-  80000000-0000-4000-8000-000000000019 | chicago   | Matthew Clay       | 49220 Lisa Junctions           | 9132291015
-  851eb851-eb85-4000-8000-00000000001a | chicago   | Samantha Coffey    | 6423 Jessica Underpass Apt. 87 | 9437219051
-(10 rows)
-~~~
-
-To filter the results, add a `WHERE` clause identifying the columns and values to filter on:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id, name FROM users WHERE city = 'san francisco';
-~~~
-
-~~~
-                   id                  |       name
----------------------------------------+-------------------
-  75c28f5c-28f5-4400-8000-000000000017 | William Wood
-  7ae147ae-147a-4000-8000-000000000018 | Alfred Garcia
-  80000000-0000-4000-8000-000000000019 | Matthew Clay
-  851eb851-eb85-4000-8000-00000000001a | Samantha Coffey
-  8a3d70a3-d70a-4000-8000-00000000001b | Jessica Martinez
-(5 rows)
-~~~
-
-To sort the results, add an `ORDER BY` clause identifying the columns to sort by. For each column, you can choose whether to sort ascending (`ASC`) or descending (`DESC`).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, type, current_location FROM vehicles ORDER BY city, type DESC;
-~~~
-
-~~~
-      city      |    type    |        current_location
-+---------------+------------+--------------------------------+
-  amsterdam     | skateboard | 19202 Edward Pass
-  boston        | scooter    | 19659 Christina Ville
-  chicago       | skateboard | 69721 Noah River
-  detroit       | scooter    | 43051 Jonathan Fords Suite 36
-  los angeles   | skateboard | 49164 Anna Mission Apt. 38
-  minneapolis   | scooter    | 62609 Stephanie Route
-  minneapolis   | scooter    | 57637 Mitchell Shoals Suite 59
-  new york      | skateboard | 64110 Richard Crescent
-  new york      | scooter    | 86667 Edwards Valley
-  paris         | skateboard | 2505 Harrison Parkway Apt. 89
-  rome          | bike       | 64935 Matthew Flats Suite 55
-  san francisco | skateboard | 81472 Morris Run
-  san francisco | scooter    | 91427 Steven Spurs Apt. 49
-  seattle       | bike       | 37754 Farmer Extension
-  washington dc | scooter    | 47259 Natasha Cliffs
-(15 rows)
-~~~
-
-## Update rows
-
-To update rows in a table, use [`UPDATE`](update.html) followed by the table name, a `SET` clause identifying the columns to update and their new values, and a `WHERE` clause identifying the rows to update:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE promo_codes SET (description, rules) = ('EXPIRED', '{"type": "percent_discount", "value": "0%"}') WHERE expiration_time < '2019-01-22 03:04:05+00:00';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT code, description, rules FROM promo_codes LIMIT 10;
-~~~
-
-~~~
-             code            | description |                    rules
------------------------------+-------------+----------------------------------------------
-  0_explain_theory_something | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  100_address_garden_certain | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  101_system_skin_night      | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  102_card_professional_kid  | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  103_now_project_focus      | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  104_long_become_prove      | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  105_republican_guess_arm   | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  106_court_especially_plan  | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  107_she_matter_ten         | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-  108_wind_marriage_for      | EXPIRED     | {"type": "percent_discount", "value": "0%"}
-(10 rows)
-~~~
-
-If a table has a primary key, you can use that in the `WHERE` clause to reliably update specific rows; otherwise, each row matching the `WHERE` clause is updated. When there's no `WHERE` clause, all rows in the table are updated.
-
-## Delete rows
-
-To delete rows from a table, use [`DELETE FROM`](delete.html) followed by the table name and a `WHERE` clause identifying the rows to delete:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DELETE FROM promo_codes WHERE description = 'EXPIRED';
-~~~
-~~~
-DELETE 669
-~~~
-
-Just as with the `UPDATE` statement, if a table has a primary key, you can use that in the `WHERE` clause to reliably delete specific rows; otherwise, each row matching the `WHERE` clause is deleted. When there's no `WHERE` clause, all rows in the table are deleted.
-
-## Remove a table
-
-When you no longer need a table, use [`DROP TABLE`](drop-table.html) followed by the table name to remove the table and all its data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TABLE drivers;
-~~~
-
-## What's next?
-
-- Explore all [SQL Statements](sql-statements.html)
-- [Use the built-in SQL client](cockroach-sql.html) to execute statements from a shell or directly from the command line
-- [Install the client driver](install-client-drivers.html) for your preferred language and [build an app](example-apps.html)
-- [Explore core CockroachDB features](demo-replication-and-rebalancing.html) like automatic replication, rebalancing, and fault tolerance
diff --git a/src/current/v20.2/licensing-faqs.md b/src/current/v20.2/licensing-faqs.md
deleted file mode 100644
index 4dab604a23c..00000000000
--- a/src/current/v20.2/licensing-faqs.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-title: Licensing FAQs
-summary: Frequently asked questions about CockroachDB licensing.
-toc: true
----
-
-Current CockroachDB code is primarily licensed in two ways:
-
--  [Business Source License (BSL)](#bsl)
--  [Cockroach Community License (CCL)](#ccl)
-
-CockroachDB core is free to use.  Most [core features](#feature-licensing) are licensed under the BSL, but some core features are subject to the CCL or third-party licenses.
-
-Non-CCL core features from version 19.1 and earlier are licensed under [Apache 2.0](#apache); however, some features remain under third-party licenses. Beginning in version 19.2, these non-CCL features are licensed under the BSL for three years before [converting](#license-conversion-timeline) to the Apache 2.0 license.
-
-CockroachDB [Enterprise features](enterprise-licensing.html) require a [paid license](#obtain-a-license) from Cockroach and are licensed under the Cockroach Community License.
-
-{{site.data.alerts.callout_info}}
-You can find any feature's license by checking the code's file header in the [CockroachDB repository](https://github.com/cockroachdb/cockroach).
-{{site.data.alerts.end}}
-
-## Types of licenses
-
-Type | Description
--------------|------------
-<a name="apache"></a>**Apache 2.0 License** | Core features under the Apache License are free to use and fully open-source. BSL features convert to this license three years after their release. For license conversion dates, see the [table below](#license-conversion-timeline).
-<a name="bsl"></a>**Business Source License**| BSL features are free to use and the source code is available, but users may not use CockroachDB [as a service](#what-constitutes-hosting-cockroachdb-as-a-service) without an agreement with Cockroach Labs. The BSL is not certified as an open-source license, but most of the [Open Source Initiative](https://en.wikipedia.org/wiki/Open_Source_Initiative) (OSI) criteria are met.
-<a name="ccl"></a>**Cockroach <br/> Community License** | <ul><li> CCL (Free) features are free to use. The source code is available to view and modify, but it cannot be reused without an agreement with Cockroach Labs. </li><li> CCL (Paid) features require an Enterprise license key to access. The source code is available to view and modify, but it cannot be used without an agreement with Cockroach Labs. </li></ul>
-
-For additional custom licensing options, [contact us](https://support.cockroachlabs.com/hc/en-us).
-
-For each BSL release all associated alpha, beta, major, and minor (point) releases will become Apache 2.0 on the same day three years after the major release date. Once a release is published under the BSL, the license cannot be changed to prevent code from becoming open-source at the specified change date. The following table lists the current license for non-CCL features for each published release:
-
-### License conversion timeline
-
-CockroachDB version | License | Converts to Apache 2.0   
---------------------|---------|----------------------------
-21.1 | Business Source License | May 18, 2024
-20.2 | Business Source License | Nov 10, 2023
-20.1 | Business Source License | May 12, 2023  
-19.2 | Business Source License | Oct 01, 2022
-19.1 | Apache 2.0 | -                          
-2.1 | Apache 2.0 | -
-2.0 | Apache 2.0 | -
-
-## Feature licensing
-
-The table below shows how certain core and Enterprise features are licensed:
-
-Feature          | BSL | CCL (free)      | CCL (paid)
------------------|:-----:|:-----------------:|:---------------:
-**[Import](import.html)** | | ✓ |
-**[Export](export.html)** | ✓ | |
-**[Restore](restore.html)[*](#footnotes)** | | ✓ |
-**[Full backups](take-full-and-incremental-backups.html#full-backups)[*](#footnotes)** | | ✓ |
-**[Incremental backups](take-full-and-incremental-backups.html#incremental-backups)** | | | ✓
-**[Other advanced backup features](backup.html)** | | | ✓
-**[Core changefeed](stream-data-out-of-cockroachdb-using-changefeeds.html#create-a-core-changefeed)** | | ✓ |
-**[Enterprise changefeed](stream-data-out-of-cockroachdb-using-changefeeds.html#configure-a-changefeed-enterprise)** | | | ✓
-**[Table-level zone configuration](configure-replication-zones.html#replication-zone-levels)** | ✓ | |
-**[Geo-partitioning](topology-geo-partitioned-replicas.html)** | | | ✓
-**[Follower reads](follower-reads.html)** | | | ✓
-**[Node map](enable-node-map.html)** | | | ✓
-**[Locality-aware index selection](cost-based-optimizer.html#preferring-the-nearest-index)** | | | ✓
-**[Encryption at rest](encryption.html#encryption-at-rest-enterprise)** | | | ✓
-**[Role-based access management](authorization.html#roles)** | ✓ | |
-**[Password and certificate authentication](authentication.html)** | ✓ | |
-**[GSSAPI with Kerberos authentication](gssapi_authentication.html)** | | | ✓
-**[All other core features](https://www.cockroachlabs.com/compare)** | ✓ | |
-
-<a name="footnotes"></a><sup>* Now a core feature in v20.2.</sup>
-
-{{site.data.alerts.callout_info}}
-Individual feature licensing may change with each release of CockroachDB. You can use the dropdown menu at the top of the page to view documentation for other versions of CockroachDB.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-More information about all Enterprise features can be found [here](enterprise-licensing.html).
-{{site.data.alerts.end}}
-
-## Obtain a license
-
-All CockroachDB code is included in the same binary. No license key is required to access BSL and CCL (Free) features. To access CCL (Paid) features, users have two options:
-
-- An **Enterprise License** enables you to use CockroachDB Enterprise features for longer periods (one year or more). To upgrade to an Enterprise license, <a href="mailto:sales@cockroachlabs.com">contact Sales</a>.
-- A **Trial License** enables you to try out CockroachDB Enterprise features for 30 days for free. To obtain a trial license, fill out [the registration form](https://www.cockroachlabs.com/get-cockroachdb/enterprise/) and receive your trial license via email within a few minutes.
-
-{{site.data.alerts.callout_success}}
-For quick local testing of Enterprise features, you can use the [`cockroach demo`](cockroach-demo.html) command, which starts a temporary, in-memory cluster with a SQL shell open and a trial license applied automatically.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Cockroach Labs is willing to offer self-hosted CockroachDB Enterprise features free of charge and discounted prices for CockroachDB {{ site.data.products.cloud }} to select non-profit organizations and non-commercial academic projects. To learn more, please [contact us](https://support.cockroachlabs.com/hc/en-us).
-{{site.data.alerts.end}}
-
-## Set a license
-
-As the CockroachDB `root` user, open the [built-in SQL shell](cockroach-sql.html) in insecure or secure mode, as per your CockroachDB setup. In the following example, we assume that CockroachDB is running in insecure mode. Then use the [`SET CLUSTER SETTING`](set-cluster-setting.html) command to set the name of your organization and the license key:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --insecure
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
->  SET CLUSTER SETTING cluster.organization = 'Acme Company';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
->  SET CLUSTER SETTING enterprise.license = 'xxxxxxxxxxxx';
-~~~
-
-## Verify a license
-
-To verify a license, open the [built-in SQL shell](cockroach-sql.html) and use the [`SHOW CLUSTER SETTING`](show-cluster-setting.html) command to check the organization name and license key:
-
-{% include copy-clipboard.html %}
-~~~ sql
->  SHOW CLUSTER SETTING cluster.organization;
-~~~
-~~~
-  cluster.organization
-+----------------------+
-  Acme Company
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
->  SHOW CLUSTER SETTING enterprise.license;
-~~~
-~~~
-             enterprise.license
-+-------------------------------------------+
-  crl-0-ChB1x...
-(1 row)
-~~~
-
-The license setting is also logged in the cockroach.log on the node where the command is run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-$ cat cockroach.log | grep license
-~~~
-~~~
-I171116 18:11:48.279604 1514 sql/event_log.go:102  [client=[::1]:56357,user=root,n1] Event: "set_cluster_setting", target: 0, info: {SettingName:enterprise.license Value:xxxxxxxxxxxx User:root}
-~~~
-
-## Monitoring for license expiry
-
-<span class="version-tag">New in v20.2</span> You can monitor the time until your license expires with [Prometheus](monitor-cockroachdb-with-prometheus.html). The `seconds_until_enterprise_license_expiry` metric reports the number of seconds until the Enterprise license on a cluster expires. It will report 0 if there is no license or a negative number if the license has already expired. For more information, see [Monitoring and Alerting](monitoring-and-alerting.html).
-
-## Renew an expired license
-
-After your license expires, the Enterprise features stop working, but your production setup is unaffected. For example, the backup and restore features would not work until the license is renewed, but you would be able to continue using all other features of CockroachDB without interruption.
-
-To renew an expired license, <a href="mailto:sales@cockroachlabs.com">contact Sales</a> and then [set](licensing-faqs.html#set-a-license) the new license.
-
-## FAQs
-
-### Can I host CockroachDB as a service for internal use at my organization?
-
-Yes, employees and contractors can use your internal CockroachDB instance as a service, but no people outside of your organization will be able to use it without purchasing a license. Use of Enterprise features will always require a license.
-
-### What constitutes hosting CockroachDB as a service?
-
-Hosting CockroachDB as a service means creating an offering that allows third parties (other than your employees and contractors) to operate a database. Specifically, third parties cannot modify table schemas.
-
-### I would like to reuse a single component from the CockroachDB project in my own software, which uses the AGPL or another open-source license. Is this possible?
-
-The CockroachDB team is committed to supporting the open-source community and willing to consider extracting specific internal components that are generally useful as a separate project with its own license, for example APL. For more details, feel free to [contact us](https://support.cockroachlabs.com/hc/en-us).
-
-### Can I fork the CockroachDB project pre-BSL and create my own CockroachDB derivative with a different license?
-
-You can fork any historical version of CockroachDB in your own project, as allowed by the license available for that version, and modify it for your purpose. Note however that only the copyright holder (Cockroach Labs) can relicense the components that you forked from: your derivative will need to keep the original license at the time of the fork. Any component you copy from a BSL-licensed CockroachDB into your project will make the BSL apply to your project as well.
diff --git a/src/current/v20.2/limit-offset.md b/src/current/v20.2/limit-offset.md
deleted file mode 100644
index 06d2f941401..00000000000
--- a/src/current/v20.2/limit-offset.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: Limiting Query Results
-summary: LIMIT and OFFSET restrict an operation to a few row.
-toc: true
----
-
-The `LIMIT` and `OFFSET` clauses restrict the operation of:
-
-- A [selection query](selection-queries.html), including when it occurs as part of [`INSERT`](insert.html) or [`UPSERT`](upsert.html).
-- [`UPDATE`](update.html) and [`DELETE`](delete.html) statements.
-
-
-`OFFSET` instructs the operation to skip a specified number of rows. It is often used in conjunction with `LIMIT` to "paginate" through retrieved rows.
-
-{{site.data.alerts.callout_danger}}
-Using `LIMIT`/`OFFSET` to implement pagination can be very slow for large tables.  We recommend using [keyset pagination](pagination.html) instead.
-{{site.data.alerts.end}}
-
-## Syntax
-
-### LIMIT
-
-~~~
-LIMIT { <limit_value> | ALL }
-~~~
-
-For PostgreSQL compatibility, CockroachDB also supports `FETCH FIRST limit_value ROWS ONLY` and `FETCH NEXT limit_value ROWS ONLY` as aliases for `LIMIT`. If `limit_value` is omitted, then one row is fetched.
-
-### OFFSET
-
-~~~
-OFFSET <offset_value> [ ROW | ROWS ]
-~~~
-
-## Examples
-
-For example uses with `SELECT`, see [Limiting Row Count](selection-queries.html#limiting-row-count).
-
-## See also
-
-- [`DELETE`](delete.html)
-- [`UPDATE`](delete.html)
-- [`INSERT`](insert.html)
-- [`UPSERT`](upsert.html)
-- [Selection Queries](selection-queries.html)
diff --git a/src/current/v20.2/linestring.md b/src/current/v20.2/linestring.md
deleted file mode 100644
index 609ef30c352..00000000000
--- a/src/current/v20.2/linestring.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: LINESTRING
-summary: A LINESTRING is a collection of POINTs joined into a line.
-toc: true
----
-
-A `LINESTRING` is a collection of [Points](point.html) that are "strung together" into one geometric object. A LineString can be used to represent an arbitrary curve, such as a [Bézier curve](https://en.wikipedia.org/wiki/Bézier_curve).  In practice, this means that LineStrings are useful for representing real-world objects such as roads and rivers.
-
-The coordinates of each Point that makes up the LineString are translated according to the current [spatial reference system](spatial-glossary.html#spatial-reference-system) (denoted by an [SRID](spatial-glossary.html#srid)) to determine what the Point "is", or what it "means" relative to the [other spatial objects](spatial-features.html#spatial-objects) (if any) in the data set.
-
-## Examples
-
-A LineString can be created from SQL by calling the `st_geomfromtext` function on a LineString definition expressed in the [Well Known Text (WKT)](spatial-glossary.html#wkt) format as shown below.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeomFromText('LINESTRING(0 0, 1440 900)');
-~~~
-
-~~~
-                                   st_geomfromtext
---------------------------------------------------------------------------------------
-  0102000000020000000000000000000000000000000000000000000000008096400000000000208C40
-(1 row)
-~~~
-
-You can also make a LineString using the [aggregate function form](functions-and-operators.html#aggregate-functions) of `st_makeline`.
-
-## See also
-
-- [Spatial objects](spatial-features.html#spatial-objects)
-- [POINT](point.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/liquibase.md b/src/current/v20.2/liquibase.md
deleted file mode 100644
index 1eed1667717..00000000000
--- a/src/current/v20.2/liquibase.md
+++ /dev/null
@@ -1,516 +0,0 @@
----
-title: Migrate CockroachDB Schemas with Liquibase
-summary: Learn how to use Liquibase with a CockroachDB cluster.
-toc: true
----
-
-This page walks you through a series of simple database schema changes using the [Liquibase](https://www.liquibase.org/get-started/how-liquibase-works) command-line tool and the [CockroachDB SQL shell](cockroach-sql.html).
-
-For detailed information about using Liquibase, see the [Liquibase documentation site](https://docs.liquibase.com/home.html).
-
-## Before you begin
-
-Before you begin the tutorial, do the following:
-
-1. [Install CockroachDB](install-cockroachdb.html), and [start a secure cluster](secure-a-cluster.html). When starting your cluster, make sure that you generate cluster certificates, create the `bank` database, and create the `max` user.
-1. Download and install a Java Development Kit. Liquibase supports JDK versions 8+. In this tutorial, we use [AdoptOpenJDK](https://adoptopenjdk.net/) 8, but you can follow along with any JDK version 8+.
-
-## Step 1. Download and install Liquibase
-
-To install the Liquibase binary on your machine:
-
-1. Download the latest version of the [Liquibase command-line tool](https://www.liquibase.org/download). CockroachDB is fully compatible with Liquibase versions 4.2.0 and greater. We use the binary download of Liquibase 4.20, for macOS.
-
-    {{site.data.alerts.callout_info}}
-    In this tutorial, we go through a manual installation, using a download of the binary version of the Liquibase command-line tool. If you are new to Liquibase, you can also use the [Liquibase Installer](https://www.liquibase.org/get-started/using-the-liquibase-installer) to get started. The installer comes with some example properties and changelog files, an example H2 database, and a distribution of AdoptOpenJDK.
-    {{site.data.alerts.end}}
-
-1. Make a new directory for your Liquibase installation:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir liquibase-4.2.0-bin
-    ~~~
-
-1. Extract the Liquibase download to the new directory:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ tar -xvf liquibase-4.2.0.tar.gz -C liquibase-4.2.0-bin
-    ~~~
-
-1. Append the full path of the `liquibase` binary (now located in the `liquibase-4.2.0-bin` folder) to your machine's `PATH` environment variable:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ echo "export PATH=$PATH:/full-path/liquibase-4.2.0-bin" >> ~/.bash_profile
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ source ~/.bash_profile
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    If your terminal does not run `.bash_profile` at start-up, you can alternatively append the `liquibase` path to the `PATH` definition in `.bashrc` or `.profile`.
-    {{site.data.alerts.end}}
-
-1. To verify that the installation was successful, run the following command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ liquibase --version
-    ~~~
-
-    You should get output similar to the following:
-
-    ~~~
-    ####################################################
-    ##   _     _             _ _                      ##
-    ##  | |   (_)           (_) |                     ##
-    ##  | |    _  __ _ _   _ _| |__   __ _ ___  ___   ##
-    ##  | |   | |/ _` | | | | | '_ \ / _` / __|/ _ \  ##
-    ##  | |___| | (_| | |_| | | |_) | (_| \__ \  __/  ##
-    ##  \_____/_|\__, |\__,_|_|_.__/ \__,_|___/\___|  ##
-    ##              | |                               ##
-    ##              |_|                               ##
-    ##                                                ##
-    ##  Get documentation at docs.liquibase.com       ##
-    ##  Get certified courses at learn.liquibase.com  ##
-    ##  Get advanced features and support at          ##
-    ##      liquibase.com/support                     ##
-    ##                                                ##
-    ####################################################
-    Starting Liquibase at 13:38:36 (version 4.2.0 #18 built at 2020-11-13 16:49+0000)
-    Liquibase Version: 4.2.0
-    Liquibase Community 4.2.0 by Datical
-    Running Java under /Library/Java/JavaVirtualMachines/adoptopenjdk-8.jdk/Contents/Home/jre (Version 1.8.0_242)
-    ~~~
-
-## Step 2: Download the PostgreSQL JDBC driver
-
-The Liquibase command-line tool uses the PostgreSQL JDBC driver to connect to CockroachDB as a Java application.
-
-To install the driver for Liquibase:
-
-1. Download the JDBC driver from [the PostgreSQL website](https://jdbc.postgresql.org/download/).
-1. Place the driver in the `lib` directory of the Liquibase binary. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp ~/Downloads/postgresql-42.2.9.jar liquibase-4.2.0-bin/lib/
-    ~~~
-
-{{site.data.alerts.callout_success}}
-If you are using Liquibase in the context of a separate Java application, we recommend that you use a dependency management tool, like [Maven](https://docs.liquibase.com/tools-integrations/maven/home.html), to download the driver.
-{{site.data.alerts.end}}
-
-## Step 3. Generate TLS certificates for the `max` user
-
-When you [started a secure CockroachDB cluster](secure-a-cluster.html), you should have created a user `max`. You should have also given this user the [`admin` role](authorization.html#admin-role), which grants all privileges to all databases on the cluster. In this tutorial, Liquibase runs schema changes as the `max` user.
-
-To authenticate connection requests to CockroachDB from the Liquibase client, you need to generate some certificates for `max`. Use [`cockroach cert`](cockroach-cert.html#synopsis) to generate the certificates:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client max --certs-dir=certs --ca-key=my-safe-directory/ca.key --also-generate-pkcs8-key
-~~~
-
-The [`--also-generate-pkcs8-key` flag](cockroach-cert.html#flag-pkcs8) generates a key in [PKCS#8 format](https://tools.ietf.org/html/rfc5208), which is the standard key encoding format in Java. In this case, the generated PKCS8 key will be named `client.max.key.pk8`.
-
-## Step 4: Create a changelog
-
-Liquibase uses [changelog files](https://docs.liquibase.com/concepts/basic/changelog.html) to manage database schema changes. Changelog files include a list of instructions, known as [changesets](https://docs.liquibase.com/concepts/basic/changeset.html), that are executed against the database in a specified order. Liquibase supports XML, YAML, and SQL formats for changelogs and changesets.
-
-Let's define a changelog with the [XML format](https://docs.liquibase.com/concepts/basic/xml-format.html):
-
-1. Create a file named `changelog-main.xml`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ touch changelog-main.xml
-    ~~~
-
-1. Add the following to the blank `changelog-main.xml` file:
-
-    {% include copy-clipboard.html %}
-    ~~~ xml
-    <databaseChangeLog
-            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
-            xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
-            xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog
-             http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.9.xsd">
-
-        <changeSet id="1" author="max" runInTransaction="false">
-            <validCheckSum>ANY</validCheckSum>
-            <sqlFile path="create.sql"/>
-        </changeSet>
-
-    </databaseChangeLog>
-    ~~~
-
-    This first changeset uses [the `sqlFile` tag](https://docs.liquibase.com/change-types/community/sql-file.html), which tells Liquibase that an external `.sql` file contains some [SQL statements](https://docs.liquibase.com/concepts/basic/sql-format.html) to execute.
-
-    {{site.data.alerts.callout_success}}
-    CockroachDB has [limited support for online schema changes in transactions](online-schema-changes.html#limited-support-for-schema-changes-within-transactions). To avoid running into issues with incomplete transactions, we recommend setting the [`runInTransaction` attribute](https://docs.liquibase.com/concepts/basic/changeset.html#available-attributes) to `"false"` on all changesets.
-    {{site.data.alerts.end}}
-
-
-1. In the same directory, create the SQL file specified by the first changeset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ touch create.sql
-    ~~~
-
-1. Add the following [`CREATE TABLE`](create-table.html) statement to the `create.sql` file:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    create table account
-    (
-        id      int            not null primary key default unique_rowid(),
-        balance numeric(19, 2) not null,
-        name    varchar(128)   not null,
-        type    varchar(25)    not null
-    );
-    ~~~
-
-    When Liquibase runs, the first changeset will execute the statements in `create.sql`, creating a table named `account`.
-
-1. Now let's use the [XML format](https://docs.liquibase.com/concepts/basic/xml-format.html) to define the second changeset. Directly after the first `changeSet` element in `changelog-main.xml`, add the following:
-
-    {% include copy-clipboard.html %}
-    ~~~ xml
-    <changeSet id="2" author="max" runInTransaction="false">
-        <insert tableName="account">
-            <column name="id">1</column>
-            <column name="name">Alice</column>
-            <column name="balance" valueNumeric="500.00"/>
-            <column name="type">asset</column>
-        </insert>
-        <insert tableName="account">
-            <column name="id">2</column>
-            <column name="name">Bob</column>
-            <column name="balance" valueNumeric="500.00"/>
-            <column name="type">expense</column>
-        </insert>
-        <insert tableName="account">
-            <column name="id">3</column>
-            <column name="name">Bobby Tables</column>
-            <column name="balance" valueNumeric="500.00"/>
-            <column name="type">asset</column>
-        </insert>
-        <insert tableName="account">
-            <column name="id">4</column>
-            <column name="name">Doris</column>
-            <column name="balance" valueNumeric="500.00"/>
-            <column name="type">expense</column>
-        </insert>
-    </changeSet>
-    ~~~
-
-    This second changeset uses the [Liquibase XML syntax](https://docs.liquibase.com/concepts/basic/xml-format.html) to specify a series of sequential `INSERT` statements that initialize the `account` table with some values.
-
-When the application is started, all of the queries specified by the changesets are executed in the order specified by their `changeset` `id` values.
-
-{{site.data.alerts.callout_success}}
-When possible, we recommend limiting each changeset to a single statement, per the **one change per changeset** [Liquibase best practice](https://docs.liquibase.com/concepts/bestpractices.html). This is especially important for [online schema changes](online-schema-changes.html). For more information, see [Liquibase and transactions](#liquibase-and-transactions).
-{{site.data.alerts.end}}
-
-## Step 5. Configure a Liquibase properties file
-
-Liquibase properties are defined in a file named [`liquibase.properties`](https://docs.liquibase.com/workflows/liquibase-community/creating-config-properties.html). These properties define the database connection information.
-
-{{site.data.alerts.callout_info}}
-You can also set Liquibase properties with the `liquibase` command-line tool.
-{{site.data.alerts.end}}
-
-To configure Liquibase properties:
-
-1. In the same directory as `changelog-main.xml`, create a `liquibase.properties` file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ touch liquibase.properties
-    ~~~
-
-1. Add the following property definitions to the file:
-
-    {% include copy-clipboard.html %}
-    ~~~ yml
-    changeLogFile: changelog-main.xml
-    driver: org.postgresql.Driver
-    url: jdbc:postgresql://localhost:26257/bank?sslmode=verify-full&sslrootcert=/full-path/certs/ca.crt&sslkey=/full-path/certs/client.max.key.pk8&sslcert=/full-path/certs/client.max.crt
-    username: max
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    For `url`, the SSL connection parameters must specify the full paths of the certificates that you generated.
-    {{site.data.alerts.end}}
-
-## Step 6. Run Liquibase
-
-To run Liquibase from the command line, execute the following command from the directory containing your `liquibase.properties` and `changelog-main.xml` files:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ liquibase update
-~~~
-
-You should see output similar to the following:
-
-~~~
-Liquibase Community 4.2.0 by Datical
-####################################################
-##   _     _             _ _                      ##
-##  | |   (_)           (_) |                     ##
-##  | |    _  __ _ _   _ _| |__   __ _ ___  ___   ##
-##  | |   | |/ _` | | | | | '_ \ / _` / __|/ _ \  ##
-##  | |___| | (_| | |_| | | |_) | (_| \__ \  __/  ##
-##  \_____/_|\__, |\__,_|_|_.__/ \__,_|___/\___|  ##
-##              | |                               ##
-##              |_|                               ##
-##                                                ##
-##  Get documentation at docs.liquibase.com       ##
-##  Get certified courses at learn.liquibase.com  ##
-##  Get advanced features and support at          ##
-##      liquibase.com/support                     ##
-##                                                ##
-####################################################
-Starting Liquibase at 13:59:37 (version 4.2.0 #18 built at 2020-11-13 16:49+0000)
-Liquibase: Update has been successful.
-~~~
-
-When the changelog is first executed, Liquibase also creates a table called [`databasechangelog`](https://docs.liquibase.com/concepts/databasechangelog-table.html) in the database where it performs changes. This table's rows log all completed changesets.
-
-To see the completed changesets, open a new terminal, start the [built-in SQL shell](cockroach-sql.html), and query the `databasechangelog` table:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM bank.databasechangelog;
-~~~
-
-~~~
-  id | author |      filename      |           dateexecuted           | orderexecuted | exectype |               md5sum               |                                              description                                               | comments | tag  | liquibase | contexts | labels | deployment_id
------+--------+--------------------+----------------------------------+---------------+----------+------------------------------------+--------------------------------------------------------------------------------------------------------+----------+------+-----------+----------+--------+----------------
-  1  | max    | changelog-main.xml | 2020-11-30 13:59:38.40272+00:00  |             1 | EXECUTED | 8:567321cdb0100cbe76731a7ed414674b | sqlFile                                                                                                |          | NULL | 4.2.0     | NULL     | NULL   | 6762778263
-  2  | max    | changelog-main.xml | 2020-11-30 13:59:38.542547+00:00 |             2 | EXECUTED | 8:c2945f2a445cf60b4b203e1a91d14a89 | insert tableName=account; insert tableName=account; insert tableName=account; insert tableName=account |          | NULL | 4.2.0     | NULL     | NULL   | 6762778263
-(2 rows)
-~~~
-
-You can also query the `account` table directly to see the latest changes reflected in the table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM bank.account;
-~~~
-
-~~~
-  id | balance |     name     |  type
------+---------+--------------+----------
-   1 |  500.00 | Alice        | asset
-   2 |  500.00 | Bob          | expense
-   3 |  500.00 | Bobby Tables | asset
-   4 |  500.00 | Doris        | expense
-(4 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-Liquibase does not [retry transactions](transactions.html#transaction-retries) automatically. If a changeset fails at startup, you might need to restart the application manually to complete the changeset.
-{{site.data.alerts.end}}
-
-## Step 7. Add additional changesets
-
-Suppose that you want to change the primary key of the `accounts` table from a simple, incrementing [integer](int.html) (in this case, `id`) to an auto-generated [UUID](uuid.html), to follow some [CockroachDB best practices](performance-best-practices-overview.html#unique-id-best-practices). You can make these changes to the schema by creating and executing an additional changeset:
-
-1. Create a SQL file to add a new UUID-typed column to the table:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ touch add_uuid.sql
-    ~~~
-
-    {{site.data.alerts.callout_success}}
-    Using [SQL files](https://docs.liquibase.com/concepts/basic/sql-format.html) to define statements can be helpful when you want to execute statements that use syntax specific to CockroachDB.
-    {{site.data.alerts.end}}
-
-1. Add the following SQL statement to `add_uuid.sql`:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    /* Add new UUID-typed column */
-    ALTER TABLE account ADD COLUMN unique_id UUID NOT NULL DEFAULT gen_random_uuid();
-    ~~~
-
-    This statement adds [a new `unique_id` column](add-column.html) to the `accounts` table, with the default value as [a randomly-generated UUID](performance-best-practices-overview.html#use-uuid-to-generate-unique-ids).
-
-1. In the `changelog-main.xml` file, add the following after the second `changeSet` element:
-
-    ~~~ xml
-    <changeSet id="3" author="max" runInTransaction="false">
-        <sqlFile path="add_uuid.sql"/>
-    </changeSet>
-    ~~~
-
-1. Now create a SQL file to update the primary key for the table with the new column:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ touch update_pk.sql
-    ~~~
-
-1. Add the following SQL statement to `update_pk.sql`:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    /* Change primary key */
-    ALTER TABLE account ALTER PRIMARY KEY USING COLUMNS (unique_id);
-    ~~~
-
-    This statement [alters the `accounts` primary key](alter-primary-key.html) to use the `unique_id` column.
-
-1. In the `changelog-main.xml` file, add the following after the third `changeSet` element:
-
-    ~~~ xml
-    <changeSet id="4" author="max" runInTransaction="false">
-        <sqlFile path="update_pk.sql"/>
-    </changeSet>
-    ~~~
-
-1. To update the table, run `liquibase update` again:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ liquibase update
-    ~~~
-
-    You should see output similar to the following:
-
-    ~~~
-    Liquibase Community 4.2.0 by Datical
-    ####################################################
-    ##   _     _             _ _                      ##
-    ##  | |   (_)           (_) |                     ##
-    ##  | |    _  __ _ _   _ _| |__   __ _ ___  ___   ##
-    ##  | |   | |/ _` | | | | | '_ \ / _` / __|/ _ \  ##
-    ##  | |___| | (_| | |_| | | |_) | (_| \__ \  __/  ##
-    ##  \_____/_|\__, |\__,_|_|_.__/ \__,_|___/\___|  ##
-    ##              | |                               ##
-    ##              |_|                               ##
-    ##                                                ##
-    ##  Get documentation at docs.liquibase.com       ##
-    ##  Get certified courses at learn.liquibase.com  ##
-    ##  Get advanced features and support at          ##
-    ##      liquibase.com/support                     ##
-    ##                                                ##
-    ####################################################
-    Starting Liquibase at 14:26:50 (version 4.2.0 #18 built at 2020-11-13 16:49+0000)
-    Liquibase: Update has been successful.
-    ~~~
-
-To see the completed changesets, open a new terminal, start the [built-in SQL shell](cockroach-sql.html), and query the `databasechangelog` table:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql --certs-dir=certs
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM bank.databasechangelog;
-~~~
-
-~~~
-  id | author |      filename      |           dateexecuted           | orderexecuted | exectype |               md5sum               |                                              description                                               | comments | tag  | liquibase | contexts | labels | deployment_id
------+--------+--------------------+----------------------------------+---------------+----------+------------------------------------+--------------------------------------------------------------------------------------------------------+----------+------+-----------+----------+--------+----------------
-  1  | max    | changelog-main.xml | 2020-11-30 13:59:38.40272+00:00  |             1 | EXECUTED | 8:567321cdb0100cbe76731a7ed414674b | sqlFile                                                                                                |          | NULL | 4.2.0     | NULL     | NULL   | 6762778263
-  2  | max    | changelog-main.xml | 2020-11-30 13:59:38.542547+00:00 |             2 | EXECUTED | 8:c2945f2a445cf60b4b203e1a91d14a89 | insert tableName=account; insert tableName=account; insert tableName=account; insert tableName=account |          | NULL | 4.2.0     | NULL     | NULL   | 6762778263
-  3  | max    | changelog-main.xml | 2020-11-30 14:26:51.916768+00:00 |             3 | EXECUTED | 8:7b76f0ae200b1ae1d9f0c0f78979348b | sqlFile                                                                                                |          | NULL | 4.2.0     | NULL     | NULL   | 6764411427
-  4  | max    | changelog-main.xml | 2020-11-30 14:26:52.609161+00:00 |             4 | EXECUTED | 8:fcaa0dca049c34c6372847af7a2646d9 | sqlFile                                                                                                |          | NULL | 4.2.0     | NULL     | NULL   | 6764411427
-(4 rows)
-~~~
-
-You can also query the `account` table directly to see the latest changes reflected in the table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM bank.account;
-~~~
-
-~~~
-  id | balance |     name     |  type   |              unique_id
------+---------+--------------+---------+---------------------------------------
-   1 |  500.00 | Alice        | asset   | 3d2b7da4-0876-4ddd-8626-b980cef3323e
-   2 |  500.00 | Bob          | expense | 8917ce09-c7d2-42a0-9ee4-8cb9cb3515ec
-   3 |  500.00 | Bobby Tables | asset   | b5dccde6-25fe-4c73-b3a2-501225d8b235
-   4 |  500.00 | Doris        | expense | f37dc62e-a2d5-4f63-801a-3eaa3fc68806
-(4 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE bank.account;
-~~~
-
-~~~
-      table_name      |                     create_statement
-----------------------+------------------------------------------------------------
-  bank.public.account | CREATE TABLE account (
-                      |     id INT8 NOT NULL DEFAULT unique_rowid(),
-                      |     balance DECIMAL(19,2) NOT NULL,
-                      |     name VARCHAR(128) NOT NULL,
-                      |     type VARCHAR(25) NOT NULL,
-                      |     unique_id UUID NOT NULL DEFAULT gen_random_uuid(),
-                      |     CONSTRAINT "primary" PRIMARY KEY (unique_id ASC),
-                      |     UNIQUE INDEX account_id_key (id ASC),
-                      |     FAMILY "primary" (id, balance, name, type, unique_id)
-                      | )
-(1 row)
-~~~
-
-## Liquibase and transactions
-
-By default, Liquibase wraps each changeset within a single transaction. If the transaction fails to successfully commit, Liquibase rolls back the transaction.
-
-CockroachDB has [limited support for online schema changes within transactions](online-schema-changes.html#limited-support-for-schema-changes-within-transactions). If a schema change fails, automatic rollbacks can lead to unexpected results. To avoid running into issues with incomplete transactions, we recommend setting the `runInTransaction` attribute on each of your changesets to `"false"`, as demonstrated throughout this tutorial.
-
-{{site.data.alerts.callout_info}}
-If `runInTransaction="false"` for a changeset, and an error occurs while Liquid is running the changeset, the `databasechangelog` table might be left in an invalid state and need to be fixed manually.
-{{site.data.alerts.end}}
-
-### Transaction retries
-
-When multiple, concurrent transactions or statements are issued to a single CockroachDB cluster, [transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention) can cause schema migrations to fail. In the event of transaction contention, CockroachDB returns a `40001 SQLSTATE` (i.e., a serialization failure).
-
-Liquibase does not automatically retry transactions. To handle transaction failures, we recommend writing client-side transaction retry logic. For more information about client-side transaction retries in CockroachDB, see [Transaction Retries](transactions.html#transaction-retries).
-
-## Liquibase integrations
-
-You can run Liquibase in the context of a Java application framework, like Spring Boot. For examples of using Liquibase for schema management in a Spring Boot application built on CockroachDB, see [Build a Spring App with CockroachDB and JDBC](build-a-spring-app-with-cockroachdb-jdbc.html) and [Build a Spring App with CockroachDB and JPA](build-a-spring-app-with-cockroachdb-jpa.html).
-
-For documentation on running Liquibase with other tooling, see [the Liquibase documentation site](https://docs.liquibase.com/workflows/liquibase-community/running.html).
-
-## Report Issues with Liquibase and CockroachDB
-
-If you run into problems, please file an issue on the [Liquibase issue tracker](https://github.com/liquibase/liquibase/issues), including the following details about the environment where you encountered the issue:
-
-- CockroachDB version ([`cockroach version`](cockroach-version.html))
-- Liquibase version
-- Operating system
-- Steps to reproduce the behavior
-
-## See Also
-
-+ [Liquibase documentation](https://docs.liquibase.com/home.html)
-+ [Liquibase issue tracker](https://github.com/liquibase/liquibase/issues)
-+ [Client connection parameters](connection-parameters.html)
-+ [Third-Party Database Tools](third-party-database-tools.html)
-+ [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
-+ [Build a Spring App with CockroachDB and JDBC](build-a-spring-app-with-cockroachdb-jdbc.html)
-+ [Build a Spring App with CockroachDB and JPA](build-a-spring-app-with-cockroachdb-jpa.html)
diff --git a/src/current/v20.2/load-based-splitting.md b/src/current/v20.2/load-based-splitting.md
deleted file mode 100644
index 0b0eccec70d..00000000000
--- a/src/current/v20.2/load-based-splitting.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: Load-Based Splitting
-summary: To optimize your cluster's performance, CockroachDB can split frequently accessed keys into their own ranges.
-toc: true
----
-
-To optimize your cluster's performance, CockroachDB can split frequently accessed keys into smaller ranges. In conjunction with [load-based rebalancing](architecture/replication-layer.html#load-based-replica-rebalancing), load-based splitting distributes load evenly across your cluster.
-
-## Settings
-
-### Enable/disable load-based splitting
-
-Use [`SET CLUSTER SETTING`](set-cluster-setting.html) to set `kv.range_split.by_load_enabled` to:
-
-- `true` to enable load-based splitting _(default)_
-- `false` to disable load-based splitting
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING kv.range_split.by_load_enabled = true;
-~~~
-
-#### When to enable load-based splitting
-
-Load-based splitting is on by default and beneficial in almost all situations.
-
-#### When to disable load-based splitting
-
-You might want to disable load-based splitting when troubleshooting range-related issues under the guidance of our developers.
-
-### Control load-based splitting threshold
-
-Use [`SET CLUSTER SETTING`](set-cluster-setting.html) to set `kv.range_split.load_qps_threshold` to the queries-per-second (QPS) at which you want to consider splitting a range (defaults to `2500`):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING kv.range_split.load_qps_threshold = 2000;
-~~~
-
-#### When to modify the load-based splitting threshold
-
-Some workloads might find splitting ranges more aggressively (i.e., a lower QPS threshold) can improve performance.
-
-On the other hand, some workloads with very large machines might want to increase the QPS threshold to split more conservatively.
-
-## How load-based splitting works
-
-Whenever a range exceeds the cluster's setting for `kv.range_split.load_qps_threshold`, the range becomes eligible for load-based splitting.
-
-At that point, we begin gathering per-key metrics to determine whether or not a split would benefit the cluster's performance based on the following heuristics:
-
-- **Balance factor:** If we perform a split, would there be a balance of load on both sides of the split? For example, if 99% of the traffic is for a single key, splitting it apart from the others in the range will not have a substantial impact on performance. However, if 60% of the queries are for a single key, it is likely to benefit the cluster to move the key to its own range.
-
-- **Split crossing:** If we perform a split, how many queries would have to cross this new range boundary? Because involving multiple ranges in a query incurs greater overhead than a single range, splitting a range could actually degrade performance. For example, if the range is involved in many `SELECT COUNT(*)...` operations, splitting the range in two could negatively impact performance.
-
-### Determining a split point
-
-Using the per-key metrics gathered once a node exceeds the `kv.range_split.load_qps_threshold` value, we estimate a good place to perform a split by determining the total operations over the first set of keys that exceed the `kv.range_split.load_qps_threshold`.
-
-For example, if the operations on a single key exceed the `kv.range_split.load_qps_threshold` value, it's a good candidate to split the range at that point.
-
-Another example is that if the range has equal access among all keys, whose total operation exceeds `kv.range_split.load_qps_threshold`. By splitting the range at the first set of keys whose total operations exceed the threshold, we can reduce the load on the node. If the "other" range still exceeds the threshold, it will eventually be split again.
-
-In both of these examples, the split would only occur if the balance factor and split crossing heuristics determined the split would produce better results.
-
-## Why load-based splitting works
-
-CockroachDB creates a relatively even distribution of leaseholders throughout your cluster. ([Leaseholders](architecture/replication-layer.html#leases) are a single replica of a range that both serve reads and coordinate writes operations.)
-
-However, without load-based splitting this distribution is created without considering the load present on any set of keys. This means that even with an equitable distribution of leases throughout the cluster, some leases will generate more traffic for the node that houses them than others. Because each node can only provide so much throughput, a single node can become a bottleneck for providing access to a subset of data in your cluster.
-
-However, by leveraging load-based splitting, the cluster can understand load on a per-range basis and split up ranges that generate a significant amount of load into multiple ranges, and therefore multiple leaseholders. This lets the cluster express its load as a function of leases; so the roughly equal distribution of leases also generates a roughly equal distribution of traffic, preventing individual nodes from becoming bottlenecks for your cluster.
-
-This benefit is further amplified by [load-based rebalancing](architecture/replication-layer.html#load-based-replica-rebalancing), which ensures that all nodes contain replicas with a roughly equal load. By evenly distributing load throughout your cluster, it's easier to prevent bottlenecks from arising, as well as simplifying hardware forecasting.
-
-## See also
-
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
diff --git a/src/current/v20.2/make-queries-fast.md b/src/current/v20.2/make-queries-fast.md
deleted file mode 100644
index 0d828a5c3e1..00000000000
--- a/src/current/v20.2/make-queries-fast.md
+++ /dev/null
@@ -1,478 +0,0 @@
----
-title: Optimize Query Performance
-summary: How to make your queries run faster during application development
-toc: true
----
-
-This page provides an overview for optimizing query performance in CockroachDB. To get good performance, you need to look at how you're accessing the database through several lenses:
-
-- [SQL query performance](#sql-query-performance): This is the most common cause of performance problems, and where most developers should start.
-- [Schema design](#schema-design): Depending on your SQL schema and the data access patterns of your workload, you may need to make changes to avoid creating "hotspots".
-- [Cluster topology](#cluster-topology): As a distributed system, CockroachDB requires you to trade off latency vs. resiliency. This requires choosing the right cluster topology for your needs.
-
-{{site.data.alerts.callout_info}}
-If you aren't sure whether SQL query performance needs to be improved on your cluster, see [Identify slow queries](query-behavior-troubleshooting.html#identify-slow-queries).
-{{site.data.alerts.end}}
-
-## SQL query performance
-
-To get good SQL query performance, follow the rules below (in approximate order of importance):
-
-{{site.data.alerts.callout_info}}
-These rules apply to an environment where thousands of [OLTP](https://en.wikipedia.org/wiki/Online_transaction_processing) queries are being run per second, and each query needs to run in milliseconds. These rules are not intended to apply to analytical queries.
-{{site.data.alerts.end}}
-
-- [Rule 1. Scan as few rows as possible](#rule-1-scan-as-few-rows-as-possible). If your application is scanning more rows than necessary for a given query, it's going to be difficult to scale.
-- [Rule 2. Use the right index](#rule-2-use-the-right-index): Your query should use an index on the columns in the `WHERE` clause. You want to avoid the performance hit of a full table scan.
-- [Rule 3. Use the right join type](#rule-3-use-the-right-join-type): Depending on the relative sizes of the tables you are querying, the type of [join][joins] may be important. This should rarely be necessary because the [cost-based optimizer](cost-based-optimizer.html) should pick the best-performing join type if you add the right indexes as described in Rule 2.
-
-To show each of these rules in action, we will optimize a query against the [MovR data set](movr.html) as follows:
-
-1. Start a [local cluster](start-a-local-cluster.html).
-
-2. Populate the cluster with data by running the following [`cockroach workload`](cockroach-workload.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    cockroach workload init movr --num-histories 250000 --num-promo-codes 250000 --num-rides 125000 --num-users 12500 --num-vehicles 3750 'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-It's common to offer users promo codes to increase usage and customer loyalty. In this scenario, we want to find the 10 users who have taken the highest number of rides on a given date, and offer them promo codes that provide a 10% discount.
-
-To phrase it in the form of a question: "Who are the top 10 users by number of rides on a given date?"
-
-### Rule 1. Scan as few rows as possible
-
-First, let's study the schema so we understand the relationships between the tables.
-
-Start a SQL shell:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach sql --insecure
-~~~
-
-Next, set `movr` as the current database and run [`SHOW TABLES`](show-tables.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-USE movr;
-SHOW TABLES;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |              250000
-  public      | rides                      | table |              125000
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |               12500
-  public      | vehicle_location_histories | table |              250000
-  public      | vehicles                   | table |                3750
-(6 rows)
-~~~
-
-Let's look at the schema for the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                      create_statement
--------------+--------------------------------------------------------------
-  users      | CREATE TABLE public.users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | )
-(1 row)
-~~~
-
-There's no information about the number of rides taken here, nor anything about the days on which rides occurred. Luckily, there is also a `rides` table. Let's look at it:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SHOW CREATE TABLE rides;
-~~~
-
-~~~
-  table_name |                                                        create_statement
--------------+----------------------------------------------------------------------------------------------------------------------------------
-  rides      | CREATE TABLE public.rides (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     vehicle_city VARCHAR NULL,
-             |     rider_id UUID NULL,
-             |     vehicle_id UUID NULL,
-             |     start_address VARCHAR NULL,
-             |     end_address VARCHAR NULL,
-             |     start_time TIMESTAMP NULL,
-             |     end_time TIMESTAMP NULL,
-             |     revenue DECIMAL(10,2) NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     CONSTRAINT fk_city_ref_users FOREIGN KEY (city, rider_id) REFERENCES public.users(city, id),
-             |     CONSTRAINT fk_vehicle_city_ref_vehicles FOREIGN KEY (vehicle_city, vehicle_id) REFERENCES public.vehicles(city, id),
-             |     INDEX rides_auto_index_fk_city_ref_users (city ASC, rider_id ASC),
-             |     INDEX rides_auto_index_fk_vehicle_city_ref_vehicles (vehicle_city ASC, vehicle_id ASC),
-             |     FAMILY "primary" (id, city, vehicle_city, rider_id, vehicle_id, start_address, end_address, start_time, end_time, revenue),
-             |     CONSTRAINT check_vehicle_city_city CHECK (vehicle_city = city)
-             | )
-(1 row)
-~~~
-
-There is a `rider_id` field that we can use to match each ride to a user. There is also a `start_time` field that we can use to filter the rides by date.
-
-This means that to get the information we want, we'll need to do a [join][joins] on the `users` and `rides` tables.
-
-Next, let's get the row counts for the tables that we'll be using in this query. We need to understand which tables are large, and which are small by comparison. We will need this later if we need to verify we are [using the right join type](#rule-3-use-the-right-join-type).
-
-As specified above by our [`cockroach workload`](cockroach-workload.html) command, the `users` table has 12,500 records, and the `rides` table has 125,000 records. Because it's so large, we want to avoid scanning the entire `rides` table in our query. In this case, we can avoid scanning `rides` using an index, as shown in the next section.
-
-### Rule 2. Use the right index
-
-Below is a query that fetches the right answer to our question: "Who are the top 10 users by number of rides on a given date?"
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	name, count(rides.id) AS sum
-FROM
-	users JOIN rides ON users.id = rides.rider_id
-WHERE
-	rides.start_time BETWEEN '2018-12-31 00:00:00' AND '2020-01-01 00:00:00'
-GROUP BY
-	name
-ORDER BY
-	sum DESC
-LIMIT
-	10;
-~~~
-
-~~~
-        name       | sum
--------------------+------
-  William Brown    |  14
-  William Mitchell |  10
-  Joseph Smith     |  10
-  Paul Nelson      |   9
-  Christina Smith  |   9
-  Jennifer Johnson |   8
-  Jeffrey Walker   |   8
-  Joseph Jones     |   7
-  James Williams   |   7
-  Thomas Smith     |   7
-(10 rows)
-
-Server Execution Time: 103.41ms
-Network Latency: 822µs
-~~~
-
-Unfortunately, this query is a bit slow. 160 milliseconds puts us [over the limit where a user feels the system is reacting instantaneously](https://www.nngroup.com/articles/response-times-3-important-limits/), and we're still down in the database layer. This data still needs to be shipped back out to your application and displayed to the user.
-
-We can see why if we look at the output of [`EXPLAIN`](explain.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPLAIN SELECT
-	name, count(rides.id) AS sum
-FROM
-	users JOIN rides ON users.id = rides.rider_id
-WHERE
-	rides.start_time BETWEEN '2018-12-31 00:00:00' AND '2019-01-01 00:00:00'
-GROUP BY
-	name
-ORDER BY
-	sum DESC
-LIMIT
-	10;
-~~~
-
-~~~
-              tree              |        field        |                                   description
---------------------------------+---------------------+----------------------------------------------------------------------------------
-                                | distribution        | full
-                                | vectorized          | true
-  limit                         |                     |
-   │                            | count               | 10
-   └── sort                     |                     |
-        │                       | order               | -count_rows
-        └── group               |                     |
-             │                  | group by            | name
-             └── hash join      |                     |
-                  │             | equality            | (id) = (rider_id)
-                  ├── scan      |                     |
-                  │             | estimated row count | 12500
-                  │             | table               | users@primary
-                  │             | spans               | FULL SCAN
-                  └── filter    |                     |
-                       │        | filter              | (start_time >= '2018-12-31 00:00:00') AND (start_time <= '2019-01-01 00:00:00')
-                       └── scan |                     |
-                                | estimated row count | 125000
-                                | table               | rides@primary
-                                | spans               | FULL SCAN
-(20 rows)
-~~~
-
-The main problem is that we are doing full table scans on both the `users` and `rides` tables (see `spans | FULL SCAN`). This tells us that we do not have indexes on the columns in our `WHERE` clause, which is [an indexing best practice](indexes.html#best-practices).
-
-Therefore, we need to create an index on the column in our `WHERE` clause, in this case: `rides.start_time`.
-
-It's also possible that there is not an index on the `rider_id` column that we are doing a join against, which will also hurt performance.
-
-Before creating any more indexes, let's see what indexes already exist on the `rides` table by running [`SHOW INDEXES`](show-index.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-SHOW INDEXES FROM rides;
-~~~
-
-~~~
-  table_name |                  index_name                   | non_unique | seq_in_index | column_name  | direction | storing | implicit
--------------+-----------------------------------------------+------------+--------------+--------------+-----------+---------+-----------
-  rides      | primary                                       |   false    |            1 | city         | ASC       |  false  |  false
-  rides      | primary                                       |   false    |            2 | id           | ASC       |  false  |  false
-  rides      | rides_auto_index_fk_city_ref_users            |    true    |            1 | city         | ASC       |  false  |  false
-  rides      | rides_auto_index_fk_city_ref_users            |    true    |            2 | rider_id     | ASC       |  false  |  false
-  rides      | rides_auto_index_fk_city_ref_users            |    true    |            3 | id           | ASC       |  false  |   true
-  rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |    true    |            1 | vehicle_city | ASC       |  false  |  false
-  rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |    true    |            2 | vehicle_id   | ASC       |  false  |  false
-  rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |    true    |            3 | id           | ASC       |  false  |   true
-  rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |    true    |            4 | city         | ASC       |  false  |   true
-(9 rows)
-~~~
-
-As we suspected, there are no indexes on `start_time` or `rider_id`, so we'll need to create indexes on those columns.
-
-Because another performance best practice is to [create an index on the `WHERE` condition storing the join key](sql-tuning-with-explain.html#solution-create-a-secondary-index-on-the-where-condition-storing-the-join-key), we will create an index on `start_time` that stores the join key `rider_id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX ON rides (start_time) storing (rider_id);
-~~~
-
-Now that we have an index on the column in our `WHERE` clause that stores the join key, let's run the query again:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	name, count(rides.id) AS sum
-FROM
-	users JOIN rides ON users.id = rides.rider_id
-WHERE
-	rides.start_time BETWEEN '2018-12-31 00:00:00' AND '2019-01-01 00:00:00'
-GROUP BY
-	name
-ORDER BY
-	sum DESC
-LIMIT
-	10;
-~~~
-
-~~~
-        name       | sum
--------------------+------
-  William Brown    |   6
-  Laura Marsh      |   5
-  Joseph Smith     |   5
-  David Martinez   |   4
-  Michael Garcia   |   4
-  David Mitchell   |   4
-  Arthur Nielsen   |   4
-  Michael Bradford |   4
-  William Mitchell |   4
-  Jennifer Johnson |   4
-(10 rows)
-
-Server Execution Time: 24.523ms
-Network Latency: 325µs
-~~~
-
-This query is now running much faster than it was before we added the indexes (160ms vs. 25ms). This means we have an extra 135 milliseconds we can budget towards other areas of our application.
-
-To see what changed, let's look at the [`EXPLAIN`](explain.html) output:
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPLAIN SELECT
-	name, count(rides.id) AS sum
-FROM
-	users JOIN rides ON users.id = rides.rider_id
-WHERE
-	rides.start_time BETWEEN '2018-12-31 00:00:00' AND '2019-01-01 00:00:00'
-GROUP BY
-	name
-ORDER BY
-	sum DESC
-LIMIT
-	10;
-~~~
-
-As you can see, this query is no longer scanning the entire (larger) `rides` table. Instead, it is now doing a much smaller range scan against only the values in `rides` that match the index we just created on the `start_time` column (3975 rows instead of 125000).
-
-~~~
-            tree           |        field        |                    description
----------------------------+---------------------+----------------------------------------------------
-                           | distribution        | full
-                           | vectorized          | true
-  limit                    |                     |
-   │                       | count               | 10
-   └── sort                |                     |
-        │                  | order               | -count_rows
-        └── group          |                     |
-             │             | group by            | name
-             └── hash join |                     |
-                  │        | equality            | (id) = (rider_id)
-                  ├── scan |                     |
-                  │        | estimated row count | 12500
-                  │        | table               | users@primary
-                  │        | spans               | FULL SCAN
-                  └── scan |                     |
-                           | estimated row count | 3975
-                           | table               | rides@rides_start_time_idx
-                           | spans               | [/'2018-12-31 00:00:00' - /'2019-01-01 00:00:00']
-(18 rows)
-~~~
-
-
-### Rule 3. Use the right join type
-
-Out of the box, the [cost-based optimizer](cost-based-optimizer.html) will select the right join type for your query in the majority of cases. This statement becomes more and more true with every new release of CockroachDB. Therefore, you should only provide [join hints](cost-based-optimizer.html#join-hints) in your query if you can **prove** to yourself through experimentation that the optimizer should be using a different [join type](joins.html#join-algorithms) than it is selecting.
-
-We can confirm that in this case the optimizer has already found the right join type for this query by using a hint to force another join type.
-
-For example, we might think that a [lookup join](joins.html#lookup-joins) could perform better in this instance, since one of the tables in the join is 10x smaller than the other.
-
-In order to get CockroachDB to plan a lookup join in this case, we will need to add an explicit index on the join key for the right-hand-side table, in this case, `rides`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX ON rides (rider_id);
-~~~
-
-Next, we can specify the lookup join with a join hint:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	name, count(rides.id) AS sum
-FROM
-	users INNER LOOKUP JOIN rides ON users.id = rides.rider_id
-WHERE
-	(rides.start_time BETWEEN '2018-12-31 00:00:00' AND '2019-01-01 00:00:00')
-GROUP BY
-	name
-ORDER BY
-	sum DESC
-LIMIT
-	10;
-~~~
-
-~~~
-        name       | sum
--------------------+------
-  William Brown    |   6
-  Laura Marsh      |   5
-  Joseph Smith     |   5
-  Michael Garcia   |   4
-  David Mitchell   |   4
-  David Martinez   |   4
-  Arthur Nielsen   |   4
-  Jennifer Johnson |   4
-  William Mitchell |   4
-  Michael Bradford |   4
-(10 rows)
-
-Server Execution Time: 881.797ms
-Network Latency: 402µs
-~~~
-
-The results, however, are not good. The query is much slower using a lookup join than what CockroachDB planned for us earlier.
-
-The query is a little faster when we force CockroachDB to use a merge join:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	name, count(rides.id) AS sum
-FROM
-	users INNER MERGE JOIN rides ON users.id = rides.rider_id
-WHERE
-	(rides.start_time BETWEEN '2018-12-31 00:00:00' AND '2019-01-01 00:00:00')
-GROUP BY
-	name
-ORDER BY
-	sum DESC
-LIMIT
-	10;
-~~~
-
-~~~
-        name        | sum
-+-------------------+-----+
-  William Brown     |   6
-  Laura Marsh       |   5
-  Joseph Smith      |   5
-  Jennifer Ford     |   4
-  David Mitchell    |   4
-  William Mitchell  |   4
-  Christopher Allen |   4
-  Michael Bradford  |   4
-  Michael Garcia    |   4
-  Jennifer Johnson  |   4
-(10 rows)
-
-Time: 31.31ms
-~~~
-
-The results are consistently about 31-35ms with merge join vs. 25-27ms when we let CockroachDB choose the join type as shown in the previous section. In other words, forcing the merge join is slightly slower than if we had done nothing.
-
-## Schema design
-
-If you are following the instructions in [the SQL performance section](#sql-query-performance) and still not getting the performance you want, you may need to look at your schema design and data access patterns to make sure you are not creating "hotspots" in your cluster that will lead to performance problems due to transaction contention.
-
-You can avoid contention with the following strategies:
-
-- Use index keys with a more random distribution of values, as described in [Unique ID best practices](performance-best-practices-overview.html#unique-id-best-practices).
-- Make transactions smaller by operating on less data per transaction. This will offer fewer opportunities for transactions' data access to overlap.
-- [Split the table across multiple ranges](split-at.html) to distribute its data across multiple nodes for better load balancing of some write-heavy workloads.
-
-For more information about how to avoid performance problems caused by contention, see [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-
-## Cluster topology
-
-It's very important to make sure that the cluster topology you are using is the right one for your use case. Because CockroachDB is a distributed system that involves nodes communicating over the network, you need to choose the cluster topology that results in the right latency vs. resiliency tradeoff.
-
-For more information about how to choose the cluster topology that is right for your application, see [this list of topology patterns](topology-patterns.html).
-
-## See also
-
-Reference information:
-
-- [SQL Performance Best Practices](performance-best-practices-overview.html)
-- [SQL Tuning with `EXPLAIN`](sql-tuning-with-explain.html)
-- [Joins](joins.html)
-- [CockroachDB Performance](performance.html)
-- [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention)
-- [Topology Patterns](topology-patterns.html)
-
-Specific tasks:
-
-- [Connect to the Database](connect-to-the-database.html)
-- [Insert Data](insert-data.html)
-- [Query Data](query-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-- [Run Multi-Statement Transactions](run-multi-statement-transactions.html)
-- [Identify slow queries](query-behavior-troubleshooting.html#identify-slow-queries)
-- [Error Handling and Troubleshooting](error-handling-and-troubleshooting.html)
-- [Hello World Example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[joins]: joins.html
diff --git a/src/current/v20.2/manage-a-backup-schedule.md b/src/current/v20.2/manage-a-backup-schedule.md
deleted file mode 100644
index 8fa0ca9d6c3..00000000000
--- a/src/current/v20.2/manage-a-backup-schedule.md
+++ /dev/null
@@ -1,279 +0,0 @@
----
-title: Manage a Backup Schedule
-summary: Learn about how to create, manage, and restore from a schedule of periodic backups.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> You can create schedules in CockroachDB for periodic backups. Once a [backup schedule is created](#create-a-new-backup-schedule), you can do the following:
-
-- [Set up monitoring for the backup schedule](#set-up-monitoring-for-the-backup-schedule)
-- [View scheduled backup details](#view-scheduled-backup-details)
-- [View and control the backup schedule](#view-and-control-the-backup-schedule)
-- [View and control a backup initiated by a schedule](#view-and-control-a-backup-initiated-by-a-schedule)
-- [Restore from a scheduled backup](#restore-from-a-scheduled-backup)
-
-## Create a new backup schedule
-
-To create a new backup schedule, use the [`CREATE SCHEDULE FOR BACKUP`](create-schedule-for-backup.html) statement. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEDULE schedule_label
-  FOR BACKUP INTO 's3://test/backups/test_schedule_1?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=123'
-    WITH revision_history
-    RECURRING '@daily'
-    WITH SCHEDULE OPTIONS first_run = 'now';
-~~~
-
-In this example, a schedule labeled `schedule_label` is created to take daily (incremental) backups with revision history in AWS S3, with the first backup being taken now. A second [schedule for weekly full backups](create-schedule-for-backup.html#full-backup-clause) is also created by default. Both schedules have the same `label` (i.e., `schedule_label`).
-
-For more information about the different options available when creating a backup schedule, see [`CREATE SCHEDULE FOR BACKUP`](create-schedule-for-backup.html).
-
-## Set up monitoring for the backup schedule
-
-We recommend that you [monitor your backup schedule with Prometheus](monitoring-and-alerting.html#prometheus-endpoint), and alert when there are anomalies such as backups that have failed or no backups succeeding over a certain amount of time&mdash; at which point, you can inspect schedules by running [`SHOW SCHEDULES`](show-schedules.html).
-
-Metrics for scheduled backups fall into two categories:
-
-- Backup schedule-specific metrics, aggregated across all schedules:
-
-    - `schedules_BACKUP_started`: A counter for the total number of backups started by a schedule
-    - `schedules_BACKUP_succeeded`: A counter for the number of backups started by a schedule that succeeded
-    - `schedules_BACKUP_failed`: A counter for the number of backups started by a schedule that failed
-
-        When `schedules_BACKUP_failed` increments, run [`SHOW SCHEDULES`](show-schedules.html) to check which schedule is affected and to inspect the error in the `status` column.
-
-- Scheduler-specific metrics:
-
-    - `schedules.round.reschedule-wait`: The number of schedules that were rescheduled due to a currently running job. A value greater than 0 indicates that a previous backup was still running when a new scheduled backup was supposed to start. This corresponds to the [`on_previous_running=wait`](create-schedule-for-backup.html#on-previous-running-option) schedule option.
-
-    - `schedules.round.reschedule-skip`: The number of schedules that were skipped due to a currently running job. A value greater than 0 indicates that a previous backup was still running when a new scheduled backup was supposed to start. This corresponds to the [`on_previous_running=skip`](create-schedule-for-backup.html#on-previous-running-option) schedule option.
-
-{{site.data.alerts.callout_info}}
-`schedules.round.reschedule-wait` and `schedules.round.reschedule-skip` are gauge metrics and can be graphed. A continual positive value for either of these metrics may indicate a misconfigured backup cadence, and you should consider adjusting the cadence to avoid waiting for or skipping the next backup.
-{{site.data.alerts.end}}
-
-For a tutorial on how to use Prometheus to set up monitoring and alerting, see [Monitor CockroachDB with Prometheus](monitor-cockroachdb-with-prometheus.html).
-
-## View scheduled backup details
-
-<span class="version-tag">New in v20.2:</span> When a [backup is created by a schedule](create-schedule-for-backup.html), it is stored within a collection of backups in the given location. To view details for a backup created by a schedule, you can use the following:
-
-- `SHOW BACKUPS IN y` statement to [view a list of the full backup's subdirectories](#view-a-list-of-the-full-backups-subdirectories).
-- `SHOW BACKUP x IN y` statement to [view a list of the full and incremental backups that are stored in a specific full backup's subdirectory](#view-a-list-of-the-full-and-incremental-backups-in-a-specific-full-backup-subdirectory).
-
-For more details, see [`SHOW BACKUP`](show-backup.html).
-
-{% include {{ page.version.version }}/backups/show-scheduled-backups.md %}
-
-## View and control the backup schedule
-
-Once a backup schedule is successfully created, you can [view the schedule](#view-the-schedule), [pause the schedule](#pause-the-schedule), [resume the schedule](#resume-the-schedule), or [drop the schedule](#drop-the-schedule).
-
-### View the schedule
-
-{% include copy-clipboard.html %}
-~~~~
-> SHOW SCHEDULES;
-~~~~
-
-For more information, see [`SHOW SCHEDULES`](show-schedules.html).
-
-### Pause the schedule
-
-To pause a schedule, you can either specify the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~~ sql
-> PAUSE SCHEDULE 589963390487363585;
-~~~~
-
-Or nest a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `PAUSE SCHEDULES` statement:
-
-{% include copy-clipboard.html %}
-~~~~ sql
-> PAUSE SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'schedule_database';
-~~~~
-
-For more information, see [`PAUSE SCHEDULES`](pause-schedules.html).
-
-### Resume the schedule
-
-To resume a paused schedule, you can either specify the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~~ sql
-> RESUME SCHEDULE 589963390487363585;
-~~~~
-
-Or nest a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `RESUME SCHEDULES` statement:
-
-{% include copy-clipboard.html %}
-~~~~ sql
-> RESUME SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'schedule_database';
-~~~~
-
-For more information, see [`RESUME SCHEDULES`](resume-schedules.html).
-
-### Drop the schedule
-
-To drop a schedule, you can either specify the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~~ sql
-> DROP SCHEDULE 589963390487363585;
-~~~~
-
-Or nest a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `DROP SCHEDULES` statement:
-
-{% include copy-clipboard.html %}
-~~~~ sql
-> DROP SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'schedule_database';
-~~~~
-
-For more information, see [`DROP SCHEDULES`](drop-schedules.html).
-
-{{site.data.alerts.callout_danger}}
-`DROP SCHEDULE` does **not** cancel any in-progress jobs started by the schedule. Before you drop a schedule, [cancel any in-progress jobs](cancel-job.html) first, as you will not be able to look up the job ID once the schedule is dropped.
-{{site.data.alerts.end}}
-
-## View and control a backup initiated by a schedule
-
-After CockroachDB successfully initiates a scheduled backup, it registers the backup as a job. You can [view](#view-the-backup-job), [pause](#pause-the-backup-job), [resume](#resume-the-backup-job), or [cancel](#cancel-the-backup-job) each individual backup job.
-
-### View the backup job
-
-To view jobs for a specific [backup schedule](create-schedule-for-backup.html), use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW JOBS FOR SCHEDULE 590204387299262465;
-~~~
-~~~
-        job_id       | job_type |                                                                                                             description                                                                                   | statement | user_name | status  | running_status |             created              | started | finished |             modified             | fraction_completed | error | coordinator_id
----------------------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+-----------+---------+----------------+----------------------------------+---------+----------+----------------------------------+--------------------+-------+-----------------
-  590205481558802434 | BACKUP   | BACKUP INTO '/2020/09/15-161444.99' IN 's3://test/scheduled-backup-0915?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' AS OF SYSTEM TIME '2020-09-15 16:20:00+00:00' WITH revision_history, detached |           | root      | running | NULL           | 2020-09-15 16:20:18.347383+00:00 | NULL    | NULL     | 2020-09-15 16:20:18.347383+00:00 |                  0 |       |              0
-(1 row)
-~~~
-
-You can also view multiple schedules by nesting a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `SHOW JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW JOBS FOR SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'test_schedule';
-~~~
-
-~~~
-        job_id       | job_type |                                                                                                                 description                                                                                      | statement | user_name |  status   | running_status |             created              | started |             finished             |             modified             | fraction_completed | error | coordinator_id
----------------------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+-----------+-----------+----------------+----------------------------------+---------+----------------------------------+----------------------------------+--------------------+-------+-----------------
-  590204496007299074 | BACKUP   | BACKUP INTO '/2020/09/15-161444.99' IN 's3://test/scheduled-backup-0915?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' AS OF SYSTEM TIME '2020-09-15 16:14:44.991631+00:00' WITH revision_history, detached |           | root      | succeeded | NULL           | 2020-09-15 16:15:17.720725+00:00 | NULL    | 2020-09-15 16:15:20.913789+00:00 | 2020-09-15 16:15:20.910594+00:00 |                  1 |       |              0
-  590205481558802434 | BACKUP   | BACKUP INTO '/2020/09/15-161444.99' IN 's3://test/scheduled-backup-0915?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' AS OF SYSTEM TIME '2020-09-15 16:20:00+00:00' WITH revision_history, detached        |           | root      | succeeded | NULL           | 2020-09-15 16:20:18.347383+00:00 | NULL    | 2020-09-15 16:20:48.37873+00:00  | 2020-09-15 16:20:48.374256+00:00 |                  1 |       |              0
-(2 rows)
-~~~
-
-For more information, see [`SHOW JOBS`](show-jobs.html).
-
-### Pause the backup job
-
-To pause jobs for a specific [backup schedule](create-schedule-for-backup.html), use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOBS FOR SCHEDULE 590204387299262465;
-~~~
-~~~
-PAUSE JOBS FOR SCHEDULES 1
-~~~
-
-You can also pause multiple schedules by nesting a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `PAUSE JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOBS FOR SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'test_schedule';
-~~~
-
-~~~
-PAUSE JOBS FOR SCHEDULES 2
-~~~
-
-For more information, see [`PAUSE JOB`](pause-job.html).
-
-### Resume the backup job
-
-To resume jobs for a specific [backup schedule](create-schedule-for-backup.html), use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOBS FOR SCHEDULE 590204387299262465;
-~~~
-~~~
-RESUME JOBS FOR SCHEDULES 1
-~~~
-
-You can also resume multiple schedules by nesting a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `PAUSE JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOBS FOR SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'test_schedule';
-~~~
-
-~~~
-RESUME JOBS FOR SCHEDULES 2
-~~~
-
-For more information, see [`RESUME JOB`](resume-job.html).
-
-### Cancel the backup job
-
-To cancel jobs for a specific [backup schedule](create-schedule-for-backup.html), use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL JOBS FOR SCHEDULE 590204387299262465;
-~~~
-~~~
-CANCEL JOBS FOR SCHEDULES 1
-~~~
-
-You can also CANCEL multiple schedules by nesting a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `CANCEL JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL JOBS FOR SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'test_schedule';
-~~~
-
-~~~
-CANCEL JOBS FOR SCHEDULES 2
-~~~
-
-For more information, see [`CANCEL JOB`](cancel-job.html).
-
-## Restore from a scheduled backup
-
-To restore from a scheduled backup, use the [`RESTORE`](restore.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE
-    FROM 's3://test/backups/test_schedule_1/2020/08/19-035600.00?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x'
-    AS OF SYSTEM TIME '2020-08-19 03:50:00+00:00';
-~~~
-
-To view the backups stored within a collection, use the [`SHOW BACKUP`](#view-scheduled-backup-details) statement.
-
-## See also
-
-- [`CREATE SCHEDULE FOR BACKUP`](create-schedule-for-backup.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`SHOW BACKUP`](show-backup.html)
-- [`SHOW SCHEDULES`](show-schedules.html)
-- [`PAUSE SCHEDULES`](pause-schedules.html)
-- [`RESUME SCHEDULES`](resume-schedules.html)
-- [`DROP SCHEDULES`](drop-schedules.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`RESUME JOB`](pause-job.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/manage-long-running-queries.md b/src/current/v20.2/manage-long-running-queries.md
deleted file mode 100644
index 4449f3b904b..00000000000
--- a/src/current/v20.2/manage-long-running-queries.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Manage Long-Running Queries
-summary: Learn how to identify and cancel long-running queries.
-toc: true
----
-
-This page shows you how to identify and, if necessary, cancel SQL queries that are taking longer than expected to process.
-
-{{site.data.alerts.callout_success}} Schema changes are treated differently than other SQL queries. You can use <a href="show-jobs.html"><code>SHOW JOBS</code></a> to monitor the progress of schema changes and <a href="cancel-job.html"><code>CANCEL JOB</code></a> to cancel schema changes that are taking longer than expected. {{site.data.alerts.end}}
-
-
-## Identify long-running queries
-
-Use the [`SHOW QUERIES`](show-queries.html) statement to list details about currently active SQL queries, including each query's `start` timestamp:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER QUERIES]
-      WHERE application_name != '$ cockroach sql';
-~~~
-
-~~~
-              query_id             | node_id |            session_id            | user_name |              start               |                                 query                                 | client_address  | application_name | distributed |   phase
-+----------------------------------+---------+----------------------------------+-----------+----------------------------------+-----------------------------------------------------------------------+-----------------+------------------+-------------+-----------+
-  15f92c0dd24bec200000000000000003 |       3 | 15f92b0e4ea399680000000000000003 | root      | 2020-03-04 18:06:21.871708+00:00 | SELECT city, id FROM vehicles WHERE city = $1                         | 127.0.0.1:65088 |                  |    false    | executing
-  15f92c0dd26655d80000000000000001 |       1 | 15f92be36964ac800000000000000001 | root      | 2020-03-04 18:06:21.873515+00:00 | UPSERT INTO vehicle_location_histories VALUES ($1, $2, now(), $3, $4) | 127.0.0.1:65240 |                  |    false    | executing
-  15f92c0dd25882c80000000000000001 |       1 | 15f92aefb240d2980000000000000001 | root      | 2020-03-04 18:06:21.872608+00:00 | UPSERT INTO vehicle_location_histories VALUES ($1, $2, now(), $3, $4) | 127.0.0.1:65044 |                  |    false    | executing
-  15f92c0dd262cb980000000000000002 |       2 | 15f92b7dc85b7ba80000000000000002 | maxroach  | 2020-03-04 18:06:21.873286+00:00 | SELECT city, id FROM vehicles WHERE city = $1                         | 127.0.0.1:65196 |                  |    false    | executing
-~~~
-
-You can also filter for queries that have been running for a certain amount of time. For example, to find queries that have been running for more than 3 hours, you would run the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER QUERIES]
-      WHERE start < (now() - INTERVAL '3 hours');
-~~~
-
-## Cancel long-running queries
-
-Once you've identified a long-running query via [`SHOW QUERIES`](show-queries.html), note the `query_id` and use it with the [`CANCEL QUERY`](cancel-query.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL QUERY '15f92c0dd24bec200000000000000003';
-~~~
-
-When a query is successfully cancelled, CockroachDB sends a `query execution canceled` error to the client that issued the query.
-
-- If the canceled query was a single, stand-alone statement, no further action is required by the client.
-- If the canceled query was part of a larger, multi-statement [transaction](transactions.html), the client should then issue a [`ROLLBACK`](rollback-transaction.html) statement.
-
-You can cancel all queries from a particular application by using a subquery.
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-CANCEL QUERIES (SELECT query_id FROM [SHOW CLUSTER QUERIES]
-      WHERE application_name = 'test_app');
-~~~
-
-## Improve query performance
-
-After cancelling a long-running query, use the [`EXPLAIN`](explain.html) statement to examine it. It's possible that the query was slow because it performs a full-table scan. In these cases, you can likely improve the query's performance by [adding an index](create-index.html).
-
-*(More guidance around query performance optimization forthcoming.)*
-
-## See also
-
-- [`SHOW QUERIES`](show-queries.html)
-- [`CANCEL QUERY`](cancel-query.html)
-- [`EXPLAIN`](explain.html)
-- [Query Behavior Troubleshooting](query-behavior-troubleshooting.html)
diff --git a/src/current/v20.2/manual-deployment.md b/src/current/v20.2/manual-deployment.md
deleted file mode 100644
index ff1295a2652..00000000000
--- a/src/current/v20.2/manual-deployment.md
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: Manual Deployment
-summary: Learn how to deploy CockroachDB manually on-premises or on popular cloud platforms.
-toc: false
----
-
-Use the following guides to deploy CockroachDB manually on-premises or on popular cloud platforms:
-
-- [On-Premises](deploy-cockroachdb-on-premises.html)
-- [Amazon Web Services (AWS)](deploy-cockroachdb-on-aws.html)
-- [Digital Ocean](deploy-cockroachdb-on-digital-ocean.html)
-- [Google Cloud Platform (GCE)](deploy-cockroachdb-on-google-cloud-platform.html)
-- [Microsoft Azure](deploy-cockroachdb-on-microsoft-azure.html)
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## See also
-
-- [Production Checklist](recommended-production-settings.html)
-- [Orchestrated Deployment](orchestration.html)
-- [Monitoring and Alerting](monitoring-and-alerting.html)
-- [Local Deployment](start-a-local-cluster.html)
diff --git a/src/current/v20.2/migrate-from-avro.md b/src/current/v20.2/migrate-from-avro.md
deleted file mode 100644
index a8300adc047..00000000000
--- a/src/current/v20.2/migrate-from-avro.md
+++ /dev/null
@@ -1,223 +0,0 @@
----
-title: Migrate from Avro
-summary: Learn how to migrate data from Avro files into a CockroachDB cluster.
-toc: true
----
-
-This page has instructions for migrating data from Avro files into CockroachDB using [`IMPORT`][import].
-
-{% include {{ page.version.version }}/misc/import-perf.md %}
-
-## Step 1. Export data to Avro
-
-Please refer to the documentation of your database for instructions on exporting data to Avro.
-
-You will need to export one file per table, with the following requirements:
-
-- Files must be self-contained [object container file (OFC)](#import-an-object-container-file) or a [binary or JSON file](#import-binary-or-json-records) containing one Avro record per line.
-- Files must be UTF-8 encoded.
-
-### Data type mapping
-
-Avro data types will be flexibly mapped to the target schema; that is, Avro and CockroachDB SQL types do not need to match exactly. By default, CockroachDB ignores unknown Avro fields and sets any columns to `NULL` if they were not set in the Avro record.
-
-Use the table below for data type mappings:
-
- Avro Data Type | CockroachDB Data Type
-----------------+------------------------------------------------
-`BOOL`          | [`BOOL`](bool.html), [`STRING`](string.html)
-`INT`           | [`INT`](int.html), [`STRING`](string.html)
-`FLOAT`         | [`FLOAT`](float.html), [`STRING`](string.html)
-`STRING`        | [`STRING`](string.html)
-`BYTES`         | [`BYTES`](bytes.html), [`STRING`](string.html)
-`ARRAY`         | [`ARRAY`](array.html), [`STRING`](string.html)
-`UUID`          | [`STRING`](string.html)
-`DATE`          | [`STRING`](string.html)
-`TIME`          | [`STRING`](string.html)
-`INTERVAL`      | [`STRING`](string.html)
-`TIMESTAMP`     | [`STRING`](string.html)
-`JSON`          | [`STRING`](string.html)
-`BIT`           | [`STRING`](string.html)
-`DECIMAL`       | [`STRING`](string.html)
-
-{{site.data.alerts.callout_info}}
-CockroachDB will attempt to convert the Avro data type to the CockroachDB data type; otherwise, it will report an error.
-{{site.data.alerts.end}}
-
-## Step 2. Host the files where the cluster can access them
-
-Each node in the CockroachDB cluster needs to have access to the files being imported. There are several ways for the cluster to access the data; for more information on the types of storage [`IMPORT`][import] can pull from, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-{{site.data.alerts.callout_success}}
-We strongly recommend using cloud storage such as Amazon S3 or Google Cloud to host the data files you want to import.
-{{site.data.alerts.end}}
-
-## Step 3. Import the Avro
-
-To import Avro data:
-
-- [Import an object container file](#import-an-object-container-file).
-- [Import binary or JSON records](#import-binary-or-json-records).
-
-### Import an object container file
-
-An [object container file (OCF)](https://avro.apache.org/docs/current/spec.html#Object+Container+Files) is a self-contained Avro file and includes both the table schema and records. For Avro OCF, there is one available import [option][option]:
-
-- `strict_validation`, which rejects Avro records that do not have a [one-to-one data type mapping][datatypes] to the target schema. By default, CockroachDB ignores unknown Avro fields and sets missing SQL fields to `NULL`.
-
-{{site.data.alerts.callout_info}}
-The following example uses [sample data from Teradata](https://github.com/Teradata/kylo/tree/master/samples/sample-data/avro).
-{{site.data.alerts.end}}
-
-For example, to import the data from `userdata1.avro` into an `employees` table, issue the following [`IMPORT`][import] statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-		registration_dttm STRING,
-		id INT,
-		first_name STRING,
-		last_name STRING,
-		email STRING,
-		gender STRING,
-		ip_address STRING,
-		cc INT,
-		country STRING,
-		birthdate STRING,
-		salary FLOAT,
-		title STRING,
-		comments STRING
-  )
-  AVRO DATA (
-		's3://[bucket-placeholder]/userdata1.avro?AWS_ACCESS_KEY_ID=[placeholder]&AWS_SECRET_ACCESS_KEY=[placeholder]'
-	);
-~~~
-
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries | bytes
----------------------+-----------+--------------------+------+---------------+---------
-  535041064396062721 | succeeded |                  1 | 1000 |             0 | 162825
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM employees LIMIT 5;
-~~~
-
-~~~
-   registration_dttm   | id | first_name | last_name |          email           | gender |   ip_address   |        cc        |        country         | birthdate  |  salary   |          title           | comments
------------------------+----+------------+-----------+--------------------------+--------+----------------+------------------+------------------------+------------+-----------+--------------------------+-----------
-  2016-02-03T07:55:29Z |  1 | Amanda     | Jordan    | ajordan0@com.com         | Female | 1.197.201.2    | 6759521864920116 | Indonesia              | 3/8/1971   |  49756.53 | Internal Auditor         | 1E+02
-  2016-02-03T17:04:03Z |  2 | Albert     | Freeman   | afreeman1@is.gd          | Male   | 218.111.175.34 |             NULL | Canada                 | 1/16/1968  | 150280.17 | Accountant IV            |
-  2016-02-03T01:09:31Z |  3 | Evelyn     | Morgan    | emorgan2@altervista.org  | Female | 7.161.136.94   | 6767119071901597 | Russia                 | 2/1/1960   | 144972.51 | Structural Engineer      |
-  2016-02-03T12:36:21Z |  4 | Denise     | Riley     | driley3@gmpg.org         | Female | 140.35.109.83  | 3576031598965625 | China                  | 4/8/1997   |  90263.05 | Senior Cost Accountant   |
-  2016-02-03T05:05:31Z |  5 | Carlos     | Burns     | cburns4@miitbeian.gov.cn |        | 169.113.235.40 | 5602256255204850 | South Africa           |            | NULL      |                          |
-(5 rows)
-~~~
-
-Repeat the above for each OCF you want to import.
-
-{% include {{ page.version.version }}/sql/use-import-into.md %}
-
-{{site.data.alerts.callout_info}}
-You will need to run [`ALTER TABLE ... ADD CONSTRAINT`](add-constraint.html) to add any foreign key relationships.
-{{site.data.alerts.end}}
-
-### Import binary or JSON records
-
-In addition to importing [Avro OCF](#import-an-object-container-file), you can also import a binary or JSON file containing Avro records:
-
-- To import a binary file, use the `data_as_binary_records` [option][option].
-- To import a JSON file, use the `data_as_json_records` [option][option].
-
-The schema is not included in these types of files, so you need to specify the schema. You need to either:
-
-- Specify the schema inline with the `schema` [option][option].
-- Specify the schema by pointing to the file with the `schema_uri` [option][option].
-
-There are additional import [options][option] you can use when importing binary and JSON files:
-
-- `strict_validation`, which rejects Avro records that do not have a [one-to-one data type mapping][datatypes] to the target schema. By default, CockroachDB ignores unknown Avro fields and sets missing SQL fields to `NULL`.
-- `records_terminated_by`, which specifies the unicode character used to indicate new lines in the input binary or JSON file (default: `\n`).
-
-{{site.data.alerts.callout_info}}
-The following example uses sample data generated by [Avro tools](https://github.com/cockroachdb/cockroach/tree/master/pkg/ccl/importccl/testdata/avro).
-{{site.data.alerts.end}}
-
-For example, to import the data from `simple-schema.json` into an `simple` table, issue the following [`IMPORT`][import] statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE simple
-  CREATE USING
-	  's3://[bucket-placeholder]/simple-schema.sql?AWS_ACCESS_KEY_ID=[placeholder]&AWS_SECRET_ACCESS_KEY=[placeholder]'
-  AVRO DATA (
-		's3://[bucket-placeholder]/simple-sorted.json?AWS_ACCESS_KEY_ID=[placeholder]&AWS_SECRET_ACCESS_KEY=[placeholder]'
-	)
-  WITH
-	   data_as_json_records,
-	   schema = '{ "type": "record",
-  "name": "simple",
-  "fields":
-    [
-      { "name": "i", "type": "int" },
-      { "name": "s", "type": "string" },
-      { "name": "b", "type": ["null", "bytes"] }
-    ]
-}';
-~~~
-
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries | bytes
----------------------+-----------+--------------------+------+---------------+--------
-  535294613223669761 | succeeded |                  1 | 1000 |             0 | 50372
-(1 row)
-~~~
-
-~~~
-> SELECT * FROM  simple LIMIT 5;
-~~~
-
-~~~
-       i      |                 s                 |                   b
---------------+-----------------------------------+---------------------------------------------...
-  -2135825688 | dcpamywjlvtohbbtbtpypubccu        | \303\204\303\264\303\216\027\303\221\017\303...
-  -2135463332 | rmspluxnumigrpbrkfmuktphnmfskt    | \303\232\017i>{b.~\302\277\177A\302\264\303\...
-  -2132354298 | mebfxrhurtngsqvlyjechuglymuxfjpvv | \303\2541E\302\277\302\2714\302\257\303\201\...
-  -2131856455 | hfrgfefflpopvtemrspaixitncghwqfrr | NULL
-  -2116408431 | thuosfwm                          | \016s\026\303\264\303\247\302\201\302\264o\3...
-(5 rows)
-~~~
-
-Repeat the above for each binary or JSON file you want to import.
-
-{% include {{ page.version.version }}/sql/use-import-into.md %}
-
-{{site.data.alerts.callout_info}}
-You will need to run [`ALTER TABLE ... ADD CONSTRAINT`](add-constraint.html) to add any foreign key relationships.
-{{site.data.alerts.end}}
-
-## See also
-
-- [`IMPORT`][import]
-- [Import Performance Best Practices](import-performance-best-practices.html)
-- [Migrate from CSV][csv]
-- [Migrate from MySQL][mysql]
-- [Migrate from Postgres][postgres]
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back Up and Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference Links -->
-
-[csv]: migrate-from-csv.html
-[postgres]: migrate-from-postgres.html
-[mysql]: migrate-from-mysql.html
-[import]: import.html
-[option]: import.html#import-options
-[datatypes]: migrate-from-avro.html#data-type-mapping
diff --git a/src/current/v20.2/migrate-from-csv.md b/src/current/v20.2/migrate-from-csv.md
deleted file mode 100644
index 4b144139ce7..00000000000
--- a/src/current/v20.2/migrate-from-csv.md
+++ /dev/null
@@ -1,207 +0,0 @@
----
-title: Migrate from CSV
-summary: Learn how to migrate data from CSV files into a CockroachDB cluster.
-toc: true
----
-
-This page has instructions for migrating data from CSV files into CockroachDB using [`IMPORT`][import].
-
-The examples below use the [employees data set](https://github.com/datacharmer/test_db) that is also used in the [MySQL docs](https://dev.mysql.com/doc/employee/en/).
-
-The examples below pull real data from [Amazon S3](https://aws.amazon.com/s3/).  They use the [employees data set](https://github.com/datacharmer/test_db) that is also used in the [MySQL docs](https://dev.mysql.com/doc/employee/en/), dumped as a set of CSV files.
-
-{% include {{ page.version.version }}/misc/import-perf.md %}
-
-## Step 1. Export data to CSV
-
-Please refer to the documentation of your database for instructions on exporting data to CSV.
-
-You will need to export one CSV file per table, with the following requirements:
-
-- Files must be in [valid CSV format](https://tools.ietf.org/html/rfc4180), with the caveat that the delimiter must be a single character.  To use a character other than comma (such as a tab), set a custom delimiter using the [`delimiter` option](import.html#delimiter).
-- Files must be UTF-8 encoded.
-- If one of the following characters appears in a field, the field must be enclosed by double quotes:
-    - delimiter (`,` by default)
-    - double quote (`"`)
-    - newline (`\n`)
-    - carriage return (`\r`)
-- If double quotes are used to enclose fields, then a double quote appearing inside a field must be escaped by preceding it with another double quote.  For example: `"aaa","b""bb","ccc"`
-- If a column is of type [`BYTES`](bytes.html), it can either be a valid UTF-8 string or a [hex-encoded byte literal](sql-constants.html#hexadecimal-encoded-byte-array-literals) beginning with `\x`. For example, a field whose value should be the bytes `1`, `2` would be written as `\x0102`.
-
-## Step 2. Host the files where the cluster can access them
-
-Each node in the CockroachDB cluster needs to have access to the files being imported. There are several ways for the cluster to access the data; for more information on the types of storage [`IMPORT`][import] can pull from, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-{{site.data.alerts.callout_success}}
-We strongly recommend using cloud storage such as Amazon S3 or Google Cloud to host the data files you want to import.
-{{site.data.alerts.end}}
-
-## Step 3. Import the CSV
-
-You will need to write an [`IMPORT TABLE`][import] statement that matches the schema of the table data you're importing.
-
-For example, to import the data from `employees.csv` into an `employees` table, issue the following statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  ) CSV DATA ('https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/csv/employees.csv.gz');
-~~~
-
-~~~
-       job_id       |  status   | fraction_completed |  rows  | index_entries | system_records |  bytes   
---------------------+-----------+--------------------+--------+---------------+----------------+----------
- 381866942129111041 | succeeded |                  1 | 300024 |             0 |              0 | 13258389
-(1 row)
-~~~
-
-Repeat the above for each CSV file you want to import.
-
-{% include {{ page.version.version }}/sql/use-import-into.md %}
-
-{% include {{ page.version.version }}/misc/csv-import-callout.md %}
-
-{{site.data.alerts.callout_info}}
-You will need to run [`ALTER TABLE ... ADD CONSTRAINT`](add-constraint.html) to add any foreign key relationships.
-{{site.data.alerts.end}}
-
-## Configuration Options
-
-The following options are available to [`IMPORT ... CSV`][import]:
-
-+ [Column delimiter](#column-delimiter)
-+ [Comment syntax](#comment-syntax)
-+ [Skip header rows](#skip-header-rows)
-+ [Null strings](#null-strings)
-+ [File compression](#file-compression)
-
-### Column delimiter
-
-The `delimiter` option is used to set the Unicode character that marks where each column ends.  **Default: `,`**.
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  )
-  CSV DATA ('s3://acme-co/employees.csv?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456')
-        WITH delimiter = e'\t';
-~~~
-
-### Comment syntax
-
-The `comment` option determines which Unicode character marks the rows in the data to be skipped.
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  )
-  CSV DATA ('s3://acme-co/employees.csv?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456')
-        WITH comment = '#';
-~~~
-
-### Skip header rows
-
-The `skip` option determines the number of header rows to skip when importing a file.
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  )
-  CSV DATA ('s3://acme-co/employees.csv?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456')
-        WITH skip = '2';
-~~~
-
-### Null strings
-
-The `nullif` option defines which string should be converted to `NULL`.
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  )
-  CSV DATA ('s3://acme-co/employees.csv?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456')
-        WITH nullif = '';
-~~~
-
-### File compression
-
-The `compress` option defines which decompression codec should be used on the CSV file to be imported.  Options include:
-
-+ `gzip`: Uses the [gzip](https://en.wikipedia.org/wiki/Gzip) algorithm to decompress the file.
-+ `bzip`: Uses the [bzip](https://en.wikipedia.org/wiki/Bzip2) algorithm to decompress the file.
-+ `none`: Disables decompression.
-+ `auto`: **Default**. Guesses based on file extension ('none' for `.csv`, 'gzip' for `.gz`, 'bzip' for `.bz` and `.bz2`).
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  )
-  CSV DATA ('s3://acme-co/employees.csv.gz?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456')
-        WITH compress = 'gzip';
-~~~
-
-## See also
-
-- [`IMPORT`][import]
-- [Import Performance Best Practices](import-performance-best-practices.html)
-- [Migrate from MySQL][mysql]
-- [Migrate from Postgres][postgres]
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back Up and Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference Links -->
-
-[postgres]: migrate-from-postgres.html
-[mysql]: migrate-from-mysql.html
-[import]: import.html
diff --git a/src/current/v20.2/migrate-from-geojson.md b/src/current/v20.2/migrate-from-geojson.md
deleted file mode 100644
index ec4f90ad099..00000000000
--- a/src/current/v20.2/migrate-from-geojson.md
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: Migrate from GeoJSON
-summary: Learn how to migrate data from GeoJSON into a CockroachDB cluster.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: CockroachDB supports efficiently storing and querying [spatial data](spatial-data.html).
-
-This page has instructions for migrating data from the [GeoJSON](https://en.wikipedia.org/wiki/GeoJSON) format into CockroachDB using [`ogr2ogr`](https://gdal.org/programs/ogr2ogr.html) and [`IMPORT`][import].
-
-In the example below we will import a data set with [the locations of underground storage tanks in the state of Vermont (USA)](https://anrweb.vt.gov/DEC/ERT/UST.aspx?ustfacilityid=96).
-
-## Before You Begin
-
-To follow along with the example below, you will need the following prerequisites:
-
-- CockroachDB [installed](install-cockroachdb.html) and [running](start-a-local-cluster.html)
-- [`ogr2ogr`](https://gdal.org/programs/ogr2ogr.html)
-- [Python 3](https://www.python.org)
-
-{% include {{page.version.version}}/spatial/ogr2ogr-supported-version.md %}
-
-## Step 1. Download the GeoJSON data
-
-First, download the storage tank GeoJSON data:
-
-{% include copy-clipboard.html %}
-~~~ shell
-wget -O tanks.geojson https://geodata.vermont.gov/datasets/986155613c5743239e7b1980b45bbf36_162.geojson
-~~~
-
-## Step 2. Convert the GeoJSON data to SQL
-
-Next, convert the GeoJSON data to SQL using the following `ogr2ogr` command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-ogr2ogr -f PGDUMP tanks.sql -lco LAUNDER=NO -lco DROP_TABLE=OFF tanks.geojson
-~~~
-
-{% include {{page.version.version}}/spatial/ogr2ogr-supported-version.md %}
-
-## Step 3. Host the files where the cluster can access them
-
-Each node in the CockroachDB cluster needs to have access to the files being imported.  There are several ways for the cluster to access the data; for a complete list of the types of storage [`IMPORT`][import] can pull from, see [import file locations](import.html#import-file-location).
-
-For local testing, you can [start a local file server](use-a-local-file-server-for-bulk-operations.html).  The following command will start a local file server listening on port 3000:
-
-{% include copy-clipboard.html %}
-~~~ shell
-python3 -m http.server 3000
-~~~
-
-## Step 4. Prepare the database
-
-Next, create a database to hold the storage tank data:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach sql --insecure
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE DATABASE IF NOT EXISTS tanks;
-USE tanks;
-~~~
-
-## Step 5. Import the SQL
-
-Since the file is being served from a local server and is formatted as Postgres-compatible SQL, we can import the data using the following [`IMPORT PGDUMP`](import.html#import-a-postgres-database-dump) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-IMPORT PGDUMP ('http://localhost:3000/tanks.sql');
-~~~
-
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries | bytes
----------------------+-----------+--------------------+------+---------------+---------
-  588555793549328385 | succeeded |                  1 | 2709 |          2709 | 822504
-(1 row)
-~~~
-
-## See also
-
-- [`IMPORT`][import]
-- [Export Spatial Data](export-spatial-data.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
-- [Migration Overview](migration-overview.html)
-- [Migrate from MySQL][mysql]
-- [Migrate from Postgres][postgres]
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back Up and Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference Links -->
-
-[postgres]: migrate-from-postgres.html
-[mysql]: migrate-from-mysql.html
-[import]: import.html
diff --git a/src/current/v20.2/migrate-from-geopackage.md b/src/current/v20.2/migrate-from-geopackage.md
deleted file mode 100644
index adb1442bb48..00000000000
--- a/src/current/v20.2/migrate-from-geopackage.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: Migrate from GeoPackages
-summary: Learn how to migrate data from GeoPackages into a CockroachDB cluster.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: CockroachDB supports efficiently storing and querying [spatial data](spatial-data.html).
-
-This page has instructions for migrating data from the [GeoPackage](https://www.geopackage.org/) format into CockroachDB using [`ogr2ogr`](https://gdal.org/programs/ogr2ogr.html) and [`IMPORT`][import].
-
-In the example below we will import a data set with <a href="https://gisdata.mn.gov/dataset/env-mn-springs-inventory" data-proofer-ignore>the locations of natural springs in the state of Minnesota (USA)<a/> that is made available via <a href="https://gisdata.mn.gov" data-proofer-ignore>gisdata.mn.gov</a>.
-
-## Before You Begin
-
-To follow along with the example below, you will need the following prerequisites:
-
-- CockroachDB [installed](install-cockroachdb.html) and [running](start-a-local-cluster.html)
-- [`ogr2ogr`](https://gdal.org/programs/ogr2ogr.html)
-- [Python 3](https://www.python.org)
-
-{% include {{page.version.version}}/spatial/ogr2ogr-supported-version.md %}
-
-## Step 1. Download the GeoPackage data
-
-First, download the zip file containing the spring location data:
-
-{% include copy-clipboard.html %}
-~~~ shell
-wget https://resources.gisdata.mn.gov/pub/gdrs/data/pub/us_mn_state_dnr/env_mn_springs_inventory/gpkg_env_mn_springs_inventory.zip
-~~~
-
-Next, unzip the file:
-
-{% include copy-clipboard.html %}
-~~~ shell
-unzip gpkg_env_mn_springs_inventory.zip
-~~~
-
-## Step 2. Convert the GeoPackage data to SQL
-
-To load the GeoPackage into CockroachDB, we must first convert it to SQL using the `ogr2ogr` tool.
-
-{% include copy-clipboard.html %}
-~~~ shell
-ogr2ogr -f PGDUMP springs.sql -lco LAUNDER=NO -lco DROP_TABLE=OFF env_mn_springs_inventory.gpkg
-~~~
-
-This particular data set emits a warning  due to some date formatting.
-
-~~~
-Warning 1: Non-conformant content for record 1 in column field_ch_1, 2017/05/04, successfully parsed
-~~~
-
-{% include {{page.version.version}}/spatial/ogr2ogr-supported-version.md %}
-
-## Step 3. Host the files where the cluster can access them
-
-Each node in the CockroachDB cluster needs to have access to the files being imported.  There are several ways for the cluster to access the data; for a complete list of the types of storage [`IMPORT`][import] can pull from, see [import file locations](import.html#import-file-location).
-
-For local testing, you can [start a local file server](use-a-local-file-server-for-bulk-operations.html).  The following command will start a local file server listening on port 3000:
-
-{% include copy-clipboard.html %}
-~~~ shell
-python3 -m http.server 3000
-~~~
-
-## Step 4. Prepare the database
-
-Next, create a database to hold the natural spring location data:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach sql --insecure
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE DATABASE springs;
-USE springs;
-~~~
-
-## Step 5. Import the SQL
-
-Since the file is being served from a local server and is formatted as Postgres-compatible SQL, we can import the data using the following [`IMPORT PGDUMP`](import.html#import-a-postgres-database-dump) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-IMPORT PGDUMP ('http://localhost:3000/springs.sql');
-~~~
-
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries |  bytes
----------------------+-----------+--------------------+------+---------------+----------
-  589053379352526849 | succeeded |                  1 | 5124 |          5124 | 2449139
-(1 row)
-~~~
-
-## See also
-
-- [`IMPORT`][import]
-- [Export Spatial Data](export-spatial-data.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
-- [Migration Overview](migration-overview.html)
-- [Migrate from MySQL][mysql]
-- [Migrate from Postgres][postgres]
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back Up and Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference Links -->
-
-[postgres]: migrate-from-postgres.html
-[mysql]: migrate-from-mysql.html
-[import]: import.html
diff --git a/src/current/v20.2/migrate-from-mysql.md b/src/current/v20.2/migrate-from-mysql.md
deleted file mode 100644
index aff73ac11f7..00000000000
--- a/src/current/v20.2/migrate-from-mysql.md
+++ /dev/null
@@ -1,218 +0,0 @@
----
-title: Migrate from MySQL
-summary: Learn how to migrate data from MySQL into a CockroachDB cluster.
-toc: true
----
-
-This page has instructions for migrating data from MySQL to CockroachDB using [`IMPORT`](import.html)'s support for reading [`mysqldump`][mysqldump] files.
-
-The examples below use the [employees data set](https://github.com/datacharmer/test_db) that is also used in the [MySQL docs](https://dev.mysql.com/doc/employee/en/).
-
-{% include {{ page.version.version }}/misc/import-perf.md %}
-
-## Considerations
-
-In addition to the general considerations listed in the [Migration Overview](migration-overview.html), there is also the following MySQL-specific information to consider as you prepare your migration.
-
-### String case sensitivity
-
-MySQL strings are case-insensitive by default, but strings in CockroachDB are case-sensitive.  This means that you may need to edit your MySQL dump file to get the results you expect from CockroachDB.  For example, you may have been doing string comparisons in MySQL that will need to be changed to work with CockroachDB.
-
-For more information about the case sensitivity of strings in MySQL, see [Case Sensitivity in String Searches](https://dev.mysql.com/doc/refman/8.0/en/case-sensitivity.html) from the MySQL documentation.  For more information about CockroachDB strings, see [`STRING`](string.html).
-
-### `FIELD` function
-
-The MYSQL `FIELD` function is not supported in CockroachDB. Instead, you can use the [`array_position`](functions-and-operators.html#array-functions) function, which returns the index of the first occurrence of element in the array.
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT array_position(ARRAY[4,1,3,2],1);
-~~~
-
-~~~
-  array_position
-------------------
-               2
-(1 row)
-~~~
-
-While MYSQL returns 0 when the element is not found, CockroachDB returns `NULL`. So if you are using the `ORDER BY` clause in a statement with the `array_position` function, the caveat is that sort is applied even when the element is not found. As a workaround, you can use the [`COALESCE`](functions-and-operators.html#conditional-and-function-like-operators) operator.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM table_a ORDER BY COALESCE(array_position(ARRAY[4,1,3,2],5),999);
-~~~
-
-## Step 1. Dump the MySQL database
-
-There are several ways to dump data from MySQL to be imported into CockroachDB:
-
-- [Dump the entire database](#dump-the-entire-database)
-- [Dump one table at a time](#dump-one-table-at-a-time)
-
-### Dump the entire database
-
-Most users will want to import their entire MySQL database all at once, as shown below in [Import a full database dump](#import-a-full-database-dump).  To dump the entire database, run the [`mysqldump`][mysqldump] command shown below:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ mysqldump -uroot employees > /tmp/employees-full.sql
-~~~
-
-If you only want to import one table from a database dump, see [Import a table from a full database dump](#import-a-table-from-a-full-database-dump) below.
-
-### Dump one table at a time
-
-To dump the `employees` table from a MySQL database also named `employees`, run the [`mysqldump`][mysqldump] command shown below.  You can import this table using the instructions in [Import a table from a table dump](#import-a-table-from-a-table-dump) below.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ mysqldump -uroot employees employees > employees.sql
-~~~
-
-## Step 2. Host the files where the cluster can access them
-
-Each node in the CockroachDB cluster needs to have access to the files being imported.  There are several ways for the cluster to access the data; for more information on the types of storage [`IMPORT`][import] can pull from,  see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-{{site.data.alerts.callout_success}}
-We strongly recommend using cloud storage such as Amazon S3 or Google Cloud to host the data files you want to import.
-{{site.data.alerts.end}}
-
-## Step 3. Import the MySQL dump file
-
-You can choose from several variants of the [`IMPORT`][import] statement, depending on whether you want to import an entire database or just one table:
-
-- [Import a full database dump](#import-a-full-database-dump)
-- [Import a table from a full database dump](#import-a-table-from-a-full-database-dump)
-- [Import a table from a table dump](#import-a-table-from-a-table-dump)
-
-All of the [`IMPORT`][import] statements in this section pull real data from [Amazon S3](https://aws.amazon.com/s3/) and will kick off background import jobs that you can monitor with [`SHOW JOBS`](show-jobs.html).
-
-{% include {{ page.version.version }}/sql/use-import-into.md %}
-
-### Import a full database dump
-
-This example assumes you [dumped the entire database](#dump-the-entire-database).
-
-The [`IMPORT`][import] statement below reads the data and [DDL](https://en.wikipedia.org/wiki/Data_definition_language) statements (including `CREATE TABLE` and [foreign key constraints](foreign-key.html)) from the full database dump.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE IF NOT EXISTS employees;
-> USE employees;
-> IMPORT MYSQLDUMP 'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/mysqldump/employees-full.sql.gz';
-~~~
-
-~~~
-       job_id       |  status   | fraction_completed |  rows   | index_entries | system_records |   bytes
---------------------+-----------+--------------------+---------+---------------+----------------+-----------
- 382716507639906305 | succeeded |                  1 | 3919015 |        331636 |              0 | 110104816
-(1 row)
-~~~
-
-### Import a table from a full database dump
-
-This example assumes you [dumped the entire database](#dump-the-entire-database).
-
-[`IMPORT`][import] can import one table's data from a full database dump.  It reads the data and applies any `CREATE TABLE` statements from the dump file.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE IF NOT EXISTS employees;
-> USE employees;
-> IMPORT TABLE employees FROM MYSQLDUMP 'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/mysqldump/employees.sql.gz';
-~~~
-
-~~~
-       job_id       |  status   | fraction_completed |  rows  | index_entries | system_records |  bytes
---------------------+-----------+--------------------+--------+---------------+----------------+----------
- 383839294913871873 | succeeded |                  1 | 300024 |             0 |              0 | 11534293
-(1 row)
-~~~
-
-### Import a table from a table dump
-
-The examples below assume you [dumped one table](#dump-one-table-at-a-time).
-
-The simplest way to import a table dump is to run [`IMPORT TABLE`][import] as shown below.  It reads the table data and any `CREATE TABLE` statements from the dump file.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE IF NOT EXISTS employees;
-> USE employees;
-> IMPORT TABLE employees FROM MYSQLDUMP 'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/mysqldump/employees.sql.gz';
-~~~
-
-~~~
-       job_id       |  status   | fraction_completed |  rows  | index_entries | system_records |  bytes   
---------------------+-----------+--------------------+--------+---------------+----------------+----------
- 383855569817436161 | succeeded |                  1 | 300024 |             0 |              0 | 11534293
-(1 row)
-~~~
-
-If you need to specify the table's columns for some reason, you can use an [`IMPORT TABLE`][import] statement like the one below, which will import data but ignore any `CREATE TABLE` statements in the dump file, instead relying on the columns you specify.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE IF NOT EXISTS employees;
-> USE employees;
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  )
-  MYSQLDUMP DATA ('https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/mysqldump/employees.sql.gz');
-~~~
-
-## Configuration Options
-
-The following options are available to `IMPORT ... MYSQLDUMP`:
-
-+ [Skip foreign keys](#skip-foreign-keys)
-
-### Skip foreign keys
-
-By default, [`IMPORT ... MYSQLDUMP`][import] supports foreign keys.  **Default: false**.  Add the `skip_foreign_keys` option to speed up data import by ignoring foreign key constraints in the dump file's DDL.  It will also enable you to import individual tables that would otherwise fail due to dependencies on other tables.
-
-{{site.data.alerts.callout_info}}
-The most common dependency issues are caused by unsatisfied foreign key relationships. You can avoid these issues by adding the `skip_foreign_keys` option to your `IMPORT` statement as needed. For more information, see the list of [import options](import.html#import-options).
-
-For example, if you get the error message `pq: there is no unique constraint matching given keys for referenced table tablename`, use `IMPORT ... WITH skip_foreign_keys`.
-{{site.data.alerts.end}}
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT MYSQLDUMP 's3://your-external-storage/employees.sql?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456' WITH skip_foreign_keys;
-~~~
-
-[Foreign key constraints](foreign-key.html) can be added by using [`ALTER TABLE ... ADD CONSTRAINT`](add-constraint.html) commands after importing the data.
-
-## See also
-
-- [`IMPORT`](import.html)
-- [Import Performance Best Practices](import-performance-best-practices.html)
-- [Migrate from CSV][csv]
-- [Migrate from Postgres][postgres]
-- [Can a Postgres or MySQL application be migrated to CockroachDB?](frequently-asked-questions.html#can-a-postgresql-or-mysql-application-be-migrated-to-cockroachdb)
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back up Data](take-full-and-incremental-backups.html)
-- [Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference Links -->
-
-[postgres]: migrate-from-postgres.html
-[csv]: migrate-from-csv.html
-[import]: import.html
-[mysqldump]: https://dev.mysql.com/doc/refman/8.0/en/mysqldump-sql-format.html
diff --git a/src/current/v20.2/migrate-from-openstreetmap.md b/src/current/v20.2/migrate-from-openstreetmap.md
deleted file mode 100644
index e7e7ef53cba..00000000000
--- a/src/current/v20.2/migrate-from-openstreetmap.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: Migrate from OpenStreetMap
-summary: Learn how to migrate data from the OpenStreetMap pbf format into a CockroachDB cluster.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: CockroachDB supports efficiently storing and querying [spatial data](spatial-data.html).
-
-This page has instructions for migrating data from [OpenStreetMap](https://www.openstreetmap.org) `.pbf` data files into CockroachDB using [`osm2pgsql`](https://github.com/openstreetmap/osm2pgsql/) and [`IMPORT`][import].
-
-In the example below we will import the [OSM data for Australia](https://download.geofabrik.de/australia-oceania/australia.html) that is available from [GeoFabrik GmbH](http://www.geofabrik.de/data/shapefiles.html).
-
-## Before You Begin
-
-To follow along with the example below, you will need the following prerequisites:
-
-- CockroachDB [installed](install-cockroachdb.html) and [running](start-a-local-cluster.html)
-- [`osm2pgsql`](https://github.com/openstreetmap/osm2pgsql/)
-
-## Step 1. Download the OpenStreetMap data
-
-First, download the OSM data:
-
-{% include copy-clipboard.html %}
-~~~ shell
-wget https://download.geofabrik.de/australia-oceania/australia-latest.osm.pbf
-~~~
-
-## Step 2. Prepare the database
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach sql --insecure
-~~~
-
-Next, create a database to hold the Australia map data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE DATABASE IF NOT EXISTS australia;
-USE australia;
-~~~
-
-## Step 3. Import the OpenStreetMap data
-
-Run the `osm2pgsql` command shown below to convert the OSM data and import it into the `australia` database. The arguments to `osm2pgsql` shown below assume a [locally running insecure cluster](start-a-local-cluster.html) and may need to be changed depending on your system. You may also need to tweak the cache setting (`-C`) depending on your system's hardware.
-
-{% include copy-clipboard.html %}
-~~~ shell
-osm2pgsql -C 2048 -d australia -U root -H localhost -P 26257 australia-latest.osm.pbf
-~~~
-
-This will take a few (30+) minutes to run on a laptop, and there will be a lot of output. A successful run will look something like the following:
-
-~~~
-osm2pgsql version 1.3.0
-
-Allocating memory for dense node cache
-Allocating dense node cache in one big chunk
-Allocating memory for sparse node cache
-Sharing dense sparse
-Node-cache: cache=2048MB, maxblocks=32768*65536, allocation method=3
-Using built-in tag processing pipeline
-Using projection SRS 3857 (Spherical Mercator)
-WARNING:  setting session var "synchronous_commit" is a no-op
-WARNING:  setting session var "synchronous_commit" is a no-op
-Setting up table: planet_osm_point
-NOTICE:  UNLOGGED TABLE will behave as a regular table in CockroachDB
-NOTICE:  storage parameter "autovacuum_enabled = 'off'" is ignored
-WARNING:  setting session var "synchronous_commit" is a no-op
-Setting up table: planet_osm_line
-NOTICE:  UNLOGGED TABLE will behave as a regular table in CockroachDB
-NOTICE:  storage parameter "autovacuum_enabled = 'off'" is ignored
-WARNING:  setting session var "synchronous_commit" is a no-op
-Setting up table: planet_osm_polygon
-NOTICE:  UNLOGGED TABLE will behave as a regular table in CockroachDB
-NOTICE:  storage parameter "autovacuum_enabled = 'off'" is ignored
-WARNING:  setting session var "synchronous_commit" is a no-op
-Setting up table: planet_osm_roads
-NOTICE:  UNLOGGED TABLE will behave as a regular table in CockroachDB
-NOTICE:  storage parameter "autovacuum_enabled = 'off'" is ignored
-
-Reading in file: australia-latest.osm.pbf
-Using PBF parser.
-Processing: Node(66994k 411.0k/s) Way(4640k 7.13k/s) Relation(124777 1313.4/s)  parse time: 909s
-Node stats: total(66994811), max(7888181047) in 163s
-Way stats: total(4640490), max(845495883) in 651s
-Relation stats: total(124777), max(11596803) in 95s
-Sorting data and creating indexes for planet_osm_point
-node cache: stored: 66994811(100.00%), storage efficiency: 50.93% (dense blocks: 800, sparse nodes: 62492547), hit rate: 100.00%
-Sorting data and creating indexes for planet_osm_line
-Sorting data and creating indexes for planet_osm_polygon
-Sorting data and creating indexes for planet_osm_roads
-Using native order for clustering
-Using native order for clustering
-Using native order for clustering
-Using native order for clustering
-Copying planet_osm_roads to cluster by geometry finished
-Creating geometry index on planet_osm_roads
-Copying planet_osm_point to cluster by geometry finished
-Creating geometry index on planet_osm_point
-Creating indexes on planet_osm_roads finished
-Copying planet_osm_polygon to cluster by geometry finished
-Creating geometry index on planet_osm_polygon
-All indexes on planet_osm_roads created in 318s
-Completed planet_osm_roads
-Copying planet_osm_line to cluster by geometry finished
-Creating geometry index on planet_osm_line
-Creating indexes on planet_osm_point finished
-All indexes on planet_osm_point created in 1084s
-Completed planet_osm_point
-Creating indexes on planet_osm_polygon finished
-All indexes on planet_osm_polygon created in 1897s
-Completed planet_osm_polygon
-Creating indexes on planet_osm_line finished
-All indexes on planet_osm_line created in 1961s
-Completed planet_osm_line
-
-Osm2pgsql took 2879s overall
-~~~
-
-## See also
-
-- [`IMPORT`][import]
-- [Export Spatial Data](export-spatial-data.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Migrate from GeoPackages](migrate-from-geopackage.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
-- [Migration Overview](migration-overview.html)
-- [Migrate from MySQL][mysql]
-- [Migrate from Postgres][postgres]
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back Up and Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference Links -->
-
-[postgres]: migrate-from-postgres.html
-[mysql]: migrate-from-mysql.html
-[import]: import.html
diff --git a/src/current/v20.2/migrate-from-oracle.md b/src/current/v20.2/migrate-from-oracle.md
deleted file mode 100644
index 4d6681b593b..00000000000
--- a/src/current/v20.2/migrate-from-oracle.md
+++ /dev/null
@@ -1,391 +0,0 @@
----
-title: Migrate from Oracle
-summary: Learn how to migrate data from Oracle into a CockroachDB cluster.
-toc: true
----
-
-This page has instructions for migrating data from Oracle into CockroachDB by [importing](import.html) CSV files. Note that `IMPORT` only works for creating new tables. For information on how to add CSV data to existing tables, see [`IMPORT INTO`](import-into.html).
-
-To illustrate this process, we use the following sample data and tools:
-
-- [Swingbench OrderEntry data set](http://www.dominicgiles.com/swingbench.html), which is based on the `oe` schema that ships with Oracle Database 11g and Oracle Database 12c.
-- [Oracle Data Pump](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sutil/oracle-data-pump.html), which enables the movement of data and metadata from one database to another, and comes with all Oracle installations.
-- [SQL*Plus](https://docs.oracle.com/database/121/SQPUG/ch_three.htm), the interactive and batch query tool that comes with every Oracle Database installation.
-
-{% include {{ page.version.version }}/misc/import-perf.md %}
-
-## Step 1. Export the Oracle schema
-
-Using [Oracle's Data Pump Export utility](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sutil/oracle-data-pump-export-utility.html), export the schema:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ expdp user/password directory=datapump dumpfile=oracle_example.dmp content=metadata_only logfile=example.log
-~~~
-
-The schema is stored in an Oracle-specific format (e.g., `oracle_example.dmp`).
-
-## Step 2. Convert the Oracle schema to SQL
-
-Using [Oracle's Data Pump Import utility](https://docs.oracle.com/en/database/oracle/oracle-database/12.2/sutil/datapump-import-utility.html), load the exported DMP file to convert it to a SQL file:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ impdp user/password directory=datapump dumpfile=oracle_example.dmp sqlfile=example_sql.sql TRANSFORM=SEGMENT_ATTRIBUTES:N:table PARTITION_OPTIONS=MERGE
-~~~
-
-This SQL output will be used later, in [Step 7](#step-7-map-oracle-to-cockroachdb-data-types).
-
-## Step 3. Export table data
-
-You need to extract each table's data into a data list file (`.lst`). We wrote a simple SQL script (`spool.sql`) to do this:
-
-~~~ shell
-$ cat spool.sql
-
-SET ECHO OFF
-SET TERMOUT OFF
-SET FEEDBACK OFF
-SET PAGESIZE 0
-SET TRIMSPOOL ON
-SET WRAP OFF
-set linesize 30000
-SET RECSEP OFF
-SET VERIFY OFF
-SET ARRAYSIZE 10000
-SET COLSEP '|'
-
-SPOOL '&1'
-
-ALTER SESSION SET nls_date_format = 'YYYY-MM-DD HH24:MI:SS';
-  # Used to set a properly formatted date for CockroachDB
-
-SELECT * from &1;
-
-SPOOL OFF
-
-SET PAGESIZE 24
-SET FEEDBACK ON
-SET TERMOUT ON
-~~~
-
-{{site.data.alerts.callout_info}}
-In the example SQL script, `|` is used as a delimiter. Choose a delimiter that will not also occur in the rows themselves. For more information, see [`IMPORT`](import.html#delimiter).
-{{site.data.alerts.end}}
-
-To extract the data, we ran the script for each table in SQL*Plus:
-
-{% include copy-clipboard.html %}
-~~~ sql
-$ sqlplus user/password
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> @spool CUSTOMERS
-  @spool ADDRESSES
-  @spool CARD_DETAILS
-  @spool WAREHOUSES
-  @spool ORDER_ITEMS
-  @spool ORDERS
-  @spool INVENTORIES
-  @spool PRODUCT_INFORMATION
-  @spool LOGON
-  @spool PRODUCT_DESCRIPTIONS
-  @spool ORDERENTRY_METADATA
-~~~
-
-A data list file (`.lst`) with leading and trailing spaces is created for each table.
-
-Exit SQL*Plus:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXIT
-~~~
-
-## Step 4. Configure and convert the table data to CSV
-
-Each table's data list file needs to be converted to CSV and formatted for CockroachDB. We wrote a simple Python script (`fix-example.py`) to do this:
-
-~~~ python
-$ cat fix-example.py
-
-import csv
-import string
-import sys
-
-for lstfile in sys.argv[1:]:
-  filename = lstfile.split(".")[0]
-
-  with open(lstfile) as f:
-    reader = csv.reader(f, delimiter="|")
-    with open(filename+".csv", "w") as fo:
-      writer = csv.writer(fo)
-      for rec in reader:
-        writer.writerow(map(string.strip, rec))
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ python3 fix-example.py CUSTOMERS.lst ADDRESSES.lst CARD_DETAILS.lst WAREHOUSES.lst ORDER_ITEMS.lst ORDERS.lst INVENTORIES.lst PRODUCT_INFORMATION.lst LOGON.lst PRODUCT_DESCRIPTIONS.lst ORDERENTRY_METADATA.lst
-~~~
-
-Format the generated CSV files to meet the CockroachDB's [CSV requirements](#csv-requirements).
-
-### CSV requirements
-
-You will need to export one CSV file per table, with the following requirements:
-
-- Files must be in [valid CSV format](https://tools.ietf.org/html/rfc4180).
-- Files must be UTF-8 encoded.
-- If one of the following characters appears in a field, the field must be enclosed by double quotes:
-    - delimiter (`,` by default)
-    - double quote (`"`)
-    - newline (`\n`)
-    - carriage return (`\r`)
-- If double quotes are used to enclose fields, then a double quote appearing inside a field must be escaped by preceding it with another double quote.  For example: `"aaa","b""bb","ccc"`
-- If a column is of type [`BYTES`](bytes.html), it can either be a valid UTF-8 string or a [hex-encoded byte literal](sql-constants.html#hexadecimal-encoded-byte-array-literals) beginning with `\x`. For example, a field whose value should be the bytes `1`, `2` would be written as `\x0102`.
-
-### CSV configuration options
-
-The following options are available to [`IMPORT ... CSV`](import.html):
-
-- [Column delimiter](migrate-from-csv.html#column-delimiter)
-- [Comment syntax](migrate-from-csv.html#comment-syntax)
-- [Skip header rows](migrate-from-csv.html#skip-header-rows)
-- [Null strings](migrate-from-csv.html#null-strings)
-- [File compression](migrate-from-csv.html#file-compression)
-
-For usage examples, see [Migrate from CSV - Configuration Options](migrate-from-csv.html#configuration-options).
-
-## Step 5. Compress the CSV files
-
-Compress the CSV files for a faster import:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ gzip CUSTOMERS.csv ADDRESSES.csv CARD_DETAILS.csv WAREHOUSES.csv ORDER_ITEMS.csv ORDERS.csv INVENTORIES.csv PRODUCT_INFORMATION.csv LOGON.csv PRODUCT_DESCRIPTIONS.csv ORDERENTRY_METADATA.csv
-~~~
-
-These compressed CSV files will be used to import your data into CockroachDB.
-
-## Step 6. Host the files where the cluster can access them
-
-Each node in the CockroachDB cluster needs to have access to the files being imported. There are several ways for the cluster to access the data; for more information on the types of storage [`IMPORT`](import.html) can pull from, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-{{site.data.alerts.callout_success}}
-We strongly recommend using cloud storage such as Amazon S3 or Google Cloud to host the data files you want to import.
-{{site.data.alerts.end}}
-
-## Step 7. Map Oracle to CockroachDB data types
-
-Using the SQL file created in [Step 2](#step-2-convert-the-oracle-schema-to-sql), write [`IMPORT TABLE`](import.html) statements that match the schemas of the table data you're importing.
-
-Remove all Oracle-specific attributes, remap all Oracle data types, refactor all [`CREATE TABLE`](create-table.html) statements to include [primary keys](primary-key.html).
-
-### Data type mapping
-
-Use the table below for data type mappings:
-
- Oracle Data Type | CockroachDB Data Type
-------------------+-----------------------
-`BLOB` | [`BYTES`](bytes.html) [<sup>1</sup>](#considerations)
-`CHAR(n)`, `CHARACTER(n)`<br>n < 256 | [`CHAR(n)`, `CHARACTER(n)`](string.html)
-`CLOB` | [`STRING`](string.html) [<sup>1</sup>](#considerations)
-`DATE` | [`DATE`](date.html)
-`FLOAT(n)` | [`DECIMAL(n)`](decimal.html)
-`INTERVAL YEAR(p) TO MONTH `| [`VARCHAR`](string.html), [`INTERVAL`](interval.html)
-`INTERVAL DAY(p) TO SECOND(s)` | [`VARCHAR`](string.html), [`INTERVAL`](interval.html)
-`JSON` | [`JSON`](jsonb.html) [<sup>2</sup>](#considerations)
-`LONG` | [`STRING`](string.html)
-`LONG RAW` | [`BYTES`](bytes.html)
-`NCHAR(n)`<br>n < 256 | [`CHAR(n)`](string.html )
-`NCHAR(n)`<br>n > 255 | [`VARCHAR`, `STRING`](string.html)
-`NCLOB` | [`STRING`](string.html)
-`NUMBER(p,0)`, `NUMBER(p)`<br>1 <= p < 5 | [`INT2`](int.html) [<sup>3</sup>](#considerations)
-`NUMBER(p,0)`, `NUMBER(p)`<br>5 <= p < 9 | [`INT4`](int.html) [<sup>3</sup>](#considerations)
-`NUMBER(p,0)`, `NUMBER(p)`<br>9 <= p < 19 | [`INT8`](int.html) [<sup>3</sup>](#considerations)
-`NUMBER(p,0)`, `NUMBER(p)`<br>19 <= p <= 38 | [`DECIMAL(p)`](decimal.html)
-`NUMBER(p,s)`<br>s > 0 | [`DECIMAL(p,s)`](decimal.html)
-`NUMBER`, `NUMBER(\*)` | [`DECIMAL`](decimal.html)
-`NVARCHAR2(n)` | [`VARCHAR(n)`](string.html)
-`RAW(n)` | [`BYTES`](bytes.html)
-`TIMESTAMP(p)` | [`TIMESTAMP`](timestamp.html)
-`TIMESTAMP(p) WITH TIME ZONE` | [`TIMESTAMP WITH TIMEZONE`](timestamp.html)
-`VARCHAR(n)`, `VARCHAR2(n)` | [`VARCHAR(n)`](string.html)
-`XML` | [`JSON`](jsonb.html) [<sup>2</sup>](#considerations)
-
-<a name="considerations"></a>
-
-- <sup>1</sup> `BLOBS` and `CLOBS` should be converted to [`BYTES`](bytes.html), or [`STRING`](string.html) where the size is variable, but it's recommended to keep values under 1 MB to ensure performance. Anything above 1 MB would require refactoring into an object store with a pointer embedded in the table in place of the object.
-- <sup>2</sup> `JSON` and `XML` types can be converted to [`JSONB`](jsonb.html) using any XML to JSON conversion. `XML` must be converted to `JSONB` before importing into CockroachDB.
-- <sup>3</sup> When converting `NUMBER(p,0)`, consider `NUMBER` types with Base-10 limits map to the Base-10 Limits for CockroachDB [`INT`](int.html) types. Optionally, `NUMBERS` can be converted to [`DECIMAL`](decimal.html).
-
-When moving from Oracle to CockroachDB data types, consider the following:
-
-- [Schema changes within transactions](known-limitations.html#schema-changes-within-transactions)
-- [Schema changes between executions of prepared statements](online-schema-changes.html#no-schema-changes-between-executions-of-prepared-statements)
-- If [`JSON`](jsonb.html) columns are used only for payload, consider switching to [`BYTES`](bytes.html).
-- Max size of a single column family (512 MiB by default).
-
-For more information, see [Known Limitations](known-limitations.html), [Online Schema Changes](online-schema-changes.html), and [Transactions](transactions.html).
-
-### NULLs
-
-For information on how CockroachDB handles `NULL`s, see [NULL Handling](null-handling.html) and [NOT NULL Constraint](not-null.html).
-
-### Primary key, constraints, and secondary indexes
-
-Cockroach distributes a table by the [primary key](primary-key.html) or by a default `ROWID` when a primary key is not provided. This also requires the primary key creation to be part of the table creation. Using the above [data type mapping](#data-type-mapping), refactor each table DDL to include the [primary key](primary-key.html), [constraints](constraints.html), and [secondary indexes](indexes.html).
-
-For more information and examples, refer to the following:
-
-- [`CREATE TABLE` - Create a table](create-table.html)
-- [Define Table Partitions](partitioning.html)
-- [Constraints - Supported constraints](constraints.html#supported-constraints)
-
-### Privileges for users and roles
-
-The Oracle privileges for [users](create-user.html) and [roles](create-role.html) must be rewritten for CockroachDB. Once the CockroachDB cluster is [secured](security-overview.html), CockroachDB follows the same [role-based access control](authorization.html) methodology as Oracle.   
-
-
-## Step 8. Import the CSV
-
-For example, to import the data from `CUSTOMERS.csv.gz` into a new `CUSTOMERS` table, issue the following statement in the CockroachDB SQL shell:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-        customer_id       DECIMAL
-                          NOT NULL
-                          PRIMARY KEY,
-        cust_first_name   VARCHAR(40) NOT NULL,
-        cust_last_name    VARCHAR(40) NOT NULL,
-        nls_language      VARCHAR(3),
-        nls_territory     VARCHAR(30),
-        credit_limit      DECIMAL(9,2),
-        cust_email        VARCHAR(100),
-        account_mgr_id    DECIMAL,
-        customer_since    DATE,
-        customer_class    VARCHAR(40),
-        suggestions       VARCHAR(40),
-        dob               DATE,
-        mailshot          VARCHAR(1),
-        partner_mailshot  VARCHAR(1),
-        preferred_address DECIMAL,
-        preferred_card    DECIMAL,
-        INDEX cust_email_ix (cust_email),
-        INDEX cust_dob_ix (dob),
-        INDEX cust_account_manager_ix (
-            account_mgr_id
-        )
-       )
-   CSV DATA (
-        'https://your-bucket-name.s3.us-east-2.amazonaws.com/CUSTOMERS.csv.gz'
-       )
-  WITH delimiter = e'\t',
-       "nullif" = '',
-       decompress = 'gzip';
-~~~
-
-~~~
-       job_id       |  status   | fraction_completed |  rows  | index_entries | system_records |  bytes   
---------------------+-----------+--------------------+--------+---------------+----------------+----------
- 381866942129111041 | succeeded |                  1 | 300024 |             0 |              0 | 13258389
-(1 row)
-~~~
-
-{% include {{ page.version.version }}/sql/use-import-into.md %}
-
-Then add the [computed columns](computed-columns.html), [constraints](add-constraint.html), and [function-based indexes](create-index.html). For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE CUSTOMERS SET credit_limit = 50000 WHERE credit_limit > 50000;
-  ALTER TABLE CUSTOMERS ADD CONSTRAINT CUSTOMER_CREDIT_LIMIT_MAX CHECK (credit_limit <= 50000);
-  ALTER TABLE CUSTOMERS ADD COLUMN LOW_CUST_LAST_NAME STRING AS (lower(CUST_LAST_NAME)) STORED;
-  ALTER TABLE CUSTOMERS ADD COLUMN LOW_CUST_FIRST_NAME STRING AS (lower(CUST_FIRST_NAME)) STORED;
-  CREATE INDEX CUST_FUNC_LOWER_NAME_IX on CUSTOMERS (LOW_CUST_LAST_NAME,CUST_FIRST_NAME);
-~~~
-
-Repeat the above for each CSV file you want to import.
-
-## Step 9. Refactor application SQL
-
-The last phase of the migration process is to change the [transactional behavior](#transactions-locking-and-concurrency-control) and [SQL dialect](#sql-dialect) of your application.
-
-### Transactions, locking, and concurrency control
-
-Both Oracle and CockroachDB support [multi-statement transactions](transactions.html), which are atomic and guarantee ACID semantics. However, CockroachDB operates in a serializable isolation mode while Oracle defaults to read committed, which can create both non-repeatable reads and phantom reads when a transaction reads data twice. It is typical that Oracle developers will use `SELECT FOR UPDATE` to work around read committed issues. The [`SELECT FOR UPDATE`](select-for-update.html) statement is also supported in CockroachDB.
-
-Regarding locks, Cockroach utilizes a [lightweight latch](architecture/transaction-layer.html#latch-manager) to serialize access to common keys across concurrent transactions. Oracle and CockroachDB transaction control flows only have a few minor differences; for more details, refer to [Transactions - SQL statements](transactions.html#sql-statements).  
-
-As CockroachDB does not allow serializable anomalies, [transactions](begin-transaction.html) may experience deadlocks or [read/write contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). This is expected during concurrency on the same keys. These can be addressed with either [automatic retries](transactions.html#automatic-retries) or [client-side intervention techniques](transactions.html#client-side-intervention).  
-
-### SQL dialect
-
-Cockroach is ANSI SQL compliant with a Postgres dialect, which allows you to use [native drivers](install-client-drivers.html) to connect applications and ORMs to CockroachDB. CockroachDB’s [SQL Layer](architecture/sql-layer.html#sql-api) supports full relational schema and SQL (similar to Oracle).
-
-You will have to refactor Oracle SQL and functions that do not comply with [ANSI SQL-92](https://en.wikipedia.org/wiki/SQL-92) in order to work with CockroachDB. For more information about the [Cockroach SQL Grammar](sql-grammar.html) and a [SQL comparison](sql-feature-support.html), see below:
-
-- [SQL best practices](performance-best-practices-overview.html)
-- [Common table expressions (CTE)](common-table-expressions.html)
-- `DUAL` table
-
-    Oracle requires use of the `DUAL` table, as Oracle requires a `SELECT ... FROM`. In CockroachDB, all reference to the `DUAL` table should be eliminated.
-
-- [Function call syntax](functions-and-operators.html#string-and-byte-functions)
-- [Hints](cost-based-optimizer.html#join-hints)
-
-    See also: [Table Expressions - Force index selection](table-expressions.html#force-index-selection)
-
-- [Joins](joins.html)
-
-    CockroachDB supports [`HASH`](joins.html#hash-joins), [`MERGE`](joins.html#merge-joins), and [`LOOKUP`](joins.html#lookup-joins) joins. Oracle uses the `+` operator for `LEFT` and `RIGHT` joins, but CockroachDB uses the ANSI join syntax.
-
-- [Sequences](create-sequence.html)
-
-    Sequences in CockroachDB do not require a trigger to self-increment; place the sequence in the table DDL:
-
-    ~~~
-    > CREATE TABLE customer_list (
-        id INT PRIMARY KEY DEFAULT nextval('customer_seq'),
-        customer string,
-        address string
-      );
-    ~~~  
-
-- [Subqueries](subqueries.html)
-- `SYSDATE`
-
-    CockroachDB does not support `SYSDATE`; however, it does support date and time with the following:
-
-    ~~~
-    > SELECT transaction_timestamp(), clock_timestamp();
-    ~~~
-
-    ~~~
-    > SELECT current_timestamp
-    ~~~
-
-    ~~~
-    > SELECT now();
-    ~~~
-
-- [Window functions](window-functions.html)
-
-## See also
-
-- [`IMPORT`](import.html)
-- [Import Performance Best Practices](import-performance-best-practices.html)
-- [Migrate from CSV](migrate-from-csv.html)
-- [Migrate from MySQL](migrate-from-mysql.html)
-- [Migrate from Postgres](migrate-from-postgres.html)
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back Up and Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/migrate-from-postgres.md b/src/current/v20.2/migrate-from-postgres.md
deleted file mode 100644
index 9c013f43ba2..00000000000
--- a/src/current/v20.2/migrate-from-postgres.md
+++ /dev/null
@@ -1,240 +0,0 @@
----
-title: Migrate from Postgres
-summary: Learn how to migrate data from Postgres into a CockroachDB cluster.
-toc: true
----
-
-This page has instructions for migrating data from Postgres to CockroachDB using [`IMPORT`][import]'s support for reading [`pg_dump`][pgdump] files.
-
-The examples below pull real data from [Amazon S3](https://aws.amazon.com/s3/).  They use the [employees data set](https://github.com/datacharmer/test_db) that is also used in the [MySQL docs](https://dev.mysql.com/doc/employee/en/).  The data was imported to Postgres using [pgloader][pgloader], and then modified for use here as explained below.
-
-{% include {{ page.version.version }}/misc/import-perf.md %}
-
-## Step 1. Dump the Postgres database
-
-There are several ways to dump data from Postgres to be imported into CockroachDB:
-
-- [Dump the entire database](#dump-the-entire-database)
-- [Dump one table at a time](#dump-one-table-at-a-time)
-
-The import will fail if the dump file contains functions or type definitions.  In addition to calling [`pg_dump`][pgdump] as shown below, you may need to edit the dump file to remove functions and data types.
-
-Also, note that CockroachDB's [`IMPORT`][import] does not support automatically importing data from Postgres' non-public [schemas][pgschema].  As a workaround, you can edit the dump file to change the table and schema names in the `CREATE TABLE` statements.
-
-### Dump the entire database
-
-Most users will want to import their entire Postgres database all at once, as shown below in [Import a full database dump](#import-a-full-database-dump).
-
-To dump the entire database, run the [`pg_dump`][pgdump] command shown below.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pg_dump employees > /tmp/employees-full.sql
-~~~
-
-For this data set, the Postgres dump file required the following edits, which have already been performed on the files used in the examples below:
-
-- The type of the `employees.gender` column in the `CREATE TABLE` statement had to be changed from `employees.employees_gender` to [`STRING`](string.html) since Postgres represented the employee's gender using a [`CREATE TYPE`](https://www.postgresql.org/docs/10/static/sql-createtype.html) statement that is not supported by CockroachDB.
-
-- A `CREATE TYPE employee ...` statement needed to be removed.
-
-If you only want to import one table from a database dump, see [Import a table from a full database dump](#import-a-table-from-a-full-database-dump) below.
-
-### Dump one table at a time
-
-To dump the `employees` table from a Postgres database also named `employees`, run the [`pg_dump`][pgdump] command shown below.  You can import this table using the instructions in [Import a table from a table dump](#import-a-table-from-a-table-dump) below.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ pg_dump -t employees  employees > /tmp/employees.sql
-~~~
-
-For this data set, the Postgres dump file required the following edits, which have already been performed on the files used in the examples below.
-
-- The type of the `employees.gender` column in the `CREATE TABLE` statement had to be changed from `employees.employees_gender` to [`STRING`](string.html) since Postgres represented the employee's gender using a [`CREATE TYPE`](https://www.postgresql.org/docs/10/static/sql-createtype.html) statement that is not supported by CockroachDB.
-
-## Step 2. Host the files where the cluster can access them
-
-Each node in the CockroachDB cluster needs to have access to the files being imported. There are several ways for the cluster to access the data; for more information on the types of storage [`IMPORT`](import.html) can pull from, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-{{site.data.alerts.callout_success}}
-We strongly recommend using cloud storage such as Amazon S3 or Google Cloud to host the data files you want to import.
-{{site.data.alerts.end}}
-
-## Step 3. Import the Postgres dump file
-
-You can choose from several variants of the [`IMPORT`][import] statement, depending on whether you want to import a full database or a single table:
-
-- [Import a full database dump](#import-a-full-database-dump)
-- [Import a table from a full database dump](#import-a-table-from-a-full-database-dump)
-- [Import a table from a table dump](#import-a-table-from-a-table-dump)
-
-Note that all of the [`IMPORT`][import] statements in this section pull real data from [Amazon S3](https://aws.amazon.com/s3/) and will kick off background import jobs that you can monitor with [`SHOW JOBS`](show-jobs.html).
-
-{% include {{ page.version.version }}/sql/use-import-into.md %}
-
-### Import a full database dump
-
-This example assumes you [dumped the entire database](#dump-the-entire-database).
-
-The [`IMPORT`][import] statement below reads the data and [DDL](https://en.wikipedia.org/wiki/Data_definition_language) statements (including existing foreign key relationships) from the full database dump file.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT PGDUMP 'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/employees-full.sql.gz';
-~~~
-
-~~~
-       job_id       |  status   | fraction_completed |  rows  | index_entries | system_records |  bytes
---------------------+-----------+--------------------+--------+---------------+----------------+----------
- 381845110403104769 | succeeded |                  1 | 300024 |             0 |              0 | 11534293
-(1 row)
-~~~
-
-### Import a table from a full database dump
-
-This example assumes you [dumped the entire database](#dump-the-entire-database).
-
-[`IMPORT`][import] can import one table's data from a full database dump.  It reads the data and applies any `CREATE TABLE` statements from the file.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE IF NOT EXISTS employees;
-> USE employees;
-> IMPORT TABLE employees FROM PGDUMP 'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/employees-full.sql.gz';
-~~~
-
-~~~
-       job_id       |  status   | fraction_completed |  rows  | index_entries | system_records |  bytes
---------------------+-----------+--------------------+--------+---------------+----------------+----------
- 383839294913871873 | succeeded |                  1 | 300024 |             0 |              0 | 11534293
-(1 row)
-~~~
-
-### Import a table from a table dump
-
-The examples below assume you [dumped one table](#dump-one-table-at-a-time).
-
-The simplest way to import a table dump is to run [`IMPORT TABLE`][import] as shown below.  It reads the table data and any `CREATE TABLE` statements from the file.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE IF NOT EXISTS employees;
-> USE employees;
-> IMPORT PGDUMP 'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/employees.sql.gz';
-~~~
-
-~~~
-       job_id       |  status   | fraction_completed |  rows  | index_entries | system_records |  bytes   
---------------------+-----------+--------------------+--------+---------------+----------------+----------
- 383855569817436161 | succeeded |                  1 | 300024 |             0 |              0 | 11534293
-(1 row)
-~~~
-
-If you need to specify the table's columns for some reason, you can use an [`IMPORT TABLE`][import] statement like the one below, which will import data but ignore any `CREATE TABLE` statements in the file, instead relying on the columns you specify.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  )
-  PGDUMP DATA ('https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/employees.sql.gz');
-~~~
-
-## Configuration Options
-
-The following options are available to `IMPORT ... PGDUMP`:
-
-+ [Max row size](#max-row-size)
-+ [Skip foreign keys](#skip-foreign-keys)
-
-### Max row size
-
-The `max_row_size` option is used to override limits on line size.  **Default: 0.5MB**.  This setting may need to be tweaked if your Postgres dump file has extremely long lines, for example as part of a `COPY` statement.
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INT PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  )
-  PGDUMP DATA ('s3://your-external-storage/employees.sql?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456') WITH max_row_size = '5MB';
-~~~
-
-### Skip foreign keys
-
-By default, [`IMPORT ... PGDUMP`][import] supports foreign keys.  **Default: false**.  Add the `skip_foreign_keys` option to speed up data import by ignoring foreign key constraints in the dump file's DDL.  It will also enable you to import individual tables that would otherwise fail due to dependencies on other tables.
-
-{{site.data.alerts.callout_info}}
-The most common dependency issues are caused by unsatisfied foreign key relationships. You can avoid these issues by adding the `skip_foreign_keys` option to your `IMPORT` statement as needed. For more information, see the list of [import options](import.html#import-options).
-
-For example, if you get the error message `pq: there is no unique constraint matching given keys for referenced table tablename`, use `IMPORT ... WITH skip_foreign_keys`.
-{{site.data.alerts.end}}
-
-Example usage:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE employees (
-    emp_no INTEGER PRIMARY KEY,
-    birth_date DATE NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    gender STRING NOT NULL,
-    hire_date DATE NOT NULL
-  ) PGDUMP DATA ('s3://your-external-storage/employees.sql?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456') WITH skip_foreign_keys;
-~~~
-
-[Foreign key constraints](foreign-key.html) can be added by using [`ALTER TABLE ... ADD CONSTRAINT`](add-constraint.html) commands after importing the data.
-
-## See also
-
-- [`IMPORT`][import]
-- [Import Performance Best Practices](import-performance-best-practices.html)
-- [Migrate from CSV][csv]
-- [Migrate from MySQL][mysql]
-- [Can a Postgres or MySQL application be migrated to CockroachDB?](frequently-asked-questions.html#can-a-postgresql-or-mysql-application-be-migrated-to-cockroachdb)
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back up Data](take-full-and-incremental-backups.html)
-- [Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference Links -->
-
-[csv]: migrate-from-csv.html
-[mysql]: migrate-from-mysql.html
-[import]: import.html
-[pgdump]: https://www.postgresql.org/docs/current/static/app-pgdump.html
-[postgres]: migrate-from-postgres.html
-[pgschema]: https://www.postgresql.org/docs/current/static/ddl-schemas.html
-[pgloader]: https://pgloader.io/
-
-<!-- Notes
-
-These instructions were prepared with the following versions:
-
-- Postgres 10.5
-
-- CockroachDB CCL v2.2.0-alpha.00000000-757-gb33c49ff73
-  (x86_64-apple-darwin16.7.0, built 2018/09/12 19:30:43, go1.10.3)
-  (built from master on Wednesday, September 12, 2018)
-
-- /usr/local/bin/mysql Ver 14.14 Distrib 5.7.22, for osx10.12 (x86_64)
-  using EditLine wrapper
-
--->
diff --git a/src/current/v20.2/migrate-from-shapefiles.md b/src/current/v20.2/migrate-from-shapefiles.md
deleted file mode 100644
index 1ec950949c5..00000000000
--- a/src/current/v20.2/migrate-from-shapefiles.md
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: Migrate from Shapefiles
-summary: Learn how to migrate data from ESRI Shapefiles into a CockroachDB cluster.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: CockroachDB supports efficiently storing and querying [spatial data](spatial-data.html).
-
-This page has instructions for migrating data from ESRI [Shapefiles](spatial-glossary.html#shapefile) into CockroachDB using [`shp2pgsql`](https://manpages.debian.org/stretch/postgis/shp2pgsql.1.en.html) and [`IMPORT`][import].
-
-{{site.data.alerts.callout_success}}
-We are using `shp2pgsql` in the example below, but [`ogr2ogr`](https://gdal.org/programs/ogr2ogr.html) could also be used, e.g.
-`ogr2ogr -f PGDUMP file.sql -lco LAUNDER=NO -lco DROP_TABLE=OFF file.shp`
-{{site.data.alerts.end}}
-
-{% include {{page.version.version}}/spatial/ogr2ogr-supported-version.md %}
-
-In the example below we will import a [tornadoes data set](http://web.archive.org/web/20201018170120/https://www.spc.noaa.gov/gis/svrgis/zipped/1950-2018-torn-initpoint.zip) that is [available from the US National Weather Service](https://www.spc.noaa.gov/gis/svrgis/) (NWS).
-
-{{site.data.alerts.callout_info}}
-Please refer to the documentation of your GIS software for instructions on exporting GIS data to Shapefiles.
-{{site.data.alerts.end}}
-
-## Before You Begin
-
-To follow along with the example below, you will need the following prerequisites:
-
-- CockroachDB [installed](install-cockroachdb.html) and [running](start-a-local-cluster.html)
-- [`shp2pgsql`](https://manpages.debian.org/stretch/postgis/shp2pgsql.1.en.html)
-- [Python 3](https://www.python.org)
-
-## Step 1. Download the Shapefile data
-
-First, download and unzip the tornado data:
-
-{% include copy-clipboard.html %}
-~~~ shell
-wget http://web.archive.org/web/20201018170120/https://www.spc.noaa.gov/gis/svrgis/zipped/1950-2018-torn-initpoint.zip
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-unzip 1950-2018-torn-initpoint.zip
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-cd 1950-2018-torn-initpoint/
-~~~
-
-## Step 2. Convert the Shapefile data to SQL
-
-To load the tornado Shapefile into CockroachDB, we must first convert it to SQL using the `shp2pgsql` tool:
-
-{% include copy-clipboard.html %}
-~~~ shell
-shp2pgsql 1950-2018-torn-initpoint.shp > tornado-points.sql &
-~~~
-
-## Step 3. Host the files where the cluster can access them
-
-Each node in the CockroachDB cluster needs to have access to the files being imported. There are several ways for the cluster to access the data; for a complete list of the types of storage [`IMPORT`][import] can pull from, see [import file locations](import.html#import-file-location).
-
-For local testing, you can [start a local file server](use-a-local-file-server-for-bulk-operations.html). The following command will start a local file server listening on port 3000:
-
-{% include copy-clipboard.html %}
-~~~ shell
-python3 -m http.server 3000
-~~~
-
-## Step 4. Prepare the database
-
-Next, create a `tornadoes` database to store the data in, and switch to it:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach sql --insecure
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE DATABASE IF NOT EXISTS tornadoes;
-USE tornadoes;
-~~~
-
-## Step 5. Import the SQL
-
-Since the file is being served from a local server and is formatted as Postgres-compatible SQL, we can import the data using the following [`IMPORT PGDUMP`](import.html#import-a-postgres-database-dump) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-IMPORT PGDUMP ('http://localhost:3000/tornado-points.sql');
-~~~
-
-~~~
-        job_id       |  status   | fraction_completed | rows  | index_entries |  bytes
----------------------+-----------+--------------------+-------+---------------+-----------
-  584874782851497985 | succeeded |                  1 | 63645 |             0 | 18287213
-(1 row)
-~~~
-
-## See also
-
-- [`IMPORT`][import]
-- [Export Spatial Data](export-spatial-data.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
-- [Migration Overview](migration-overview.html)
-- [Migrate from MySQL][mysql]
-- [Migrate from Postgres][postgres]
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back Up and Restore Data](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference Links -->
-
-[postgres]: migrate-from-postgres.html
-[mysql]: migrate-from-mysql.html
-[import]: import.html
diff --git a/src/current/v20.2/migration-overview.md b/src/current/v20.2/migration-overview.md
deleted file mode 100644
index bcce5d8a0fe..00000000000
--- a/src/current/v20.2/migration-overview.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: Migration Overview
-summary: Learn how to migrate data into a CockroachDB cluster.
-toc: true
----
-
-CockroachDB supports [importing](import.html) data from the following databases:
-
-- MySQL
-- Oracle (using CSV)
-- Postgres (and <span class="version-tag">New in v20.2</span>: PostGIS)
-
-and from the following data formats:
-
-- CSV/TSV
-- Avro
-- <span class="version-tag">New in v20.2</span>: ESRI Shapefiles (`.shp`) (using `shp2pgsql`)
-- <span class="version-tag">New in v20.2</span>: OpenStreetMap data files (`.pbf`) (using `osm2pgsql`)
-- <span class="version-tag">New in v20.2</span>: GeoPackage data files (`.gpkg`) (using `ogr2ogr`)
-- <span class="version-tag">New in v20.2</span>: GeoJSON data files (`.geojson`) (using `ogr2ogr`)
-
-This page lists general considerations to be aware of as you plan your migration to CockroachDB.
-
-In addition to the information listed below, see the following pages for specific instructions and considerations that apply to the database (or data format) you're migrating from:
-
-- [Migrate from Oracle][oracle]
-- [Migrate from Postgres][postgres]
-- [Migrate from MySQL][mysql]
-- [Migrate from CSV][csv]
-- [Migrate from Avro][avro]
-- [Migrate from Shapefiles][shp]
-- [Migrate from OpenStreetMap][pbf]
-- [Migrate from GeoPackage][gpkg]
-- [Migrate from GeoJSON][geojson]
-
-{% include {{ page.version.version }}/misc/import-perf.md %}
-
-## File storage during import
-
-During migration, all of the features of [`IMPORT`][import] that interact with external file storage assume that every node has the exact same view of that storage.  In other words, in order to import from a file, every node needs to have the same access to that file.
-
-## Schema and application changes
-
-In general, you are likely to have to make changes to your schema, and how your app interacts with the database.  We **strongly recommend testing your application against CockroachDB** to ensure that:
-
-1. The state of your data is what you expect post-migration.
-2. Performance is as expected for your application's workloads.  You may need to apply some [best practices for optimizing SQL performance in CockroachDB](performance-best-practices-overview.html).
-
-## Data type sizes
-
-Above a certain size, many data types such as [`STRING`](string.html)s, [`DECIMAL`](decimal.html)s, [`ARRAY`](array.html), [`BYTES`](bytes.html), and [`JSONB`](jsonb.html) may run into performance issues due to [write amplification](https://en.wikipedia.org/wiki/Write_amplification).  See each data type's documentation for its recommended size limits.
-
-## See also
-
-- [`IMPORT`][import]
-- [Import Performance Best Practices](import-performance-best-practices.html)
-- [Migrate from Oracle][oracle]
-- [Migrate from CSV][csv]
-- [Migrate from MySQL][mysql]
-- [Migrate from Postgres][postgres]
-- [Migrate from Avro][avro]
-- [Can a Postgres or MySQL application be migrated to CockroachDB?](frequently-asked-questions.html#can-a-postgresql-or-mysql-application-be-migrated-to-cockroachdb)
-- [PostgreSQL Compatibility](postgresql-compatibility.html)
-- [SQL Dump (Export)](cockroach-dump.html)
-- [Back Up and Restore](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Links -->
-
-[oracle]: migrate-from-oracle.html
-[postgres]: migrate-from-postgres.html
-[mysql]: migrate-from-mysql.html
-[csv]: migrate-from-csv.html
-[import]: import.html
-[avro]: migrate-from-avro.html
-[shp]: migrate-from-shapefiles.html
-[pbf]: migrate-from-openstreetmap.html
-[gpkg]: migrate-from-geopackage.html
-[geojson]: migrate-from-geojson.html
diff --git a/src/current/v20.2/monitor-cockroachdb-with-prometheus.md b/src/current/v20.2/monitor-cockroachdb-with-prometheus.md
deleted file mode 100644
index 8f5121e72a3..00000000000
--- a/src/current/v20.2/monitor-cockroachdb-with-prometheus.md
+++ /dev/null
@@ -1,188 +0,0 @@
----
-title: Monitor CockroachDB with Prometheus
-summary: How to pull CockroachDB's time series metrics into Prometheus.
-toc: true
----
-
-CockroachDB generates detailed time series metrics for each node in a cluster. This page shows you how to pull these metrics into [Prometheus](https://prometheus.io/), an open source tool for storing, aggregating, and querying time series data. It also shows you how to connect [Grafana](https://grafana.com/) and [Alertmanager](https://prometheus.io/docs/alerting/alertmanager/) to Prometheus for flexible data visualizations and notifications.
-
-{{site.data.alerts.callout_success}}For details about other monitoring options, see <a href="monitoring-and-alerting.html">Monitoring and Alerting</a>. {{site.data.alerts.end}}
-
-
-## Before you begin
-
-- Make sure you have already started a CockroachDB cluster, either [locally](start-a-local-cluster.html) or in a [production environment](manual-deployment.html).
-
-- Note that all files used in this tutorial can be found in the [`monitoring`](https://github.com/cockroachdb/cockroach/tree/master/monitoring) directory of the CockroachDB repository.
-
-## Step 1. Install Prometheus
-
-1. Download the [2.x Prometheus tarball](https://prometheus.io/download/) for your OS.
-
-2. Extract the binary and add it to your `PATH`. This makes it easy to start Prometheus from any shell.
-
-3. Make sure Prometheus installed successfully:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ prometheus --version
-    ~~~
-
-    ~~~
-    prometheus, version 2.2.1 (branch: HEAD, revision: bc6058c81272a8d938c05e75607371284236aadc)
-      build user:       root@149e5b3f0829
-      build date:       20180314-14:21:40
-      go version:       go1.10
-    ~~~
-
-## Step 2. Configure Prometheus
-
-1. Download the starter [Prometheus configuration file](https://github.com/cockroachdb/cockroach/blob/master/monitoring/prometheus.yml) for CockroachDB:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget https://raw.githubusercontent.com/cockroachdb/cockroach/master/monitoring/prometheus.yml \
-    -O prometheus.yml
-    ~~~
-
-    When you examine the configuration file, you'll see that it is set up to scrape the time series metrics of a single, insecure local node every 10 seconds:
-    - `scrape_interval: 10s` defines the scrape interval.
-    - `metrics_path: '/_status/vars'` defines the Prometheus-specific CockroachDB endpoint for scraping time series metrics.
-    - `scheme: 'http'` specifies that the cluster being scraped is insecure.
-    - `targets: ['localhost:8080']` specifies the hostname and `http-port` of the Cockroach node to collect time series metrics on.
-
-2. Edit the configuration file to match your deployment scenario:
-
-    Scenario | Config Change
-    ---------|--------------
-    Multi-node local cluster | Expand the `targets` field to include `'localhost:<http-port>'` for each additional node.
-    Production cluster | Change the `targets` field to include `'<hostname>:<http-port>'` for each node in the cluster. Also, be sure your network configuration allows TCP communication on the specified ports.
-    Secure cluster | Uncomment `scheme: 'https'` and comment out `scheme: 'http'`.
-
-4. Create a `rules` directory and download the [aggregation rules](https://github.com/cockroachdb/cockroach/blob/master/monitoring/rules/aggregation.rules.yml) and [alerting rules](https://github.com/cockroachdb/cockroach/blob/master/monitoring/rules/alerts.rules.yml) for CockroachDB into it:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir rules
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cd rules
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget -P rules https://raw.githubusercontent.com/cockroachdb/cockroach/master/monitoring/rules/aggregation.rules.yml
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget -P rules https://raw.githubusercontent.com/cockroachdb/cockroach/master/monitoring/rules/alerts.rules.yml
-    ~~~
-
-## Step 3. Start Prometheus
-
-1. Start the Prometheus server, with the `--config.file` flag pointing to the configuration file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ prometheus --config.file=prometheus.yml
-    ~~~
-
-    ~~~
-    INFO[0000] Starting prometheus (version=1.4.1, branch=master, revision=2a89e8733f240d3cd57a6520b52c36ac4744ce12)  source=main.go:77
-    INFO[0000] Build context (go=go1.7.3, user=root@e685d23d8809, date=20161128-10:02:41)  source=main.go:78
-    INFO[0000] Loading configuration file prometheus.yml     source=main.go:250
-    INFO[0000] Loading series map and head chunks...         source=storage.go:354
-    INFO[0000] 0 series loaded.                              source=storage.go:359
-    INFO[0000] Listening on :9090                            source=web.go:248
-    INFO[0000] Starting target manager...                    source=targetmanager.go:63
-    ~~~
-
-2. Point your browser to `http://<hostname of machine running prometheus>:9090`, where you can use the Prometheus UI to query, aggregate, and graph CockroachDB time series metrics.
-  - Prometheus auto-completes CockroachDB time series metrics for you, but if you want to see a full listing, with descriptions, point your browser to `http://<hostname of a CockroachDB node>:8080/_status/vars`.
-  - For more details on using the Prometheus UI, see their [official documentation](https://prometheus.io/docs/introduction/getting_started/).
-
-## Step 4. Send notifications with Alertmanager
-
-Active monitoring helps you spot problems early, but it is also essential to send notifications when there are events that require investigation or intervention. In step 2, you already downloaded CockroachDB's starter [alerting rules](https://github.com/cockroachdb/cockroach/blob/master/monitoring/rules/alerts.rules.yml). Now, download, configure, and start [Alertmanager](https://prometheus.io/docs/alerting/alertmanager/).
-
-1. Download the [latest Alertmanager tarball](https://prometheus.io/download/#alertmanager) for your OS.
-
-2. Extract the binary and add it to your `PATH`. This makes it easy to start Alertmanager from any shell.
-
-3. Make sure Alertmanager installed successfully:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ alertmanager --version
-    ~~~
-
-    ~~~
-    alertmanager, version 0.15.0-rc.1 (branch: HEAD, revision: acb111e812530bec1ac6d908bc14725793e07cf3)
-      build user:       root@f278953f13ef
-      build date:       20180323-13:07:06
-      go version:       go1.10
-    ~~~
-
-4. [Edit the Alertmanager configuration file](https://prometheus.io/docs/alerting/configuration/) that came with the binary, `simple.yml`, to specify the desired receivers for notifications.
-
-5. Start the Alertmanager server, with the `--config.file` flag pointing to the configuration file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ alertmanager --config.file=simple.yml
-    ~~~
-
-6. Point your browser to `http://<hostname of machine running alertmanager>:9093`, where you can use the Alertmanager UI to define rules for [silencing alerts](https://prometheus.io/docs/alerting/alertmanager/#silences).
-
-## Step 5. Visualize metrics in Grafana
-
-Although Prometheus lets you graph metrics, [Grafana](https://grafana.com/) is a much more powerful visualization tool that integrates with Prometheus easily.
-
-1. [Install and start Grafana for your OS](https://grafana.com/grafana/download).
-
-2. Point your browser to `http://<hostname of machine running grafana>:3000` and log into the Grafana UI with the default username/password, `admin/admin`, or create your own account.
-
-3. [Add Prometheus as a datasource](http://docs.grafana.org/datasources/prometheus/), and configure the datasource as follows:
-
-    Field | Definition
-    ------|-----------
-    Name | Prometheus
-    Default | True
-    Type | Prometheus
-    Url | `http://<hostname of machine running prometheus>:9090`
-    Access | Direct
-
-4. Download the starter [Grafana dashboards](https://github.com/cockroachdb/cockroach/tree/master/monitoring/grafana-dashboards) for CockroachDB:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget https://raw.githubusercontent.com/cockroachdb/cockroach/master/monitoring/grafana-dashboards/runtime.json
-    # runtime dashboard: node status, including uptime, memory, and cpu.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget https://raw.githubusercontent.com/cockroachdb/cockroach/master/monitoring/grafana-dashboards/storage.json
-    # storage dashboard: storage availability.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget https://raw.githubusercontent.com/cockroachdb/cockroach/master/monitoring/grafana-dashboards/sql.json
-    # sql dashboard: sql queries/transactions.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget https://raw.githubusercontent.com/cockroachdb/cockroach/master/monitoring/grafana-dashboards/replication.json
-    # replicas dashboard: replica information and operations.
-    ~~~
-
-5. [Add the dashboards to Grafana](http://docs.grafana.org/reference/export_import/#importing-a-dashboard).
-
-## See also
-
-- [Monitoring and Alerting](monitoring-and-alerting.html)
diff --git a/src/current/v20.2/monitoring-and-alerting.md b/src/current/v20.2/monitoring-and-alerting.md
deleted file mode 100644
index 789c11ea4a6..00000000000
--- a/src/current/v20.2/monitoring-and-alerting.md
+++ /dev/null
@@ -1,181 +0,0 @@
----
-title: Monitoring and Alerting
-summary: Monitor the health and performance of a cluster and alert on critical events and metrics.
-toc: true
----
-
-Despite CockroachDB's various [built-in safeguards against failure](frequently-asked-questions.html#how-does-cockroachdb-survive-failures), it is critical to actively monitor the overall health and performance of a cluster running in production and to create alerting rules that promptly send notifications when there are events that require investigation or intervention.
-
-This page explains available monitoring tools and critical events and metrics to alert on.
-
-## Monitoring tools
-
-### DB Console
-
-The [DB Console](ui-overview.html) displays essential metrics about a cluster's health, such as node status, number of unavailable ranges, and queries per second and service latency across the cluster. This tool is designed to help you optimize cluster performance and troubleshoot issues.
-
-The DB Console is accessible from every node at `http://<host>:<http-port>`, or `http://<host>:8080` by default. For more information on accessing the DB Console, see [DB Console access](ui-overview.html#db-console-access).
-
-{{site.data.alerts.callout_danger}}
-Because the DB Console is built into CockroachDB, if a cluster becomes unavailable, most of the DB Console becomes unavailable as well. Therefore, it's essential to plan additional methods of monitoring cluster health as described below.
-{{site.data.alerts.end}}
-
-### Prometheus endpoint
-
-Every node of a CockroachDB cluster exports granular timeseries metrics at `http://<host>:<http-port>/_status/vars`. The metrics are formatted for easy integration with [Prometheus](https://prometheus.io/), an open source tool for storing, aggregating, and querying timeseries data, but the format is **easy-to-parse** and can be massaged to work with other third-party monitoring systems (e.g., [Sysdig](https://sysdig.atlassian.net/wiki/plugins/servlet/mobile?contentId=64946336#content/view/64946336) and [Stackdriver](https://github.com/GoogleCloudPlatform/k8s-stackdriver/tree/master/prometheus-to-sd)).
-
-For a tutorial on using Prometheus, see [Monitor CockroachDB with Prometheus](monitor-cockroachdb-with-prometheus.html).
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ curl http://localhost:8080/_status/vars
-~~~
-
-~~~
-# HELP gossip_infos_received Number of received gossip Info objects
-# TYPE gossip_infos_received counter
-gossip_infos_received 0
-# HELP sys_cgocalls Total number of cgo calls
-# TYPE sys_cgocalls gauge
-sys_cgocalls 3501
-# HELP sys_cpu_sys_percent Current system cpu percentage
-# TYPE sys_cpu_sys_percent gauge
-sys_cpu_sys_percent 1.098855319644276e-10
-# HELP replicas_quiescent Number of quiesced replicas
-# TYPE replicas_quiescent gauge
-replicas_quiescent{store="1"} 20
-...
-~~~
-
-{{site.data.alerts.callout_info}}In addition to using the exported timeseries data to monitor a cluster via an external system, you can write alerting rules against them to make sure you are promptly notified of critical events or issues that may require intervention or investigation. See <a href="#events-to-alert-on">Events to Alert On</a> for more details.{{site.data.alerts.end}}
-
-### Health endpoints
-
-CockroachDB provides two HTTP endpoints for checking the health of individual nodes.
-
-#### /health
-
-If a node is down, the `http://<host>:<http-port>/health` endpoint returns a `Connection refused` error:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ curl http://localhost:8080/health
-~~~
-
-~~~
-curl: (7) Failed to connect to localhost port 8080: Connection refused
-~~~
-
-Otherwise, it returns an HTTP `200 OK` status response code with an empty body:
-
-~~~
-{
-
-}
-~~~
-
-The `/health` endpoint no longer returns details about the node such as its private IP address. These details could be considered privileged information in some deployments. If you need to retrieve node details, you can use the `/_status/details` endpoint along with a valid authentication cookie.
-
-#### /health?ready=1
-
-The `http://<node-host>:<http-port>/health?ready=1` endpoint returns an HTTP `503 Service Unavailable` status response code with an error in the following scenarios:
-
-- The node is draining open SQL connections and rejecting new SQL connections because it is in the process of shutting down (e.g., after being [decommissioned](remove-nodes.html#how-it-works)). This is especially useful for making sure load balancers do not direct traffic to nodes that are live but not "ready", which is a necessary check during [rolling upgrades](upgrade-cockroach-version.html).
-
-    {{site.data.alerts.callout_success}}
-    If you find that your load balancer's health check is not always recognizing a node as unready before the node shuts down, you can increase the `server.shutdown.drain_wait` [cluster setting](cluster-settings.html) to cause a node to return `503 Service Unavailable` even before it has started shutting down.
-    {{site.data.alerts.end}}
-
-    Prior to v20.1, [decommissioning](remove-nodes.html#how-it-works) nodes would erroneously be considered unready and return `503 Service Unavailable`. This is no longer the case. Although decommissioned nodes no longer store replicas, they can still function as gateways to route SQL connections to relevant data until they are shut down. 
-
-- The node is unable to communicate with a majority of the other nodes in the cluster, likely because the cluster is unavailable due to too many nodes being down.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ curl http://localhost:8080/health?ready=1
-~~~
-
-~~~
-{
-  "error": "node is not ready",
-  "code": 14
-}
-~~~
-
-Otherwise, it returns an HTTP `200 OK` status response code with an empty body:
-
-~~~
-{
-
-}
-~~~
-
-### Raw status endpoints
-
-Several endpoints return raw status metrics in JSON at `http://<host>:<http-port>/#/debug`. Feel free to investigate and use these endpoints, but note that they are subject to change.  
-
-<img src="{{ 'images/v20.2/raw-status-endpoints.png' | relative_url }}" alt="Raw Status Endpoints" style="border:1px solid #eee;max-width:100%" />
-
-### Node status command
-
-The [`cockroach node status`](cockroach-node.html) command gives you metrics about the health and status of each node.
-
-- With the `--ranges` flag, you get granular range and replica details, including unavailability and under-replication.
-- With the `--stats` flag, you get granular disk usage details.
-- With the `--decommission` flag, you get details about the [node decommissioning](remove-nodes.html) process.
-- With the `--all` flag, you get all of the above.
-
-## Events to alert on
-
-Active monitoring helps you spot problems early, but it is also essential to create alerting rules that promptly send notifications when there are events that require investigation or intervention. This section identifies the most important events to create alerting rules for, with the [Prometheus Endpoint](#prometheus-endpoint) metrics to use for detecting the events.
-
-{{site.data.alerts.callout_success}}If you use Prometheus for monitoring, you can also use our pre-defined <a href="https://github.com/cockroachdb/cockroach/blob/master/monitoring/rules/alerts.rules.yml">alerting rules</a> with Alertmanager. See <a href="monitor-cockroachdb-with-prometheus.html">Monitor CockroachDB with Prometheus</a> for guidance.{{site.data.alerts.end}}
-
-### Node is down
-
-- **Rule:** Send an alert when a node has been down for 5 minutes or more.
-
-- **How to detect:** If a node is down, its `_status/vars` endpoint will return a `Connection refused` error. Otherwise, the `liveness_livenodes` metric will be the total number of live nodes in the cluster.
-
-### Node is restarting too frequently
-
-- **Rule:** Send an alert if a node has restarted more than 5 times in 10 minutes.
-
-- **How to detect:** Calculate this using the number of times the `sys_uptime` metric in the node's `_status/vars` output was reset back to zero. The `sys_uptime` metric gives you the length of time, in seconds, that the `cockroach` process has been running.
-
-### Node is running low on disk space
-
-- **Rule:** Send an alert when a node has less than 15% of free space remaining.
-
-- **How to detect:** Divide the `capacity` metric by the `capacity_available` metric in the node's `_status/vars` output.
-
-### Node is not executing SQL
-
-- **Rule:** Send an alert when a node is not executing SQL despite having connections.
-
-- **How to detect:** The `sql_conns` metric in the node's `_status/vars` output will be greater than `0` while the `sql_query_count` metric will be `0`. You can also break this down by statement type using `sql_select_count`, `sql_insert_count`, `sql_update_count`, and `sql_delete_count`.
-
-### CA certificate expires soon
-
-- **Rule:** Send an alert when the CA certificate on a node will expire in less than a year.
-
-- **How to detect:** Calculate this using the `security_certificate_expiration_ca` metric in the node's `_status/vars` output.
-
-### Node certificate expires soon
-
-- **Rule:** Send an alert when a node's certificate will expire in less than a year.
-
-- **How to detect:** Calculate this using the `security_certificate_expiration_node` metric in the node's `_status/vars` output.
-
-### Changefeed is experiencing high latency
-
-- **Rule:** Send an alert when the latency of any changefeed running on any node is higher than the set threshold, which depends on the [`gc.ttlseconds`](configure-replication-zones.html#replication-zone-variables) variable set in the cluster.
-
-- **How to detect:** Calculate this using a threshold, where the threshold is less than the value of the [`gc.ttlseconds`](configure-replication-zones.html#replication-zone-variables) variable. For example, `changefeed.max_behind_nanos > [some threshold]`.
-
-## See also
-
-- [Production Checklist](recommended-production-settings.html)
-- [Manual Deployment](manual-deployment.html)
-- [Orchestrated Deployment](orchestration.html)
-- [Local Deployment](start-a-local-cluster.html)
diff --git a/src/current/v20.2/movr.md b/src/current/v20.2/movr.md
deleted file mode 100644
index 4ed1f0c970f..00000000000
--- a/src/current/v20.2/movr.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: MovR
-summary: The MovR application uses CockroachDB to store information about vehicles, users, and rides.
-toc: true
----
-
-MovR is a fictional vehicle-sharing company created to demonstrate CockroachDB's features.
-
-## Overview
-
-The MovR example consists of the following:
-
-- The `movr` dataset, which contains rows of data that populate tables in the `movr` database. The `movr` dataset is built into [`cockroach demo`](cockroach-demo.html) and [`cockroach workload`](cockroach-workload.html).
-- The MovR application, a fully-functional vehicle-sharing application, written in Python. All of MovR application source code is open-source, and available on the [movr](https://github.com/cockroachdb/movr) GitHub repository.
-
-## The `movr` database
-
-{% include {{ page.version.version }}/misc/movr-schema.md %}
-
-## Generating schemas and data for MovR
-
-You can use the `cockroach demo` and `cockroach workload` commands to load the `movr` database and dataset into a CockroachDB cluster.
-
-[`cockroach demo`](cockroach-demo.html) opens a SQL shell to a temporary, in-memory cluster. To open a SQL shell to a demo cluster with the `movr` database preloaded and set as the [current database](sql-name-resolution.html#current-database), use the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo movr
-~~~
-
-[`cockroach workload`](cockroach-workload.html) loads sample datasets and workloads into running clusters. To load the `movr` database and some sample data into a running cluster, do the following:
-
-1. Start a [secure](secure-a-cluster.html) or [insecure](start-a-local-cluster.html) local cluster.
-1. Use `cockroach workload` to load the `movr` dataset:
-
-    <div class="filters filters-big clearfix">
-      <button class="filter-button" data-scope="secure">Secure</button>
-      <button class="filter-button" data-scope="insecure">Insecure</button>
-    </div>
-
-    <section class="filter-content" markdown="1" data-scope="secure">
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init movr 'postgresql://root@localhost:26257?sslcert=certs%2Fclient.root.crt&sslkey=certs%2Fclient.root.key&sslmode=verify-full&sslrootcert=certs%2Fca.crt'
-    ~~~
-
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="insecure">
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init movr 'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    </section>
-
-1. Use [`cockroach sql`](cockroach-sql.html) to open an interactive SQL shell and set `movr` as the  [current database](sql-name-resolution.html#current-database):
-
-    <section class="filter-content" markdown="1" data-scope="secure">
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs --host=localhost:26257
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > USE movr;
-    ~~~
-
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="insecure">
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=localhost:26257
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > USE movr;
-    ~~~        
-
-    </section>
-
-## How the MovR application works
-
-{% include {{ page.version.version }}/misc/movr-workflow.md %}
-
-## Extended examples
-
-For a tutorial on running MovR against a multi-region cluster, using two important multi-region [data topologies](topology-patterns.html) to get very low latency reads and writes, see [Low Latency, Multi-Region Deployment](demo-low-latency-multi-region-deployment.html).
-
-For a tutorial about performance tuning in CockroachDB, see [Performance Tuning](performance-tuning.html).
-
-For a tutorial on developing and deploying a multi-region web application for MovR, see [Develop and Deploy a Multi-Region Web Application](multi-region-overview.html).
-
-## See also
-
-- [Learn CockroachDB SQL](learn-cockroachdb-sql.html)
-- [Build an App with CockroachDB](example-apps.html)
-- [Experimental Features](experimental-features.html)
diff --git a/src/current/v20.2/multi-active-availability.md b/src/current/v20.2/multi-active-availability.md
deleted file mode 100644
index cd605875376..00000000000
--- a/src/current/v20.2/multi-active-availability.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Multi-Active Availability
-summary: Learn about CockroachDB's high availability model, known as Multi-Active Availability.
-toc: true
----
-
-CockroachDB's availability model is described as "Multi-Active Availability." In essence, multi-active availability provides benefits similar to traditional notions of high availability, but also lets you read and write from every node in your cluster without generating any conflicts.
-
-
-## What is high availability?
-
-High availability lets an application continue running even if a system hosting one of its services fails. This is achieved by scaling the application's services horizontally, i.e., replicating the service across many machines or systems. If any one of them fails, the others can simply step in and perform the same service.
-
-Before diving into the details of CockroachDB's multi-active availability, we'll review the two most common high availability designs: [Active-Passive](#active-passive) and [Active-Active](#active-active) systems.
-
-### Active-Passive
-
-In active-passive systems, all traffic is routed to a single, "active" replica. Changes to the replica's state are then copied to a backup "passive" replica, in an attempt to always mirror the active replica as closely as possible.
-
-However, this design has downsides:
-
-- If you use asynchronous replication, you cannot guarantee that any data is ever successfully replicated to passive followers––meaning you can easily lose data. Depending on your industry, this could have pretty dire consequences.
-- If you use synchronous replication and any passive replicas fail, you have to either sacrifice availability for the entire application or risk inconsistencies.
-
-### Active-Active
-
-In active-active systems, multiple replicas run identical services, and traffic is routed to all of them. If any replica fails, the others simply handle the traffic that would've been routed to it.
-
-For databases, though, active-active replication is incredibly difficult to instrument for most workloads. For example, if you let multiple replicas handle writes for the same keys, how do you keep them consistent?
-
-#### Example: conflicts with active-active replication
-
-For this example, we have 2 replicas (**A**, **B**) in an active-active high availability cluster.
-
-1. **A** receives a write for key `xyz` of `'123'`, and then immediately fails.
-2. **B** receives a read of key `xyz`, and returns a `NULL` because it cannot find the key.
-3. **B** then receives a write for key `xyz` of `'456'`.
-4. **A** is restarted and attempts to rejoin **B**––but what do you do about key `xyz`? There's an inconsistency in the system without a clear way to resolve it.
-
-{{site.data.alerts.callout_info}}In this example, the cluster remained active the entire time. But in terms of the <a href="https://en.wikipedia.org/wiki/CAP_theorem">CAP theorem</a>, this is an AP system; it favored being available instead of consistent when partitions occur.{{site.data.alerts.end}}
-
-## What is multi-active availability?
-
-Multi-active availability is CockroachDB's version of high availability (keeping your application online in the face of partial failures), which we've designed to avoid the downsides of both active-passive and traditional active-active systems.
-
-Like active-active designs, all replicas can handle traffic, including both reads and writes. However, CockroachDB improves upon that design by also ensuring that data remains consistent across them, which we achieve by using "consensus replication." In this design, replication requests are sent to at least 3 replicas, and are only considered committed when a majority of replicas acknowledge that they've received it. This means that you can still have failures without compromising availability.
-
-To prevent conflicts and guarantee your data's consistency, clusters that lose a majority of replicas stop responding because they've lost the ability to reach a consensus on the state of your data. When a majority of replicas are restarted, your database resumes operation.
-
-### Consistency example
-
-For this example, we have 3 CockroachDB nodes (**A**, **B**, **C**) in a multi-active availability cluster.
-
-1. **A** receives a write on `xyz` of `'123'`. It communicates this write to nodes **B** and **C**, who confirm that they've received the write, as well. Once **A** receives the first confirmation, the change is committed.
-2. **A** fails.
-3. **B** receives a read of key `xyz`, and returns the result `'123'`.
-4. **C** then receives an update for key `xyz` to the values `'456'`. It communicates this write to node **B**, who confirms that its received the write, as well. After receiving the confirmation, the change is committed.
-5. **A** is restarted and rejoins the cluster. It receives an update that the key `xyz` had its value changed to `'456'`.
-
-{{site.data.alerts.callout_info}}In this example, if nodes <strong>B</strong> or <strong>C</strong> failed at any time, the cluster would have stopped responding. In terms of the <a href="https://en.wikipedia.org/wiki/CAP_theorem">CAP theorem</a>, this is a CP system; it favored being consistent instead of available when partitions occur.{{site.data.alerts.end}}
-
-## What's next?
-
-To get a greater understanding of how CockroachDB is a survivable system that enforces strong consistency, check out our [architecture documentation](architecture/overview.html).
-
-To see Multi-Active Availability in action, see this [availability demo](demo-fault-tolerance-and-recovery.html).
diff --git a/src/current/v20.2/multi-region-application.md b/src/current/v20.2/multi-region-application.md
deleted file mode 100644
index 01fc6e3863f..00000000000
--- a/src/current/v20.2/multi-region-application.md
+++ /dev/null
@@ -1,404 +0,0 @@
----
-title: Develop a Multi-Region Web Application
-summary: This page includes instructions for building a multi-region web application on CockroachDB, using Flask and SQLAlchemy.
-toc: true
-canonical: /stable/movr-flask-application
----
-
-This page walks you through developing a multi-region application. It is the fourth section of the [Develop and Deploy a Multi-Region Web Application](multi-region-overview.html) tutorial.
-
-{% include {{ page.version.version }}/misc/movr-flask-211.md %}
-
-<!-- {% include {{ page.version.version }}/misc/movr-live-demo.md %} -->
-
-## Before you begin
-
-Before you begin this section, complete the previous section of the tutorial, [Set Up a Virtual Environment for Developing Multi-Region Applications](multi-region-setup.html).
-
-## Project structure
-
-Our application needs to handle requests from clients, namely web browsers. To translate these kinds of requests into database transactions, the application stack consists of the following components:
-
-- A geo-partitioned database schema that defines the tables and indexes for user, vehicle, and ride data.
-    The database schema is covered on a separate page, [Create a Multi-Region Database Schema](multi-region-database.html).
-- A multi-node, geo-distributed CockroachDB cluster, with each node's locality corresponding to cloud provider regions.
-    Database deployment is covered on separate pages. For instructions on setting up a demo cluster, see [Set Up a Virtual Environment for Developing Multi-Region Applications](multi-region-setup.html). For instructions on setting up a multi-region cluster, see [Deploy a Multi-Region Web Application](multi-region-deployment.html).
-- Python class definitions that map to the tables in our database.
-    For details, see [Mappings](multi-region-application.html#mappings) below.
-- Functions that wrap database transactions.
-    For details, see [Transactions](multi-region-application.html#transactions) below.
-- A backend API that defines the application's connection to the database.
-    For details, see [Database connection](multi-region-application.html#database-connection) below.
-- A [Flask](https://palletsprojects.com/p/flask/) server that handles requests from client mobile applications and web browsers.
-    For details, see [Web application](multi-region-application.html#web-application) below.
-- HTML files that the Flask server can render into web pages.
-    For details, see [User interface](multi-region-application.html#user-interface) below.
-
-In the sections that follow, we go over each of the files and folders in the project, with a focus on the backend and database components. Here is the application's project directory structure:
-
-~~~ shell
-movr
-├── Dockerfile  ## Defines the Docker container build
-├── LICENSE  ## A license file for your application
-├── Pipfile ## Lists PyPi dependencies for pipenv
-├── Pipfile.lock
-├── README.md  ## Contains instructions on running the application
-├── __init__.py
-├── dbinit.sql  ## Initializes the database, and partitions the tables by region
-├── mcingress.yaml ## Defines the multi-cluster ingress K8s object, for multi-region deployment
-├── movr
-│   ├── __init__.py
-│   ├── models.py  ## Defines classes that map to tables in the movr database
-│   ├── movr.py  ## Defines the primary backend API
-│   └── transactions.py ## Defines transaction callback functions
-├── movr.yaml  ## Defines service and deployment K8s objects for multi-region deployment
-├── requirements.txt  ## Lists PyPi dependencies for Docker container
-├── server.py  ## Defines a Flask web application to handle requests from clients and render HTML files
-├── static  ## Static resources for the web frontend
-│   ├── movr-lockup.png
-│   └── movr-symbol.png
-├── templates  ## HTML templates for the web UI
-│   ├── _nav.html
-│   ├── home.html
-│   ├── layout.html
-│   ├── login.html
-│   ├── register.html
-│   ├── rides.html
-│   ├── user.html
-│   ├── users.html
-│   ├── vehicles-add.html
-│   └── vehicles.html
-└── web
-    ├── __init__.py
-    ├── config.py   ## Contains Flask configuration settings
-    ├── forms.py  ## Defines FlaskForm classes
-    ├── geoutils.py  ## Defines utility functions for the web application
-    └── gunicorn.py  ## Contains gunicorn configuration settings
-~~~
-
-
-## SQLAlchemy with CockroachDB
-
-Object Relational Mappers (ORMs) map classes to tables, class instances to rows, and class methods to transactions on the rows of a table. The `sqlalchemy` package includes some base classes and methods that you can use to connect to your database's server from a Python application, and then map tables in that database to Python classes.
-
-In our example, we use SQLAlchemy's [Declarative](https://docs.sqlalchemy.org/en/13/orm/extensions/declarative/) extension, which is built on the `mapper()` and `Table` data structures. We also use the [`sqlalchemy-cockroachdb`](https://github.com/cockroachdb/sqlalchemy-cockroachdb) Python package, which defines the CockroachDB SQLAlchemy [dialect](https://docs.sqlalchemy.org/en/13/dialects/). The package includes some functions that help you handle [transactions](transactions.html) in a running CockroachDB cluster.
-
-### Mappings
-
-After completing the [Create a Multi-Region Database Schema](multi-region-database.html) section, you should be familiar with the `movr` database and each of the tables in the database (`users`, `vehicles`, and `rides`).
-
-Open [`movr/models.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/models.py), and look at the first 10 lines of the file:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/models.py ||# START front ||# END front %}
-~~~
-
-The first data structure that the file imports is `declarative_base`, a constructor for the [declarative base class](https://docs.sqlalchemy.org/en/13/orm/extensions/declarative/api.html#sqlalchemy.ext.declarative.declarative_base), built on SQLAlchemy's Declarative extension. All mapped objects inherit from this object. We assign a declarative base object to the `Base` variable right below the imports.
-
-The `models.py` file also imports some other standard SQLAlchemy data structures that represent database objects (like columns), data types, and constraints, in addition to a standard Python library to help with default values (i.e., `datetime`).
-
-Since the application handles user logins and authentication, we also need to import some security libraries from the Flask ecosystem. We'll cover the web development libraries in more detail in the [Web application](multi-region-application.html#web-application) section below.
-
-#### The `User` class
-
-Recall that each instance of a table class represents a row in the table, so we name our table classes as if they were individual rows of their parent table, since that's what they'll represent when we construct class objects.
-
-Take a look at the `User` class definition:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/models.py ||# START User ||# END User %}
-~~~
-
-The `User` class has the following attributes:
-
-- `__tablename__`, which holds the stored name of the table in the database. SQLAlchemy requires this attribute for all classes that map to tables.
-- All of the other attributes of the `User` class (`id`, `city`, `first_name`, etc.), stored as `Column` objects. These attributes represent columns of the `users` table. The constructor for each `Column` takes the column data type as its first argument, and then any additional arguments. To help define column objects, SQLAlchemy also includes classes for SQL data types and column constraints. For the columns in this table, we use `UUID` and `String` data types.
-- `PrimaryKeyConstraint()`, which defines a composite primary key with the `city` and `id` columns. Note that the partitioned column (`city`) precedes the `id` column, per [partition querying best practices](partitioning.html#filtering-on-an-indexed-column).
-- The `__repr__` function, which defines the string representation of the object.
-
-#### The `Vehicle` class
-
-Next, look at the `Vehicle` class definition:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/models.py ||# START Vehicle ||# END Vehicle %}
-~~~
-
-Recall that the `vehicles` table contains more columns and data types than the `users` table. It also contains a [foreign key constraint](foreign-key.html) (on the `users` table), and a default value. These differences are reflected in the `Vehicle` class.
-
-#### The `Ride` class
-
-Lastly, there's the `Ride` class:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/models.py ||# START Ride ||# END Ride %}
-~~~
-
-The `rides` table has four foreign key constraints, two on the `users` table and two on the `vehicles` table.
-
-### Transactions
-
-After you create a class for each table in the database, you can start defining functions that bundle together common SQL operations as atomic [transactions](transactions.html).
-
-#### The SQLAlchemy CockroachDB dialect
-
-The [`sqlalchemy-cockroachdb`](https://github.com/cockroachdb/sqlalchemy-cockroachdb/tree/master/cockroachdb) Python library handles transactions in SQLAlchemy with the `run_transaction()` function. This function takes a `transactor`, which can be an [`Engine`](https://docs.sqlalchemy.org/en/13/core/connections.html#sqlalchemy.engine.Engine), [`Connection`](https://docs.sqlalchemy.org/en/13/core/connections.html#sqlalchemy.engine.Connection), or [`sessionmaker`](https://docs.sqlalchemy.org/en/13/orm/session_api.html#sqlalchemy.orm.session.sessionmaker) object, and a callback function. It then uses the `transactor` to connect to the database, and executes the callback as a database transaction. For some examples of `run_transaction()` usage, see [Transaction callback functions](multi-region-application.html#transaction-callback-functions) below.
-
-`run_transaction()` abstracts the details of [transaction retries](transactions.html#client-side-intervention) away from your application code. Transactions may require retries if they experience deadlock or read/write contention with other concurrent transactions that cannot be resolved without allowing potential serializable anomalies. As a result, a CockroachDB transaction may have to be tried more than once before it can commit. This is part of how we ensure that our transaction ordering guarantees meet the ANSI [SERIALIZABLE](https://en.wikipedia.org/wiki/Isolation_(database_systems)#Serializable) isolation level.
-
-`run_transaction()` has the following additional benefits:
-
-- When passed a [`sqlalchemy.orm.session.sessionmaker`](https://docs.sqlalchemy.org/en/latest/orm/session_api.html#session-and-sessionmaker) object, it ensures that a new session is created exclusively for use by the callback, which protects you from accidentally reusing objects via any sessions created outside the transaction. Note that a `sessionmaker` objects is different from a `session` object, which is not an allowable `transactor` for `run_transaction()`.
-- By abstracting transaction retry logic away from your application, it keeps your application code portable across different databases.
-
- Because all callback functions are passed to `run_transaction()`, the `Session` method calls within those callback functions are written a little differently than the typical SQLAlchemy application. Most importantly, those functions must not change the session and/or transaction state. This is in line with the recommendations of the [SQLAlchemy FAQs](https://docs.sqlalchemy.org/en/latest/orm/session_basics.html#session-frequently-asked-questions), which state (with emphasis added by the original author) that
-
- > As a general rule, the application should manage the lifecycle of the session *externally* to functions that deal with specific data. This is a fundamental separation of concerns which keeps data-specific operations agnostic of the context in which they access and manipulate that data.
-
- and
-
- > Keep the lifecycle of the session (and usually the transaction) **separate and external**.
-
- In keeping with the above recommendations from the official docs, we strongly recommend avoiding any explicit mutations of the transaction state inside the callback passed to `run_transaction()`. Specifically, we do not make calls to the following functions from inside `run_transaction()`:
-
- - [`sqlalchemy.orm.Session.commit()`](https://docs.sqlalchemy.org/en/latest/orm/session_api.html?highlight=commit#sqlalchemy.orm.session.Session.commit) (or other variants of `commit()`): This is not necessary because `run_transaction()` handles the savepoint/commit logic for you.
- - [`sqlalchemy.orm.Session.rollback()`](https://docs.sqlalchemy.org/en/latest/orm/session_api.html?highlight=rollback#sqlalchemy.orm.session.Session.rollback) (or other variants of `rollback()`): This is not necessary because `run_transaction()` handles the commit/rollback logic for you.
- - `Session.flush()`: This will not work as expected with CockroachDB because [CockroachDB does not support nested transactions](savepoint.html), which are necessary for `Session.flush()` to work properly. If the call to `Session.flush()` encounters an error and aborts, it will try to rollback. This will not be allowed by the currently-executing CockroachDB transaction created by `run_transaction()`, and will result in an error message like the following: `sqlalchemy.orm.exc.DetachedInstanceError: Instance <FooModel at 0x12345678> is not bound to a Session; attribute refresh operation cannot proceed (Background on this error at: http://sqlalche.me/e/bhk3)`.
-
- In the example application provided, all calls to `run_transaction()` are found within the methods of the `MovR` class (defined in [`movr/movr.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/movr.py)), which represents the connection to the running database. Requests to the web application frontend (defined in [`server.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/server.py)), are routed to the `MovR` class methods.
-
-#### Transaction callback functions
-
- To separate concerns, we define all callback functions passed to `run_transaction()` calls in a separate file, [`movr/transactions.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/transactions.py). These callback functions wrap `Session` method calls, like [`session.query()`](https://docs.sqlalchemy.org/en/13/orm/session_api.html#sqlalchemy.orm.session.Session.query) and [`session.add()`](https://docs.sqlalchemy.org/en/13/orm/session_api.html#sqlalchemy.orm.session.Session.add), to perform database operations within a transaction.
-
-{{site.data.alerts.callout_success}}
-We recommend that you use a `sessionmaker` object, bound to an existing `Engine`, as the `transactor` that you pass to `run_transaction()`. This protects you from accidentally reusing objects via any sessions created outside the transaction. Every time `run_transaction()` is called, it uses the `sessionmaker` object to create a new [`Session`](https://docs.sqlalchemy.org/en/13/orm/session.html) object for the callback. If the `sessionmaker` is bound to an existing `Engine`, the same database connection can be reused.
-{{site.data.alerts.end}}
-
-`transactions.py` imports all of the table classes that we defined in [`movr/models.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/models.py), in addition to some standard Python data structures needed to generate correctly-typed row values that the ORM can write to the database.
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/transactions.py ||# START front ||# END front %}
-~~~
-
-##### Reading
-
-A common query that a client might want to run is a read of the `rides` table. The transaction callback function for this query is defined here as `get_rides_txn()`:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/transactions.py ||# START get_rides_txn ||# END get_rides_txn %}
-~~~
-
-The `get_rides_txn()` function takes a `Session` object and a `rider_id` string as its inputs, and it outputs a list of dictionaries containing the columns-value pairs of a row in the `rides` table. To retrieve the data from the database bound to a particular `Session` object, we use `Session.query()`, a method of the `Session` class. This method returns a `Query` object, with methods for filtering and ordering query results.
-
-Note that `get_rides_txn()` gets all rides for a specific rider across multiple regions. It does not filter the rides by `city`, and therefore does not limit the query to data stored in a particular region. As discussed in [MovR: An Example Multi-Region Use-Case](multi-region-use-case.html#latency-in-global-applications), running queries on data in multiple regions of a multi-region deployment can lead to latency problems. Because this function defines [a read operation](architecture/reads-and-writes-overview.html#read-scenario), it requires fewer trips between replicated nodes than a write operation, but will likely be slower than a read operation on data constrained to a single region.
-
-Another common query would be to read the registered vehicles in a particular city, to see which vehicles are available for riding. Unlike `get_rides_txn()`, the `get_vehicles_txn()` function takes the `city` string as an input.
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/transactions.py ||# START get_vehicles_txn ||# END get_vehicles_txn %}
-~~~
-
-This function filters the query on the `city` column. Because the data in the vehicles table is partitioned by `city`, the function only queries a specific partition of data, constrained to a particular region. This limits latency, as the query only needs to travel to database deployments in a single region.
-
-##### Writing
-
-There are two basic types of write operations: creating new rows and updating existing rows. In SQL terminology, these are [`INSERT`](insert.html)/[`UPSERT`](insert.html) statements and [`UPDATE`](update.html) statements.  All transaction callback functions that update existing rows include a `session.query()` call. All functions adding new rows call `session.add()`. Some functions do both.
-
-For example, `start_ride_txn()`, which is called when a user starts a ride, adds a new row to the `rides` table, and then updates a row in the `vehicles` table.
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/transactions.py ||# START start_ride_txn ||# END start_ride_txn %}
-~~~
-
-The function takes the `city` string, `rider_id` UUID, `rider_city` string, and `vehicle_id` UUID as inputs. It queries the `vehicles` table for all vehicles of a specific ID, and in a specific city. It also creates a `Ride` object, representing a row of the `rides` table. To add the ride to the table in the database bound to the `Session`, the function calls `Session.add()`. To update a row in the `vehicles` table, it modifies the object attribute. `start_ride_txn()` is called by `run_transaction()`, which commits the transaction to the database.
-
-Be sure to review the other callback functions in [`movr/transactions.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/transactions.py) before moving on to the next section.
-
-Now that we've covered the table classes and some transaction functions, we can look at the interface that connects web requests to a running CockroachDB cluster.
-
-### Database connection
-
-The `MovR` class, defined in [`movr/movr.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/movr.py), handles connections to CockroachDB using SQLAlchemy's [`Engine`](https://docs.sqlalchemy.org/en/13/core/connections.html#sqlalchemy.engine.Engine) class.
-
-Let's start with the beginning of the file:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/movr.py ||# START front ||# END front %}
-~~~
-
-`movr.py` first imports the transaction callback functions that we defined in [`movr/transactions.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/transactions.py). It then imports the `run_transaction()` function. The `MovR` class methods call `run_transaction()` to execute the transaction callback functions as transactions.
-
-The file also imports some `sqlalchemy` libraries to create instances of the `Engine` and `Session` classes, and to [register the CockroachDB as a dialect](https://docs.sqlalchemy.org/en/13/core/connections.html#registering-new-dialects).
-
-When called, the `MovR` class constructor creates an instance of the `Engine` class using an input connection string. This `Engine` object represents the connection to the database, and is used by the `sessionmaker()` function to create `Session` objects for each transaction.
-
-### Backend API
-
-The `MovR` class methods function as the "backend API" for the application. [Frontend requests](multi-region-application.html#routing) get routed to the these methods.
-
-We've already defined the transaction logic in the transaction callback functions, in [`movr/transactions.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/transactions.py). We can now wrap calls to the `run_transaction()` function in the `MovR` class methods.
-
-For example, look at the `start_ride()` method, the method to which frontend requests to start a ride are routed:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/movr/movr.py ||# START start_ride ||# END start_ride %}
-~~~
-
-This method takes some keyword arguments, and then returns a `run_transaction()` call. It passes `sessionmaker(bind=self.engine)` as the first argument to `run_transaction()`, which creates a new `Session` object that binds to the `Engine` instance initialized by the `MovR` constructor. It also passes `city`, `rider_id`, `rider_city`, and `vehicle_id`, values passed from the frontend request, as inputs. These are the same keyword arguments, and should be of the same types, as the inputs for the [transaction callback function](multi-region-application.html#writing) `start_ride_txn()`.
-
-Be sure to review the other functions in [`movr/movr.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/movr.py) before moving on to the next section.
-
-## Web application
-
-The application needs a frontend and a user interface. We use Flask for the web server, routing, and forms. For the web UI, we use some basic, Bootstrapped HTML templates.
-
-Most of the web application components are found in the `web` and `templates` folders, and in the `server.py` file.
-
-### Configuration
-
-We store the Flask configuration settings in [a `Config` class](https://flask.palletsprojects.com/en/1.1.x/config/#development-production), defined in [`web/config.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/web/config.py):
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/web/config.py %}
-~~~
-
-This file imports the `os` library, which is used to read from environment variables. When debugging a local deployment, these environment variables are set by the `.env` file that `Pipenv` reads. In a multi-region deployment, the environment variables are set by the `Dockerfile`, and by some commands issued during [the Kubernetes deployment](multi-region-deployment.html#multi-region-application-deployment-gke).
-
-The application sets a global Flask configuration variable (`DEBUG`), which it checks to determine whether or not to run against a demo cluster, or a real multi-region deployment.
-
-### Web forms
-
-Forms make up an important part of most web application frontends. We define these in [`web/forms.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/web/forms.py), using some data structures from the [`flask_wtf`](https://flask-wtf.readthedocs.io/en/latest/) and [`wtforms`](https://wtforms.readthedocs.io/en/stable/) libraries.
-
-We will not go into much detail about these forms. The important thing to know is that they help handle `POST` requests in the web UI.
-
-The `CredentialForm` class, for example, defines the fields of the login form that users interface with to send a login request to the server:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/web/forms.py ||# START CredentialForm ||# END CredentialForm %}
-~~~
-
-Most of the forms defined on this page take the inputs for database reads and writes.
-
-`VehicleForm`, for example, defines the fields of the vehicle registration form. Users enter information about a vehicle they would like to register, and the data is routed to the `add_vehicle()` method defined in [`movr/movr.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/movr.py):
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/web/forms.py ||# START VehicleForm ||# END VehicleForm %}
-~~~
-
-### Initialization
-
-[`server.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/server.py) defines the main process of the application: the web server. After initializing the database, we run `python server.py` to start up the web server.
-
-Let's look at the first ten lines of `server.py`:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/server.py ||# START front ||# END front %}
-~~~
-
-The first line imports standard Flask libraries for connecting, routing, and rendering web pages. The next three lines import some libraries from the Flask ecosystem, for [bootstrapping](https://pythonhosted.org/Flask-Bootstrap/), [authentication](https://flask-login.readthedocs.io/en/latest/), and [security](https://github.com/pallets/werkzeug/blob/master/src/werkzeug/security.py).
-
-The next four lines import other web resources that we've defined separately in our project:
-
-- The [`MovR`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/movr.py#L10) class, which handles the connection and interaction with the running CockroachDB cluster.
-- Several [`FlaskForm`](https://flask-wtf.readthedocs.io/en/latest/api.html#flask_wtf.FlaskForm) superclasses, which define the structure of web forms.
-- The [`Config`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/web/config.py) class, which holds configuration information for the Flask application.
-- [`get_region()`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/web/geoutils.py), which matches a city to a cloud provider region, so the application knows which partition to query.
-
-Finally, we import the `DBAPIError` type from `sqlalchemy`, for error handling.
-
-The next five or so lines initialize the application:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/server.py ||# START init ||# END init %}
-~~~
-
-Calling the `Flask()` constructor initializes our Flask web server. By assigning this to a variable (`app`), we can then configure the application, store variables in its attributes, and call it with functions from other libraries, to add features and functionality to the application.
-
-For example, we can bootstrap the application for enhanced HTML and form generation with [`Bootstrap(app)`](https://pythonhosted.org/Flask-Bootstrap/basic-usage.html#basic-usage). We can also add authentication with [`LoginManager(app)`](https://flask-login.readthedocs.io/en/latest/#configuring-your-application), and then control the default routes, based on authentication, with the `DEFAULT_ROUTE_AUTHENTICATED` and `DEFAULT_ROUTE_AUTHENTICATED` constants.
-
-Note that we also define a  `protocol` variable that the application later uses to determine its protocol scheme. You should always use HTTPS for secure connections when building an application that accepts user login information.
-
-After initializing the application, we can connect to the database:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/server.py ||# START connect ||# END connect %}
-~~~
-
-These two lines connect the application to the database. First the application retrieves the connection string that is stored as a configuration variable of the `app`. Then it calls the `MovR()` constructor to establish a connection to the database at the location we provided to the `Config` object.
-
-
-### User authentication
-
-User authentication is handled with the [`Flask-Login`](https://flask-login.readthedocs.io/en/latest/) library. This library manages user logins with the [`LoginManager`](https://flask-login.readthedocs.io/en/latest/#flask_login.LoginManager), and some other functions that help verify if a user has been authenticated or not.
-
-To control whether certain routes are accessible to a client session, we define a [`user_loader()` function](https://flask-login.readthedocs.io/en/latest/#flask_login.LoginManager.user_loader):
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/server.py ||# START user_loader ||# END user_loader %}
-~~~
-
-To restrict access to a certain page to users that are logged in with the [`LoginManager`](https://flask-login.readthedocs.io/en/latest/#flask_login.LoginManager), we add the `@login_required` decorator function to the route. We'll go over some examples in the [Routing](multi-region-application.html#routing) section below.
-
-### Routing
-
-We define all Flask routing functions directly in `server.py`.
-
-Flask applications use [`@app.route()` decorators](https://flask.palletsprojects.com/en/1.1.x/patterns/viewdecorators/) to handle client requests to specific URLs. When a request is sent to a URL served by the Flask app instance, the server calls the function defined within the decorator (the routing function).
-
-Flask provides a few useful callbacks to use within a routing function definition:
-
-- [`redirect()`](https://flask.palletsprojects.com/en/1.1.x/api/#flask.redirect), which redirects a request to a different URL.
-- [`render_template()`](https://flask.palletsprojects.com/en/1.1.x/api/#flask.render_template), which renders an HTML page, with Jinja2 templating, into a static webpage.
-- [`flash()`](https://flask.palletsprojects.com/en/1.1.x/api/#flask.flash), which sends messages from the application output to the webpage.
-
-In addition to calling these functions, and some other standard Flask and Python libraries, the application's routing functions need to call some of the methods that we defined in [`movr/movr.py`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/movr/movr.py) (the "backend API").
-
-For example, look at the `login()` route:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/server.py ||# START login_page ||# END login_page %}
-~~~
-
-### Client Location
-
-To optimize for latency in a global application, when a user arrives at the website, their request needs to be routed to the application deployment closest to the location from which they made the request. This step is handled outside of the application logic, by a [cloud-hosted, global load balancer](https://en.wikipedia.org/wiki/Cloud_load_balancing). In our [example multi-region deployment](multi-region-deployment.html#multi-region-application-deployment-gke), we use a [GCP multi-cluster ingress](https://cloud.google.com/kubernetes-engine/docs/how-to/multi-cluster-ingress).
-
-Let's assume that the application has been deployed behind a global load balancer that routes requests to deployments, based on the location of the request. Even if the application request is routed to the correct regional deployment of the application, the application still needs to know where the client is located, so that requests can be translated into database operations on the partitions relevant to the client's location (city, in this case). For example, if a user logs onto your website in New York, you want them to only see the vehicles available in New York, and you want to them to only be able to start rides in New York.
-
-All HTTP requests include standard HTTP headers. Client location information is not included in [standard HTTP header fields](https://en.wikipedia.org/wiki/List_of_HTTP_header_fields), but some non-standard HTTP header fields include information that can be used to derive client location, using client-side logic. For example, you can reverse geo-locate an IP address delivered through the [`X-Forwarded-For`](https://en.wikipedia.org/wiki/X-Forwarded-For) field.
-
-Most load-balancing services require you to enable header forwarding, or the original request headers will be lost behind the load balancer. Some services, like GCP Network Services, allow you to define non-standard HTTP headers to include location information directly with [user-defined request headers](https://cloud.google.com/load-balancing/docs/user-defined-request-headers), helping you avoid writing client-side logic for reverse geo-location.
-
-We discuss the details of configuring custom request header fields in our [example production deployment](multi-region-deployment.html#multi-region-application-deployment-gke). For now, let's assume that you receive the location of your client from a request header field named "`X-City`".
-
-Suppose that a user is coming to the website for the first time. They type in the address of the website, let's say `https://movr.com`, into their browser, and hit enter. The following example routing function gathers the client's location, stores it in a persistent Flask `session` variable, and then renders the home page:
-
-~~~ python
-{% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/server.py ||# START index ||# END index %}
-~~~
-
-The function's control flow sequence evaluates the `DEBUG` configuration variable first. If the application is in `DEBUG` mode, it simplifies the work that the application needs to do with the request information by setting the city to `new york`. This variable should be set to `True` if you are running the application against [a demo CockroachDB cluster](multi-region-setup.html#set-up-a-demo-multi-region-cockroachdb-cluster).
-
-If the application is not in `DEBUG` mode, then the request defines a new session variable, `city`, as the value in the request header field `X-City`. If the process fails for some reason (e.g., the `X-City` header field wasn't properly forwarded), the application sets `city` to `new york`, like the `DEBUG` case, and prints the error to the rendered webpage, using Flask's `flash()` function.
-
-In all cases, the session variables `city`, `region`, and `riding` are initialized, and then the `home.html` web page is rendered, with the `region` and `city` variables passed to the HTML template as variables.
-
-### User interface
-
-For the example application, we limit the web UI to some static HTML web pages, rendered using Flask's built-in [Jinja-2 engine](https://flask.palletsprojects.com/en/1.1.x/templating/). We will not spend much time covering the web UI. Just note that the forms take input from the user, and that input is usually passed to the backend where it is translated into and executed as a database transaction.
-
-We've also added some Bootstrap syntax and Google Maps, for UX purposes. As you can see, the Google Maps API requires a key. For debugging, you can define this key in the `.env` file. If you decide to use an embedded service like Google Maps in production, you should restrict your Google Maps API key to a specific hostname or IP address from within the cloud provider's console, as the API key will be publicly visible in the HTML. In [Deploying a Multi-Region Web Application](multi-region-deployment.html), we use Kubernetes secrets to the store the API keys.
-
-## Next Steps
-
-After you finish developing and debugging your application, you can start [deploying the application](multi-region-deployment.html).
-
-## See also
-
-<!-- [MovR (live demo)](https://movr.cloud)-->
-- [SQLAlchemy documentation](https://docs.sqlalchemy.org/en/latest/)
-- [Transactions](transactions.html)
-- [Flask documentation](https://flask.palletsprojects.com/en/1.1.x/)
-- [Build a Python App with CockroachDB and SQLAlchemy](build-a-python-app-with-cockroachdb-sqlalchemy.html)
diff --git a/src/current/v20.2/multi-region-database.md b/src/current/v20.2/multi-region-database.md
deleted file mode 100644
index c5aa1d0e14b..00000000000
--- a/src/current/v20.2/multi-region-database.md
+++ /dev/null
@@ -1,139 +0,0 @@
----
-title: Create a Multi-Region Database Schema
-summary: This page documents the database schema for the multi-region Flask application built on CockroachDB.
-toc: true
-canonical: /stable/movr-flask-database
----
-
-This page walks you through creating a database schema for an example multi-region application. It is the second section of the [Develop and Deploy a Multi-Region Web Application](multi-region-overview.html) tutorial.
-
-{% include {{ page.version.version }}/misc/movr-flask-211.md %}
-
-## Before you begin
-
-Before you begin this section, complete the previous section of the tutorial, [MovR: An Example Multi-Region Use-Case](multi-region-use-case.html).
-
-## The `movr` database
-
-The example application is built on a multi-region deployment of CockroachDB, loaded with the `movr` database. This database contains the following tables:
-
-- `users`
-- `vehicles`
-- `rides`
-
-These tables store information about the users and vehicles registered with MovR, and the rides associated with those users and vehicles.
-
-Here's a diagram of the database schema, generated with [DBeaver](dbeaver.html):
-
-<img src="{{ 'images/v20.2/movr_v2.png' | relative_url }}" alt="MovR database schema" style="border:1px solid #eee;max-width:100%" />
-
-Initialization statements for `movr` are defined in [`dbinit.sql`](https://github.com/cockroachlabs/movr-flask/blob/v1.0/dbinit.sql), a SQL file that you use later in this tutorial to load the database to a running cluster.
-
-{{site.data.alerts.callout_info}}
-This database is a slightly simplified version of the [`movr` database](movr.html) that is built into the `cockroach` binary. Although the two databases are similar, they have different schemas.
-{{site.data.alerts.end}}
-
-## Geo-partition the `movr` database
-
-Distributed CockroachDB deployments consist of multiple regional deployments of CockroachDB nodes that communicate as a single, logical database. In [CockroachDB terminology](architecture/overview.html#terms), these nodes comprise a *cluster*. CockroachDB splits rows of table data into *ranges*, and then replicates the ranges and distributes them to the individual nodes of the cluster. You can control where ranges are replicated and distributed with CockroachDB metadata objects known as [*replication zones*](configure-replication-zones.html).
-
-At startup, each node in a cluster is assigned a [locality](cockroach-start.html#locality). You can assign nodes to the same replication zone based on their locality. When you partition data, you break up tables into segments of rows, based on a common value or characteristic. To geo-partition the data, you constrain a partition to a specific replication zone.
-
-For example, suppose that the `movr` database is loaded to a multi-region CockroachDB cluster, with each node assigned a cloud provider `region` locality at startup.
-
-Each table in the `movr` database contains a `city` column, which signals a location for each row of data. If a user is registered in New York, their row in the `users` table will have a `city` value of `new york`. If that user takes a ride in Seattle, that ride's row in the `rides` table has a `city` value of `seattle`.
-
-You can [partition the tables](partition-by.html) of the `movr` database, based on the row's `city` value.
-
-For example:
-
-~~~ sql
-> PARTITION BY LIST (city) (
-    PARTITION us_west VALUES IN (('seattle'), ('san francisco'), ('los angeles')),
-    PARTITION us_east VALUES IN (('new york'), ('boston'), ('washington dc')),
-    PARTITION europe_west VALUES IN (('amsterdam'), ('paris'), ('rome'))
-);
-~~~
-
-After you define a partition, you can constrain it to a replication zone, using a [zone constraint](configure-zone.html) on the `region` locality. For the `users` table, this looks like:
-
-~~~ sql
-> ALTER PARTITION europe_west OF INDEX movr.public.users@primary CONFIGURE ZONE USING
-    constraints = '[+region=gcp-europe-west1]';
-  ALTER PARTITION us_east OF INDEX movr.public.users@primary CONFIGURE ZONE USING
-    constraints = '[+region=gcp-us-east1]';
-  ALTER PARTITION us_west OF INDEX movr.public.users@primary CONFIGURE ZONE USING
-    constraints = '[+region=gcp-us-west1]';
-~~~
-
-For full partitioning statements for each table and secondary index, see `dbinit.sql`.
-
-See below for the [`CREATE TABLE`](create-table.html) statements for each table in the database.
-
-## The `users` table
-
-Here is the `CREATE TABLE` statement for the `users` table:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> {% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/dbinit.sql ||-- START users ||-- END users %}
-~~~
-
-Note the following:
-
-- We want to partition this table on the `city` column. In order to partition on a column value, the column must be indexed. This table's composite [primary key index](primary-key.html) is on the `city` and `id` columns. Note that primary keys also imply [unique](unique.html) and [`NOT NULL`](not-null.html) constraints on the constrained column pair.
-- To optimize [queries on partitioned data](partitioning.html#filtering-on-an-indexed-column), the `city` column precedes the `id` column in the primary index. This guarantees that scans on the `users` table evaluate each row's `city` first, and then its `id`.
-- To improve the performance of [filtered query scans](select-clause.html#filter-rows), it is a best practice to [index columns in a `WHERE` clause.](indexes.html#best-practices). The composite primary key ensures that queries on partitioned data and on rows filtered by `id` (e.g., single-row look-ups) are optimized. To optimize queries filtered on the `username` column, there is a [secondary index](indexes.html) on the `username` column. Although explicitly stated here, CockroachDB automatically applies a [unique](unique.html) constraint to columns that are indexed.
-- There is a [check constraint](check.html) on the `city` column, which verifies that the value of the `city` column is valid. When [querying partitions](partitioning.html#filtering-on-an-indexed-column), check constraints also optimize queries filtered on the constrained columns.
-
-## The `vehicles` table
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> {% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/dbinit.sql ||-- START vehicles ||-- END vehicles %}
-~~~
-
-Note the following:
-
-- Like the `users` table, the `vehicles` table has a composite primary key on `city` and `id`.
-- The `vehicles` table has a [foreign key constraint](foreign-key.html) on the `users` table, for the `city` and `owner_id` columns. This guarantees that a vehicle is registered to a particular user (i.e., an "owner") in the city where that user is registered.
-- The table has a secondary index (`vehicles_auto_index_fk_city_ref_users`) on the `city`, `owner_id`, and `status`. By default, CockroachDB creates secondary indexes for all foreign key constraints. This optimizes scans made on the foreign key columns, for foreign key enforcement. Here, we add `status` to the secondary index, because reading and writing the status of a vehicle is a common query for the application. As mentioned in the `users` table section, it is a best practice to [index columns in a `WHERE` clause.](indexes.html#best-practices)
-- We include a [`PARTITION BY`](partition-by.html) statement for the `vehicles_auto_index_fk_city_ref_users` index. When geo-partitioning a database, it's important to geo-partition all indexes containing partition columns. In this case, the index includes `city`, so we should partition the index.
-
-    After defining this partition, you also need to add a zone constraint to the partition, so that it is truly geo-partitioned. For example, for the index's `us_east` partition, we use the following statement to configure the zone:
-
-    ~~~ sql
-    > ALTER PARTITION us_east OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users CONFIGURE ZONE USING
-        constraints = '[+region=gcp-us-east1]';
-    ~~~
-
-    See `dbinit.sql` for full zone configuration statements for all partitioned indexes.
-
-- Like `users`, the `vehicles` table also has a `CHECK` constraint on the `city` row, to optimize table scans in filtered queries.
-
-## The `rides` table
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> {% remote_include https://raw.githubusercontent.com/cockroachlabs/movr-flask/v1-doc-includes/dbinit.sql ||-- START rides ||-- END rides %}
-~~~
-
-Note the following:
-
-- Like the `users` and `vehicles` tables, the `rides` table has a composite primary key on `city` and `id`.
-- Like the `vehicles` table, the `rides` table has foreign key constraints. These constraints are on the `users` and the `vehicles` tables.
-- The foreign key indexes are partitioned. These partitions need to be zone-constrained like the other partitions. For full zone configuration statements, see `dbinit.sql`.
-- Like `users` and `vehicles`, the table has a `CHECK` constraint on the `city` row, to optimize filtered queries.
-
-## Next steps
-
-Now that you are familiar with the `movr` schema, [set up a development environment for a multi-region application](multi-region-setup.html).
-
-## See also
-
-- [`movr-flask` on GitHub](https://github.com/cockroachlabs/movr-flask)
-- [CockroachDB terminology](architecture/overview.html#terms)
-- [Configure Replication Zones](configure-replication-zones.html)
-- [`CONFIGURE ZONE`](configure-zone.html)
-- [Define Table Partitions](partitioning.html)
-- [`PARTITION BY`](partition-by.html)
diff --git a/src/current/v20.2/multi-region-deployment.md b/src/current/v20.2/multi-region-deployment.md
deleted file mode 100644
index 03ffa251df3..00000000000
--- a/src/current/v20.2/multi-region-deployment.md
+++ /dev/null
@@ -1,276 +0,0 @@
----
-title: Deploy a Multi-Region Web Application
-summary: This page includes instructions for deploying a multi-region web application using CockroachDB Cloud and Google Cloud services.
-toc: true
-canonical: /stable/movr-flask-deployment
----
-
-This page walks you through deploying an application and database in multiple regions. It is the fifth and final section of the [Develop and Deploy a Multi-Region Web Application](multi-region-overview.html) tutorial.
-
-{% include {{ page.version.version }}/misc/movr-flask-211.md %}
-
-<!-- {% include {{ page.version.version }}/misc/movr-live-demo.md %} -->
-
-## Before you begin
-
-Before you begin this section, complete the previous section of the tutorial, [Develop a Multi-Region Web Application](multi-region-application.html). After you finish developing and debugging your multi-region application in a local development environment, you are ready to deploy the application and database in multiple regions.
-
-In addition to the requirements listed in [Setting Up a Virtual Environment for Developing Multi-Region Applications](multi-region-setup.html), make sure that you have the following installed on your local machine:
-
-- [Google Cloud SDK](https://cloud.google.com/sdk/install)
-- [Docker](https://docs.docker.com/v17.12/docker-for-mac/install/)
-- [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/)
-
-## Multi-region database deployment
-
-In production, you want to start a secure CockroachDB cluster, with nodes on machines located in different areas of the world. To deploy CockroachDB in multiple regions, using [CockroachDB {{ site.data.products.serverless }}](../cockroachcloud/quickstart.html):
-
-1. Create a CockroachDB {{ site.data.products.cloud }} account at [https://cockroachlabs.cloud](https://cockroachlabs.cloud).
-
-1. Request a multi-region CockroachDB {{ site.data.products.cloud }} cluster on GCP, in regions us-west1, us-east1, and europe-west1.
-
-1. After the cluster is created, open the console, and select the cluster.
-
-1. Select **SQL Users** from the side panel, select **Add user**, give the user a name and a password, and then add the user. You can use any user name except "root".
-
-1. Select **Networking** from the side panel, and then select **Add network**. Give the network any name you'd like, select either a **New network** or a **Public network**, check both **UI** and **SQL**, and then add the network. In this example, we use a public network.
-
-1. Select **Connect** at the top-right corner of the cluster console.
-
-1. Select the **User** that you created, and then **Continue**.
-
-1. Copy the connection string, with the user and password specified.
-
-1. **Go back**, and retrieve the connection strings for the other two regions.
-
-1. Download the cluster cert to your local machine (it's the same for all regions).
-
-1. Open a new terminal, and run the `dbinit.sql` file on the running cluster to initialize the database. You can connect to the database from any node on the cluster for this step.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --url any-connection-string < dbinit.sql
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    You need to specify the password in the connection string!
-    {{site.data.alerts.end}}
-
-    e.g.,
-
-    ~~~ shell
-    $ cockroach sql --url \ 'postgresql://user:password@region.cockroachlabs.cloud:26257/defaultdb?sslmode=verify-full&sslrootcert=certs-dir/movr-app-ca.crt' < dbinit.sql
-    ~~~
-
-{{site.data.alerts.callout_info}}
-You can also deploy CockroachDB manually. For instructions, see the [Manual Deployment](manual-deployment.html) page of the Cockroach Labs documentation site.
-{{site.data.alerts.end}}
-
-## Multi-region application deployment (GKE)
-
-To deploy an application in multiple regions in production, we recommend that you use a [managed Kubernetes engine](https://kubernetes.io/docs/setup/#production-environment), like [Amazon EKS](https://aws.amazon.com/eks/), [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), or [Azure Kubernetes Service](https://azure.microsoft.com/en-us/services/kubernetes-service/). To route requests to the container cluster deployed closest to clients, you should also set up a multi-cluster [ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/).
-
-In this tutorial, we use [kubemci](https://cloud.google.com/kubernetes-engine/docs/how-to/multi-cluster-ingress) to configure a GCP HTTP Load Balancer to container clusters deployed on GKE.
-
-{{site.data.alerts.callout_info}}
-To serve a secure web application, you also need a public domain name!
-{{site.data.alerts.end}}
-
-1. If you do not have a gcloud account, create one at https://cloud.google.com/.
-
-1. Create a gcloud project on the [GCP console](https://console.cloud.google.com/).
-
-1. **Optional:** Enable the [Google Maps Embed API](https://console.cloud.google.com/apis/library), create an API key, restrict the API key to all subdomains of your domain name (e.g., `https://site.com/*`), and retrieve the API key.
-
-    {{site.data.alerts.callout_info}}
-    The example HTML templates include maps. Not providing an API key to the application will not break the application.
-    {{site.data.alerts.end}}
-
-1. Configure/authorize the `gcloud` CLI to use your project and region.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud init
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud auth login
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud auth application-default login
-    ~~~
-
-1. If you haven't already, install `kubectl`.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud components install kubectl
-    ~~~
-
-1. Build and run the Docker image locally.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ docker build -t gcr.io/<gcp_project>/movr-app:v1 .
-    ~~~
-
-    If there are no errors, the container built successfully.
-
-1. Push the Docker image to the project’s gcloud container registry.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ docker push gcr.io/<gcp_project>/movr-app:v1
-    ~~~
-
-1. Create a K8s cluster for all three regions.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud config set compute/zone us-east1-b && \
-      gcloud container clusters create movr-us-east
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud config set compute/zone us-west1-b && \
-      gcloud container clusters create movr-us-west
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud config set compute/zone europe-west1-b && \
-      gcloud container clusters create movr-europe-west
-    ~~~
-
-1. Add the container credentials to `kubeconfig`.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ KUBECONFIG=~/mcikubeconfig gcloud container clusters get-credentials --zone=us-east1-b movr-us-east
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ KUBECONFIG=~/mcikubeconfig gcloud container clusters get-credentials --zone=us-west1-b movr-us-west
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ KUBECONFIG=~/mcikubeconfig gcloud container clusters get-credentials --zone=europe-west1-b movr-europe-west
-    ~~~
-
-1. For each cluster context, create a secret for the connection string, Google Maps API, and the certs, and then create the k8s deployment and service using the `movr.yaml` manifest file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl config use-context <context-name> && \
-    kubectl create secret generic movr-db-cert --from-file=cert=<full-path-to-cert> && \
-    kubectl create secret generic movr-db-uri --from-literal=DB_URI="connection-string" && \
-    kubectl create secret generic maps-api-key --from-literal=API_KEY="APIkey" \
-    kubectl create -f ~/movr-flask/movr.yaml
-    ~~~
-
-    Where:
-    <ul>
-      <li>`<context-name>` is the cluster context for a regional deployment. To get the contexts for all deployments, run `$ kubectl config get-contexts -o name`.</li>
-      <li>`<full-path-to-cert>` is the full directory path to the certificates for [the multi-region CockroachDB {{ site.data.products.cloud }} cluster](#multi-region-database-deployment). These certificates are available for download from the CockroachDB {{ site.data.products.cloud }} console, and they are the same for all regions.</li>
-      <li>`<connection-string>` is the full connection string to the gateway node of [a regional CockroachDB {{ site.data.products.cloud }} deployment](#multi-region-database-deployment). It should look something like:<br> `postgresql://user:password@region.cockroachlabs.cloud:26257/defaultdb?sslmode=verify-full&sslrootcert=certs-dir/movr-app-ca.crt`</li>
-      <li>`<APIkey>` is the API key for the [Google Maps Embed API](https://console.cloud.google.com/apis/library). This API key is *not* required to run the demo application. Not providing a Google Maps Embed API key will not break the application.</li>
-    </ul>
-
-    {{site.data.alerts.callout_info}}
-    Secrets must be generated for each cluster context.
-    {{site.data.alerts.end}}
-
-1. Reserve a static IP address for the ingress.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud compute addresses create --global movr-ip
-    ~~~
-
-    To verify that you successfully created the new IP address, run the following command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud compute addresses list
-    ~~~
-
-
-1. Download [`kubemci`](https://github.com/GoogleCloudPlatform/k8s-multicluster-ingress), and then make it executable:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ chmod +x ~/kubemci
-    ~~~
-
-1. Use `kubemci` to make the ingress.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ~/kubemci create movr-mci \
-    --ingress=<path>/movr-flask/mcingress.yaml \
-    --gcp-project=<gcp_project> \
-    --kubeconfig=<path>/mcikubeconfig
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    `kubemci` requires full paths.
-    {{site.data.alerts.end}}
-
-1. In GCP's **Load balancing** console (found under **Network Services**), select and edit the load balancer that you just created.
-
-    1. Edit the backend configuration.
-        - Expand the advanced configurations, and add [a custom header](https://cloud.google.com/load-balancing/docs/user-defined-request-headers): `X-City: {client_city}`. This forwards an additional header to the application telling it what city the client is in. The header name (`X-City`) is hardcoded into the example application.
-
-    1. Edit the frontend configuration, and add a new frontend.
-        - Under "**Protocol**", select HTTPS.
-        - Under "**IP address**", select the static IP address that you reserved earlier (e.g., "`movr-ip`").
-        - Under "**Certificate**", select "**Create a new certificate**".
-        - On the "**Create a new certificate**" page, give a name to the certificate (e.g., "`movr-ssl-cert`"), check "**Create Google-managed certificate**", and then under "Domains", enter a domain name that you own and want to use for your application.
-    1. Review and finalize the load balancer, and then "**Update**".
-
-        {{site.data.alerts.callout_info}}
-        It will take several minutes to provision the SSL certificate that you just created for the frontend.
-        {{site.data.alerts.end}}
-
-1. Check the status of the ingress.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ~/kubemci list --gcp-project=<gcp_project>
-    ~~~
-
-1. In the **Cloud DNS** console (found under **Network Services**), create a new zone. You can name the zone whatever you want. Enter the same domain name for which you created a certificate earlier.
-
-1. Select your zone, and copy the nameserver addresses (under "**Data**") for the recordset labeled "**NS**".
-
-1. Outside of the GCP console, through your domain name provider, add the nameserver addresses to the authoritative nameserver list for your domain name.
-
-    {{site.data.alerts.callout_info}}
-    It can take up to 48 hours for changes to the authoritative nameserver list to take effect.
-    {{site.data.alerts.end}}
-
-1. Navigate to the domain name and test out your application.
-
-## Next steps
-
-### Develop your own application
-
-This tutorial demonstrates how to develop and deploy an example multi-region application. Most of the development instructions are specific to Python, Flask, and SQLAlchemy, and most of the deployment instructions are specific to Google Cloud Platform, Docker, and Kubernetes. CockroachDB supports [many more drivers and ORM's for development](example-apps.html). You can deploy applications using a number of cloud provider orchestration tools and networking services. We encourage you to modify the code and deployments to fit your framework and use case.
-
-### Upgrade your deployment
-
-Some time after you have deployed your application, you will likely need to push changes that you've made locally. When pushing changes, be aware that you defined the database separate from the application. If you change a data type, for example, in your application, you will also need to modify the database schema to be compatible with your application's requests. For information about making online changes to database schemas, see [Online Schema Changes](online-schema-changes.html).
-
-## See also
-
-<!-- [MovR (live demo)](https://movr.cloud)-->
-- [CockroachDB {{ site.data.products.cloud }} documentation](../cockroachcloud/quickstart.html)
-- [Google Cloud Platform documentation](https://cloud.google.com/docs/)
-- [Docker documentation](https://docs.docker.com/)
-- [Kubernetes documentation](https://kubernetes.io/docs/home/)
diff --git a/src/current/v20.2/multi-region-overview.md b/src/current/v20.2/multi-region-overview.md
deleted file mode 100644
index 84a3a156cd5..00000000000
--- a/src/current/v20.2/multi-region-overview.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Develop and Deploy a Multi-Region Web Application
-summary: Learn how to build and deploy a multi-region web application on CockroachDB, using Flask, SQLAlchemy, CockroachDB Cloud, and Google Cloud services.
-toc: true
-canonical: /stable/movr-flask-overview
----
-
-This tutorial walks you through developing and deploying a multi-region web application built on CockroachDB, using Flask, SQLAlchemy, CockroachDB {{ site.data.products.cloud }}, and Google Cloud Platform services.
-
-{% include {{ page.version.version }}/misc/movr-flask-211.md %}
-
-The following sections make up the tutorial:
-
-1. [MovR: An Example Multi-Region Use-Case](multi-region-use-case.html)
-1. [Create a Multi-Region Database Schema](multi-region-database.html)
-1. [Set Up a Virtual Environment for Developing Multi-Region Applications](multi-region-setup.html)
-1. [Develop a Multi-Region Web Application](multi-region-application.html)
-1. [Deploy a Multi-Region Web Application](multi-region-deployment.html)
-
-Throughout the tutorial, we reference the source code for an example web application for the fictional vehicle-sharing company [MovR](movr.html). The source code for this application is open source and available on GitHub, in the [`movr-flask` repository ](https://github.com/cockroachlabs/movr-flask/tree/v1.0). The code is well-commented, with docstrings defined at the beginning of each class and function definition.
-
-The repo's [README](https://github.com/cockroachlabs/movr-flask/blob/v1.0/README.md) also includes instructions on debugging and deploying the application using Google Cloud services. Those instructions are reproduced in [Setting Up a Virtual Environment for Developing Multi-Region Applications](multi-region-setup.html) and [Deploying a Multi-Region Web Application](multi-region-deployment.html).
-
-<!-- {% include {{ page.version.version }}/misc/movr-live-demo.md %} -->
diff --git a/src/current/v20.2/multi-region-setup.md b/src/current/v20.2/multi-region-setup.md
deleted file mode 100644
index 9339cf8f50a..00000000000
--- a/src/current/v20.2/multi-region-setup.md
+++ /dev/null
@@ -1,138 +0,0 @@
----
-title: Set Up a Virtual Environment for Developing Multi-Region Applications
-summary: This page walks you through setting up a demo multi-region CockroachDB cluster, and a virtual development environment.
-toc: true
-canonical: /stable/movr-flask-setup
----
-
-This page walks you through setting up a virtual environment for developing and debugging an example multi-region application. It is the third section of the [Develop and Deploy a Multi-Region Web Application](multi-region-overview.html) tutorial. In this section, you will set up a demo CockroachDB cluster, initialize the database, and set up a virtual development environment.
-
-{% include {{ page.version.version }}/misc/movr-flask-211.md %}
-
-## Before you begin
-
-1. Complete the previous section of the tutorial, [Create a Multi-Region Database Schema](multi-region-database.html).
-
-1. Make sure that you have the following installed on your local machine:
-      - [CockroachDB](install-cockroachdb-mac.html)
-      - [Python 3](https://www.python.org/downloads/)
-      - [Pipenv](https://pipenv.readthedocs.io/en/latest/)
-
-1. Clone the [`movr-flask`](https://github.com/cockroachlabs/movr-flask) repository. We'll reference the source code in this repository throughout the tutorial.
-
-## Set up a demo multi-region CockroachDB cluster
-
-For debugging and development purposes, you can use the [`cockroach demo`](cockroach-demo.html) command. This command starts up an insecure, nine-node demo cluster.
-
-1. To set up the demo multi-region cluster, run `cockroach demo`, with the `--nodes` and `--demo-locality` flags. The localities specified below assume GCP region names.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach demo \
-    --nodes=9 \
-    --demo-locality=region=gcp-us-east1:region=gcp-us-east1:region=gcp-us-east1:\
-    region=gcp-us-west1:region=gcp-us-west1:region=gcp-us-west1:\
-    region=gcp-europe-west1:region=gcp-europe-west1:region=gcp-europe-west1
-    ~~~
-
-    ~~~
-    root@127.0.0.1:62268/movr>
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    Your port number will likely be different than the one shown here.
-    {{site.data.alerts.end}}
-
-    Keep this terminal window open. Closing it will shut down the demo cluster.
-
-1. Copy the connection string at the prompt (e.g., `root@127.0.0.1:62268/movr`).
-
-1. Open another terminal window. In the new window, run the following command to load `dbinit.sql` to the demo database. This file contains the `movr` database definition, and SQL instructions to geo-partition the database.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --url='postgresql://root@127.0.0.1:62268/movr' < dbinit.sql
-    ~~~
-
-
-1. In the demo cluster terminal, verify that the database schema loaded properly:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TABLES;
-    ~~~
-    ~~~
-      table_name
-    +------------+
-      rides
-      users
-      vehicles
-    (3 rows)
-    ~~~
-
-{{site.data.alerts.callout_info}}
-In production, you want to start a secure CockroachDB cluster, with nodes on machines located in different areas of the world. For instructions on deploying a multi-region CockroachDB cluster for this application, using CockroachDB {{ site.data.products.dedicated }}, see [Deploy a Multi-Region Web Application](multi-region-deployment.html).
-{{site.data.alerts.end}}
-
-
-## Set up a virtual development environment
-
-For debugging, use [`pipenv`](https://docs.pipenv.org/), a tool that manages dependencies with `pip` and creates virtual environments with `virtualenv`.
-
-1. Run the following command to initialize the project's virtual environment:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ pipenv --three
-    ~~~
-
-    `pipenv` creates a `Pipfile` in the current directory, with the requirements needed for the app.
-
-1. Run the following command to install the packages listed in the `Pipfile`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ pipenv install
-    ~~~
-
-1. To connect to a SQL database (like CockroachDB) from a client, you need a [SQL connection string](connection-parameters.html). Rather than hard-coding the connection string into the source code, the application reads it from an environment variable. Pipenv automatically sets any variables defined in a `.env` file as environment variables in a Pipenv virtual environment.
-
-    Open `.env` and edit the `DB_URI` environment variable so that it matches the connection string for the demo cluster that you started earlier (you may need to change the `<port>`). Note that SQLAlchemy requires the connection string protocol to be specific to the CockroachDB dialect, as shown below:
-
-    ~~~
-    DB_URI = 'cockroachdb://root@127.0.0.1:62268/movr'
-    ~~~
-
-    `.env` also specifies a few other variables, like API keys and secret keys, that are used by the application. For debugging purposes, you should leave these variables as they are.
-
-1. Activate the virtual environment:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ pipenv shell
-    ~~~
-
-    From this shell, you can run any Python 3 application with the required dependencies that you listed in the `Pipfile`, and the environment variables that you listed in the `.env` file. You can exit the shell subprocess at any time with a simple `exit` command.
-
-1. To test out the application, you can run the server file:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ python server.py
-    ~~~
-
-1. Navigate to the URL provided to test out the application. By default, this should be http://127.0.0.1:5000/.
-
-{{site.data.alerts.callout_info}}
-In production, you want to [containerize](https://www.docker.com/resources/what-container) your application and deploy it with a deployment orchestration tool, like [Kubernetes](https://kubernetes.io/). For instructions on deploying this application in multiple regions, see [Deploy a Multi-Region Web Application](multi-region-deployment.html).
-{{site.data.alerts.end}}
-
-## Next steps
-
-Now that you've set up a development environment, you can start [developing and debugging the application](multi-region-application.html).
-
-## See also
-
-- [`movr-flask` on GitHub](https://github.com/cockroachlabs/movr-flask)
-- [`cockroach demo`](cockroach-demo.html)
-- [Pipenv](https://pipenv.readthedocs.io/en/latest/)
diff --git a/src/current/v20.2/multi-region-use-case.md b/src/current/v20.2/multi-region-use-case.md
deleted file mode 100644
index b0b094a3e21..00000000000
--- a/src/current/v20.2/multi-region-use-case.md
+++ /dev/null
@@ -1,65 +0,0 @@
----
-title: MovR&#58; An Example Multi-Region Use-Case
-summary: This page covers an example use-case for multi-region applications.
-toc: true
-canonical: /stable/movr-flask-use-case
----
-
-This page walks you through an example use case for multi-region application development and deployment. It is the first section of the [Develop and Deploy a Multi-Region Web Application](multi-region-overview.html) tutorial.
-
-{% include {{ page.version.version }}/misc/movr-flask-211.md %}
-
-## Overview
-
-MovR is a fictional company that offers users a platform for sharing vehicles, like scooters, bicycles, and skateboards, in select cities across the United States and Europe. To serve users in two continents, they need an application that is globally available, [resilient to  system failures](multi-region-use-case.html#resiliency-and-distributed-deployments), and [optimized for latency](multi-region-use-case.html#latency-in-global-applications). To meet these requirements, the application is built on CockroachDB, and designed and deployed to consider resiliency and latency across different geographic locations.
-
-## Resiliency and distributed deployments
-
-For an application to be resilient to system failures, the application server and database need to be deployed on multiple machines (i.e., part of a distributed deployment). In distributed CockroachDB deployments, all data is replicated and distributed across the instances of the database that make up the deployment.  For more information about data replication and distribution in CockroachDB, see [The Raft Protocol in CockroachDB](https://www.youtube.com/watch?v=k5BR9m8o9ec&feature=youtu.be).
-
-The replication and distribution of data across multiple machines in a *single region* makes the deployment resilient to individual node failures within the region. Replication and distribution across *multiple regions* makes the deployment resilient to regional failures. To make the database resilient to regional failures, use a multi-region deployment.
-
-{{site.data.alerts.callout_info}}
-In the example deployment, the application and the database deployments are separate and not co-located on the same machine.
-{{site.data.alerts.end}}
-
-## Latency in global applications
-
-If the MovR application and database are deployed in a single region, latency can be a serious problem for users located in cities outside the deployment region. However, deploying the application and database in multiple regions will not improve latency if client requests are sent to any server in the deployment, without consideration for the client's location.
-
-Limiting latency improves the user experience, and it can also help avoid problems with data integrity, like [transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). For the purpose of this tutorial, we'll focus on two types of latency:
-
-- [*Database latency*](multi-region-use-case.html#database-latency), which we define as the time required to complete database operations.
-- [*Application latency*](multi-region-use-case.html#application-latency), which we define as the time required to make requests to an application server.
-
-### Database latency
-
-To reduce database latency in a distributed CockroachDB deployment, data can be [geo-partitioned](topology-geo-partitioned-replicas.html). Geo-partitioning enables you to control where specific rows of data are stored. Limiting database operations to specific partitions can reduce the distance requests need to travel between the client and the database.
-
-{{site.data.alerts.callout_info}}
-Geo-partitioned replicas can dramatically improve latency in multi-region deployments, but at the [cost of resiliency](topology-geo-partitioned-replicas.html#resiliency). Geo-partitioned replicas are resilient to availability zone failures, but not regional failures.
-{{site.data.alerts.end}}
-
-If you are building an application, it's likely that the end user will not be making requests to the database directly. Instead, the user makes requests to the application, and the application makes requests to the database on behalf of the user. To limit the latency between the application and the database, you need to design and deploy your application such that:
-
-- Each instance of the application communicates with the closest database instance. This can be configured during the deployment. Later in the tutorial, in the [multi-region deployment steps](multi-region-deployment.html#multi-region-application-deployment-gke), we walk you through configuring the application to communicate with the database closest to it.
-- The application's database operations query relevant, geo-partitioned data. To do this, the application must be aware of the client's location. This requires the load balancer to pass client location information to the application. We cover configuring custom HTTP headers for client location in the [application deployment steps](multi-region-deployment.html#multi-region-application-deployment-gke). We also discuss [handling client location server-side](multi-region-application.html#client-location) in [Developing a Multi-Region Web Application](multi-region-application.html).
-
-### Application latency
-
-To limit the latency between client and application server requests, you need to deploy your application such that requests are routed to the application deployment closest to the client. This requires a global load balancer that can redirect traffic to application deployments, based on client location. We cover setting up a multi-cluster ingress in the [multi-region application deployment steps](multi-region-deployment.html#multi-region-application-deployment-gke).
-
-In the sections that follow, we cover some best practices in database schema creation with an example database. We also cover some basics for developing a locality-aware, global application.
-
-## Next steps
-
-You should now be ready to start [creating a multi-region database schema](multi-region-database.html).
-
-## See also
-
-- [`movr-flask` on GitHub](https://github.com/cockroachlabs/movr-flask)
-- [CockroachDB terminology](architecture/overview.html#terms)
-- [Configure Replication Zones](configure-replication-zones.html)
-- [Define Table Partitions](partitioning.html)
-- [Topology Patterns](topology-patterns.html)
-- [Geo-Partitioned Replicas Topology](topology-geo-partitioned-replicas.html)
diff --git a/src/current/v20.2/multilinestring.md b/src/current/v20.2/multilinestring.md
deleted file mode 100644
index d706c3932f5..00000000000
--- a/src/current/v20.2/multilinestring.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: MULTILINESTRING
-summary: The spatial MULTILINESTRING object is a collection of LINESTRINGs.
-toc: true
----
-
-A `MULTILINESTRING` is a collection of [LineStrings](linestring.html).  MultiLineStrings are useful for gathering a group of LineStrings into one geometry. For example, you may want to gather the LineStrings denoting all of the roads in a particular municipality.
-
-## Examples
-
-### Well known text
-
-A MultiLineString can be created from SQL by calling the `st_geomfromtext` function on a MultiLineString definition expressed in the [Well Known Text (WKT)](spatial-glossary.html#wkt) format.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeomFromText('MULTILINESTRING((0 0, 1440 900), (800 600, 200 400))');
-~~~
-
-~~~
-                                                                                     st_geomfromtext
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  0105000000020000000102000000020000000000000000000000000000000000000000000000008096400000000000208C4001020000000200000000000000000089400000000000C0824000000000000069400000000000007940
-(1 row)
-~~~
-
-### SQL
-
-A MultiLineString can be created from SQL by calling an aggregate function such as `ST_Collect` or [`ST_Union`](st_union.html) on a column that contains [LineString](linestring.html) geometries.  In the example below, we will build a MultiLineString from several LineStrings.
-
-First, insert the LineStrings:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE tmp_linestrings (id INT8 default unique_rowid(), geom GEOMETRY);
-
-INSERT INTO tmp_linestrings (geom)
-VALUES
-(st_geomfromtext('SRID=4326;LINESTRING(-88.243385 40.116421, -87.906471 43.038902, -95.992775 36.153980)')),
-(st_geomfromtext('SRID=4326;LINESTRING(-75.704722 36.076944, -95.992775 36.153980, -87.906471 43.038902)')),
-(st_geomfromtext('SRID=4326;LINESTRING(-76.8261 42.1727,  -75.6608 41.4102,-73.5422 41.052, -73.929 41.707,  -76.8261 42.1727)'));
-~~~
-
-Next, build a MultiLineString from the individual [LineStrings](linestring.html) using `ST_Collect`, and check the output with `ST_GeometryType` to verify that it is indeed a MultiLineString:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeometryType(st_collect(geom)) AS output FROM tmp_linestrings;
-~~~
-
-~~~
-        output
-----------------------
-  ST_MultiLineString
-(1 row)
-~~~
-
-Finally, drop the temporary table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-DROP TABLE tmp_linestrings;
-~~~
-
-## See also
-
-- [Spatial objects](spatial-features.html#spatial-objects)
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/multipoint.md b/src/current/v20.2/multipoint.md
deleted file mode 100644
index c74de939dbf..00000000000
--- a/src/current/v20.2/multipoint.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-title: MULTIPOINT
-summary: The spatial MULTIPOINT object is a collection of POINTs.
-toc: true
----
-
-A `MULTIPOINT` is a collection of [Points](point.html).  MultiPoints are useful for gathering a group of Points into one geometry. For example, you may want to gather the points denoting all of the State Capitols in the U.S. into a single geometry.
-
-## Examples
-
-### SQL
-
-A MultiPoint can be created from SQL by calling an aggregate function such as `ST_Collect` or [`ST_Union`](st_union.html) on a column that contains [Point](point.html) geometries.  In the example below, we will build a MultiPoint from several Points.
-
-First, insert the Points:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE tmp_points (id INT8 default unique_rowid(), geom GEOMETRY);
-
-INSERT INTO tmp_points (geom)
-VALUES
-(st_geomfromtext('POINT (-88.243357000000003 40.117404000000001)')),
-(st_geomfromtext('POINT (-94.598371 39.050068000000003)')),
-(st_geomfromtext('POINT (-73.962090000000003 40.609226)'));
-~~~
-
-Next, build a MultiPoint from the individual [Points](point.html) using `ST_Collect`, and check the output with `ST_GeometryType` to verify that it is indeed a MultiPoint:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeometryType(st_collect(geom)) AS output FROM tmp_points;
-~~~
-
-~~~
-     output
------------------
-  ST_MultiPoint
-(1 row)
-~~~
-
-Finally, drop the temporary table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-DROP TABLE tmp_points;
-~~~
-
-### Well known text
-
-A MultiPoint can be created from SQL by calling the `st_geomfromtext` function on a MultiPoint definition expressed in the [Well Known Text (WKT)](spatial-glossary.html#wkt) format.
-
-For example, the MultiPoint in the example below includes the locations of [independent bookstores in Chicago, Illinois USA](https://www.bookweb.org/member_directory/search/ABAmember/results/0/Chicago/IL/0):
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeomFromText('MULTIPOINT (-87.738258999999999 42.010930999999999, -87.716257999999996 41.981231000000001, -87.708889999999997 41.975000000000001, -87.707705000000004 41.929195999999997, -87.707192000000006 41.926580000000001, -87.704300000000003 41.928013999999997, -87.698012000000006 41.939076, -87.682384999999996 41.943232000000002, -87.681599000000006 41.705936999999999, -87.677763999999996 41.916998, -87.674808999999996 41.9086, -87.668653000000006 41.977356999999998, -87.668611999999996 41.904580000000003, -87.664944000000006 41.921931999999998, -87.655131999999995 41.881686000000002, -87.654752999999999 41.881632000000003, -87.654584 41.944774000000002, -87.653409999999994 41.857928000000001, -87.650779999999997 41.926853000000001, -87.644745999999998 41.941915999999999, -87.644356999999999 41.899109000000003, -87.634562000000003 41.897446000000002, -87.630498000000003 41.899751000000002, -87.629164000000003 41.873215999999999, -87.627983999999998 41.883583999999999, -87.627189999999999 41.890832000000003, -87.624488999999997 41.885147000000003, -87.624283000000005 41.876899000000002, -87.624251999999998 41.874115000000003, -87.622851999999995 41.894931999999997, -87.619151000000002 41.864832999999997, -87.597796000000002 41.789636000000002, -87.596547999999999 41.790515999999997, -87.594948000000002 41.791434000000002, -87.591048999999998 41.808132999999998, -87.590436999999994 41.783611000000001, -87.590277 41.800938000000002)');
-~~~
-
-~~~
-                                                                               st_geomfromtext
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  0104000000250000000101000000923EADA23FEF55C09CC1DF2F660145400101000000E55FCB2BD7ED55C0236937FA98FD44400101000000889D29745EED55C0CDCCCCCCCCFC44400101000000CE8DE9094BED55C079C9FFE4EFF6444001010000008BFF3BA242ED55C05890662C9AF644400101000000A9A44E4013ED55C0751DAA29C9F644400101000000CC0D863AACEC55C0B03A72A433F844400101000000FB912232ACEB55C0354580D3BBF844400101000000207F69519FEB55C0A704C4245CDA44400101000000FE99417C60EB55C0AB3FC23060F544400101000000F982161230EB55C0A3923A014DF444400101000000D4D7F335CBEA55C022C2BF081AFD44400101000000A46DFC89CAEA55C0CF4E0647C9F344400101000000F96A47718EEA55C0649126DE01F64440010100000009A4C4AEEDE955C0A8AB3B16DBF0444001010000004E7D2079E7E955C0B58D3F51D9F044400101000000081F4AB4E4E955C0390EBC5AEEF84440010100000047382D78D1E955C04E29AF95D0ED4440010100000004392861A6E955C089997D1EA3F644400101000000840EBA8443E955C021CA17B490F844400101000000B77C24253DE955C00745F30016F3444001010000003352EFA99CE855C088F6B182DFF244400101000000618C48145AE855C08BC56F0A2BF34440010100000084F4143944E855C0062CB98AC5EF44400101000000529ACDE330E855C06AA2CF4719F144400101000000359886E123E855C07A1D71C806F2444001010000008DEDB5A0F7E755C08693347F4CF144400101000000B91CAF40F4E755C09372F7393EF0444001010000009B1DA9BEF3E755C0B6F81400E3EF44400101000000E28FA2CEDCE755C06A12BC218DF2444001010000004912842BA0E755C033C005D9B2EE444001010000007F6B274A42E655C044DFDDCA12E544400101000000A19FA9D72DE655C07C7BD7A02FE54440010100000085B4C6A013E655C0A37895B54DE54440010100000058552FBFD3E555C0C0E8F2E670E7444001010000004B5645B8C9E555C097E4805D4DE4444001010000002FA52E19C7E555C0D40FEA2285E64440
-(1 row)
-~~~
-
-## See also
-
-- [Spatial objects](spatial-features.html#spatial-objects)
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/multipolygon.md b/src/current/v20.2/multipolygon.md
deleted file mode 100644
index 504abe21f17..00000000000
--- a/src/current/v20.2/multipolygon.md
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: MULTIPOLYGON
-summary: The spatial MULTIPOLYGON object is a collection of POLYGONs.
-toc: true
----
-
-A `MULTIPOLYGON` is a collection of [Polygons](polygon.html).  MultiPolygons are useful for gathering a group of Polygons into one geometry. For example, you may want to gather the Polygons denoting a group of properties in a particular municipality.  Another use of MultiPolygons is to represent states or countries that include islands, or that are otherwise made up of non-overlapping shapes.
-
-## Examples
-
-A MultiPolygon can be created from SQL by calling the `st_geomfromtext` function on a MultiPolygon definition expressed in the [Well Known Text (WKT)](spatial-glossary.html#wkt) format.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeomFromText('SRID=4326;MULTIPOLYGON(((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902), (-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832), (-84.191605 39.758949, -75.165222 39.952583, -78.878738 42.880230, -84.191605 39.758949)))');
-~~~
-
-~~~
-                                                                                                                                                                                                                            st_geomfromtext
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  0106000020E610000001000000010300000003000000040000006FF1F09E03FA55C0DFDFA0BDFA844540545227A089FF57C0791EDC9DB513424064B14D2A1AED52C0CCCF0D4DD90942406FF1F09E03FA55C0DFDFA0BDFA84454004000000A4A7C821E2E755C07C48F8DEDFF0444073309B00C38C56C038BF61A241504340E884D041979C54C0967A1684F2344340A4A7C821E2E755C07C48F8DEDFF044400400000001309E41430C55C07C2AA73D25E143401AA54BFF92CA52C0DFDC5F3DEEF9434028F04E3E3DB853C0A27A6B60AB70454001309E41430C55C07C2AA73D25E14340
-(1 row)
-~~~
-
-## See also
-
-- [Spatial objects](spatial-features.html#spatial-objects)
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/not-null.md b/src/current/v20.2/not-null.md
deleted file mode 100644
index 66d382ec9f0..00000000000
--- a/src/current/v20.2/not-null.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: NOT NULL constraint
-summary: The NOT NULL constraint specifies the column may not contain NULL values.
-toc: true
----
-
-The `NOT NULL` [constraint](constraints.html) specifies a column may not contain [`NULL`](null-handling.html) values.
-
-## Details
-
-- `INSERT` or `UPDATE` statements containing `NULL` values are rejected. This includes `INSERT` statements that do not include values for any columns that do not have a [`DEFAULT` value constraint](default-value.html).
-
-  For example, if the table `foo` has columns `a` and `b` (and `b` *does not* have a `DEFAULT VALUE`), when you run the following command:
-
-  ~~~ sql
-  > INSERT INTO foo (a) VALUES (1);
-  ~~~
-
-  CockroachDB tries to write a `NULL` value into column `b`. If that column has the `NOT NULL` constraint, the `INSERT` statement is rejected.
-
-- To add the `NOT NULL` constraint to an existing table column, use the [`ALTER COLUMN`](alter-column.html#set-not-null-constraint) statement.
-
-- For more information about `NULL`, see [NULL handling](null-handling.html).
-
-## Syntax
-
-You can only apply the `NOT NULL` constraint to individual columns.
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/not_null_column_level.html %}
-</div>
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table you're creating.
- `column_name` | The name of the constrained column.
- `column_type` | The constrained column's [data type](data-types.html).
- `column_constraints` | Any other column-level [constraints](constraints.html) you want to apply to this column.
- `column_def` | Definitions for any other columns in the table.
- `table_constraints` | Any table-level [constraints](constraints.html) you want to apply.
-
-## Usage example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS customers (
-    customer_id INT         PRIMARY KEY,
-    cust_name   STRING(30)  NULL,
-    cust_email  STRING(100) NOT NULL
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers (customer_id, cust_name, cust_email) VALUES (1, 'Smith', NULL);
-~~~
-
-~~~
-pq: null value in column "cust_email" violates not-null constraint
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers (customer_id, cust_name) VALUES (1, 'Smith');
-~~~
-
-~~~
-pq: null value in column "cust_email" violates not-null constraint
-~~~
-
-## See also
-
-- [Constraints](constraints.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`CHECK` constraint](check.html)
-- [`DEFAULT` constraint](default-value.html)
-- [`REFERENCES` constraint (Foreign Key)](foreign-key.html)
-- [`PRIMARY KEY` constraint](primary-key.html)
-- [`UNIQUE` constraint](unique.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`NULL HANDLING`](null-handling.html)
diff --git a/src/current/v20.2/null-handling.md b/src/current/v20.2/null-handling.md
deleted file mode 100644
index de88c81e8ea..00000000000
--- a/src/current/v20.2/null-handling.md
+++ /dev/null
@@ -1,569 +0,0 @@
----
-title: NULL Handling
-summary: Learn how NULL values are handled in CockroachDB SQL.
-toc: true
----
-
-This page summarizes how `NULL` values are handled in CockroachDB
-SQL. Each topic is demonstrated via the [built-in SQL
-client](cockroach-sql.html).
-
-{{site.data.alerts.callout_info}}
-When using the built-in client, `NULL` values are displayed using the word `NULL`. This distinguishes them from a character field that contains an empty string ("").
-{{site.data.alerts.end}}
-
-## NULLs and simple comparisons
-
-Any simple comparison between a value and `NULL` results in
-`NULL`. The remaining cases are described in the next section.
-
-This behavior is consistent with PostgreSQL as well as all other major RDBMS's.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers (customer_id, cust_name, cust_email) VALUES (1, 'Smith', NULL);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE t1(
-  a INT,
-  b INT,
-  c INT
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t1 VALUES(1, 0, 0);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t1 VALUES(2, 0, 1);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t1 VALUES(3, 1, 0);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t1 VALUES(4, 1, 1);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t1 VALUES(5, NULL, 0);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t1 VALUES(6, NULL, 1);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t1 VALUES(7, NULL, NULL);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1;
-~~~
-
-~~~
-+---+------+------+
-| a |  b   |  c   |
-+---+------+------+
-| 1 |    0 |    0 |
-| 2 |    0 |    1 |
-| 3 |    1 |    0 |
-| 4 |    1 |    1 |
-| 5 | NULL |    0 |
-| 6 | NULL |    1 |
-| 7 | NULL | NULL |
-+---+------+------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 WHERE b < 10;
-~~~
-
-~~~
-+---+---+---+
-| a | b | c |
-+---+---+---+
-| 1 | 0 | 0 |
-| 2 | 0 | 1 |
-| 3 | 1 | 0 |
-| 4 | 1 | 1 |
-+---+---+---+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 WHERE NOT b > 10;
-~~~
-
-~~~
-+---+---+---+
-| a | b | c |
-+---+---+---+
-| 1 | 0 | 0 |
-| 2 | 0 | 1 |
-| 3 | 1 | 0 |
-| 4 | 1 | 1 |
-+---+---+---+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 WHERE b < 10 OR c = 1;
-~~~
-
-~~~
-+---+------+---+
-| a |  b   | c |
-+---+------+---+
-| 1 |    0 | 0 |
-| 2 |    0 | 1 |
-| 3 |    1 | 0 |
-| 4 |    1 | 1 |
-| 6 | NULL | 1 |
-+---+------+---+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 WHERE b < 10 AND c = 1;
-~~~
-
-~~~
-+---+---+---+
-| a | b | c |
-+---+---+---+
-| 2 | 0 | 1 |
-| 4 | 1 | 1 |
-+---+---+---+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 WHERE NOT (b < 10 AND c = 1);
-~~~
-
-~~~
-+---+------+---+
-| a |  b   | c |
-+---+------+---+
-| 1 |    0 | 0 |
-| 3 |    1 | 0 |
-| 5 | NULL | 0 |
-+---+------+---+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 WHERE NOT (c = 1 AND b < 10);
-~~~
-
-~~~
-+---+------+---+
-| a |  b   | c |
-+---+------+---+
-| 1 |    0 | 0 |
-| 3 |    1 | 0 |
-| 5 | NULL | 0 |
-+---+------+---+
-~~~
-
-Use the `IS NULL` or `IS NOT NULL` clauses when checking for `NULL` values.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 WHERE b IS NULL AND c IS NOT NULL;
-~~~
-
-~~~
-+---+------+---+
-| a |  b   | c |
-+---+------+---+
-| 5 | NULL | 0 |
-| 6 | NULL | 1 |
-+---+------+---+
-~~~
-
-## NULLs and conditional operators
-
-The [conditional
-operators](scalar-expressions.html#conditional-expressions)
-(including `IF`, `COALESCE`, `IFNULL`) only evaluate some
-operands depending on the value of a condition operand, so their
-result is not always `NULL` depending on the given operands.
-
-For example, `COALESCE(1, NULL)` will always return `1` even though
-the second operand is `NULL`.
-
-## NULLs and ternary logic
-
-`AND`, `OR` and `IS` implement ternary logic, as follows.
-
-| Expression       | Result |
--------------------|---------
- `FALSE AND FALSE` | `FALSE`
- `FALSE AND TRUE`  | `FALSE`
- `FALSE AND NULL`  | `FALSE`
- `TRUE AND FALSE`  | `FALSE`
- `TRUE AND TRUE`   | `TRUE`  
- `TRUE AND NULL`   | `NULL`  
- `NULL AND FALSE`  | `FALSE`
- `NULL AND TRUE`   | `NULL`  
- `NULL AND NULL`   | `NULL`  
-
-| Expression      | Result |
-------------------|---------
- `FALSE OR FALSE` | `FALSE`
- `FALSE OR TRUE`  | `TRUE`  
- `FALSE OR NULL`  | `NULL`  
- `TRUE OR FALSE`  | `TRUE`  
- `TRUE OR TRUE`   | `TRUE`  
- `TRUE OR NULL`   | `TRUE`  
- `NULL OR FALSE`  | `NULL`  
- `NULL OR TRUE`   | `TRUE`  
- `NULL OR NULL`   | `NULL`  
-
-| Expression      | Result  |
-------------------|---------
- `FALSE IS FALSE` | `TRUE`  
- `FALSE IS TRUE`  | `FALSE`
- `FALSE IS NULL`  | `FALSE`
- `TRUE IS FALSE`  | `FALSE`
- `TRUE IS TRUE`   | `TRUE`  
- `TRUE IS NULL`   | `FALSE`
- `NULL IS FALSE`  | `FALSE`
- `NULL IS TRUE`   | `FALSE`
- `NULL IS NULL`   | `TRUE`  
-
-## NULLs and arithmetic
-
-Arithmetic operations involving a `NULL` value will yield a `NULL` result.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT a, b, c, b*0, b*c, b+c FROM t1;
-~~~
-
-~~~
-+---+------+------+-------+-------+-------+
-| a |  b   |  c   | b * 0 | b * c | b + c |
-+---+------+------+-------+-------+-------+
-| 1 |    0 |    0 |     0 |     0 |     0 |
-| 2 |    0 |    1 |     0 |     0 |     1 |
-| 3 |    1 |    0 |     0 |     0 |     1 |
-| 4 |    1 |    1 |     0 |     1 |     2 |
-| 5 | NULL |    0 | NULL  | NULL  | NULL  |
-| 6 | NULL |    1 | NULL  | NULL  | NULL  |
-| 7 | NULL | NULL | NULL  | NULL  | NULL  |
-+---+------+------+-------+-------+-------+
-~~~
-
-## NULLs and aggregate functions
-
-Aggregate [functions](functions-and-operators.html) are those that operate on a set of rows and return a single value. The example data has been repeated here to make it easier to understand the results.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1;
-~~~
-
-~~~
-+---+------+------+
-| a |  b   |  c   |
-+---+------+------+
-| 1 |    0 |    0 |
-| 2 |    0 |    1 |
-| 3 |    1 |    0 |
-| 4 |    1 |    1 |
-| 5 | NULL |    0 |
-| 6 | NULL |    1 |
-| 7 | NULL | NULL |
-+---+------+------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT COUNT(*), COUNT(b), SUM(b), AVG(b), MIN(b), MAX(b) FROM t1;
-~~~
-
-~~~
-+----------+----------+--------+--------------------+--------+--------+
-| COUNT(*) | COUNT(b) | SUM(b) |       AVG(b)       | MIN(b) | MAX(b) |
-+----------+----------+--------+--------------------+--------+--------+
-|        7 |        4 |      2 | 0.5000000000000000 |      0 |      1 |
-+----------+----------+--------+--------------------+--------+--------+
-~~~
-
-Note the following:
-
-- `NULL` values are not included in the `COUNT()` of a column. `COUNT(*)` returns 7 while `COUNT(b)` returns 4.
-
-- `NULL` values are not considered as high or low values in `MIN()` or `MAX()`.
-
-- `AVG(b)` returns `SUM(b)/COUNT(b)`, which is different than `AVG(*)` as `NULL` values are not considered in the `COUNT(b)` of rows. See [NULLs as Other Values](#nulls-as-other-values) for more details.
-
-
-## NULL as a distinct value
-
-`NULL` values are considered distinct from other values and are included in the list of distinct values from a column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT DISTINCT b FROM t1;
-~~~
-
-~~~
-+------+
-|  b   |
-+------+
-|    0 |
-|    1 |
-| NULL |
-+------+
-~~~
-
-However, counting the number of distinct values excludes `NULL`s, which is consistent with the `COUNT()` function.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT COUNT(DISTINCT b) FROM t1;
-~~~
-
-~~~
-+-------------------+
-| count(DISTINCT b) |
-+-------------------+
-|                 2 |
-+-------------------+
-~~~
-
-## NULLs as other values
-
-In some cases, you may want to include `NULL` values in arithmetic or aggregate function calculations. To do so, use the `IFNULL()` function to substitute a value for `NULL` during calculations.
-
-For example, let's say you want to calculate the average value of column `b` as being the `SUM()` of all numbers in `b` divided by the total number of rows, regardless of whether `b`'s value is `NULL`. In this case, you would use `AVG(IFNULL(b, 0))`, where `IFNULL(b, 0)` substitutes a value of zero (0) for `NULL`s during the calculation.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT COUNT(*), COUNT(b), SUM(b), AVG(b), AVG(IFNULL(b, 0)), MIN(b), MAX(b) FROM t1;
-~~~
-
-~~~
-+----------+----------+--------+--------------------+--------------------+--------+--------+
-| COUNT(*) | COUNT(b) | SUM(b) |       AVG(b)       | AVG(IFNULL(b, 0))  | MIN(b) | MAX(b) |
-+----------+----------+--------+--------------------+--------------------+--------+--------+
-|        7 |        4 |      2 | 0.5000000000000000 | 0.2857142857142857 |      0 |      1 |
-+----------+----------+--------+--------------------+--------------------+--------+--------+
-~~~
-
-## NULLs and set operations
-
-`NULL` values are considered as part of a `UNION` [set operation](selection-queries.html#set-operations).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT b FROM t1 UNION SELECT b FROM t1;
-~~~
-
-~~~
-+------+
-|  b   |
-+------+
-|    0 |
-|    1 |
-| NULL |
-+------+
-~~~
-
-
-## NULLs and sorting
-
-When [sorting a column](order-by.html) containing `NULL` values, CockroachDB sorts `NULL` values first with `ASC` and last with `DESC`. This differs from PostgreSQL, which sorts `NULL` values last with `ASC` and first with `DESC`.
-
-Note that the `NULLS FIRST` and `NULLS LAST` options of the `ORDER BY` clause are not implemented in CockroachDB, so you cannot change where `NULL` values appear in the sort order.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 ORDER BY b ASC;
-~~~
-
-~~~
-+---+------+------+
-| a |  b   |  c   |
-+---+------+------+
-| 6 | NULL |    1 |
-| 5 | NULL |    0 |
-| 7 | NULL | NULL |
-| 1 |    0 |    0 |
-| 2 |    0 |    1 |
-| 4 |    1 |    1 |
-| 3 |    1 |    0 |
-+---+------+------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1 ORDER BY b DESC;
-~~~
-
-~~~
-+---+------+------+
-| a |  b   |  c   |
-+---+------+------+
-| 4 |    1 |    1 |
-| 3 |    1 |    0 |
-| 2 |    0 |    1 |
-| 1 |    0 |    0 |
-| 7 | NULL | NULL |
-| 6 | NULL |    1 |
-| 5 | NULL |    0 |
-+---+------+------+
-~~~
-
-## NULLs and unique constraints
-
-`NULL` values are not considered unique. Therefore, if a table has a Unique constraint on one or more columns that are optional (nullable), it is possible to insert multiple rows with `NULL` values in those columns, as shown in the example below.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE t2(a INT, b INT UNIQUE);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t2 VALUES(1, 1);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t2 VALUES(2, NULL);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t2 VALUES(3, NULL);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t2;
-~~~
-
-~~~
-+---+------+
-| a |  b   |
-+---+------+
-| 1 |    1 |
-| 2 | NULL |
-| 3 | NULL |
-+---+------+
-~~~
-
-## NULLs and CHECK Constraints
-
-A [`CHECK` constraint](check.html) expression that evaluates to `NULL` is considered to pass, allowing for concise expressions like `discount < price` without worrying about adding `OR discount IS NULL` clauses. When non-null validation is desired, the usual `NOT NULL` constraint can be used along side a Check constraint.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE products (id STRING PRIMARY KEY, price INT NOT NULL CHECK (price > 0), discount INT, CHECK (discount <= price));
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO products (id, price) VALUES ('ncc-1701-d', 100);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO products (id, price, discount) VALUES ('ncc-1701-a', 100, 50);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM products;
-~~~
-
-~~~
-+----------+-------+----------+
-|    id    | price | discount |
-+----------+-------+----------+
-| ncc1701a |   100 |       50 |
-| ncc1701d |   100 | NULL     |
-+----------+-------+----------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO products (id, price) VALUES ('ncc-1701-b', -5);
-~~~
-
-~~~
-failed to satisfy CHECK constraint (price > 0)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO products (id, price, discount) VALUES ('ncc-1701-b', 100, 150);
-~~~
-
-~~~
-failed to satisfy CHECK constraint (discount <= price)
-~~~
-
-## NULLs and concatenation with other types
-
-For all values other than [`STRING`](string.html), concatenation between a non-`NULL` value and a `NULL` value results in an [`ARRAY`](array.html) of the non-`NULL` value's type.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT NULL || 1;
-~~~
-
-~~~
-  ?column?
-------------
-  {1}
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT NULL || true;
-~~~
-
-~~~
-  ?column?
-------------
-  {t}
-(1 row)
-~~~
-
-Concatenating a `STRING` value with a [`NULL` value](null-handling.html) results in a `NULL` value.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT NULL || 'item';
-~~~
-
-~~~
-  ?column?
-------------
-  NULL
-(1 row)
-~~~
diff --git a/src/current/v20.2/online-schema-changes.md b/src/current/v20.2/online-schema-changes.md
deleted file mode 100644
index a5b6d8c070e..00000000000
--- a/src/current/v20.2/online-schema-changes.md
+++ /dev/null
@@ -1,256 +0,0 @@
----
-title: Online Schema Changes
-summary: Update table schemas without external tools or downtime.
-toc: true
----
-
-CockroachDB's online schema changes provide a simple way to update a table schema without imposing any negative consequences on an application — including downtime. The schema change engine is a built-in feature requiring no additional tools, resources, or ad hoc sequencing of operations.
-
-Benefits of online schema changes include:
-
-- Changes to your table schema happen while the database is running.
-- The schema change runs as a [background job][show-jobs] without holding locks on the underlying table data.
-- Your application's queries can run normally, with no effect on read/write latency. The schema is cached for performance.
-- Your data is kept in a safe, [consistent][consistent] state throughout the entire schema change process.
-
-{{site.data.alerts.callout_danger}}
-Schema changes consume additional resources, and if they are run when the cluster is near peak capacity, latency spikes can occur. This is especially true for any schema change that adds columns, drops columns, or adds an index. We do not recommend doing more than one schema change at a time while in production.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-Support for schema changes within [transactions][txns] is [limited](#limitations). We recommend doing schema changes outside transactions where possible. When a schema management tool uses transactions on your behalf, we recommend only doing one schema change operation per transaction.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-You cannot start an online schema change on a table if a [primary key change](alter-primary-key.html) is currently in progress on the same table.
-{{site.data.alerts.end}}
-
-## How online schema changes work
-
-At a high level, online schema changes are accomplished by using a bridging strategy involving concurrent uses of multiple versions of the schema. The process is as follows:
-
-1. A user initiates a schema change by executing [`ALTER TABLE`][alter-table], [`CREATE INDEX`][create-index], [`TRUNCATE`][truncate], etc.
-
-2. The schema change engine converts the original schema to the new schema in discrete steps while ensuring that the underlying table data is always in a consistent state. These changes are executed as a [background job][show-jobs], and can be [paused](pause-job.html), [resumed](resume-job.html), and [canceled](cancel-job.html).
-
-This approach allows the schema change engine to roll out a new schema while the previous version is still in use. It then backfills or deletes the underlying table data as needed in the background, while the cluster is still running and servicing reads and writes from your application.
-
-During the backfilling process, the schema change engine updates the underlying table data to make sure all instances of the table are stored according to the requirements of the new schema.
-
-Once backfilling is complete, all nodes will switch over to the new schema, and will allow reads and writes of the table using the new schema.
-
-For more technical details, see [How online schema changes are possible in CockroachDB][blog].
-
-{{site.data.alerts.callout_info}}
-If a schema change fails, the schema change job will be cleaned up automatically. However, there are limitations with rolling back schema changes within a transaction; for more information, [see below](#schema-change-ddl-statements-inside-a-multi-statement-transaction-can-fail-while-other-statements-succeed).
-{{site.data.alerts.end}}
-
-## Examples
-
-{{site.data.alerts.callout_success}}
-For more examples of schema change statements, see the [`ALTER TABLE`][alter-table] subcommands.
-{{site.data.alerts.end}}
-
-### Run schema changes inside a transaction with `CREATE TABLE`
-
-As noted in [Limitations](#limitations), you cannot run schema changes inside transactions in general.
-
-However, as of version v2.1, you can run schema changes inside the same transaction as a [`CREATE TABLE`][create-table] statement. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-  SAVEPOINT cockroach_restart;
-  CREATE TABLE fruits (
-        id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-        name STRING,
-        color STRING
-    );
-  INSERT INTO fruits (name, color) VALUES ('apple', 'red');
-  ALTER TABLE fruits ADD COLUMN inventory_count INTEGER DEFAULT 5;
-  ALTER TABLE fruits ADD CONSTRAINT name CHECK (name IN ('apple', 'banana', 'orange'));
-  SELECT name, color, inventory_count FROM fruits;
-  RELEASE SAVEPOINT cockroach_restart;
-  COMMIT;
-~~~
-
-The transaction succeeds with the following output:
-
-~~~
-BEGIN
-SAVEPOINT
-CREATE TABLE
-INSERT 0 1
-ALTER TABLE
-ALTER TABLE
-+-------+-------+-----------------+
-| name  | color | inventory_count |
-+-------+-------+-----------------+
-| apple | red   |               5 |
-+-------+-------+-----------------+
-(1 row)
-COMMIT
-COMMIT
-~~~
-
-### Run multiple schema changes in a single `ALTER TABLE` statement
-
-As of v19.1, some schema changes can be used in combination in a single `ALTER TABLE` statement. For a list of commands that can be combined, see [`ALTER TABLE`](alter-table.html). For a demonstration, see [Add and rename columns atomically](rename-column.html#add-and-rename-columns-atomically).
-
-### Show all schema change jobs
-
-You can check on the status of the schema change jobs on your system at any time using the [`SHOW JOBS`][show-jobs] statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW JOBS] WHERE job_type = 'SCHEMA CHANGE';
-~~~
-
-~~~
-+--------------------+---------------+-----------------------------------------------------------------------------+-----------+-----------+----------------------------+----------------------------+----------------------------+----------------------------+--------------------+-------+----------------+
-|             job_id | job_type      | description                                                                 | user_name | status    | created                    | started                    | finished                   | modified                   | fraction_completed | error | coordinator_id |
-|--------------------+---------------+-----------------------------------------------------------------------------+-----------+-----------+----------------------------+----------------------------+----------------------------+----------------------------+--------------------+-------+----------------|
-| 368863345707909121 | SCHEMA CHANGE | ALTER TABLE test.public.fruits ADD COLUMN inventory_count INTEGER DEFAULT 5 | root      | succeeded | 2018-07-26 20:55:59.698793 | 2018-07-26 20:55:59.739032 | 2018-07-26 20:55:59.816007 | 2018-07-26 20:55:59.816008 |                  1 |       | NULL           |
-| 370556465994989569 | SCHEMA CHANGE | ALTER TABLE test.public.foo ADD COLUMN bar VARCHAR                          | root      | pending   | 2018-08-01 20:27:38.708813 | NULL                       | NULL                       | 2018-08-01 20:27:38.708813 |                  0 |       | NULL           |
-| 370556522386751489 | SCHEMA CHANGE | ALTER TABLE test.public.foo ADD COLUMN bar VARCHAR                          | root      | pending   | 2018-08-01 20:27:55.830832 | NULL                       | NULL                       | 2018-08-01 20:27:55.830832 |                  0 |       | NULL           |
-+--------------------+---------------+-----------------------------------------------------------------------------+-----------+-----------+----------------------------+----------------------------+----------------------------+----------------------------+--------------------+-------+----------------+
-(1 row)
-~~~
-
-All schema change jobs can be [paused](pause-job.html), [resumed](resume-job.html), and [canceled](cancel-job.html).
-
-## Undoing a schema change
-
-Prior to [garbage collection](architecture/storage-layer.html#garbage-collection), it's possible to recover data that may have been lost prior to schema changes by using the [`AS OF SYSTEM TIME`](as-of-system-time.html) parameter. However, this solution is limited in terms of time, and doesn't work beyond the designated garbage collection window.
-
-For more long-term recovery solutions, consider taking either a [full or incremental backup](take-full-and-incremental-backups.html) of your cluster.
-
-## Limitations
-
-### Overview
-
-Schema changes keep your data consistent at all times, but they do not run inside [transactions][txns] in the general case. This is necessary so the cluster can remain online and continue to service application reads and writes.
-
-Specifically, this behavior is necessary because making schema changes transactional would mean requiring a given schema change to propagate across all the nodes of a cluster. This would block all user-initiated transactions being run by your application, since the schema change would have to commit before any other transactions could make progress. This would prevent the cluster from servicing reads and writes during the schema change, requiring application downtime.
-
-### Limited support for schema changes within transactions
-
-{% include {{ page.version.version }}/known-limitations/schema-changes-within-transactions.md %}
-
-### Schema change DDL statements inside a multi-statement transaction can fail while other statements succeed
-
-{% include {{ page.version.version }}/known-limitations/schema-change-ddl-inside-multi-statement-transactions.md %}
-
-### No schema changes between executions of prepared statements
-
-{% include {{ page.version.version }}/known-limitations/schema-changes-between-prepared-statements.md %}
-
-### Examples of statements that fail
-
-The following statements fail due to [limited support for schema changes within transactions](#limited-support-for-schema-changes-within-transactions).
-
-#### Create an index and then run a select against that index inside a transaction
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE foo (id INT PRIMARY KEY, name VARCHAR);
-  BEGIN;
-  SAVEPOINT cockroach_restart;
-  CREATE INDEX foo_idx ON foo (id, name);
-  SELECT * from foo@foo_idx;
-  RELEASE SAVEPOINT cockroach_restart;
-  COMMIT;
-~~~
-
-~~~
-CREATE TABLE
-BEGIN
-SAVEPOINT
-CREATE INDEX
-ERROR:  relation "foo_idx" does not exist
-ERROR:  current transaction is aborted, commands ignored until end of transaction block
-ROLLBACK
-~~~
-
-#### Add a column and then add a constraint against that column inside a transaction
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE foo ();
-  BEGIN;
-  SAVEPOINT cockroach_restart;
-  ALTER TABLE foo ADD COLUMN bar VARCHAR;
-  ALTER TABLE foo ADD CONSTRAINT bar CHECK (foo IN ('a', 'b', 'c', 'd'));
-  RELEASE SAVEPOINT cockroach_restart;
-  COMMIT;
-~~~
-
-~~~
-CREATE TABLE
-BEGIN
-SAVEPOINT
-ALTER TABLE
-ERROR:  column "foo" not found for constraint "foo"
-ERROR:  current transaction is aborted, commands ignored until end of transaction block
-ROLLBACK
-~~~
-
-#### Add a column and then select against that column inside a transaction
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE foo ();
-  BEGIN;
-  SAVEPOINT cockroach_restart;
-  ALTER TABLE foo ADD COLUMN bar VARCHAR;
-  SELECT bar FROM foo;
-  RELEASE SAVEPOINT cockroach_restart;
-  COMMIT;
-~~~
-
-~~~
-CREATE TABLE
-BEGIN
-SAVEPOINT
-ALTER TABLE
-ERROR:  column name "bar" not found
-ERROR:  current transaction is aborted, commands ignored until end of transaction block
-ROLLBACK
-~~~
-
-## See also
-
-+ [How online schema changes are possible in CockroachDB][blog]: Blog post with more technical details about how our schema change engine works.
-+ [`ALTER DATABASE`](alter-database.html)
-+ [`ALTER INDEX`](alter-index.html)
-+ [`ALTER RANGE`](alter-range.html)
-+ [`ALTER SEQUENCE`](alter-sequence.html)
-+ [`ALTER TABLE`][alter-table]
-+ [`ALTER VIEW`](alter-view.html)
-+ [`CREATE DATABASE`](create-database.html)
-+ [`CREATE INDEX`][create-index]
-+ [`CREATE SEQUENCE`](create-sequence.html)
-+ [`CREATE TABLE`](create-table.html)
-+ [`CREATE VIEW`](create-view.html)
-+ [`DROP DATABASE`](drop-database.html)
-+ [`DROP INDEX`][drop-index]
-+ [`DROP SEQUENCE`](drop-sequence.html)
-+ [`DROP TABLE`](drop-table.html)
-+ [`DROP VIEW`](drop-view.html)
-+ [`TRUNCATE`][truncate]
-
-
-
-<!-- Reference Links -->
-
-[alter-table]: alter-table.html
-[blog]: https://cockroachlabs.com/blog/how-online-schema-changes-are-possible-in-cockroachdb/
-[consistent]: frequently-asked-questions.html#how-is-cockroachdb-strongly-consistent
-[create-index]: create-index.html
-[drop-index]: drop-index.html
-[create-table]: create-table.html
-[select]: selection-queries.html
-[show-jobs]: show-jobs.html
-[sql-client]: cockroach-sql.html
-[txns]: transactions.html
-[truncate]: truncate.html
diff --git a/src/current/v20.2/operational-faqs.md b/src/current/v20.2/operational-faqs.md
deleted file mode 100644
index 7fb89c929d2..00000000000
--- a/src/current/v20.2/operational-faqs.md
+++ /dev/null
@@ -1,143 +0,0 @@
----
-title: Operational FAQs
-summary: Get answers to frequently asked questions about operating CockroachDB.
-toc: true
-toc_not_nested: true
----
-
-## Why is my process hanging when I try to start nodes with the `--background` flag?
-
-Check whether you have previously run a multi-node cluster using the same data directory. If you have not, refer to [Troubleshoot Cluster Setup](cluster-setup-troubleshooting.html). 
-
-If you have previously started and stopped a multi-node cluster, and are now trying to bring it back up, note the following:
-
-The [`--background`](cockroach-start.html#general) flag of [`cockroach start`](cockroach-start.html) causes the `start` command to wait until the node has fully initialized and is able to start serving queries. In addition, to keep your data consistent, CockroachDB waits until a majority of nodes are running. This means that if only one node of a three-node cluster is running, that one node will not be operational. 
-
-As a result, starting nodes with the `--background` flag will cause `cockroach start` to hang until a majority of nodes are fully initialized. 
-
-To restart your cluster, you should either: 
-
-- Use multiple terminals to start multiple nodes at once.
-- Start each node in the background using your shell's functionality (e.g., `cockroach start &`) instead of using the `--background` flag.
-
-## Why is memory usage increasing despite lack of traffic?
-
-Like most databases, CockroachDB caches the most recently accessed data in memory so that it can provide faster reads, and [its periodic writes of time-series data](#why-is-disk-usage-increasing-despite-lack-of-writes) cause that cache size to increase until it hits its configured limit. For information about manually controlling the cache size, see [Recommended Production Settings](recommended-production-settings.html#cache-and-sql-memory-size).
-
-## Why is disk usage increasing despite lack of writes?
-
-The time-series data used in the [DB Console](ui-overview-dashboard.html) is stored within the cluster and accumulates for 10 days before it starts to be truncated. As a result, for the first 10 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 are not writing data to the cluster.
-
-## Can I reduce or disable the storage of time-series data?
-
-Yes, you can either [reduce the interval for time-series storage](#reduce-the-interval-for-time-series-storage) or [disable time-series storage entirely](#disable-time-series-storage-entirely).
-
-{{site.data.alerts.callout_info}}
-After reducing or disabling time-series storage, it can take up to 24 hours for time-series data to be deleted and for the change to be reflected in DB Console metrics.
-{{site.data.alerts.end}}
-
-### Reduce the interval for time-series storage
-
-By default, CockroachDB stores time-series data at 10s resolution for 10 days. This data is aggregated into time-series data at 30m resolution, which is stored for 90 days.
-
-To reduce the interval for storage of time-series data:
-
-- For data stored at 10s resolution, change the `timeseries.storage.resolution_10s.ttl` cluster setting to an [`INTERVAL`](interval.html) value less than `240h0m0s` (10 days). 
-
-  For example, to change the storage interval for time-series data at 10s resolution to 5 days, run the following [`SET CLUSTER SETTING`](set-cluster-setting.html) command:
-
-  {% include copy-clipboard.html %}
-  ~~~ sql
-  > SET CLUSTER SETTING timeseries.storage.resolution_10s.ttl = '120h0m0s';
-  ~~~
-
-  {% include copy-clipboard.html %}
-  ~~~ sql
-  > SHOW CLUSTER SETTING timeseries.storage.resolution_10s.ttl;
-  ~~~
-
-  ~~~
-    timeseries.storage.resolution_10s.ttl
-  +---------------------------------------+
-    120:00:00
-  (1 row)
-  ~~~
-
-  Note that this data is still aggregated into data at 30m resolution, which is stored for 90 days by default.
-
-- For data stored at 30m resolution, change the `timeseries.storage.resolution_30m.ttl` cluster setting to an [`INTERVAL`](interval.html) value less than `2160h0m0s` (90 days).
-
-### Disable time-series storage entirely
-
-{{site.data.alerts.callout_info}}
-Disabling time-series storage is recommended only if you exclusively use a third-party tool such as [Prometheus](monitor-cockroachdb-with-prometheus.html) for time-series monitoring. Prometheus and other such tools do not rely on CockroachDB-stored time-series data; instead, they ingest metrics exported by CockroachDB from memory and then store the data themselves.
-{{site.data.alerts.end}}
-
-To disable the storage of time-series data entirely, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING timeseries.storage.enabled = false;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING timeseries.storage.enabled;
-~~~
-
-~~~
-  timeseries.storage.enabled
-+----------------------------+
-            false
-(1 row)
-~~~
-
-If you want all existing time-series data to be deleted, also change both the `timeseries.storage.resolution_10s.ttl` and `timeseries.storage.resolution_30m.ttl` cluster settings:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING timeseries.storage.resolution_10s.ttl = '0s';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING timeseries.storage.resolution_30m.ttl = '0s';
-~~~
-
-## What happens when a node runs out of disk space?
-
-When a node runs out of disk space, it shuts down and cannot be restarted until space is freed up. To prepare for this case, place a [ballast file](cockroach-debug-ballast.html) in each node's storage directory that can be deleted to free up enough space to be able to restart the node. If you did not create a ballast file, look for other files that can be deleted, such as [log files](debug-and-error-logs.html).
-
-{{site.data.alerts.callout_info}}
-In addition to using ballast files, it is important to actively [monitor remaining disk space](monitoring-and-alerting.html#events-to-alert-on).
-{{site.data.alerts.end}}
-
-## Why would increasing the number of nodes not result in more operations per second?
-
-If queries operate on different data, then increasing the number of nodes should improve the overall throughput (transactions/second or QPS).
-
-However, if your queries operate on the same data, you may be observing transaction contention. For details, see [SQL Performance Best Practices](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-
-## Why does CockroachDB collect anonymized cluster usage details by default?
-
-Cockroach Labs collects information about CockroachDB's real-world usage to help prioritize the development of product features. We choose our default as "opt-in" to strengthen the information collected, and are careful to send only anonymous, aggregate usage statistics. For details on what information is collected and how to opt out, see [Diagnostics Reporting](diagnostics-reporting.html).
-
-## What happens when node clocks are not properly synchronized?
-
-{% include {{ page.version.version }}/faq/clock-synchronization-effects.md %}
-
-## How can I tell how well node clocks are synchronized?
-
-{% include {{ page.version.version }}/faq/clock-synchronization-monitoring.html %}
-
-You can also see these metrics in [the Clock Offset graph](ui-runtime-dashboard.html#clock-offset) on the DB Console.
-
-## How do I prepare for planned node maintenance?
-
-{% include {{ page.version.version }}/faq/planned-maintenance.md %}
-
-## See also
-
-- [Production Checklist](recommended-production-settings.html)
-- [Product FAQs](frequently-asked-questions.html)
-- [SQL FAQs](sql-faqs.html)
\ No newline at end of file
diff --git a/src/current/v20.2/orchestrate-a-local-cluster-with-kubernetes-insecure.md b/src/current/v20.2/orchestrate-a-local-cluster-with-kubernetes-insecure.md
deleted file mode 100644
index 4962c1d813e..00000000000
--- a/src/current/v20.2/orchestrate-a-local-cluster-with-kubernetes-insecure.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-title: Orchestration with Kubernetes (Insecure)
-summary: Orchestrate the deployment and management of a local cluster using Kubernetes.
-toc: true
----
-
-<div class="filters filters-big clearfix">
-  <a href="orchestrate-a-local-cluster-with-kubernetes.html"><button class="filter-button">Secure</button></a>
-  <button class="filter-button current"><strong>Insecure</strong></button>
-</div>
-
-On top of CockroachDB's built-in automation, you can use a third-party [orchestration](orchestration.html) system to simplify and automate even more of your operations, from deployment to scaling to overall cluster management.
-
-This page walks you through a simple demonstration, using the open-source [Kubernetes](http://kubernetes.io/) orchestration system. Using either the CockroachDB [Helm](https://helm.sh/) chart or a few configuration files, you'll quickly create a 3-node local cluster. You'll run some SQL commands against the cluster and then simulate node failure, watching how Kubernetes auto-restarts without the need for any manual intervention. You'll then scale the cluster with a single command before shutting the cluster down, again with a single command.
-
-{{site.data.alerts.callout_info}}
-To orchestrate a physically distributed cluster in production, see [Orchestrated Deployments](orchestration.html). To deploy a free CockroachDB {{ site.data.products.cloud }} cluster instead of running CockroachDB yourself, see the [Quickstart](../cockroachcloud/quickstart.html).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/orchestration/local-start-kubernetes.md %}
-
-## Step 2. Start CockroachDB
-
-To start your CockroachDB cluster, you can either use our StatefulSet configuration and related files directly, or you can use the [Helm](https://helm.sh/) package manager for Kubernetes to simplify the process.
-
-<div class="filters filters-big clearfix">
-    <button class="filter-button" data-scope="helm">Use Helm</button>
-    <button class="filter-button" data-scope="manual">Use Configs</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="manual">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-local-insecure.md %}
-</section>
-
-<section class="filter-content" markdown="1" data-scope="helm">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-local-helm-insecure.md %}
-</section>
-
-## Step 3. Use the built-in SQL client
-
-{% include {{ page.version.version }}/orchestration/test-cluster-insecure.md %}
-
-## Step 4. Access the DB Console
-
-{% include {{ page.version.version }}/orchestration/monitor-cluster.md %}
-
-## Step 5. Simulate node failure
-
-{% include {{ page.version.version }}/orchestration/kubernetes-simulate-failure.md %}
-
-## Step 6. Add nodes
-
-1. Use the `kubectl scale` command to add a pod for another CockroachDB node:
-
-    <section class="filter-content" markdown="1" data-scope="manual">
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl scale statefulset cockroachdb --replicas=4
-    ~~~
-
-    ~~~
-    statefulset "cockroachdb" scaled
-    ~~~
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="helm">
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl scale statefulset my-release-cockroachdb --replicas=4
-    ~~~
-
-    ~~~
-    statefulset "my-release-cockroachdb" scaled
-    ~~~
-    </section>
-
-2. Verify that the pod for a fourth node, `cockroachdb-3`, was added successfully:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods
-    ~~~
-
-    <section class="filter-content" markdown="1" data-scope="manual">
-    ~~~
-    NAME                      READY     STATUS    RESTARTS   AGE
-    cockroachdb-0             1/1       Running   0          28m
-    cockroachdb-1             1/1       Running   0          27m
-    cockroachdb-2             1/1       Running   0          10m
-    cockroachdb-3             1/1       Running   0          5s
-    example-545f866f5-2gsrs   1/1       Running   0          25m
-    ~~~
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="helm">
-    ~~~
-    NAME                                 READY     STATUS    RESTARTS   AGE
-    my-release-cockroachdb-0             1/1       Running   0          28m
-    my-release-cockroachdb-1             1/1       Running   0          27m
-    my-release-cockroachdb-2             1/1       Running   0          10m
-    my-release-cockroachdb-3             1/1       Running   0          5s
-    example-545f866f5-2gsrs              1/1       Running   0          25m
-    ~~~
-    </section>
-
-## Step 7. Remove nodes
-
-{% include {{ page.version.version }}/orchestration/kubernetes-remove-nodes-insecure.md %}
-
-## Step 8. Stop the cluster
-
-- **If you plan to restart the cluster**, use the `minikube stop` command. This shuts down the minikube virtual machine but preserves all the resources you created:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ minikube stop
-    ~~~
-
-    ~~~
-    Stopping local Kubernetes cluster...
-    Machine stopped.
-    ~~~
-
-    You can restore the cluster to its previous state with `minikube start`.
-
-- **If you do not plan to restart the cluster**, use the `minikube delete` command. This shuts down and deletes the minikube virtual machine and all the resources you created, including persistent volumes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ minikube delete
-    ~~~
-
-    ~~~
-    Deleting local Kubernetes cluster...
-    Machine deleted.
-    ~~~
-
-    {{site.data.alerts.callout_success}}To retain logs, copy them from each pod's <code>stderr</code> before deleting the cluster and all its resources. To access a pod's standard error stream, run <code>kubectl logs &lt;podname&gt;</code>.{{site.data.alerts.end}}
-
-## See also
-
-Explore other core CockroachDB benefits and features:
-
-{% include {{ page.version.version }}/misc/explore-benefits-see-also.md %}
-
-You might also want to learn how to [orchestrate a production deployment of CockroachDB with Kubernetes](orchestrate-cockroachdb-with-kubernetes.html).
diff --git a/src/current/v20.2/orchestrate-a-local-cluster-with-kubernetes.md b/src/current/v20.2/orchestrate-a-local-cluster-with-kubernetes.md
deleted file mode 100644
index e7232cbfba5..00000000000
--- a/src/current/v20.2/orchestrate-a-local-cluster-with-kubernetes.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: Orchestrate a Local Cluster with Kubernetes
-summary: Orchestrate the deployment and management of a local cluster using Kubernetes.
-toc: true
-secure: true
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Secure</strong></button>
-  <a href="orchestrate-a-local-cluster-with-kubernetes-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-On top of CockroachDB's built-in automation, you can use a third-party [orchestration](orchestration.html) system to simplify and automate even more of your operations, from deployment to scaling to overall cluster management.
-
-This page walks you through a simple demonstration, using the open-source [Kubernetes](http://kubernetes.io/) orchestration system. Using either the CockroachDB [Helm](https://helm.sh/) chart or a few configuration files, you'll quickly create a 3-node local cluster. You'll run some SQL commands against the cluster and then simulate node failure, watching how Kubernetes auto-restarts without the need for any manual intervention. You'll then scale the cluster with a single command before shutting the cluster down, again with a single command.
-
-{{site.data.alerts.callout_info}}
-To orchestrate a physically distributed cluster in production, see [Orchestrated Deployments](orchestration.html). To deploy a free CockroachDB {{ site.data.products.cloud }} cluster instead of running CockroachDB yourself, see the [Quickstart](../cockroachcloud/quickstart.html).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/orchestration/local-start-kubernetes.md %}
-
-## Step 2. Start CockroachDB
-
-Choose a way to deploy and maintain the CockroachDB cluster:
-
-- [CockroachDB Kubernetes Operator](https://github.com/cockroachdb/cockroach-operator) (recommended)
-- [Helm](https://helm.sh/) package manager
-- Manually apply our StatefulSet configuration and related files
-
-<div class="filters filters-big clearfix">
-    <button class="filter-button" data-scope="operator">Use Operator</button>
-    <button class="filter-button" data-scope="helm">Use Helm</button>
-    <button class="filter-button" data-scope="manual">Use Configs</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="operator">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-operator-secure.md %}
-</section>
-
-<section class="filter-content" markdown="1" data-scope="manual">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-secure.md %}
-</section>
-
-<section class="filter-content" markdown="1" data-scope="helm">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-helm-secure.md %}
-</section>
-
-## Step 3. Use the built-in SQL client
-
-{% include {{ page.version.version }}/orchestration/test-cluster-secure.md %}
-
-## Step 4. Access the DB Console
-
-{% include {{ page.version.version }}/orchestration/monitor-cluster.md %}
-
-## Step 5. Simulate node failure
-
-{% include {{ page.version.version }}/orchestration/kubernetes-simulate-failure.md %}
-
-## Step 6. Add nodes
-
-{% include {{ page.version.version }}/orchestration/kubernetes-scale-cluster.md %}
-
-## Step 7. Remove nodes
-
-{% include {{ page.version.version }}/orchestration/kubernetes-remove-nodes-secure.md %}
-
-## Step 8. Stop the cluster
-
-- **If you plan to restart the cluster**, use the `minikube stop` command. This shuts down the minikube virtual machine but preserves all the resources you created:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ minikube stop
-    ~~~
-
-    ~~~
-    Stopping local Kubernetes cluster...
-    Machine stopped.
-    ~~~
-
-    You can restore the cluster to its previous state with `minikube start`.
-
-- **If you do not plan to restart the cluster**, use the `minikube delete` command. This shuts down and deletes the minikube virtual machine and all the resources you created, including persistent volumes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ minikube delete
-    ~~~
-
-    ~~~
-    Deleting local Kubernetes cluster...
-    Machine deleted.
-    ~~~
-
-    {{site.data.alerts.callout_success}}To retain logs, copy them from each pod's <code>stderr</code> before deleting the cluster and all its resources. To access a pod's standard error stream, run <code>kubectl logs &lt;podname&gt;</code>.{{site.data.alerts.end}}
-
-## See also
-
-Explore other core CockroachDB benefits and features:
-
-{% include {{ page.version.version }}/misc/explore-benefits-see-also.md %}
-
-You might also want to learn how to [orchestrate a production deployment of CockroachDB with Kubernetes](orchestrate-cockroachdb-with-kubernetes.html).
diff --git a/src/current/v20.2/orchestrate-cockroachdb-with-docker-swarm-insecure.md b/src/current/v20.2/orchestrate-cockroachdb-with-docker-swarm-insecure.md
deleted file mode 100644
index ece76a73a95..00000000000
--- a/src/current/v20.2/orchestrate-cockroachdb-with-docker-swarm-insecure.md
+++ /dev/null
@@ -1,321 +0,0 @@
----
-title: Orchestrate CockroachDB with Docker Swarm
-summary: How to orchestrate the deployment and management of an insecure three-node CockroachDB cluster as a Docker swarm.
-toc: true
----
-
-<div class="filters filters-big clearfix">
-  <a href="orchestrate-cockroachdb-with-docker-swarm.html"><button class="filter-button">Secure</button></a>
-  <button class="filter-button current"><strong>Insecure</strong></button>
-</div>
-
-This page shows you how to orchestrate the deployment and management of an insecure three-node CockroachDB cluster as a [swarm of Docker Engines](https://docs.docker.com/engine/swarm/).
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-## Before you begin
-
-Before you begin, it's helpful to review some terminology:
-
-Feature | Description
---------|------------
-instance | A physical or virtual machine. In this tutorial, you'll use three, one per CockroachDB node.
-[Docker Engine](https://docs.docker.com/engine/) | This is the core Docker application that creates and runs containers. In this tutorial, you'll install and start Docker Engine on each of your three instances.
-[swarm](https://docs.docker.com/engine/swarm/key-concepts/#/swarm) | A swarm is a group of Docker Engines joined into a single, virtual host.
-[swarm node](https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/) | Each member of a swarm is considered a node. In this tutorial, each instance will be a swarm node, one as the master node and the two others as worker nodes. You'll submit service definitions to the master node, which will dispatch work to the worker nodes.
-[service](https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/) | A service is the definition of the tasks to execute on swarm nodes. In this tutorial, you'll define three services, each starting a CockroachDB node inside a container and joining it into a single cluster. Each service also ensures a stable network identity on restart via a resolvable DNS name.
-[overlay network](https://docs.docker.com/engine/userguide/networking/#/an-overlay-network-with-docker-engine-swarm-mode) | An overlay network enables communication between the nodes of a swarm. In this tutorial, you'll create an overlay network and use it in each of your services.
-
-## Step 1. Create instances
-
-Create three instances, one for each node of your cluster.
-
-- For GCE-specific instructions, read through step 2 of [Deploy CockroachDB on GCE](deploy-cockroachdb-on-google-cloud-platform-insecure.html).
-- For AWS-specific instructions, read through step 2 of [Deploy CockroachDB on AWS](deploy-cockroachdb-on-aws-insecure.html).
-
-Be sure to configure your network to allow TCP communication on these ports:
-
-- `26257` for inter-node communication (i.e., working as a cluster) and connecting with applications
-- `8080` for exposing your DB Console
-
-## Step 2. Install Docker Engine
-
-On each instance:
-
-1. [Install and start Docker Engine](https://docs.docker.com/engine/installation/).
-
-2. Confirm that the Docker daemon is running in the background:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker version
-    ~~~
-
-## Step 3. Start the swarm
-
-1. On the instance where you want to run your manager node, [initialize the swarm](https://docs.docker.com/engine/swarm/swarm-tutorial/create-swarm/).
-
-    Take note of the output for `docker swarm init` as it includes the command you'll use in the next step. It should look like this:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker swarm init --advertise-addr 10.142.0.2
-    ~~~
-
-    ~~~
-    Swarm initialized: current node (414z67gr5cgfalm4uriu4qdtm) is now a manager.
-
-    To add a worker to this swarm, run the following command:
-
-      $ docker swarm join \
-      --token SWMTKN-1-5vwxyi6zl3cc62lqlhi1jrweyspi8wblh2i3qa7kv277fgy74n-e5eg5c7ioxypjxlt3rpqorh15 \
-      10.142.0.2:2377
-
-    To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
-    ~~~
-
-2. On the other two instances, [create a worker node joined to the swarm](https://docs.docker.com/engine/swarm/swarm-tutorial/add-nodes/) by running the `docker swarm join` command in the output from step 1, for example:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker swarm join \
-         --token SWMTKN-1-5vwxyi6zl3cc62lqlhi1jrweyspi8wblh2i3qa7kv277fgy74n-e5eg5c7ioxypjxlt3rpqorh15 \
-         10.142.0.2:2377
-    ~~~
-
-    ~~~
-    This node joined a swarm as a worker.
-    ~~~
-
-3. On the instance running your manager node, verify that your swarm is running:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker node ls
-    ~~~
-
-    ~~~
-    ID                           HOSTNAME    STATUS  AVAILABILITY  MANAGER STATUS
-    414z67gr5cgfalm4uriu4qdtm *  instance-1  Ready   Active        Leader
-    ae144s35dx1p1lcegh6bblyed    instance-2  Ready   Active
-    aivjg2joxyvzvbksjsix27khy    instance-3  Ready   Active
-    ~~~
-
-## Step 4. Create an overlay network
-
-On the instance running your manager node, create an overlay network so that the containers in your swarm can talk to each other:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ sudo docker network create --driver overlay --attachable cockroachdb
-~~~
-
-The `--attachable` option enables non-swarm containers running on Docker to access services on the network, which makes the service easier to use interactively.
-
-## Step 5. Start the CockroachDB cluster
-
-1. On the instance running your manager node, create one swarm service for each CockroachDB node:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    # Start the first service:
-    $ sudo docker service create \
-    --replicas 1 \
-    --name cockroachdb-1 \
-    --hostname cockroachdb-1 \
-    --network cockroachdb \
-    --mount type=volume,source=cockroachdb-1,target=/cockroach/cockroach-data,volume-driver=local \
-    --stop-grace-period 60s \
-    --publish 8080:8080 \
-    cockroachdb/cockroach:{{page.release_info.version}} start \
-    --join=cockroachdb-1:26257,cockroachdb-2:26257,cockroachdb-3:26257 \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --logtostderr \
-    --insecure
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~
-    # Start the second service:
-    $ sudo docker service create \
-    --replicas 1 \
-    --name cockroachdb-2 \
-    --hostname cockroachdb-2 \
-    --network cockroachdb \
-    --mount type=volume,source=cockroachdb-2,target=/cockroach/cockroach-data,volume-driver=local \
-    --stop-grace-period 60s \
-    cockroachdb/cockroach:{{page.release_info.version}} start \
-    --join=cockroachdb-1:26257,cockroachdb-2:26257,cockroachdb-3:26257 \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --logtostderr \
-    --insecure
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~
-    # Start the third service:
-    $ sudo docker service create \
-    --replicas 1 \
-    --name cockroachdb-3 \
-    --hostname cockroachdb-3 \
-    --network cockroachdb \
-    --mount type=volume,source=cockroachdb-3,target=/cockroach/cockroach-data,volume-driver=local \
-    --stop-grace-period 60s \
-    cockroachdb/cockroach:{{page.release_info.version}} start \
-    --join=cockroachdb-1:26257,cockroachdb-2:26257,cockroachdb-3:26257 \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --logtostderr \
-    --insecure
-    ~~~
-
-    These commands each create a service that starts a container, joins it to the overlay network, and starts a CockroachDB node inside the container mounted to a local volume for persistent storage. Let's look at each part:
-    - `sudo docker service create`: The Docker command to create a new service.
-    - `--replicas`: The number of containers controlled by the service. Since each service will control one container running one CockroachDB node, this will always be `1`.
-    - `--name`: The name for the service.
-    - `--hostname`: The hostname of the container. It will listen for connections on this address.
-    - `--network`: The overlay network for the container to join. See [Step 4. Create an overlay network](#step-4-create-an-overlay-network) for more details.
-    - `--mount`: This flag mounts a local volume with the same name as the service. This means that data and logs for the node running in this container will be stored in `/cockroach/cockroach-data` on the instance and will be reused on restart as long as restart happens on the same instance, which is not guaranteed.
-     {{site.data.alerts.callout_info}}If you plan on replacing or adding instances, it's recommended to use remote storage instead of local disk. To do so, <a href="https://docs.docker.com/engine/reference/commandline/volume_create/">create a remote volume</a> for each CockroachDB instance using the volume driver of your choice, and then specify that volume driver instead of the <code>volume-driver=local</code> part of the command above, e.g., <code>volume-driver=gce</code> if using the <a href="https://github.com/mcuadros/gce-docker">GCE volume driver</a>.
-    - `--stop-grace-period`: This flag sets a grace period to give CockroachDB enough time to shut down gracefully, when possible.
-    - `--publish`: This flag makes the DB Console accessible at the IP of any instance running a swarm node on port `8080`. Note that, even though this flag is defined only in the first node's service, the swarm exposes this port on every swarm node using a routing mesh. See [Publishing ports](https://docs.docker.com/engine/swarm/services/#publish-ports) for more details.
-    - `cockroachdb/cockroach:{{page.release_info.version}} start ...`: The CockroachDB command to [start a node](cockroach-start.html) in the container in insecure mode and instruct other cluster members to talk to each other using their persistent network addresses, which match the services' names.
-
-2. Verify that all three services were created successfully:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker service ls
-    ~~~
-
-    ~~~
-    ID            NAME           MODE        REPLICAS  IMAGE
-    a6g0ur6857j6  cockroachdb-1  replicated  1/1       cockroachdb/cockroach:{{page.release_info.version}}
-    dr81a756gaa6  cockroachdb-2  replicated  1/1       cockroachdb/cockroach:{{page.release_info.version}}
-    il4m7op1afg9  cockroachdb-3  replicated  1/1       cockroachdb/cockroach:{{page.release_info.version}}
-    ~~~
-
-    {{site.data.alerts.callout_success}}The service definitions tell the CockroachDB nodes to log to <code>stderr</code>, so if you ever need access to a node's logs for troubleshooting, use <a href="https://docs.docker.com/engine/reference/commandline/logs/"><code>sudo docker logs &lt;container id&gt;</code></a> from the instance on which the container is running.{{site.data.alerts.end}}
-
-3. Now all the CockroachDB nodes are running, but we still have to explicitly tell them to initialize a new cluster together. To do so, use the `sudo docker run` command to run the `cockroach init` command against one of the nodes. The `cockroach init` command will initialize the cluster, bringing it into a usable state.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker run -it --rm --network=cockroachdb cockroachdb/cockroach:{{page.release_info.version}} init --host=cockroachdb-1 --insecure
-    ~~~
-
-
-## Step 6. Use the built-in SQL client
-
-1. Use the `sudo docker run` command to start a new container attached to the CockroachDB network, run the built-in SQL shell, and connect it to the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker run -it --rm --network=cockroachdb cockroachdb/cockroach:{{page.release_info.version}} sql --host=cockroachdb-1 --insecure
-    ~~~
-
-2. Create an `insecurenodetest` database:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE insecurenodetest;
-    ~~~
-
-3. Use **CTRL-D**, **CTRL-C**, or `\q` to exit the SQL shell.
-
-## Step 7. Monitor the cluster
-
-To view your cluster's DB Console, open a browser and go to `http://<any node's external IP address>:8080`.
-
-{{site.data.alerts.callout_info}}It's possible to access the DB Console from outside of the swarm because you published port <code>8080</code> externally in the first node's service definition.{{site.data.alerts.end}}
-
-On this page, verify that the cluster is running as expected:
-
-1. View **Node list** to ensure that all of your nodes successfully joined the cluster.
-
-2. Click the **Databases** tab on the left to verify that `insecurenodetest` is listed.
-
-## Step 8. Simulate node failure
-
-Since we have three service definitions, one for each node, Docker swarm will ensure that there are three nodes running at all times. If a node fails, Docker swarm will automatically create another node with the same network identity and storage.
-
-To see this in action:
-
-1. On any instance, use the `sudo docker ps` command to get the ID of the container running the CockroachDB node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker ps | grep cockroachdb
-    ~~~
-
-    ~~~
-    9539871cc769        cockroachdb/cockroach:{{page.release_info.version}}   "/cockroach/cockroach"   10 minutes ago        Up 10 minutes         8080/tcp, 26257/tcp   cockroachdb-0.1.0wigdh8lx0ylhuzm4on9bbldq
-    ~~~
-
-2. Use `sudo docker kill` to remove the container, which implicitly terminates the node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker kill 9539871cc769
-    ~~~
-
-3. Verify that the node was restarted in a new container:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker ps | grep cockroachdb
-    ~~~
-
-    ~~~
-    4a58f86e3ced        cockroachdb/cockroach:{{page.release_info.version}}   "/cockroach/cockroach"   7 seconds ago       Up 1 seconds        8080/tcp, 26257/tcp   cockroachdb-0.1.cph86kmhhcp8xzq6a1nxtk9ng
-    ~~~
-
-4. Back in the DB Console, view the **Node list** and verify that all 3 nodes are live.
-
-## Step 9. Scale the cluster
-
-To increase the number of nodes in your CockroachDB cluster:
-
-1. Create an additional instance (see [Step 1](#step-1-create-instances)).
-2. Install Docker Engine on the instance (see [Step 2](#step-2-install-docker-engine)).
-3. Join the instance to the swarm as a worker node (see [Step 3.2](#step-3-start-the-swarm)).
-4. Create a new service to start another node and join it to the CockroachDB cluster (see [Step 5.1](#step-5-start-the-cockroachdb-cluster)).
-
-## Step 10. Stop the cluster
-
-To stop the CockroachDB cluster, on the instance running your manager node, remove the services:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ sudo docker service rm cockroachdb-1 cockroachdb-2 cockroachdb-3
-~~~
-
-~~~
-cockroachdb-1
-cockroachdb-2
-cockroachdb-3
-~~~
-
-You may want to remove the persistent volumes used by the services as well. To do this, on each instance:
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Identify the name of the local volume:
-$ sudo docker volume ls
-~~~
-
-~~~
-cockroachdb-1
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Remove the local volume:
-$ sudo docker volume rm cockroachdb-1
-~~~
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/orchestrate-cockroachdb-with-docker-swarm.md b/src/current/v20.2/orchestrate-cockroachdb-with-docker-swarm.md
deleted file mode 100644
index cf497f49fe9..00000000000
--- a/src/current/v20.2/orchestrate-cockroachdb-with-docker-swarm.md
+++ /dev/null
@@ -1,565 +0,0 @@
----
-title: Orchestrate CockroachDB with Docker Swarm
-summary: How to orchestrate the deployment and management of a secure three-node CockroachDB cluster as a Docker swarm.
-toc: true
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Secure</strong></button>
-  <a href="orchestrate-cockroachdb-with-docker-swarm-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-This page shows you how to orchestrate the deployment and management of a secure three-node CockroachDB cluster as a [swarm of Docker Engines](https://docs.docker.com/engine/swarm/).
-
-If you are only testing CockroachDB, or you are not concerned with protecting network communication with TLS encryption, you can use an insecure cluster instead. Select **Insecure** above for instructions.
-
-
-## Before you begin
-
-Before you begin, it's helpful to review some terminology:
-
-Feature | Description
---------|------------
-instance | A physical or virtual machine. In this tutorial, you'll use three, one per CockroachDB node.
-[Docker Engine](https://docs.docker.com/engine/) | This is the core Docker application that creates and runs containers. In this tutorial, you'll install and start Docker Engine on each of your three instances.
-[swarm](https://docs.docker.com/engine/swarm/key-concepts/#/swarm) | A swarm is a group of Docker Engines joined into a single, virtual host.
-[swarm node](https://docs.docker.com/engine/swarm/how-swarm-mode-works/nodes/) | Each member of a swarm is considered a node. In this tutorial, each instance will be a swarm node, one as the master node and the two others as worker nodes. You'll submit service definitions to the master node, which will dispatch work to the worker nodes.
-[service](https://docs.docker.com/engine/swarm/how-swarm-mode-works/services/) | A service is the definition of the tasks to execute on swarm nodes. In this tutorial, you'll define three services, each starting a CockroachDB node inside a container and joining it into a single cluster. Each service also ensures a stable network identity on restart via a resolvable DNS name.
-[secret](https://docs.docker.com/engine/swarm/secrets/) | A secret is Docker's mechanism for managing sensitive data that a container needs at runtime. Since CockroachDB uses TLS certificates to authenticate and encrypt inter-node and client/node communication, you'll create a secret per certificate and use the secrets in your services.
-[overlay network](https://docs.docker.com/engine/userguide/networking/#/an-overlay-network-with-docker-engine-swarm-mode) | An overlay network enables communication between the nodes of a swarm. In this tutorial, you'll create an overlay network and use it in each of your services.
-
-## Step 1. Create instances
-
-Create three instances, one for each node of your cluster.
-
-- For GCE-specific instructions, read through step 2 of [Deploy CockroachDB on GCE](deploy-cockroachdb-on-google-cloud-platform-insecure.html).
-- For AWS-specific instructions, read through step 2 of [Deploy CockroachDB on AWS](deploy-cockroachdb-on-aws-insecure.html).
-
-Be sure to configure your network to allow TCP communication on these ports:
-
-- `26257` for inter-node communication (i.e., working as a cluster) and connecting with applications
-- `8080` for exposing your DB Console
-
-## Step 2. Install Docker Engine
-
-On each instance:
-
-1. [Install and start Docker Engine](https://docs.docker.com/engine/installation/).
-
-2. Confirm that the Docker daemon is running in the background:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker version
-    ~~~
-
-## Step 3. Start the swarm
-
-1. On the instance where you want to run your manager node, [initialize the swarm](https://docs.docker.com/engine/swarm/swarm-tutorial/create-swarm/).
-
-    Take note of the output for `docker swarm init` as it includes the command you'll use in the next step. It should look like this:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker swarm init --advertise-addr 10.142.0.2
-    ~~~
-
-    ~~~
-    Swarm initialized: current node (414z67gr5cgfalm4uriu4qdtm) is now a manager
-    To add a worker to this swarm, run the following command
-       $ docker swarm join \
-       --toke    SWMTKN-1-5vwxyi6zl3cc62lqlhi1jrweyspi8wblh2i3qa7kv277fgy74n-e5eg5c7ioxypjxlt3rpqorh15 \
-       10.142.0.2:237
-    To add a manager to this swarm, run 'docker swarm join-token manager' and follow the instructions.
-    ~~~
-
-2. On the other two instances, [create a worker node joined to the swarm](https://docs.docker.com/engine/swarm/swarm-tutorial/add-nodes/) by running the `docker swarm join` command in the output from step 1, for example:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker swarm join \
-          --to    SWMTKN-1-5vwxyi6zl3cc62lqlhi1jrweyspi8wblh2i3qa7kv277fgy74n-e5eg5c7ioxypjxlt3rpqorh15 \
-          10.142.0.2:2377
-    ~~~
-
-    ~~~
-    This node joined a swarm as a worker.
-    ~~~
-
-3. On the instance running your manager node, verify that your swarm is running:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker node ls
-    ~~~
-
-    ~~~
-    ID                           HOSTNAME    STATUS  AVAILABILITY  MANAGER STATUS
-    414z67gr5cgfalm4uriu4qdtm *  instance-1  Ready   Active        Leader
-    ae144s35dx1p1lcegh6bblyed    instance-2  Ready   Active
-    aivjg2joxyvzvbksjsix27khy    instance-3  Ready   Active
-    ~~~
-
-## Step 4. Create an overlay network
-
-On the instance running your manager node, create an overlay network so that the containers in your swarm can talk to each other:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ sudo docker network create --driver overlay --attachable cockroachdb
-~~~
-
-+The `--attachable` option enables non-swarm containers running on Docker to access services on the network, which makes the service easier to use interactively.
-
-## Step 5. Create security resources
-
-A secure CockroachDB cluster uses TLS certificates for encrypted inter-node and client/node authentication and communication. In this step, you'll install CockroachDB on the instance running your manager node, use the [`cockroach cert`](cockroach-cert.html) command to generate certificate authority (CA), node, and client certificate and key pairs, and use the [`docker secret create`](https://docs.docker.com/engine/reference/commandline/secret_create/) command to assign these files to Docker [secrets](https://docs.docker.com/engine/swarm/secrets/) for use by your Docker services.
-
-1. On the instance running your manager node, install CockroachDB from our latest binary:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Get the latest CockroachDB tarball:
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Extract the binary:
-    $ tar -xzf cockroach-{{ page.release_info.version }}.linux-amd64.tgz  \
-    --strip=1 cockroach-{{ page.release_info.version }}.linux-amd64/cockroach
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Move the binary:
-    $ sudo mv cockroach /usr/local/bin/
-    ~~~
-
-2. Create a `certs` directory and a safe directory to keep your CA key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir my-safe-directory
-    ~~~
-
-3. Create the CA certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-ca \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ls certs
-    ~~~
-
-    ~~~
-    ca.crt
-    ~~~
-
-4. Create a Docker secret for the `ca.crt` file using the [`docker secret create`](https://docs.docker.com/engine/reference/commandline/secret_create/) command:
-
-    {{site.data.alerts.callout_danger}}Store the <code>ca.key</code> file somewhere safe and keep a backup; if you lose it, you will not be able to add new nodes or clients to your cluster.{{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create ca-crt certs/ca.crt
-    ~~~
-
-    This command assigns a name to the secret (`ca-crt`) and identifies the location of the cockroach-generated CA certificate file. You can use a different secret name, if you like, but be sure to reference the correct name when starting the CockroachDB nodes in the next step.
-
-5. Create the certificate and key for the first node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    cockroachdb-1 \
-    localhost \
-    127.0.0.1 \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ls certs
-    ~~~
-
-    ~~~
-    ca.crt
-    node.crt
-    node.key
-    ~~~
-
-    This command issues the certificate/key pair to the service name you will use for the node later (`cockroachdb-1`) as well as to local addresses that will make it easier to run the built-in SQL shell and other CockroachDB client commands in the same container as the node.
-
-6. Create Docker secrets for the first node's certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create cockroachdb-1-crt certs/node.crt
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create cockroachdb-1-key certs/node.key
-    ~~~
-
-    Again, these commands assign names to the secrets (`cockroachdb-1-crt` and `cockroachdb-1-key`) and identify the location of the cockroach-generated certificate and key files.
-
-7. Create the certificate and key for the second node, using the `--overwrite` flag to replace the files created for the first node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node --overwrite \
-    cockroachdb-2 \
-    localhost \
-    127.0.0.1 \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ls certs
-    ~~~
-
-    ~~~
-    ca.crt
-    node.crt
-    node.key
-    ~~~
-
-8. Create Docker secrets for the second node's certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create cockroachdb-2-crt certs/node.crt
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create cockroachdb-2-key certs/node.key
-    ~~~
-
-9. Create the certificate and key for the third node, again using the `--overwrite` flag to replace the files created for the second node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node --overwrite \
-    cockroachdb-3 \
-    localhost \
-    127.0.0.1 \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ls certs
-    ~~~
-
-    ~~~
-    ca.crt
-    node.crt
-    node.key
-    ~~~
-
-10. Create Docker secrets for the third node's certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create cockroachdb-3-crt certs/node.crt
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create cockroachdb-3-key certs/node.key
-    ~~~
-
-11. Create a client certificate and key for the `root` user:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-client \
-    root \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-12. Create Docker secrets for the `root` user's certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create cockroachdb-root-crt certs/client.root.crt
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker secret create cockroachdb-root-key certs/client.root.key
-    ~~~
-
-## Step 6. Start the CockroachDB cluster
-
-1. On the instance running your manager node, create one swarm service for each CockroachDB node:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    # Create the first service:
-    $ sudo docker service create \
-    --replicas 1 \
-    --name cockroachdb-1 \
-    --hostname cockroachdb-1 \
-    --network cockroachdb \
-    --mount type=volume,source=cockroachdb-1,target=/cockroach/cockroach-data,volume-driver=local \
-    --stop-grace-period 60s \
-    --publish 8080:8080 \
-    --secret source=ca-crt,target=ca.crt \
-    --secret source=cockroachdb-1-crt,target=node.crt \
-    --secret source=cockroachdb-1-key,target=node.key,mode=0600 \
-    --secret source=cockroachdb-root-crt,target=client.root.crt \
-    --secret source=cockroachdb-root-key,target=client.root.key,mode=0600 \
-    cockroachdb/cockroach:{{page.release_info.version}} start \
-    --join=cockroachdb-1:26257,cockroachdb-2:26257,cockroachdb-3:26257 \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --logtostderr \
-    --certs-dir=/run/secrets
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~
-    # Create the second service:
-    $ sudo docker service create \
-    --replicas 1 \
-    --name cockroachdb-2 \
-    --hostname cockroachdb-2 \
-    --network cockroachdb \
-    --stop-grace-period 60s \
-    --mount type=volume,source=cockroachdb-2,target=/cockroach/cockroach-data,volume-driver=local \
-    --secret source=ca-crt,target=ca.crt \
-    --secret source=cockroachdb-2-crt,target=node.crt \
-    --secret source=cockroachdb-2-key,target=node.key,mode=0600 \
-    --secret source=cockroachdb-root-crt,target=client.root.crt \
-    --secret source=cockroachdb-root-key,target=client.root.key,mode=0600 \
-    cockroachdb/cockroach:{{page.release_info.version}} start \
-    --join=cockroachdb-1:26257,cockroachdb-2:26257,cockroachdb-3:26257 \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --logtostderr \
-    --certs-dir=/run/secrets
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~
-    # Create the third service:
-    $ sudo docker service create \
-    --replicas 1 \
-    --name cockroachdb-3 \
-    --hostname cockroachdb-3 \
-    --network cockroachdb \
-    --mount type=volume,source=cockroachdb-3,target=/cockroach/cockroach-data,volume-driver=local \
-    --stop-grace-period 60s \
-    --secret source=ca-crt,target=ca.crt \
-    --secret source=cockroachdb-3-crt,target=node.crt \
-    --secret source=cockroachdb-3-key,target=node.key,mode=0600 \
-    --secret source=cockroachdb-root-crt,target=client.root.crt \
-    --secret source=cockroachdb-root-key,target=client.root.key,mode=0600 \
-    cockroachdb/cockroach:{{page.release_info.version}} start \
-    --join=cockroachdb-1:26257,cockroachdb-2:26257,cockroachdb-3:26257 \
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --logtostderr \
-    --certs-dir=/run/secrets
-    ~~~
-
-    These commands each create a service that starts a container securely, joins it to the overlay network, and starts a CockroachDB node inside the container mounted to a local volume for persistent storage. Let's look at each part:
-    - `sudo docker service create`: The Docker command to create a new service.
-    - `--replicas`: The number of containers controlled by the service. Since each service will control one container running one CockroachDB node, this will always be `1`.
-    - `--name`: The name for the service.
-    - `--hostname`: The hostname of the container. It will listen for connections on this address.
-    - `--network`: The overlay network for the container to join. See [Step 4. Create an overlay network](#step-4-create-an-overlay-network) for more details.
-    - `--mount`: This flag mounts a local volume with the same name as the service. This means that data and logs for the node running in this container will be stored in `/cockroach/cockroach-data` on the instance and will be reused on restart as long as restart happens on the same instance, which is not guaranteed.
-    {{site.data.alerts.callout_info}}If you plan on replacing or adding instances, it's recommended to use remote storage instead of local disk. To do so, <a href="https://docs.docker.com/engine/reference/commandline/volume_create/">create a remote volume</a> for each CockroachDB instance using the volume driver of your choice, and then specify that volume driver instead of the <code>volume-driver=local</code> part of the command above, e.g., <code>volume-driver=gce</code> if using the <a href="https://github.com/mcuadros/gce-docker">GCE volume driver</a>.{{site.data.alerts.end}}
-    - `--stop-grace-period`: This flag sets a grace period to give CockroachDB enough time to shut down gracefully, when possible.
-    - `--publish`: This flag makes the DB Console accessible at the IP of any instance running a swarm node on port `8080`. Note that, even though this flag is defined only in the first node's service, the swarm exposes this port on every swarm node using a routing mesh. See [Publishing ports](https://docs.docker.com/engine/swarm/services/#publish-ports) for more details.
-    - `--secret`: These flags identify the secrets to use in securing the node. They must reference the secret names defined in step 5. For the node and client certificate and key secrets, the `source` field identifies the relevant secret, and the `target` field defines the name to be used in `cockroach start` and `cockroach sql` flags. For the node and client key secrets, the `mode` field also sets the file permissions to `0600`; if this isn't set, Docker will assign a default file permission of `0444`, which will not work with CockroachDB's built-in SQL client.
-    - `cockroachdb/cockroach:{{page.release_info.version}} start ...`: The CockroachDB command to [start a node](cockroach-start.html) in the container in insecure mode and instruct other cluster members to talk to each other using their persistent network addresses, which match the services' names.
-
-2. Verify that all three services were created successfully:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker service ls
-    ~~~
-
-    ~~~
-    ID            NAME           MODE        REPLICAS  IMAGE
-    a6g0ur6857j6  cockroachdb-1  replicated  1/1       cockroachdb/cockroach:{{page.release_info.version}}
-    dr81a756gaa6  cockroachdb-2  replicated  1/1       cockroachdb/cockroach:{{page.release_info.version}}
-    il4m7op1afg9  cockroachdb-3  replicated  1/1       cockroachdb/cockroach:{{page.release_info.version}}
-    ~~~
-
-    {{site.data.alerts.callout_success}}The service definitions tell the CockroachDB nodes to log to <code>stderr</code>, so if you ever need access to a node's logs for troubleshooting, use <a href="https://docs.docker.com/engine/reference/commandline/logs/"><code>sudo docker logs &lt;container id&gt;</code></a> from the instance on which the container is running.{{site.data.alerts.end}}
-
-3. Now all the CockroachDB nodes are running, but we still have to explicitly tell them to initialize a new cluster together. To do so, use the `sudo docker run` command to run the `cockroach init` command against one of the nodes. The `cockroach init` command will initialize the cluster, bringing it into a usable state.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker run -it --rm --network cockroachdb --mount type=bind,source="$(pwd)/certs",target=/cockroach/certs,readonly cockroachdb/cockroach:{{page.release_info.version}} init --host=cockroachdb-1 --certs-dir=certs
-    ~~~
-
-    We mount the `certs` directory as a volume inside the container because it contains the `root` user's client certificate and key, which we need to talk to the cluster.
-
-## Step 7. Use the built-in SQL client
-
-1. Use the `sudo docker run` command to start a new container attached to the CockroachDB network, run the built-in SQL shell, and connect it to the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker run -it --rm --network cockroachdb --mount type=bind,source="$(pwd)/certs",target=/cockroach/certs,readonly cockroachdb/cockroach:{{page.release_info.version}} sql --host=cockroachdb-1 --certs-dir=certs
-    ~~~
-
-2. Create a `securenodetest` database:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE securenodetest;
-    ~~~
-
-3. [Create a user with a password](create-user.html#create-a-user-with-a-password).
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER roach WITH PASSWORD 'Q7gc8rEdS';
-    ~~~
-
-  You will need this username and password to access the DB Console in Step 8.
-
-4. Use **CTRL-D**, **CTRL-C**, or `\q` to exit the SQL shell.
-
-## Step 8. Monitor the cluster
-
-To access your cluster's DB Console:
-
-1. Open a browser and go to `https://<any node's external IP address>:8080`.
-{{site.data.alerts.callout_info}}It's possible to access the DB Console from outside of the swarm because you published port <code>8080</code> externally in the first node's service definition. However, your browser will consider the CockroachDB-created certificate invalid, so you’ll need to click through a warning message to get to the UI.{{site.data.alerts.end}}
-
-2. On accessing the DB Console, you will see a Login screen, where you will need to enter your username and password created in Step 7.
-
-3. On the DB Console, verify that the cluster is running as expected:
-
-  1. View **Node List** to ensure that all of your nodes successfully joined the cluster.
-
-  2. Click the **Databases** tab on the left to verify that `securenodetest` is listed.
-
-## Step 9. Simulate node failure
-
-Since we have three service definitions, one for each node, Docker Swarm will ensure that there are three nodes running at all times. If a node fails, Docker Swarm will automatically create another node with the same network identity and storage.
-
-To see this in action:
-
-1. On any instance, use the `sudo docker ps` command to get the ID of the container running the CockroachDB node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker ps | grep cockroachdb
-    ~~~
-
-    ~~~
-    32769a6dd664        cockroachdb/cockroach:{{page.release_info.version}}   "/cockroach/cockroach"   10 minutes ago        Up 10 minutes         8080/tcp, 26257/tcp   cockroachdb-2.1.0wigdh8lx0ylhuzm4on9bbldq
-    ~~~
-
-2. Use `sudo docker kill` to remove the container, which implicitly terminates the node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker kill <container ID>
-    ~~~
-
-3. Verify that the node was restarted in a new container:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo docker ps | grep cockroachdb
-    ~~~
-
-    ~~~
-    4a58f86e3ced        cockroachdb/cockroach:{{page.release_info.version}}   "/cockroach/cockroach"   7 seconds ago       Up 1 seconds        8080/tcp, 26257/tcp   cockroachdb-2.1.cph86kmhhcp8xzq6a1nxtk9ng
-    ~~~
-
-4. Back in the DB Console, view **Node List** and verify that all 3 nodes are live.
-
-## Step 10. Scale the cluster
-
-To increase the number of nodes in your CockroachDB cluster:
-
-1. Create an additional instance (see [Step 1](#step-1-create-instances)).
-2. Install Docker Engine on the instance (see [Step 2](#step-2-install-docker-engine)).
-3. Join the instance to the swarm as a worker node (see [Step 3.2](#step-3-start-the-swarm)).
-4. Create security resources for the node (see [Step 5.7 and 5.8](#step-5-create-security-resources)).
-5. Create a new service to start another node and join it to the CockroachDB cluster (see [Step 6.1](#step-6-start-the-cockroachdb-cluster)).
-
-## Step 11. Stop the cluster
-
-To stop the CockroachDB cluster, on the instance running your manager node, remove the services:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ sudo docker service rm cockroachdb-1 cockroachdb-2 cockroachdb-3
-~~~
-
-~~~
-cockroachdb-1
-cockroachdb-2
-cockroachdb-3
-~~~
-
-You may want to remove the persistent volumes and secrets used by the services as well. To do this, on each instance:
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Identify the name of the local volume:
-$ sudo docker volume ls
-~~~
-
-~~~
-cockroachdb-1
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Remove the local volume:
-$ sudo docker volume rm cockroachdb-1
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Identify the name of secrets:
-$ sudo docker secrets ls
-~~~
-
-~~~
-ca-crt
-cockroachdb-1-crt
-cockroachdb-1-key
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-# Remove the secrets:
-$ sudo docker secret rm ca-crt cockroachdb-1-crt cockroachdb-1-key
-~~~
-
-## See also
-
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes-insecure.md b/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes-insecure.md
deleted file mode 100644
index 5427a963a95..00000000000
--- a/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes-insecure.md
+++ /dev/null
@@ -1,180 +0,0 @@
----
-title: Orchestrate CockroachDB in a Single Kubernetes Cluster (Insecure)
-summary: How to orchestrate the deployment, management, and monitoring of an insecure 3-node CockroachDB cluster with Kubernetes.
-toc: true
-toc_not_nested: true
-canonical: /stable/deploy-cockroachdb-with-kubernetes-insecure
----
-
-<div class="filters filters-big clearfix">
-  <a href="orchestrate-cockroachdb-with-kubernetes.html"><button class="filter-button">Secure</button></a>
-  <button class="filter-button current"><strong>Insecure</strong></button>
-</div>
-
-This page shows you how to orchestrate the deployment, management, and monitoring of an insecure 3-node CockroachDB cluster in a single [Kubernetes](http://kubernetes.io/) cluster, using the [StatefulSet](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) feature directly or via the [Helm](https://helm.sh/) Kubernetes package manager.
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-To deploy across multiple Kubernetes clusters in different geographic regions instead, see [Kubernetes Multi-Cluster Deployment](orchestrate-cockroachdb-with-kubernetes-multi-cluster.html). Also, for details about potential performance bottlenecks to be aware of when running CockroachDB in Kubernetes and guidance on how to optimize your deployment for better performance, see [CockroachDB Performance on Kubernetes](kubernetes-performance.html).
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-Before getting started, it's helpful to review some Kubernetes-specific terminology and current limitations.
-
-- [Kubernetes terminology](#kubernetes-terminology)
-- [Limitations](#limitations)
-
-### Kubernetes terminology
-
-Feature | Description
---------|------------
-[node](https://kubernetes.io/docs/concepts/architecture/nodes/) | A physical or virtual machine. In this tutorial, you'll create GCE or AWS instances and join them as worker nodes into a single Kubernetes cluster from your local workstation.
-[pod](http://kubernetes.io/docs/user-guide/pods/) | A pod is a group of one or more Docker containers. In this tutorial, each pod will run on a separate Kubernetes node and include one Docker container running a single CockroachDB node. You'll start with 3 pods and grow to 4.
-[StatefulSet](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) | A StatefulSet is a group of pods treated as stateful units, where each pod has distinguishable network identity and always binds back to the same persistent storage on restart. StatefulSets are considered stable as of Kubernetes version 1.9 after reaching beta in version 1.5.
-[persistent volume](http://kubernetes.io/docs/user-guide/persistent-volumes/) | A persistent volume is a piece of networked storage (Persistent Disk on GCE, Elastic Block Store on AWS) mounted into a pod. The lifetime of a persistent volume is decoupled from the lifetime of the pod that's using it, ensuring that each CockroachDB node binds back to the same storage on restart.<br><br>This tutorial assumes that dynamic volume provisioning is available. When that is not the case, [persistent volume claims](http://kubernetes.io/docs/user-guide/persistent-volumes/#persistentvolumeclaims) need to be created manually.
-
-### Limitations
-
-{% include {{ page.version.version }}/orchestration/kubernetes-limitations.md %}
-
-## Step 1. Start Kubernetes
-
-{% include {{ page.version.version }}/orchestration/start-kubernetes.md %}
-
-## Step 2. Start CockroachDB
-
-To start your CockroachDB cluster, you can either use our StatefulSet configuration and related files directly, or you can use the [Helm](https://helm.sh/) package manager for Kubernetes to simplify the process.
-
-<div class="filters filters-big clearfix">
-    <button class="filter-button" data-scope="helm">Use Helm</button>
-    <button class="filter-button" data-scope="manual">Use Configs</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="manual">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-insecure.md %}
-</section>
-
-<section class="filter-content" markdown="1" data-scope="helm">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-helm-insecure.md %}
-</section>
-
-## Step 3. Use the built-in SQL client
-
-{% include {{ page.version.version }}/orchestration/test-cluster-insecure.md %}
-
-## Step 4. Access the DB Console
-
-{% include {{ page.version.version }}/orchestration/monitor-cluster.md %}
-
-## Step 5. Simulate node failure
-
-{% include {{ page.version.version }}/orchestration/kubernetes-simulate-failure.md %}
-
-## Step 6. Monitor the cluster
-
-{% include {{ page.version.version }}/orchestration/kubernetes-prometheus-alertmanager.md %}
-
-## Step 7. Maintain the cluster
-
-- [Add nodes](#add-nodes)
-- [Remove nodes](#remove-nodes)
-- [Expand disk size](#expand-disk-size)
-- [Upgrade the cluster](#upgrade-the-cluster)
-- [Stop the cluster](#stop-the-cluster)
-
-### Add nodes
-
-{% include {{ page.version.version }}/orchestration/kubernetes-scale-cluster.md %}
-
-### Remove nodes
-
-{% include {{ page.version.version }}/orchestration/kubernetes-remove-nodes-insecure.md %}
-
-### Expand disk size
-
-{% include {{ page.version.version }}/orchestration/kubernetes-expand-disk-size.md %}
-
-### Upgrade the cluster
-
-{% include {{ page.version.version }}/orchestration/kubernetes-upgrade-cluster.md %}
-
-### Stop the cluster
-
-To shut down the CockroachDB cluster:
-
-1. Delete the resources you created, including the logs:
-
-    {{site.data.alerts.callout_danger}}
-    This does not include deleting the persistent volumes that were attached to the pods. If you want to delete the persistent volumes and free up the storage used by CockroachDB, be sure you have a backup copy of your data. Data **cannot** be recovered once the persistent volumes are deleted. For more information, see the [Kubernetes documentation](https://kubernetes.io/docs/tasks/run-application/delete-stateful-set/#persistent-volumes).
-    {{site.data.alerts.end}}
-
-    <section class="filter-content" markdown="1" data-scope="manual">
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete pods,statefulsets,services,poddisruptionbudget,jobs,rolebinding,clusterrolebinding,role,clusterrole,serviceaccount,alertmanager,prometheus,prometheusrule,serviceMonitor -l app=cockroachdb
-    ~~~
-
-    ~~~
-    pod "cockroachdb-0" deleted
-    pod "cockroachdb-1" deleted
-    pod "cockroachdb-2" deleted
-    pod "cockroachdb-3" deleted
-    service "alertmanager-cockroachdb" deleted
-    service "cockroachdb" deleted
-    service "cockroachdb-public" deleted
-    poddisruptionbudget "cockroachdb-budget" deleted
-    job "cluster-init" deleted
-    clusterrolebinding "prometheus" deleted
-    clusterrole "prometheus" deleted
-    serviceaccount "prometheus" deleted
-    alertmanager "cockroachdb" deleted
-    prometheus "cockroachdb" deleted
-    prometheusrule "prometheus-cockroachdb-rules" deleted
-    servicemonitor "cockroachdb" deleted
-    ~~~
-    </section>
-
-    <section class="filter-content" markdown="1" data-scope="helm">
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ helm uninstall my-release
-    ~~~
-
-    ~~~
-    release "my-release" deleted
-    ~~~
-    </section>
-
-2. Stop Kubernetes:
-    - Hosted GKE:
-
-        {% include copy-clipboard.html %}
-        ~~~ shell
-        $ gcloud container clusters delete cockroachdb --region {region-name}
-        ~~~
-    - Hosted EKS:
-
-        {% include copy-clipboard.html %}
-        ~~~ shell
-        $ eksctl delete cluster --name cockroachdb
-        ~~~
-    - Manual GCE:
-
-        {% include copy-clipboard.html %}
-        ~~~ shell
-        $ cluster/kube-down.sh
-        ~~~
-    - Manual AWS:
-
-        {% include copy-clipboard.html %}
-        ~~~ shell
-        $ cluster/kube-down.sh
-        ~~~
-
-## See also
-
-- [Kubernetes Multi-Cluster Deployment](orchestrate-cockroachdb-with-kubernetes-multi-cluster.html)
-- [Kubernetes Performance Guide](kubernetes-performance.html)
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md b/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md
deleted file mode 100644
index 19ffef6d26f..00000000000
--- a/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md
+++ /dev/null
@@ -1,1290 +0,0 @@
----
-title: Orchestrate CockroachDB Across Multiple Kubernetes Clusters
-summary: Orchestrate the deployment, management, and monitoring of CockroachDB across multiple Kubernetes clusters in different regions.
-toc: true
-toc_not_nested: true
----
-
-<div class="filters filters-big clearfix">
-    <button class="filter-button" data-scope="gke">GKE</button>
-    <button class="filter-button" data-scope="eks">EKS</button>
-</div>
-
-This page shows you how to orchestrate a secure CockroachDB deployment across three [Kubernetes](http://kubernetes.io/) clusters, each in a different geographic region, using [StatefulSets](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) to manage the containers within each cluster and linking them together via DNS. This will result in a single, multi-region CockroachDB cluster running on Kubernetes.
-
-{{site.data.alerts.callout_success}}
-To deploy CockroachDB in a single Kubernetes cluster instead, see [Kubernetes Single-Cluster Deployment](orchestrate-cockroachdb-with-kubernetes.html). Also, for details about potential performance bottlenecks to be aware of when running CockroachDB in Kubernetes and guidance on how to optimize your deployment for better performance, see [CockroachDB Performance on Kubernetes](kubernetes-performance.html).
-{{site.data.alerts.end}}
-
-## Before you begin
-
-Before getting started, it's helpful to review some Kubernetes-specific terminology and current limitations.
-
-- [Kubernetes terminology](#kubernetes-terminology)
-- [UX differences from running in a single cluster](#ux-differences-from-running-in-a-single-cluster)
-- [Limitations](#limitations)
-
-### Kubernetes terminology
-
-Feature | Description
---------|------------
-[node](https://kubernetes.io/docs/concepts/architecture/nodes/) | A physical or virtual machine. In this tutorial, you'll run GKE or EKS instances and join them as worker nodes in three independent Kubernetes clusters, each in a different region.
-[pod](http://kubernetes.io/docs/user-guide/pods/) | A pod is a group of one or more Docker containers. In this tutorial, each pod will run on a separate GKE or EKS instance and include one Docker container running a single CockroachDB node. You'll start with 3 pods in each region and grow to 4.
-[StatefulSet](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) | A group of pods treated as stateful units, where each pod has distinguishable network identity and always binds back to the same persistent storage on restart. StatefulSets are considered stable as of Kubernetes version 1.9 after reaching beta in version 1.5.
-[persistent volume](http://kubernetes.io/docs/user-guide/persistent-volumes/) | A piece of networked storage (Persistent Disk on GCE, Elastic Block Store on AWS) mounted into a pod. The lifetime of a persistent volume is decoupled from the lifetime of the pod that's using it, ensuring that each CockroachDB node binds back to the same storage on restart.<br><br>This tutorial assumes that dynamic volume provisioning is available. When that is not the case, [persistent volume claims](http://kubernetes.io/docs/user-guide/persistent-volumes/#persistentvolumeclaims) need to be created manually.
-[CSR](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/) | A CSR, or certificate signing request, is a request to have a TLS certificate verified by a certificate authority (CA). A CSR is issued for the CockroachDB node running in each pod, as well as each client as it connects to the Kubernetes cluster.
-[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) | RBAC, or role-based access control, is the system Kubernetes uses to manage permissions within the cluster. In order to take an action (e.g., `get` or `create`) on an API resource (e.g., a `pod`), the client must have a `Role` that allows it to do so.
-[namespace](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/) | A namespace provides a scope for resources and names within a Kubernetes cluster. Names of resources must be unique within a namespace, but not across namespaces. Most Kubernetes client commands will use the `default` namespace by default, but can operate on resources in other namespaces as well. In this tutorial, CockroachDB pods will be deployed in their own namespace in each Kubernetes cluster.
-[kubectl](https://kubernetes.io/docs/reference/kubectl/overview/) | `kubectl` is the command-line interface for running commands against Kubernetes clusters.
-[kubectl context](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#kubectl-context-and-configuration) | When multiple Kubernetes clusters are deployed on your account, `kubectl` "context" specifies a cluster to connect to.
-
-### UX differences from running in a single cluster
-
-These instructions create 3 StatefulSets that each run 3 CockroachDB pods in a separate Kubernetes cluster deployed in its own region. If you haven't often worked with multiple Kubernetes clusters, remember that `kubectl` commands are run against a cluster in a specific context. Either run `kubectl use-context <cluster-context>` frequently to switch contexts between commands, or append `--context <cluster-context>` to the commands you run to ensure they are run against the correct cluster.
-
-<section class="filter-content" markdown="1" data-scope="gke">
-Each Kubernetes cluster's DNS server is pointed at the other clusters' DNS servers so that DNS lookups for certain zone-scoped suffixes (e.g., `*.us-west1-a.svc.cluster.local`) can be deferred to the appropriate cluster's DNS server. To make this work, we create the StatefulSets in namespaces named after the region in which each Kubernetes cluster is deployed. To run a command against one of the pods, append `--namespace <cluster-namespace>` to your commands. Alternatively, run `kubectl config set-context <context-name> --namespace <namespace-name>` to set the default namespace for a context.
-
-Because the CockroachDB pods run in a non-default namespace, client applications wanting to talk to CockroachDB from the default namespace would need to use a zone-scoped service name (e.g., `cockroachdb-public.us-west1-a`) rather than `cockroachdb-public`, as in a single-cluster setting. However, the setup script used by these instructions sets up an additional [`ExternalName` service](https://kubernetes.io/docs/concepts/services-networking/service/#externalname) in the default namespace such that the clients in the default namespace can simply talk to the `cockroachdb-public` address.
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-To enable the pods to communicate across regions, we peer the VPCs in all 3 regions with each other and configure a CoreDNS service in each region to route DNS traffic to the appropriate pods. To make this work, we create the StatefulSets in namespaces named after the region in which each Kubernetes cluster is deployed. To run a command against one of the pods, append `--namespace <cluster-namespace>` to your commands. Alternatively, run `kubectl config set-context <context-name> --namespace <namespace-name>` to set the default namespace for a context.
-</section>
-
-### Limitations
-
-{% include {{ page.version.version }}/orchestration/kubernetes-limitations.md %}
-
-<section class="filter-content" markdown="1" data-scope="gke">
-#### Exposing DNS servers
-
-{{site.data.alerts.callout_danger}}
-Until December 2019, Google Cloud Platform restricted clients to using a load balancer in the same region. In the approach documented below, the DNS servers from each Kubernetes cluster are hooked together by exposing them via a load balanced IP address that is visible to the public Internet. None of the services in your Kubernetes cluster will be accessible publicly, but their names could leak out to a motivated attacker.
-
-You can now [enable global access](https://cloud.google.com/load-balancing/docs/internal/setting-up-internal#ilb-global-access) on Google Cloud Platform to allow clients from one region to use an internal load balancer in another. We will update this tutorial accordingly.
-{{site.data.alerts.end}}
-</section>
-
-## Step 1. Start Kubernetes clusters
-
-Our multi-region deployment approach relies on pod IP addresses being routable across three distinct Kubernetes clusters and regions. Both the hosted Google Kubernetes Engine (GKE) and Amazon Elastic Kubernetes Service (EKS) satisfy this requirement.
-
-If you want to run on another cloud or on-premises, use this [basic network test](https://github.com/cockroachdb/cockroach/tree/master/cloud/kubernetes/multiregion#pod-to-pod-connectivity) to see if it will work.
-
-<section class="filter-content" markdown="1" data-scope="gke">
-1. Complete the **Before You Begin** steps described in the [Google Kubernetes Engine Quickstart](https://cloud.google.com/kubernetes-engine/docs/quickstart) documentation.
-
-    This includes installing `gcloud`, which is used to create and delete Kubernetes Engine clusters, and `kubectl`, which is the command-line tool used to manage Kubernetes from your workstation.
-
-    {{site.data.alerts.callout_success}}The documentation offers the choice of using Google's Cloud Shell product or using a local shell on your machine. Choose to use a local shell if you want to be able to view the DB Console using the steps in this guide.{{site.data.alerts.end}}
-
-1. From your local workstation, start the first Kubernetes cluster, specifying the [zone](https://cloud.google.com/compute/docs/regions-zones/) it should run in:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud container clusters create cockroachdb1 --zone=<gce-zone>
-    ~~~
-
-    ~~~
-    Creating cluster cockroachdb1...done.
-    ~~~
-
-    This creates GKE instances in the zone specified and joins them into a single Kubernetes cluster named `cockroachdb1`.
-
-    {{site.data.alerts.callout_info}}
-    The process can take a few minutes, so do not move on to the next step until you see a `Creating cluster cockroachdb1...done` message and details about your cluster.
-    {{site.data.alerts.end}}
-
-1. Start the second Kubernetes cluster, specifying the [zone](https://cloud.google.com/compute/docs/regions-zones/) it should run in:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud container clusters create cockroachdb2 --zone=<gce-zone>
-    ~~~
-
-    ~~~
-    Creating cluster cockroachdb2...done.
-    ~~~
-
-1. Start the third Kubernetes cluster, specifying the [zone](https://cloud.google.com/compute/docs/regions-zones/) it should run in:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud container clusters create cockroachdb3 --zone=<gce-zone>
-    ~~~
-
-    ~~~
-    Creating cluster cockroachdb3...done.
-    ~~~
-
-1. Get the `kubectl` "contexts" for your clusters:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl config get-contexts
-    ~~~
-
-    ~~~
-    CURRENT   NAME                                                  CLUSTER                                               AUTHINFO                                              NAMESPACE
-    *         gke_cockroach-shared_us-east1-b_cockroachdb1          gke_cockroach-shared_us-east1-b_cockroachdb1          gke_cockroach-shared_us-east1-b_cockroachdb1
-              gke_cockroach-shared_us-west1-a_cockroachdb2          gke_cockroach-shared_us-west1-a_cockroachdb2          gke_cockroach-shared_us-west1-a_cockroachdb2
-              gke_cockroach-shared_us-central1-a_cockroachdb3       gke_cockroach-shared_us-central1-a_cockroachdb3       gke_cockroach-shared_us-central1-a_cockroachdb3                        
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    `kubectl` commands are run against the `CURRENT` context by default. You can change the current context with this command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    kubectl config use-context <context-name>
-    ~~~
-
-    When sending commands to another context, you need to use the `--context` flag to specify the context. For clarity, every `kubectl` command in this tutorial uses the `--context` flag to indicate the proper context.
-    {{site.data.alerts.end}}
-
-1. Get the email address associated with your Google Cloud account:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud info | grep Account
-    ~~~
-
-    ~~~
-    Account: [your.google.cloud.email@example.org]
-    ~~~
-
-    {{site.data.alerts.callout_danger}}
-    This command returns your email address in all lowercase. However, in the next step, you must enter the address using the accurate capitalization. For example, if your address is YourName@example.com, you must use YourName@example.com and not yourname@example.com.
-    {{site.data.alerts.end}}
-
-1. For each Kubernetes cluster, [create the RBAC roles](https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control#prerequisites_for_using_role-based_access_control) CockroachDB needs for running on GKE, using the email address and relevant "context" name from the previous steps:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create clusterrolebinding $USER-cluster-admin-binding --clusterrole=cluster-admin --user=<your.google.cloud.email@example.org> --context <cluster-context-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create clusterrolebinding $USER-cluster-admin-binding --clusterrole=cluster-admin --user=<your.google.cloud.email@example.org> --context <cluster-context-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create clusterrolebinding $USER-cluster-admin-binding --clusterrole=cluster-admin --user=<your.google.cloud.email@example.org> --context <cluster-context-3>
-    ~~~
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-1. Complete the steps described in the [EKS Getting Started](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html) documentation.
-
-    This includes installing and configuring the AWS CLI and `eksctl`, which is the command-line tool used to create and delete Kubernetes clusters on EKS, and `kubectl`, which is the command-line tool used to manage Kubernetes from your workstation.
-
-1. From your local workstation, create three Kubernetes clusters. For each cluster, specify a unique region and a **non-overlapping** IP range for the VPC in CIDR notation (e.g., 10.0.0.0/16). Refer to the AWS documentation for valid [regions](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions) and [CIDR blocks](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Subnets.html#VPC_Sizing).
-
-    {{site.data.alerts.callout_danger}}
-    In order to enable VPC peering between the regions, the CIDR blocks of the VPCs **must not** overlap. This value cannot change once the cluster has been created, so be sure that your IP ranges do not overlap.
-    {{site.data.alerts.end}}
-
-    {{site.data.alerts.callout_success}}
-    To ensure that all 3 nodes can be placed into a different availability zone, you may want to first [confirm that at least 3 zones are available in the region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#availability-zones-describe) for your account.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ eksctl create cluster \
-    --name cockroachdb1 \
-    --nodegroup-name standard-workers \
-    --node-type m5.xlarge \
-    --nodes 3 \
-    --node-ami auto \
-    --region <aws-region-1> \
-    --vpc-cidr <ip-range-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ eksctl create cluster \
-    --name cockroachdb2 \
-    --nodegroup-name standard-workers \
-    --node-type m5.xlarge \
-    --nodes 3 \
-    --node-ami auto \
-    --region <aws-region-2> \
-    --vpc-cidr <ip-range-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ eksctl create cluster \
-    --name cockroachdb3 \
-    --nodegroup-name standard-workers \
-    --node-type m5.xlarge \
-    --nodes 3 \
-    --node-ami auto \
-    --region <aws-region-3> \
-    --vpc-cidr <ip-range-3>
-    ~~~
-
-    Each command creates three EKS instances in a region, one for each CockroachDB node you will deploy. Note that each instance is assigned to a different availability zone in the region.
-
-    In each region, the EKS instances are joined into a separate Kubernetes cluster: `cockroachdb1`, `cockroachdb2`, and `cockroachdb3`. The `--node-type` flag tells the node pool to use the [`m5.xlarge`](https://aws.amazon.com/ec2/instance-types/) instance type (4 vCPUs, 16 GB memory), which meets our [recommended CPU and memory configuration](recommended-production-settings.html#basic-hardware-recommendations).
-
-    {{site.data.alerts.callout_info}}
-    Cluster provisioning usually takes between 10 and 15 minutes. Do not move on to the next step until you see a message like `[✔]  EKS cluster "cockroachdb1" in "us-east-1" region is ready` for each cluster.
-    {{site.data.alerts.end}}
-
-1. Open the [Amazon EC2 console](https://console.aws.amazon.com/ec2/) and verify that three instances, using the node group name you specified, are running in each region. You will need to toggle between each region in the console.
-
-1. Get the context name for each of the 3 regions. When running `kubectl` commands against each region's cluster, you will need to specify the context name for that region.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl config get-contexts
-    ~~~
-
-    ~~~
-    CURRENT   NAME                                           CLUSTER                               AUTHINFO                                       NAMESPACE
-    *         maxroach@cockroachdb1.eu-central-1.eksctl.io   cockroachdb1.eu-central-1.eksctl.io   maxroach@cockroachdb1.eu-central-1.eksctl.io
-              maxroach@cockroachdb2.ca-central-1.eksctl.io   cockroachdb2.ca-central-1.eksctl.io   maxroach@cockroachdb2.ca-central-1.eksctl.io
-              maxroach@cockroachdb3.eu-north-1.eksctl.io     cockroachdb3.eu-north-1.eksctl.io     maxroach@cockroachdb3.eu-north-1.eksctl.io
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    `kubectl` commands are run against the "current" context by default. You can change the current context with `kubectl config use-context <context-name>`.
-
-    When running commands on another region, you need to use the `--context` flag to specify that region's context. For clarity, every `kubectl` command in this tutorial uses the `--context` flag to indicate the proper context.
-    {{site.data.alerts.end}}
-
-1. Create three namespaces, one corresponding to each region. The CockroachDB cluster in each region will run in this namespace.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    kubectl create namespace <cluster-namespace> --context <cluster-context>
-    ~~~
-
-    It's simplest for the namespace and region to have the same name, e.g.:
-
-    ~~~ shell
-    kubectl create namespace eu-central-1 --context maxroach@cockroachdb1.eu-central-1.eksctl.io
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    `kubectl` commands are run against the namespace named `default` by default. You can change the default namespace for a given context with `kubectl config set-context <context-name> --namespace <namespace-name>`.
-
-    For clarity, every `kubectl` command in this tutorial uses the `--namespace` flag to indicate the proper namespace.
-    {{site.data.alerts.end}}
-
-## Step 2. Configure your network
-
-### Set up VPC peering
-
-For pods to communicate across three separate Kubernetes clusters, the VPCs in all regions need to be peered. Network traffic can then be routed between the VPCs. For more information about VPC peering, see the [AWS documentation](https://docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html).
-
-1. Open the [Amazon VPC console](https://console.aws.amazon.com/vpc/) and note the ID of the VPC in each region. The VPC ID is found in the section called Your VPCs.
-
-1. Navigate to the Peering Connections section and [create a VPC peering connection](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html#create-vpc-peering-connection-local) between each of the 3 regions. When you create a peering connection, you will first select a requester VPC in the current region and then an accepter VPC in another region, specified by pasting the VPC ID.
-
-    {{site.data.alerts.callout_success}}
-    You need to create a total of 3 VPC peering connections between your 3 VPCs, which means switching regions at least once in the console. For example, if you are deploying in `eu-central-1`, `eu-north-1`, and `ca-central-1`, you can select `eu-central-1` in the console and create VPC peering connections to both `eu-north-1` and `ca-central-1`. Then switch to either `eu-north-1` or `ca-central-1` to create the VPC peering connection between those two regions.
-    {{site.data.alerts.end}}
-
-1. To complete the VPC peering connections, switch to each destination region and [accept the pending connection](https://docs.aws.amazon.com/vpc/latest/peering/create-vpc-peering-connection.html#accept-vpc-peering-connection) in the VPC console.
-
-1. For all 3 regions, navigate to the Route Tables section and find `PublicRouteTable`. [Update this route table](https://docs.aws.amazon.com/vpc/latest/peering/vpc-peering-routing.html) with 2 new entries that point traffic to the other 2 peered VPCs. The **Destination** should be the CIDR block of a destination region, and the **Target** should be the VPC peering connection between the current and the destination region.
-
-### Create inbound rules
-
-For each region, navigate to the Security Groups section of the [Amazon EC2 console](https://console.aws.amazon.com/ec2/) and locate the security group that enables communication between nodes in the cluster. It should have a name like `ClusterSharedNodeSecurityGroup`. [Add Custom TCP inbound rules](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) to this security group to allow TCP communication on two ports:
-
-- `26257` for inter-node and client-node communication. This enables the nodes to work as a cluster, the load balancer to route traffic to the nodes, and applications to connect to the load balancer.
-- `8080` for exposing the DB Console to the user, and for routing the load balancer to the health check endpoint.
-
-{{site.data.alerts.callout_info}}
-Remember to create these inbound rules in all 3 regions. This enables CockroachDB to communicate across each Kubernetes cluster.
-{{site.data.alerts.end}}
-
-#### Inter-region communication
-
- Field | Value
--------|-------------------
-Port Range | **26257**
-Source | The IP range of each region's VPC in CIDR notation (e.g., 10.12.0.0/16)
-
-This important rule enables node communication between Kubernetes clusters in different regions. You need to create a separate rule for each region in your deployment.
-
-{% include {{ page.version.version }}/prod-deployment/aws-inbound-rules.md %}
-
-### Set up load balancing
-
-The Kubernetes cluster in each region needs to have a [Network Load Balancer](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html) pointed at its CoreDNS service, which you will configure in the next step.
-
-1. Upload our load balancer manifest [`dns-lb-eks.yaml`](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/multiregion/eks/dns-lb-eks.yaml) to the Kubernetes clusters in all 3 regions:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    kubectl apply -f https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/multiregion/eks/dns-lb-eks.yaml --context <cluster-context-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    kubectl apply -f https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/multiregion/eks/dns-lb-eks.yaml --context <cluster-context-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    kubectl apply -f https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/multiregion/eks/dns-lb-eks.yaml --context <cluster-context-3>
-    ~~~
-
-    You should see the load balancer appear in the Load Balancers section of the EC2 console in each region. This load balancer will route traffic to CoreDNS in the region.
-
-1. For each region, navigate to the Load Balancer section of the [EC2 console](https://console.aws.amazon.com/ec2/) and get the DNS name of the Network Load Balancer you created in the previous step.
-
-1. For each region's load balancer, look up the IP addresses mapped to the load balancer's DNS name:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    dig <nlb-dns-name>
-    ~~~
-
-    ~~~
-    ...
-
-    ;; ANSWER SECTION:
-    ac63a423fbf6231cba51235e1e51e6ec-132cf6c423e67123.elb.eu-central-1.amazonaws.com. 60 IN A ip1
-    ac63a423fbf6231cba51235e1e51e6ec-132cf6c423e67123.elb.eu-central-1.amazonaws.com. 60 IN A ip2
-    ac63a423fbf6231cba51235e1e51e6ec-132cf6c423e67123.elb.eu-central-1.amazonaws.com. 60 IN A ip3
-
-    ...
-    ~~~
-
-    `ip1`, `ip2`, and `ip3` correspond to the 3 availability zones in the region where Network Load Balancers have been set up. You will need these IP addresses when configuring your network in the next step.
-
-### Configure CoreDNS
-
-Each Kubernetes cluster has a [CoreDNS](https://coredns.io/) service that responds to DNS requests for pods in its region. CoreDNS can also forward DNS requests to pods in other regions.
-
-To enable traffic forwarding to CockroachDB pods in all 3 regions, you need to [modify the ConfigMap](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#coredns-configmap-options) for the CoreDNS Corefile in each region.
-
-1. Download and open our ConfigMap template [`configmap.yaml`](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/multiregion/eks/configmap.yaml):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    curl -O https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/multiregion/eks/configmap.yaml
-    ~~~
-
-1. After [obtaining the IP addresses of EKS instances](#set-up-load-balancing) in all 3 regions, you can use this information to define a **separate ConfigMap for each region**. Each unique ConfigMap lists the forwarding addresses for the pods in the 2 other regions.
-
-    ~~~
-    ...
-       region2.svc.cluster.local:53 {       # <---- Modify
-           log
-           errors
-           ready
-           cache 10
-           forward . ip1 ip2 ip3 {      # <---- Modify
-                force_tcp
-           }
-       }
-       region3.svc.cluster.local:53 {       # <---- Modify
-           log
-           errors
-           ready
-           cache 10
-           forward . ip1 ip2 ip3 {      # <---- Modify
-                force_tcp
-           }
-       }
-    ~~~
-
-    For each region, modify `configmap.yaml` by replacing:
-
-    <ul><li><code>region2</code> and <code>region3</code> with the namespaces in which the CockroachDB pods will run in the other 2 regions. You defined these namespaces after <a href="#step-1-start-kubernetes-clusters">starting the Kubernetes clusters</a>.</li><li><code>ip1</code>, <code>ip2</code>, and <code>ip3</code> with the IP addresses of the Network Load Balancers in the region, which you looked up in the previous step.</li></ul>
-
-    You will end up with 3 different ConfigMaps. Give each ConfigMap a unique filename like `configmap-1.yaml`.
-
-    {{site.data.alerts.callout_info}}
-    If you configure your Network Load Balancer to support UDP traffic, you can drop the `force_tcp` line.
-    {{site.data.alerts.end}}
-
-1. For each region, first back up the existing ConfigMap:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    kubectl -n kube-system get configmap coredns -o yaml > <configmap-backup-name>
-    ~~~
-
-    Then apply the new ConfigMap:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    kubectl apply -f <configmap-name> --context <cluster-context>
-    ~~~
-
-1. For each region, check that your CoreDNS settings were applied:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    kubectl get -n kube-system cm/coredns --export -o yaml --context <cluster-context>
-    ~~~
-
-### Exclude VPCs from SNAT
-
-You will need to tell AWS to exclude your VPCs from [source network address translation (SNAT)](https://docs.aws.amazon.com/eks/latest/userguide/external-snat.html). This ensures that cross-VPC traffic is handled correctly by AWS while still allowing access to the public internet from the pods.
-
-Set `AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS` to recognize the values of your 3 CIDR blocks. Do this for all 3 regions:
-
-{% include copy-clipboard.html %}
-~~~
-kubectl set env ds aws-node -n kube-system AWS_VPC_K8S_CNI_EXCLUDE_SNAT_CIDRS="cidr1,cidr2,cidr3" --context <cluster-context>
-~~~
-
-Remember that these are the CIDR blocks you chose when [starting your Kubernetes clusters](#step-1-start-kubernetes-clusters). You can also get the IP range of a VPC by opening the [Amazon VPC console](https://console.aws.amazon.com/vpc/) and finding the VPC listed in the section called Your VPCs.
-
-{{site.data.alerts.callout_info}}
-If you plan to run your instances exclusively on private subnets, set the following environment variable instead on each region: <code style="white-space:pre-line">kubectl set env ds aws-node -n kube-system AWS_VPC_K8S_CNI_EXTERNALSNAT=true --context \<cluster-context\></code>
-{{site.data.alerts.end}}
-</section>
-
-<section class="filter-content" markdown="1" data-scope="gke">
-## Step 2. Start CockroachDB
-
-1. Create a directory and download the required script and configuration files into it:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir multiregion
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cd multiregion
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl -OOOOOOOOO \
-    https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/multiregion/{README.md,client-secure.yaml,cluster-init-secure.yaml,cockroachdb-statefulset-secure.yaml,dns-lb.yaml,example-app-secure.yaml,external-name-svc.yaml,setup.py,teardown.py}
-    ~~~
-
-2. Retrieve the `kubectl` "contexts" for your clusters:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl config get-contexts
-    ~~~
-
-    At the top of the `setup.py` script, fill in the `contexts` map with the zones of your clusters and their "context" names, e.g.:
-
-    ~~~
-    contexts = {
-        'us-east1-b': 'gke_cockroach-shared_us-east1-b_cockroachdb1',
-        'us-west1-a': 'gke_cockroach-shared_us-west1-a_cockroachdb2',
-        'us-central1-a': 'gke_cockroach-shared_us-central1-a_cockroachdb3',
-    }
-    ~~~
-
-3. In the `setup.py` script, fill in the `regions` map with the zones and corresponding regions of your clusters, for example:
-
-    ~~~
-    $ regions = {
-        'us-east1-b': 'us-east1',
-        'us-west1-a': 'us-west1',
-        'us-central1-a': 'us-central1',
-    }
-    ~~~
-
-    Setting `regions` is optional, but recommended, because it improves CockroachDB's ability to diversify data placement if you use more than one zone in the same region. If you aren't specifying regions, just leave the map empty.
-
-4. If you haven't already, [install CockroachDB locally and add it to your `PATH`](install-cockroachdb.html). The `cockroach` binary will be used to generate certificates.
-
-    If the `cockroach` binary is not on your `PATH`, in the `setup.py` script, set the `cockroach_path` variable to the path to the binary.
-
-5. Optionally, to optimize your deployment for better performance, review [CockroachDB Performance on Kubernetes](kubernetes-performance.html) and make the desired modifications to the `cockroachdb-statefulset-secure.yaml` file.
-
-6. Run the `setup.py` script:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ python setup.py
-    ~~~
-
-    As the script creates various resources and creates and initializes the CockroachDB cluster, you'll see a lot of output, eventually ending with `job "cluster-init-secure" created`.
-
-7. Confirm that the CockroachDB pods in each cluster say `1/1` in the `READY` column, indicating that they've successfully joined the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods --selector app=cockroachdb --all-namespaces --context <cluster-context-1>
-    ~~~
-
-    ~~~
-    NAMESPACE    NAME            READY     STATUS    RESTARTS   AGE
-    us-east1-b   cockroachdb-0   1/1       Running   0          14m
-    us-east1-b   cockroachdb-1   1/1       Running   0          14m
-    us-east1-b   cockroachdb-2   1/1       Running   0          14m    
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods --selector app=cockroachdb --all-namespaces --context <cluster-context-2>
-    ~~~
-
-    ~~~
-    NAMESPACE       NAME            READY     STATUS    RESTARTS   AGE
-    us-central1-a   cockroachdb-0   1/1       Running   0          14m
-    us-central1-a   cockroachdb-1   1/1       Running   0          14m
-    us-central1-a   cockroachdb-2   1/1       Running   0          14m
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods --selector app=cockroachdb --all-namespaces --context <cluster-context-3>
-    ~~~
-
-    ~~~
-    NAMESPACE    NAME            READY     STATUS    RESTARTS   AGE
-    us-west1-a   cockroachdb-0   1/1       Running   0          14m
-    us-west1-a   cockroachdb-1   1/1       Running   0          14m
-    us-west1-a   cockroachdb-2   1/1       Running   0          14m
-    ~~~    
-
-    If you notice that only one of the Kubernetes clusters' pods are marked as `READY`, you likely also need to configure a network firewall rule that will allow the pods in the different clusters to talk to each other. You can run the following command to create a firewall rule allowing traffic on port 26257 (the port used by CockroachDB for inter-node traffic) within your private GCE network. It will not allow any traffic in from outside your private network:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud compute firewall-rules create allow-cockroach-internal --allow=tcp:26257 --source-ranges=10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
-    ~~~
-
-    ~~~
-    Creating firewall...done.
-    NAME                      NETWORK  DIRECTION  PRIORITY  ALLOW      DENY
-    allow-cockroach-internal  default  INGRESS    1000      tcp:26257
-    ~~~
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-## Step 3. Start CockroachDB
-
-### Generate certificates
-
-{{site.data.alerts.callout_info}}
-Amazon EKS does not support certificates signed by Kubernetes' built-in CA. The below steps use [`cockroach cert` commands](cockroach-cert.html) to quickly generate and sign the CockroachDB node and client certificates. Read our [Authentication](authentication.html#using-digital-certificates-with-cockroachdb) docs to learn about other methods of signing certificates.
-{{site.data.alerts.end}}
-
-1. Create two directories:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs my-safe-directory
-    ~~~
-
-    Directory | Description
-    ----------|------------
-    `certs` | You'll generate your CA certificate and all node and client certificates and keys in this directory.
-    `my-safe-directory` | You'll generate your CA key in this directory and then reference the key when generating node and client certificates.
-
-1. Create the CA certificate and key pair:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-ca \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-1. Create a client certificate and key pair for the root user:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-client \
-    root \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-1. For all 3 regions, upload the client certificate and key to the Kubernetes cluster as a secret.
-
-    {{site.data.alerts.callout_success}}
-    Specify the namespace in which the CockroachDB pods will run. You defined these namespaces after [starting your Kubernetes clusters](#step-1-start-kubernetes-clusters).
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create secret \
-    generic cockroachdb.client.root \
-    --from-file=certs \
-    --context <cluster-context-1> \
-    --namespace <cluster-namespace-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create secret \
-    generic cockroachdb.client.root \
-    --from-file=certs \
-    --context <cluster-context-2> \
-    --namespace <cluster-namespace-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create secret \
-    generic cockroachdb.client.root \
-    --from-file=certs \
-    --context <cluster-context-3> \
-    --namespace <cluster-namespace-3>
-    ~~~
-
-1. Create the certificate and key pair for your CockroachDB nodes in one region, substituting `<cluster-namespace>` in this command with the appropriate namespace:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    localhost 127.0.0.1 \
-    cockroachdb-public \
-    cockroachdb-public.<cluster-namespace> \
-    cockroachdb-public.<cluster-namespace>.svc.cluster.local \
-    *.cockroachdb \
-    *.cockroachdb.<cluster-namespace> \
-    *.cockroachdb.<cluster-namespace>.svc.cluster.local \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-1. Upload the node certificate and key to the Kubernetes cluster as a secret, specifying the appropriate context and namespace:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create secret \
-    generic cockroachdb.node \
-    --from-file=certs
-    --context <cluster-context> \
-    --namespace <cluster-namespace>    
-    ~~~
-
-1. Repeat the previous 2 steps for your 2 remaining regions. You may need to delete the local `node.crt` and `node.key` in your `certs` directory before generating a new node certificate and key pair.
-
-1. For all 3 regions, check that the secrets were created on the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get secrets --context <cluster-context>
-    ~~~
-
-    ~~~
-    NAME                      TYPE                                  DATA   AGE
-    cockroachdb-token-db5wp   kubernetes.io/service-account-token   3      1m
-    cockroachdb.client.root   Opaque                                5      1m
-    cockroachdb.node          Opaque                                6      1m
-    default-token-65489       kubernetes.io/service-account-token   3      5m
-    ~~~
-
-### Create StatefulSets
-
-1. Download and open our [multi-region StatefulSet configuration](https://github.com/cockroachdb/cockroach/blob/master/cloud/kubernetes/multiregion/eks/cockroachdb-statefulset-secure-eks.yaml). You'll save three versions of this file locally, one for each set of 3 CockroachDB nodes per region.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl -O https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/multiregion/eks/cockroachdb-statefulset-secure-eks.yaml
-    ~~~
-
-    Look for **TODO** comments in the file. These highlight fields you need to define before deploying your StatefulSet.
-
-1. Fill in the namespace where CockroachDB nodes will run in region 1.
-
-    ~~~
-    namespace: <cluster-namespace>
-    ~~~
-
-1. Allocate a memory request and limit to CockroachDB on each pod, using the `resources` object in the CockroachDB `containers` spec.
-
-    {{site.data.alerts.callout_success}}
-    These values should be appropriate for the instances that you have provisioned. Run `kubectl describe nodes` to see the available resources.
-    {{site.data.alerts.end}}
-
-    For example, to allocate 8Gi of memory to CockroachDB in each pod:
-
-    ~~~
-    resources:
-      requests:
-        memory: "8Gi"
-      limits:
-        memory: "8Gi"
-    ~~~
-
-    {{site.data.alerts.callout_danger}}
-    If you do not specify a memory request, no memory will be allocated to CockroachDB. If you do not specify a memory limit, the Kubernetes scheduler will allocate the maximum possible amount.
-    {{site.data.alerts.end}}
-
-1. The StatefulSet configuration includes a [`cockroach start`](cockroach-start.html) command that creates the nodes on the Kubernetes pods.
-
-    In the `--locality` flag, name `region` after region 1. This can technically be an arbitrary value, but it's simplest to use the CockroachDB namespace in region 1.
-
-    ~~~
-    --locality=region=<cluster-namespace-1>,az=$(cat /etc/cockroach-env/zone),dns=$(hostname -f)
-    ~~~
-
-    In the `--join` flag, update the Cockroach node addresses in all 3 regions with their corresponding namespaces.
-
-    ~~~
-    --join cockroachdb-0.cockroachdb.<cluster-namespace-1>,cockroachdb-1.cockroachdb.<cluster-namespace-1>,cockroachdb-2.cockroachdb.<cluster-namespace-1>,cockroachdb-0.cockroachdb.<cluster-namespace-2>,cockroachdb-1.cockroachdb.<cluster-namespace-2>,cockroachdb-2.cockroachdb.<cluster-namespace-2>,cockroachdb-0.cockroachdb.<cluster-namespace-3>,cockroachdb-1.cockroachdb.<cluster-namespace-3>,cockroachdb-2.cockroachdb.<cluster-namespace-3>
-    ~~~
-
-1. Save this StatefulSet configuration, giving it a filename like `cockroachdb-statefulset-secure-eks-1.yaml`.
-
-1. Create and save a StatefulSet configuration for each of the other 2 regions in the same way, being sure to use the correct namespaces for those regions in steps 2 and 4.
-
-1. Deploy the StatefulSets in each of your 3 regions:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create -f <statefulset-1> --context <cluster-context-1> --namespace <cluster-namespace-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create -f <statefulset-2> --context <cluster-context-2> --namespace <cluster-namespace-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create -f <statefulset-3> --context <cluster-context-3> --namespace <cluster-namespace-3>
-    ~~~
-
-1. Run `cockroach init` on one of the pods to complete the node startup process and have them join together as a cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~
-    kubectl exec \
-    --context <cluster-context> \
-    --namespace <cluster-namespace> \
-    -it cockroachdb-0 \
-    -- /cockroach/cockroach init \
-    --certs-dir=/cockroach/cockroach-certs
-    ~~~
-
-    ~~~
-    Cluster successfully initialized
-    ~~~
-
-1. Confirm that cluster initialization has completed successfully in each region. The job should be considered successful and the Kubernetes pods should soon be considered `Ready`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods --context <cluster-context> --namespace <cluster-namespace>
-    ~~~
-
-    ~~~
-    NAMESPACE      NAME           READY   STATUS    RESTARTS   AGE
-    eu-central-1   cockroachdb-0  1/1     Running   0          12m
-    eu-central-1   cockroachdb-1  1/1     Running   0          12m
-    eu-central-1   cockroachdb-2  1/1     Running   0          12m
-    ~~~
-</section>
-
-{{site.data.alerts.callout_success}}
-In each Kubernetes cluster, the StatefulSet configuration sets all CockroachDB nodes to write to `stderr`, so if you ever need access to a pod/node's logs to troubleshoot, use `kubectl logs <podname> --context <cluster-context> --namespace <cluster-namespace>` rather than checking the log on the persistent volume.
-{{site.data.alerts.end}}
-
-<section class="filter-content" markdown="1" data-scope="gke">
-## Step 3. Use the built-in SQL client
-
-1. Use the `client-secure.yaml` file to launch a pod and keep it running indefinitely, specifying the context of the Kubernetes cluster to run it in:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl create -f client-secure.yaml --context <cluster-context>
-    ~~~
-
-    ~~~
-    pod "cockroachdb-client-secure" created
-    ~~~
-
-    The pod uses the `root` client certificate created earlier by the `setup.py` script. Note that this will work from any of the three Kubernetes clusters as long as you use the correct namespace and context combination.
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-## Step 4. Use the built-in SQL client
-
-1. Use the `client-secure.yaml` file to launch a pod and keep it running indefinitely, specifying the context of the Kubernetes cluster and namespace of the CockroachDB pods to run it in:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    kubectl create -f https://raw.githubusercontent.com/cockroachdb/cockroach/master/cloud/kubernetes/multiregion/client-secure.yaml --context <cluster-context> --namespace <cluster-namespace>
-    ~~~
-
-    ~~~
-    pod "cockroachdb-client-secure" created
-    ~~~
-
-    The pod uses the `root` client certificate you [generated earlier](#generate-certificates). Note that this will work from any of the three Kubernetes clusters as long as you use the correct namespace and context combination.
-</section>
-
-1. Get a shell into the pod and start the CockroachDB [built-in SQL client](cockroach-sql.html), again specifying the namespace and context of the Kubernetes cluster where the pod is running:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl exec -it cockroachdb-client-secure --context <cluster-context> --namespace <cluster-namespace> -- ./cockroach sql --certs-dir=/cockroach-certs --host=cockroachdb-public
-    ~~~
-
-    ~~~
-    # Welcome to the cockroach SQL interface.
-    # All statements must be terminated by a semicolon.
-    # To exit: CTRL + D.
-    #
-    # Server version: CockroachDB CCL v2.0.5 (x86_64-unknown-linux-gnu, built 2018/08/13 17:59:42, go1.10) (same version as client)
-    # Cluster ID: 99346e82-9817-4f62-b79b-fdd5d57f8bda
-    #
-    # Enter \? for a brief introduction.
-    #
-    warning: no current database set. Use SET database = <dbname> to change, CREATE DATABASE to make a new database.
-    root@cockroachdb-public:26257/>
-    ~~~
-
-1. Run some basic [CockroachDB SQL statements](learn-cockroachdb-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE bank;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE bank.accounts (id INT PRIMARY KEY, balance DECIMAL);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO bank.accounts VALUES (1, 1000.50);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.accounts;
-    ~~~
-
-    ~~~
-    +----+---------+
-    | id | balance |
-    +----+---------+
-    |  1 |  1000.5 |
-    +----+---------+
-    (1 row)
-    ~~~
-
-1. [Create a user with a password](create-user.html#create-a-user-with-a-password):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER roach WITH PASSWORD 'Q7gc8rEdS';
-    ~~~
-
-      You will need this username and password to access the DB Console in the next step.
-
-1. Exit the SQL shell and pod:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-    The pod will continue running indefinitely, so any time you need to reopen the built-in SQL client or run any other [`cockroach` client commands](cockroach-commands.html) (e.g., `cockroach node`), repeat step 2 using the appropriate command.
-
-    If you'd prefer to delete the pod and recreate it when needed, run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete pod cockroachdb-client-secure --context <cluster-context>
-    ~~~
-
-<section class="filter-content" markdown="1" data-scope="gke">
-## Step 4. Access the DB Console
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-## Step 5. Access the DB Console
-</section>
-
-To access the cluster's [DB Console](ui-overview.html):
-
-1. On secure clusters, [certain pages of the DB Console](ui-overview.html#db-console-access) can only be accessed by `admin` users.
-
-    Get a shell into the pod with the `cockroach` binary created earlier and start the CockroachDB [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl exec -it cockroachdb-client-secure --context <cluster-context> --namespace <cluster-namespace> -- ./cockroach sql --certs-dir=/cockroach-certs --host=cockroachdb-public
-    ~~~
-
-1.  Assign `roach` to the `admin` role (you only need to do this once):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT admin TO roach;
-    ~~~
-
-1. Exit the SQL shell and pod:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-1. Port-forward from your local machine to a pod in one of your Kubernetes clusters:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl port-forward cockroachdb-0 8080 --context <cluster-context> --namespace <cluster-namespace>
-    ~~~
-
-    ~~~
-    Forwarding from 127.0.0.1:8080 -> 8080
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    The `port-forward` command must be run on the same machine as the web browser in which you want to view the DB Console. If you have been running these commands from a cloud instance or other non-local shell, you will not be able to view the UI without configuring `kubectl` locally and running the above `port-forward` command on your local machine.
-    {{site.data.alerts.end}}
-
-1. Go to <a href="https://localhost:8080/" data-proofer-ignore>https://localhost:8080</a> and log in with the username and password created in the [Use the built-in SQL client](#step-3-use-the-built-in-sql-client) step.
-
-1. In the UI, check the [**Node List**](ui-cluster-overview-page.html#node-list) to verify that all nodes are running, open the [**Databases** page](ui-databases-page.html) to verify that `bank` is listed, and open the [**Network Latency** page](ui-network-latency-page.html) to see the performance of your CockroachDB cluster across 3 regions.
-
-<section class="filter-content" markdown="1" data-scope="gke">
-## Step 5. Simulate datacenter failure
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-## Step 6. Simulate datacenter failure
-</section>
-
-One of the major benefits of running a multi-region CockroachDB cluster is that an entire datacenter or region can go down without affecting the availability of the cluster as a whole.
-
-To see this in action:
-
-1. Scale down one of the StatefulSets to zero pods, specifying the namespace and context of the Kubernetes cluster where it's running:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl scale statefulset cockroachdb --replicas=0 --context <cluster-context> --namespace <cluster-namespace>
-    ~~~
-
-    ~~~
-    statefulset "cockroachdb" scaled
-    ~~~
-
-1. In the DB Console, the **Cluster Overview** will soon show the three nodes from that region as **Suspect**. If you wait for 5 minutes or more, they will be listed as **Dead**. Note that even though there are three dead nodes, the other nodes are all healthy, and any clients using the database in the other regions will continue to work just fine.
-
-1. When you're done verifying that the cluster still fully functions with one of the regions down, you can bring the region back up by running:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl scale statefulset cockroachdb --replicas=3 --context <cluster-context> --namespace <cluster-namespace>
-    ~~~
-
-    ~~~
-    statefulset "cockroachdb" scaled
-    ~~~
-
-<section class="filter-content" markdown="1" data-scope="gke">
-## Step 6. Maintain the cluster
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-## Step 7. Maintain the cluster
-</section>
-
-- [Scale the cluster](#scale-the-cluster)
-- [Upgrade the cluster](#upgrade-the-cluster)
-- [Stop the cluster](#stop-the-cluster)
-
-### Scale the cluster
-
-Each of your Kubernetes clusters contains 3 instances that can run CockroachDB pods. It's easy to scale a cluster to run more pods. To ensure that you do not have two CockroachDB pods on the same instance (as recommended in our [production best practices](recommended-production-settings.html)), you need to first add a new instance and then edit your StatefulSet configuration to add another pod.
-
-<section class="filter-content" markdown="1" data-scope="gke">
-1. [Resize your Kubernetes cluster.](https://cloud.google.com/kubernetes-engine/docs/how-to/resizing-a-cluster)
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-1. [Resize your Kubernetes cluster.](https://eksctl.io/usage/managing-nodegroups/#scaling)
-</section>
-
-1. Use the `kubectl scale` command to add a pod to the StatefulSet in the Kubernetes cluster where you want to add a CockroachDB node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl scale statefulset cockroachdb --replicas=4 --context <cluster-context> --namespace <cluster-namespace>
-    ~~~
-
-    ~~~
-    statefulset "cockroachdb" scaled
-    ~~~
-
-1. Verify that a fourth pod was added successfully:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods --context <cluster-context> --namespace <cluster-namespace>
-    ~~~
-
-    ~~~
-    NAME                        READY     STATUS    RESTARTS   AGE
-    cockroachdb-0               1/1       Running   0          1h
-    cockroachdb-1               1/1       Running   0          1h
-    cockroachdb-2               1/1       Running   0          7m
-    cockroachdb-3               1/1       Running   0          44s
-    cockroachdb-client-secure   1/1       Running   0          26m
-    ~~~
-
-### Upgrade the cluster
-
-As new versions of CockroachDB are released, it's strongly recommended to upgrade to newer versions in order to pick up bug fixes, performance improvements, and new features. The [general CockroachDB upgrade documentation](upgrade-cockroach-version.html) provides best practices for how to prepare for and execute upgrades of CockroachDB clusters, but the mechanism of actually stopping and restarting processes in Kubernetes is somewhat special.
-
-Kubernetes knows how to carry out a safe rolling upgrade process of the CockroachDB nodes. When you tell it to change the Docker image used in the CockroachDB StatefulSet, Kubernetes will go one-by-one, stopping a node, restarting it with the new image, and waiting for it to be ready to receive client requests before moving on to the next one. For more information, see [the Kubernetes documentation](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#updating-statefulsets).
-
-1. Decide how the upgrade will be finalized.
-
-    {{site.data.alerts.callout_info}}This step is relevant only when upgrading from v20.1.x to v20.2. For upgrades within the v20.2.x series, skip this step.{{site.data.alerts.end}}
-
-    By default, after all nodes are running the new version, the upgrade process will be **auto-finalized**. This will enable certain performance improvements and bug fixes introduced in v20.2. After finalization, however, it will no longer be possible to perform a downgrade to v20.1. In the event of a catastrophic failure or corruption, the only option will be to start a new cluster using the old binary and then restore from one of the backups created prior to performing the upgrade.
-
-    We recommend disabling auto-finalization so you can monitor the stability and performance of the upgraded cluster before finalizing the upgrade:
-
-    1. Get a shell into the pod with the `cockroach` binary created earlier and start the CockroachDB [built-in SQL client](cockroach-sql.html):
-
-        {% include copy-clipboard.html %}
-        ~~~ shell
-        $ kubectl exec -it cockroachdb-client-secure --context <cluster-context> --namespace <cluster-namespace> -- ./cockroach sql --certs-dir=/cockroach-certs --host=cockroachdb-public
-        ~~~
-
-    2. Set the `cluster.preserve_downgrade_option` [cluster setting](cluster-settings.html):
-
-        {% include copy-clipboard.html %}
-        ~~~ sql
-        > SET CLUSTER SETTING cluster.preserve_downgrade_option = '20.1';
-        ~~~
-
-2. For each Kubernetes cluster, kick off the upgrade process by changing the desired Docker image. To do so, pick the version that you want to upgrade to, then run the following command, replacing "VERSION" with your desired new version and specifying the relevant namespace and "context" name for the Kubernetes cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl patch statefulset cockroachdb --namespace <namespace-of-kubernetes-cluster1> --context <cluster-context-1> --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"cockroachdb/cockroach:VERSION"}]'
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl patch statefulset cockroachdb --namespace <namespace-of-kubernetes-cluster2> --context <cluster-context-2> --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"cockroachdb/cockroach:VERSION"}]'
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl patch statefulset cockroachdb --namespace <namespace-of-kubernetes-cluster3> --context <cluster-context-3> --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/image", "value":"cockroachdb/cockroach:VERSION"}]'
-    ~~~
-
-3. If you then check the status of the pods in each Kubernetes cluster, you should see one of them being restarted:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods --selector app=cockroachdb --all-namespaces --context <cluster-context-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods --selector app=cockroachdb --all-namespaces --context <cluster-context-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get pods --selector app=cockroachdb --all-namespaces --context <cluster-context-3>
-    ~~~
-
-    This will continue until all of the pods have restarted and are running the new image.
-
-4. Finish the upgrade.
-
-    {{site.data.alerts.callout_info}}This step is relevant only when upgrading from v20.1.x to v20.2. For upgrades within the v20.2.x series, skip this step.{{site.data.alerts.end}}
-
-    If you disabled auto-finalization in step 1 above, monitor the stability and performance of your cluster for as long as you require to feel comfortable with the upgrade (generally at least a day). If during this time you decide to roll back the upgrade, repeat the rolling restart procedure with the old binary.
-
-    Once you are satisfied with the new version, re-enable auto-finalization:
-
-    1. Get a shell into the pod with the `cockroach` binary created earlier and start the CockroachDB [built-in SQL client](cockroach-sql.html):
-
-        {% include copy-clipboard.html %}
-        ~~~ shell
-        $ kubectl exec -it cockroachdb-client-secure --context <cluster-context> --namespace <cluster-namespace> -- ./cockroach sql --certs-dir=/cockroach-certs --host=cockroachdb-public
-        ~~~
-
-    2. Re-enable auto-finalization:
-
-        {% include copy-clipboard.html %}
-        ~~~ sql
-        > RESET CLUSTER SETTING cluster.preserve_downgrade_option;
-        ~~~
-
-### Stop the cluster
-
-<section class="filter-content" markdown="1" data-scope="gke">
-1. To delete all of the resources created in your clusters, copy the `contexts` map from `setup.py` into `teardown.py`, and then run `teardown.py`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ python teardown.py
-    ~~~
-
-    ~~~
-    namespace "us-east1-b" deleted
-    service "kube-dns-lb" deleted
-    configmap "kube-dns" deleted
-    pod "kube-dns-5dcfcbf5fb-l4xwt" deleted
-    pod "kube-dns-5dcfcbf5fb-tddp2" deleted
-    namespace "us-west1-a" deleted
-    service "kube-dns-lb" deleted
-    configmap "kube-dns" deleted
-    pod "kube-dns-5dcfcbf5fb-8csc9" deleted
-    pod "kube-dns-5dcfcbf5fb-zlzn7" deleted
-    namespace "us-central1-a" deleted
-    service "kube-dns-lb" deleted
-    configmap "kube-dns" deleted
-    pod "kube-dns-5dcfcbf5fb-6ngmw" deleted
-    pod "kube-dns-5dcfcbf5fb-lcfxd" deleted
-    ~~~
-
-2. Stop each Kubernetes cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud container clusters delete cockroachdb1 --zone=<gce-zone>
-    ~~~
-
-    ~~~
-    Deleting cluster cockroachdb1...done.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud container clusters delete cockroachdb2 --zone=<gce-zone>
-    ~~~
-
-    ~~~
-    Deleting cluster cockroachdb2...done.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud container clusters delete cockroachdb3 --zone=<gce-zone>
-    ~~~
-
-    ~~~
-    Deleting cluster cockroachdb3...done.
-    ~~~
-</section>
-
-<section class="filter-content" markdown="1" data-scope="eks">
-1. In each region, delete all of the resources associated with the `cockroachdb` label, including the logs, and remote persistent volumes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete pods,statefulsets,services,persistentvolumeclaims,persistentvolumes,poddisruptionbudget,jobs,rolebinding,clusterrolebinding,role,clusterrole,serviceaccount -l app=cockroachdb --context <cluster-context-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete pods,statefulsets,services,persistentvolumeclaims,persistentvolumes,poddisruptionbudget,jobs,rolebinding,clusterrolebinding,role,clusterrole,serviceaccount -l app=cockroachdb --context <cluster-context-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete pods,statefulsets,services,persistentvolumeclaims,persistentvolumes,poddisruptionbudget,jobs,rolebinding,clusterrolebinding,role,clusterrole,serviceaccount -l app=cockroachdb --context <cluster-context-3>
-    ~~~
-
-    ~~~
-    pod "cockroachdb-0" deleted
-    pod "cockroachdb-1" deleted
-    pod "cockroachdb-2" deleted
-    service "cockroachdb" deleted
-    service "cockroachdb-public" deleted
-    persistentvolumeclaim "datadir-cockroachdb-0" deleted
-    persistentvolumeclaim "datadir-cockroachdb-1" deleted
-    persistentvolumeclaim "datadir-cockroachdb-2" deleted
-    poddisruptionbudget.policy "cockroachdb-budget" deleted
-    rolebinding.rbac.authorization.k8s.io "cockroachdb" deleted
-    clusterrolebinding.rbac.authorization.k8s.io "cockroachdb" deleted
-    role.rbac.authorization.k8s.io "cockroachdb" deleted
-    clusterrole.rbac.authorization.k8s.io "cockroachdb" deleted
-    serviceaccount "cockroachdb" deleted
-    ~~~
-
-1. Delete the pod created for `cockroach` client commands, if you didn't do so earlier:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete pod cockroachdb-client-secure --context <cluster-context>
-    ~~~
-
-    ~~~
-    pod "cockroachdb-client-secure" deleted
-    ~~~
-
-1. Get the names of the secrets you created on each cluster. These should be identical in all 3 regions:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl get secrets --context <cluster-context>
-    ~~~
-
-    ~~~
-    NAME                      TYPE                                  DATA   AGE
-    cockroachdb.client.root   Opaque                                5      1d
-    cockroachdb.node          Opaque                                6      1d
-    ...
-    ~~~
-
-1. Delete the secrets that you created:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete secrets cockroachdb.client.root cockroachdb.node  --context <cluster-context-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete secrets cockroachdb.client.root cockroachdb.node  --context <cluster-context-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ kubectl delete secrets cockroachdb.client.root cockroachdb.node  --context <cluster-context-3>
-    ~~~
-
-1. Stop Kubernetes in each region:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ eksctl delete cluster --name cockroachdb1 --region <aws-region-1>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ eksctl delete cluster --name cockroachdb2 --region <aws-region-2>
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ eksctl delete cluster --name cockroachdb3 --region <aws-region-3>
-    ~~~
-
-1. Open the [AWS CloudFormation console](https://console.aws.amazon.com/cloudformation/home) to verify that the stacks were successfully deleted in each region.
-
-{{site.data.alerts.callout_danger}}
-If you stop Kubernetes without first deleting the persistent volumes, they will still exist in your cloud project.
-{{site.data.alerts.end}}
-</section>
-
-## See also
-
-- [Kubernetes Single-Cluster Deployment](orchestrate-cockroachdb-with-kubernetes.html)
-- [Kubernetes Performance Guide](kubernetes-performance.html)
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes.md b/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes.md
deleted file mode 100644
index d437d23d9ec..00000000000
--- a/src/current/v20.2/orchestrate-cockroachdb-with-kubernetes.md
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: Orchestrate CockroachDB in a Single Kubernetes Cluster
-summary: How to orchestrate the deployment, management, and monitoring of a secure 3-node CockroachDB cluster with Kubernetes.
-toc: true
-toc_not_nested: true
-secure: true
-canonical: /stable/deploy-cockroachdb-with-kubernetes
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Secure</strong></button>
-  <a href="orchestrate-cockroachdb-with-kubernetes-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-This page shows you how to orchestrate the deployment, management, and monitoring of a secure 3-node CockroachDB cluster in a single [Kubernetes](http://kubernetes.io/) cluster, using the [StatefulSet](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) feature directly or via the [Helm](https://helm.sh/) package manager for Kubernetes.
-
-To deploy across multiple Kubernetes clusters in different geographic regions instead, see [Kubernetes Multi-Cluster Deployment](orchestrate-cockroachdb-with-kubernetes-multi-cluster.html). Also, for details about potential performance bottlenecks to be aware of when running CockroachDB in Kubernetes and guidance on how to optimize your deployment for better performance, see [CockroachDB Performance on Kubernetes](kubernetes-performance.html).
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-Before getting started, it's helpful to review some Kubernetes-specific terminology and current limitations.
-
-- [Kubernetes terminology](#kubernetes-terminology)
-- [Limitations](#limitations)
-
-### Kubernetes terminology
-
-Feature | Description
---------|------------
-[node](https://kubernetes.io/docs/concepts/architecture/nodes/) | A physical or virtual machine. In this tutorial, you'll create GCE or AWS instances and join them as worker nodes into a single Kubernetes cluster from your local workstation.
-[pod](http://kubernetes.io/docs/user-guide/pods/) | A pod is a group of one of more Docker containers. In this tutorial, each pod will run on a separate Kubernetes node and include one Docker container running a single CockroachDB node. You'll start with 3 pods and grow to 4.
-[StatefulSet](http://kubernetes.io/docs/concepts/abstractions/controllers/statefulsets/) | A StatefulSet is a group of pods treated as stateful units, where each pod has distinguishable network identity and always binds back to the same persistent storage on restart. StatefulSets are considered stable as of Kubernetes version 1.9 after reaching beta in version 1.5.
-[persistent volume](http://kubernetes.io/docs/user-guide/persistent-volumes/) | A persistent volume is a piece of networked storage (Persistent Disk on GCE, Elastic Block Store on AWS) mounted into a pod. The lifetime of a persistent volume is decoupled from the lifetime of the pod that's using it, ensuring that each CockroachDB node binds back to the same storage on restart.<br><br>This tutorial assumes that dynamic volume provisioning is available. When that is not the case, [persistent volume claims](http://kubernetes.io/docs/user-guide/persistent-volumes/#persistentvolumeclaims) need to be created manually.
-[RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) | RBAC, or Role-Based Access Control, is the system Kubernetes uses to manage permissions within the cluster. In order to take an action (e.g., `get` or `create`) on an API resource (e.g., a `pod`), the client must have a `Role` that allows it to do so. This tutorial creates the RBAC resources necessary for CockroachDB to create and access certificates.
-
-### Limitations
-
-{% include {{ page.version.version }}/orchestration/kubernetes-limitations.md %}
-
-## Step 1. Start Kubernetes
-
-{% include {{ page.version.version }}/orchestration/start-kubernetes.md %}
-
-## Step 2. Start CockroachDB
-
-Choose how you want to deploy and maintain the CockroachDB cluster:
-
-- [CockroachDB Kubernetes Operator](https://github.com/cockroachdb/cockroach-operator) (recommended)
-- [Helm](https://helm.sh/) package manager
-- Manually apply our StatefulSet configuration and related files
-
-{{site.data.alerts.callout_success}}
-<span class="version-tag">New in v20.2:</span> The [CockroachDB Kubernetes Operator](https://github.com/cockroachdb/cockroach-operator) eases the creation of StatefulSets, pod authentication, cluster scaling, and rolling upgrades. The Operator is currently in **beta** and is not yet production-ready.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-The CockroachDB Kubernetes Operator can also be run on platforms such as [Red Hat OpenShift](https://marketplace.redhat.com/en-us/products/cockroachdb-operator) and [IBM Cloud Pak for Data](https://www.ibm.com/products/cloud-pak-for-data).
-{{site.data.alerts.end}}
-
-<div class="filters filters-big clearfix">
-    <button class="filter-button" data-scope="operator">Use Operator</button>
-    <button class="filter-button" data-scope="helm">Use Helm</button>
-    <button class="filter-button" data-scope="manual">Use Configs</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="operator">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-operator-secure.md %}
-</section>
-
-<section class="filter-content" markdown="1" data-scope="manual">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-secure.md %}
-</section>
-
-<section class="filter-content" markdown="1" data-scope="helm">
-{% include {{ page.version.version }}/orchestration/start-cockroachdb-helm-secure.md %}
-</section>
-
-## Step 3. Use the built-in SQL client
-
-{% include {{ page.version.version }}/orchestration/test-cluster-secure.md %}
-
-## Step 4. Access the DB Console
-
-{% include {{ page.version.version }}/orchestration/monitor-cluster.md %}
-
-## Step 5. Simulate node failure
-
-{% include {{ page.version.version }}/orchestration/kubernetes-simulate-failure.md %}
-
-## Step 6. Monitor the cluster
-
-{% include {{ page.version.version }}/orchestration/kubernetes-prometheus-alertmanager.md %}
-
-## Step 7. Maintain the cluster
-
-- [Add nodes](#add-nodes)
-- [Remove nodes](#remove-nodes)
-- [Expand disk size](#expand-disk-size)
-- [Upgrade the cluster](#upgrade-the-cluster)
-- [Stop the cluster](#stop-the-cluster)
-
-### Add nodes
-
-{% include {{ page.version.version }}/orchestration/kubernetes-scale-cluster.md %}
-
-### Remove nodes
-
-{% include {{ page.version.version }}/orchestration/kubernetes-remove-nodes-secure.md %}
-
-### Expand disk size
-
-<section class="filter-content" markdown="1" data-scope="operator">
-{{site.data.alerts.callout_info}}
-Expansion of persistent volumes with the Operator is forthcoming. See the [GitHub project](https://github.com/cockroachdb/cockroach-operator) for progress.
-{{site.data.alerts.end}}
-</section>
-
-{% include {{ page.version.version }}/orchestration/kubernetes-expand-disk-size.md %}
-
-### Upgrade the cluster
-
-{% include {{ page.version.version }}/orchestration/kubernetes-upgrade-cluster.md %}
-
-### Stop the cluster
-
-{% include {{ page.version.version }}/orchestration/kubernetes-stop-cluster.md %}
-
-#### Stop Kubernetes
-
-To delete the Kubernetes cluster:
-
-- Hosted GKE:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ gcloud container clusters delete cockroachdb --region {region-name}
-    ~~~
-- Hosted EKS:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ eksctl delete cluster --name cockroachdb
-    ~~~
-
-{{site.data.alerts.callout_danger}}
-If you stop Kubernetes without first deleting the persistent volumes, they will still exist in your cloud project.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Kubernetes Multi-Cluster Deployment](orchestrate-cockroachdb-with-kubernetes-multi-cluster.html)
-- [Kubernetes Performance Guide](kubernetes-performance.html)
-{% include {{ page.version.version }}/prod-deployment/prod-see-also.md %}
diff --git a/src/current/v20.2/orchestration.md b/src/current/v20.2/orchestration.md
deleted file mode 100644
index 8ab5fa6615e..00000000000
--- a/src/current/v20.2/orchestration.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-title: Orchestration
-summary: Learn how to run CockroachDB with popular open-source orchestration systems.
-toc: false
-canonical: /stable/kubernetes-overview
----
-
-Orchestration systems automate the deployment, scaling, and management of containerized applications. Combined with CockroachDB's [automated sharding](frequently-asked-questions.html#how-does-cockroachdb-scale) and [fault tolerance](frequently-asked-questions.html#how-does-cockroachdb-survive-failures), they have the potential to lower operator overhead to almost nothing.
-
-Use the following guides to run CockroachDB with popular open-source orchestration systems:
-
-- [Kubernetes Single-Cluster Deployment](orchestrate-cockroachdb-with-kubernetes.html)
-- [Kubernetes Multi-Cluster Deployment](orchestrate-cockroachdb-with-kubernetes-multi-cluster.html)
-- [Kubernetes Performance Optimization](kubernetes-performance.html)
-- [Docker Swarm Deployment](orchestrate-cockroachdb-with-docker-swarm.html)
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## See also
-
-- [Production Checklist](recommended-production-settings.html)
-- [Manual Deployment](manual-deployment.html)
-- [Monitoring and Alerting](monitoring-and-alerting.html)
-- [Local Deployment](start-a-local-cluster.html)
diff --git a/src/current/v20.2/order-by.md b/src/current/v20.2/order-by.md
deleted file mode 100644
index 08cdbc6ae7c..00000000000
--- a/src/current/v20.2/order-by.md
+++ /dev/null
@@ -1,287 +0,0 @@
----
-title: ORDER BY
-summary: The ORDER BY clause controls the order in which rows are returned or processed.
-toc: true
----
-
-The `ORDER BY` clause controls the order in which rows are returned or
-processed. It can be used in any [selection
-query](selection-queries.html), including
-as operand of [`INSERT`](insert.html) or [`UPSERT`](upsert.html), as
-well as with [`DELETE`](delete.html) and [`UPDATE`](update.html)
-statements.
-
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/sort_clause.html %}
-</div>
-
-## Parameters
-
-The `ORDER BY` clause takes a comma-separated list of ordering specifications.
-Each ordering specification is composed of a column selection followed optionally
-by the keyword `ASC` or `DESC`.
-
-Each **column selection** can take one of the following forms:
-
-- A simple column selection, determined as follows:
-  1. The name of a column label configured with `AS` earlier in the [`SELECT` clause](select-clause.html). This uses the value computed by the `SELECT` clause as the sorting key.
-  2. A positive integer number, designating one of the columns in the data source, either the `FROM` clause of the `SELECT` clause where it happens or the table being written to by `DELETE` or `UPDATE`. This uses the corresponding input value from the data source to use as the sorting key.
-  3. An arbitrary [scalar expression](scalar-expressions.html). This uses the result of evaluating that expression as the sorting key.
-- The notation `PRIMARY KEY <table_name>`. This uses the primary key column(s) of the given table as sorting key. This table must be part of the data source.
-- The notation `INDEX <table_name>@<index_name>`. This uses the columns indexed by the given index as sorting key. This table must be part of the data source.
-
-The optional keyword `ASC` after a column selection indicates to use
-the sorting key as-is, and thus is meaningless.
-
-The optional keyword `DESC` inverts the direction of the column(s)
-selected by the selection that immediately precedes.
-
- CockroachDB supports `NULLS FIRST`/`NULLS LAST` in `ORDER BY` clauses for compatibility with [PostgreSQL row-sorting syntax](https://www.postgresql.org/docs/current/queries-order.html).
-
-{{site.data.alerts.callout_info}}
-Support for `NULLS LAST` is currently syntax-only. If you specify `NULLS LAST` in an `ORDER BY` clause, CockroachDB uses `NULLS FIRST` and does not return an error.
-{{site.data.alerts.end}}
-
-## Order preservation
-
-In general, the order of the intermediate results of a query is not guaranteed,
-even if `ORDER BY` is specified. In other words, the `ORDER BY` clause is only
-effective at the top-level statement. For example, it is *ignored* by the query
-planner when present in a sub-query in a `FROM` clause as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
->  SELECT * FROM a, b ORDER BY a.x;                 -- valid, effective
->  SELECT * FROM (SELECT * FROM a ORDER BY a.x), b; -- ignored, ineffective
-~~~
-
-However, when combining queries together with
-[sub-queries](table-expressions.html#subqueries-as-table-expressions),
-some combinations will make the `ORDER BY` clause in a sub-query
-significant:
-
-1. The ordering of the operand of a `WITH ORDINALITY` clause
-   (within the `FROM` operand of a `SELECT` clause) is preserved,
-   to control the numbering of the rows.
-2. The ordering of the operand of a stand-alone `LIMIT` or `OFFSET` clause (within
-   a `FROM` operand of a `SELECT` clause) is preserved, to determine
-   which rows are kept in the result.
-3. The ordering of the data source for an [`INSERT`](insert.html)
-   statement or an [`UPSERT`](upsert.html) statement that also uses
-   `LIMIT` is preserved, to determine [which rows are processed, but not their order](#ordering-rows-in-dml-statements).
-4. The ordering indicated for an [`UPDATE`](update.html) or [`DELETE`](delete.html)
-   statement that also uses `LIMIT` is used to determine
-   [which rows are processed, but not their order](#ordering-rows-in-dml-statements).
-   (This is a CockroachDB extension.)
-5. The ordering of a sub-query used in a scalar expression
-   is preserved.
-
-For example, using `WITH ORDINALITY`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM (SELECT * FROM a ORDER BY a.x) WITH ORDINALITY;
-  -- ensures that the rows are numbered in the order of column a.x.
-~~~
-
-For example, using a stand-alone `LIMIT` clause in `FROM`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM a, ((SELECT * FROM b ORDER BY b.x) LIMIT 1);
-  -- ensures that only the first row of b in the order of column b.x
-  -- is used in the cross join.
-~~~
-
-For example, using a sub-query in scalar context:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ARRAY(SELECT a.x FROM a ORDER BY a.x);
-  -- ensures that the array is constructed using the values of a.x in sorted order.
-> SELECT (1, 2, 3) = (SELECT a.x FROM a ORDER BY a.x);
-  -- ensures that the values on the right-hand side are compared in the order of column a.x.
-~~~
-
-## Ordering of rows without `ORDER BY`
-
-Without `ORDER BY`, rows are processed or returned in a
-non-deterministic order. "Non-deterministic" means that the actual order
-can depend on the logical plan, the order of data on disk, the topology
-of the CockroachDB cluster, and is generally variable over time.
-
-## Sorting using simple column selections
-
-Considering the following table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE a(a INT);
-> INSERT INTO a VALUES (1), (3), (2);
-~~~
-
-The following statements are equivalent:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT a AS b FROM a ORDER BY b; -- first form: refers to an AS alias.
-> SELECT a      FROM a ORDER BY 1; -- second form: refers to a column position.
-> SELECT a      FROM a ORDER BY a; -- third form: refers to a column in the data source.
-~~~
-
-~~~
-+---------+
-| a       |
-+---------+
-|       1 |
-|       2 |
-|       3 |
-+---------+
-(3 rows)
-~~~
-
-Note that the order of the rules matter. If there is ambiguity, the `AS` aliases
-take priority over the data source columns, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE ab(a INT, b INT);
-> SELECT a AS b, b AS c FROM ab ORDER BY b; -- orders by column a, renamed to b
-> SELECT a,      b      FROM ab ORDER BY b; -- orders by column b
-~~~
-
-It is also possible to sort using an arbitrary scalar expression computed for each row, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT a, b FROM ab ORDER BY a + b; -- orders by the result of computing a+b.
-~~~
-
-## Sorting using multiple columns
-
-When more than one ordering specification is given, the later specifications are used
-to order rows that are equal over the earlier specifications, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE ab(a INT, b INT);
-> SELECT a, b FROM ab ORDER BY b, a;
-~~~
-
-This sorts the results by column `b`, and then if there are multiple
-rows that have the same value in column `b`, it will then order these
-rows by column `a`.
-
-## Inverting the sort order
-
-The keyword `DESC` ("descending") can be added after an ordering specification to
-invert its order. This can be specified separately for each specification, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE ab(a INT, b INT);
-> SELECT a, b FROM ab ORDER BY b DESC, a; -- sorts on b descending, then a ascending.
-~~~
-
-## Sorting in primary key order
-
-The `ORDER BY PRIMARY KEY` notation guarantees that the results are
-presented in primary key order.
-
-The particular advantage is that for queries using the primary index,
-this guarantees the order while also guaranteeing there will not be an
-additional sorting computation to achieve it, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE kv(k INT PRIMARY KEY, v INT);
-> SELECT k, v FROM kv ORDER BY PRIMARY KEY kv; -- guarantees ordering by column k.
-~~~
-
-If a primary key uses the keyword `DESC` already, then its meaning
-will be flipped (cancelled) if the `ORDER BY` clause also uses
-`DESC`, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE ab(a INT, b INT, PRIMARY KEY (b DESC, a ASC));
-> SELECT * FROM ab ORDER BY b DESC; -- orders by b descending, then a ascending.
-                                    -- The primary index may be used to optimize.
-
-> SELECT * FROM ab ORDER BY PRIMARY KEY ab DESC; -- orders by b ascending, then a descending.
-                                                 -- The index order is inverted.
-~~~
-
-## Sorting in index order
-
-The `ORDER BY INDEX` notation guarantees that the results are presented
-in the order of a given index.
-
-The particular advantage is that for queries using that index, this
-guarantees the order while also guaranteeing there will not be an
-additional sorting computation to achieve it, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE kv(k INT PRIMARY KEY, v INT, INDEX v_idx(v));
-> SELECT k, v FROM kv ORDER BY INDEX kv@v_idx; -- guarantees ordering by column v.
-~~~
-
-If an index uses the keyword `DESC` already, then its meaning
-will be flipped (cancelled) if the `ORDER BY` clause also uses
-`DESC`, for example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE ab(a INT, b INT, INDEX b_idx (b DESC, a ASC));
-> SELECT * FROM ab ORDER BY b DESC; -- orders by b descending, then a ascending.
-                                    -- The index b_idx may be used to optimize.
-
-> SELECT * FROM ab ORDER BY INDEX ab@b_idx DESC; -- orders by b ascending, then a descending.
-                                                 -- The index order is inverted.
-~~~
-
-## Ordering rows in DML statements
-
-When using `ORDER BY` with an [`INSERT`](insert.html),
-[`UPSERT`](upsert.html), [`UPDATE`](update.html) or
-[`DELETE`](delete.html) (i.e., a DML statement), the `ORDER BY` clause is
-ignored if it is not used in combination with [`LIMIT` and/or
-`OFFSET`](limit-offset.html).
-
-The combination of both `ORDER BY` and `LIMIT`/`OFFSET` determines
-which rows of the input are used to insert, update or delete the table
-data, but *it does not determine in which order the mutation takes
-place*.
-
-For example, using `LIMIT` in `INSERT`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO a SELECT * FROM b ORDER BY b.x LIMIT 1;
-  -- ensures that only the first row of b in the order of column b.x
-  -- is inserted into a.
-~~~
-
-The reason why `ORDER BY` does not control the final order of the rows
-in the table is that the ordering of rows in the target table is
-determined by its [primary and secondary indexes](indexes.html).
-
-To order the result of the `RETURNING` clause, see [Sorting the output
-of deletes](#sorting-the-output-of-deletes).
-
-## Sorting the output of deletes
-
-{% include {{page.version.version}}/misc/sorting-delete-output.md %}
-
-## See also
-
-- [Selection Queries](selection-queries.html)
-- [Scalar Expressions](scalar-expressions.html)
-- [`INSERT`](insert.html)
-- [`UPSERT`](upsert.html)
-- [`DELETE`](delete.html)
-- [`UPDATE`](delete.html)
diff --git a/src/current/v20.2/owner-to.md b/src/current/v20.2/owner-to.md
deleted file mode 100644
index 0a8132e11a8..00000000000
--- a/src/current/v20.2/owner-to.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: OWNER TO
-summary: The OWNER TO subcommand changes the owner of an object.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: `OWNER TO` is a subcommand of [`ALTER DATABASE`](alter-database.html), [`ALTER TABLE`](alter-table.html), [`ALTER SCHEMA`](alter-schema.html), and [`ALTER TYPE`](alter-type.html), and is used to change the owner of an object in a cluster.
-
-{{site.data.alerts.callout_info}}
-This page documents `ALTER DATABASE ... OWNER TO` and `ALTER TABLE ... OWNER TO`. For details on the `ALTER SCHEMA ... OWNER TO` and `ALTER TYPE ... OWNER TO`, see the [`ALTER SCHEMA`](alter-schema.html) and [`ALTER TYPE`](alter-type.html) pages.
-{{site.data.alerts.end}}
-
-## Required privileges
-
-- To change the owner of a database, the user must be an `admin` user, or the current owner of the database and a member of the new owner [role](authorization.html#roles). The user must also have the `CREATEDB` [privilege](authorization.html#assign-privileges).
-- To change the owner of a table, the user must be an `admin` user, or the current owner of the table and a member of the new owner [role](authorization.html#roles). The new owner role must also have the `CREATE` [privilege](authorization.html#assign-privileges) on the schema to which the table belongs.
-
-## Syntax
-
-### Databases
-
-~~~
-ALTER DATABASE <name> OWNER TO <newowner>
-~~~
-
-### Tables
-
-~~~
-ALTER TABLE <name> OWNER TO <newowner>
-~~~
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`name` | The name of the table or database.
-`newowner` | The name of the new owner.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Change a database's owner
-
-Suppose that the current owner of the `movr` database is `root` and you want to change the owner to a new user named `max`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER DATABASE movr OWNER TO max;
-~~~
-
-To verify that the owner is now `max`, query the `pg_catalog.pg_database` and `pg_catalog.pg_roles` tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT rolname FROM pg_catalog.pg_database d JOIN pg_catalog.pg_roles r ON d.datdba = r.oid WHERE datname = 'movr';
-~~~
-
-~~~
-  rolname
------------
-  max
-(1 row)
-~~~
-
-{{site.data.alerts.callout_info}}
-If the user running the command is not an admin user, they must own the database and be a member of the new owning role. They must also have the `CREATEDB` [privilege](authorization.html#assign-privileges).
-{{site.data.alerts.end}}
-
-### Change a table's owner
-
-Suppose that the current owner of the `rides` table is `root` and you want to change the owner to a new user named `max`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE promo_codes OWNER TO max;
-~~~
-
-To verify that the owner is now `max`, query the `pg_catalog.pg_tables` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT tableowner FROM pg_catalog.pg_tables WHERE tablename = 'promo_codes';
-~~~
-
-~~~
-  tableowner
---------------
-  max
-(1 row)
-~~~
-
-{{site.data.alerts.callout_info}}
-If the user running the command is not an admin user, they must own the table and be a member of the new owning role. Also, the new owner role must also have the `CREATE` [privilege](authorization.html#assign-privileges) on the schema to which the table belongs.
-{{site.data.alerts.end}}
-
-
-
-## See also
-
-- [`CREATE DATABASE`](create-database.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`CREATE TABLE`](create-table.html)
-- [`SHOW TABLES`](show-tables.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/pagination.md b/src/current/v20.2/pagination.md
deleted file mode 100644
index 487b62f04ab..00000000000
--- a/src/current/v20.2/pagination.md
+++ /dev/null
@@ -1,184 +0,0 @@
----
-title: Paginate Results
-summary: Paginate results from queries against your cluster
-toc: true
----
-
-To iterate through a table one "page" of results at a time (also known as pagination) there are two options, only one of which is recommended:
-
-- Keyset pagination (**fast, recommended**)
-- `LIMIT` / `OFFSET` pagination (slow, not recommended)
-
-## Keyset pagination
-
-Keyset pagination (also known as the "seek method") is used to fetch a subset of records from a table quickly. It does this by restricting the set of records returned with a combination of `WHERE` and [`LIMIT`](limit-offset.html) clauses. To get the next page, you check the value of the column in the `WHERE` clause against the last row returned in the previous page of results.
-
-The general pattern for keyset pagination queries is:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM t AS OF SYSTEM TIME ${time}
-  WHERE key > ${value}
-  ORDER BY key
-  LIMIT ${amount}
-~~~
-
-This is faster than using `LIMIT`/`OFFSET` because, instead of doing a full table scan up to the value of the `OFFSET`, a keyset pagination query looks at a fixed-size set of records for each iteration. This can be done quickly provided that the key used in the `WHERE` clause to implement the pagination is [indexed](indexes.html#best-practices) and [unique](unique.html). A [primary key](primary-key.html) meets both of these criteria.
-
-{{site.data.alerts.callout_info}}
-CockroachDB does not have cursors. To support a cursor-like use case, namely "operate on a snapshot of the database at the moment the cursor is opened", use the [`AS OF SYSTEM TIME`](as-of-system-time.html) clause as shown in the examples below.
-{{site.data.alerts.end}}
-
-## Example
-
-The examples in this section use the [employees data set](https://github.com/datacharmer/test_db), which you can load into CockroachDB as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE DATABASE IF NOT EXISTS employees;
-USE employees;
-IMPORT PGDUMP 'https://s3-us-west-1.amazonaws.com/cockroachdb-movr/datasets/employees-db/pg_dump/employees-full.sql.gz';
-~~~
-
-To get the first page of results using keyset pagination, run the statement below.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM employees AS OF SYSTEM TIME '-1m' WHERE emp_no > 10000 ORDER BY emp_no LIMIT 25;
-~~~
-
-~~~
-emp_no |        birth_date         | first_name |  last_name  | gender |         hire_date
----------+---------------------------+------------+-------------+--------+----------------------------
- 10001 | 1953-09-02 00:00:00+00:00 | Georgi     | Facello     | M      | 1986-06-26 00:00:00+00:00
- 10002 | 1964-06-02 00:00:00+00:00 | Bezalel    | Simmel      | F      | 1985-11-21 00:00:00+00:00
- 10003 | 1959-12-03 00:00:00+00:00 | Parto      | Bamford     | M      | 1986-08-28 00:00:00+00:00
- 10004 | 1954-05-01 00:00:00+00:00 | Chirstian  | Koblick     | M      | 1986-12-01 00:00:00+00:00
-...
-(25 rows)
-
-Server Execution Time: 540µs
-Network Latency: 797µs
-~~~
-
-{{site.data.alerts.callout_success}}
-When writing your own queries of this type, use a known minimum value for the key's data type. If you do not know what the minimum value of the key is, you can use `SELECT min(key) FROM table`.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-We use [`AS OF SYSTEM TIME`](as-of-system-time.html) in these examples to ensure that we are operating on a consistent snapshot of the database as of the specified timestamp. This reduces the chance that there will be any concurrent updates to the data the query is accessing, and thus no missing or duplicated rows during the pagination. It also reduces the risk of [transaction retries](transactions.html#client-side-intervention) due to concurrent data access. The value of `-1m` passed to `AS OF SYSTEM TIME` may need to be updated depending on your application's data access patterns.
-{{site.data.alerts.end}}
-
-To get the second page of results, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM employees AS OF SYSTEM TIME '-1m' WHERE emp_no > 10025 ORDER BY emp_no LIMIT 25;
-~~~
-
-~~~
-  emp_no |        birth_date         | first_name | last_name  | gender |         hire_date
----------+---------------------------+------------+------------+--------+----------------------------
-   10026 | 1953-04-03 00:00:00+00:00 | Yongqiao   | Berztiss   | M      | 1995-03-20 00:00:00+00:00
-   10027 | 1962-07-10 00:00:00+00:00 | Divier     | Reistad    | F      | 1989-07-07 00:00:00+00:00
-   10028 | 1963-11-26 00:00:00+00:00 | Domenick   | Tempesti   | M      | 1991-10-22 00:00:00+00:00
-   10029 | 1956-12-13 00:00:00+00:00 | Otmar      | Herbst     | M      | 1985-11-20 00:00:00+00:00
-...
-(25 rows)
-
-Server Execution Time: 545µs
-Network Latency: 529µs
-~~~
-
-To get an arbitrary page of results showing employees whose IDs (`emp_no`) are in a much higher range, run the following query. Note that it takes about the same amount of time to run as the previous queries.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM employees AS OF SYSTEM TIME '-1m' WHERE emp_no > 300025 ORDER BY emp_no LIMIT 25;
-~~~
-
-~~~
-  emp_no |        birth_date         | first_name |  last_name   | gender |         hire_date
----------+---------------------------+------------+--------------+--------+----------------------------
-  400000 | 1963-11-29 00:00:00+00:00 | Mitsuyuki  | Reinhart     | M      | 1985-08-27 00:00:00+00:00
-  400001 | 1962-06-02 00:00:00+00:00 | Rosalie    | Chinin       | M      | 1986-11-28 00:00:00+00:00
-  400002 | 1964-08-16 00:00:00+00:00 | Quingbo    | Birnbaum     | F      | 1986-04-23 00:00:00+00:00
-  400003 | 1958-04-30 00:00:00+00:00 | Jianwen    | Sidhu        | M      | 1986-02-01 00:00:00+00:00
-  400004 | 1958-04-30 00:00:00+00:00 | Sedat      | Suppi        | M      | 1995-12-18 00:00:00+00:00
-....
-(25 rows)
-
-Server Execution Time: 545µs
-Network Latency: 529µs
-~~~
-
-Compare the execution speed of the previous keyset pagination queries with the query below that uses `LIMIT` / `OFFSET` to get the same page of results:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM employees AS OF SYSTEM TIME '-1m' LIMIT 25 OFFSET 200024;
-~~~
-
-~~~
-  emp_no |        birth_date         | first_name |  last_name   | gender |         hire_date
----------+---------------------------+------------+--------------+--------+----------------------------
-  400000 | 1963-11-29 00:00:00+00:00 | Mitsuyuki  | Reinhart     | M      | 1985-08-27 00:00:00+00:00
-  400001 | 1962-06-02 00:00:00+00:00 | Rosalie    | Chinin       | M      | 1986-11-28 00:00:00+00:00
-  400002 | 1964-08-16 00:00:00+00:00 | Quingbo    | Birnbaum     | F      | 1986-04-23 00:00:00+00:00
-  400003 | 1958-04-30 00:00:00+00:00 | Jianwen    | Sidhu        | M      | 1986-02-01 00:00:00+00:00
-...
-(25 rows)
-
-Server Execution Time: 141.314ms
-Network Latency: 498µs
-~~~
-
-The query using `LIMIT`/`OFFSET` for pagination is almost 100 times slower. To see why, let's use [`EXPLAIN`](explain.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPLAIN SELECT * FROM employees LIMIT 25 OFFSET 200024;
-~~~
-
-~~~
-    tree    |        field        |         description
-------------+---------------------+------------------------------
-            | distribution        | full
-            | vectorized          | true
-  limit     |                     |
-   │        | offset              | 200024
-   └── scan |                     |
-            | estimated row count | 200049
-            | table               | employees@idx_17110_primary
-            | spans               | LIMITED SCAN
-            | limit               | 200049
-(9 rows)
-~~~
-
-The culprit is this: because we used `LIMIT`/`OFFSET`, we are performing a limited scan of the entire table (see `spans` = `LIMITED SCAN` above) from the first record all the way up to the value of the offset. In other words, we are iterating over a big array of rows from 1 to *n*, where *n* is 200049. The `estimated row count` row shows this.
-
-Meanwhile, the keyset pagination queries are looking at a much smaller range of table spans, which is much faster (see `spans` = `300026-` + 25 below). Because [there is an index on every column in the `WHERE` clause](indexes.html#best-practices), these queries are doing an index lookup to jump to the start of the page of results, and then getting an additional 25 rows from there. This is much faster.
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPLAIN SELECT * FROM employees WHERE emp_no > 300025 ORDER BY emp_no LIMIT 25;
-~~~
-
-~~~
-  tree |        field        |         description
--------+---------------------+------------------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 25
-       | table               | employees@idx_17110_primary
-       | spans               | [/300026 - ]
-       | limit               | 25
-(7 rows)
-~~~
-
-As shown by the `estimated row count` row, this query scans only 25 rows, far fewer than the 200049 scanned by the `LIMIT`/`OFFSET` query.
-
-{{site.data.alerts.callout_danger}}
-Using a sequential (i.e., non-[UUID](uuid.html)) primary key creates hot spots in the database for write-heavy workloads, since concurrent [`INSERT`](insert.html)s to the table will attempt to write to the same (or nearby) underlying [ranges](architecture/overview.html#architecture-range). This can be mitigated by designing your schema with [multi-column primary keys which include a monotonically increasing column](performance-best-practices-overview.html#use-multi-column-primary-keys).
-{{site.data.alerts.end}}
diff --git a/src/current/v20.2/partial-indexes.md b/src/current/v20.2/partial-indexes.md
deleted file mode 100644
index bb1ceb396ce..00000000000
--- a/src/current/v20.2/partial-indexes.md
+++ /dev/null
@@ -1,392 +0,0 @@
----
-title: Partial Indexes
-summary: Partial indexes allow you to specify a subset of rows and columns to add to an index.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-<span class="version-tag">New in v20.2:</span> Partial indexes allow you to specify a subset of rows and columns to add to an [index](indexes.html). Partial indexes include the subset of rows in a table that evaluate to true on a boolean *predicate expression* (i.e., a `WHERE` filter) defined at [index creation](#creation).
-
-## How do partial indexes work?
-
-When you create a partial index, CockroachDB "indexes" the columns and rows that evaluate to true on the index's boolean predicate expression, creating a sorted copy of the subset of row values, without modifying the values in the table itself.
-
-CockroachDB can use a partial index to efficiently execute queries on any subset of rows implied by the partial index. When possible, the [cost-based optimizer](cost-based-optimizer.html) creates a plan that limits table scans on rows implied by the partial index to just the rows in the index. It also limits index rewrites to fewer rows.
-
-Partial indexes can improve cluster performance in a number of ways:
-
-- They contain fewer rows than full indexes, making them less expensive to create and store on a cluster.
-- Read queries on rows included in a partial index only scan the rows in the partial index. This contrasts with queries on columns in full indexes, which must scan all rows in the indexed column.
-- Write queries on tables with a partial index only perform an index write when the rows inserted satisfy the partial index predicate. This contrasts with write queries on tables with full indexes, which incur the overhead of a full index write when the rows inserted modify an indexed column.
-
-{{site.data.alerts.callout_info}}
-When a query on a table with a partial index has a filter expression, the [cost-based optimizer](cost-based-optimizer.html) attempts to prove that the filter implies the partial index predicate. It is not guaranteed that the optimizer can prove the implication of arbitrarily complex expressions. Although unlikely, it is possible that a filter implies a predicate, but the optimizer cannot prove the implication.
-{{site.data.alerts.end}}
-
-## Creation
-
-To create a partial index, use a [`CREATE INDEX`](create-index.html) statement, with a standard `WHERE` clause defining a predicate expression.
-
-For example, to define a partial index on columns `a` and `b` of table `t`, filtering on rows in column `c` greater than 5:
-
-~~~ sql
-> CREATE INDEX ON t (a, b) WHERE c > 5;
-~~~
-
-The following queries use the partial index:
-
-~~~ sql
-> SELECT a, b FROM t WHERE c > 5;
-~~~
-
-~~~ sql
-> SELECT * FROM t WHERE c = 10;
-~~~
-
-The following queries do *not* use the partial index:
-
-~~~ sql
-> SELECT a, b FROM t;
-~~~
-
-~~~ sql
-> SELECT * FROM t WHERE c = 3;
-~~~
-
-When defining the predicate expression, note that:
-
-- The predicate expression must result in a [boolean](bool.html).
-- The predicate expression can only refer to columns in the table being indexed.
-- [Functions](functions-and-operators.html) used in predicates must be immutable. For example, the `now()` function is not allowed in predicates because its value depends on more than its arguments.
-
-## Unique partial indexes
-
-You can enforce [uniqueness](unique.html) on a subset of rows with `CREATE UNIQUE INDEX ... WHERE ...`.
-
-For example, to define a unique partial index on columns `a` and `b` for table `t`, filtering on rows in column `d` equal to `'x'`:
-
-~~~ sql
-> CREATE UNIQUE INDEX ON t (a, b) WHERE d = 'x';
-~~~
-
-This creates a partial index and a `UNIQUE` constraint on the subset of rows where `d` is equal to `'x'`.
-
-For another example, see [Create a partial index that enforces uniqueness on a subset of rows](#create-a-partial-index-that-enforces-uniqueness-on-a-subset-of-rows).
-
-{{site.data.alerts.callout_success}}
-When [inserted values](insert.html) conflict with a `UNIQUE` constraint on one or more columns, CockroachDB normally returns an error. We recommend adding an [`ON CONFLICT`](insert.html#on-conflict-clause) clause to all `INSERT` statements that might conflict with rows in the unique index.
-{{site.data.alerts.end}}
-
-## Index hints
-
-You can force queries [to use a specific partial index](table-expressions.html#force-index-selection) (also known as "index hinting"), like you can with full indexes. However, unlike full indexes, partial indexes cannot be used to satisfy all queries. If a query's filter implies the partial index predicate expression, the partial index will be used in the query plan. If not, an error will be returned.
-
-## Known limitations
-
-- CockroachDB does not currently support partial [GIN indexes](inverted-indexes.html). See [tracking issue](https://github.com/cockroachdb/cockroach/issues/50952).
-- CockroachDB does not currently support [`IMPORT`](import.html) statements on tables with partial indexes. See [tracking issue](https://github.com/cockroachdb/cockroach/issues/50225).
-- CockroachDB does not currently support multiple arbiter indexes for `INSERT ON CONFLICT DO UPDATE`, and will return an error if there are multiple unique or exclusion constraints matching the `ON CONFLICT DO UPDATE` specification. See [tracking issue](https://github.com/cockroachdb/cockroach/issues/53170).
-
-## Examples
-
-### Setup
-
-The following examples use MovR, a fictional vehicle-sharing application, to demonstrate CockroachDB SQL statements. For more information about the MovR example application and dataset, see [MovR: A Global Vehicle-sharing App](movr.html).
-
-To follow along, run [`cockroach demo`](cockroach-demo.html) to start a temporary, in-memory cluster with the `movr` workload:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo --with-load
-~~~
-
-### Create an index on a subset of rows
-
-Suppose that you want to query the subset of `rides` with a `revenue` greater than 80.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW TABLES] WHERE table_name='rides';
-~~~
-
-~~~
-  schema_name | table_name | type  | estimated_row_count
---------------+------------+-------+---------------------
-  public      | rides      | table |               29446
-(1 row)
-~~~
-
-Without a partial index, querying the `rides` table with a `WHERE revenue > 80` clause will scan the entire table. To see the plan for such a query, you can use an [`EXPLAIN` statement](explain.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM rides WHERE revenue > 80;
-~~~
-
-~~~
-    tree    |        field        |  description
-------------+---------------------+----------------
-            | distribution        | full
-            | vectorized          | true
-  filter    |                     |
-   │        | filter              | revenue > 80
-   └── scan |                     |
-            | estimated row count | 29446
-            | table               | rides@primary
-            | spans               | FULL SCAN
-(8 rows)
-~~~
-
-The `description` column for the `estimated row count` lists the number of rows that the query plan will scan (in this case, the entire table row count of 31337). The `description` for the `table` lists the index used in the scan (in this case, the [primary key index](primary-key.html)).
-
-To limit the number of rows scanned to just the rows that you are querying, you can create a partial index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON rides (city, revenue) WHERE revenue > 80;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM rides;
-~~~
-
-~~~
-  table_name |                  index_name                   | non_unique | seq_in_index | column_name  | direction | storing | implicit
--------------+-----------------------------------------------+------------+--------------+--------------+-----------+---------+-----------
-  rides      | primary                                       |   false    |            1 | city         | ASC       |  false  |  false
-  rides      | primary                                       |   false    |            2 | id           | ASC       |  false  |  false
-...
-  rides      | rides_city_revenue_idx                        |    true    |            1 | city         | ASC       |  false  |  false
-  rides      | rides_city_revenue_idx                        |    true    |            2 | revenue      | ASC       |  false  |  false
-  rides      | rides_city_revenue_idx                        |    true    |            3 | id           | ASC       |  false  |   true
-(12 rows)
-~~~
-
-Another `EXPLAIN` statement shows that the number of rows scanned by the original query decreases significantly with a partial index on the `rides` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM rides WHERE revenue > 80;
-~~~
-
-~~~
-     tree    |        field        |                 description
--------------+---------------------+-----------------------------------------------
-             | distribution        | full
-             | vectorized          | true
-  index join |                     |
-   │         | table               | rides@primary
-   └── scan  |                     |
-             | estimated row count | 5829
-             | table               | rides@rides_city_revenue_idx (partial index)
-             | spans               | FULL SCAN
-(8 rows)
-~~~
-
-Note that the query's `SELECT` statement queries all columns in the `rides` table, not just the indexed columns. As a result, an "index join" is required on both the primary index and the partial index.
-
-Querying only the columns in the index will make the query more efficient by removing the index join from the query plan:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT city, revenue FROM rides WHERE revenue > 80;
-~~~
-
-~~~
-  tree |        field        |                 description
--------+---------------------+-----------------------------------------------
-       | distribution        | full
-       | vectorized          | true
-  scan |                     |
-       | estimated row count | 5829
-       | table               | rides@rides_city_revenue_idx (partial index)
-       | spans               | FULL SCAN
-(6 rows)
-~~~
-
-Querying a subset of the rows implied by the partial index predicate expression (in this case, `revenue > 80`) will also use the partial index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT city, revenue FROM rides WHERE revenue > 95;
-~~~
-
-~~~
-    tree    |        field        |                 description
-------------+---------------------+-----------------------------------------------
-            | distribution        | full
-            | vectorized          | true
-  filter    |                     |
-   │        | filter              | revenue > 95
-   └── scan |                     |
-            | estimated row count | 5829
-            | table               | rides@rides_city_revenue_idx (partial index)
-            | spans               | FULL SCAN
-(8 rows)
-~~~
-
-The number of rows scanned is the same, and an additional filter is applied to the query plan so that only the subset specified by the filter is returned.
-
-So far, all the query scans in this example have spanned the entire partial index (i.e., performed a `FULL SCAN` of the index). This is because the `WHERE` clause does not filter on the first column in the index prefix (`city`). Filtering the query on both columns in the partial index will limit the scan to just the rows that match the filter:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT city, revenue FROM rides WHERE city = 'new york' AND revenue > 80;
-~~~
-
-~~~
-  tree |        field        |                 description
--------+---------------------+-----------------------------------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 660
-       | table               | rides@rides_city_revenue_idx (partial index)
-       | spans               | [/'new york' - /'new york']
-(6 rows)
-~~~
-
-Refining the `revenue` filter expression to match just a subset of the partial index will lower the scanned row count even more:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT city, revenue FROM rides WHERE city = 'new york' AND revenue >= 90 AND revenue < 95;
-~~~
-
-~~~
-  tree |        field        |                 description
--------+---------------------+-----------------------------------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 174
-       | table               | rides@rides_city_revenue_idx (partial index)
-       | spans               | [/'new york'/90 - /'new york'/95)
-(6 rows)
-~~~
-
-### Create an index that excludes values
-
-Suppose that you have a number of rows in a table with values that you regularly filter out of selection queries (e.g., `NULL` values).
-
-A selection query on these values will require a full table scan, using the primary index, as shown by the [`EXPLAIN` statement](explain.html) below:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM rides WHERE end_time IS NOT NULL;
-~~~
-
-~~~
-    tree    |        field        |     description
-------------+---------------------+-----------------------
-            | distribution        | full
-            | vectorized          | true
-  filter    |                     |
-   │        | filter              | end_time IS NOT NULL
-   └── scan |                     |
-            | estimated row count | 31337
-            | table               | rides@primary
-            | spans               | FULL SCAN
-(8 rows)
-~~~
-
-You can create a partial index that excludes these rows, making queries that filter out the non-`NULL` values more efficient.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON rides (city, revenue) WHERE end_time IS NOT NULL;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM rides;
-~~~
-
-~~~
-  table_name |                  index_name                   | non_unique | seq_in_index | column_name  | direction | storing | implicit
--------------+-----------------------------------------------+------------+--------------+--------------+-----------+---------+-----------
-  rides      | primary                                       |   false    |            1 | city         | ASC       |  false  |  false
-  rides      | primary                                       |   false    |            2 | id           | ASC       |  false  |  false
-...
-  rides      | rides_city_revenue_idx                        |    true    |            1 | city         | ASC       |  false  |  false
-  rides      | rides_city_revenue_idx                        |    true    |            2 | revenue      | ASC       |  false  |  false
-  rides      | rides_city_revenue_idx                        |    true    |            3 | id           | ASC       |  false  |   true
-(12 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT (city, revenue) FROM rides WHERE end_time IS NOT NULL;
-~~~
-
-~~~
-    tree    |        field        |                 description
-------------+---------------------+-----------------------------------------------
-            | distribution        | full
-            | vectorized          | false
-  render    |                     |
-   └── scan |                     |
-            | estimated row count | 5822
-            | table               | rides@rides_city_revenue_idx (partial index)
-            | spans               | FULL SCAN
-(7 rows)
-~~~
-
-
-### Create a partial index that enforces uniqueness on a subset of rows
-
-Suppose that you want to constrain a subset of the rows in a table, such that all values for a particular column in the subset are unique. For example, let's say that every user in New York City must have a unique name.
-
-You can do this efficiently with a [unique partial index](#unique-partial-indexes):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE UNIQUE INDEX ON users (name) WHERE city='new york';
-~~~
-
-This creates a partial index and a [`UNIQUE` constraint](unique.html) on just the subset of rows where `city='new york'`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id, name FROM users WHERE city='new york' LIMIT 3;
-~~~
-
-~~~
-                   id                  |       name
----------------------------------------+-------------------
-  8647a7cf-4af0-4c82-9344-224097f87b1a | Andre Sanchez
-  598eaab2-5200-40cb-8e19-244d49f3f63a | Austin Meyer
-  147ae147-ae14-4b00-8000-000000000004 | Catherine Nelson
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users(id, city, name) VALUES (gen_random_uuid(), 'new york', 'Andre Sanchez');
-~~~
-
-~~~
-ERROR: duplicate key value (name)=('Andre Sanchez') violates unique constraint "users_name_key"
-SQLSTATE: 23505
-~~~
-
-Because the unique partial index predicate only implies the rows where `city='new york'`, the `UNIQUE` constraint does not apply to all rows in the table.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users(id, city, name) VALUES (gen_random_uuid(), 'seattle', 'Andre Sanchez');
-~~~
-
-~~~
-INSERT 1
-~~~
-
-## See also
-
-- [Indexes](indexes.html)
-- [`CREATE INDEX`](create-index.html)
-- [`DROP INDEX`](drop-index.html)
-- [`RENAME INDEX`](rename-index.html)
-- [`SHOW INDEX`](show-index.html)
-- [SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/partition-by.md b/src/current/v20.2/partition-by.md
deleted file mode 100644
index 6f65931f406..00000000000
--- a/src/current/v20.2/partition-by.md
+++ /dev/null
@@ -1,169 +0,0 @@
----
-title: PARTITION BY
-summary: Use the PARTITION BY statement to partition, re-partition, or un-partition a table or secondary index.
-toc: true
----
-
-`PARTITION BY` is a subcommand of [`ALTER TABLE`](alter-table.html) and [`ALTER INDEX`](alter-index.html) that is used to partition, re-partition, or un-partition a table or secondary index. After defining partitions, [`CONFIGURE ZONE`](configure-zone.html) is used to control the replication and placement of partitions.
-
-{{site.data.alerts.callout_info}}
-[Partitioning](partitioning.html) is an [Enterprise-only](enterprise-licensing.html) feature. If you are looking for the `PARTITION BY` used in SQL window functions, see [Window Functions](window-functions.html).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Primary key requirements
-
-The [primary key required for partitioning](partitioning.html#partition-using-primary-key) is different from the conventional primary key: The unique identifier in the primary key must be prefixed with all columns you want to partition and subpartition the table on, in the order in which you want to nest your subpartitions.
-
-If the primary key in your existing table does not meet the requirements, you can change the primary key with an [`ALTER TABLE ... PRIMARY KEY` statement](alter-primary-key.html).
-
-## Synopsis
-
-**alter_table_partition_by_stmt ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/alter_table_partition_by.html %}
-</div>
-
-**alter_index_partition_by_stmt ::=**
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/alter_index_partition_by.html %}
-</div>
-
-## Parameters
-
-Parameter | Description |
------------|-------------|
-`table_name` | The name of the table you want to define partitions for.
-`index_name` | The name of the index you want to define partitions for.
-`name_list` | List of columns you want to define partitions on (in the order they are defined in the primary key).
-`list_partitions` | Name of list partition followed by the list of values to be included in the partition.
-`range_partitions` | Name of range partition followed by the range of values to be included in the partition.
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the table.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-
-{% include {{page.version.version}}/sql/querying-partitions.md %}
-
-## Examples
-
-### Define a list partition on a table or secondary index
-
-Suppose we have a table called `students_by_list`, and secondary index on the table called `name_idx`, in a global online learning portal, and the primary key of the table is defined as `(country, id)`. We can define partitions on the table and index by list:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE students_by_list PARTITION BY LIST (country) (
-    PARTITION north_america VALUES IN ('CA','US'),
-    PARTITION australia VALUES IN ('AU','NZ'),
-    PARTITION DEFAULT VALUES IN (default)
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX students_by_list@name_idx PARTITION BY LIST (country) (
-    PARTITION north_america VALUES IN ('CA','US'),
-    PARTITION australia VALUES IN ('AU','NZ'),
-    PARTITION DEFAULT VALUES IN (default)
-  );
-~~~
-
-### Define a range partition on a table or secondary index
-
-Suppose we have another table called `students_by_range`, also with a secondary index called `name_idx`, and the primary key of the table is defined as `(expected_graduation_date, id)`. We can define partitions on the table and index by range:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE students_by_range PARTITION BY RANGE (expected_graduation_date) (
-    PARTITION graduated VALUES FROM (MINVALUE) TO ('2017-08-15'),
-    PARTITION current VALUES FROM ('2017-08-15') TO (MAXVALUE)
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX students_by_range@name_idx PARTITION BY RANGE (expected_graduation_date) (
-    PARTITION graduated VALUES FROM (MINVALUE) TO ('2017-08-15'),
-    PARTITION current VALUES FROM ('2017-08-15') TO (MAXVALUE)
-  );
-~~~
-
-### Define subpartitions on a table or secondary index
-
-Suppose we have an yet another table named `students`, again with a secondary index called `name_idx`, and the primary key is defined as `(country, expected_graduation_date, id)`. We can define partitions and subpartitions on the table and index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE students PARTITION BY LIST (country) (
-    PARTITION australia VALUES IN ('AU','NZ') PARTITION BY RANGE (expected_graduation_date) (
-      PARTITION graduated_au VALUES FROM (MINVALUE) TO ('2017-08-15'),
-      PARTITION current_au VALUES FROM ('2017-08-15') TO (MAXVALUE)
-    ),
-    PARTITION north_america VALUES IN ('US','CA') PARTITION BY RANGE (expected_graduation_date) (
-      PARTITION graduated_us VALUES FROM (MINVALUE) TO ('2017-08-15'),
-      PARTITION current_us VALUES FROM ('2017-08-15') TO (MAXVALUE)
-    )
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX students@name_idx PARTITION BY LIST (country) (
-    PARTITION australia VALUES IN ('AU','NZ') PARTITION BY RANGE (expected_graduation_date) (
-      PARTITION graduated_au VALUES FROM (MINVALUE) TO ('2017-08-15'),
-      PARTITION current_au VALUES FROM ('2017-08-15') TO (MAXVALUE)
-    ),
-    PARTITION north_america VALUES IN ('US','CA') PARTITION BY RANGE (expected_graduation_date) (
-      PARTITION graduated_us VALUES FROM (MINVALUE) TO ('2017-08-15'),
-      PARTITION current_us VALUES FROM ('2017-08-15') TO (MAXVALUE)
-    )
-  );
-~~~
-
-### Repartition a table or secondary index
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE students_by_range PARTITION BY RANGE (expected_graduation_date) (
-    PARTITION graduated VALUES FROM (MINVALUE) TO ('2018-08-15'),
-    PARTITION current VALUES FROM ('2018-08-15') TO (MAXVALUE)
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX students_by_range@name_idx PARTITION BY RANGE (expected_graduation_date) (
-    PARTITION graduated VALUES FROM (MINVALUE) TO ('2018-08-15'),
-    PARTITION current VALUES FROM ('2018-08-15') TO (MAXVALUE)
-  );
-~~~
-
-### Unpartition a table or secondary index
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE students PARTITION BY NOTHING;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX students@name_idx PARTITION BY NOTHING;
-~~~
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`ALTER INDEX`](alter-index.html)
-- [Define Table Partitions](partitioning.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [`SHOW PARTITIONS`](show-partitions.html)
diff --git a/src/current/v20.2/partitioning.md b/src/current/v20.2/partitioning.md
deleted file mode 100644
index 4e0d5355c34..00000000000
--- a/src/current/v20.2/partitioning.md
+++ /dev/null
@@ -1,726 +0,0 @@
----
-title: Define Table Partitions
-summary: Partitioning is an Enterprise feature that gives you row-level control of how and where your data is stored.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-CockroachDB allows you to define table partitions, thus giving you row-level control of how and where your data is stored. Partitioning enables you to reduce latencies and costs and can assist in meeting regulatory requirements for your data.
-
-{{site.data.alerts.callout_info}}
-Table partitioning is an [Enterprise-only](enterprise-licensing.html) feature. For insight into how to use this feature to get low latency reads and writes in multi-region deployments, see the [Geo-Partitioned Replicas](topology-geo-partitioned-replicas.html) and [Geo-Partitioned Leaseholders](topology-geo-partitioned-leaseholders.html) topology patterns.
-{{site.data.alerts.end}}
-
-## Why use table partitioning
-
-Table partitioning helps you reduce latency and cost:
-
-- **Geo-partitioning** allows you to keep user data close to the user, which reduces the distance that the data needs to travel, thereby **reducing latency**. To geo-partition a table, define location-based partitions while creating a table, create location-specific zone configurations, and apply the zone configurations to the corresponding partitions.
-- **Archival-partitioning** allows you to store infrequently-accessed data on slower and cheaper storage, thereby **reducing costs**. To archival-partition a table, define frequency-based partitions while creating a table, create frequency-specific zone configurations with appropriate storage devices constraints, and apply the zone configurations to the corresponding partitions.
-
-## How it works
-
-Table partitioning involves a combination of CockroachDB features:
-
-- [Node Attributes](#node-attributes)
-- [Enterprise License](#enterprise-license)
-- [Table Creation](#table-creation)
-- [Replication Zones](#replication-zones)
-
-### Node attributes
-
-To store partitions in specific locations (e.g., geo-partitioning), or on machines with specific attributes (e.g., archival-partitioning), the nodes of your cluster must be [started](cockroach-start.html) with the relevant flags:
-
-- Use the `--locality` flag to assign key-value pairs that describe the location of a node, for example, `--locality=region=east,az=us-east-1`.
-- Use the `--attrs` flag to specify node capability, which might include specialized hardware or number of cores, for example, `--attrs=ram:64gb`.
-- Use the `attrs` field of the `--store` flag to specify disk type or capability, for example,`--store=path=/mnt/ssd01,attrs=ssd`.
-
-For more details about these flags, see the [`cockroach start`](cockroach-start.html) documentation.
-
-### Enterprise license
-
-You must have a valid Enterprise license to use table partitioning features. For details about requesting and setting a trial or full Enterprise license, see [Enterprise Licensing](enterprise-licensing.html).
-
-Note that the following features do not work with an **expired license**:
-
-- Creating new table partitions or adding new zone configurations for partitions
-- Changing the partitioning scheme on any table or index
-- Changing the zone config for a partition
-
-However, the following features continue to work even with an expired Enterprise license:
-
-- Querying a partitioned table (for example, `SELECT foo PARTITION`)
-- Inserting or updating data in a partitioned table
-- Dropping a partitioned table
-- Unpartitioning a partitioned table
-- Making non-partitioning changes to a partitioned table (for example, adding a column/index/foreign key/check constraint)
-
-### Table creation
-
-You can define partitions and subpartitions over one or more columns of a table. During [table creation](create-table.html), you declare which values belong to each partition in one of two ways:
-
-- **List partitioning**: Enumerate all possible values for each partition. List partitioning is a good choice when the number of possible values is small. List partitioning is well-suited for geo-partitioning.
-- **Range partitioning**: Specify a contiguous range of values for each partition by specifying lower and upper bounds. Range partitioning is a good choice when the number of possible values is too large to explicitly list out. Range partitioning is well-suited for archival-partitioning.
-
-#### Partition by list
-
-[`PARTITION BY LIST`](partition-by.html) lets you map one or more tuples to a partition.
-
-To partition a table by list, use the [`PARTITION BY LIST`](partition-by.html) syntax while creating the table. While defining a list partition, you can also set the `DEFAULT` partition that acts as a catch-all if none of the rows match the requirements for the defined partitions.
-
-See [Partition by List](#define-table-partitions-by-list) example below for more details.
-
-#### Partition by range
-
-[`PARTITION BY RANGE`](partition-by.html) lets you map ranges of tuples to a partition.
-
-To define a table partition by range, use the [`PARTITION BY RANGE`](partition-by.html) syntax while creating the table.  While defining a range partition, you can use CockroachDB-defined `MINVALUE` and `MAXVALUE` parameters to define the lower and upper bounds of the ranges respectively.
-
-{{site.data.alerts.callout_info}}The lower bound of a range partition is inclusive, while the upper bound is exclusive. For range partitions, <code>NULL</code> is considered less than any other data, which is consistent with our key encoding ordering and <code>ORDER BY</code> behavior.{{site.data.alerts.end}}
-
-Partition values can be any SQL expression, but it’s only evaluated once. If you create a partition with value `< (now() - '1d')` on 2017-01-30, it would be contain all values less than 2017-01-29. It would not update the next day, it would continue to contain values less than 2017-01-29.
-
-See [Partition by Range](#define-table-partitions-by-range) example below for more details.
-
-#### Partition using primary key
-
-The primary key required for partitioning is different from the conventional primary key. To define the primary key for partitioning, prefix the unique identifier(s) in the primary key with all columns you want to partition and subpartition the table on, in the order in which you want to nest your subpartitions.
-
-For instance, consider the database of a global online learning portal that has a table for students of all the courses across the world. If you want to geo-partition the table based on the countries of the students, then the primary key needs to be defined as:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE students (
-    id INT DEFAULT unique_rowid(),
-    name STRING,
-    email STRING,
-    country STRING,
-    expected_graduation_date DATE,   
-    PRIMARY KEY (country, id));
-~~~
-
-**Primary Key Considerations**
-
-- The order in which the columns are defined in the primary key is important. The partitions and subpartitions need to follow that order. In the example of the online learning portal, if you define the primary key as `(country, expected_graduation_date, id)`, the primary partition is by `country`, and then subpartition is by `expected_graduation_date`. You cannot skip `country` and partition by `expected_graduation_date`.
-
-#### Partition using secondary index
-
-The primary key discussed above has two drawbacks:
-
-- It does not enforce that the identifier column is globally unique.
-- It does not provide fast lookups on the identifier.
-
-To ensure uniqueness or fast lookups, create a [secondary index](indexes.html) on the identifier.
-
-Indexes are not required to be partitioned, but creating a non-partitioned index on a partitioned table may not perform well.
-
- When you create a non-partitioned index on a partitioned table, CockroachDB sends a [`NOTICE` message](https://www.postgresql.org/docs/current/plpgsql-errors-and-messages.html) to the client stating that creating a non-partitioned index on a partitioned table may not perform well.
-
-### Replication zones
-
-On their own, partitions are inert and simply apply a label to the rows of the table that satisfy the criteria of the defined partitions. Applying functionality to a partition requires creating and applying [replication zone](configure-replication-zones.html) to the corresponding partitions.
-
-CockroachDB uses the most granular zone config available. Zone configs that target a partition are considered more granular than those that target a table or index, which in turn are considered more granular than those that target a database.
-
-
-{% include {{page.version.version}}/sql/querying-partitions.md %}
-
-## Examples
-
-### Define table partitions by list
-
-Consider a global online learning portal, RoachLearn, that has a database containing a table of students across the world. Suppose we have three availability zone: one in the United States, one in Germany, and another in Australia. To reduce latency, we want to keep the students' data closer to their locations:
-
-- We want to keep the data of the students located in the United States and Canada in the United States availability zone.
-- We want to keep the data of students located in Germany and Switzerland in the German availability zone.
-- We want to keep the data of students located in Australia and New Zealand in the Australian availability zone.
-
-#### Step 1. Identify the partitioning method
-
-We want to geo-partition the table to keep the students' data closer to their locations. We can achieve this by partitioning on `country` and using the `PARTITION BY LIST` syntax.
-
-#### Step 2. Start each node with its availability zone location specified in the `--locality` flag
-
-1. Start 3 nodes in the US availability zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=us \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --store=node1 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=us \
-    --listen-addr=localhost:26258 \
-    --http-addr=localhost:8081 \
-    --store=node2 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=us \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --store=node3 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-2. Initialize the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init \
-    --insecure \
-    --host=localhost:26257
-    ~~~
-
-3. Add 3 nodes in the German availability zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=de \
-    --listen-addr=localhost:26260 \
-    --http-addr=localhost:8083 \
-    --store=node4 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=de \
-    --listen-addr=localhost:26261 \
-    --http-addr=localhost:8084 \
-    --store=node5 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=de \
-    --listen-addr=localhost:26262 \
-    --http-addr=localhost:8085 \
-    --store=node6 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-3. Add 3 nodes in the Australian availability zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=aus \
-    --listen-addr=localhost:26263 \
-    --http-addr=localhost:8086 \
-    --store=node7 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=aus \
-    --listen-addr=localhost:26264 \
-    --http-addr=localhost:8087 \
-    --store=node8 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --listen-addr=localhost \
-    --locality=region=aus \
-    --listen-addr=localhost:26265 \
-    --http-addr=localhost:8088 \
-    --store=node9 \
-    --background \
-    --join=localhost:26257,localhost:26258,localhost:26259
-    ~~~
-
-
-#### Step 3. Request and set a trial Enterprise license
-
-See [Set the Trial or Enterprise License Key](licensing-faqs.html#set-a-license).
-
-#### Step 4. Create the `roachlearn` database and `students` table
-
-1. Open the CockroachDB SQL shell:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=localhost:26257
-    ~~~
-
-2. Create the database and set it as current:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE roachlearn;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET DATABASE = roachlearn;
-    ~~~
-
-3. Create the table with the appropriate partitions:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE students (
-        id INT DEFAULT unique_rowid(),
-        name STRING,
-        email STRING,
-        country STRING,
-        expected_graduation_date DATE,   
-        PRIMARY KEY (country, id))
-        PARTITION BY LIST (country) (
-          PARTITION north_america VALUES IN ('CA','US'),
-          PARTITION europe VALUES IN ('DE', 'CH'),
-          PARTITION australia VALUES IN ('AU','NZ'),
-          PARTITION DEFAULT VALUES IN (default)
-        );
-    ~~~
-
-    Alternatively, you can create and partition the table as separate steps:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE students (
-        id INT DEFAULT unique_rowid(),
-        name STRING,
-        email STRING,
-        country STRING,
-        expected_graduation_date DATE,   
-        PRIMARY KEY (country, id));
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE students
-      PARTITION BY LIST (country) (
-        PARTITION north_america VALUES IN ('CA','US'),
-        PARTITION europe VALUES IN ('DE', 'CH'),
-        PARTITION australia VALUES IN ('AU','NZ'),
-        PARTITION DEFAULT VALUES IN (default)
-      );
-    ~~~    
-
-#### Step 5. Create and apply corresponding replication zones
-
-To create replication zone and apply them to corresponding partitions, use the [`ALTER PARTITION ... CONFIGURE ZONE`](configure-zone.html) statement:
-
-1. Create a replication zone for the `north_america` partition and constrain its data to the US availability zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION north_america OF TABLE students
-        CONFIGURE ZONE USING constraints='[+region=us]';
-    ~~~
-
-2. Create a replication zone for the `europe` partition and constrain its data to the German availability zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION europe OF TABLE students
-        CONFIGURE ZONE USING constraints='[+region=de]';
-    ~~~
-
-3. Create a replication zone for the `australia` partition and constrain its data to the Australian availability zone:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION australia OF TABLE students
-        CONFIGURE ZONE USING constraints='[+region=aus]';
-    ~~~
-
-4. After creating these replication zones, you can view them using the [`SHOW ZONE CONFIGURATION`](show-zone-configurations.html) statement:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW ZONE CONFIGURATION FOR PARTITION north_america OF TABLE students;
-    ~~~
-
-    ~~~
-                   target                   |                            raw_config_sql
-+-------------------------------------------+----------------------------------------------------------------------+
-  PARTITION north_america OF TABLE students | ALTER PARTITION north_america OF TABLE students CONFIGURE ZONE USING
-                                            |     range_min_bytes = 134217728,
-                                            |     range_max_bytes = 536870912,
-                                            |     gc.ttlseconds = 90000,
-                                            |     num_replicas = 3,
-                                            |     constraints = '[+region=us]',
-                                            |     lease_preferences = '[]'
-(1 row)
-    ~~~
-
-
-#### Step 6. Check replica distribution
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW RANGES FROM TABLE roachlearn.students] WHERE "start_key" IS NOT NULL AND "start_key" NOT LIKE '%Prefix%';
-~~~
-
-You should see the following output:
-
-~~~
-  start_key |     end_key     | range_id | replicas | lease_holder
-+-----------+-----------------+----------+----------+--------------+
-  /"AU"     | /"AU"/PrefixEnd |       35 | {7,8,9}  |            8
-  /"CA"     | /"CA"/PrefixEnd |       31 | {1,2,3}  |            1
-  /"CH"     | /"CH"/PrefixEnd |       51 | {4,5,6}  |            5
-  /"DE"     | /"DE"/PrefixEnd |       53 | {4,5,6}  |            5
-  /"NZ"     | /"NZ"/PrefixEnd |       55 | {7,8,9}  |            8
-  /"US"     | /"US"/PrefixEnd |       33 | {1,2,3}  |            1
-(6 rows)
-~~~
-
-For reference, here's how the nodes map to zones:
-
-Node IDs | Zone
----------|-----
-1-3 | `north_america`
-4-6 | `europe`
-7-9 | `australia`
-
-We can see that, after partitioning, the replicas for `US` and `CA`-based students are located on nodes 1-3 in `north_america`, the replicas for `DE` and `CH`-based students are located on nodes 4-6 in `europe`, and the replicas for `AU` and `NZ`-based students are located on nodes 7-9 in `australia`.
-
-### Show partitions and zone constraints
-
-To retrieve table partitions, you can use the [`SHOW PARTITIONS`](show-partitions.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW PARTITIONS FROM TABLE students;
-~~~
-
-~~~
-  database_name | table_name | partition_name | parent_partition | column_names |    index_name    | partition_value | zone_constraints
-+---------------+------------+----------------+------------------+--------------+------------------+-----------------+------------------+
-  roachlearn    | students   | north_america  | NULL             | country      | students@primary | ('CA'), ('US')  | [+region=us]
-  roachlearn    | students   | europe         | NULL             | country      | students@primary | ('DE'), ('CH')  | [+region=de]
-  roachlearn    | students   | australia      | NULL             | country      | students@primary | ('AU'), ('NZ')  | [+region=aus]
-  roachlearn    | students   | default        | NULL             | country      | students@primary | (DEFAULT)       | NULL
-(4 rows)
-~~~
-
-You can also view partitions by [database](show-partitions.html#show-partitions-by-database) and [index](show-partitions.html#show-partitions-by-index).
-
-{% include {{page.version.version}}/sql/crdb-internal-partitions.md %}
-
-### Define table partitions by range
-
-Suppose we want to store the data of current students on fast and expensive storage devices (e.g., SSD) and store the data of the graduated students on slower, cheaper storage devices (e.g., HDD).
-
-#### Step 1. Identify the partitioning method
-
-We want to archival-partition the table to keep newer data on faster devices and older data on slower devices. We can achieve this by partitioning the table by date and using the `PARTITION BY RANGE` syntax.
-
-#### Step 2. Set the Enterprise license
-
-To set the Enterprise license, see [Set the Trial or Enterprise License Key](licensing-faqs.html#set-a-license).
-
-#### Step 3. Start each node with the appropriate storage device specified in the `--store` flag
-
-1. Start the first node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start --insecure \
-    --store=path=/mnt/1,attrs=ssd \
-    --advertise-addr=<node1 hostname> \
-    --join=<node1 hostname>,<node2 hostname>
-    ~~~
-
-2. Start the second node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start --insecure \
-    --store=path=/mnt/2,attrs=hdd \
-    --advertise-addr=<node2 hostname> \
-    --join=<node1 hostname>,<node2 hostname>
-    ~~~
-
-3. Initialize the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init \
-    --insecure \
-    --host=<address of any node>
-    ~~~
-
-#### Step 4. Create a table with the appropriate partitions
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE students_by_range (
-   id INT DEFAULT unique_rowid(),
-   name STRING,
-   email STRING,                                                                                           
-   country STRING,
-   expected_graduation_date DATE,                                                                                      
-   PRIMARY KEY (expected_graduation_date, id))
-   PARTITION BY RANGE (expected_graduation_date)
-      (PARTITION graduated VALUES FROM (MINVALUE) TO ('2017-08-15'),
-      PARTITION current VALUES FROM ('2017-08-15') TO (MAXVALUE));
-~~~
-
-#### Step 5. Create and apply corresponding zone configurations
-
-To create zone configurations and apply them to corresponding partitions, use the [`ALTER PARTITION ... CONFIGURE ZONE`](configure-zone.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION current OF TABLE students_by_range
-    CONFIGURE ZONE USING constraints='[+ssd]';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION graduated OF TABLE students_by_range
-    CONFIGURE ZONE USING constraints='[+hdd]';
-~~~
-
-#### Step 6. Check replica distribution
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGES FROM TABLE students_by_range;
-~~~
-
-You should see the following output:
-
-~~~
-  start_key | end_key | range_id | replicas | lease_holder | locality
-+-----------+---------+----------+----------+--------------+-----------+
-  NULL      | /17393  |       52 | {2,5,8}  |            5 | region=de
-  /17393    | NULL    |       53 | {6,7,10} |            6 | region=de
-(2 rows)
-~~~
-
-### Define subpartitions on a Table
-
-A list partition can itself be partitioned, forming a subpartition. There is no limit on the number of levels of subpartitioning; that is, list partitions can be infinitely nested.
-
-{{site.data.alerts.callout_info}}Range partitions cannot be subpartitioned.{{site.data.alerts.end}}
-
-Going back to RoachLearn's scenario, suppose we want to do all of the following:
-
-- Keep the students' data close to their location.
-- Store the current students' data on faster storage devices.
-- Store the graduated students' data on slower, cheaper storage devices (example: HDD).
-
-#### Step 1. Identify the Partitioning method
-
-We want to geo-partition as well as archival-partition the table. We can achieve this by partitioning the table first by location and then by date.
-
-#### Step 2. Start each node with the appropriate storage device specified in the `--store` flag
-
-Start a node in the US availability zone:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---advertise-addr=<node1 hostname> \
---locality=az=us1 \
---store=path=/mnt/1,attrs=ssd \
---store=path=/mnt/2,attrs=hdd \
---join=<node1 hostname>,<node2 hostname>
-~~~
-
-Start a node in the AUS availability zone:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start \
---insecure \
---advertise-addr=<node2 hostname> \
---locality=az=aus1 \
---store=path=/mnt/3,attrs=ssd \
---store=path=/mnt/4,attrs=hdd \
---join=<node1 hostname>,<node2 hostname>
-~~~
-
-Initialize the cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach init --insecure --host=<address of any node>
-~~~
-
-#### Step 3. Set the Enterprise license
-
-To set the Enterprise license, see [Set the Trial or Enterprise License Key](licensing-faqs.html#set-a-license).
-
-#### Step 4. Create a table with the appropriate partitions
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE students (
-    id INT DEFAULT unique_rowid(),
-    name STRING,
-    email STRING,
-    country STRING,
-    expected_graduation_date DATE,
-    PRIMARY KEY (country, expected_graduation_date, id))
-    PARTITION BY LIST (country)(
-        PARTITION australia VALUES IN ('AU','NZ') PARTITION BY RANGE (expected_graduation_date)(PARTITION graduated_au VALUES FROM (MINVALUE) TO ('2017-08-15'), PARTITION current_au VALUES FROM ('2017-08-15') TO (MAXVALUE)),
-        PARTITION north_america VALUES IN ('US','CA') PARTITION BY RANGE (expected_graduation_date)(PARTITION graduated_us VALUES FROM (MINVALUE) TO ('2017-08-15'), PARTITION current_us VALUES FROM ('2017-08-15') TO (MAXVALUE))
-    );
-~~~
-
-Subpartition names must be unique within a table. In our example, even though `graduated` and `current` are sub-partitions of distinct partitions, they still need to be uniquely named. Hence the names `graduated_au`, `graduated_us`, and `current_au` and `current_us`.
-
-#### Step 5. Create and apply corresponding zone configurations
-
-To create zone configurations and apply them to corresponding partitions, use the [`ALTER PARTITION ... CONFIGURE ZONE`](configure-zone.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION current_us OF TABLE students
-    CONFIGURE ZONE USING constraints='[+ssd,+az=us1]';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION graduated_us OF TABLE students CONFIGURE ZONE
-    USING constraints='[+hdd,+az=us1]';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION current_au OF TABLE students
-    CONFIGURE ZONE USING constraints='[+ssd,+az=aus1]';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION graduated_au OF TABLE students CONFIGURE ZONE
-    USING constraints='[+hdd,+az=aus1]';
-~~~
-
-#### Step 6. Verify table partitions
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGES FROM TABLE students;
-~~~
-
-You should see the following output:
-
-~~~
-+-----------------+-----------------+----------+----------+--------------+
-| start_key       | end_key         | range_id | replicas | lease_holder |
-+-----------------+-----------------+----------+----------+--------------+
-| NULL            | /"AU"           |      260 | {1,2,3}  |            1 |
-| /"AU"           | /"AU"/17393     |      268 | {1,2,3}  |            1 |
-| /"AU"/17393     | /"AU"/PrefixEnd |      266 | {1,2,3}  |            1 |
-| /"AU"/PrefixEnd | /"CA"           |      267 | {1,2,3}  |            1 |
-| /"CA"           | /"CA"/17393     |      265 | {1,2,3}  |            1 |
-| /"CA"/17393     | /"CA"/PrefixEnd |      261 | {1,2,3}  |            1 |
-| /"CA"/PrefixEnd | /"NZ"           |      262 | {1,2,3}  |            3 |
-| /"NZ"           | /"NZ"/17393     |      284 | {1,2,3}  |            3 |
-| /"NZ"/17393     | /"NZ"/PrefixEnd |      282 | {1,2,3}  |            3 |
-| /"NZ"/PrefixEnd | /"US"           |      283 | {1,2,3}  |            3 |
-| /"US"           | /"US"/17393     |      281 | {1,2,3}  |            3 |
-| /"US"/17393     | /"US"/PrefixEnd |      263 | {1,2,3}  |            1 |
-| /"US"/PrefixEnd | NULL            |      264 | {1,2,3}  |            1 |
-+-----------------+-----------------+----------+----------+--------------+
-(13 rows)
-
-Time: 11.586626ms
-~~~
-
-### Repartition a Table
-
-Consider the partitioned table of students of RoachLearn. Suppose the table has been partitioned on range to store the current students on fast and expensive storage devices (example: SSD) and store the data of the graduated students on slower, cheaper storage devices(example: HDD). Now suppose we want to change the date after which the students will be considered current to `2018-08-15`. We can achieve this by using the [`PARTITION BY`](partition-by.html) subcommand of the [`ALTER TABLE`](alter-table.html) command.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE students_by_range PARTITION BY RANGE (expected_graduation_date) (
-    PARTITION graduated VALUES FROM (MINVALUE) TO ('2018-08-15'),
-    PARTITION current VALUES FROM ('2018-08-15') TO (MAXVALUE));
-~~~
-
-### Unpartition a Table
-
-You can remove the partitions on a table by using the [`PARTITION BY NOTHING`](partition-by.html) syntax:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE students PARTITION BY NOTHING;
-~~~
-
-### Show the replication zone for a partition
-
-To view the replication zone for a partition, use the [`SHOW ZONE CONFIGURATION`](show-zone-configurations.html) statement.
-
-## Locality–resilience tradeoff
-
-There is a tradeoff between making reads/writes fast and surviving failures. Consider a partition with three replicas of `roachlearn.students` for Australian students.
-
-- If only one replica is pinned to an Australian availability zone, then reads may be fast (via leases follow the workload) but writes will be slow.
-- If two replicas are pinned to an Australian availability zone, then reads and writes will be fast (as long as the cross-ocean link has enough bandwidth that the third replica doesn’t fall behind). If those two replicas are in the same availability zone, then the loss of one availability zone can lead to data unavailability, so some deployments may want two separate Australian availability zones.
-- If all three replicas are in Australian availability zones, then three Australian availability zones are needed to be resilient to an availability zone loss.
-
-## How CockroachDB's partitioning differs from other databases
-
-Other databases use partitioning for three additional use cases: secondary indexes, sharding, and bulk loading/deleting. CockroachDB addresses these use-cases not by using partitioning, but in the following ways:
-
-- **Changes to secondary indexes:** CockroachDB solves these changes through online schema changes. Online schema changes are a superior feature to partitioning because they require zero-downtime and eliminate the potential for consistency problems.
-- **Sharding:** CockroachDB automatically shards data as a part of its distributed database architecture.
-- **Bulk Loading & Deleting:** CockroachDB does not have a feature that supports this use case as of now.
-
-## Known limitations
-
-- {% include {{ page.version.version }}/known-limitations/partitioning-with-placeholders.md %}
-
-- CockroachDB does not support partitioning [GIN indexes](inverted-indexes.html), including [spatial indexes](spatial-indexes.html). See [tracking issue](https://github.com/cockroachdb/cockroach/issues/43643).
-
-- Partitions cannot be created on columns of type `ENUM`. See [tracking issue](https://github.com/cockroachdb/cockroach/issues/55342).
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [`ALTER TABLE`](alter-table.html)
-- [Computed Columns](computed-columns.html)
diff --git a/src/current/v20.2/pause-job.md b/src/current/v20.2/pause-job.md
deleted file mode 100644
index f334484e807..00000000000
--- a/src/current/v20.2/pause-job.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: PAUSE JOB
-summary: The PAUSE JOB statement lets you temporarily halt the process of potentially long-running jobs.
-toc: true
----
-
-The `PAUSE JOB` [statement](sql-statements.html) lets you pause the following types of jobs:
-
-- [`IMPORT`](import.html) jobs
-- [`BACKUP`](backup.html) and [`RESTORE`](restore.html) jobs
-- [User-created table statistics](create-statistics.html) jobs
-- [Automatic table statistics](cost-based-optimizer.html#table-statistics) jobs
-- [Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html)
-- [Schema change](online-schema-changes.html) jobs
-- <span class="version-tag">New in v20.2:</span> [Scheduled backup](manage-a-backup-schedule.html) jobs
-
-After pausing jobs, you can resume them with [`RESUME JOB`](resume-job.html).
-
-## Required privileges
-
-To pause a job, the user must be a member of the `admin` role or must have the [`CONTROLJOB`](create-user.html#create-a-user-that-can-pause-resume-and-cancel-non-admin-jobs) parameter set.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/pause_job.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`job_id` | The ID of the job you want to pause, which can be found with [`SHOW JOBS`](show-jobs.html).
-`select_stmt` | A [selection query](selection-queries.html) that returns `job_id`(s) to pause.
-`for_schedules_clause` | <span class="version-tag">New in v20.2:</span> The schedule you want to pause jobs for. You can pause jobs for a specific schedule (`FOR SCHEDULE id`) or pause jobs for multiple schedules by nesting a [`SELECT` clause](select-clause.html) in the statement (`FOR SCHEDULES <select_clause>`). See the [examples](#pause-jobs-for-a-schedule) below.
-
-## Examples
-
-### Pause a single job
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW JOBS;
-~~~
-
-~~~
-      job_id     |  job_type |               description                 |...
------------------+-----------+-------------------------------------------+...
-  27536791415282 |  RESTORE  | RESTORE db.* FROM 'azure://backup/db/tbl' |...
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOB 27536791415282;
-~~~
-
-### Pause multiple jobs
-
-To pause multiple jobs, nest a [`SELECT` clause](select-clause.html) that retrieves `job_id`(s) inside the `PAUSE JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOBS (SELECT job_id FROM [SHOW JOBS]
-      WHERE user_name = 'maxroach');
-~~~
-
-All jobs created by `maxroach` will be paused.
-
-### Pause automatic table statistics jobs
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW AUTOMATIC JOBS;
-~~~
-
-~~~
-        job_id       |       job_type      |                    description                      |...
----------------------+---------------------+-----------------------------------------------------+...
-  438235476849557505 |  AUTO CREATE STATS  | Table statistics refresh for defaultdb.public.users |...
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOB 438235476849557505;
-~~~
-
-To permanently disable automatic table statistics jobs, disable the `sql.stats.automatic_collection.enabled` [cluster setting](cluster-settings.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.stats.automatic_collection.enabled = false;
-~~~
-
-### Pause jobs for a schedule
-
-<span class="version-tag">New in v20.2:</span> To pause jobs for a specific [backup schedule](create-schedule-for-backup.html), use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOBS FOR SCHEDULE 590204387299262465;
-~~~
-
-~~~
-PAUSE JOBS FOR SCHEDULES 1
-~~~
-
-You can also pause multiple schedules by nesting a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `PAUSE JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOBS FOR SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'test_schedule';
-~~~
-
-~~~
-PAUSE JOBS FOR SCHEDULES 2
-~~~
-
-## See also
-
-- [`RESUME JOB`](resume-job.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`IMPORT`](import.html)
-- [`CREATE CHANGEFEED`](create-changefeed.html)
diff --git a/src/current/v20.2/pause-schedules.md b/src/current/v20.2/pause-schedules.md
deleted file mode 100644
index 438554a0c92..00000000000
--- a/src/current/v20.2/pause-schedules.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: PAUSE SCHEDULES
-summary: The PAUSE SCHEDULES statement lets you temporarily halt the process of a backup schedule.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `PAUSE SCHEDULES` [statement](sql-statements.html) can be used to pause [backup schedules](create-schedule-for-backup.html).
-
-After pausing a schedule, you can resume it with [`RESUME SCHEDULES`](resume-schedules.html).
-
-## Required privileges
-
-Only members of the [`admin` role](authorization.html#default-roles) can pause a schedule. By default, the `root` user belongs to the `admin` role.
-
-## Synopsis
-
-~~~
-PAUSE SCHEDULES <selectclause>
-  select clause: select statement returning schedule id to pause.
-PAUSE SCHEDULE <scheduleID>
-~~~
-
-## Parameters
-
- Parameter     | Description
----------------+------------
-`selectclause` | A [selection query](selection-queries.html) that returns `id`(s) to pause.
-`scheduleID`   | The `id` of the schedule you want to pause, which can be found with [`SHOW SCHEDULES`](show-schedules.html).
-
-## Examples
-
-### Pause a single schedule
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE SCHEDULE 589963390487363585;
-~~~
-
-~~~
-PAUSE SCHEDULES 1
-~~~
-
-### Pause multiple schedules
-
-To pause multiple schedules, nest a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `PAUSE SCHEDULES` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'schedule_database';
-~~~
-
-~~~
-PAUSE SCHEDULES 4
-~~~
-
-In this example, all schedules with the label `schedule_database` are paused.
-
-## See also
-
-- [Manage a Backup Schedule](manage-a-backup-schedule.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`SHOW BACKUP`](show-backup.html)
-- [`SHOW SCHEDULES`](show-schedules.html)
-- [`RESUME SCHEDULES`](resume-schedules.html)
-- [`DROP SCHEDULES`](drop-schedules.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`RESUME JOB`](pause-job.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/performance-benchmarking-with-tpcc-large.md b/src/current/v20.2/performance-benchmarking-with-tpcc-large.md
deleted file mode 100644
index 82e9e825159..00000000000
--- a/src/current/v20.2/performance-benchmarking-with-tpcc-large.md
+++ /dev/null
@@ -1,495 +0,0 @@
----
-title: Performance Benchmarking with TPC-C
-summary: Learn how to benchmark CockroachDB against TPC-C with 81 nodes on `c5d.9xlarge` machines
-toc: true
-toc_not_nested: true
-key: performance-benchmarking-with-tpc-c-100k-warehouses.html
----
-
-This page shows you how to reproduce [CockroachDB's TPC-C performance benchmarking results](performance.html#scale) on commodity AWS hardware. Across all scales, CockroachDB can process tpmC (new order transactions per minute) at near maximum efficiency. Start by choosing the scale you're interested in:
-
-<div class="filters filters-big clearfix">
-  <a href="performance-benchmarking-with-tpcc-local.html"><button class="filter-button">Local</button></a>
-  <a href="performance-benchmarking-with-tpcc-small.html"><button class="filter-button">Small</button></a>
-  <a href="performance-benchmarking-with-tpcc-medium.html"><button class="filter-button">Medium</button></a>
-  <button class="filter-button current"><strong>Large</strong></button>
-</div>
-
-| Workload | Cluster size                       | Warehouses | Data size |
-|----------+------------------------------------+------------+-----------|
-| Local    | 3 nodes on your laptop             | 10         | 2 GB      |
-| Small    | 3 nodes on `c5d.4xlarge` machines  | 2500       | 200 GB    |
-| Medium   | 15 nodes on `c5d.4xlarge` machines | 13,000     | 1.04 TB   |
-| Large    | 81 nodes on `c5d.9xlarge` machines | 140,000    | 11.2 TB   |
-
-<span class="version-tag">New in v20.2</span>: CockroachDB can achieve a TPC-C run of 140k warehouses on the same cluster size used for 100k in version 19.2, a 40% improvement:
-
-<img src="{{ 'images/v20.2/tpcc140k.png' | relative_url }}" alt="TPC-C 140,000" style="border:1px solid #eee;max-width:100%" />
-
-## Before you begin
-
-- [Review TPC-C concepts](#review-tpc-c-concepts)
-- [Request a trial license](#request-a-trial-license)
-
-### Review TPC-C concepts
-
-TPC-C provides the most realistic and objective measure for OLTP performance at various scale factors. Before you get started, consider reviewing [what TPC-C is and how it is measured](performance.html#tpc-c).
-
-### Request a trial license
-
-Reproducing these TPC-C results involves using CockroachDB's [partitioning](partitioning.html) feature to ensure replicas for any given section of data are located on the same nodes that will be queried by the load generator for that section of data. Partitioning helps distribute the workload evenly across the cluster.
-
-The partitioning feature requires an Enterprise license, so [request a 30-day trial license](https://www.cockroachlabs.com/get-cockroachdb/enterprise/) before you get started.
-
-You should receive your trial license via email within a few minutes. You'll enable your license once your cluster is up-and-running.
-
-## Step 1. Set up the environment
-
-- [Provision VMs](#provision-vms)
-- [Configure your network](#configure-your-network)
-
-### Provision VMs
-
-1. [Create 86 VM instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html), 81 for CockroachDB nodes and 5 for the TPC-C workload.
-    - Create all instances in the same region and the same security group.
-    - Use the `c5d.9xlarge` machine type.
-    - Use [local SSD instance store volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#instance-store-volumes). Local SSDs are low latency disks attached to each VM, which maximizes performance. This configuration best resembles what a bare metal deployment would look like, with machines directly connected to one physical disk each. We do not recommend using network-attached block storage.
-
-2. Note the internal IP address of each instance. You'll need these addresses when starting the CockroachDB nodes.
-
-{{site.data.alerts.callout_danger}}
-This configuration is intended for performance benchmarking only. For production deployments, there are other important considerations, such as security, load balancing, and data location techniques to minimize network latency. For more details, see the [Production Checklist](recommended-production-settings.html).
-{{site.data.alerts.end}}
-
-### Configure your network
-
-CockroachDB requires TCP communication on two ports:
-
-- `26257` for inter-node communication (i.e., working as a cluster) and for the TPC-C workload to connect to nodes
-- `8080` for exposing your DB Console
-
-[Create inbound rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) for your security group:
-
-#### Inter-node and TPCC-to-node communication
-
- Field | Recommended Value
--------|-------------------
- Type | Custom TCP Rule
- Protocol | TCP
- Port Range | **26257**
- Source | The name of your security group (e.g., *sg-07ab277a*)
-
-#### DB Console
-
- Field | Recommended Value
--------|-------------------
- Type | Custom TCP Rule
- Protocol | TCP
- Port Range | **8080**
- Source | Your network's IP ranges
-
-## Step 2. Start CockroachDB
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-1. SSH to the first VM where you want to run a CockroachDB node.
-
-2. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-    If you get a permissions error, prefix the command with `sudo`.
-
-3. Run the [`cockroach start`](cockroach-start.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --advertise-addr=<node1 internal address> \
-    --join=<node1 internal address>,<node2 internal address>,<node3 internal address> \
-    --cache=.25 \
-    --locality=rack=0 \
-    --background
-    ~~~
-
-    Each node will start with a [locality](cockroach-start.html#locality) that includes an artificial "rack number" (e.g., `--locality=rack=0`). Use 81 racks for 81 nodes so that 1 node will be assigned to each rack.
-
-4. Repeat steps 1 - 3 for the other 80 VMs for CockroachDB nodes. Each time, be sure to:
-    - Adjust the `--advertise-addr` flag.
-    - Set the [`--locality`](cockroach-start.html#locality) flag to the appropriate "rack number", as described above.
-
-5. On any of the VMs with the `cockroach` binary, run the one-time [`cockroach init`](cockroach-init.html) command to join the first nodes into a cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --insecure --host=<address of any node on --join list>
-    ~~~
-
-## Step 3. Configure the cluster
-
-You'll be importing a large TPC-C data set. To speed that up, you can temporarily disable replication and tweak some cluster settings. You'll also need to enable the Enterprise license you requested earlier.
-
-1. SSH to any VM with the `cockroach` binary.
-
-2. Launch the [built-in SQL shell](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=<address of any node>
-    ~~~
-
-3. Adjust some [cluster settings](cluster-settings.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    SET CLUSTER SETTING kv.dist_sender.concurrency_limit = 2016;
-    SET CLUSTER SETTING kv.snapshot_rebalance.max_rate = '256 MiB';
-    SET CLUSTER SETTING kv.snapshot_recovery.max_rate = '256 MiB';
-    SET CLUSTER SETTING sql.stats.automatic_collection.enabled = false;
-    SET CLUSTER SETTING schemachanger.backfiller.max_buffer_size = '5 GiB';
-    SET CLUSTER SETTING rocksdb.min_wal_sync_interval = '500us';
-    SET CLUSTER SETTING kv.range_merge.queue_enabled = false
-    ~~~
-
-4. Change the default [GC TTL](configure-replication-zones.html#gc-ttlseconds) to the following value:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    ALTER RANGE default CONFIGURE ZONE USING gc.ttlseconds = 600;
-    ~~~
-
-5. Enable the trial license you requested earlier:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING cluster.organization = '<your organization>';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING enterprise.license = '<your license key>';
-    ~~~
-
-6. Exit the SQL shell:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-## Step 4. Import the TPC-C dataset
-
-CockroachDB comes with a number of [built-in workloads](cockroach-workload.html) for simulating client traffic. This step features CockroachDB's version of the [TPC-C](http://www.tpc.org/tpcc/) workload.
-
-1. SSH to the VM where you want to run TPC-C.
-
-1. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-    If you get a permissions error, prefix the command with `sudo`.
-
-1. Import the TPC-C dataset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload fixtures import tpcc \
-    --partitions=81 \
-    --warehouses=140000 \
-    --replicate-static-columns \
-    --partition-strategy=leases \
-    'postgres://root@<address of any CockroachDB node>:26257?sslmode=disable'
-    ~~~
-
-    This will load 11.2 TB of data for 140,000 "warehouses". This can take up to 8 hours to complete.
-
-    You can monitor progress on the **Jobs** screen of the DB Console. Open the [DB Console](ui-overview.html) by pointing a browser to the address in the `admin` field in the standard output of any node on startup.
-
-## Step 5. Partition the database
-
-Next, [partition your database](partitioning.html) to divide all of the TPC-C tables and indexes into 81 partitions, one per rack, and then use [zone configurations](configure-replication-zones.html) to pin those partitions to a particular rack.
-
-Wait for up-replication and partitioning to finish.  You will know when they have finished because both the number of *lease transfers* and *snapshots* will go down to `0` and stay there.  Note that this will likely take 10s of minutes.
-
-- To monitor the number of Lease transfers, open the [DB Console](ui-overview.html), select the **Replication** dashboard, hover over the **Range Operations** graph, and check the **Lease Transfers** data point.
-
-- To check the number of snapshots, open the [DB Console](ui-overview.html), select the **Replication** dashboard, and hover over the **Snapshots** graph.
-
-<img src="{{ 'images/v20.2/tpcc-large-replication-dashboard.png' | relative_url }}" alt="TPC-C 140k replication and partitioning dashboards" style="border:1px solid #eee;max-width:100%" />
-
-## Step 7. Allocate partitions
-
-Before running the benchmark, it's important to allocate partitions to workload binaries properly to ensure that the cluster is balanced.
-
-1. Create an `addrs` file containing connection strings to all 81 CockroachDB nodes:
-
-    ~~~
-    postgres://root@<node 1 internal address>:26257?sslmode=disable postgres://root@<node 2 internal address>:26257?sslmode=disable postgres://root@<node 3 internal address>:26257?sslmode=disable postgres://root@<node 4 internal address>:26257?sslmode=disable ...
-    ~~~
-
-2. Upload the `addrs` file to the 5 VMs with the `workload` binary:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp addrs <username>@<workload instance 1 address>:.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp addrs <username>@<workload instance 2 address>:.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp addrs <username>@<workload instance 3 address>:.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp addrs <username>@<workload instance 4 address>:.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp addrs <username>@<workload instance 5 address>:.
-    ~~~
-
-3. SSH to each VM with `workload` and allocate partitions:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    ulimit -n 500000 && cockroach workload run tpcc --partitions=81 \
-    --warehouses=140000 \
-    --partition-affinity=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 \
-    --ramp=30m \
-    --duration=1ms \
-    --histograms=workload1.histogram.ndjson \
-    $(cat addrs)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    ulimit -n 500000 && cockroach workload run tpcc \
-    --partitions 81 \
-    --warehouses 140000 \
-    --partition-affinity=17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32 \
-    --ramp=30m \
-    --duration=1ms \
-    --histograms=workload2.histogram.ndjson \
-    $(cat addrs)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    ulimit -n 500000 && cockroach workload run tpcc \
-    --partitions=81 \
-    --warehouses=140000 \
-    --partition-affinity=33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48 \
-    --ramp=30m \
-    --duration=1ms \
-    --histograms=workload3.histogram.ndjson \
-    $(cat addrs)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    ulimit -n 500000 && cockroach workload run tpcc \
-    --partitions=81 \
-    --warehouses=140000 \
-    --partition-affinity=49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64 \
-    --ramp=30m \
-    --duration=1ms \
-    --histograms=workload4.histogram.ndjson \
-    $(cat addrs)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    ulimit -n 500000 && cockroach workload run tpcc \
-    --partitions=81 \
-    --warehouses=140000 \
-    --partition-affinity=65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80 \
-    --ramp=30m \
-    --duration=1ms \
-    --histograms=workload5.histogram.ndjson \
-    $(cat addrs)
-    ~~~
-
-## Step 8. Run the benchmark
-
-Once the allocations finish, run TPC-C for 30 minutes on each VM with `workload`:
-
-{{site.data.alerts.callout_info}}
-It is critical to run the benchmark from the workload nodes in parallel, so start them as simultaneously as possible.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ shell
-ulimit -n 500000 && cockroach workload run tpcc \
---partitions=81 \
---warehouses=140000 \
---partition-affinity=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16 \
---ramp=4m \
---duration=30m \
---histograms=workload1.histogram.ndjson \
-$(cat addrs)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-ulimit -n 500000 && cockroach workload run tpcc \
---partitions=81 \
---warehouses=140000 \
---partition-affinity=17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32 \
---ramp=4m \
---duration=30m \
---histograms=workload2.histogram.ndjson \
-$(cat addrs)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-ulimit -n 500000 && cockroach workload run tpcc \
---partitions=81 \
---warehouses=140000 \
---partition-affinity=33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48 \
---ramp=4m \
---duration=30m \
---histograms=workload3.histogram.ndjson \
-$(cat addrs)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-ulimit -n 500000 && cockroach workload run tpcc \
---partitions=81 \
---warehouses=140000 \
---partition-affinity=49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64 \
---ramp=4m \
---duration=30m \
---histograms=workload4.histogram.ndjson \
-$(cat addrs)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-ulimit -n 500000 && cockroach workload run tpcc \
---partition=81 \
---warehouses=140000 \
---partition-affinity=65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80 \
---ramp=4m \
---duration=30m \
---histograms=workload5.histogram.ndjson \
-$(cat addrs)
-~~~
-
-## Step 9. Interpret the results
-
-1. Collect the result files from each VM with `workload`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp <username>@<workload instance 1 address>:workload1.histogram.ndjson .
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp <username>@<workload instance 2 address>:workload2.histogram.ndjson .
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp <username>@<workload instance 3 address>:workload3.histogram.ndjson .
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp <username>@<workload instance 4 address>:workload4.histogram.ndjson .
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp <username>@<workload instance 5 address>:workload5.histogram.ndjson .
-    ~~~
-
-2. Upload the result files to one of the VMs with the `workload` binary:
-
-    {{site.data.alerts.callout_info}}
-    The commands below assume you're uploading to the VM with the `workload1.histogram.ndjson` file.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp workload2.histogram.ndjson <username>@<workload instance 2 address>:.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp workload3.histogram.ndjson <username>@<workload instance 3 address>:.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp workload4.histogram.ndjson <username>@<workload instance 4 address>:.
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp workload5.histogram.ndjson <username>@<workload instance 5 address>:.
-    ~~~
-
-3. SSH to the VM where you uploaded the results files.
-
-4. Run the `workload debug tpcc-merge-results` command to synthesize the results:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    cockroach workload debug tpcc-merge-results \
-    --warehouses=140000 \
-    workload*.histogram.ndjson
-    ~~~
-
-    You'll should see results similar to the following, with **1.68M tpmC with 140,000 warehouses, resulting in an efficiency score of 95%**:
-
-    ~~~
-    Duration: 30m1., Warehouses: 140000, Efficiency: 95.45, tpmC: 1684437.21
-    _elapsed___ops/sec(cum)__p50(ms)__p90(ms)__p95(ms)__p99(ms)_pMax(ms)
-    1801.1s 	 2824.0     302.0   1140.9   2415.9   9126.8  55834.6 delivery
-    1801.1s		28074.0     402.7   1409.3   2684.4   9126.8  45097.2 newOrder
-    1801.1s 	 2826.0       6.8     62.9    125.8   4160.7  33286.0 orderStatus
-    1801.1s 	28237.4     251.7   1006.6   2415.9  15032.4 103079.2 payment
-    1801.1s 	 2823.5      39.8    469.8    906.0   5905.6  38654.7 stockLevel
-    ~~~
-
-## See also
-
-- [Performance Overview](performance.html)
-
-- Hardware
-
-    CockroachDB works well on commodity hardware in public cloud, private cloud, on-prem, and hybrid environments. For hardware recommendations, see our [Production Checklist](recommended-production-settings.html#hardware).
-
-    Also note that CockroachDB creates a yearly cloud report focused on evaluating hardware performance. For more information, see the [2020 Cloud Report](https://www.cockroachlabs.com/blog/2020-cloud-report/).
-
-- Performance Tuning
-
-    For guidance on tuning a real workload's performance, see [SQL Best Practices](performance-best-practices-overview.html), and for guidance on data location techniques to minimize network latency, see [Topology Patterns](topology-patterns.html).
diff --git a/src/current/v20.2/performance-benchmarking-with-tpcc-local.md b/src/current/v20.2/performance-benchmarking-with-tpcc-local.md
deleted file mode 100644
index 030aec474f0..00000000000
--- a/src/current/v20.2/performance-benchmarking-with-tpcc-local.md
+++ /dev/null
@@ -1,171 +0,0 @@
----
-title: Performance Benchmarking with TPC-C
-summary: Learn how to benchmark CockroachDB against TPC-C 13k on 3 nodes on your laptop
-toc: true
-toc_not_nested: true
-key: performance-benchmarking-with-tpc-c-10-warehouses.html
----
-
-This page shows you how to reproduce [CockroachDB's TPC-C performance benchmarking results](performance.html#scale) on commodity AWS hardware. Across all scales, CockroachDB can process tpmC (new order transactions per minute) at near maximum efficiency. Start by choosing the scale you're interested in:
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Local</strong></button>
-  <a href="performance-benchmarking-with-tpcc-small.html"><button class="filter-button">Small</button></a>
-  <a href="performance-benchmarking-with-tpcc-medium.html"><button class="filter-button">Medium</button></a>
-  <a href="performance-benchmarking-with-tpcc-large.html"><button class="filter-button">Large</button></a>
-</div>
-
-| Workload | Cluster size                       | Warehouses | Data size |
-|----------+------------------------------------+------------+-----------|
-| Local    | 3 nodes on your laptop             | 10         | 2 GB      |
-| Small    | 3 nodes on `c5d.4xlarge` machines  | 2500       | 200 GB    |
-| Medium   | 15 nodes on `c5d.4xlarge` machines | 13,000     | 1.04 TB   |
-| Large    | 81 nodes on `c5d.9xlarge` machines | 140,000    | 11.2 TB   |
-
-## Before you begin
-
-- TPC-C provides the most realistic and objective measure for OLTP performance at various scale factors. Before you get started, consider reviewing [what TPC-C is and how it is measured](performance.html#tpc-c).
-
-- Make sure you have already [installed CockroachDB](install-cockroachdb.html).
-
-## Step 1. Start CockroachDB
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-1. Use the [`cockroach start`](cockroach-start.html) command to start 3 nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=tpcc-local1 \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=tpcc-local2 \
-    --listen-addr=localhost:26258 \
-    --http-addr=localhost:8081 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=tpcc-local3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-2. Use the [`cockroach init`](cockroach-init.html) command to perform a one-time initialization of the cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init \
-    --insecure \
-    --host=localhost:26257
-    ~~~
-
-## Step 2. Import the TPC-C dataset
-
-CockroachDB comes with a number of [built-in workloads](cockroach-workload.html) for simulating client traffic. This step features CockroachDB's version of the [TPC-C](http://www.tpc.org/tpcc/) workload.
-
-Use [`cockroach workload`](cockroach-workload.html) to load the initial schema and data:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach workload fixtures import tpcc \
---warehouses=10 \
-'postgresql://root@localhost:26257?sslmode=disable'
-~~~
-
-This will load 2 GB of data for 10 "warehouses".
-
-## Step 3. Run the benchmark
-
-Run the workload for ten "warehouses" of data for ten minutes:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach workload run tpcc \
---warehouses=10 \
---ramp=3m \
---duration=10m \
-'postgresql://root@localhost:26257?sslmode=disable'
-~~~
-
-You'll see per-operation statistics every second:
-
-~~~
-Initializing 20 connections...
-Initializing 100 workers and preparing statements...
-_elapsed___errors__ops/sec(inst)___ops/sec(cum)__p50(ms)__p95(ms)__p99(ms)_pMax(ms)
-    1.0s        0            0.0            0.0      0.0      0.0      0.0      0.0 delivery
-    1.0s        0            0.0            0.0      0.0      0.0      0.0      0.0 newOrder
-...
-  105.0s        0            0.0            0.2      0.0      0.0      0.0      0.0 delivery
-  105.0s        0            4.0            1.8     44.0     46.1     46.1     46.1 newOrder
-  105.0s        0            0.0            0.2      0.0      0.0      0.0      0.0 orderStatus
-  105.0s        0            1.0            2.0     14.7     14.7     14.7     14.7 payment
-  105.0s        0            0.0            0.2      0.0      0.0      0.0      0.0 stockLevel
-...
-~~~
-
-{{site.data.alerts.callout_success}}
-For more `tpcc` options, use `cockroach workload run tpcc --help`. For details about other built-in load generators, use `cockroach workload run --help`.
-{{site.data.alerts.end}}
-
-## Step 4. Interpret the results
-
-Once the `workload` has finished running, you'll see a final output line:
-
-~~~
-_elapsed_______tpmC____efc__avg(ms)__p50(ms)__p90(ms)__p95(ms)__p99(ms)_pMax(ms)
-  300.0s      121.6  94.6%     41.0     39.8     54.5     71.3     96.5    130.0
-~~~
-
-You will also see some audit checks and latency statistics for each individual query. For this run, some of those checks might indicate that they were `SKIPPED` due to insufficient data. For a more comprehensive test, run `workload` for a longer duration (e.g., two hours). The `tpmC` (new order transactions/minute) number is the headline number and `efc` ("efficiency") tells you how close CockroachDB gets to theoretical maximum `tpmC`.
-
-The [TPC-C specification](http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5.11.0.pdf) has p90 latency requirements in the order of seconds, but as you see here, CockroachDB far surpasses that requirement with p90 latencies in the tens of milliseconds.
-
-## Step 5. Clean up
-
-1. When you're done with your test cluster, use the [`cockroach quit`](cockroach-quit.html) command to gracefully shut down each node.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26257
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26258
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    For the last node, the shutdown process will take longer (about a minute each) and will eventually force the node to stop. This is because, with only 1 of 3 nodes left, all ranges no longer have a majority of replicas available, and so the cluster is no longer operational.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26259
-    ~~~
-
-2. To restart the cluster at a later time, run the same `cockroach start` commands as earlier from the directory containing the nodes' data stores.  
-
-    If you do not plan to restart the cluster, you may want to remove the nodes' data stores:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -rf tpcc-local1 tpcc-local2 tpcc-local3
-    ~~~
diff --git a/src/current/v20.2/performance-benchmarking-with-tpcc-medium.md b/src/current/v20.2/performance-benchmarking-with-tpcc-medium.md
deleted file mode 100644
index 56e90a311e6..00000000000
--- a/src/current/v20.2/performance-benchmarking-with-tpcc-medium.md
+++ /dev/null
@@ -1,278 +0,0 @@
----
-title: Performance Benchmarking with TPC-C
-summary: Benchmark CockroachDB against TPC-C with 15 nodes on `c5d.4xlarge` machines
-toc: true
-toc_not_nested: true
-key: performance-benchmarking-with-tpc-c-10k-warehouses.html
----
-
-This page shows you how to reproduce [CockroachDB's TPC-C performance benchmarking results](performance.html#scale) on commodity AWS hardware. Across all scales, CockroachDB can process tpmC (new order transactions per minute) at near maximum efficiency. Start by choosing the scale you're interested in:
-
-<div class="filters filters-big clearfix">
-  <a href="performance-benchmarking-with-tpcc-local.html"><button class="filter-button">Local</button></a>
-  <a href="performance-benchmarking-with-tpcc-small.html"><button class="filter-button">Small</button></a>
-  <button class="filter-button current"><strong>Medium</strong></button>
-  <a href="performance-benchmarking-with-tpcc-large.html"><button class="filter-button">Large</button></a>
-</div>
-
-| Workload | Cluster size                       | Warehouses | Data size |
-|----------+------------------------------------+------------+-----------|
-| Local    | 3 nodes on your laptop             | 10         | 2 GB      |
-| Small    | 3 nodes on `c5d.4xlarge` machines  | 2500       | 200 GB    |
-| Medium   | 15 nodes on `c5d.4xlarge` machines | 13,000     | 1.04 TB   |
-| Large    | 81 nodes on `c5d.9xlarge` machines | 140,000    | 11.2 TB   |
-
-<span class="version-tag">New in v20.2</span>: CockroachDB can achieve a TPC-C run of 13k warehouses on the same cluster size used for 10k in version 19.2, a 30% improvement:
-
-<img src="{{ 'images/v20.2/tpcc13k.png' | relative_url }}" alt="TPC-C 13,000" style="border:1px solid #eee;max-width:100%" />
-
-## Before you begin
-
-- [Review TPC-C concepts](#review-tpc-c-concepts)
-- [Request a trial license](#request-a-trial-license)
-
-### Review TPC-C concepts
-
-TPC-C provides the most realistic and objective measure for OLTP performance at various scale factors. Before you get started, consider reviewing [what TPC-C is and how it is measured](performance.html#tpc-c).
-
-### Request a trial license
-
-Reproducing these TPC-C results involves using CockroachDB's [partitioning](partitioning.html) feature to ensure replicas for any given section of data are located on the same nodes that will be queried by the load generator for that section of data. Partitioning helps distribute the workload evenly across the cluster.
-
-The partitioning feature requires an Enterprise license, so [request a 30-day trial license](https://www.cockroachlabs.com/get-cockroachdb/enterprise/) before you get started.
-
-You should receive your trial license via email within a few minutes. You'll enable your license once your cluster is up-and-running.
-
-## Step 1. Set up the environment
-
-- [Provision VMs](#provision-vms)
-- [Configure your network](#configure-your-network)
-
-### Provision VMs
-
-1. [Create 16 VM instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html), 15 for CockroachDB nodes and 1 for the TPC-C workload.
-    - Create all instances in the same region and the same security group.
-    - Use the `c5d.4xlarge` machine type.
-    - Use [local SSD instance store volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#instance-store-volumes). Local SSDs are low latency disks attached to each VM, which maximizes performance. This configuration best resembles what a bare metal deployment would look like, with machines directly connected to one physical disk each. We do not recommend using network-attached block storage.
-
-2. Note the internal IP address of each instance. You'll need these addresses when starting the CockroachDB nodes.
-
-{{site.data.alerts.callout_danger}}
-This configuration is intended for performance benchmarking only. For production deployments, there are other important considerations, such as security, load balancing, and data location techniques to minimize network latency. For more details, see the [Production Checklist](recommended-production-settings.html).
-{{site.data.alerts.end}}
-
-### Configure your network
-
-CockroachDB requires TCP communication on two ports:
-
-- `26257` for inter-node communication (i.e., working as a cluster) and for the TPC-C workload to connect to nodes
-- `8080` for exposing your DB Console
-
-[Create inbound rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) for your security group:
-
-#### Inter-node and TPCC-to-node communication
-
- Field | Recommended Value
--------|-------------------
- Type | Custom TCP Rule
- Protocol | TCP
- Port Range | **26257**
- Source | The name of your security group (e.g., *sg-07ab277a*)
-
-#### DB Console
-
- Field | Recommended Value
--------|-------------------
- Type | Custom TCP Rule
- Protocol | TCP
- Port Range | **8080**
- Source | Your network's IP ranges
-
-## Step 2. Start CockroachDB
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-1. SSH to the first VM where you want to run a CockroachDB node.
-
-2. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-    If you get a permissions error, prefix the command with `sudo`.
-
-3. Run the [`cockroach start`](cockroach-start.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --advertise-addr=<node1 internal address> \
-    --join=<node1 internal address>,<node2 internal address>,<node3 internal address> \
-    --cache=.25 \
-    --locality=rack=0 \
-    --background
-    ~~~
-
-    Each node will start with a [locality](cockroach-start.html#locality) that includes an artificial "rack number" (e.g., `--locality=rack=0`). Use 5 racks for 15 nodes so that 3 nodes will be assigned to each rack.
-
-4. Repeat steps 1 - 3 for the other 14 VMs for CockroachDB nodes. Each time, be sure to:
-    - Adjust the `--advertise-addr` flag.
-    - Set the [`--locality`](cockroach-start.html#locality) flag to the appropriate "rack number", as described above.
-
-5. On any of the VMs with the `cockroach` binary, run the one-time [`cockroach init`](cockroach-init.html) command to join the first nodes into a cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --insecure --host=<address of any node on --join list>
-    ~~~
-
-## Step 3. Configure the cluster
-
-You'll be importing a large TPC-C data set. To speed that up, you can tweak some cluster settings. You'll also need to enable the Enterprise license you requested earlier.
-
-1. SSH to any VM with the `cockroach` binary.
-
-2. Launch the [built-in SQL shell](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=<address of any node>
-    ~~~
-
-3. Adjust some [cluster settings](cluster-settings.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING rocksdb.ingest_backpressure.l0_file_count_threshold = 100;
-    SET CLUSTER SETTING rocksdb.ingest_backpressure.pending_compaction_threshold = '5 GiB';
-    SET CLUSTER SETTING schemachanger.backfiller.max_buffer_size = '5 GiB';
-    SET CLUSTER SETTING kv.snapshot_rebalance.max_rate = '128 MiB';
-    SET CLUSTER SETTING rocksdb.min_wal_sync_interval = '500us';
-    SET CLUSTER SETTING kv.range_merge.queue_enabled = false;
-    ~~~
-
-4. Enable the trial license you requested earlier:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING cluster.organization = '<your organization>';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING enterprise.license = '<your license key>';
-    ~~~
-
-5. Exit the SQL shell:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-## Step 4. Import the TPC-C dataset
-
-CockroachDB comes with a number of [built-in workloads](cockroach-workload.html) for simulating client traffic. This step features CockroachDB's version of the [TPC-C](http://www.tpc.org/tpcc/) workload.
-
-1. SSH to the VM where you want to run TPC-C.
-
-1. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-    If you get a permissions error, prefix the command with `sudo`.
-
-1. Import the TPC-C dataset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload fixtures import tpcc \
-    --partitions=5 \
-    --warehouses=13000 \
-    'postgres://root@<address of any CockroachDB node>:26257?sslmode=disable'
-    ~~~
-
-    This will load 1.04 TB of data for 13,000 "warehouses". This can take around 1 hour to complete.
-
-    You can monitor progress on the **Jobs** screen of the DB Console. Open the [DB Console](ui-overview.html) by pointing a browser to the address in the `admin` field in the standard output of any node on startup.
-
-## Step 5. Allow the cluster to rebalance
-
-Next, [partition your database](partitioning.html) to divide all of the TPC-C tables and indexes into 5 partitions, one per rack, and then use [zone configurations](configure-replication-zones.html) to pin those partitions to a particular rack.
-
-1. Still on the same VM, briefly run TPC-C to let the cluster balance and the leases settle. Bump the file descriptor limits with `ulimit` to the high value shown below, since the workload generators create a lot of database connections.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ulimit -n 100000 && cockroach workload run tpcc \
-    --partitions=5 \
-    --warehouses=13000 \
-    --duration=1m \
-    --ramp=1ms \
-    'postgres://root@<address of any CockroachDB node>:26257?sslmode=disable'
-    ~~~
-
-2. Wait for range rebalancing to finish.
-
-    This will likely take 10s of minutes. To watch the progress, go to the **Metrics > Queues > Replication Queue** graph in the DB Console. Once the **Replication Queue** gets to `0` for all actions and stays there, you can move on to the next step.
-
-## Step 6. Run the benchmark
-
-1. Back on the VM with the `workload` binary, create an `addrs` file containing connection strings to all 15 CockroachDB nodes:
-
-    ~~~
-    postgres://root@<node 1 internal address>:26257?sslmode=disable postgres://root@<node 2 internal address>:26257?sslmode=disable postgres://root@<node 3 internal address>:26257?sslmode=disable postgres://root@<node 4 internal address>:26257?sslmode=disable ...
-    ~~~
-
-2. Run TPC-C for 30 minutes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ulimit -n 100000 && cockroach workload run tpcc \
-    --partitions=5 \
-    --warehouses=13000 \
-    --ramp=1m \
-    --duration=30m \
-    $(cat addrs)
-    ~~~
-
-## Step 7. Interpret the results
-
-Once the workload has finished running, you will see a final result similar to the following. The efficiency and latency can be combined to determine whether this was a passing run. You should expect to see an efficiency number above 95%, well above the required minimum of 85%, and p95 latencies well below the required maximum of 10 seconds.
-
-~~~
-_elapsed_______tpmC____efc__avg(ms)__p50(ms)__p90(ms)__p95(ms)__p99(ms)_pMax(ms)
- 1800.0s   160420.0  96.0%    303.1    285.2    570.4    671.1    939.5   4160.7
-~~~
-
-## See also
-
-- [Performance Overview](performance.html)
-
-- Hardware
-
-    CockroachDB works well on commodity hardware in public cloud, private cloud, on-prem, and hybrid environments. For hardware recommendations, see our [Production Checklist](recommended-production-settings.html#hardware).
-
-    Also note that CockroachDB creates a yearly cloud report focused on evaluating hardware performance. For more information, see the [2020 Cloud Report](https://www.cockroachlabs.com/blog/2020-cloud-report/).
-
-- Performance Tuning
-
-    For guidance on tuning a real workload's performance, see [SQL Best Practices](performance-best-practices-overview.html), and for guidance on data location techniques to minimize network latency, see [Topology Patterns](topology-patterns.html).  
diff --git a/src/current/v20.2/performance-benchmarking-with-tpcc-small.md b/src/current/v20.2/performance-benchmarking-with-tpcc-small.md
deleted file mode 100644
index e1a6890eefa..00000000000
--- a/src/current/v20.2/performance-benchmarking-with-tpcc-small.md
+++ /dev/null
@@ -1,192 +0,0 @@
----
-title: Performance Benchmarking with TPC-C
-summary: Learn how to benchmark CockroachDB against TPC-C with 3 nodes on `c5d.4xlarge` machines
-toc: true
-toc_not_nested: true
-key: performance-benchmarking-with-tpc-c-1k-warehouses.html
----
-
-This page shows you how to reproduce [CockroachDB's TPC-C performance benchmarking results](performance.html#scale) on commodity AWS hardware. Across all scales, CockroachDB can process tpmC (new order transactions per minute) at near maximum efficiency. Start by choosing the scale you're interested in:
-
-<div class="filters filters-big clearfix">
-  <a href="performance-benchmarking-with-tpcc-local.html"><button class="filter-button">Local</button></a>
-  <button class="filter-button current"><strong>Small</strong></button>
-  <a href="performance-benchmarking-with-tpcc-medium.html"><button class="filter-button">Medium</button></a>
-  <a href="performance-benchmarking-with-tpcc-large.html"><button class="filter-button">Large</button></a>
-</div>
-
-| Workload | Cluster size                       | Warehouses | Data size |
-|----------+------------------------------------+------------+-----------|
-| Local    | 3 nodes on your laptop             | 10         | 2 GB      |
-| Small    | 3 nodes on `c5d.4xlarge` machines  | 2500       | 200 GB    |
-| Medium   | 15 nodes on `c5d.4xlarge` machines | 13,000     | 1.04 TB   |
-| Large    | 81 nodes on `c5d.9xlarge` machines | 140,000    | 11.2 TB   |
-
-## Before you begin
-
-### Review TPC-C concepts
-
-TPC-C provides the most realistic and objective measure for OLTP performance at various scale factors. Before you get started, consider reviewing [what TPC-C is and how it is measured](performance.html#tpc-c).
-
-## Step 1. Set up the environment
-
-- [Provision VMs](#provision-vms)
-- [Configure your network](#configure-your-network)
-
-### Provision VMs
-
-1. [Create 4 VM instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/LaunchingAndUsingInstances.html), 3 for CockroachDB nodes and 1 for the TPC-C workload.
-    - Create all instances in the same region and the same security group.
-    - Use the `c5d.4xlarge` machine type.
-    - Use [local SSD instance store volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/InstanceStorage.html#instance-store-volumes). Local SSDs are low latency disks attached to each VM, which maximizes performance. This configuration best resembles what a bare metal deployment would look like, with machines directly connected to one physical disk each. We do not recommend using network-attached block storage.
-
-2. Note the internal IP address of each instance. You'll need these addresses when starting the CockroachDB nodes.
-
-{{site.data.alerts.callout_danger}}
-This configuration is intended for performance benchmarking only. For production deployments, there are other important considerations, such as security, load balancing, and data location techniques to minimize network latency. For more details, see the [Production Checklist](recommended-production-settings.html).
-{{site.data.alerts.end}}
-
-### Configure your network
-
-CockroachDB requires TCP communication on two ports:
-
-- `26257` for inter-node communication (i.e., working as a cluster) and for the TPC-C workload to connect to nodes
-- `8080` for exposing your DB Console
-
-[Create inbound rules](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html#adding-security-group-rule) for your security group:
-
-#### Inter-node and TPCC-to-node communication
-
- Field | Recommended Value
--------|-------------------
- Type | Custom TCP Rule
- Protocol | TCP
- Port Range | **26257**
- Source | The name of your security group (e.g., *sg-07ab277a*)
-
-#### DB Console
-
- Field | Recommended Value
--------|-------------------
- Type | Custom TCP Rule
- Protocol | TCP
- Port Range | **8080**
- Source | Your network's IP ranges
-
-## Step 2. Start CockroachDB
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-1. SSH to the first VM where you want to run a CockroachDB node.
-
-2. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-    If you get a permissions error, prefix the command with `sudo`.
-
-3. Run the [`cockroach start`](cockroach-start.html) command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --advertise-addr=<node1 internal address> \
-    --join=<node1 internal address>,<node2 internal address>,<node3 internal address> \
-    --cache=.25 \
-    --background
-    ~~~
-
-4. Repeat steps 1 - 3 for the other 2 VMs for CockroachDB nodes. Each time, be sure to adjust the `--advertise-addr` flag.
-
-5. On any of the VMs with the `cockroach` binary, run the one-time [`cockroach init`](cockroach-init.html) command to join the first nodes into a cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --insecure --host=<address of any node on --join list>
-    ~~~
-
-## Step 3. Import the TPC-C dataset
-
-CockroachDB comes with a number of [built-in workloads](cockroach-workload.html) for simulating client traffic. This step features CockroachDB's version of the [TPC-C](http://www.tpc.org/tpcc/) workload.
-
-1. SSH to the VM where you want to run TPC-C.
-
-1. Download the [CockroachDB archive](https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz) for Linux, extract the binary, and copy it into the `PATH`:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{ page.release_info.version }}.linux-amd64.tgz \
-    | tar -xz
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{ page.release_info.version }}.linux-amd64/cockroach /usr/local/bin/
-    ~~~
-
-    If you get a permissions error, prefix the command with `sudo`.
-
-1. Import the TPC-C dataset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload fixtures import tpcc \
-    --warehouses=2500 \
-    'postgres://root@<address of any CockroachDB node>:26257?sslmode=disable'
-    ~~~
-
-    This will load 200 GB of data for 2500 "warehouses". This can take a while to complete.
-
-    You can monitor progress on the **Jobs** screen of the DB Console. Open the [DB Console](ui-overview.html) by pointing a browser to the address in the `admin` field in the standard output of any node on startup.
-
-## Step 4. Run the benchmark
-
-1. Still on the same VM, create an `addrs` file containing connection strings to the 3 CockroachDB nodes:
-
-    ~~~
-    postgres://root@<node 1 internal address>:26257?sslmode=disable postgres://root@<node 2 internal address>:26257?sslmode=disable postgres://root@<node 3 internal address>:26257?sslmode=disable
-    ~~~
-
-1. Run TPC-C for 30 minutes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run tpcc \
-    --warehouses=2500 \
-    --ramp=1m \
-    --duration=30m \
-    $(cat addrs)
-    ~~~
-
-## Step 5. Interpret the results
-
-Once the workload has finished running, you will see a final result similar to the following. The efficiency and latency can be combined to determine whether this was a passing run. You should expect to see an efficiency number above 95%, well above the required minimum of 85%, and p95 latencies well below the required maximum of 10 seconds.
-
-~~~
-_elapsed_______tpmC____efc__avg(ms)__p50(ms)__p90(ms)__p95(ms)__p99(ms)_pMax(ms)
- 1800.0s    31064.6  96.6%    107.4     88.1    243.3    302.0    402.7    973.1
-~~~
-
-## See also
-
-- [Performance Overview](performance.html)
-
-- Hardware
-
-    CockroachDB works well on commodity hardware in public cloud, private cloud, on-prem, and hybrid environments. For hardware recommendations, see our [Production Checklist](recommended-production-settings.html#hardware).
-
-    Also note that CockroachDB creates a yearly cloud report focused on evaluating hardware performance. For more information, see the [2020 Cloud Report](https://www.cockroachlabs.com/blog/2020-cloud-report/).
-
-- Performance Tuning
-
-    For guidance on tuning a real workload's performance, see [SQL Best Practices](performance-best-practices-overview.html), and for guidance on data location techniques to minimize network latency, see [Topology Patterns](topology-patterns.html).  
diff --git a/src/current/v20.2/performance-best-practices-overview.md b/src/current/v20.2/performance-best-practices-overview.md
deleted file mode 100644
index 91b9a590d5c..00000000000
--- a/src/current/v20.2/performance-best-practices-overview.md
+++ /dev/null
@@ -1,436 +0,0 @@
----
-title: SQL Performance Best Practices
-summary: Best practices for optimizing SQL performance in CockroachDB.
-toc: true
----
-
-This page provides best practices for optimizing query performance in CockroachDB.
-
-{{site.data.alerts.callout_success}}
-For a demonstration of some of these techniques, see [Performance Tuning](performance-tuning.html). For guidance on deployment and data location techniques to minimize network latency, see [Topology Patterns](topology-patterns.html).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-If you aren't sure whether SQL query performance needs to be improved on your cluster, see [Identify slow queries](query-behavior-troubleshooting.html#identify-slow-queries).
-{{site.data.alerts.end}}
-
-## DML best practices
-
-### Use multi-row statements instead of multiple single-row statements
-
-For `INSERT`, `UPSERT`, and `DELETE` statements, a single multi-row statement is faster than multiple single-row statements. Whenever possible, use multi-row statements for DML queries instead of multiple single-row statements.
-
-For more information, see:
-
-- [Insert Data](insert-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-- [How to improve IoT application performance with multi-row DML](https://www.cockroachlabs.com/blog/multi-row-dml/)
-
-### Use `UPSERT` instead of `INSERT ON CONFLICT` on tables with no secondary indexes
-
-When inserting/updating all columns of a table, and the table has no secondary
-indexes, we recommend using an [`UPSERT`](upsert.html) statement instead of the
-equivalent [`INSERT ON CONFLICT`](insert.html) statement. Whereas `INSERT ON
-CONFLICT` always performs a read to determine the necessary writes, the `UPSERT`
-statement writes without reading, making it faster. For tables with secondary
-indexes, there is no performance difference between `UPSERT` and `INSERT ON
-CONFLICT`.
-
-This issue is particularly relevant when using a simple SQL table of two columns
-to [simulate direct KV access](sql-faqs.html#can-i-use-cockroachdb-as-a-key-value-store).
-In this case, be sure to use the `UPSERT` statement.
-
-## Bulk-insert best practices
-
-### Use multi-row `INSERT` statements for bulk-inserts into existing tables
-
-To bulk-insert data into an existing table, batch multiple rows in one multi-row `INSERT` statement. Experimentally determine the optimal batch size for your application by monitoring the performance for different batch sizes (10 rows, 100 rows, 1000 rows). Do not include bulk `INSERT` statements within an explicit transaction.
-
-{{site.data.alerts.callout_success}}
-You can also use the [`IMPORT INTO`](import-into.html) statement to bulk-insert CSV data into an existing table.
-{{site.data.alerts.end}}
-
-For more information, see [Insert Multiple Rows](insert.html#insert-multiple-rows-into-an-existing-table).
-
-{{site.data.alerts.callout_info}}
-Large multi-row `INSERT` queries can lead to long-running transactions that result in [transaction retry errors](transaction-retry-error-reference.html). If a multi-row `INSERT` query results in an error code [`40001` with the message `"transaction deadline exceeded"`](transaction-retry-error-reference.html#retry_commit_deadline_exceeded), we recommend breaking up the query up into smaller batches of rows.
-{{site.data.alerts.end}}
-
-### Use `IMPORT` instead of `INSERT` for bulk-inserts into new tables
-
-To bulk-insert data into a brand new table, the [`IMPORT`](import.html) statement performs better than `INSERT`.
-
-## Bulk-update best practices
-
-### Use batch updates to delete a large number of rows
-
-To delete a large number of rows, we recommend iteratively deleting batches of rows until all of the unwanted rows are deleted. For an example, see [Bulk-update Data](bulk-update-data.html).
-
-## Bulk-delete best practices
-
-### Use `TRUNCATE` instead of `DELETE` to delete all rows in a table
-
-The [`TRUNCATE`](truncate.html) statement removes all rows from a table by dropping the table and recreating a new table with the same name. This performs better than using `DELETE`, which performs multiple transactions to delete all rows.
-
-### Use batch deletes to delete a large number of rows
-
-To delete a large number of rows, we recommend iteratively deleting batches of rows until all of the unwanted rows are deleted. For an example, see [Bulk-delete Data](bulk-delete-data.html).
-
-### Batch delete "expired" data
-
-CockroachDB does not support Time to Live (TTL) on table rows. To delete "expired" rows, we recommend automating a batch delete process with a job scheduler like `cron`. For an example, see [Batch-delete "expired" data](bulk-delete-data.html#batch-delete-expired-data).
-
-## Assign column families
-
-A column family is a group of columns in a table that is stored as a single key-value pair in the underlying key-value store.
-
-When a table is created, all columns are stored as a single column family. This default approach ensures efficient key-value storage and performance in most cases. However, when frequently updated columns are grouped with seldom updated columns, the seldom updated columns are nonetheless rewritten on every update. Especially when the seldom updated columns are large, it's therefore more performant to [assign them to a distinct column family](column-families.html).
-
-## Unique ID best practices
-
-The best practices for generating unique IDs in a distributed database like CockroachDB are very different than for a legacy single-node database. Traditional approaches for generating unique IDs for legacy single-node databases include:
-
-1. Using the [`SERIAL`](serial.html) pseudo-type for a column to generate random unique IDs. This can result in a performance bottleneck because IDs generated temporally near each other have similar values and are located physically near each other in a table's storage.
-2. Generating monotonically increasing [`INT`](int.html) IDs by using transactions with roundtrip [`SELECT`](select-clause.html)s, e.g., `INSERT INTO tbl (id, …) VALUES ((SELECT max(id)+1 FROM tbl), …)`. This has a **very high performance cost** since it makes all [`INSERT`](insert.html) transactions wait for their turn to insert the next ID. You should only do this if your application really does require strict ID ordering. In some cases, using [Change Data Capture (CDC)](stream-data-out-of-cockroachdb-using-changefeeds.html) can help avoid the requirement for strict ID ordering. If you can avoid the requirement for strict ID ordering, you can use one of the higher performance ID strategies outlined below.
-
-The approaches described above are likely to create hotspots for both reads and writes in CockroachDB. To avoid this issue, we recommend the following approaches (listed in order from best to worst performance).
-
-| Approach                                                                             | Pros                                             | Cons                                                                                    |
-|--------------------------------------------------------------------------------------+--------------------------------------------------+-----------------------------------------------------------------------------------------|
-| 1. [Use multi-column primary keys](#use-multi-column-primary-keys)                   | Potentially fastest, if done right               | Complex, requires up-front design and testing to ensure performance                     |
-| 2. [Use `UUID` to generate unique IDs](#use-uuid-to-generate-unique-ids)             | Good performance; spreads load well; easy choice | May leave some performance on the table; requires other columns to be useful in queries |
-| 3. [Use `INSERT` with the `RETURNING` clause](#use-insert-with-the-returning-clause-to-generate-unique-ids) | Easy to query against; familiar design           | Slower performance than the other options; higher chance of transaction contention      |
-
-### Use multi-column primary keys
-
-A well-designed multi-column primary key can yield even better performance than a [UUID primary key](#use-uuid-to-generate-unique-ids), but it requires more up-front schema design work. To get the best performance, ensure that any monotonically increasing field is located **after** the first column of the primary key. When done right, such a composite primary key should result in:
-
-- Enough randomness in your primary key to spread the table data / query load relatively evenly across the cluster, which will avoid hotspots. By "enough randomness" we mean that the prefix of the primary key should be relatively uniformly distributed over its domain. Its domain should have at least as many elements as you have nodes.
-- A monotonically increasing column that is part of the primary key (and thus indexed) which is also useful in your queries.
-
-For example, consider a social media website. Social media posts are written by users, and on login the user's last 10 posts are displayed. A good choice for a primary key might be `(username, post_timestamp)`. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE posts (
-    username STRING,
-    post_timestamp TIMESTAMP,
-    post_id INT,
-    post_content STRING,
-    CONSTRAINT posts_pk PRIMARY KEY(username, post_timestamp)
-);
-~~~
-
-This would make the following query efficient.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM posts
-          WHERE username = 'alyssa'
-       ORDER BY post_timestamp DESC
-          LIMIT 10;
-~~~
-
-~~~
-  username |      post_timestamp       | post_id | post_content
-+----------+---------------------------+---------+--------------+
-  alyssa   | 2019-07-31 18:01:00+00:00 |    ...  | ...
-  alyssa   | 2019-07-30 10:22:00+00:00 |    ...  | ...
-  alyssa   | 2019-07-30 09:12:00+00:00 |    ...  | ...
-  alyssa   | 2019-07-29 13:48:00+00:00 |    ...  | ...
-  alyssa   | 2019-07-29 13:47:00+00:00 |    ...  | ...
-  alyssa   | 2019-07-29 13:46:00+00:00 |    ...  | ...
-  alyssa   | 2019-07-29 13:43:00+00:00 |    ...  | ...
-  ...
-
-Time: 924µs
-~~~
-
-To see why, let's look at the [`EXPLAIN`](explain.html) output. It shows that the query is fast because it does a point lookup on the indexed column `username` (as shown by the line `spans | /"alyssa"-...`). Furthermore, the column `post_timestamp` is already in an index, and sorted (since it's a monotonically increasing part of the primary key).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (VERBOSE)
-    SELECT * FROM posts
-            WHERE username = 'alyssa'
-         ORDER BY post_timestamp DESC
-            LIMIT 10;
-~~~
-
-~~~
-   tree   |        field        |          description          |                      columns                      |    ordering
-----------+---------------------+-------------------------------+---------------------------------------------------+------------------
-          | distribution        | local                         |                                                   |
-          | vectorized          | false                         |                                                   |
-  revscan |                     |                               | (username, post_timestamp, post_id, post_content) | -post_timestamp
-          | estimated row count | 10 (missing stats)            |                                                   |
-          | table               | posts@posts_pk                |                                                   |
-          | spans               | /"alyssa"-/"alyssa"/PrefixEnd |                                                   |
-          | limit               | 10                            |                                                   |
-(7 rows)
-~~~
-
-Note that the above query also follows the [indexing best practice](indexes.html#best-practices) of indexing all columns in the `WHERE` clause.
-
-### Use `UUID` to generate unique IDs
-
-To auto-generate unique row identifiers, use the [`UUID`](uuid.html) column with the `gen_random_uuid()` [function](functions-and-operators.html#id-generation-functions) as the [default value](default-value.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE t1 (id UUID PRIMARY KEY DEFAULT gen_random_uuid(), name STRING);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t1 (name) VALUES ('a'), ('b'), ('c');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1;
-~~~
-
-~~~
-+--------------------------------------+------+
-|                  id                  | name |
-+--------------------------------------+------+
-| 60853a85-681d-4620-9677-946bbfdc8fbc | c    |
-| 77c9bc2e-76a5-4ebc-80c3-7ad3159466a1 | b    |
-| bd3a56e1-c75e-476c-b221-0da9d74d66eb | a    |
-+--------------------------------------+------+
-(3 rows)
-~~~
-
-### Use `INSERT` with the `RETURNING` clause to generate unique IDs
-
-If something prevents you from using [multi-column primary keys](#use-multi-column-primary-keys) or [`UUID`s](#use-uuid-to-generate-unique-ids) to generate unique IDs, you might resort to using `INSERT`s with `SELECT`s to return IDs. Instead, [use the `RETURNING` clause with the `INSERT` statement](insert.html#insert-and-return-values) as shown below for improved performance.
-
-#### Generate monotonically-increasing unique IDs
-
-Suppose the table schema is as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE X (
-	ID1 INT,
-	ID2 INT,
-	ID3 INT DEFAULT 1,
-	PRIMARY KEY (ID1,ID2)
-  );
-~~~
-
-The common approach would be to use a transaction with an `INSERT` followed by a `SELECT`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-
-> INSERT INTO X VALUES (1,1,1)
-  	ON CONFLICT (ID1,ID2)
-  	DO UPDATE SET ID3=X.ID3+1;
-
-> SELECT * FROM X WHERE ID1=1 AND ID2=1;
-
-> COMMIT;
-~~~
-
-However, the performance best practice is to use a `RETURNING` clause with `INSERT` instead of the transaction:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO X VALUES (1,1,1),(2,2,2),(3,3,3)
-	ON CONFLICT (ID1,ID2)
-	DO UPDATE SET ID3=X.ID3 + 1
-	RETURNING ID1,ID2,ID3;
-~~~
-
-#### Generate random unique IDs
-
-Suppose the table schema is as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE X (
-	ID1 INT,
-	ID2 INT,
-	ID3 INT DEFAULT unique_rowid(),
-	PRIMARY KEY (ID1,ID2)
-  );
-~~~
-
-The common approach to generate random Unique IDs is a transaction using a `SELECT` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-
-> INSERT INTO X VALUES (1,1);
-
-> SELECT * FROM X WHERE ID1=1 AND ID2=1;
-
-> COMMIT;
-~~~
-
-However, the performance best practice is to use a `RETURNING` clause with `INSERT` instead of the transaction:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO X VALUES (1,1),(2,2),(3,3)
-	RETURNING ID1,ID2,ID3;
-~~~
-
-## Secondary index best practices
-
-See [Secondary Index Best Practices](schema-design-indexes.html#best-practices).
-
-## Join best practices
-
-See [Join Performance Best Practices](joins.html#performance-best-practices).
-
-## Subquery best practices
-
-See [Subquery Performance Best Practices](subqueries.html#performance-best-practices).
-
-## Table scans best practices
-
-### Avoid `SELECT *` for large tables
-
-For large tables, avoid table scans (that is, reading the entire table data) whenever possible. Instead, define the required fields in a `SELECT` statement.
-
-#### Example
-
-Suppose the table schema is as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE accounts (
-	id INT,
-	customer STRING,
-	address STRING,
-	balance INT
-	nominee STRING
-	);
-~~~
-
-Now if we want to find the account balances of all customers, an inefficient table scan would be:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM ACCOUNTS;
-~~~
-
-This query retrieves all data stored in the table. A more efficient query would be:
-
-{% include copy-clipboard.html %}
-~~~ sql
- > SELECT CUSTOMER, BALANCE FROM ACCOUNTS;
-~~~
-
-This query returns the account balances of the customers.
-
-### Avoid `SELECT DISTINCT` for large tables
-
-`SELECT DISTINCT` allows you to obtain unique entries from a query by removing duplicate entries. However, `SELECT DISTINCT` is computationally expensive. As a performance best practice, use [`SELECT` with the `WHERE` clause](select-clause.html#filter-rows) instead.
-
-### Use `AS OF SYSTEM TIME` to decrease conflicts with long-running queries
-
-If you have long-running queries (such as analytics queries that perform full table scans) that can tolerate slightly out-of-date reads, consider using the [`... AS OF SYSTEM TIME` clause](select-clause.html#select-historical-data-time-travel). Using this, your query returns data as it appeared at a distinct point in the past and will not cause [conflicts](architecture/transaction-layer.html#transaction-conflicts) with other concurrent transactions, which can increase your application's performance.
-
-However, because `AS OF SYSTEM TIME` returns historical data, your reads might be stale.
-
-## Understanding and avoiding transaction contention
-
-{{site.data.alerts.callout_success}}
-You can use a [statement trace](query-behavior-troubleshooting.html#visualize-statement-traces-in-jaeger) to identify transaction contention on a running cluster.
-{{site.data.alerts.end}}
-
-Transaction contention occurs when the following three conditions are met:
-
-- There are multiple concurrent transactions or statements (sent by
-  multiple clients connected simultaneously to a single CockroachDB
-  cluster).
-- They operate on the same data, specifically over table rows with the
-  same index key values (either on [primary keys](primary-key.html) or
-  secondary [indexes](indexes.html)) or using index key values
-  that are close to each other, and thus place the indexed data on the
-  same [data ranges](architecture/overview.html).
-- At least some of the transactions write or modify the data.
-
-A set of transactions that all contend on the same keys will be
-limited in performance to the maximum processing speed of a single
-node (limited horizontal scalability). Non-contended transactions are
-not affected in this way.
-
-There are two levels of contention:
-
-- Transactions that operate on the same range but different index key
-  values will be limited by the overall hardware capacity of a single
-  node (the range lease holder).
-
-- Transactions that operate on the same index key values
-  (specifically, that operate on the same [column
-  family](column-families.html) for a given index key) will be more
-  strictly serialized to obey transaction isolation semantics.
-
-Transaction contention can also increase the rate of transaction
-restarts, and thus make the proper implementation of [client-side
-transaction
-retries](transactions.html#client-side-intervention) more
-critical.
-
-To avoid contention, multiple strategies can be applied:
-
-- Use index key values with a more random distribution of values, so
-  that transactions over different rows are more likely to operate on
-  separate data ranges. See the [SQL FAQs](sql-faqs.html) on row IDs for
-  suggestions.
-
-- Make transactions smaller, so that each transaction has less work to
-  do. In particular, avoid multiple client-server exchanges per
-  transaction. For example, use [common table
-  expressions](common-table-expressions.html) to group multiple
-  [`SELECT`](select-clause.html) and
-  [`INSERT`](insert.html)/[`UPDATE`](update.html)/[`DELETE`](delete.html)/[`UPSERT`](upsert.html)
-  clauses together in a single SQL statement.
-
-  - For an example showing how to break up large transactions in an application, see [Break up large transactions into smaller units of work](build-a-python-app-with-cockroachdb-sqlalchemy.html#break-up-large-transactions-into-smaller-units-of-work).
-  - If you are experiencing contention (retries) when doing bulk deletes, see [Bulk-delete data](bulk-delete-data.html).
-
-- In combination with the above, if you are able to [send all of the statements in your transaction in a single batch](transactions.html#batched-statements), CockroachDB can automatically retry the transaction for you.
-
-- Use the [`SELECT FOR UPDATE`](select-for-update.html) statement in scenarios where a transaction performs a read and then updates the row(s) it just read. It orders transactions by controlling concurrent access to one or more rows of a table. It works by locking the rows returned by a [selection query](selection-queries.html), such that other transactions trying to access those rows are forced to wait for the transaction that locked the rows to finish. These other transactions are effectively put into a queue that is ordered based on when they try to read the value of the locked row(s).
-
-- When replacing values in a row, use [`UPSERT`](upsert.html) and
-  specify values for all columns in the inserted rows. This will
-  usually have the best performance under contention, compared to
-  combinations of [`SELECT`](select-clause.html),
-  [`INSERT`](insert.html), and [`UPDATE`](update.html).
-
-- Increase
-  [normalization](https://en.wikipedia.org/wiki/Database_normalization)
-  of the data to place parts of the same records that are modified by
-  different transactions in different tables. Note however that this
-  is a double-edged sword, because denormalization can also increase
-  performance by creating multiple copies of often-referenced data in
-  separate ranges.
-
-- If the application strictly requires operating on very few different
-  index key values, consider using [`ALTER ... SPLIT
-  AT`](split-at.html) so that each index key value can be served by
-  a separate group of nodes in the cluster.
-
-It is always best to avoid contention as much as possible via the
-design of the schema and application. However, sometimes contention is
-unavoidable. To maximize performance in the presence of contention,
-you'll need to maximize the performance of a single range.
-To achieve this, multiple strategies can be applied:
-
-- Minimize the network distance between the replicas of a range,
-  possibly using zone configs and partitioning.
-- Use the fastest storage devices available.
-- If the contending transactions operate on different keys within the
-  same range, add more CPU power (more cores) per node. Note however
-  that this is less likely to provide an improvement if the
-  transactions all operate on the same key.
diff --git a/src/current/v20.2/performance-tuning-insecure.md b/src/current/v20.2/performance-tuning-insecure.md
deleted file mode 100644
index 4f55f4c094e..00000000000
--- a/src/current/v20.2/performance-tuning-insecure.md
+++ /dev/null
@@ -1,1071 +0,0 @@
----
-title: Performance Tuning
-summary: Essential techniques for getting fast reads and writes in a single- and multi-region CockroachDB deployment.
-toc: true
-certs: --insecure
-app: ./tuning.py
----
-
-<div class="filters filters-big clearfix">
-  <a href="performance-tuning.html"><button class="filter-button">Secure</button>
-  <button class="filter-button current"><strong>Insecure</strong></button></a>
-</div>
-
-This tutorial shows you essential techniques for getting fast reads and writes in CockroachDB, starting with a single-region deployment and expanding into multiple regions.
-
-For a comprehensive list of tuning recommendations, only some of which are demonstrated here, see [SQL Performance Best Practices](performance-best-practices-overview.html).
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-## Overview
-
-{% include {{ page.version.version }}/performance/overview.md %}
-
-## Single-region deployment
-
-<!-- roachprod instructions for single-region deployment
-1. Reserve 12 instances across 3 GCE zone: roachprod create <yourname>-tuning --geo --gce-zones us-east1-b,us-west1-a,us-west2-a --local-ssd -n 12
-2. Put cockroach` on all instances:
-   - roachprod stage <yourname>-tuning release v2.1.0-beta.20181008
-3. Start the cluster in us-east1-b: roachprod start <yourname>-tuning:1-3
-4. You'll need the addresses of all instances later, so list and record them somewhere: roachprod list -d <yourname>-tuning
-5. Import the Movr dataset:
-   - SSH onto instance 4: roachprod run <yourname>-tuning:4
-   - Run the SQL commands in Step 4 below.
-8. Install the Python client:
-   - Still on instance 4, run commands in Step 5 below.
-9. Test/tune read performance:
-   - Still on instance 4, run commands in Step 6.
-10. Test/tune write performance:
-   - Still on instance 4, run commands in Step 7.
--->
-
-### Step 1. Configure your network
-
-{% include {{ page.version.version }}/performance/configure-network.md %}
-
-### Step 2. Create instances
-
-You'll start with a 3-node CockroachDB cluster in the `us-east1-b` GCE zone, with an extra instance for running a client application workload.
-
-1. [Create 3 instances](https://cloud.google.com/compute/docs/instances/create-start-instance) for your CockroachDB nodes. While creating each instance:  
-    - Select the `us-east1-b` [zone](https://cloud.google.com/compute/docs/regions-zones/).
-    - Use the `n2-standard-4` machine type (4 vCPUs, 16 GB memory).
-    - Use the Ubuntu 16.04 OS image.
-    - [Create and mount a local SSD](https://cloud.google.com/compute/docs/disks/local-ssd#create_local_ssd).
-    - To apply the Web UI firewall rule you created earlier, click **Management, disk, networking, SSH keys**, select the **Networking** tab, and then enter `cockroachdb` in the **Network tags** field.
-
-2. Note the internal IP address of each `n2-standard-4` instance. You'll need these addresses when starting the CockroachDB nodes.
-
-3. Create a separate instance for running a client application workload, also in the `us-east1-b` zone. This instance can be smaller, such as `n2-standard-2`.
-
-### Step 3. Start a 3-node cluster
-
-{% include {{ page.version.version }}/performance/start-cluster.md %}
-
-### Step 4. Import the Movr dataset
-
-{% include {{ page.version.version }}/performance/import-movr.md %}
-
-### Step 5. Install the Python client
-
-When measuring SQL performance, it's best to run a given statement multiple times and look at the average and/or cumulative latency. For that purpose, you'll install and use a Python testing client.
-
-1. Still on the fourth instance, make sure all of the system software is up-to-date:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo apt-get update && sudo apt-get -y upgrade
-    ~~~
-
-2. Install the `psycopg2` driver:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo apt-get install python-psycopg2
-    ~~~
-
-3. Download the Python client:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget https://raw.githubusercontent.com/cockroachdb/docs/master/_includes/{{ page.version.version }}/performance/tuning.py \
-    && chmod +x tuning.py
-    ~~~
-
-    As you'll see below, this client lets you pass command-line flags:
-
-    Flag | Description
-    -----|------------
-    `--host` | The IP address of the target node. This is used in the client's connection string.
-    `--statement` | The SQL statement to execute.
-    `--repeat` | The number of times to repeat the statement. This defaults to 20.
-
-    When run, the client prints the median time in seconds across all repetitions of the statement. Optionally, you can pass two other flags, `--time` to print the execution time in seconds for each repetition of the statement, and `--cumulative` to print the cumulative time in seconds for all repetitions. `--cumulative` is particularly useful when testing writes.
-
-    {{site.data.alerts.callout_success}}
-    To get similar help directly in your shell, use `./tuning.py --help`.
-    {{site.data.alerts.end}}
-
-### Step 6. Test/tune read performance
-
-- [Filtering by the primary key](#filtering-by-the-primary-key)
-- [Filtering by a non-indexed column (full table scan)](#filtering-by-a-non-indexed-column-full-table-scan)
-- [Filtering by a secondary index](#filtering-by-a-secondary-index)
-- [Filtering by a secondary index storing additional columns](#filtering-by-a-secondary-index-storing-additional-columns)
-- [Joining data from different tables](#joining-data-from-different-tables)
-- [Using `IN (list)` with a subquery](#using-in-list-with-a-subquery)
-- [Using `IN (list)` with explicit values](#using-in-list-with-explicit-values)
-
-#### Filtering by the primary key
-
-Retrieving a single row based on the primary key will usually return in 2ms or less:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT * FROM rides WHERE city = 'boston' AND id = '000007ef-fa0f-4a6e-a089-ce74aa8d2276'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['id', 'city', 'vehicle_city', 'rider_id', 'vehicle_id', 'start_address', 'end_address', 'start_time', 'end_time', 'revenue']
-['000007ef-fa0f-4a6e-a089-ce74aa8d2276', 'boston', 'boston', 'd66c386d-4b7b-48a7-93e6-f92b5e7916ab', '6628bbbc-00be-4891-bc00-c49f2f16a30b', '4081 Conner Courts\nSouth Taylor, VA 86921', '2808 Willis Wells Apt. 931\nMccoyberg, OH 10303-4879', '2018-07-20 01:46:46.003070', '2018-07-20 02:27:46.003070', '44.25']
-
-Times (milliseconds):
-[2.1638870239257812, 1.2159347534179688, 1.0809898376464844, 1.0669231414794922, 1.2650489807128906, 1.1401176452636719, 1.1310577392578125, 1.0380744934082031, 1.199960708618164, 1.0530948638916016, 1.1000633239746094, 1.3430118560791016, 1.104116439819336, 1.0750293731689453, 1.0609626770019531, 1.088857650756836, 1.1639595031738281, 1.2559890747070312, 1.1899471282958984, 1.0449886322021484, 1.1057853698730469, 1.127004623413086, 0.9729862213134766, 1.1131763458251953, 1.0879039764404297, 1.119852066040039, 1.065969467163086, 1.0371208190917969, 1.1181831359863281, 1.0409355163574219, 1.0859966278076172, 1.1398792266845703, 1.032114028930664, 1.1000633239746094, 1.1360645294189453, 1.146078109741211, 1.329183578491211, 1.1131763458251953, 1.1548995971679688, 0.9977817535400391, 1.1138916015625, 1.085042953491211, 1.0950565338134766, 1.0869503021240234, 1.0170936584472656, 1.0571479797363281, 1.0640621185302734, 1.1110305786132812, 1.1279582977294922, 1.1119842529296875]
-
-Median time (milliseconds):
-1.10495090485
-~~~
-
-Retrieving a subset of columns will usually be even faster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT rider_id, vehicle_id \
-FROM rides \
-WHERE city = 'boston' AND id = '000007ef-fa0f-4a6e-a089-ce74aa8d2276'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['rider_id', 'vehicle_id']
-['d66c386d-4b7b-48a7-93e6-f92b5e7916ab', '6628bbbc-00be-4891-bc00-c49f2f16a30b']
-
-Times (milliseconds):
-[2.218961715698242, 1.2569427490234375, 1.3570785522460938, 1.1570453643798828, 1.3251304626464844, 1.3320446014404297, 1.0790824890136719, 1.0139942169189453, 1.0251998901367188, 1.1150836944580078, 1.1949539184570312, 1.2140274047851562, 1.2080669403076172, 1.238107681274414, 1.071929931640625, 1.104116439819336, 1.0230541229248047, 1.0571479797363281, 1.0519027709960938, 1.0688304901123047, 1.0118484497070312, 1.0051727294921875, 1.1889934539794922, 1.0571479797363281, 1.177072525024414, 1.0449886322021484, 1.0669231414794922, 1.004934310913086, 0.9818077087402344, 0.9369850158691406, 1.004934310913086, 1.0461807250976562, 1.0628700256347656, 1.1332035064697266, 1.1780261993408203, 1.0361671447753906, 1.1410713195800781, 1.1188983917236328, 1.026153564453125, 0.9629726409912109, 1.0199546813964844, 1.0409355163574219, 1.0440349578857422, 1.1110305786132812, 1.1761188507080078, 1.508951187133789, 1.2068748474121094, 1.3430118560791016, 1.4159679412841797, 1.3141632080078125]
-
-Median time (milliseconds):
-1.09159946442
-~~~
-
-#### Filtering by a non-indexed column (full table scan)
-
-You'll get generally poor performance when retrieving a single row based on a column that is not in the primary key or any secondary index:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT * FROM users WHERE name = 'Natalie Cunningham'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['id', 'city', 'name', 'address', 'credit_card']
-['02cc9e5b-1e91-4cdb-87c4-726b4ea7219a', 'boston', 'Natalie Cunningham', '97477 Lee Path\nKimberlyport, CA 65960', '4532613656695680']
-
-Times (milliseconds):
-[33.271074295043945, 4.4689178466796875, 4.18400764465332, 4.327058792114258, 5.700111389160156, 4.509925842285156, 4.525899887084961, 4.294157028198242, 4.516124725341797, 5.700111389160156, 5.105018615722656, 4.5070648193359375, 4.798173904418945, 5.930900573730469, 4.445075988769531, 4.1790008544921875, 4.065036773681641, 4.296064376831055, 5.722999572753906, 4.827976226806641, 4.640102386474609, 4.374980926513672, 4.269123077392578, 4.422903060913086, 4.110813140869141, 4.091024398803711, 4.189014434814453, 4.345178604125977, 5.600929260253906, 4.827976226806641, 4.416942596435547, 4.424095153808594, 4.736185073852539, 4.462003707885742, 4.307031631469727, 5.10096549987793, 4.56690788269043, 4.641056060791016, 4.701137542724609, 4.538059234619141, 4.474163055419922, 4.561901092529297, 4.431009292602539, 4.756927490234375, 4.54401969909668, 4.415035247802734, 4.396915435791016, 5.9719085693359375, 4.543066024780273, 5.830049514770508]
-
-Median time (milliseconds):
-4.51302528381
-~~~
-
-To understand why this query performs poorly, use the SQL client built into the `cockroach` binary to [`EXPLAIN`](explain.html) the query plan:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT * FROM users WHERE name = 'Natalie Cunningham';"
-~~~
-
-~~~
-  tree |    field    |         description
--------+-------------+------------------------------
-       | distributed | true
-       | vectorized  | false
-  scan |             |
-       | table       | users@primary
-       | spans       | FULL SCAN
-       | filter      | name = 'Natalie Cunningham'
-(6 rows)
-~~~
-
-The row with `spans | FULL SCAN` shows you that, without a secondary index on the `name` column, CockroachDB scans every row of the `users` table, ordered by the primary key (`city`/`id`), until it finds the row with the correct `name` value.
-
-#### Filtering by a secondary index
-
-To speed up this query, add a secondary index on `name`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="CREATE INDEX on users (name);"
-~~~
-
-The query will now return much faster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT * FROM users WHERE name = 'Natalie Cunningham'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['id', 'city', 'name', 'address', 'credit_card']
-['02cc9e5b-1e91-4cdb-87c4-726b4ea7219a', 'boston', 'Natalie Cunningham', '97477 Lee Path\nKimberlyport, CA 65960', '4532613656695680']
-
-Times (milliseconds):
-[3.545045852661133, 1.4619827270507812, 1.399993896484375, 2.0101070404052734, 1.672983169555664, 1.4941692352294922, 1.4650821685791016, 1.4579296112060547, 1.567840576171875, 1.5709400177001953, 1.4760494232177734, 1.6181468963623047, 1.6210079193115234, 1.6970634460449219, 1.6469955444335938, 1.7261505126953125, 1.7559528350830078, 1.875162124633789, 1.7170906066894531, 1.870870590209961, 1.641988754272461, 1.7061233520507812, 1.628875732421875, 1.6558170318603516, 1.7809867858886719, 1.6698837280273438, 1.8429756164550781, 1.6090869903564453, 1.7080307006835938, 1.74713134765625, 1.6620159149169922, 1.9519329071044922, 1.6849040985107422, 1.7440319061279297, 1.8851757049560547, 1.8699169158935547, 1.7409324645996094, 1.9140243530273438, 1.7828941345214844, 1.7158985137939453, 1.6720294952392578, 1.7750263214111328, 1.7368793487548828, 1.9288063049316406, 1.8749237060546875, 1.7838478088378906, 1.8091201782226562, 1.8210411071777344, 1.7669200897216797, 1.8210411071777344]
-
-Median time (milliseconds):
-1.72162055969
-~~~
-
-To understand why performance improved from 4.51ms (without index) to 1.72ms (with index), use [`EXPLAIN`](explain.html) to see the new query plan:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT * FROM users WHERE name = 'Natalie Cunningham';"
-~~~
-
-~~~
-     tree    |    field    |                      description
--------------+-------------+--------------------------------------------------------
-             | distributed | false
-             | vectorized  | false
-  index-join |             |
-   │         | table       | users@primary
-   │         | key columns | city, id
-   └── scan  |             |
-             | table       | users@users_name_idx
-             | spans       | /"Natalie Cunningham"-/"Natalie Cunningham"/PrefixEnd
-(8 rows)
-~~~
-
-This shows you that CockroachDB starts with the secondary index (`table | users@users_name_idx`). Because it is sorted by `name`, the query can jump directly to the relevant value (`spans | /"Natalie Cunningham"-/"Natalie Cunningham"/PrefixEnd`). However, the query needs to return values not in the secondary index, so CockroachDB grabs the primary key (`city`/`id`) stored with the `name` value (the primary key is always stored with entries in a secondary index), jumps to that value in the primary index, and then returns the full row.
-
-Thinking back to the [earlier discussion of ranges and leaseholders](#important-concepts), because the `users` table is under 512 MiB, the primary index and all secondary indexes are contained in a single range with a single leaseholder. If the table were bigger, however, the primary index and secondary index could reside in separate ranges, each with its own leaseholder. In this case, if the leaseholders were on different nodes, the query would require more network hops, further increasing latency.
-
-#### Filtering by a secondary index storing additional columns
-
-When you have a query that filters by a specific column but retrieves a subset of the table's total columns, you can improve performance by [storing](indexes.html#storing-columns) those additional columns in the secondary index to prevent the query from needing to scan the primary index as well.
-
-For example, let's say you frequently retrieve a user's name and credit card number:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT name, credit_card FROM users WHERE name = 'Natalie Cunningham'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['name', 'credit_card']
-['Natalie Cunningham', '4532613656695680']
-
-Times (milliseconds):
-[2.8769969940185547, 1.7559528350830078, 1.8100738525390625, 1.8839836120605469, 1.5971660614013672, 1.5900135040283203, 1.7750263214111328, 2.2847652435302734, 1.641988754272461, 1.4967918395996094, 1.4641284942626953, 1.6689300537109375, 1.9679069519042969, 1.8970966339111328, 1.8780231475830078, 1.7609596252441406, 1.68609619140625, 1.9791126251220703, 1.661062240600586, 1.9869804382324219, 1.5938282012939453, 1.8041133880615234, 1.5909671783447266, 1.5878677368164062, 1.7380714416503906, 1.638174057006836, 1.6970634460449219, 1.9309520721435547, 1.992940902709961, 1.8689632415771484, 1.7511844635009766, 2.007007598876953, 1.9829273223876953, 1.8939971923828125, 1.7490386962890625, 1.6179084777832031, 1.6510486602783203, 1.6078948974609375, 1.6129016876220703, 1.67083740234375, 1.786947250366211, 1.7840862274169922, 1.956939697265625, 1.8689632415771484, 1.9350051879882812, 1.789093017578125, 1.9249916076660156, 1.8649101257324219, 1.9619464874267578, 1.7361640930175781]
-
-Median time (milliseconds):
-1.77955627441
-~~~
-
-With the current secondary index on `name`, CockroachDB still needs to scan the primary index to get the credit card number:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT name, credit_card FROM users WHERE name = 'Natalie Cunningham';"
-~~~
-
-~~~
-     tree    |    field    |                      description
--------------+-------------+--------------------------------------------------------
-             | distributed | false
-             | vectorized  | false
-  index-join |             |
-   │         | table       | users@primary
-   │         | key columns | city, id
-   └── scan  |             |
-             | table       | users@users_name_idx
-             | spans       | /"Natalie Cunningham"-/"Natalie Cunningham"/PrefixEnd
-(8 rows)
-~~~
-
-Let's drop and recreate the index on `name`, this time storing the `credit_card` value in the index:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="DROP INDEX users_name_idx;"
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="CREATE INDEX ON users (name) STORING (credit_card);"
-~~~
-
-Now that `credit_card` values are stored in the index on `name`, CockroachDB only needs to scan that index:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT name, credit_card FROM users WHERE name = 'Natalie Cunningham';"
-~~~
-
-~~~
-  tree |    field    |                      description
--------+-------------+--------------------------------------------------------
-       | distributed | false
-       | vectorized  | false
-  scan |             |
-       | table       | users@users_name_idx
-       | spans       | /"Natalie Cunningham"-/"Natalie Cunningham"/PrefixEnd
-(5 rows)
-~~~
-
-This results in even faster performance, reducing latency from 1.77ms (index without storing) to 0.99ms (index with storing):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT name, credit_card FROM users WHERE name = 'Natalie Cunningham'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['name', 'credit_card']
-['Natalie Cunningham', '4532613656695680']
-
-Times (milliseconds):
-[1.8029212951660156, 0.9858608245849609, 0.9548664093017578, 0.8459091186523438, 0.9710788726806641, 1.1639595031738281, 0.8571147918701172, 0.8800029754638672, 0.8509159088134766, 0.8771419525146484, 1.1739730834960938, 0.9100437164306641, 1.1181831359863281, 0.9679794311523438, 1.0800361633300781, 1.02996826171875, 1.2090206146240234, 1.0440349578857422, 1.210927963256836, 1.0418891906738281, 1.1951923370361328, 0.9548664093017578, 1.0848045349121094, 0.9748935699462891, 1.15203857421875, 1.0280609130859375, 1.0819435119628906, 0.9641647338867188, 1.0979175567626953, 0.9720325469970703, 1.0638236999511719, 0.9410381317138672, 1.0039806365966797, 1.207113265991211, 0.9911060333251953, 1.0039806365966797, 0.9810924530029297, 0.9360313415527344, 0.9589195251464844, 1.0609626770019531, 0.9949207305908203, 1.0139942169189453, 0.9899139404296875, 0.9818077087402344, 0.9679794311523438, 0.8809566497802734, 0.9558200836181641, 0.8878707885742188, 1.0380744934082031, 0.8897781372070312]
-
-Median time (milliseconds):
-0.990509986877
-~~~
-
-#### Joining data from different tables
-
-Secondary indexes are crucial when [joining](joins.html) data from different tables as well.
-
-For example, let's say you want to count the number of users who started rides on a given day. To do this, you need to use a join to get the relevant rides from the `rides` table and then map the `rider_id` for each of those rides to the corresponding `id` in the `users` table, counting each mapping only once:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT count(DISTINCT users.id) \
-FROM users \
-INNER JOIN rides ON rides.rider_id = users.id \
-WHERE start_time BETWEEN '2018-07-20 00:00:00' AND '2018-07-21 00:00:00'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['count']
-['1998']
-
-Times (milliseconds):
-[1443.5458183288574, 1546.0000038146973, 1563.858985900879, 1530.3218364715576, 1574.7389793395996, 1572.7760791778564, 1566.4539337158203, 1595.655918121338, 1588.2930755615234, 1567.6488876342773, 1564.5530223846436, 1573.4570026397705, 1581.406831741333, 1587.864875793457, 1575.7901668548584, 1565.0341510772705, 1519.8209285736084, 1599.7698307037354, 1612.4188899993896, 1582.5250148773193, 1604.076862335205, 1596.8739986419678, 1569.6821212768555, 1583.7080478668213, 1549.9720573425293, 1563.5790824890137, 1555.6750297546387, 1577.6000022888184, 1582.3569297790527, 1568.8848495483398, 1580.854892730713, 1566.9701099395752, 1578.8500308990479, 1592.677116394043, 1549.3559837341309, 1561.805009841919, 1561.812162399292, 1543.4870719909668, 1523.3290195465088, 1583.9049816131592, 1565.9120082855225, 1575.1979351043701, 1581.1400413513184, 1616.6048049926758, 1602.9179096221924, 1583.8429927825928, 1570.2300071716309, 1573.2421875, 1558.588981628418, 1548.7489700317383]
-
-Median time (milliseconds):
-1573.00913334
-~~~
-
-To understand what's happening, use [`EXPLAIN`](explain.html) to see the query plan:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT count(DISTINCT users.id) \
-FROM users \
-INNER JOIN rides ON rides.rider_id = users.id \
-WHERE start_time BETWEEN '2018-07-20 00:00:00' AND '2018-07-21 00:00:00';"
-~~~
-
-~~~
-         tree         |    field    |                                         description
-----------------------+-------------+----------------------------------------------------------------------------------------------
-                      | distributed | true
-                      | vectorized  | false
-  group               |             |
-   │                  | aggregate 0 | count(DISTINCT id)
-   │                  | scalar      |
-   └── render         |             |
-        └── hash-join |             |
-             │        | type        | inner
-             │        | equality    | (rider_id) = (id)
-             ├── scan |             |
-             │        | table       | rides@primary
-             │        | spans       | FULL SCAN
-             │        | filter      | (start_time >= '2018-07-20 00:00:00+00:00') AND (start_time <= '2018-07-21 00:00:00+00:00')
-             └── scan |             |
-                      | table       | users@users_name_idx
-                      | spans       | FULL SCAN
-(16 rows)
-~~~
-
-Reading from bottom up, you can see that CockroachDB does a full table scan (`spans | FULL SCAN`) first on `rides` to get all rows with a `start_time` in the specified range and then does another full table scan on `users` to find matching rows and calculate the count.
-
-Given that the `rides` table is large, its data is split across several ranges. Each range is replicated and has a leaseholder. At least some of these leaseholders are likely located on different nodes. This means that the full table scan of `rides` involves several network hops to various leaseholders before finally going to the leaseholder for `users` to do a full table scan there.
-
-To track this specifically, let's use the [`SHOW RANGES`](show-ranges.html) statement to find out where the relevant leaseholders reside for `rides` and `users`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="SHOW RANGES FROM TABLE rides;"
-~~~
-
-~~~
-                           start_key                           |                           end_key                            | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+--------------------------------------------------------------+--------------------------------------------------------------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL                                                         | /"boston"/"\x00\x00\a\xef\xfa\x0fJn\xa0\x89\xcet\xaa\x8d\"v" |       33 |             0 |            2 | region=us-central1    | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"boston"/"\x00\x00\a\xef\xfa\x0fJn\xa0\x89\xcet\xaa\x8d\"v" | /"boston"/"\x99\xf4ff\xbb1K\xf9\xab\x92\x83\x003(o\x8a"      |       41 |     21.520739 |            2 | region=us-central1    | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"boston"/"\x99\xf4ff\xbb1K\xf9\xab\x92\x83\x003(o\x8a"      | /"los angeles"/"3\ncK{?Oħ\x9e\xf0k\x96\xba\xad\xf2"          |       37 |     21.850083 |            3 | region=us-west1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"los angeles"/"3\ncK{?Oħ\x9e\xf0k\x96\xba\xad\xf2"          | /"new york"/"\xb3\xb4:#\x1f\x8aDݘ\xc9SC\a5*\xd4"             |       39 |     55.677376 |            3 | region=us-west1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"new york"/"\xb3\xb4:#\x1f\x8aDݘ\xc9SC\a5*\xd4"             | /"seattle"/"x\x15\xaa\x84\xc73Im\xa2\xbf\n\x81$\xcf\xf6\xda" |       55 |     66.072353 |            3 | region=us-west1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"seattle"/"x\x15\xaa\x84\xc73Im\xa2\xbf\n\x81$\xcf\xf6\xda" | NULL                                                         |       38 |     57.403476 |            2 | region=us-central1    | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="SHOW RANGES FROM TABLE users;"
-~~~
-
-~~~
-  start_key | end_key | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+-----------+---------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL      | NULL    |       26 |      0.267026 |            3 | region=us-west1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-(1 row)
-~~~
-
-The results above tell us:
-
-- The `rides` table is split across 6 ranges, with leaseholders on nodes 2 and 3.
-- The `users` table is stored in just a single range with its leaseholder on node 3.
-
-Now, given the `WHERE` condition of the join, the full table scan of `rides`, across all of its 6 ranges, is particularly wasteful. To speed up the query, you can create a secondary index on the `WHERE` condition (`rides.start_time`) storing the join key (`rides.rider_id`):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="CREATE INDEX ON rides (start_time) STORING (rider_id);"
-~~~
-
-Adding the secondary index reduced the query time from 1573ms to 61.56ms:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT count(DISTINCT users.id) \
-FROM users \
-INNER JOIN rides ON rides.rider_id = users.id \
-WHERE start_time BETWEEN '2018-07-20 00:00:00' AND '2018-07-21 00:00:00'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['count']
-['1998']
-
-Times (milliseconds):
-[66.78199768066406, 63.83800506591797, 65.57297706604004, 63.04502487182617, 61.54489517211914, 61.51890754699707, 60.935020446777344, 61.8891716003418, 60.71019172668457, 64.44311141967773, 64.82601165771484, 61.5849494934082, 62.136173248291016, 62.78491020202637, 62.70194053649902, 61.837196350097656, 64.13102149963379, 62.66903877258301, 71.14315032958984, 61.08808517456055, 58.36200714111328, 60.003042221069336, 58.743953704833984, 59.05413627624512, 60.63103675842285, 60.12582778930664, 61.02705001831055, 62.548160552978516, 61.45000457763672, 65.27113914489746, 60.18996238708496, 59.36002731323242, 60.13298034667969, 59.8299503326416, 59.168100357055664, 65.20915031433105, 60.43219566345215, 58.91895294189453, 58.67791175842285, 59.50117111206055, 59.977054595947266, 65.39011001586914, 62.3931884765625, 69.40793991088867, 61.64288520812988, 66.52498245239258, 69.78988647460938, 60.96601486206055, 57.71303176879883, 61.81192398071289]
-
-Median time (milliseconds):
-61.5649223328
-~~~
-
-To understand why performance improved, again use [`EXPLAIN`](explain.html) to see the new query plan:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT count(DISTINCT users.id) \
-FROM users \
-INNER JOIN rides ON rides.rider_id = users.id \
-WHERE start_time BETWEEN '2018-07-20 00:00:00' AND '2018-07-21 00:00:00';"
-~~~
-
-~~~
-         tree         |    field    |                      description
-----------------------+-------------+--------------------------------------------------------
-                      | distributed | true
-                      | vectorized  | false
-  group               |             |
-   │                  | aggregate 0 | count(DISTINCT id)
-   │                  | scalar      |
-   └── render         |             |
-        └── hash-join |             |
-             │        | type        | inner
-             │        | equality    | (rider_id) = (id)
-             ├── scan |             |
-             │        | table       | rides@rides_start_time_idx
-             │        | spans       | /2018-07-20T00:00:00Z-/2018-07-21T00:00:00.000000001Z
-             └── scan |             |
-                      | table       | users@users_name_idx
-                      | spans       | FULL SCAN
-(15 rows)
-~~~
-
-Notice that CockroachDB now starts by using `rides@rides_start_time_idx` secondary index to retrieve the relevant rides without needing to scan the full `rides` table.
-
-Let's check the ranges for the new index:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="SHOW RANGES FROM INDEX rides@rides_start_time_idx;"
-~~~
-
-~~~
-                                          start_key                                         |                                          end_key                                          | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+-------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL                                                                                      | /2018-07-03T01:30:40.141401Z/"new york"/"4v\xc5HJ\xf0Bս\xcb\x1f\xab\xe4\xd9y\x02"         |       43 |             0 |            1 | region=us-east1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /2018-07-03T01:30:40.141401Z/"new york"/"4v\xc5HJ\xf0Bս\xcb\x1f\xab\xe4\xd9y\x02"         | /2018-07-03T01:41:59.820666Z/"boston"/"\x8fX\xce\x02c\xb5O\x95\x81\x9d\xee\xa9D<\xb6\x03" |       45 |      0.431928 |            2 | region=us-central1    | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /2018-07-03T01:41:59.820666Z/"boston"/"\x8fX\xce\x02c\xb5O\x95\x81\x9d\xee\xa9D<\xb6\x03" | /2018-07-16T01:33:31.787252Z/"new york"/"\xb1\xbb\xc0\x98\xe1\xee@\"\xbayd\x0f\x02i\x18l" |       44 |     33.554432 |            1 | region=us-east1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /2018-07-16T01:33:31.787252Z/"new york"/"\xb1\xbb\xc0\x98\xe1\xee@\"\xbayd\x0f\x02i\x18l" | NULL                                                                                      |       46 |     46.717599 |            1 | region=us-east1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-(4 rows)
-~~~
-
-This tells us that the index is stored in 4 ranges, with the leaseholders on nodes 1 and 2. Based on the output of `SHOW RANGES FROM TABLE users` that we saw earlier, we already know that the leaseholder for the `users` table is on node 3.
-
-#### Using `IN (list)` with a subquery
-
-Now let's say you want to get the latest ride of each of the 5 most used vehicles. To do this, you might think to use a subquery to get the IDs of the 5 most frequent vehicles from the `rides` table, passing the results into the `IN` list of another query to get the most recent ride of each of the 5 vehicles:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT vehicle_id, max(end_time) \
-FROM rides \
-WHERE vehicle_id IN ( \
-    SELECT vehicle_id \
-    FROM rides \
-    GROUP BY vehicle_id \
-    ORDER BY count(*) DESC \
-    LIMIT 5 \
-) \
-GROUP BY vehicle_id" \
---repeat=20 \
---times
-~~~
-
-~~~
-Result:
-['vehicle_id', 'max']
-['3c950d36-c2b8-48d0-87d3-e0d6f570af62', '2018-08-02 03:06:31.293184']
-['0962cdca-9d85-457c-9616-cc2ae2d32008', '2018-08-02 03:01:25.414512']
-['78fdd6f8-c6a1-42df-a89f-cd65b7bb8be9', '2018-08-02 02:47:43.755989']
-['c6541da5-9858-4e3f-9b49-992e206d2c50', '2018-08-02 02:14:50.543760']
-['35752c4c-b878-4436-8330-8d7246406a55', '2018-08-02 03:08:49.823209']
-
-Times (milliseconds):
-[3012.6540660858154, 2456.5110206604004, 2482.675075531006, 2488.3930683135986, 2474.393129348755, 2494.3790435791016, 2504.063129425049, 2491.326093673706, 2507.4589252471924, 2482.077121734619, 2495.9230422973633, 2497.60103225708, 2478.4271717071533, 2496.574878692627, 2506.395101547241, 2468.4300422668457, 2476.508140563965, 2497.958183288574, 2480.7958602905273, 2484.0168952941895]
-
-Median time (milliseconds):
-2489.85958099
-~~~
-
-However, as you can see, this query is slow because, currently, when the `WHERE` condition of a query comes from the result of a subquery, CockroachDB scans the entire table, even if there is an available index. Use `EXPLAIN` to see this in more detail:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT vehicle_id, max(end_time) \
-FROM rides \
-WHERE vehicle_id IN ( \
-    SELECT vehicle_id \
-    FROM rides \
-    GROUP BY vehicle_id \
-    ORDER BY count(*) DESC \
-    LIMIT 5 \
-) \
-GROUP BY vehicle_id;"
-~~~
-
-~~~
-              tree              |       field        |                     description
---------------------------------+--------------------+------------------------------------------------------
-                                | distributed        | true
-                                | vectorized         | false
-  group                         |                    |
-   │                            | aggregate 0        | vehicle_id
-   │                            | aggregate 1        | max(end_time)
-   │                            | group by           | vehicle_id
-   └── hash-join                |                    |
-        │                       | type               | semi
-        │                       | equality           | (vehicle_id) = (vehicle_id)
-        │                       | right cols are key |
-        ├── scan                |                    |
-        │                       | table              | rides@primary
-        │                       | spans              | FULL SCAN
-        └── limit               |                    |
-             │                  | count              | 5
-             └── sort           |                    |
-                  │             | order              | -count_rows
-                  └── group     |                    |
-                       │        | aggregate 0        | vehicle_id
-                       │        | aggregate 1        | count_rows()
-                       │        | group by           | vehicle_id
-                       └── scan |                    |
-                                | table              | rides@rides_auto_index_fk_vehicle_city_ref_vehicles
-                                | spans              | FULL SCAN
-(24 rows)
-~~~
-
-This is a complex query plan, but the important thing to note is the full table scan of `rides@primary` above the `subquery`. This shows you that, after the subquery returns the IDs of the top 5 vehicles, CockroachDB scans the entire primary index to find the rows with `max(end_time)` for each `vehicle_id`, although you might expect CockroachDB to more efficiently use the secondary index on `vehicle_id` (CockroachDB is working to remove this limitation in a future version).
-
-#### Using `IN (list)` with explicit values
-
-Because CockroachDB will not use an available secondary index when using `IN (list)` with a subquery, it's much more performant to have your application first select the top 5 vehicles:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT vehicle_id \
-FROM rides \
-GROUP BY vehicle_id \
-ORDER BY count(*) DESC \
-LIMIT 5" \
---repeat=20 \
---times
-~~~
-
-~~~
-Result:
-['vehicle_id']
-['35752c4c-b878-4436-8330-8d7246406a55']
-['0962cdca-9d85-457c-9616-cc2ae2d32008']
-['c6541da5-9858-4e3f-9b49-992e206d2c50']
-['78fdd6f8-c6a1-42df-a89f-cd65b7bb8be9']
-['3c950d36-c2b8-48d0-87d3-e0d6f570af62']
-
-Times (milliseconds):
-[1049.2329597473145, 1038.0151271820068, 1037.7991199493408, 1036.5591049194336, 1037.7249717712402, 1040.544033050537, 1022.7780342102051, 1056.9651126861572, 1054.3549060821533, 1042.3550605773926, 1042.68217086792, 1031.7370891571045, 1051.880121231079, 1035.8471870422363, 1035.2818965911865, 1035.607099533081, 1040.0230884552002, 1048.8879680633545, 1056.014060974121, 1036.1089706420898]
-
-Median time (milliseconds):
-1039.01910782
-~~~
-
-And then put the results into the `IN` list to get the most recent rides of the vehicles:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT vehicle_id, max(end_time) \
-FROM rides \
-WHERE vehicle_id IN ( \
-  '35752c4c-b878-4436-8330-8d7246406a55', \
-  '0962cdca-9d85-457c-9616-cc2ae2d32008', \
-  'c6541da5-9858-4e3f-9b49-992e206d2c50', \
-  '78fdd6f8-c6a1-42df-a89f-cd65b7bb8be9', \
-  '3c950d36-c2b8-48d0-87d3-e0d6f570af62' \
-) \
-GROUP BY vehicle_id;" \
---repeat=20 \
---times
-~~~
-
-~~~
-Result:
-['vehicle_id', 'max']
-['35752c4c-b878-4436-8330-8d7246406a55', '2018-08-02 03:08:49.823209']
-['0962cdca-9d85-457c-9616-cc2ae2d32008', '2018-08-02 03:01:25.414512']
-['3c950d36-c2b8-48d0-87d3-e0d6f570af62', '2018-08-02 03:06:31.293184']
-['78fdd6f8-c6a1-42df-a89f-cd65b7bb8be9', '2018-08-02 02:47:43.755989']
-['c6541da5-9858-4e3f-9b49-992e206d2c50', '2018-08-02 02:14:50.543760']
-
-Times (milliseconds):
-[1165.5981540679932, 1135.9851360321045, 1201.0550498962402, 1135.0820064544678, 1195.7061290740967, 1132.0109367370605, 1134.9878311157227, 1175.88210105896, 1174.0548610687256, 1152.566909790039, 1164.9351119995117, 1175.5108833312988, 1161.651849746704, 1195.3318119049072, 1162.4629497528076, 1156.1191082000732, 1127.0110607147217, 1165.4651165008545, 1159.6789360046387, 1190.3491020202637]
-
-Median time (milliseconds):
-1163.69903088
-~~~
-
-This approach reduced the query time from 2489.85ms (query with subquery) to 2202.70ms (2 distinct queries).
-
-### Step 7. Test/tune write performance
-
-- [Bulk inserting into an existing table](#bulk-inserting-into-an-existing-table)
-- [Minimizing unused indexes](#minimizing-unused-indexes)
-- [Retrieving the ID of a newly inserted row](#retrieving-the-id-of-a-newly-inserted-row)
-
-#### Bulk inserting into an existing table
-
-Moving on to writes, let's imagine that you have a batch of 100 new users to insert into the `users` table. The most obvious approach is to insert each row using 100 separate [`INSERT`](insert.html) statements:  
-
-{{site.data.alerts.callout_info}}
-For the purpose of demonstration, the command below inserts the same user 100 times, each time with a different unique ID. Note also that you're now adding the `--cumulative` flag to print the total time across all 100 inserts.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="INSERT INTO users VALUES (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347')" \
---repeat=100 \
---times \
---cumulative
-~~~
-
-~~~
-Times (milliseconds):
-[10.773181915283203, 12.186050415039062, 9.711980819702148, 9.730815887451172, 10.200977325439453, 9.32002067565918, 9.002923965454102, 9.426116943359375, 9.312152862548828, 8.329153060913086, 9.626150131225586, 8.965015411376953, 9.562969207763672, 9.305000305175781, 9.34910774230957, 7.394075393676758, 9.3231201171875, 9.066104888916016, 8.419036865234375, 9.158134460449219, 9.278059005737305, 8.022069931030273, 8.542060852050781, 9.237051010131836, 8.165121078491211, 8.094072341918945, 8.025884628295898, 8.04591178894043, 9.728193283081055, 8.485078811645508, 7.967948913574219, 9.319067001342773, 8.099079132080078, 9.041070938110352, 10.046005249023438, 10.684013366699219, 9.672880172729492, 8.129119873046875, 8.10098648071289, 7.884979248046875, 9.484052658081055, 8.594036102294922, 9.479045867919922, 9.239912033081055, 9.16600227355957, 9.155988693237305, 9.392976760864258, 11.08694076538086, 9.402990341186523, 8.034944534301758, 8.053064346313477, 8.03995132446289, 8.891820907592773, 8.054971694946289, 8.903980255126953, 9.057998657226562, 9.713888168334961, 7.99107551574707, 8.114814758300781, 8.677959442138672, 11.178970336914062, 9.272098541259766, 9.281158447265625, 8.177995681762695, 9.47880744934082, 10.025978088378906, 8.352041244506836, 8.320808410644531, 10.892868041992188, 8.227825164794922, 8.220911026000977, 9.625911712646484, 10.272026062011719, 8.116960525512695, 10.786771774291992, 9.073972702026367, 9.686946868896484, 9.903192520141602, 9.887933731079102, 9.399890899658203, 9.413003921508789, 8.594036102294922, 8.433103561401367, 9.271860122680664, 8.529901504516602, 9.474992752075195, 9.005069732666016, 9.341001510620117, 9.388923645019531, 9.775876998901367, 8.558988571166992, 9.613990783691406, 8.897066116333008, 8.642911911010742, 9.527206420898438, 8.274078369140625, 9.073972702026367, 9.637832641601562, 8.516788482666016, 9.564876556396484]
-
-Median time (milliseconds):
-9.20152664185
-
-Cumulative time (milliseconds):
-910.985708237
-~~~
-
-The 100 inserts took 910.98ms to complete, which isn't bad. However, it's significantly faster to use a single `INSERT` statement with 100 comma-separated `VALUES` clauses:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="INSERT INTO users VALUES \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347')" \
---repeat=1 \
---cumulative
-~~~
-
-~~~
-Median time (milliseconds):
-15.4001712799
-
-Cumulative time (milliseconds):
-15.4001712799
-~~~
-
-As you can see, this multi-row `INSERT` technique reduced the total time for 100 inserts from 910.98ms to 15.40ms. It's useful to note that this technique is equally effective for [`UPSERT`](upsert.html) and [`DELETE`](delete.html) statements as well.
-
-{{site.data.alerts.callout_info}}
-You can also use the [`IMPORT INTO`](import-into.html) statement to bulk-insert CSV data into an existing table.
-{{site.data.alerts.end}}
-
-#### Minimizing unused indexes
-
-Earlier, we saw how important secondary indexes are for read performance. For writes, however, it's important to recognized the overhead that they create.
-
-Let's consider the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="SHOW INDEXES FROM users;"
-~~~
-
-~~~
-  table_name |   index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit
-+------------+----------------+------------+--------------+-------------+-----------+---------+----------+
-  users      | primary        |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary        |   false    |            2 | id          | ASC       |  false  |  false
-  users      | users_name_idx |    true    |            1 | name        | ASC       |  false  |  false
-  users      | users_name_idx |    true    |            2 | credit_card | N/A       |  true   |  false
-  users      | users_name_idx |    true    |            3 | city        | ASC       |  false  |   true
-  users      | users_name_idx |    true    |            4 | id          | ASC       |  false  |   true
-(6 rows)
-~~~
-
-This table has the primary index (the full table) and a secondary index on `name` that is also storing `credit_card`. This means that whenever a row is inserted, or whenever `name`, `credit_card`, `city`, or `id` are modified in existing rows, both indexes are updated.
-
-To make this more concrete, let's count how many rows have a name that starts with `C` and then update those rows to all have the same name:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT count(*) \
-FROM users \
-WHERE name LIKE 'C%'" \
---repeat=1
-~~~
-
-~~~
-['count']
-['179']
-
-Median time (milliseconds):
-2.52604484558
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="UPDATE users \
-SET name = 'Carl Kimball' \
-WHERE name LIKE 'C%'" \
---repeat=1
-~~~
-
-~~~
-Median time (milliseconds):
-52.2060394287
-~~~
-
-Because `name` is in both the `primary` and `users_name_idx` indexes, for each of the 168 rows, 2 keys were updated.
-
-Now, assuming that the `users_name_idx` index is no longer needed, lets drop the index and execute an equivalent query:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---insecure \
---host=<address of any node> \
---database=movr \
---execute="DROP INDEX users_name_idx;"
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="UPDATE users \
-SET name = 'Peedie Hirata' \
-WHERE name = 'Carl Kimball'" \
---repeat=1
-~~~
-
-~~~
-Median time (milliseconds):
-22.7289199829
-~~~
-
-Before, when both the primary and secondary indexes needed to be updated, the updates took 52.20ms. Now, after dropping the secondary index, an equivalent update took only 22.72ms.
-
-#### Retrieving the ID of a newly inserted row
-
-Now let's focus on the common case of inserting a row into a table and then retrieving the ID of the new row to do some follow-up work. One approach is to execute two statements, an `INSERT` to insert the row and then a `SELECT` to get the new ID:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="INSERT INTO users VALUES (gen_random_uuid(), 'new york', 'Toni Brooks', '800 Camden Lane, Brooklyn, NY 11218', '98244843845134960')" \
---repeat=1
-~~~
-
-~~~
-Median time (milliseconds):
-10.4398727417
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="SELECT id FROM users WHERE name = 'Toni Brooks'" \
---repeat=1
-~~~
-
-~~~
-Result:
-['id']
-['ae563e17-ad59-4307-a99e-191e682b4278']
-
-Median time (milliseconds):
-5.53798675537
-~~~
-
-Combined, these statements are relatively fast, at 15.96ms, but an even more performant approach is to append `RETURNING id` to the end of the `INSERT`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ ./tuning.py \
---host=<address of any node> \
---statement="INSERT INTO users VALUES (gen_random_uuid(), 'new york', 'Brian Brooks', '800 Camden Lane, Brooklyn, NY 11218', '98244843845134960') \
-RETURNING id" \
---repeat=1
-~~~
-
-~~~
-Result:
-['id']
-['3d16500e-cb2e-462e-9c83-db0965d6deaf']
-
-Median time (milliseconds):
-9.48596000671
-~~~
-
-At just 9.48ms, this approach is faster due to the write and read executing in one instead of two client-server roundtrips. Note also that, as discussed earlier, if the leaseholder for the table happens to be on a different node than the query is running against, that introduces additional network hops and latency.
-
-<!-- - upsert instead of insert/update
-- update using case expressions (instead of 2 separate updates)
-- returning nothing
-- insert with returning (auto gen ID) instead of select to get auto gen ID -->
-
-## Multi-region deployment
-
-<!-- roachprod instructions for multi-region deployment
-You created all instanced up front, so no need to add more now.
-1. Start the nodes in us-west1-a: roachprod start -b "/usr/local/bin/cockroach" <yourname>-tuning:5-7
-2. Start the nodes in us-west2-a: roachprod start -b "/usr/local/bin/cockroach" <yourname>-tuning:9-11
-3. Install the Python client on instance 8:
-   - SSH to instance 8: roachprod run <yourname>-tuning:8
-   - Run commands in Step 5 above.
-4. Install the Python client on instance 12:
-   - SSH onto instance 12: roachprod run <yourname>-tuning:12
-   - Run commands in Step 5 above.
-5. Check rebalancing:
-   - SSH to instance 4, 8, or 12.
-   - Run `SHOW RANGES` from Step 11 below.
-6. Test performance:
-   - Run the SQL commands in Step 12 below. You'll need to SSH to instance 8 or 12 as suggested.
-7. Partition the data:
-   - SSH to any node and run the SQL in Step 13 below.
-8. Check rebalancing after partitioning:
-   - SSH to instance 4, 8, or 12.
-   - Run `SHOW RANGES` from Step 14 below.
-8. Test performance after partitioning:
-   - Run the SQL commands in Step 15 below. You'll need to SSH to instance 8 or 12 as suggested.
--->
-
-Given that Movr is active on both US coasts, you'll now scale the cluster into two new regions, `us-west1-a` and `us-west2-a`, each with 3 nodes and an extra instance for simulating regional client traffic.
-
-### Step 8. Create more instances
-
-1. [Create 6 more instances](https://cloud.google.com/compute/docs/instances/create-start-instance), 3 in the `us-west1-a` zone (Oregon), and 3 in the `us-west2-a` zone (Los Angeles). While creating each instance:
-    - Use the `n2-standard-4` machine type (4 vCPUs, 16 GB memory).
-    - Use the Ubuntu 16.04 OS image.
-    - [Create and mount a local SSD](https://cloud.google.com/compute/docs/disks/local-ssd#create_local_ssd).
-    - To apply the Web UI firewall rule you created earlier, click **Management, disk, networking, SSH keys**, select the **Networking** tab, and then enter `cockroachdb` in the **Network tags** field.
-
-2. Note the internal IP address of each `n2-standard-4` instance. You'll need these addresses when starting the CockroachDB nodes.
-
-3. Create an additional instance in the `us-west1-a` and `us-west2-a` zones. These can be smaller, such as `n2-standard-2`.
-
-### Step 9. Scale the cluster
-
-{% include {{ page.version.version }}/performance/scale-cluster.md %}
-
-### Step 10. Install the Python client
-
-In each of the new zones, SSH to the instance not running a CockroachDB node, and install the Python client as described in [step 5](#step-5-install-the-python-client) above.
-
-### Step 11. Check rebalancing
-
-{% include {{ page.version.version }}/performance/check-rebalancing.md %}
-
-### Step 12. Test performance
-
-{% include {{ page.version.version }}/performance/test-performance.md %}
-
-### Step 13. Partition data by city
-
-{% include {{ page.version.version }}/performance/partition-by-city.md %}
-
-### Step 14. Check rebalancing after partitioning
-
-{% include {{ page.version.version }}/performance/check-rebalancing-after-partitioning.md %}
-
-### Step 15. Test performance after partitioning
-
-{% include {{ page.version.version }}/performance/test-performance-after-partitioning.md %}
-
-## See also
-
-- [SQL Performance Best Practices](performance-best-practices-overview.html)
-- [Performance Benchmarking](performance-benchmarking-with-tpcc-small.html)
-- [Production Checklist](recommended-production-settings.html)
diff --git a/src/current/v20.2/performance-tuning.md b/src/current/v20.2/performance-tuning.md
deleted file mode 100644
index b5ce44b0ee2..00000000000
--- a/src/current/v20.2/performance-tuning.md
+++ /dev/null
@@ -1,1286 +0,0 @@
----
-title: Performance Tuning
-summary: Essential techniques for getting fast reads and writes in a single- and multi-region CockroachDB deployment.
-toc: true
-certs: --certs-dir=certs
-app: ./tuning-secure.py
----
-
-<div class="filters filters-big clearfix">
-  <button class="filter-button current"><strong>Secure</strong></button>
-  <a href="performance-tuning-insecure.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-This tutorial shows you essential techniques for getting fast reads and writes in CockroachDB, starting with a single-region deployment and expanding into multiple regions.
-
-For a comprehensive list of tuning recommendations, only some of which are demonstrated here, see [SQL Performance Best Practices](performance-best-practices-overview.html).
-
-## Overview
-
-{% include {{ page.version.version }}/performance/overview.md %}
-
-## Single-region deployment
-
-<!-- roachprod instructions for single-region deployment
-1. Reserve 12 instances across 3 GCE zone: roachprod create <yourname>-tuning --geo --gce-zones us-east1-b,us-west1-a,us-west2-a --local-ssd -n 12
-2. Put cockroach` on all instances:
-   - roachprod stage <yourname>-tuning release v2.1.0-beta.20181008
-3. Start the cluster in us-east1-b: roachprod start <yourname>-tuning:1-3
-4. You'll need the addresses of all instances later, so list and record them somewhere: roachprod list -d <yourname>-tuning
-5. Import the MovR dataset:
-   - SSH onto instance 4: roachprod run <yourname>-tuning:4
-   - Run the SQL commands in Step 4 below.
-8. Install the Python client:
-   - Still on instance 4, run commands in Step 5 below.
-9. Test/tune read performance:
-   - Still on instance 4, run commands in Step 6.
-10. Test/tune write performance:
-   - Still on instance 4, run commands in Step 7.
--->
-
-### Step 1. Configure your network
-
-{% include {{ page.version.version }}/performance/configure-network.md %}
-
-### Step 2. Create instances
-
-You'll start with a 3-node CockroachDB cluster in the `us-east1-b` GCE zone, with an extra instance for running a client application workload.
-
-1. [Create 3 instances](https://cloud.google.com/compute/docs/instances/create-start-instance) for your CockroachDB nodes. While creating each instance:  
-    - Select the `us-east1-b` [zone](https://cloud.google.com/compute/docs/regions-zones/).
-    - Use the `n2-standard-4` machine type (4 vCPUs, 16 GB memory).
-    - Use the Ubuntu 16.04 OS image.
-    - [Create and mount a local SSD](https://cloud.google.com/compute/docs/disks/local-ssd#create_local_ssd).
-    - To apply the DB Console firewall rule you created earlier, click **Management, disk, networking, SSH keys**, select the **Networking** tab, and then enter `cockroachdb` in the **Network tags** field.
-
-2. Note the internal and external IP addresses of each `n2-standard-4` instance. You'll need these addresses when generating security certificates and when starting the CockroachDB nodes.
-
-3. Create a separate instance for running a client application workload, also in the `us-east1-b` zone. This instance can be smaller, such as `n2-standard-2`.
-
-### Step 3. Start a 3-node cluster
-
-#### Generate security certificates
-
-You can use either `cockroach cert` commands or [`openssl` commands](create-security-certificates-openssl.html) to generate security certificates. This section features the `cockroach cert` commands.
-
-Locally, you'll need to [create the following certificates and keys](cockroach-cert.html):
-
-- A certificate authority (CA) key pair (`ca.crt` and `ca.key`).
-- A node key pair for each node, issued to its IP addresses and any common names the machine uses.
-- A client key pair for the `root` user. You'll use this when running you client application workload as well as some `cockroach` client commands.
-
-{{site.data.alerts.callout_success}}
-As mentioned above, before beginning, it's useful to collect each instance's internal and external IP addresses, as well as any server names you want to issue certificates for.
-{{site.data.alerts.end}}
-
-1. [Install CockroachDB](install-cockroachdb.html) on your local machine, if you haven't already.
-
-2. Create two directories:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir my-safe-directory
-    ~~~
-    - `certs`: You'll generate your CA certificate and all node and client certificates and keys in this directory and then upload some of the files to your nodes.
-    - `my-safe-directory`: You'll generate your CA key in this directory and then reference the key when generating node and client certificates. After that, you'll keep the key safe and secret; you will not upload it to your nodes.
-
-3. Create the CA certificate and key:
-
-    {% include copy-clipboard.html %}
-  	~~~ shell
-  	$ cockroach cert create-ca \
-  	{{page.certs}} \
-  	--ca-key=my-safe-directory/ca.key
-  	~~~
-
-4. Create the certificate and key for the first node, issued to all common names you might use to refer to the node:
-
-    {% include copy-clipboard.html %}
-  	~~~ shell
-  	$ cockroach cert create-node \
-  	<node1 internal IP address> \
-  	<node1 external IP address> \
-  	<node1 hostname>  \
-  	<other common names for node1> \
-  	localhost \
-  	127.0.0.1 \
-  	{{page.certs}} \
-  	--ca-key=my-safe-directory/ca.key
-  	~~~
-
-5. Upload certificates to the first instance:
-
-    {% include copy-clipboard.html %}
-  	~~~ shell
-  	# Create the certs directory:
-  	$ ssh <username>@<node1 address> "mkdir certs"
-  	~~~
-
-  	{% include copy-clipboard.html %}
-  	~~~ shell
-  	# Upload the CA certificate and node certificate and key:
-  	$ scp certs/ca.crt \
-  	certs/node.crt \
-  	certs/node.key \
-  	<username>@<node1 address>:~/certs
-  	~~~
-
-6. Delete the local copy of the node certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm certs/node.crt certs/node.key
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    This is necessary because the certificates and keys for additional nodes will also be named `node.crt` and `node.key`. As an alternative to deleting these files, you can run the next `cockroach cert create-node` commands with the `--overwrite` flag.
-    {{site.data.alerts.end}}
-
-7. Create the certificate and key for the second node, issued to all common names you might use to refer to the node:
-
-    {% include copy-clipboard.html %}
-  	~~~ shell
-  	$ cockroach cert create-node \
-  	<node2 internal IP address> \
-  	<node2 external IP address> \
-  	<node2 hostname>  \
-  	<other common names for node2> \
-  	localhost \
-  	127.0.0.1 \
-  	{{page.certs}} \
-  	--ca-key=my-safe-directory/ca.key
-  	~~~
-
-8. Upload certificates to the second instance:
-
-    {% include copy-clipboard.html %}
-  	~~~ shell
-  	# Create the certs directory:
-  	$ ssh <username>@<node2 address> "mkdir certs"
-  	~~~
-
-  	{% include copy-clipboard.html %}
-  	~~~ shell
-  	# Upload the CA certificate and node certificate and key:
-  	$ scp certs/ca.crt \
-  	certs/node.crt \
-  	certs/node.key \
-  	<username>@<node2 address>:~/certs
-  	~~~
-
-9. Repeat steps 6 - 8 for the third node.
-
-10. Create a client certificate and key for the `root` user:
-
-    {% include copy-clipboard.html %}
-  	~~~ shell
-  	$ cockroach cert create-client \
-  	root \
-  	{{page.certs}} \
-  	--ca-key=my-safe-directory/ca.key
-  	~~~
-
-11. Upload certificates to the fourth instance, the one from which you will run a sample workload:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Create the certs directory:
-    $ ssh <username>@<instance4 address> "mkdir certs"
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Upload the CA certificate and client certificate and key:
-    $ scp certs/ca.crt \
-    certs/client.root.crt \
-    certs/client.root.key \
-    <username>@<instance4 address>:~/certs
-    ~~~
-
-{{site.data.alerts.callout_info}}
-On accessing the DB Console in a later step, your browser will consider the CockroachDB-created certificate invalid and you’ll need to click through a warning message to get to the UI. You can avoid this issue by [using a certificate issued by a public CA](create-security-certificates-custom-ca.html#accessing-the-db-console-for-a-secure-cluster).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/performance/start-cluster.md %}
-
-### Step 4. Load the MovR dataset
-
-
-{% include {{ page.version.version }}/performance/import-movr.md %}
-
-### Step 5. Install the Python client
-
-When measuring SQL performance, it's best to run a given statement multiple times and look at the average and/or cumulative latency. For that purpose, you'll install and use a Python testing client.
-
-1. Still on the fourth instance, make sure all of the system software is up-to-date:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo apt-get update && sudo apt-get -y upgrade
-    ~~~
-
-2. Install the `psycopg2` driver:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ sudo apt-get install python-psycopg2
-    ~~~
-
-3. Download the Python client:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ wget https://raw.githubusercontent.com/cockroachdb/docs/master/_includes/{{ page.version.version }}/performance/tuning-secure.py \
-    && chmod +x tuning-secure.py
-    ~~~
-
-    As you'll see below, this client lets you pass command-line flags:
-
-    Flag | Description
-    -----|------------
-    `--host` | The IP address of the target node. This is used in the client's connection string.
-    `--statement` | The SQL statement to execute.
-    `--repeat` | The number of times to repeat the statement. This defaults to 20.
-
-    When run, the client prints the median time in seconds across all repetitions of the statement. Optionally, you can pass two other flags, `--time` to print the execution time in seconds for each repetition of the statement, and `--cumulative` to print the cumulative time in seconds for all repetitions. `--cumulative` is particularly useful when testing writes.
-
-    {{site.data.alerts.callout_success}}
-    To get similar help directly in your shell, use `{{page.app}} --help`.
-    {{site.data.alerts.end}}
-
-### Step 6. Test/tune read performance
-
-- [Filtering by the primary key](#filtering-by-the-primary-key)
-- [Filtering by a non-indexed column (full table scan)](#filtering-by-a-non-indexed-column-full-table-scan)
-- [Filtering by a secondary index](#filtering-by-a-secondary-index)
-- [Filtering by a secondary index storing additional columns](#filtering-by-a-secondary-index-storing-additional-columns)
-- [Joining data from different tables](#joining-data-from-different-tables)
-- [Using `IN (list)` with a subquery](#using-in-list-with-a-subquery)
-- [Using `IN (list)` with explicit values](#using-in-list-with-explicit-values)
-
-#### Filtering by the primary key
-
-Retrieving a single row based on the primary key will usually return in 2ms or less:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT * FROM rides WHERE city = 'boston' AND id = '000007ef-fa0f-4a6e-a089-ce74aa8d2276'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['id', 'city', 'vehicle_city', 'rider_id', 'vehicle_id', 'start_address', 'end_address', 'start_time', 'end_time', 'revenue']
-['000007ef-fa0f-4a6e-a089-ce74aa8d2276', 'boston', 'boston', 'd66c386d-4b7b-48a7-93e6-f92b5e7916ab', '6628bbbc-00be-4891-bc00-c49f2f16a30b', '4081 Conner Courts\nSouth Taylor, VA 86921', '2808 Willis Wells Apt. 931\nMccoyberg, OH 10303-4879', '2018-07-20 01:46:46.003070', '2018-07-20 02:27:46.003070', '44.25']
-
-Times (milliseconds):
-[2.1638870239257812, 1.2159347534179688, 1.0809898376464844, 1.0669231414794922, 1.2650489807128906, 1.1401176452636719, 1.1310577392578125, 1.0380744934082031, 1.199960708618164, 1.0530948638916016, 1.1000633239746094, 1.3430118560791016, 1.104116439819336, 1.0750293731689453, 1.0609626770019531, 1.088857650756836, 1.1639595031738281, 1.2559890747070312, 1.1899471282958984, 1.0449886322021484, 1.1057853698730469, 1.127004623413086, 0.9729862213134766, 1.1131763458251953, 1.0879039764404297, 1.119852066040039, 1.065969467163086, 1.0371208190917969, 1.1181831359863281, 1.0409355163574219, 1.0859966278076172, 1.1398792266845703, 1.032114028930664, 1.1000633239746094, 1.1360645294189453, 1.146078109741211, 1.329183578491211, 1.1131763458251953, 1.1548995971679688, 0.9977817535400391, 1.1138916015625, 1.085042953491211, 1.0950565338134766, 1.0869503021240234, 1.0170936584472656, 1.0571479797363281, 1.0640621185302734, 1.1110305786132812, 1.1279582977294922, 1.1119842529296875]
-
-Median time (milliseconds):
-1.10495090485
-~~~
-
-Retrieving a subset of columns will usually be even faster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT rider_id, vehicle_id \
-FROM rides \
-WHERE city = 'boston' AND id = '000007ef-fa0f-4a6e-a089-ce74aa8d2276'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['rider_id', 'vehicle_id']
-['d66c386d-4b7b-48a7-93e6-f92b5e7916ab', '6628bbbc-00be-4891-bc00-c49f2f16a30b']
-
-Times (milliseconds):
-[2.218961715698242, 1.2569427490234375, 1.3570785522460938, 1.1570453643798828, 1.3251304626464844, 1.3320446014404297, 1.0790824890136719, 1.0139942169189453, 1.0251998901367188, 1.1150836944580078, 1.1949539184570312, 1.2140274047851562, 1.2080669403076172, 1.238107681274414, 1.071929931640625, 1.104116439819336, 1.0230541229248047, 1.0571479797363281, 1.0519027709960938, 1.0688304901123047, 1.0118484497070312, 1.0051727294921875, 1.1889934539794922, 1.0571479797363281, 1.177072525024414, 1.0449886322021484, 1.0669231414794922, 1.004934310913086, 0.9818077087402344, 0.9369850158691406, 1.004934310913086, 1.0461807250976562, 1.0628700256347656, 1.1332035064697266, 1.1780261993408203, 1.0361671447753906, 1.1410713195800781, 1.1188983917236328, 1.026153564453125, 0.9629726409912109, 1.0199546813964844, 1.0409355163574219, 1.0440349578857422, 1.1110305786132812, 1.1761188507080078, 1.508951187133789, 1.2068748474121094, 1.3430118560791016, 1.4159679412841797, 1.3141632080078125]
-
-Median time (milliseconds):
-1.09159946442
-~~~
-
-#### Filtering by a non-indexed column (full table scan)
-
-You'll get generally poor performance when retrieving a single row based on a column that is not in the primary key or any secondary index:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT * FROM users WHERE name = 'Natalie Cunningham'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['id', 'city', 'name', 'address', 'credit_card']
-['02cc9e5b-1e91-4cdb-87c4-726b4ea7219a', 'boston', 'Natalie Cunningham', '97477 Lee Path\nKimberlyport, CA 65960', '4532613656695680']
-
-Times (milliseconds):
-[33.271074295043945, 4.4689178466796875, 4.18400764465332, 4.327058792114258, 5.700111389160156, 4.509925842285156, 4.525899887084961, 4.294157028198242, 4.516124725341797, 5.700111389160156, 5.105018615722656, 4.5070648193359375, 4.798173904418945, 5.930900573730469, 4.445075988769531, 4.1790008544921875, 4.065036773681641, 4.296064376831055, 5.722999572753906, 4.827976226806641, 4.640102386474609, 4.374980926513672, 4.269123077392578, 4.422903060913086, 4.110813140869141, 4.091024398803711, 4.189014434814453, 4.345178604125977, 5.600929260253906, 4.827976226806641, 4.416942596435547, 4.424095153808594, 4.736185073852539, 4.462003707885742, 4.307031631469727, 5.10096549987793, 4.56690788269043, 4.641056060791016, 4.701137542724609, 4.538059234619141, 4.474163055419922, 4.561901092529297, 4.431009292602539, 4.756927490234375, 4.54401969909668, 4.415035247802734, 4.396915435791016, 5.9719085693359375, 4.543066024780273, 5.830049514770508]
-
-Median time (milliseconds):
-4.51302528381
-~~~
-
-To understand why this query performs poorly, use the SQL client built into the `cockroach` binary to [`EXPLAIN`](explain.html) the query plan:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT * FROM users WHERE name = 'Natalie Cunningham';"
-~~~
-
-~~~
-  tree |    field    |         description
--------+-------------+------------------------------
-       | distributed | true
-       | vectorized  | false
-  scan |             |
-       | table       | users@primary
-       | spans       | FULL SCAN
-       | filter      | name = 'Natalie Cunningham'
-(6 rows)
-~~~
-
-The row with `spans | FULL SCAN` shows you that, without a secondary index on the `name` column, CockroachDB scans every row of the `users` table, ordered by the primary key (`city`/`id`), until it finds the row with the correct `name` value.
-
-#### Filtering by a secondary index
-
-To speed up this query, add a secondary index on `name`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="CREATE INDEX on users (name);"
-~~~
-
-The query will now return much faster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT * FROM users WHERE name = 'Natalie Cunningham'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['id', 'city', 'name', 'address', 'credit_card']
-['02cc9e5b-1e91-4cdb-87c4-726b4ea7219a', 'boston', 'Natalie Cunningham', '97477 Lee Path\nKimberlyport, CA 65960', '4532613656695680']
-
-Times (milliseconds):
-[3.545045852661133, 1.4619827270507812, 1.399993896484375, 2.0101070404052734, 1.672983169555664, 1.4941692352294922, 1.4650821685791016, 1.4579296112060547, 1.567840576171875, 1.5709400177001953, 1.4760494232177734, 1.6181468963623047, 1.6210079193115234, 1.6970634460449219, 1.6469955444335938, 1.7261505126953125, 1.7559528350830078, 1.875162124633789, 1.7170906066894531, 1.870870590209961, 1.641988754272461, 1.7061233520507812, 1.628875732421875, 1.6558170318603516, 1.7809867858886719, 1.6698837280273438, 1.8429756164550781, 1.6090869903564453, 1.7080307006835938, 1.74713134765625, 1.6620159149169922, 1.9519329071044922, 1.6849040985107422, 1.7440319061279297, 1.8851757049560547, 1.8699169158935547, 1.7409324645996094, 1.9140243530273438, 1.7828941345214844, 1.7158985137939453, 1.6720294952392578, 1.7750263214111328, 1.7368793487548828, 1.9288063049316406, 1.8749237060546875, 1.7838478088378906, 1.8091201782226562, 1.8210411071777344, 1.7669200897216797, 1.8210411071777344]
-
-Median time (milliseconds):
-1.72162055969
-~~~
-
-To understand why performance improved from 4.51ms (without index) to 1.72ms (with index), use [`EXPLAIN`](explain.html) to see the new query plan:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT * FROM users WHERE name = 'Natalie Cunningham';"
-~~~
-
-~~~
-     tree    |    field    |                      description
--------------+-------------+--------------------------------------------------------
-             | distributed | false
-             | vectorized  | false
-  index-join |             |
-   │         | table       | users@primary
-   │         | key columns | city, id
-   └── scan  |             |
-             | table       | users@users_name_idx
-             | spans       | /"Natalie Cunningham"-/"Natalie Cunningham"/PrefixEnd
-(8 rows)
-~~~
-
-This shows you that CockroachDB starts with the secondary index (`table | users@users_name_idx`). Because it is sorted by `name`, the query can jump directly to the relevant value (`spans | /"Natalie Cunningham"-/"Natalie Cunningham"/PrefixEnd`). However, the query needs to return values not in the secondary index, so CockroachDB grabs the primary key (`city`/`id`) stored with the `name` value (the primary key is always stored with entries in a secondary index), jumps to that value in the primary index, and then returns the full row.
-
-Thinking back to the [earlier discussion of ranges and leaseholders](#important-concepts), because the `users` table is under 512 MiB, the primary index and all secondary indexes are contained in a single range with a single leaseholder. If the table were bigger, however, the primary index and secondary index could reside in separate ranges, each with its own leaseholder. In this case, if the leaseholders were on different nodes, the query would require more network hops, further increasing latency.
-
-#### Filtering by a secondary index storing additional columns
-
-When you have a query that filters by a specific column but retrieves a subset of the table's total columns, you can improve performance by [storing](indexes.html#storing-columns) those additional columns in the secondary index to prevent the query from needing to scan the primary index as well.
-
-For example, let's say you frequently retrieve a user's name and credit card number:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT name, credit_card FROM users WHERE name = 'Natalie Cunningham'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['name', 'credit_card']
-['Natalie Cunningham', '4532613656695680']
-
-Times (milliseconds):
-[2.8769969940185547, 1.7559528350830078, 1.8100738525390625, 1.8839836120605469, 1.5971660614013672, 1.5900135040283203, 1.7750263214111328, 2.2847652435302734, 1.641988754272461, 1.4967918395996094, 1.4641284942626953, 1.6689300537109375, 1.9679069519042969, 1.8970966339111328, 1.8780231475830078, 1.7609596252441406, 1.68609619140625, 1.9791126251220703, 1.661062240600586, 1.9869804382324219, 1.5938282012939453, 1.8041133880615234, 1.5909671783447266, 1.5878677368164062, 1.7380714416503906, 1.638174057006836, 1.6970634460449219, 1.9309520721435547, 1.992940902709961, 1.8689632415771484, 1.7511844635009766, 2.007007598876953, 1.9829273223876953, 1.8939971923828125, 1.7490386962890625, 1.6179084777832031, 1.6510486602783203, 1.6078948974609375, 1.6129016876220703, 1.67083740234375, 1.786947250366211, 1.7840862274169922, 1.956939697265625, 1.8689632415771484, 1.9350051879882812, 1.789093017578125, 1.9249916076660156, 1.8649101257324219, 1.9619464874267578, 1.7361640930175781]
-
-Median time (milliseconds):
-1.77955627441
-~~~
-
-With the current secondary index on `name`, CockroachDB still needs to scan the primary index to get the credit card number:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT name, credit_card FROM users WHERE name = 'Natalie Cunningham';"
-~~~
-
-~~~
-     tree    |    field    |                      description
--------------+-------------+--------------------------------------------------------
-             | distributed | false
-             | vectorized  | false
-  index-join |             |
-   │         | table       | users@primary
-   │         | key columns | city, id
-   └── scan  |             |
-             | table       | users@users_name_idx
-             | spans       | /"Natalie Cunningham"-/"Natalie Cunningham"/PrefixEnd
-(8 rows)
-~~~
-
-Let's drop and recreate the index on `name`, this time storing the `credit_card` value in the index:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="DROP INDEX users_name_idx;"
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="CREATE INDEX ON users (name) STORING (credit_card);"
-~~~
-
-Now that `credit_card` values are stored in the index on `name`, CockroachDB only needs to scan that index:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT name, credit_card FROM users WHERE name = 'Natalie Cunningham';"
-~~~
-
-~~~
-  tree |    field    |                      description
--------+-------------+--------------------------------------------------------
-       | distributed | false
-       | vectorized  | false
-  scan |             |
-       | table       | users@users_name_idx
-       | spans       | /"Natalie Cunningham"-/"Natalie Cunningham"/PrefixEnd
-(5 rows)
-~~~
-
-This results in even faster performance, reducing latency from 1.77ms (index without storing) to 0.99ms (index with storing):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT name, credit_card FROM users WHERE name = 'Natalie Cunningham'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['name', 'credit_card']
-['Natalie Cunningham', '4532613656695680']
-
-Times (milliseconds):
-[1.8029212951660156, 0.9858608245849609, 0.9548664093017578, 0.8459091186523438, 0.9710788726806641, 1.1639595031738281, 0.8571147918701172, 0.8800029754638672, 0.8509159088134766, 0.8771419525146484, 1.1739730834960938, 0.9100437164306641, 1.1181831359863281, 0.9679794311523438, 1.0800361633300781, 1.02996826171875, 1.2090206146240234, 1.0440349578857422, 1.210927963256836, 1.0418891906738281, 1.1951923370361328, 0.9548664093017578, 1.0848045349121094, 0.9748935699462891, 1.15203857421875, 1.0280609130859375, 1.0819435119628906, 0.9641647338867188, 1.0979175567626953, 0.9720325469970703, 1.0638236999511719, 0.9410381317138672, 1.0039806365966797, 1.207113265991211, 0.9911060333251953, 1.0039806365966797, 0.9810924530029297, 0.9360313415527344, 0.9589195251464844, 1.0609626770019531, 0.9949207305908203, 1.0139942169189453, 0.9899139404296875, 0.9818077087402344, 0.9679794311523438, 0.8809566497802734, 0.9558200836181641, 0.8878707885742188, 1.0380744934082031, 0.8897781372070312]
-
-Median time (milliseconds):
-0.990509986877
-~~~
-
-#### Joining data from different tables
-
-Secondary indexes are crucial when [joining](joins.html) data from different tables as well.
-
-For example, let's say you want to count the number of users who started rides on a given day. To do this, you need to use a join to get the relevant rides from the `rides` table and then map the `rider_id` for each of those rides to the corresponding `id` in the `users` table, counting each mapping only once:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT count(DISTINCT users.id) \
-FROM users \
-INNER JOIN rides ON rides.rider_id = users.id \
-WHERE start_time BETWEEN '2018-07-20 00:00:00' AND '2018-07-21 00:00:00'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['count']
-['1998']
-
-Times (milliseconds):
-[1443.5458183288574, 1546.0000038146973, 1563.858985900879, 1530.3218364715576, 1574.7389793395996, 1572.7760791778564, 1566.4539337158203, 1595.655918121338, 1588.2930755615234, 1567.6488876342773, 1564.5530223846436, 1573.4570026397705, 1581.406831741333, 1587.864875793457, 1575.7901668548584, 1565.0341510772705, 1519.8209285736084, 1599.7698307037354, 1612.4188899993896, 1582.5250148773193, 1604.076862335205, 1596.8739986419678, 1569.6821212768555, 1583.7080478668213, 1549.9720573425293, 1563.5790824890137, 1555.6750297546387, 1577.6000022888184, 1582.3569297790527, 1568.8848495483398, 1580.854892730713, 1566.9701099395752, 1578.8500308990479, 1592.677116394043, 1549.3559837341309, 1561.805009841919, 1561.812162399292, 1543.4870719909668, 1523.3290195465088, 1583.9049816131592, 1565.9120082855225, 1575.1979351043701, 1581.1400413513184, 1616.6048049926758, 1602.9179096221924, 1583.8429927825928, 1570.2300071716309, 1573.2421875, 1558.588981628418, 1548.7489700317383]
-
-Median time (milliseconds):
-1573.00913334
-~~~
-
-To understand what's happening, use [`EXPLAIN`](explain.html) to see the query plan:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT count(DISTINCT users.id) \
-FROM users \
-INNER JOIN rides ON rides.rider_id = users.id \
-WHERE start_time BETWEEN '2018-07-20 00:00:00' AND '2018-07-21 00:00:00';"
-~~~
-
-~~~
-         tree         |    field    |                                         description
-----------------------+-------------+----------------------------------------------------------------------------------------------
-                      | distributed | true
-                      | vectorized  | false
-  group               |             |
-   │                  | aggregate 0 | count(DISTINCT id)
-   │                  | scalar      |
-   └── render         |             |
-        └── hash-join |             |
-             │        | type        | inner
-             │        | equality    | (rider_id) = (id)
-             ├── scan |             |
-             │        | table       | rides@primary
-             │        | spans       | FULL SCAN
-             │        | filter      | (start_time >= '2018-07-20 00:00:00+00:00') AND (start_time <= '2018-07-21 00:00:00+00:00')
-             └── scan |             |
-                      | table       | users@users_name_idx
-                      | spans       | FULL SCAN
-(16 rows)
-~~~
-
-Reading from bottom up, you can see that CockroachDB does a full table scan (`spans | FULL SCAN`) first on `rides` to get all rows with a `start_time` in the specified range and then does another full table scan on `users` to find matching rows and calculate the count.
-
-Given that the `rides` table is large, its data is split across several ranges. Each range is replicated and has a leaseholder. At least some of these leaseholders are likely located on different nodes. This means that the full table scan of `rides` involves several network hops to various leaseholders before finally going to the leaseholder for `users` to do a full table scan there.
-
-To track this specifically, let's use the [`SHOW RANGES`](show-ranges.html) statement to find out where the relevant leaseholders reside for `rides` and `users`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="SHOW RANGES FROM TABLE rides;"
-~~~
-
-~~~
-                           start_key                           |                           end_key                            | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+--------------------------------------------------------------+--------------------------------------------------------------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL                                                         | /"boston"/"\x00\x00\a\xef\xfa\x0fJn\xa0\x89\xcet\xaa\x8d\"v" |       33 |             0 |            2 | region=us-central1    | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"boston"/"\x00\x00\a\xef\xfa\x0fJn\xa0\x89\xcet\xaa\x8d\"v" | /"boston"/"\x99\xf4ff\xbb1K\xf9\xab\x92\x83\x003(o\x8a"      |       41 |     21.520739 |            2 | region=us-central1    | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"boston"/"\x99\xf4ff\xbb1K\xf9\xab\x92\x83\x003(o\x8a"      | /"los angeles"/"3\ncK{?Oħ\x9e\xf0k\x96\xba\xad\xf2"          |       37 |     21.850083 |            3 | region=us-west1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"los angeles"/"3\ncK{?Oħ\x9e\xf0k\x96\xba\xad\xf2"          | /"new york"/"\xb3\xb4:#\x1f\x8aDݘ\xc9SC\a5*\xd4"             |       39 |     55.677376 |            3 | region=us-west1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"new york"/"\xb3\xb4:#\x1f\x8aDݘ\xc9SC\a5*\xd4"             | /"seattle"/"x\x15\xaa\x84\xc73Im\xa2\xbf\n\x81$\xcf\xf6\xda" |       55 |     66.072353 |            3 | region=us-west1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"seattle"/"x\x15\xaa\x84\xc73Im\xa2\xbf\n\x81$\xcf\xf6\xda" | NULL                                                         |       38 |     57.403476 |            2 | region=us-central1    | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="SHOW RANGES FROM TABLE users;"
-~~~
-
-~~~
-  start_key | end_key | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+-----------+---------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL      | NULL    |       26 |      0.267026 |            3 | region=us-west1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-(1 row)
-~~~
-
-The results above tell us:
-
-- The `rides` table is split across 6 ranges, with leaseholders on nodes 2 and 3.
-- The `users` table is stored in just a single range with its leaseholder on node 3.
-
-Now, given the `WHERE` condition of the join, the full table scan of `rides`, across all of its 6 ranges, is particularly wasteful. To speed up the query, you can create a secondary index on the `WHERE` condition (`rides.start_time`) storing the join key (`rides.rider_id`):
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="CREATE INDEX ON rides (start_time) STORING (rider_id);"
-~~~
-
-Adding the secondary index reduced the query time from 1573ms to 61.56ms:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT count(DISTINCT users.id)
-FROM users
-INNER JOIN rides ON rides.rider_id = users.id
-WHERE start_time BETWEEN '2019-07-20 00:00:00' AND '2019-07-21 00:00:00'" \
---repeat=50 \
---times
-~~~
-
-~~~
-Result:
-['count']
-['1998']
-
-Times (milliseconds):
-[66.78199768066406, 63.83800506591797, 65.57297706604004, 63.04502487182617, 61.54489517211914, 61.51890754699707, 60.935020446777344, 61.8891716003418, 60.71019172668457, 64.44311141967773, 64.82601165771484, 61.5849494934082, 62.136173248291016, 62.78491020202637, 62.70194053649902, 61.837196350097656, 64.13102149963379, 62.66903877258301, 71.14315032958984, 61.08808517456055, 58.36200714111328, 60.003042221069336, 58.743953704833984, 59.05413627624512, 60.63103675842285, 60.12582778930664, 61.02705001831055, 62.548160552978516, 61.45000457763672, 65.27113914489746, 60.18996238708496, 59.36002731323242, 60.13298034667969, 59.8299503326416, 59.168100357055664, 65.20915031433105, 60.43219566345215, 58.91895294189453, 58.67791175842285, 59.50117111206055, 59.977054595947266, 65.39011001586914, 62.3931884765625, 69.40793991088867, 61.64288520812988, 66.52498245239258, 69.78988647460938, 60.96601486206055, 57.71303176879883, 61.81192398071289]
-
-Median time (milliseconds):
-61.5649223328
-~~~
-
-To understand why performance improved, again use [`EXPLAIN`](explain.html) to see the new query plan:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT count(DISTINCT users.id)
-FROM users
-INNER JOIN rides ON rides.rider_id = users.id
-WHERE start_time BETWEEN '2018-07-20 00:00:00' AND '2018-07-21 00:00:00';"
-~~~
-
-~~~
-         tree         |    field    |                      description
-----------------------+-------------+--------------------------------------------------------
-                      | distributed | true
-                      | vectorized  | false
-  group               |             |
-   │                  | aggregate 0 | count(DISTINCT id)
-   │                  | scalar      |
-   └── render         |             |
-        └── hash-join |             |
-             │        | type        | inner
-             │        | equality    | (rider_id) = (id)
-             ├── scan |             |
-             │        | table       | rides@rides_start_time_idx
-             │        | spans       | /2018-07-20T00:00:00Z-/2018-07-21T00:00:00.000000001Z
-             └── scan |             |
-                      | table       | users@users_name_idx
-                      | spans       | FULL SCAN
-(15 rows)
-~~~
-
-Notice that CockroachDB now starts by using `rides@rides_start_time_idx` secondary index to retrieve the relevant rides without needing to scan the full `rides` table.
-
-Let's check the ranges for the new index:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="SHOW RANGES FROM INDEX rides@rides_start_time_idx;"
-~~~
-
-~~~
-                                          start_key                                         |                                          end_key                                          | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+-------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL                                                                                      | /2018-07-03T01:30:40.141401Z/"new york"/"4v\xc5HJ\xf0Bս\xcb\x1f\xab\xe4\xd9y\x02"         |       43 |             0 |            1 | region=us-east1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /2018-07-03T01:30:40.141401Z/"new york"/"4v\xc5HJ\xf0Bս\xcb\x1f\xab\xe4\xd9y\x02"         | /2018-07-03T01:41:59.820666Z/"boston"/"\x8fX\xce\x02c\xb5O\x95\x81\x9d\xee\xa9D<\xb6\x03" |       45 |      0.431928 |            2 | region=us-central1    | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /2018-07-03T01:41:59.820666Z/"boston"/"\x8fX\xce\x02c\xb5O\x95\x81\x9d\xee\xa9D<\xb6\x03" | /2018-07-16T01:33:31.787252Z/"new york"/"\xb1\xbb\xc0\x98\xe1\xee@\"\xbayd\x0f\x02i\x18l" |       44 |     33.554432 |            1 | region=us-east1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-  /2018-07-16T01:33:31.787252Z/"new york"/"\xb1\xbb\xc0\x98\xe1\xee@\"\xbayd\x0f\x02i\x18l" | NULL                                                                                      |       46 |     46.717599 |            1 | region=us-east1       | {1,2,3}  | {region=us-east1,region=us-central1,region=us-west1}
-(4 rows)
-~~~
-
-This tells us that the index is stored in 4 ranges, with the leaseholders on nodes 1 and 2. Based on the output of `SHOW RANGES FROM TABLE users` that we saw earlier, we already know that the leaseholder for the `users` table is on node 3.
-
-#### Using `IN (list)` with a subquery
-
-Now let's say you want to get the latest ride of each of the 5 most used vehicles. To do this, you might think to use a subquery to get the IDs of the 5 most frequent vehicles from the `rides` table, passing the results into the `IN` list of another query to get the most recent ride of each of the 5 vehicles:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT vehicle_id, max(end_time) \
-FROM rides \
-WHERE vehicle_id IN ( \
-    SELECT vehicle_id \
-    FROM rides \
-    GROUP BY vehicle_id \
-    ORDER BY count(*) DESC \
-    LIMIT 5 \
-) \
-GROUP BY vehicle_id" \
---repeat=20 \
---times
-~~~
-
-~~~
-Result:
-['vehicle_id', 'max']
-['3c950d36-c2b8-48d0-87d3-e0d6f570af62', '2018-08-02 03:06:31.293184']
-['0962cdca-9d85-457c-9616-cc2ae2d32008', '2018-08-02 03:01:25.414512']
-['78fdd6f8-c6a1-42df-a89f-cd65b7bb8be9', '2018-08-02 02:47:43.755989']
-['c6541da5-9858-4e3f-9b49-992e206d2c50', '2018-08-02 02:14:50.543760']
-['35752c4c-b878-4436-8330-8d7246406a55', '2018-08-02 03:08:49.823209']
-
-Times (milliseconds):
-[3012.6540660858154, 2456.5110206604004, 2482.675075531006, 2488.3930683135986, 2474.393129348755, 2494.3790435791016, 2504.063129425049, 2491.326093673706, 2507.4589252471924, 2482.077121734619, 2495.9230422973633, 2497.60103225708, 2478.4271717071533, 2496.574878692627, 2506.395101547241, 2468.4300422668457, 2476.508140563965, 2497.958183288574, 2480.7958602905273, 2484.0168952941895]
-
-Median time (milliseconds):
-2489.85958099
-~~~
-
-However, as you can see, this query is slow because, currently, when the `WHERE` condition of a query comes from the result of a subquery, CockroachDB scans the entire table, even if there is an available index. Use `EXPLAIN` to see this in more detail:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="EXPLAIN SELECT vehicle_id, max(end_time) \
-FROM rides \
-WHERE vehicle_id IN ( \
-    SELECT vehicle_id \
-    FROM rides \
-    GROUP BY vehicle_id \
-    ORDER BY count(*) DESC \
-    LIMIT 5 \
-) \
-GROUP BY vehicle_id;"
-~~~
-
-~~~
-              tree              |       field        |                     description
---------------------------------+--------------------+------------------------------------------------------
-                                | distributed        | true
-                                | vectorized         | false
-  group                         |                    |
-   │                            | aggregate 0        | vehicle_id
-   │                            | aggregate 1        | max(end_time)
-   │                            | group by           | vehicle_id
-   └── hash-join                |                    |
-        │                       | type               | semi
-        │                       | equality           | (vehicle_id) = (vehicle_id)
-        │                       | right cols are key |
-        ├── scan                |                    |
-        │                       | table              | rides@primary
-        │                       | spans              | FULL SCAN
-        └── limit               |                    |
-             │                  | count              | 5
-             └── sort           |                    |
-                  │             | order              | -count_rows
-                  └── group     |                    |
-                       │        | aggregate 0        | vehicle_id
-                       │        | aggregate 1        | count_rows()
-                       │        | group by           | vehicle_id
-                       └── scan |                    |
-                                | table              | rides@rides_auto_index_fk_vehicle_city_ref_vehicles
-                                | spans              | FULL SCAN
-(24 rows)
-~~~
-
-This is a complex query plan, but the important thing to note is the full table scan of `rides@primary` above the `subquery`. This shows you that, after the subquery returns the IDs of the top 5 vehicles, CockroachDB scans the entire primary index to find the rows with `max(end_time)` for each `vehicle_id`, although you might expect CockroachDB to more efficiently use the secondary index on `vehicle_id` (CockroachDB is working to remove this limitation in a future version).
-
-#### Using `IN (list)` with explicit values
-
-Because CockroachDB will not use an available secondary index when using `IN (list)` with a subquery, it's much more performant to have your application first select the top 5 vehicles:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT vehicle_id \
-FROM rides \
-GROUP BY vehicle_id \
-ORDER BY count(*) DESC \
-LIMIT 5" \
---repeat=20 \
---times
-~~~
-
-~~~
-Result:
-['vehicle_id']
-['35752c4c-b878-4436-8330-8d7246406a55']
-['0962cdca-9d85-457c-9616-cc2ae2d32008']
-['c6541da5-9858-4e3f-9b49-992e206d2c50']
-['78fdd6f8-c6a1-42df-a89f-cd65b7bb8be9']
-['3c950d36-c2b8-48d0-87d3-e0d6f570af62']
-
-Times (milliseconds):
-[1049.2329597473145, 1038.0151271820068, 1037.7991199493408, 1036.5591049194336, 1037.7249717712402, 1040.544033050537, 1022.7780342102051, 1056.9651126861572, 1054.3549060821533, 1042.3550605773926, 1042.68217086792, 1031.7370891571045, 1051.880121231079, 1035.8471870422363, 1035.2818965911865, 1035.607099533081, 1040.0230884552002, 1048.8879680633545, 1056.014060974121, 1036.1089706420898]
-
-Median time (milliseconds):
-1039.01910782
-~~~
-
-And then put the results into the `IN` list to get the most recent rides of the vehicles:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT vehicle_id, max(end_time) \
-FROM rides \
-WHERE vehicle_id IN ( \
-  '35752c4c-b878-4436-8330-8d7246406a55', \
-  '0962cdca-9d85-457c-9616-cc2ae2d32008', \
-  'c6541da5-9858-4e3f-9b49-992e206d2c50', \
-  '78fdd6f8-c6a1-42df-a89f-cd65b7bb8be9', \
-  '3c950d36-c2b8-48d0-87d3-e0d6f570af62' \
-) \
-GROUP BY vehicle_id;" \
---repeat=20 \
---times
-~~~
-
-~~~
-Result:
-['vehicle_id', 'max']
-['35752c4c-b878-4436-8330-8d7246406a55', '2018-08-02 03:08:49.823209']
-['0962cdca-9d85-457c-9616-cc2ae2d32008', '2018-08-02 03:01:25.414512']
-['3c950d36-c2b8-48d0-87d3-e0d6f570af62', '2018-08-02 03:06:31.293184']
-['78fdd6f8-c6a1-42df-a89f-cd65b7bb8be9', '2018-08-02 02:47:43.755989']
-['c6541da5-9858-4e3f-9b49-992e206d2c50', '2018-08-02 02:14:50.543760']
-
-Times (milliseconds):
-[1165.5981540679932, 1135.9851360321045, 1201.0550498962402, 1135.0820064544678, 1195.7061290740967, 1132.0109367370605, 1134.9878311157227, 1175.88210105896, 1174.0548610687256, 1152.566909790039, 1164.9351119995117, 1175.5108833312988, 1161.651849746704, 1195.3318119049072, 1162.4629497528076, 1156.1191082000732, 1127.0110607147217, 1165.4651165008545, 1159.6789360046387, 1190.3491020202637]
-
-Median time (milliseconds):
-1163.69903088
-~~~
-
-This approach reduced the query time from 2489.85ms (query with subquery) to 2202.70ms (2 distinct queries).
-
-### Step 7. Test/tune write performance
-
-- [Bulk inserting into an existing table](#bulk-inserting-into-an-existing-table)
-- [Minimizing unused indexes](#minimizing-unused-indexes)
-- [Retrieving the ID of a newly inserted row](#retrieving-the-id-of-a-newly-inserted-row)
-
-#### Bulk inserting into an existing table
-
-Moving on to writes, let's imagine that you have a batch of 100 new users to insert into the `users` table. The most obvious approach is to insert each row using 100 separate [`INSERT`](insert.html) statements:  
-
-{{site.data.alerts.callout_info}}
-For the purpose of demonstration, the command below inserts the same user 100 times, each time with a different unique ID. Note also that you're now adding the `--cumulative` flag to print the total time across all 100 inserts.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="INSERT INTO users VALUES (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347')" \
---repeat=100 \
---times \
---cumulative
-~~~
-
-~~~
-Times (milliseconds):
-[10.773181915283203, 12.186050415039062, 9.711980819702148, 9.730815887451172, 10.200977325439453, 9.32002067565918, 9.002923965454102, 9.426116943359375, 9.312152862548828, 8.329153060913086, 9.626150131225586, 8.965015411376953, 9.562969207763672, 9.305000305175781, 9.34910774230957, 7.394075393676758, 9.3231201171875, 9.066104888916016, 8.419036865234375, 9.158134460449219, 9.278059005737305, 8.022069931030273, 8.542060852050781, 9.237051010131836, 8.165121078491211, 8.094072341918945, 8.025884628295898, 8.04591178894043, 9.728193283081055, 8.485078811645508, 7.967948913574219, 9.319067001342773, 8.099079132080078, 9.041070938110352, 10.046005249023438, 10.684013366699219, 9.672880172729492, 8.129119873046875, 8.10098648071289, 7.884979248046875, 9.484052658081055, 8.594036102294922, 9.479045867919922, 9.239912033081055, 9.16600227355957, 9.155988693237305, 9.392976760864258, 11.08694076538086, 9.402990341186523, 8.034944534301758, 8.053064346313477, 8.03995132446289, 8.891820907592773, 8.054971694946289, 8.903980255126953, 9.057998657226562, 9.713888168334961, 7.99107551574707, 8.114814758300781, 8.677959442138672, 11.178970336914062, 9.272098541259766, 9.281158447265625, 8.177995681762695, 9.47880744934082, 10.025978088378906, 8.352041244506836, 8.320808410644531, 10.892868041992188, 8.227825164794922, 8.220911026000977, 9.625911712646484, 10.272026062011719, 8.116960525512695, 10.786771774291992, 9.073972702026367, 9.686946868896484, 9.903192520141602, 9.887933731079102, 9.399890899658203, 9.413003921508789, 8.594036102294922, 8.433103561401367, 9.271860122680664, 8.529901504516602, 9.474992752075195, 9.005069732666016, 9.341001510620117, 9.388923645019531, 9.775876998901367, 8.558988571166992, 9.613990783691406, 8.897066116333008, 8.642911911010742, 9.527206420898438, 8.274078369140625, 9.073972702026367, 9.637832641601562, 8.516788482666016, 9.564876556396484]
-
-Median time (milliseconds):
-9.20152664185
-
-Cumulative time (milliseconds):
-910.985708237
-~~~
-
-The 100 inserts took 910.98ms to complete, which isn't bad. However, it's significantly faster to use a single `INSERT` statement with 100 comma-separated `VALUES` clauses:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="INSERT INTO users VALUES \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), \
-(gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347'), (gen_random_uuid(), 'new york', 'Max Roach', '411 Drum Street', '173635282937347')" \
---repeat=1 \
---cumulative
-~~~
-
-~~~
-Median time (milliseconds):
-15.4001712799
-
-Cumulative time (milliseconds):
-15.4001712799
-~~~
-
-As you can see, this multi-row `INSERT` technique reduced the total time for 100 inserts from 910.98ms to 15.40ms. It's useful to note that this technique is equally effective for [`UPSERT`](upsert.html) and [`DELETE`](delete.html) statements as well.
-
-{{site.data.alerts.callout_info}}
-You can also use the [`IMPORT INTO`](import-into.html) statement to bulk-insert CSV data into an existing table.
-{{site.data.alerts.end}}
-
-#### Minimizing unused indexes
-
-Earlier, we saw how important secondary indexes are for read performance. For writes, however, it's important to recognized the overhead that they create.
-
-Let's consider the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="SHOW INDEXES FROM users;"
-~~~
-
-~~~
-  table_name |   index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit
-+------------+----------------+------------+--------------+-------------+-----------+---------+----------+
-  users      | primary        |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary        |   false    |            2 | id          | ASC       |  false  |  false
-  users      | users_name_idx |    true    |            1 | name        | ASC       |  false  |  false
-  users      | users_name_idx |    true    |            2 | credit_card | N/A       |  true   |  false
-  users      | users_name_idx |    true    |            3 | city        | ASC       |  false  |   true
-  users      | users_name_idx |    true    |            4 | id          | ASC       |  false  |   true
-(6 rows)
-~~~
-
-This table has the primary index (the full table) and a secondary index on `name` that is also storing `credit_card`. This means that whenever a row is inserted, or whenever `name`, `credit_card`, `city`, or `id` are modified in existing rows, both indexes are updated.
-
-To make this more concrete, let's count how many rows have a name that starts with `C` and then update those rows to all have the same name:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT count(*) \
-FROM users \
-WHERE name LIKE 'C%'" \
---repeat=1
-~~~
-
-~~~
-['count']
-['179']
-
-Median time (milliseconds):
-2.52604484558
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="UPDATE users \
-SET name = 'Carl Kimball' \
-WHERE name LIKE 'C%'" \
---repeat=1
-~~~
-
-~~~
-Median time (milliseconds):
-52.2060394287
-~~~
-
-Because `name` is in both the `primary` and `users_name_idx` indexes, for each of the 168 rows, 2 keys were updated.
-
-Now, assuming that the `users_name_idx` index is no longer needed, lets drop the index and execute an equivalent query:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
-{{page.certs}} \
---host=<address of any node> \
---database=movr \
---execute="DROP INDEX users_name_idx;"
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="UPDATE users \
-SET name = 'Peedie Hirata' \
-WHERE name = 'Carl Kimball'" \
---repeat=1
-~~~
-
-~~~
-Median time (milliseconds):
-22.7289199829
-~~~
-
-Before, when both the primary and secondary indexes needed to be updated, the updates took 52.20ms. Now, after dropping the secondary index, an equivalent update took only 22.72ms.
-
-#### Retrieving the ID of a newly inserted row
-
-Now let's focus on the common case of inserting a row into a table and then retrieving the ID of the new row to do some follow-up work. One approach is to execute two statements, an `INSERT` to insert the row and then a `SELECT` to get the new ID:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="INSERT INTO users VALUES (gen_random_uuid(), 'new york', 'Toni Brooks', '800 Camden Lane, Brooklyn, NY 11218', '98244843845134960')" \
---repeat=1
-~~~
-
-~~~
-Median time (milliseconds):
-10.4398727417
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="SELECT id FROM users WHERE name = 'Toni Brooks'" \
---repeat=1
-~~~
-
-~~~
-Result:
-['id']
-['ae563e17-ad59-4307-a99e-191e682b4278']
-
-Median time (milliseconds):
-5.53798675537
-~~~
-
-Combined, these statements are relatively fast, at 15.96ms, but an even more performant approach is to append `RETURNING id` to the end of the `INSERT`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ {{page.app}} \
---host=<address of any node> \
---statement="INSERT INTO users VALUES (gen_random_uuid(), 'new york', 'Brian Brooks', '800 Camden Lane, Brooklyn, NY 11218', '98244843845134960') \
-RETURNING id" \
---repeat=1
-~~~
-
-~~~
-Result:
-['id']
-['3d16500e-cb2e-462e-9c83-db0965d6deaf']
-
-Median time (milliseconds):
-9.48596000671
-~~~
-
-At just 9.48ms, this approach is faster due to the write and read executing in one instead of two client-server roundtrips. Note also that, as discussed earlier, if the leaseholder for the table happens to be on a different node than the query is running against, that introduces additional network hops and latency.
-
-<!-- - upsert instead of insert/update
-- update using case expressions (instead of 2 separate updates)
-- returning nothing
-- insert with returning (auto gen ID) instead of select to get auto gen ID-->
-
-## Multi-region deployment
-
-<!-- roachprod instructions for multi-region deployment
-You created all instanced up front, so no need to add more now.
-1. Start the nodes in us-west1-a: roachprod start -b "/usr/local/bin/cockroach" <yourname>-tuning:5-7
-2. Start the nodes in us-west2-a: roachprod start -b "/usr/local/bin/cockroach" <yourname>-tuning:9-11
-3. Install the Python client on instance 8:
-   - SSH to instance 8: roachprod run <yourname>-tuning:8
-   - Run commands in Step 5 above.
-4. Install the Python client on instance 12:
-   - SSH onto instance 12: roachprod run <yourname>-tuning:12
-   - Run commands in Step 5 above.
-5. Check rebalancing:
-   - SSH to instance 4, 8, or 12.
-   - Run `SHOW RANGES` from Step 11 below.
-6. Test performance:
-   - Run the SQL commands in Step 12 below. You'll need to SSH to instance 8 or 12 as suggested.
-7. Partition the data:
-   - SSH to any node and run the SQL in Step 13 below.
-8. Check rebalancing after partitioning:
-   - SSH to instance 4, 8, or 12.
-   - Run `SHOW RANGES` from Step 14 below.
-8. Test performance after partitioning:
-   - Run the SQL commands in Step 15 below. You'll need to SSH to instance 8 or 12 as suggested.
--->
-
-Given that MovR is active on both US coasts, you'll now scale the cluster into two new regions, `us-west1-a` and `us-west2-a`, each with 3 nodes and an extra instance for simulating regional client traffic.
-
-### Step 8. Create more instances
-
-1. [Create 6 more instances](https://cloud.google.com/compute/docs/instances/create-start-instance), 3 in the `us-west1-a` zone (Oregon), and 3 in the `us-west2-a` zone (Los Angeles). While creating each instance:
-    - Use the `n2-standard-4` machine type (4 vCPUs, 16 GB memory).
-    - Use the Ubuntu 16.04 OS image.
-    - [Create and mount a local SSD](https://cloud.google.com/compute/docs/disks/local-ssd#create_local_ssd).
-    - To apply the DB Console firewall rule you created earlier, click **Management, disk, networking, SSH keys**, select the **Networking** tab, and then enter `cockroachdb` in the **Network tags** field.
-
-2. Note the internal and external IP addresses of each `n2-standard-4` instance. You'll need these addresses when generating security certificates and when starting the CockroachDB nodes.
-
-3. Create an additional instance in the `us-west1-a` and `us-west2-a` zones. These can be smaller, such as `n2-standard-2`.
-
-### Step 9. Scale the cluster
-
-#### Generate security certificates
-
-1. On your local machine, where you generated certificates for your first nodes, create the certificate and key for one of the new nodes, issued to all common names you might use to refer to the node:
-
-    {% include copy-clipboard.html %}
-  	~~~ shell
-  	$ cockroach cert create-node \
-  	<node internal IP address> \
-  	<node external IP address> \
-  	<node hostname>  \
-  	<other common names for node> \
-  	localhost \
-  	127.0.0.1 \
-  	{{page.certs}} \
-  	--ca-key=my-safe-directory/ca.key
-  	~~~
-
-2. Upload certificates to the instance:
-
-    {% include copy-clipboard.html %}
-  	~~~ shell
-  	# Create the certs directory:
-  	$ ssh <username>@<node address> "mkdir certs"
-  	~~~
-
-  	{% include copy-clipboard.html %}
-  	~~~ shell
-  	# Upload the CA certificate and node certificate and key:
-  	$ scp certs/ca.crt \
-  	certs/node.crt \
-  	certs/node.key \
-  	<username>@<node address>:~/certs
-  	~~~
-
-3. Delete the local copy of the node certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm certs/node.crt certs/node.key
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    This is necessary because the certificates and keys for additional nodes will also be named `node.crt` and `node.key`. As an alternative to deleting these files, you can run the next `cockroach cert create-node` commands with the `--overwrite` flag.
-    {{site.data.alerts.end}}
-
-4. Repeat steps 1 - 3 for each new node.
-
-5. Upload the client certificates you created earlier to the additional instances in the `us-west1-a` and `us-west2-a` zones for your client application workload:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Create the certs directory:
-    $ ssh <username>@<instance address> "mkdir certs"
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    # Upload the CA certificate and client certificate and key:
-    $ scp certs/ca.crt \
-    certs/client.root.crt \
-    certs/client.root.key \
-    <username>@<instance address>:~/certs
-    ~~~
-
-#### Start the new nodes
-
-{% include {{ page.version.version }}/performance/scale-cluster.md %}
-
-### Step 10. Install the Python client
-
-In each of the new zones, SSH to the instance not running a CockroachDB node, and install the Python client as described in [step 5](#step-5-install-the-python-client) above.
-
-### Step 11. Check rebalancing
-
-{% include {{ page.version.version }}/performance/check-rebalancing.md %}
-
-### Step 12. Test performance
-
-{% include {{ page.version.version }}/performance/test-performance.md %}
-
-### Step 13. Partition data by city
-
-{% include {{ page.version.version }}/performance/partition-by-city.md %}
-
-### Step 14. Check rebalancing after partitioning
-
-{% include {{ page.version.version }}/performance/check-rebalancing-after-partitioning.md %}
-
-### Step 15. Test performance after partitioning
-
-{% include {{ page.version.version }}/performance/test-performance-after-partitioning.md %}
-
-## See also
-
-- [SQL Performance Best Practices](performance-best-practices-overview.html)
-- [Identify slow queries](query-behavior-troubleshooting.html#identify-slow-queries)
-- [Optimize Query Performance](make-queries-fast.html)
-- [Performance Benchmarking](performance-benchmarking-with-tpcc-small.html)
-- [Network Latency Page](ui-network-latency-page.html)
-- [Production Checklist](recommended-production-settings.html)
diff --git a/src/current/v20.2/performance.md b/src/current/v20.2/performance.md
deleted file mode 100644
index 8ebb104b1b0..00000000000
--- a/src/current/v20.2/performance.md
+++ /dev/null
@@ -1,100 +0,0 @@
----
-title: CockroachDB Performance
-summary: An overview of the performance profiles you can expect from CockroachDB.
-toc: true
-toc_not_nested: true
----
-
-CockroachDB delivers predictable throughput and latency at all scales on commodity hardware. This page provides an overview of the performance profiles you can expect, based on Cockroach Labs's extensive testing using the TPC-C industry-standard benchmark.
-
-For instructions to reproduce the TPC-C results listed here, see [Performance Benchmarking with TPC-C](performance-benchmarking-with-tpcc-large.html). If you fail to achieve similar results, there is likely a problem in either the hardware, workload, or test design.
-
-{{site.data.alerts.callout_success}}
-This document is about CockroachDB’s performance on benchmarks. For guidance on tuning real workloads, see [SQL Best Practices](performance-best-practices-overview.html), and for guidance on data location techniques to minimize network latency, see [Topology Patterns](topology-patterns.html).
-{{site.data.alerts.end}}
-
-## Scale
-
-TPC-C provides the most realistic and objective measure for OLTP performance at various scale factors, and CockroachDB can process **1.68M tpmC with 140,000 warehouses, resulting in an efficiency score of 95%.** As shown in the chart below, this is a 40% improvement over the results from CockroachDB 19.2.
-
-For a refresher on what exactly TPC-C is and how it is measured, see [Benchmark details](#benchmark-details) below.
-
-CockroachDB achieves this performance in [`SERIALIZABLE` isolation](demo-serializable.html), the strongest isolation level in the SQL standard.
-
-<img src="{{ 'images/v20.2/tpcc140k.png' | relative_url }}" alt="TPC-C 140,000" style="border:1px solid #eee;max-width:100%" />
-
-| Metric                                          | CockroachDB 19.2 | CockroachDB 20.2 |
-|-------------------------------------------------+------------------+------------------|
-| Max warehouses with max efficiency (warehouses) |          100,000 |          140,000 |
-| Max throughput (tpmC)                           |        1,245,462 |        1,684,437 |
-| Efficiency (%)                                  |            98.81 |            95.45 |
-| Max number of rows (billion)                    |             49.8 |             69.7 |
-| Max unreplicated data (TB)                      |                8 |             11.2 |
-| p95 latency for New Order transactions (ms)     |           486.50 |           2684.4 |
-| Number of nodes                                 |               81 |               81 |
-
-### Linear scaling
-
-CockroachDB has **no theoretical scaling limit** and, in practice, can achieve near-linear performance at 256 nodes. Because the TPC-C results above reflect leaps in scale, to test linear scaling, Cockroach Labs ran a simple benchmark named KV 95 (95% point reads, 5% point writes, all uniformly distributed) on AWS `c5d.4xlarge` machines:
-
-<img src="{{ 'images/v20.2/linearscale.png' | relative_url }}" alt="CRDB Linear Scale" style="max-width:100%" />
-
-This chart shows that adding nodes increases throughput linearly while holding p50 and p99 latency constant. The concurrency for each scale was chosen to optimize throughput while maintaining an acceptable latency and can be observed in the table below.
-
-| Number of Nodes | Workers | Concurrency |
-|-----------------+---------+-------------|
-|              16 |       2 |         512 |
-|              32 |       4 |         512 |
-|              64 |       4 |        1024 |
-|             128 |       8 |        1024 |
-|             256 |       8 |        2048 |
-
-## Throughput
-
-Cockroach Labs believes TPC-C provides the most realistic and objective measure for OLTP throughput. In the real world, applications generate transactional workloads that consist of a combination of reads and writes, possibly with concurrency and likely without all data being loaded into memory. Approach benchmark results quoted in QPS with caution, because anything as simple as a “query” is unlikely to be representative of the workload you need to run in practice.
-
-## Latency
-
-CockroachDB returns single-row **reads in 1 ms** and processes single-row **writes in 2 ms** within a single availability zone. As you expand out to multiple availability zones or multiple regions, latency can increase due to distance and the limitation of the speed of light.
-
-For benchmarking latency, again, Cockroach Labs believes TPC-C provides the most realistic and objective measure, since it encompasses the latency distribution, including tail performance.
-
-CockroachDB provides a number of important tuning practices for both single-region and multi-region deployments, including [secondary indexes](indexes.html) and various [data topologies](topology-patterns.html) to achieve low latency.
-
-## Benchmark details
-
-### TPC-C
-
-Cockroach Labs measures performance through many diverse tests, including the [industry-standard OLTP benchmark TPC-C](http://www.tpc.org/tpcc/), which simulates an e-commerce or retail company. Created in 1992, TPC-C has withstood the test of time and remains the most mature industry benchmark for OLTP workloads, and **the only objective comparison for evaluating OLTP performance**. In its own words, TPC-C:
-
->“…involves a mix of five concurrent transactions of different types and complexity either executed on-line or queued for deferred execution. The database is comprised of nine types of tables with a wide range of record and population sizes. While the benchmark portrays the activity of a wholesale supplier, TPC-C is not limited to the activity of any particular business segment, but, rather represents any industry that must manage, sell, or distribute a product or service.”
-
-As a result, TPC-C includes create, read, update, and delete (e.g., CRUD) queries, basic joins, and other SQL statements used to administer mission-critical transactional workloads. It includes detailed specifications for concurrency and workload contention.
-
-#### How TPC-C works
-
-TPC-C measures the throughput and latency for processing sales through a customer warehouse using a “business throughput” metric called **tpmC** that measures the number of order transactions performed per minute throughout the system. This metric is considerably more realistic than TPS (transactions per second) or QPS (queries per second) alone because it summarizes multiple transactions per order and accounts for failed transactions. TPC-C also has several latency requirements that apply to median, p90, and max latencies.
-
-TPC-C specifies restrictions on the maximum throughput achievable per warehouse. This is done to ensure that as a system becomes progressively more capable of throughput, it must also deal with progressively more data. This is how things work in the real world, and it makes little sense to say that your database can process a bazillion transactions per second if it’s processing the same data over and over again.
-
-Because TPC-C is constrained to a maximum amount of throughput per warehouse, we often discuss TPC-C performance as the **maximum number of warehouses for which a database can maintain the maximum throughput per minute.** For a full description of the benchmark, please consult the [official documentation](http://www.tpc.org/tpc_documents_current_versions/pdf/tpc-c_v5.11.0.pdf).
-
-## Performance limitations
-
-CockroachDB has no theoretical limitations to scaling, throughput, latency, or concurrency other than the speed of light. Practically, we will be improving bottlenecks and addressing challenges over the next several releases.
-
-## See also
-
-- Hardware
-
-    CockroachDB works well on commodity hardware in public cloud, private cloud, on-prem, and hybrid environments. For hardware recommendations, see our [Production Checklist](recommended-production-settings.html#hardware).
-
-    Also note that CockroachDB creates a yearly cloud report focused on evaluating hardware performance. For more information, see the [2020 Cloud Report](https://www.cockroachlabs.com/blog/2020-cloud-report/).
-
-- Performance Tuning
-
-    For guidance on tuning a real workload's performance, see [SQL Best Practices](performance-best-practices-overview.html), and for guidance on data location techniques to minimize network latency, see [Topology Patterns](topology-patterns.html).
-
-- TPC-C Replication Instructions
-
-    For instructions showing how to replicate the TPC-C results described above, see [Performance Benchmarking with TPC-C](performance-benchmarking-with-tpcc-large.html)
diff --git a/src/current/v20.2/pg-catalog.md b/src/current/v20.2/pg-catalog.md
deleted file mode 100644
index ca5c8035b6b..00000000000
--- a/src/current/v20.2/pg-catalog.md
+++ /dev/null
@@ -1,167 +0,0 @@
----
-title: pg_catalog
-summary: The pg_catalog schema contains read-only views that you can use for introspection into your database.
-toc: true
----
-
-For PostgreSQL compatibility, CockroachDB includes a [system catalog schema](system-catalogs.html) called `pg_catalog`. The tables in the `pg_catalog` schema roughly correspond to the [system catalogs in PostgreSQL](https://www.postgresql.org/docs/13/catalogs.html). `pg_catalog` tables are read-only.
-
-## Data exposed by `pg_catalog`
-
-The tables in CockroachDB's `pg_catalog` correspond to a subset of the virtual tables and views that make up the PostgreSQL system catalogs. Not all PostgreSQL system catalogs have a corresponding table in `pg_catalog`. See the following table for a detailed comparison between PostgreSQL 13 system catalogs and `pg_catalog` tables.
-
-PostgreSQL 13 system catalog | `pg_catalog` table  
------------------------------|--------------
-`pg_aggregate` | `pg_aggregate`
-`pg_am` | `pg_am`
-`pg_amop` | None
-`pg_amproc` | None
-`pg_attrdef` | `pg_attrdef`
-`pg_attribute` | `pg_attribute`
-`pg_auth_members` | `pg_auth_members`
-`pg_authid` | `pg_authid`
-`pg_available_extension_versions` | None
-`pg_available_extensions` | `pg_available_extensions`
-`pg_cast` | `pg_cast`
-`pg_class` | `pg_class`
-`pg_collation` | `pg_collation`
-`pg_config` | None
-`pg_constraint` | `pg_constraint`
-`pg_conversion` | `pg_conversion`
-`pg_cursors` | None
-`pg_database` | `pg_database`
-`pg_db_role_setting` | None
-`pg_default_acl` | `pg_default_acl`
-`pg_depend` | `pg_depend`
-`pg_description` | `pg_description`
-`pg_enum` | `pg_enum`
-`pg_event_trigger` | `pg_event_trigger`
-`pg_extension` | `pg_extension`
-`pg_file_settings` | None
-`pg_foreign_data_wrapper` | `pg_foreign_data_wrapper`
-`pg_foreign_server` | `pg_foreign_server`
-`pg_foreign_table` | `pg_foreign_table`
-`pg_group` | None
-`pg_hba_file_rules` | None
-`pg_index` | `pg_index`
-`pg_indexes` | `pg_indexes`
-`pg_inherits` | `pg_inherits`
-`pg_init_privs` | None
-`pg_language` | `pg_language` (empty)
-`pg_largeobject` | None
-`pg_largeobject_metadata` | None
-`pg_locks` | `pg_locks`
-`pg_matviews` | `pg_matviews`
-`pg_namespace` | `pg_namespace`
-`pg_opclass` | None
-`pg_operator` | `pg_operator`
-`pg_opfamily` | None
-`pg_partitioned_table` | None
-`pg_policies` | None
-`pg_policy` | None
-`pg_prepared_statements` | `pg_prepared_statements` (empty)
-`pg_prepared_xacts` | `pg_prepared_xacts` (empty)
-`pg_proc` | `pg_proc`
-`pg_publication` | None
-`pg_publication_rel` | None
-`pg_publication_tables` | None
-`pg_range` | `pg_range`
-`pg_replication_origin` | None
-`pg_replication_origin_status` | None
-`pg_replication_slots` | None
-`pg_rewrite` | `pg_rewrite`
-`pg_roles` | `pg_roles`
-`pg_rules` | None
-`pg_seclabel` | `pg_seclabel`
-`pg_seclabels` | `pg_seclabels`
-`pg_sequence` | `pg_sequence`
-`pg_sequences` | None
-`pg_settings` | `pg_settings`
-`pg_shadow` | None
-`pg_shdepend` | `pg_shdepend` (empty)
-`pg_shdescription` | `pg_shdescription`
-`pg_shmem_allocations` | None
-`pg_shseclabel` | `pg_shseclabel`
-`pg_stat_activity` | `pg_stat_activity`
-`pg_statistic` | None
-`pg_statistic_ext` | None
-`pg_statistic_ext_data` | None
-`pg_stats` | None
-`pg_stats_ext` | None
-`pg_subscription` | None
-`pg_subscription_rel` | None
-`pg_tables` | `pg_tables`
-`pg_tablespace` | `pg_tablespace`
-`pg_timezone_abbrevs` | None
-`pg_timezone_names` | None
-`pg_transform` | None
-`pg_trigger` | `pg_trigger`
-`pg_ts_config` | None
-`pg_ts_config_map` | None
-`pg_ts_dict` | None
-`pg_ts_parser` | None
-`pg_ts_template` | None
-`pg_type` | `pg_type`
-`pg_user` | `pg_user`
-`pg_user_mapping` | `pg_user_mapping`
-`pg_user_mappings` | None
-`pg_views` | `pg_views`
-
-To list the tables in `pg_catalog` for the [current database](sql-name-resolution.html#current-database), use the following [`SHOW TABLES`](show-tables.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM pg_catalog;
-~~~
-
-~~~
-  schema_name |       table_name        | type  | owner | estimated_row_count
---------------+-------------------------+-------+-------+----------------------
-  pg_catalog  | pg_aggregate            | table | NULL  |                NULL
-  pg_catalog  | pg_am                   | table | NULL  |                NULL
-  pg_catalog  | pg_attrdef              | table | NULL  |                NULL
-  ...
-~~~
-
-## Query `pg_catalog` tables
-
-You can run [`SELECT` queries](selection-queries.html) on the tables in `pg_catalog`.
-
-{{site.data.alerts.callout_success}}
-To ensure that you can view all of the tables in `pg_catalog`, query the tables as a user with [`admin` privileges](authorization.html#admin-role).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Unless specified otherwise, queries to `pg_catalog` assume the [current database](sql-name-resolution.html#current-database).
-{{site.data.alerts.end}}
-
-For example, to return the `pg_catalog` table with additional information about indexes in [`movr` database](movr.html), you can query the `pg_catalog.pg_indexes` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM movr.pg_catalog.pg_indexes;
-~~~
-
-~~~
-   crdb_oid  | schemaname |         tablename          |                   indexname                   | tablespace |                                                            indexdef
--------------+------------+----------------------------+-----------------------------------------------+------------+---------------------------------------------------------------------------------------------------------------------------------
-  2055313241 | public     | users                      | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.users USING btree (city ASC, id ASC)
-  1795576970 | public     | vehicles                   | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.vehicles USING btree (city ASC, id ASC)
-  1795576969 | public     | vehicles                   | vehicles_auto_index_fk_city_ref_users         | NULL       | CREATE INDEX vehicles_auto_index_fk_city_ref_users ON movr.public.vehicles USING btree (city ASC, owner_id ASC)
-   450499963 | public     | rides                      | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.rides USING btree (city ASC, id ASC)
-   450499960 | public     | rides                      | rides_auto_index_fk_city_ref_users            | NULL       | CREATE INDEX rides_auto_index_fk_city_ref_users ON movr.public.rides USING btree (city ASC, rider_id ASC)
-   450499961 | public     | rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles | NULL       | CREATE INDEX rides_auto_index_fk_vehicle_city_ref_vehicles ON movr.public.rides USING btree (vehicle_city ASC, vehicle_id ASC)
-  2315049508 | public     | vehicle_location_histories | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.vehicle_location_histories USING btree (city ASC, ride_id ASC, "timestamp" ASC)
-   969972501 | public     | promo_codes                | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.promo_codes USING btree (code ASC)
-   710236230 | public     | user_promo_codes           | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.user_promo_codes USING btree (city ASC, user_id ASC, code ASC)
-(9 rows)
-~~~
-
-## See also
-
-- [`SHOW`](show-vars.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [`SHOW TABLES`](show-tables.html)
-- [SQL Name Resolution](sql-name-resolution.html)
-- [System Catalogs](system-catalogs.html)
diff --git a/src/current/v20.2/pg-extension.md b/src/current/v20.2/pg-extension.md
deleted file mode 100644
index 1c74792ea41..00000000000
--- a/src/current/v20.2/pg-extension.md
+++ /dev/null
@@ -1,78 +0,0 @@
----
-title: pg_extension
-summary: The pg_extension schema contains information about CockroachDB extensions.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: The `pg_extension` [system catalogs](system-catalogs.html) provides information about CockroachDB extensions.
-
-## Data exposed by `pg_extension`
-
-In CockroachDB {{ page.version.version }}, `pg_extension` contains the following tables, all of which provide information about CockroachDB's [spatial extension](spatial-features.html):
-
-- `geography_columns`
-- `geometry_columns`
-- `spatial_ref_sys`
-
-{{site.data.alerts.callout_info}}
-`pg_extension` tables are read-only.
-{{site.data.alerts.end}}
-
-To see the list of tables in `pg_extension` for the [current database](sql-name-resolution.html#current-database), use the following [`SHOW TABLES`](show-tables.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM pg_extension;
-~~~
-
-~~~
-  schema_name  |    table_name     | type  | owner | estimated_row_count
----------------+-------------------+-------+-------+----------------------
-  pg_extension | geography_columns | table | NULL  |                NULL
-  pg_extension | geometry_columns  | table | NULL  |                NULL
-  pg_extension | spatial_ref_sys   | table | NULL  |                NULL
-(3 rows)
-~~~
-
-## Querying `pg_extension` tables
-
-You can run [`SELECT` queries](selection-queries.html) on the tables in `pg_extension`.
-
-{{site.data.alerts.callout_success}}
-To ensure that you can view all of the tables in `pg_extension`, query the tables as a user with [`admin` privileges](authorization.html#admin-role).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Unless specified otherwise, queries to `pg_extension` assume the [current database](sql-name-resolution.html#current-database).
-{{site.data.alerts.end}}
-
-For example, to return the `pg_extension` table with additional information about indexes in the `movr` database, you can query the `pg_extension.pg_indexes` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM movr.pg_extension.pg_indexes;
-~~~
-
-~~~
-   crdb_oid  | schemaname |         tablename          |                   indexname                   | tablespace |                                                            indexdef
--------------+------------+----------------------------+-----------------------------------------------+------------+---------------------------------------------------------------------------------------------------------------------------------
-  2055313241 | public     | users                      | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.users USING btree (city ASC, id ASC)
-  1795576970 | public     | vehicles                   | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.vehicles USING btree (city ASC, id ASC)
-  1795576969 | public     | vehicles                   | vehicles_auto_index_fk_city_ref_users         | NULL       | CREATE INDEX vehicles_auto_index_fk_city_ref_users ON movr.public.vehicles USING btree (city ASC, owner_id ASC)
-   450499963 | public     | rides                      | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.rides USING btree (city ASC, id ASC)
-   450499960 | public     | rides                      | rides_auto_index_fk_city_ref_users            | NULL       | CREATE INDEX rides_auto_index_fk_city_ref_users ON movr.public.rides USING btree (city ASC, rider_id ASC)
-   450499961 | public     | rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles | NULL       | CREATE INDEX rides_auto_index_fk_vehicle_city_ref_vehicles ON movr.public.rides USING btree (vehicle_city ASC, vehicle_id ASC)
-  2315049508 | public     | vehicle_location_histories | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.vehicle_location_histories USING btree (city ASC, ride_id ASC, "timestamp" ASC)
-   969972501 | public     | promo_codes                | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.promo_codes USING btree (code ASC)
-   710236230 | public     | user_promo_codes           | primary                                       | NULL       | CREATE UNIQUE INDEX "primary" ON movr.public.user_promo_codes USING btree (city ASC, user_id ASC, code ASC)
-(9 rows)
-~~~
-
-## See also
-
-- [`SHOW`](show-vars.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [`SHOW TABLES`](show-tables.html)
-- [SQL Name Resolution](sql-name-resolution.html)
-- [System Catalogs](system-catalogs.html)
diff --git a/src/current/v20.2/point.md b/src/current/v20.2/point.md
deleted file mode 100644
index 8996c3bef4c..00000000000
--- a/src/current/v20.2/point.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: POINT
-summary: A POINT is a geometry object; a sizeless location identified by its X and Y coordinates.
-toc: true
----
-
-A `POINT` is a sizeless location identified by its X and Y coordinates. These coordinates are then translated according to the current [spatial reference system](spatial-glossary.html#spatial-reference-system) (denoted by an [SRID](spatial-glossary.html#srid)) to determine what the Point "is", or what it "means" relative to the [other spatial objects](spatial-features.html#spatial-objects) (if any) in the data set. 
-
-## Examples
-
-### SQL
-
-A Point can be created in SQL by the `st_point` function.
-
-The statement below creates a Point (using the common [SRID 4326](spatial-glossary.html#srid)).
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_SetSRID(ST_Makepoint(0,0), 4326);
-~~~
-
-~~~
-                      st_setsrid
-------------------------------------------------------
-  0101000020E610000000000000000000000000000000000000
-(1 row)
-~~~
-
-### Well known text
-
-A Point can be created from SQL by calling the `st_geomfromtext` function on a Point definition expressed in the [Well Known Text (WKT)](spatial-glossary.html#wkt) format as shown below.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeomFromText('POINT(0 0)');
-~~~
-
-~~~
-               st_geomfromtext
-----------------------------------------------
-  010100000000000000000000000000000000000000
-(1 row)
-~~~
-
-## See also
-
-- [Spatial objects](spatial-features.html#spatial-objects)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/polygon.md b/src/current/v20.2/polygon.md
deleted file mode 100644
index fbdac49bbbe..00000000000
--- a/src/current/v20.2/polygon.md
+++ /dev/null
@@ -1,69 +0,0 @@
----
-title: POLYGON
-summary: A POLYGON is a shape with a closed exterior that is made up of lines.
-toc: true
----
-
-A `POLYGON` is a shape with a closed exterior that is made up of lines. Polygons can also contain holes.  Polygons are often used to represent areas such as countries, states, or municipalities.
-
-The coordinates of each Point and line that make up the Polygon are translated according to the current [spatial reference system](spatial-glossary.html#spatial-reference-system) (denoted by an [SRID](spatial-glossary.html#srid)) to determine what the point "is", or what it "means" relative to the [other spatial objects](spatial-features.html#spatial-objects) (if any) in the data set.
-
-## Examples
-
-### Well known text
-
-A Polygon can be created from SQL by calling the `st_geomfromtext` function on a LineString definition expressed in the [Well Known Text (WKT)](spatial-glossary.html#wkt) format as shown below.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeomFromText('POLYGON((0 0, 0 1024, 1024 1024, 1024 0, 0 0))');
-~~~
-
-~~~
-                                                                                       st_geomfromtext
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  010300000001000000050000000000000000000000000000000000000000000000000000000000000000009040000000000000904000000000000090400000000000009040000000000000000000000000000000000000000000000000
-(1 row)
-~~~
-
-### Polygons with holes
-
-To represent a polygon with holes in [WKT](spatial-glossary.html#wkt), add one or more additional lists of coordinates that define the boundaries of the holes as shown below:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_GeomFromText('POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902), (-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))');
-~~~
-
-~~~
-                                                                                                                                           st_geomfromtext
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  010300000002000000040000006FF1F09E03FA55C0DFDFA0BDFA844540545227A089FF57C0791EDC9DB513424064B14D2A1AED52C0CCCF0D4DD90942406FF1F09E03FA55C0DFDFA0BDFA84454004000000A4A7C821E2E755C07C48F8DEDFF0444073309B00C38C56C038BF61A241504340E884D041979C54C0967A1684F2344340A4A7C821E2E755C07C48F8DEDFF04440
-(1 row)
-~~~
-
-### Using a SQL function
-
-You can also use the `st_makepolygon` function on a LineString that defines the outer boundary of the Polygon, e.g.:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_MakePolygon('LINESTRING(0 0, 0 1024, 1024 1024, 1024 0, 0 0)');
-~~~
-
-~~~
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  010300000001000000050000000000000000000000000000000000000000000000000000000000000000009040000000000000904000000000000090400000000000009040000000000000000000000000000000000000000000000000
-(1 row)
-~~~
-
-## See also
-
-- [Spatial objects](spatial-features.html#spatial-objects)
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/postgresql-compatibility.md b/src/current/v20.2/postgresql-compatibility.md
deleted file mode 100644
index 315ed1a3527..00000000000
--- a/src/current/v20.2/postgresql-compatibility.md
+++ /dev/null
@@ -1,192 +0,0 @@
----
-title: PostgreSQL Compatibility
-summary: A summary of CockroachDB's compatibility with PostgreSQL
-toc: true
----
-
-CockroachDB supports the [PostgreSQL wire protocol](https://www.postgresql.org/docs/current/protocol.html) and the majority of PostgreSQL syntax. This means that existing applications built on PostgreSQL can often be migrated to CockroachDB without changing application code.
-
-CockroachDB is compatible with PostgreSQL 9.5 and works with majority of PostgreSQL database tools such as [Dbeaver](dbeaver.html), [Intellij](intellij-idea.html), pgdump and so on. Consult this link for a full list of supported [third-party database tools](third-party-database-tools.html). CockroachDB also works with most [PostgreSQL drivers and ORMs](example-apps.html).
-
-However, CockroachDB does not support some of the PostgreSQL features or behaves differently from PostgreSQL because not all features can be easily implemented in a distributed system. This page documents the known list of differences between PostgreSQL and CockroachDB for identical input. That is, a SQL statement of the type listed here will behave differently than in PostgreSQL. Porting an existing application to CockroachDB will require changing these expressions.
-
-{{site.data.alerts.callout_info}}
-This document currently only covers unsupported SQL and how to rewrite SQL expressions. It does not discuss strategies for porting applications that use <a href="sql-feature-support.html">SQL features CockroachDB does not currently support</a>.
-{{site.data.alerts.end}}
-
-## Unsupported Features
-
-{% include {{page.version.version}}/sql/unsupported-postgres-features.md %}
-
-## Features that differ from PostgreSQL
-
-Note, some of the differences below only apply to rare inputs, and so no change will be needed, even if the listed feature is being used. In these cases, it is safe to ignore the porting instructions.
-
-### Overflow of `float`
-
-In PostgreSQL, the `float` type returns an error when it overflows or an expression would return Infinity:
-
-~~~
-postgres=# select 1e300::float * 1e10::float;
-ERROR:  value out of range: overflow
-postgres=#  select pow(0::float, -1::float);
-ERROR:  zero raised to a negative power is undefined
-~~~
-
-In CockroachDB, these expressions instead return Infinity:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT 1e300::float * 1e10::float;
-~~~
-
-~~~
-  ?column?
-------------
-  +Inf
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT pow(0::float, -1::float);
-~~~
-
-~~~
-  pow
---------
-  +Inf
-(1 row)
-~~~
-
-### Precedence of unary `~`
-
-In PostgreSQL, the unary `~` (bitwise not) operator has a low precedence. For example, the following query is parsed as `~ (1 + 2)` because `~` has a lower precedence than `+`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ~1 + 2;
-~~~
-
-~~~
-  ?column?
-------------
-         0
-(1 row)
-~~~
-
-In CockroachDB, unary `~` has the same (high) precedence as unary `-`, so the above expression will be parsed as `(~1) + 2`.
-
-**Porting instructions:** Manually add parentheses around expressions that depend on the PostgreSQL behavior.
-
-### Precedence of bitwise operators
-
-In PostgreSQL, the operators `|` (bitwise OR), `#` (bitwise XOR), and `&` (bitwise AND) all have the same precedence.
-
-In CockroachDB, the precedence from highest to lowest is: `&`, `#`, `|`.
-
-**Porting instructions:** Manually add parentheses around expressions that depend on the PostgreSQL behavior.
-
-### Integer division
-
-In PostgreSQL, division of integers results in an integer. For example, the following query returns `1`, since the `1 / 2` is truncated to `0`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT 1 + 1 / 2;
-~~~
-
-~~~
-  ?column?
-------------
-       1.5
-(1 row)
-~~~
-
-In CockroachDB, integer division results in a `decimal`. CockroachDB instead provides the `//` operator to perform floor division.
-
-**Porting instructions:** Change `/` to `//` in integer division where the result must be an integer.
-
-### Shift argument modulo
-
-In PostgreSQL, the shift operators (`<<`, `>>`) sometimes modulo their second argument to the bit size of the underlying type. For example, the following query results in a `1` because the int type is 32 bits, and `32 % 32` is `0`, so this is the equivalent of `1 << 0`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT 1::int << 32;
-~~~
-
-~~~
-   ?column?
---------------
-  4294967296
-(1 row)
-~~~
-
-In CockroachDB, no such modulo is performed.
-
-**Porting instructions:** Manually add a modulo to the second argument. Also note that CockroachDB's [`INT`](int.html) type is always 64 bits. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT 1::int << (x % 64);
-~~~
-
-### Locking and `FOR UPDATE`
-
-CockroachDB supports the `SELECT FOR UPDATE` statement, which is used to order transactions by controlling concurrent access to one or more rows of a table.
-
-For more information, see [`SELECT FOR UPDATE`](select-for-update.html).
-
-### `CHECK` constraint validation for `INSERT ON CONFLICT`
-
-CockroachDB validates [`CHECK`](check.html) constraints on the results of [`INSERT ON CONFLICT`](insert.html#on-conflict-clause) statements, preventing new or changed rows from violating the constraint. Unlike PostgreSQL, CockroachDB does not also validate `CHECK` constraints on the input rows of `INSERT ON CONFLICT` statements.
-
-If this difference matters to your client, you can `INSERT ON CONFLICT` from a `SELECT` statement and check the inserted value as part of the `SELECT`. For example, instead of defining `CHECK (x > 0)` on `t.x` and using `INSERT INTO t(x) VALUES (3) ON CONFLICT (x) DO UPDATE SET x = excluded.x`, you could do the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t (x)
-    SELECT if (x <= 0, crdb_internal.force_error('23514', 'check constraint violated'), x)
-      FROM (values (3)) AS v(x)
-    ON CONFLICT (x)
-      DO UPDATE SET x = excluded.x;
-~~~
-
-An `x` value less than `1` would result in the following error:
-
-~~~
-pq: check constraint violated
-~~~
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/35370)
-
-### Column name from an outer column inside a subquery
-
-CockroachDB returns the column name from an outer column inside a subquery as `?column?`, unlike PostgreSQL. For example:
-
-~~~ sql
-> SELECT (SELECT t.*) FROM (VALUES (1)) t(x);
-~~~
-
-CockroachDB:
-
-~~~
-  ?column?
-------------
-         1
-~~~
-
-PostgreSQL:
-
-~~~
- x
----
- 1
-~~~
-
-[Tracking GitHub Issue](https://github.com/cockroachdb/cockroach/issues/46563)
-
-### SQL Compatibility
-
-Click the following link to find a full list of [CockroachDB supported SQL Features](sql-feature-support.html).
diff --git a/src/current/v20.2/primary-key.md b/src/current/v20.2/primary-key.md
deleted file mode 100644
index ac946e213f4..00000000000
--- a/src/current/v20.2/primary-key.md
+++ /dev/null
@@ -1,138 +0,0 @@
----
-title: Primary Key Constraint
-summary: A primary key constraint specifies columns that can be used to uniquely identify rows in a table.
-toc: true
----
-
-The `PRIMARY KEY` [constraint](constraints.html) specifies that the constrained columns' values must uniquely identify each row.
-
-Unlike other constraints which have very specific uses, the `PRIMARY KEY` constraint *must be used for every table* because it provides an intrinsic structure to the table's data.
-
-A table's primary key should be explicitly defined in the [`CREATE TABLE`](create-table.html) statement. Tables can only have one primary key.
-
-You can [change the primary key](#changing-primary-key-columns) of an existing table with an [`ALTER TABLE ... ALTER PRIMARY KEY`](alter-primary-key.html) statement, or by using [`DROP CONSTRAINT`](drop-constraint.html) and then [`ADD CONSTRAINT`](add-constraint.html) in the same transaction.
-
-## Syntax
-
-`PRIMARY KEY` constraints can be defined at the [table level](#table-level). However, if you only want the constraint to apply to a single column, it can be applied at the [column level](#column-level).
-
-### Column level
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/primary_key_column_level.html %}
-</div>
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table you're creating.
- `column_name` | The name of the Primary Key column.
- `column_type` | The Primary Key column's [data type](data-types.html).
- `column_constraints` | Any other column-level [constraints](constraints.html) you want to apply to this column.
- `column_def` | Definitions for any other columns in the table.
- `table_constraints` | Any table-level [constraints](constraints.html) you want to apply.
-
-**Example**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders (
-    order_id        UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    order_date      TIMESTAMP NOT NULL,
-    order_mode      STRING(8),
-    customer_id     INT,
-    order_status    INT
-  );
-~~~
-
-### Table level
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/primary_key_table_level.html %}
-</div>
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table you're creating.
- `column_def` | Definitions for any other columns in the table.
- `name` | The name you want to use for the constraint, which must be unique to its table and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
- `column_name` | The name of the column you want to use as the `PRIMARY KEY`.<br/><br/>The order in which you list columns here affects the structure of the `primary` index.
- `table_constraints` | Any other table-level [constraints](constraints.html) you want to apply.
-
-**Example**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS inventories (
-    product_id        INT,
-    warehouse_id      INT,
-    quantity_on_hand  INT NOT NULL,
-    PRIMARY KEY (product_id, warehouse_id)
-  );
-~~~
-
-## Details
-
-The columns in the `PRIMARY KEY` constraint are used to create its `primary` [index](indexes.html), which CockroachDB uses by default to access the table's data. This index does not take up additional disk space (unlike secondary indexes, which do) because CockroachDB uses the `primary` index to structure the table's data in the key-value layer. For more information, see our blog post [SQL in CockroachDB: Mapping Table Data to Key-Value Storage](https://www.cockroachlabs.com/blog/sql-in-cockroachdb-mapping-table-data-to-key-value-storage/).
-
-To ensure each row has a unique identifier, the `PRIMARY KEY` constraint combines the properties of both the [`UNIQUE`](unique.html) and [`NOT NULL`](not-null.html) constraints. The properties of both constraints are necessary to make sure each row's primary key columns contain distinct sets of values. The properties of the `UNIQUE` constraint ensure that each value is distinct from all other values. However, because *NULL* values never equal other *NULL* values, the `UNIQUE` constraint is not enough (two rows can appear the same if one of the values is *NULL*). To prevent the appearance of duplicated values, the `PRIMARY KEY` constraint also enforces the properties of the `NOT NULL` constraint.
-
-For best practices, see [Schema Design: Select primary key columns](schema-design-table.html#select-primary-key-columns).
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS inventories (
-    product_id        INT,
-    warehouse_id      INT,
-    quantity_on_hand  INT NOT NULL,
-    PRIMARY KEY (product_id, warehouse_id)
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO inventories VALUES (1, 1, 100);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO inventories VALUES (1, 1, 200);
-~~~
-
-~~~
-pq: duplicate key value (product_id,warehouse_id)=(1,1) violates unique constraint "primary"
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO inventories VALUES (1, NULL, 100);
-~~~
-
-~~~
-pq: null value in column "warehouse_id" violates not-null constraint
-~~~
-
-## Changing primary key columns
-
-You can change the primary key of an existing table by doing one of the following:
-
-- Issuing an [`ALTER TABLE ... ALTER PRIMARY KEY`](alter-primary-key.html) statement. When you change a primary key with `ALTER PRIMARY KEY`, the old primary key index becomes a secondary index. This helps optimize the performance of queries that still filter on the old primary key column.
-- Issuing an [`ALTER TABLE ... DROP CONSTRAINT ... PRIMARY KEY`](drop-constraint.html) statement to drop the primary key, followed by an [`ALTER TABLE ... ADD CONSTRAINT ... PRIMARY KEY`](add-constraint.html) statement, in the same transaction, to add a new primary key. This replaces the existing primary key without creating a secondary index from the old primary key. For examples, see the [`ADD CONSTRAINT`](add-constraint.html#examples) and [`DROP CONSTRAINT`](drop-constraint.html#examples) pages.
-
-{{site.data.alerts.callout_info}}
-You can use an [`ADD CONSTRAINT ... PRIMARY KEY`](add-constraint.html) statement without a [`DROP CONSTRAINT ... PRIMARY KEY`](drop-constraint.html) if the primary key was not explicitly defined at [table creation](create-table.html), and the current [primary key is on `rowid`](indexes.html#creation).
-{{site.data.alerts.end}}
-
-## See also
-
-- [Constraints](constraints.html)
-- [`CHECK` constraint](check.html)
-- [`DEFAULT` constraint](default-value.html)
-- [`REFERENCES` constraint (Foreign Key)](foreign-key.html)
-- [`PRIMARY KEY` constraint](primary-key.html)
-- [`NOT NULL` constraint](not-null.html)
-- [`UNIQUE` constraint](unique.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`ALTER PRIMARY KEY`](alter-primary-key.html)
-- [`ALTER TABLE`](alter-table.html)
diff --git a/src/current/v20.2/query-behavior-troubleshooting.md b/src/current/v20.2/query-behavior-troubleshooting.md
deleted file mode 100644
index e23184afd83..00000000000
--- a/src/current/v20.2/query-behavior-troubleshooting.md
+++ /dev/null
@@ -1,215 +0,0 @@
----
-title: Troubleshoot SQL Behavior
-summary: Learn how to troubleshoot issues with specific SQL statements with CockroachDB
-toc: true
----
-
-If a [SQL statement](sql-statements.html) returns an unexpected result or takes longer than expected to process, this page will help you troubleshoot the issue.
-
-{{site.data.alerts.callout_success}}
-For a developer-centric walkthrough of optimizing SQL query performance, see [Optimize Query Performance](make-queries-fast.html).
-{{site.data.alerts.end}}
-
-## Identify slow queries
-
-Use the [slow query log](#using-the-slow-query-log) or [DB Console](#using-the-db-console) to detect slow queries in your cluster.
-
-### Using the slow query log
-
- The slow query log is a record of SQL queries whose service latency exceeds a specified threshold value. When the `sql.log.slow_query.latency_threshold` [cluster setting](cluster-settings.html) is set to a non-zero value, each gateway node will log slow SQL queries to a secondary log file (`cockroach-sql-slow.log`) in the [log directory](debug-and-error-logs.html#write-to-file).
-
-{{site.data.alerts.callout_info}}
-Service latency is the time taken to execute a query once it is received by the cluster. It does not include the time taken to send the query to the cluster or return the result to the client.
-{{site.data.alerts.end}}
-
-1. Run the [`cockroach sql`](cockroach-sql.html) command against one of your nodes. This opens the interactive SQL shell.
-
-2. Set the `sql.log.slow_query.latency_threshold` [cluster setting](cluster-settings.html) to a threshold of your choosing. For example, 100 milliseconds represents [the limit where a user feels the system is reacting instantaneously](https://www.nngroup.com/articles/response-times-3-important-limits/).
-
-  	{% include copy-clipboard.html %}
-  	~~~ sql
-  	> SET CLUSTER SETTING sql.log.slow_query.latency_threshold = '100ms';
-    ~~~
-
-3. <span class="version-tag">New in v20.2:</span> To write slow internal queries to a separate log, set the `sql.log.slow_query.internal_queries.enabled` cluster setting to `true`.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING sql.log.slow_query.internal_queries.enabled = 'true';
-    ~~~
-
-4. Each node's slow query logs are written by default in CockroachDB's standard [log directory](debug-and-error-logs.html#write-to-file).
-
-5. When you open a slow query log, look for a line that corresponds to your earlier [`SET CLUSTER SETTING`](set-cluster-setting.html) command. For example:
-
-	~~~
-  I201008 21:16:13.751178 1947 sql/exec_log.go:225 ⋮ [n1,client=‹[::1]:54351›,hostnossl,user=root] 1 53.832ms ‹exec› ‹"$ cockroach sql"› ‹{}› ‹"SET CLUSTER SETTING \"sql.log.slow_query.latency_threshold\" = '100ms'"› ‹{}› 0 ‹""› 0 ‹{ LATENCY_THRESHOLD }›
-	~~~
-
-	Slow queries will be logged after this line.
-
-6. The slow query log generally shares the [SQL audit log file format](experimental-audit.html#audit-log-file-format). One exception is that service latency is found between the log entry counter and log message.
-
-  	For example, the below query was logged with a service latency of 117.473ms milliseconds:
-
-  	~~~
-    I201008 21:17:53.642721 7444 sql/exec_log.go:225 ⋮ [n1,client=‹[::1]:54425›,hostnossl,user=root] 270 117.473ms ‹exec› ‹"movr"› ‹{}› ‹"UPDATE rides SET end_address = $3, end_time = now() WHERE (city = $1) AND (id = $2)"› ‹{$1:"'san francisco'", $2:"'9c33be8a-fdeb-428b-b3df-50c3c947df5a'", $3:"'3873 Margaret Junctions Apt. 52'"}› 1 ‹""› 0 ‹{ LATENCY_THRESHOLD }›
-  	~~~
-
-    And the following internal query was logged with a service latency of 483.627 milliseconds:
-
-    ~~~
-    I201008 21:16:06.534587 28912 sql/exec_log.go:225 ⋮ [intExec=‹create-stats›] 10 483.627ms ‹exec-internal› ‹"$ internal-create-stats"› ‹{}› ‹"CREATE STATISTICS __auto__ FROM [56] WITH OPTIONS THROTTLING 0.9 AS OF SYSTEM TIME '-30s'"› ‹{}› 0 ‹""› 0 ‹{ LATENCY_THRESHOLD }›
-    ~~~
-
-{{site.data.alerts.callout_info}}
-Setting `sql.log.slow_query.latency_threshold` to a non-zero value enables tracing on all queries, which impacts performance. After debugging, set the value back to `0s` to disable the log.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-{% include {{ page.version.version }}/ui/ui-log-files.md %}
-{{site.data.alerts.end}}
-
-### Using the DB Console
-
-High latency SQL statements are displayed on the [**Statements page**](ui-statements-page.html) of the DB Console. To view the Statements page, [access the DB Console](ui-overview.html#db-console-access) and click **Statements** on the left.
-
-You can also check the [service latency graph](ui-sql-dashboard.html#service-latency-sql-99th-percentile) and the [CPU graph](ui-hardware-dashboard.html#cpu-percent) on the SQL and Hardware Dashboards, respectively. If the graphs show latency spikes or CPU usage spikes, these might indicate slow queries in your cluster.
-
-## Visualize statement traces in Jaeger
-
-You can look more closely at the behavior of a statement by visualizing a statement trace in [Jaeger](https://www.jaegertracing.io/). A [statement trace](show-trace.html) contains messages and timing information from all nodes involved in the execution.
-
-1. Activate [statement diagnostics](ui-statements-page.html#diagnostics) on the DB Console Statements Page or run [`EXPLAIN ANALYZE (DEBUG)`](explain-analyze.html#debug-option) to obtain a diagnostics bundle for the statement.
-
-1. Start Jaeger:
-
-  {% include copy-clipboard.html %}
-  ~~~ shell
-  docker run -d --name jaeger -p 16686:16686 jaegertracing/all-in-one:1.17
-  ~~~
-
-1. Access the Jaeger UI at `http://localhost:16686/search`.
-
-1. Click on **JSON File** in the Jaeger UI and upload `trace-jaeger.json` from the diagnostics bundle. The trace will appear in the list on the right.
-
-    <img src="{{ 'images/v20.2/jaeger-trace-json.png' | relative_url }}" alt="Jaeger Trace Upload JSON" style="border:1px solid #eee;max-width:40%" />
-
-1. Click on the trace to view its details. It is visualized as a collection of spans with timestamps. These may include operations executed by different nodes.
-
-    <img src="{{ 'images/v20.2/jaeger-trace-spans.png' | relative_url }}" alt="Jaeger Trace Spans" style="border:1px solid #eee;max-width:100%" />
-
-    The full timeline displays the execution time and [execution phases](architecture/sql-layer.html#sql-parser-planner-executor) for the statement.
-
-1. Click on a span to view details for that span and log messages.
-
-    <img src="{{ 'images/v20.2/jaeger-trace-log-messages.png' | relative_url }}" alt="Jaeger Trace Log Messages" style="border:1px solid #eee;max-width:100%" />
-
-1. You can troubleshoot [transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention), for example, by gathering [diagnostics](ui-statements-page.html#diagnostics) on statements with high latency and looking through the log messages in `trace-jaeger.json` for jumps in latency.
-
-  In the example below, the trace shows that there is significant latency between a push attempt on a transaction that is holding a [lock](architecture/transaction-layer.html#writing) (56.85ms) and that transaction being committed (131.37ms).
-
-    <img src="{{ 'images/v20.2/jaeger-trace-transaction-contention.png' | relative_url }}" alt="Jaeger Trace Log Messages" style="border:1px solid #eee;max-width:100%" />
-
-## `SELECT` statement performance issues
-
-The common reasons for a sub-optimal `SELECT` performance are inefficient scans, full scans, and incorrect use of indexes. To improve the performance of `SELECT` statements, refer to the following documents:
-
--  [Table scan best practices](performance-best-practices-overview.html#table-scans-best-practices)
-
--  [Indexes best practices](schema-design-indexes.html#best-practices)
-
-## Query is always slow
-
-If you have consistently slow queries in your cluster, use the [Statement Details](ui-statements-page.html#statement-details-page) page to drill down to an individual statement and [collect diagnostics](ui-statements-page.html#diagnostics) for the statement. A diagnostics bundle contains a record of transaction events across nodes for the SQL statement.
-
-You can also use an [`EXPLAIN ANALYZE`](explain-analyze.html) statement, which executes a SQL query and returns a physical query plan with execution statistics. Query plans can be used to troubleshoot slow queries by indicating where time is being spent, how long a processor (i.e., a component that takes streams of input rows and processes them according to a specification) is not doing work, etc.
-
-We recommend sending either the diagnostics bundle or the `EXPLAIN ANALYZE` output to our [support team](support-resources.html) for analysis.
-
-## Query is sometimes slow
-
-If the query performance is irregular:
-
-1.  Run [`SHOW TRACE`](show-trace.html) for the query twice: once when the query is performing as expected and once when the query is slow.
-
-2.  [Contact us](support-resources.html) to analyze the outputs of the `SHOW TRACE` command.
-
-## Cancelling running queries
-
-See [Cancel query](manage-long-running-queries.html#cancel-long-running-queries)
-
-## Low throughput
-
-Throughput is affected by the disk I/O, CPU usage, and network latency. Use the DB Console to check the following metrics:
-
-- Disk I/O: [Disk IOPS in progress](ui-hardware-dashboard.html#disk-iops-in-progress)
-
-- CPU usage: [CPU percent](ui-hardware-dashboard.html#cpu-percent)
-
-- Network latency: [Network Latency page](ui-network-latency-page.html)
-
-## Single hot node
-
-A hot node is one that has much higher resource usage than other nodes. To determine if you have a hot node in your cluster, [access the DB Console](ui-overview.html#db-console-access), click **Metrics** on the left, and navigate to the following graphs. Hover over each of the following graphs to see the per-node values of the metrics. If one of the nodes has a higher value, you have a hot node in your cluster.
-
--   Replication dashboard > Average queries per store graph.
-
--   Overview Dashboard > Service Latency graph
-
--   Hardware Dashboard > CPU percent graph
-
--   SQL Dashboard > SQL Connections graph
-
--   Hardware Dashboard > Disk IOPS in Progress graph
-
-**Solution:**
-
--   If you have a small table that fits into one range, then only one of the nodes will be used. This is expected behavior. However, you can [split your range](split-at.html) to distribute the table across multiple nodes.
-
--   If the **SQL Connections** graph shows that one node has a higher number of SQL connections and other nodes have zero connections, check if your app is set to talk to only one node.
-
--   Check load balancer settings.
-
--   Check for [transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-
--   If you have a monotonically increasing index column or Primary Key, then your index or Primary Key should be redesigned. See [Unique ID best practices](performance-best-practices-overview.html#unique-id-best-practices) for more information.
-
-## INSERT/UPDATE statements are slow
-
-Use the [Statements page](ui-statements-page.html) to identify the slow [SQL statements](sql-statements.html). To view the Statements page, [access the DB Console](ui-overview.html#db-console-access) and then click Statements on the left.
-
-Refer to the following documents to improve `INSERT` / `UPDATE` performance:
-
--   [Multi-row DML](performance-best-practices-overview.html#dml-best-practices)
-
--   [Bulk-Insert best practices](performance-best-practices-overview.html#bulk-insert-best-practices)
-
-## Per-node queries per second (QPS) is high
-
-If a cluster is not idle, it is useful to monitor the per-node queries per second. Cockroach will automatically distribute load throughout the cluster. If one or more nodes is not performing any queries there is likely something to investigate. See `exec_success` and `exec_errors` which track operations at the KV layer and `sql_{select,insert,update,delete}_count` which track operations at the SQL layer.
-
-## Increasing number of nodes does not improve performance
-
-See [Why would increasing the number of nodes not result in more operations per second?](operational-faqs.html#why-would-increasing-the-number-of-nodes-not-result-in-more-operations-per-second)
-
-## `bad connection` & `closed` responses
-
-If you receive a response of `bad connection` or `closed`, this normally indicates that the node you connected to died. You can check this by connecting to another node in the cluster and running [`cockroach node status`](cockroach-node.html#show-the-status-of-all-nodes).
-
-Once you find the downed node, you can check its [logs](debug-and-error-logs.html) (stored in `cockroach-data/logs` by default).
-
-Because this kind of behavior is entirely unexpected, you should [file an issue](file-an-issue.html).
-
-## SQL logging
-
-{% include {{ page.version.version }}/faq/sql-query-logging.md %}
-
-## Something else?
-
-Try searching the rest of our docs for answers or using our other [support resources](support-resources.html), including:
-
-- [CockroachDB Community Forum](https://forum.cockroachlabs.com)
-- [CockroachDB Community Slack](https://cockroachdb.slack.com)
-- [StackOverflow](http://stackoverflow.com/questions/tagged/cockroachdb)
-- [CockroachDB Support Portal](https://support.cockroachlabs.com)
diff --git a/src/current/v20.2/query-data.md b/src/current/v20.2/query-data.md
deleted file mode 100644
index c90734f262e..00000000000
--- a/src/current/v20.2/query-data.md
+++ /dev/null
@@ -1,210 +0,0 @@
----
-title: Query Data
-summary: How to send SQL queries to CockroachDB from various programming languages
-toc: true
----
-
-This page has instructions for making SQL [selection queries][selection] against CockroachDB from various programming languages.
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Install a Postgres client](install-client-drivers.html).
-- [Connect to the database](connect-to-the-database.html).
-- [Insert data](insert-data.html) that you now want to run queries against.
-
-{% include {{page.version.version}}/app/retry-errors.md %}
-
-## Simple selects
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go</button>
-  <button class="filter-button" data-scope="java">Java</button>
-  <button class="filter-button" data-scope="python">Python</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT id, balance from accounts;
-~~~
-
-For more information about how to use the built-in SQL client, see the [`cockroach sql`](cockroach-sql.html) reference docs.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-// 'db' is an open database connection
-
-rows, err := db.Query("SELECT id, balance FROM accounts")
-if err != nil {
-    log.Fatal(err)
-}
-defer rows.Close()
-fmt.Println("Initial balances:")
-for rows.Next() {
-    var id, balance int
-    if err := rows.Scan(&id, &balance); err != nil {
-        log.Fatal(err)
-    }
-    fmt.Printf("%d %d\n", id, balance)
-}
-~~~
-
-{% include {{page.version.version}}/app/for-a-complete-example-go.md %}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-// ds is an org.postgresql.ds.PGSimpleDataSource
-
-try (Connection connection = ds.getConnection()) {
-    Statement stmt = connection.createStatement();
-    ResultSet rs = stmt.executeQuery("SELECT id, balance FROM accounts");
-
-    while (rs.next()) {
-        int id = rs.getInt(1);
-        int bal = rs.getInt(2);
-        System.out.printf("ID: %10s\nBalance: %5s\n", id, bal);
-    }
-    rs.close();
-
-} catch (SQLException e) {
-    System.out.printf("sql state = [%s]\ncause = [%s]\nmessage = [%s]\n",
-                      e.getSQLState(), e.getCause(), e.getMessage());
-}
-~~~
-
-{% include {{page.version.version}}/app/for-a-complete-example-java.md %}
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-# conn is a psycopg2 connection
-
-with conn.cursor() as cur:
-    cur.execute("SELECT id, balance FROM accounts")
-    rows = cur.fetchall()
-    for row in rows:
-        print([str(cell) for cell in row])
-~~~
-
-{% include {{page.version.version}}/app/for-a-complete-example-python.md %}
-
-</section>
-
-## Order results
-
-To order the results of a query, use an `ORDER BY` clause.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM bank ORDER BY balance;
-~~~
-
-~~~
-  id | balance |                                               payload
------+---------+-------------------------------------------------------------------------------------------------------
-   0 |    -500 | initial-dTqnRurXztAPkykhZWvsCmeJkMwRNcJAvTlNbgUEYfagEQJaHmfPsquKZUBOGwpAjPtATpGXFJkrtQCEJODSlmQctvyh
-   1 |    -499 | initial-PCLGABqTvrtRNyhAyOhQdyLfVtCmRykQJSsdwqUFABkPOMQayVEhiAwzZKHpJUiNmVaWYZnReMKfONZvRKbTETaIDccE
-   2 |    -498 | initial-VNfyUJHfCmMeAUoTgoSVvnByDyvpHNPHDfVoNWdXBFQpwMOBgNVtNijyTjmecvFqyeLHlDbIBRrbCzSeiHWSLmWbhIvh
-   3 |    -497 | initial-llflzsVuQYUlfwlyoaqjdwKUNgNFVgvlnINeOUUVyfxyvmOiAelxqkTBfpBBziYVHgQLLEuCazSXmURnXBlCCfsOqeji
-   4 |    -496 | initial-rmGzVVucMqbYnBaccWilErbWvcatqBsWSXvrbxYUUEhmOnccXzvqcsGuMVJNBjmzKErJzEzzfCzNTmLQqhkrDUxdgqDD
-(5 rows)
-~~~
-
-For reference documentation and more examples, see the [`ORDER BY`](order-by.html) syntax page.
-
-## Limit results
-
-To limit the results of a query, use a `LIMIT` clause.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM bank LIMIT 5;
-~~~
-
-~~~
-  id | balance |                                               payload
------+---------+-------------------------------------------------------------------------------------------------------
-   0 |       0 | initial-dTqnRurXztAPkykhZWvsCmeJkMwRNcJAvTlNbgUEYfagEQJaHmfPsquKZUBOGwpAjPtATpGXFJkrtQCEJODSlmQctvyh
-   1 |       0 | initial-PCLGABqTvrtRNyhAyOhQdyLfVtCmRykQJSsdwqUFABkPOMQayVEhiAwzZKHpJUiNmVaWYZnReMKfONZvRKbTETaIDccE
-   2 |       0 | initial-VNfyUJHfCmMeAUoTgoSVvnByDyvpHNPHDfVoNWdXBFQpwMOBgNVtNijyTjmecvFqyeLHlDbIBRrbCzSeiHWSLmWbhIvh
-   3 |       0 | initial-llflzsVuQYUlfwlyoaqjdwKUNgNFVgvlnINeOUUVyfxyvmOiAelxqkTBfpBBziYVHgQLLEuCazSXmURnXBlCCfsOqeji
-   4 |       0 | initial-rmGzVVucMqbYnBaccWilErbWvcatqBsWSXvrbxYUUEhmOnccXzvqcsGuMVJNBjmzKErJzEzzfCzNTmLQqhkrDUxdgqDD
-(5 rows)
-~~~
-
-For reference documentation and more examples, see the [`LIMIT`/`OFFSET`](limit-offset.html) syntax page.
-
-## Joins
-
-The syntax for a [selection query][selection] with a two-way [join][joins] is shown below.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	a.col1, b.col1
-FROM
-	some_table AS a
-	JOIN
-    some_other_table AS b
-    ON
-    a.id = b.id
-WHERE
-	a.col2 > 100 AND a.col3 > now()
-ORDER BY
-	a.col2 DESC
-LIMIT
-	25;
-~~~
-
-Join performance can be a big factor in your application's performance.  For more information about how to make sure your SQL performs well, see [Optimize Query Performance][fast].
-
-## See also
-
-Reference information related to this task:
-
-- [Selection queries][selection]
-- [`SELECT`](select-clause.html)
-- [Joins][joins]
-- [Paginate through limited results][paginate]
-- [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention)
-
-Other common tasks:
-
-- [Connect to the Database](connect-to-the-database.html)
-- [Insert Data](insert-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-- [Run Multi-Statement Transactions](run-multi-statement-transactions.html)
-- [Error Handling and Troubleshooting](error-handling-and-troubleshooting.html)
-- [Optimize Query Performance][fast]
-- [Hello World Example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[selection]: selection-queries.html
-[manual]: manual-deployment.html
-[orchestrated]: orchestration.html
-[fast]: make-queries-fast.html
-[paginate]: pagination.html
-[joins]: joins.html
diff --git a/src/current/v20.2/query-replication-reports.md b/src/current/v20.2/query-replication-reports.md
deleted file mode 100644
index e7921276c53..00000000000
--- a/src/current/v20.2/query-replication-reports.md
+++ /dev/null
@@ -1,516 +0,0 @@
----
-title: Replication Reports
-summary: Verify that your cluster's data replication, data placement, and zone configurations are working as expected.
-keywords: availability zone, zone config, zone configs, zone configuration, constraint, constraints
-toc: true
----
-
-Several new and updated tables (listed below) are available to help you query the status of your cluster's data replication, data placement, and zone constraint conformance. For example, you can:
-
-- See what data is under-replicated or unavailable.
-- Show which of your localities (if any) are critical. A locality is "critical" for a range if all of the nodes in that locality becoming unreachable would cause the range to become unavailable. In other words, the locality contains a majority of the range's replicas.
-- See if any of your cluster's data placement constraints are being violated.
-
-{{site.data.alerts.callout_info}}
-The information on this page assumes you are familiar with [replication zones](configure-replication-zones.html) and [partitioning](partitioning.html).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_danger}}
-**This is an experimental feature.**  The interface and output are subject to change.
-
-In particular, the direct access to `system` tables shown here will not be a supported way to inspect CockroachDB in future versions. We're committed to adding stable ways to inspect these replication reports in the future, likely via `SHOW` statements and/or [views](views.html) and [built-in functions](functions-and-operators.html) in the `crdb_internal` schema.
-{{site.data.alerts.end}}
-
-## Conformance reporting tables
-
-The following new and updated tables are available for verifying constraint conformance.
-
-- [`system.reports_meta`](#system-reports_meta) contains metadata about the replication report data listed in the `system.replication_*` tables. Currently, the only metadata available is the report generation time.
-- [`system.replication_stats`](#system-replication_stats) shows information about whether data is under-replicated, over-replicated, or unavailable.
-- [`system.replication_constraint_stats`](#system-replication_constraint_stats) shows the status of any data placement constraints you've configured.
-- [`system.replication_critical_localities`](#system-replication_critical_localities) shows which localities in your cluster (if any) are critical. A locality is "critical" for a range if all of the nodes in that locality becoming unreachable would cause the range to become unavailable. In other words, the locality contains a majority of the range's replicas.
-- [`crdb_internal.zones`](#crdb_internal-zones) can be used with the tables above to figure out the databases and table names where the non-conforming or at-risk data is located.
-
-To configure how often the conformance reports are run, adjust the `kv.replication_reports.interval` [cluster setting](cluster-settings.html), which accepts an [`INTERVAL`](interval.html). For example, to run it every five minutes:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SET CLUSTER setting kv.replication_reports.interval = '5m';
-~~~
-
-Only members of the `admin` role can access these tables. By default, the `root` user belongs to the `admin` role. For more information about users and roles, see [Manage Users](authorization.html#create-and-manage-users) and [Manage Roles](authorization.html#create-and-manage-roles).
-
-<a name="necessary-attributes"></a>
-
-{{site.data.alerts.callout_info}}
-The replication reports are only generated for zones that meet the following criteria:
-
-- The zone overrides some replication attributes compared to their parent zone. Ranges in zones for which a report is not generated are counted in the report of the first ancestor zone for which a report is generated.
-
-The attributes that must be overridden to trigger each report to run are:
-
-| Report                            | Field(s)                       |
-|-----------------------------------+--------------------------------|
-| `replication_constraint_stats`    | `constraints`                  |
-| `replication_critical_localities` | `constraints`,  `num_replicas` |
-| `replication_stats`               | `constraints`, `num_replicas`  |
-
-In addition to the above, the system's `default` zone always gets a report.
-{{site.data.alerts.end}}
-
-### system.replication_stats
-
-The `system.replication_stats` report contains information about whether data is under-replicated, over-replicated, or unavailable.
-
-For an example using this table, see [Find out which databases and tables have under-replicated ranges](#find-out-which-databases-and-tables-have-under-replicated-ranges).
-
- Ranges are considered under-replicated when one of the replicas is unresponsive. This includes the case when the node where the replica is stored is not running.
-
- This report considers a node to be dead (for the purposes of calculating the `unavailable_ranges` and `under_replicated_ranges` columns) if its [liveness record](cluster-setup-troubleshooting.html#check-node-liveness-record-last-update) is expired, which occurs if the node is unresponsive for more than a few seconds. In versions of CockroachDB prior to 20.1, this report used the value of the [cluster setting](cluster-settings.html) `server.time_until_store_dead`, which defaults to 5 minutes.
-
-#### Columns
-
-| Column name             | Data type          | Description                                                                                                                           |
-|-------------------------+--------------------+---------------------------------------------------------------------------------------------------------------------------------------|
-| zone_id                 | [`INT8`](int.html) | The ID of the [replication zone](configure-zone.html).                                                                                |
-| subzone_id              | [`INT8`](int.html) | The ID of the subzone (i.e., [partition](partition-by.html)).                                                                         |
-| report_id               | [`INT8`](int.html) | The ID of the [report](#system-reports_meta) that generated all of the rows in this table.                                            |
-| total_ranges            | [`INT8`](int.html) | Total [ranges](architecture/overview.html#architecture-range) in the zone this report entry is referring to.                          |
-| unavailable_ranges      | [`INT8`](int.html) | Unavailable ranges in the zone this report entry is referring to.                                                                     |
-| under_replicated_ranges | [`INT8`](int.html) | [Under-replicated ranges](ui-replication-dashboard.html#under-replicated-ranges) in the zone this report entry is referring to. |
-| over_replicated_ranges  | [`INT8`](int.html) | Over-replicated ranges in the zone this report entry is referring to.                                                                 |
-
-### system.replication_critical_localities
-
-The `system.replication_critical_localities` report contains which of your localities (if any) are critical. A locality is "critical" for a range if all of the nodes in that locality becoming unreachable would cause the range to become unavailable. In other words, the locality contains a majority of the range's replicas.
-
-That said, a locality being critical is not necessarily a bad thing as long as you are aware of it. What matters is that [you configure the topology of your cluster to get the resiliency you expect](topology-patterns.html).
-
-As described in [Configure Replication Zones](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes), localities are key-value pairs defined at [node startup time](cockroach-start.html#locality), and are ordered into _locality tiers_ that range from most inclusive to least inclusive (e.g., region before datacenter as in `region=eu,dc=paris`).
-
-For an example using this table, see [Find out which databases and tables have ranges in critical localities](#find-out-which-databases-and-tables-have-ranges-in-critical-localities).
-
- This report considers a node to be dead (for the purposes of calculating the `at_risk_ranges` column) if its [liveness record](cluster-setup-troubleshooting.html#check-node-liveness-record-last-update) is expired, which occurs if the node is unresponsive for more than a few seconds. In versions of CockroachDB prior to 20.1, this report used the value of the [cluster setting](cluster-settings.html) `server.time_until_store_dead`, which defaults to 5 minutes.
-
-#### Columns
-
-| Column name    | Data type               | Description                                                                                                                         |
-|----------------+-------------------------+-------------------------------------------------------------------------------------------------------------------------------------|
-| zone_id        | [`INT8`](int.html)      | The ID of the [replication zone](configure-zone.html).                                                                              |
-| subzone_id     | [`INT8`](int.html)      | The ID of the subzone (i.e., [partition](partition-by.html)).                                                                       |
-| locality       | [`STRING`](string.html) | The name of the critical [locality](configure-replication-zones.html#zone-config-node-locality).                                    |
-| report_id      | [`INT8`](int.html)      | The ID of the [report](#system-reports_meta) that generated all of the rows in this table.                                          |
-| at_risk_ranges | [`INT8`](int.html)      | The [ranges](architecture/overview.html#architecture-range) that are at risk of becoming unavailable as of the time of this report. |
-
-{{site.data.alerts.callout_info}}
-If you have not [defined any localities](configure-replication-zones.html#zone-config-node-locality), this report will not return any results. It only reports on localities that have been explicitly defined.
-{{site.data.alerts.end}}
-
-### system.replication_constraint_stats
-
-The `system.replication_constraint_stats` report lists violations to any data placement requirements you've configured.
-
-For an example using this table, see [Find out which of your tables have a constraint violation](#find-out-which-of-your-tables-have-a-constraint-violation).
-
-#### Columns
-
-| Column name      | Data type                       | Description                                                                                             |
-|------------------+---------------------------------+---------------------------------------------------------------------------------------------------------|
-| zone_id          | [`INT8`](int.html)              | The ID of the [replication zone](configure-zone.html).                                                  |
-| subzone_id       | [`INT8`](int.html)              | The ID of the subzone (i.e., [partition](partition-by.html)).                                           |
-| type             | [`STRING`](string.html)         | The type of zone configuration that was violated, e.g., `constraint`.                                   |
-| config           | [`STRING`](string.html)         | The YAML key-value pair used to configure the zone, e.g., `+region=europe-west1`.                       |
-| report_id        | [`INT8`](int.html)              | The ID of the [report](#system-reports_meta) that generated all of the rows in this table.              |
-| violation_start  | [`TIMESTAMPTZ`](timestamp.html) | The time when the violation was detected. Will return `NULL` if the number of `violating_ranges` is 0.  |
-| violating_ranges | [`INT8`](int.html)              | The [ranges](architecture/overview.html#architecture-range) that are in violation of the configuration. |
-
-### system.reports_meta
-
-The `system.reports_meta` report contains metadata about when the replication reports were last run. Each report contains a number of report entries, one per zone.
-
-Replication reports are run at the interval specified by the `kv.replication_reports.interval` [cluster setting](cluster-settings.html).
-
-#### Columns
-
-| Column name | Data type                       | Description                                             |
-|-------------+---------------------------------+---------------------------------------------------------|
-| id          | [`INT8`](int.html)              | The ID of the report that this report entry is part of. |
-| generated   | [`TIMESTAMPTZ`](timestamp.html) | When the report was generated.                          |
-
-### crdb_internal.zones
-
-The `crdb_internal.zones` table is useful for:
-
-- Viewing your cluster's zone configurations in various formats: YAML, SQL, etc.
-- Matching up data returned from the various replication reports with the names of the databases and tables, indexes, and partitions where that data lives.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SHOW COLUMNS FROM crdb_internal.zones;
-~~~
-
-| column_name         | data_type               | description                                                                                                                     |
-|---------------------+-------------------------+---------------------------------------------------------------------------------------------------------------------------------|
-| zone_id             | [`INT8`](int.html)      | The ID of the [replication zone](configure-zone.html).                                                                          |
-| subzone_id          | [`INT8`](int.html)      | The ID of the subzone (i.e., [partition](partition-by.html)).                                                                   |
-| target              | [`STRING`](string.html) | The "object" that the constraint is being applied to, e.g., `PARTITION us_west OF INDEX movr.public.users@primary`.             |
-| range_name          | [`STRING`](string.html) | The zone's name.                                                                                                                |
-| database_name       | [`STRING`](string.html) | The [database](show-databases.html) where the `target`'s data is located.                                                       |
-| table_name          | [`STRING`](string.html) | The [table](show-tables.html) where the `target`'s data is located.                                                             |
-| index_name          | [`STRING`](string.html) | The [index](show-index.html) where the `target`'s data is located.                                                              |
-| partition_name      | [`STRING`](string.html) | The [partition](show-partitions.html) where the `target`'s data is located.                                                     |
-| full_config_yaml    | [`STRING`](string.html) | The YAML you used to [configure this replication zone](configure-replication-zones.html).                                       |
-| full_config_sql     | [`STRING`](string.html) | The SQL you used to [configure this replication zone](configure-replication-zones.html).                                        |
-| raw_config_yaml     | [`STRING`](string.html) | The YAML for this [replication zone](configure-replication-zones.html), showing only values the user changed from the defaults. |
-| raw_config_sql      | [`STRING`](string.html) | The SQL for this [replication zone](configure-replication-zones.html), showing only values the user changed from the defaults.  |
-| raw_config_protobuf | [`BYTES`](bytes.html)   | A protobuf representation of the configuration for this [replication zone](configure-replication-zones.html).                   |
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements-geo-partitioned-replicas.md %}
-
-### Find out which of your tables have a constraint violation
-
-By default, this geo-distributed demo cluster will not have any constraint violations.
-
-To introduce a violation that we can then query for, we'll modify the zone configuration of the `users` table.
-
-First, let's see what existing zone configurations are attached to the `users` table, so we know what to modify.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                                  create_statement                                    
-+------------+-------------------------------------------------------------------------------------+
-  users      | CREATE TABLE users (                                                                 
-             |     id UUID NOT NULL,                                                                
-             |     city VARCHAR NOT NULL,                                                           
-             |     name VARCHAR NULL,                                                               
-             |     address VARCHAR NULL,                                                            
-             |     credit_card VARCHAR NULL,                                                        
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),                             
-             |     FAMILY "primary" (id, city, name, address, credit_card)                          
-             | ) PARTITION BY LIST (city) (                                                         
-             |     PARTITION us_west VALUES IN (('seattle'), ('san francisco'), ('los angeles')),   
-             |     PARTITION us_east VALUES IN (('new york'), ('boston'), ('washington dc')),       
-             |     PARTITION europe_west VALUES IN (('amsterdam'), ('paris'), ('rome'))             
-             | );                                                                                   
-             | ALTER PARTITION europe_west OF INDEX movr.public.users@primary CONFIGURE ZONE USING  
-             |     constraints = '[+region=europe-west1]';                                          
-             | ALTER PARTITION us_east OF INDEX movr.public.users@primary CONFIGURE ZONE USING      
-             |     constraints = '[+region=us-east1]';                                              
-             | ALTER PARTITION us_west OF INDEX movr.public.users@primary CONFIGURE ZONE USING      
-             |     constraints = '[+region=us-west1]'                                               
-(1 row)
-~~~
-
-To create a constraint violation, let's tell the ranges in the `europe_west` partition that they are explicitly supposed to *not* be in the `region=europe-west1` locality by issuing the following statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER PARTITION europe_west of INDEX movr.public.users@primary CONFIGURE ZONE USING constraints = '[-region=europe-west1]';
-~~~
-
-Once the statement above executes, the ranges currently stored in that locality will now be in a state where they are explicitly not supposed to be in that locality, and are thus in violation of a constraint.
-
-In other words, we are telling the ranges "where you are now is exactly where you are *not* supposed to be". This will cause the cluster to rebalance the ranges, which will take some time. During the time it takes for the rebalancing to occur, the ranges will be in violation.
-
-By default, the system constraint conformance report runs once every minute. You can change that interval by modifying the `kv.replication_reports.interval` [cluster setting](cluster-settings.html).
-
-After the internal constraint conformance report has run again, the following query should report a violation:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM system.replication_constraint_stats WHERE violating_ranges > 0;
-~~~
-
-~~~
-  zone_id | subzone_id |    type    |        config        | report_id |         violation_start         | violating_ranges  
-+---------+------------+------------+----------------------+-----------+---------------------------------+------------------+
-       53 |          2 | constraint | +region=us-east1     |         1 | 2019-10-21 20:28:40.79508+00:00 |                2  
-       53 |          3 | constraint | -region=europe-west1 |         1 | 2019-10-21 20:28:40.79508+00:00 |                2  
-       54 |          2 | constraint | +region=us-west1     |         1 | 2019-10-21 20:28:40.79508+00:00 |                1  
-       54 |          4 | constraint | +region=us-east1     |         1 | 2019-10-21 20:28:40.79508+00:00 |                2  
-       55 |          6 | constraint | +region=us-east1     |         1 | 2019-10-21 20:28:40.79508+00:00 |                4  
-       55 |          9 | constraint | +region=europe-west1 |         1 | 2019-10-21 20:28:40.79508+00:00 |                6  
-       56 |          2 | constraint | +region=us-east1     |         1 | 2019-10-21 20:28:40.79508+00:00 |                2  
-       56 |          3 | constraint | +region=europe-west1 |         1 | 2019-10-21 20:28:40.79508+00:00 |                1  
-       58 |          2 | constraint | +region=us-east1     |         1 | 2019-10-21 20:28:40.79508+00:00 |                2  
-(9 rows)
-~~~
-
-To be more useful, we'd like to find out the database and table names where these constraint-violating ranges live. To get that information we'll need to join the output of `system.replication_constraint_stats` report with the `crdb_internal.zones` table using a query like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-    partition_violations
-        AS (
-            SELECT
-                *
-            FROM
-                system.replication_constraint_stats
-            WHERE
-                violating_ranges > 0
-        ),
-    report
-        AS (
-            SELECT
-                crdb_internal.zones.zone_id,
-                crdb_internal.zones.subzone_id,
-                target,
-                database_name,
-                table_name,
-                index_name,
-                partition_violations.type,
-                partition_violations.config,
-                partition_violations.violation_start,
-                partition_violations.violating_ranges
-            FROM
-                crdb_internal.zones, partition_violations
-            WHERE
-                crdb_internal.zones.zone_id
-                = partition_violations.zone_id
-        )
-SELECT * FROM report;
-~~~
-
-~~~
-  zone_id | subzone_id |                                             target                                             | database_name | table_name |                  index_name                   |    type    |        config        |         violation_start         | violating_ranges  
-+---------+------------+------------------------------------------------------------------------------------------------+---------------+------------+-----------------------------------------------+------------+----------------------+---------------------------------+------------------+
-       53 |          1 | PARTITION us_west OF INDEX movr.public.users@primary                                           | movr          | users      | primary                                       | constraint | -region=europe-west1 | 2019-10-21 20:28:40.79508+00:00 |                1  
-       53 |          2 | PARTITION us_east OF INDEX movr.public.users@primary                                           | movr          | users      | primary                                       | constraint | -region=europe-west1 | 2019-10-21 20:28:40.79508+00:00 |                1  
-       53 |          3 | PARTITION europe_west OF INDEX movr.public.users@primary                                       | movr          | users      | primary                                       | constraint | -region=europe-west1 | 2019-10-21 20:28:40.79508+00:00 |                1  
-       54 |          1 | PARTITION us_west OF INDEX movr.public.vehicles@primary                                        | movr          | vehicles   | primary                                       | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       54 |          2 | PARTITION us_west OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users          | movr          | vehicles   | vehicles_auto_index_fk_city_ref_users         | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       54 |          3 | PARTITION us_east OF INDEX movr.public.vehicles@primary                                        | movr          | vehicles   | primary                                       | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       54 |          4 | PARTITION us_east OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users          | movr          | vehicles   | vehicles_auto_index_fk_city_ref_users         | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       54 |          5 | PARTITION europe_west OF INDEX movr.public.vehicles@primary                                    | movr          | vehicles   | primary                                       | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       54 |          6 | PARTITION europe_west OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users      | movr          | vehicles   | vehicles_auto_index_fk_city_ref_users         | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          1 | PARTITION us_west OF INDEX movr.public.rides@primary                                           | movr          | rides      | primary                                       | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          2 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | movr          | rides      | rides_auto_index_fk_city_ref_users            | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          3 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          4 | PARTITION us_east OF INDEX movr.public.rides@primary                                           | movr          | rides      | primary                                       | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          5 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | movr          | rides      | rides_auto_index_fk_city_ref_users            | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          6 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          7 | PARTITION europe_west OF INDEX movr.public.rides@primary                                       | movr          | rides      | primary                                       | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          8 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users            | movr          | rides      | rides_auto_index_fk_city_ref_users            | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-       55 |          9 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles | constraint | +region=us-east1     | 2019-10-21 20:28:40.79508+00:00 |                1  
-(18 rows)
-~~~
-
-If you were to repeat this query at 60-second intervals, you would see that the number of results returned decreases and eventually falls to zero as the cluster rebalances the ranges to their new homes. Eventually you will see this output, which will tell you that the rebalancing has finished.
-
-~~~
-  zone_id | subzone_id | target | database_name | table_name | index_name | type | config | violation_start | violating_ranges  
-+---------+------------+--------+---------------+------------+------------+------+--------+-----------------+------------------+
-(0 rows)
-~~~
-
-### Find out which databases and tables have under-replicated ranges
-
-By default, this geo-distributed demo cluster will not have any [under-replicated ranges](ui-replication-dashboard.html#under-replicated-ranges).
-
-To force it into a state where some ranges are under-replicated, issue the following statement, which tells it to store 9 copies of each range underlying the `rides` table (by default [it stores 3](configure-replication-zones.html#num_replicas)).
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE rides CONFIGURE ZONE USING num_replicas=9;
-~~~
-
-Once the statement above executes, the cluster will rebalance so that it's storing 9 copies of each range underlying the `rides` table. During the time it takes for the rebalancing to occur, these ranges will be considered "under-replicated", since there are not yet as many copies (9) of each range as you have just specified.
-
-By default, the internal constraint conformance report runs once every minute. You can change that interval by modifying the `kv.replication_reports.interval` [cluster setting](cluster-settings.html).
-
-After the system constraint conformance report has run again, the following query should report under-replicated ranges:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM system.replication_stats WHERE under_replicated_ranges > 0;
-~~~
-
-~~~
-  zone_id | subzone_id | report_id | total_ranges | unavailable_ranges | under_replicated_ranges | over_replicated_ranges  
-+---------+------------+-----------+--------------+--------------------+-------------------------+------------------------+
-       55 |          0 |         3 |           28 |                  0 |                       6 |                      0  
-       55 |          3 |         3 |            9 |                  0 |                       9 |                      0  
-       55 |          6 |         3 |            9 |                  0 |                       9 |                      0  
-       55 |          9 |         3 |            9 |                  0 |                       9 |                      0  
-(4 rows)
-~~~
-
-To be more useful, we'd like to find out the database and table names where these under-replicated ranges live. To get that information we'll need to join the output of `system.replication_stats` report with the `crdb_internal.zones` table using a query like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-    under_replicated_zones
-        AS (
-            SELECT
-                zone_id, under_replicated_ranges
-            FROM
-                system.replication_stats
-            WHERE
-                under_replicated_ranges > 0
-        ),
-    report
-        AS (
-            SELECT
-                crdb_internal.zones.zone_id,
-                target,
-                range_name,
-                database_name,
-                table_name,
-                index_name,
-                under_replicated_zones.under_replicated_ranges
-            FROM
-                crdb_internal.zones, under_replicated_zones
-            WHERE
-                crdb_internal.zones.zone_id
-                = under_replicated_zones.zone_id
-        )
-SELECT * FROM report;
-~~~
-
-~~~
-  zone_id |                                             target                                             | range_name | database_name | table_name |                  index_name                   | under_replicated_ranges  
-+---------+------------------------------------------------------------------------------------------------+------------+---------------+------------+-----------------------------------------------+-------------------------+
-       55 | TABLE movr.public.rides                                                                        | NULL       | movr          | rides      | NULL                                          |                       9  
-       55 | TABLE movr.public.rides                                                                        | NULL       | movr          | rides      | NULL                                          |                       9  
-       55 | TABLE movr.public.rides                                                                        | NULL       | movr          | rides      | NULL                                          |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@primary                                           | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@primary                                           | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@primary                                           | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@primary                                           | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@primary                                           | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@primary                                           | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@primary                                       | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@primary                                       | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@primary                                       | NULL       | movr          | rides      | primary                                       |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users            | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users            | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users            | NULL       | movr          | rides      | rides_auto_index_fk_city_ref_users            |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles | NULL       | movr          | rides      | rides_auto_index_fk_vehicle_city_ref_vehicles |                       9  
-(30 rows)
-~~~
-
-### Find out which databases and tables have ranges in critical localities
-
-The `system.replication_critical_localities` report contains which of your localities (if any) are critical. A locality is "critical" for a range if all of the nodes in that locality becoming unreachable would cause the range to become unavailable. In other words, the locality contains a majority of the range's replicas.
-
-That said, a locality being critical is not necessarily a bad thing as long as you are aware of it. What matters is that [you configure the topology of your cluster to get the resiliency you expect](topology-patterns.html).
-
-By default, the [movr demo cluster](cockroach-demo.html#start-a-multi-region-demo-cluster-with-automatic-geo-partitioning) has some ranges in critical localities. This is expected because it follows the [geo-partitioned replicas topology pattern](topology-geo-partitioned-replicas.html), which ties data for latency-sensitive queries to specific geographies at the cost of data unavailability during a region-wide failure.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM system.replication_critical_localities WHERE at_risk_ranges > 0;
-~~~
-
-~~~
-  zone_id | subzone_id |      locality       | report_id | at_risk_ranges  
-+---------+------------+---------------------+-----------+----------------+
-       53 |          1 | region=us-west1     |         2 |              3  
-       53 |          2 | region=us-east1     |         2 |              3  
-       53 |          3 | region=europe-west1 |         2 |              3  
-       54 |          2 | region=us-west1     |         2 |              6  
-       54 |          4 | region=us-east1     |         2 |              6  
-       54 |          6 | region=europe-west1 |         2 |              6  
-       55 |          3 | region=us-west1     |         2 |              9  
-       55 |          6 | region=us-east1     |         2 |              9  
-       55 |          9 | region=europe-west1 |         2 |              9  
-       56 |          1 | region=us-west1     |         2 |              3  
-       56 |          2 | region=us-east1     |         2 |              3  
-       56 |          3 | region=europe-west1 |         2 |              3  
-       58 |          1 | region=us-west1     |         2 |              3  
-       58 |          2 | region=us-east1     |         2 |              3  
-       58 |          3 | region=europe-west1 |         2 |              3  
-(15 rows)
-~~~
-
-To be more useful, we'd like to find out the database and table names where these ranges live that are at risk of unavailability in the event of a locality becoming unreachable. To get that information we'll need to join the output of `system.replication_critical_localities` report with the `crdb_internal.zones` table using a query like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	at_risk_zones AS (
-			SELECT
-				zone_id, locality, at_risk_ranges
-			FROM
-				system.replication_critical_localities
-			WHERE
-				at_risk_ranges > 0
-		),
-	report AS (
-			SELECT
-				crdb_internal.zones.zone_id,
-				target,
-				database_name,
-				table_name,
-				index_name,
-				at_risk_zones.at_risk_ranges
-			FROM
-				crdb_internal.zones, at_risk_zones
-			WHERE
-				crdb_internal.zones.zone_id
-				= at_risk_zones.zone_id
-		)
-SELECT DISTINCT * FROM report;
-~~~
-
-~~~
-  zone_id |                                             target                                             | database_name |         table_name         |                  index_name                   | at_risk_ranges  
-+---------+------------------------------------------------------------------------------------------------+---------------+----------------------------+-----------------------------------------------+----------------+
-       53 | PARTITION us_west OF INDEX movr.public.users@primary                                           | movr          | users                      | primary                                       |              3  
-       53 | PARTITION us_east OF INDEX movr.public.users@primary                                           | movr          | users                      | primary                                       |              3  
-       53 | PARTITION europe_west OF INDEX movr.public.users@primary                                       | movr          | users                      | primary                                       |              3  
-       54 | PARTITION us_west OF INDEX movr.public.vehicles@primary                                        | movr          | vehicles                   | primary                                       |              6  
-       54 | PARTITION us_west OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users          | movr          | vehicles                   | vehicles_auto_index_fk_city_ref_users         |              6  
-       54 | PARTITION us_east OF INDEX movr.public.vehicles@primary                                        | movr          | vehicles                   | primary                                       |              6  
-       54 | PARTITION us_east OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users          | movr          | vehicles                   | vehicles_auto_index_fk_city_ref_users         |              6  
-       54 | PARTITION europe_west OF INDEX movr.public.vehicles@primary                                    | movr          | vehicles                   | primary                                       |              6  
-       54 | PARTITION europe_west OF INDEX movr.public.vehicles@vehicles_auto_index_fk_city_ref_users      | movr          | vehicles                   | vehicles_auto_index_fk_city_ref_users         |              6  
-       55 | PARTITION us_west OF INDEX movr.public.rides@primary                                           | movr          | rides                      | primary                                       |              9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | movr          | rides                      | rides_auto_index_fk_city_ref_users            |              9  
-       55 | PARTITION us_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | movr          | rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles |              9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@primary                                           | movr          | rides                      | primary                                       |              9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users                | movr          | rides                      | rides_auto_index_fk_city_ref_users            |              9  
-       55 | PARTITION us_east OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles     | movr          | rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles |              9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@primary                                       | movr          | rides                      | primary                                       |              9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_city_ref_users            | movr          | rides                      | rides_auto_index_fk_city_ref_users            |              9  
-       55 | PARTITION europe_west OF INDEX movr.public.rides@rides_auto_index_fk_vehicle_city_ref_vehicles | movr          | rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles |              9  
-       56 | PARTITION us_west OF INDEX movr.public.vehicle_location_histories@primary                      | movr          | vehicle_location_histories | primary                                       |              3  
-       56 | PARTITION us_east OF INDEX movr.public.vehicle_location_histories@primary                      | movr          | vehicle_location_histories | primary                                       |              3  
-       56 | PARTITION europe_west OF INDEX movr.public.vehicle_location_histories@primary                  | movr          | vehicle_location_histories | primary                                       |              3  
-       58 | PARTITION us_west OF INDEX movr.public.user_promo_codes@primary                                | movr          | user_promo_codes           | primary                                       |              3  
-       58 | PARTITION us_east OF INDEX movr.public.user_promo_codes@primary                                | movr          | user_promo_codes           | primary                                       |              3  
-       58 | PARTITION europe_west OF INDEX movr.public.user_promo_codes@primary                            | movr          | user_promo_codes           | primary                                       |              3  
-(24 rows)
-~~~
-
-To give another example, let's say your cluster were similar to the one shown above, but configured with [tiered localities](cockroach-start.html#locality) such that you had split `us-east1` into `{region=us-east1,dc=dc1, region=us-east1,dc=dc2, region=us-east1,dc=dc3}`. In that case, you wouldn't expect any DC to be critical, because the cluster would "diversify" each range's location as much as possible across data centers. In such a situation, if you were to see a DC identified as a critical locality, you'd be surprised and you'd take some action. For example, perhaps the diversification process is failing because some localities are filled to capacity. If there is no disk space free in a locality, your cluster cannot move replicas there.
-
-## See also
-
-- [Configure Replication Zones](configure-replication-zones.html)
-- [Partitioning](partitioning.html)
-- [`PARTITION BY`](partition-by.html)
-- [`CONFIGURE ZONE`](configure-zone.html)
-- [Start a node](cockroach-start.html)
diff --git a/src/current/v20.2/query-spatial-data.md b/src/current/v20.2/query-spatial-data.md
deleted file mode 100644
index 1b027fc0b8a..00000000000
--- a/src/current/v20.2/query-spatial-data.md
+++ /dev/null
@@ -1,150 +0,0 @@
----
-title: Query Spatial Data
-summary: How to query a spatial dataset imported into CockroachDB.
-toc: true
----
-
-This page has instructions for querying spatial data imported into CockroachDB. On this page, we use a sample [Shapefile dataset](spatial-glossary.html#file-formats) from the National Oceanic and Atmospheric Administration.
-
-## Before you begin
-
-- Install a build of CockroachDB with support for spatial data by following the instructions at [Install CockroachDB](install-cockroachdb.html).
-
-- [Start a local insecure cluster](start-a-local-cluster.html) and connect to that cluster from a [SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    cockroach sql --insecure --host=localhost --port=26257
-    ~~~
-
-    Leave this shell open for use in the example below.
-
-- Import some sample spatial data into CockroachDB by following the instructions at [Migrate from Shapefiles](migrate-from-shapefiles.html).
-
-## Query spatial data
-
-After you have imported [the sample tornado data into CockroachDB](migrate-from-shapefiles.html), you can query the spatial data from SQL.
-
-For example, we may be interested in the [1999 Oklahoma tornado outbreak](https://en.wikipedia.org/wiki/1999_Oklahoma_tornado_outbreak), which is described by Wikipedia as:
-
-> a significant tornado outbreak that affected much of the Central and parts of the Eastern United States, with the highest record-breaking wind speeds of 302 ± 22 mph (486 ± 35 km/h). During this week-long event, 154 tornadoes touched down (including one in Canada), more than half of them on May 3 and 4 when activity reached its peak over Oklahoma, Kansas, Nebraska, Texas, and Arkansas.
-
-According to the wiki page linked above, there were 152 tornadoes confirmed between May 2-8, 1999 (one in Canada).
-
-We can try to verify this number against the NWS's tornado data set with the following query:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT COUNT(*) FROM "1950-2018-torn-initpoint" WHERE yr = 1999 AND mo = 5 AND dy >= 02 AND dy <= 08;
-~~~
-
-~~~
-  count
----------
-    150
-(1 row)
-~~~
-
-It might be interesting to look into why these numbers are different!
-
-Next, let's get a list of starting points for all of the tornadoes in the outbreak that started in Oklahoma:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_AsText(geom) FROM "1950-2018-torn-initpoint" WHERE yr = 1999 AND st = 'OK' AND mo = 5 AND dy > 02 AND dy <= 08;
-~~~
-
-~~~
-                    st_astext
---------------------------------------------------
-  POINT (-98.379999999999995 34.770000000000003)
-  POINT (-98.329999999999998 34.780000000000001)
-  POINT (-98.319999999999993 34.880000000000003)
-  POINT (-98.230000000000004 34.920000000000002)
-  POINT (-99.019999999999996 34.799999999999997)
-  POINT (-98.25 35.030000000000001)
-  POINT (-98.120000000000005 34.969999999999999)
-  POINT (-98.030000000000001 35.049999999999997)
-  POINT (-97.980000000000004 35.079999999999998)
-  POINT (-98.569999999999993 34.950000000000003)
-  POINT (-97.849999999999994 35.130000000000003)
-  POINT (-98.430000000000007 34.979999999999997)
-  POINT (-98.329999999999998 35.07)
-  POINT (-98.019999999999996 35.719999999999999)
-  POINT (-97.980000000000004 35.719999999999999)
-  POINT (-97.599999999999994 35.299999999999997)
-  POINT (-98.280000000000001 35.119999999999997)
-  POINT (-98.200000000000003 35.170000000000002)
-  POINT (-97.400000000000006 35.399999999999999)
-  POINT (-98.099999999999994 35.18)
-  POINT (-98.069999999999993 35.270000000000003)
-  POINT (-98.129999999999995 35.270000000000003)
-  POINT (-98.019999999999996 35.32)
-  POINT (-97.299999999999997 35.469999999999999)
-  POINT (-98 35.270000000000003)
-  POINT (-97.969999999999999 35.399999999999999)
-  POINT (-97.219999999999999 35.549999999999997)
-  POINT (-97.920000000000002 35.420000000000002)
-  POINT (-97.900000000000006 35.43)
-  POINT (-97.230000000000004 35.579999999999998)
-  POINT (-98.370000000000005 35.880000000000003)
-  POINT (-97.920000000000002 35.520000000000003)
-  POINT (-98.280000000000001 35.649999999999999)
-  POINT (-97.849999999999994 35.530000000000001)
-  POINT (-97.200000000000003 35.130000000000003)
-  POINT (-97.780000000000001 35.649999999999999)
-  POINT (-98.030000000000001 35.850000000000001)
-  POINT (-97.719999999999999 35.700000000000003)
-  POINT (-98.030000000000001 35.880000000000003)
-  POINT (-97 35.369999999999997)
-  POINT (-97.680000000000007 35.780000000000001)
-  POINT (-97.950000000000003 35.93)
-  POINT (-98.170000000000002 35.850000000000001)
-  POINT (-97.680000000000007 35.880000000000003)
-  POINT (-97.879999999999995 36.020000000000003)
-  POINT (-97.950000000000003 36.020000000000003)
-  POINT (-98 35.5)
-  POINT (-97.879999999999995 36.100000000000001)
-  POINT (-97.969999999999999 35.549999999999997)
-  POINT (-96.799999999999997 35.649999999999999)
-  POINT (-97.650000000000006 36.119999999999997)
-  POINT (-98.25 36.299999999999997)
-  POINT (-97.719999999999999 35.780000000000001)
-  POINT (-97.780000000000001 35.850000000000001)
-  POINT (-97.599999999999994 35.920000000000002)
-  POINT (-97.420000000000002 36.030000000000001)
-  POINT (-96.129999999999995 35.979999999999997)
-  POINT (-96.069999999999993 36.020000000000003)
-  POINT (-95.650000000000006 35.630000000000003)
-  POINT (-95.180000000000007 35.950000000000003)
-  POINT (-94.730000000000004 36)
-  POINT (-97.400000000000006 35.32)
-  POINT (-96.400000000000006 36.469999999999999)
-  POINT (-95.579999999999998 34.579999999999998)
-  POINT (-95.219999999999999 34.880000000000003)
-  POINT (-95 35.130000000000003)
-  POINT (-94.780000000000001 35.299999999999997)
-  POINT (-94.700000000000003 35.43)
-  POINT (-94.549999999999997 35.57)
-(69 rows)
-~~~
-
-We can see that almost half of all of the tornadoes in this outbreak began in Oklahoma.
-
-It might be interesting to draw these points on a map. The image below shows the points from the query above drawn as a simple polygon on a map of Oklahoma. The boxes around the polygon show the [spatial index](spatial-indexes.html) coverings for the polygon.
-
-<img width="100%" src="{{ 'images/v20.2/geospatial/1999-oklahoma-tornado-outbreak-map.png' | relative_url }}" alt="1999 Oklahoma tornado outbreak map view">
-
-(Map data &copy; 2020 Google)
-
-## See also
-
-- [Spatial Features](spatial-features.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial & GIS Glossary of Terms](spatial-glossary.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
diff --git a/src/current/v20.2/recommended-production-settings.md b/src/current/v20.2/recommended-production-settings.md
deleted file mode 100644
index f51734cfc8f..00000000000
--- a/src/current/v20.2/recommended-production-settings.md
+++ /dev/null
@@ -1,581 +0,0 @@
----
-title: Production Checklist
-summary: Recommended settings for production deployments of CockroachDB.
-toc: true
-toc_not_nested: true
----
-
-This page provides important recommendations for production deployments of CockroachDB.
-
-## Topology
-
-When planning your deployment, it's important to carefully review and choose the [topology patterns](topology-patterns.html) that best meet your latency and resiliency requirements. This is especially crucial for multi-region deployments.
-
-Also keep in mind some basic topology recommendations:
-
-{% include {{ page.version.version }}/prod-deployment/topology-recommendations.md %}
-
-## Software
-
-We recommend running a [glibc](https://www.gnu.org/software/libc/)-based Linux distribution and Linux kernel version from the last 5 years, such as [Ubuntu](https://ubuntu.com/), [Red Hat Enterprise Linux (RHEL)](https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux), [CentOS](https://www.centos.org/), or [Container-Optimized OS](https://cloud.google.com/container-optimized-os/docs).
-
-## Hardware
-
-{{site.data.alerts.callout_info}}
-Mentions of "CPU resources" refer to vCPUs, which are also known as hyperthreads.
-{{site.data.alerts.end}}
-
-### Basic hardware recommendations
-
-This hardware guidance is meant to be platform agnostic and can apply to bare-metal, containerized, and orchestrated deployments. Also see our [cloud-specific](#cloud-specific-recommendations) recommendations.
-
-| Value | Recommendation | Reference
-|-------|----------------|----------
-| RAM per vCPU | 4 GiB | [CPU and memory](#cpu-and-memory)
-| Capacity per vCPU | 150 GiB | [Storage](#storage)
-| IOPS per vCPU | 500 | [Disk I/O](#disk-i-o)
-| MB/s per vCPU | 30 | [Disk I/O](#disk-i-o)
-
-Before deploying to production, test and tune your hardware setup for your application workload. For example, read-heavy and write-heavy workloads will place different emphases on [CPU](#cpu-and-memory), [RAM](#cpu-and-memory), [storage](#storage), [I/O](#disk-i-o), and [network](#networking) capacity.
-
-#### CPU and memory
-
-Each node should have **at least 2 vCPUs**. For best performance, we recommend at least 4 vCPUs per node. Provision **4 GiB of RAM per vCPU**.
-
-- To optimize for throughput, use larger nodes with up to 32 vCPUs. To further increase throughput, add more nodes to the cluster instead of increasing node size.
-
-      {{site.data.alerts.callout_info}}
-      Based on internal testing, 32 vCPUs is a sweet spot for OLTP workloads. It is not a hard limit, especially for deployments using physical hardware rather than cloud instances.
-      {{site.data.alerts.end}}
-
-      {{site.data.alerts.callout_info}}
-      The benefits to having more RAM decrease as the number of vCPUs increases.
-      {{site.data.alerts.end}}
-
-- To optimize for resiliency, use many smaller nodes instead of fewer larger nodes. Recovery from a failed node is faster when data is spread across more nodes.
-
-- To optimize for the support of large numbers of tables, increase the amount of RAM. For more information, see [Quantity of tables and other schema objects](schema-design-overview.html#quantity-of-tables-and-other-schema-objects). Supporting a large number of rows is a matter of [Storage](#storage).
-
-- Avoid "burstable" or "shared-core" virtual machines that limit the load on CPU resources.
-
-- To ensure consistent SQL performance, make sure all nodes have a uniform configuration.
-
-- Disable Linux memory swapping. CockroachDB manages its own [memory caches](#cache-and-sql-memory-size) (configured via the `--cache` and `--max-sql-memory` flags), independent of the operating system. Over-allocating memory on production machines can lead to unexpected performance issues when pages have to be read back into memory.
-
-{{site.data.alerts.callout_info}}
-Under-provisioning RAM results in reduced performance (due to reduced caching and increased spilling to disk), and in some cases can cause OOM crashes. Under-provisioning CPU generally results in poor performance, and in extreme cases can lead to cluster unavailability. For more information, see [capacity planning issues](cluster-setup-troubleshooting.html#capacity-planning-issues) and [memory issues](cluster-setup-troubleshooting.html#memory-issues).
-{{site.data.alerts.end}}
-
-#### Storage
-
-We recommend provisioning volumes with **150 GiB per vCPU**. It's fine to have less storage per vCPU if your workload does not have significant capacity needs.
-
-- The maximum recommended storage capacity per node is 2.5 TiB, regardless of the number of vCPUs.
-
-- Use dedicated volumes for the CockroachDB [store](architecture/storage-layer.html). Do not share the store volume with any other I/O activity.
-
-    We suggest storing CockroachDB [log files](debug-and-error-logs.html) in a separate volume from CockroachDB data so that logging is not impacted by I/O throttling.
-
-- The recommended Linux filesystems are [ext4](https://ext4.wiki.kernel.org/index.php/Main_Page) and [XFS](https://xfs.wiki.kernel.org/).
-
-- Always keep some of your disk capacity free on production. Doing so accommodates fluctuations in routine database operations and supports continuous data growth.
-
-    We strongly recommend [monitoring](monitoring-and-alerting.html#node-is-running-low-on-disk-space) your storage utilization and rate of growth, and taking action to add capacity well before you hit the limit.
-
-- Place a [ballast file](cockroach-debug-ballast.html) in each node's storage directory. In the unlikely case that a node runs out of disk space and shuts down, you can delete the ballast file to free up enough space to be able to restart the node.
-
-- Use [zone configs](configure-replication-zones.html) to increase the replication factor from 3 (the default) to 5 (across at least 5 nodes).
-
-    This is especially recommended if you are using local disks with no RAID protection rather than a cloud provider's network-attached disks that are often replicated under the hood, because local disks have a greater risk of failure. You can do this for the [entire cluster](configure-replication-zones.html#edit-the-default-replication-zone) or for specific [databases](configure-replication-zones.html#create-a-replication-zone-for-a-database), [tables](configure-replication-zones.html#create-a-replication-zone-for-a-table), or [rows](configure-replication-zones.html#create-a-replication-zone-for-a-partition) (Enterprise-only).
-
-{{site.data.alerts.callout_info}}
-Underprovisioning storage leads to node crashes when the disks fill up. Once this has happened, it is difficult to recover from. To prevent your disks from filling up, provision enough storage for your workload, monitor your disk usage, and use a ballast file as described above. For more information, see [capacity planning issues](cluster-setup-troubleshooting.html#capacity-planning-issues) and [storage issues](cluster-setup-troubleshooting.html#storage-issues).
-{{site.data.alerts.end}}
-
-##### Disk I/O
-
-Disks must be able to achieve **500 IOPS and 30 MB/s per vCPU**.
-
-- Monitor IOPS for higher service times. If they exceed 1-5 ms, you will need to add more devices or expand the cluster to reduce the disk latency. To monitor IOPS, use tools such as `iostat` (part of `sysstat`).
-
-- To calculate IOPS, use [sysbench](https://github.com/akopytov/sysbench). If IOPS decrease, add more nodes to your cluster to increase IOPS.
-
-- The optimal configuration for striping more than one device is [RAID 10](https://en.wikipedia.org/wiki/Nested_RAID_levels#RAID_10_(RAID_1+0)). RAID 0 and 1 are also acceptable from a performance perspective.
-
-{{site.data.alerts.callout_info}}
-Disk I/O especially affects performance on write-heavy workloads. For more context, see [Reads and Writes in CockroachDB](architecture/reads-and-writes-overview.html#write-scenario).
-{{site.data.alerts.end}}
-
-##### Node density testing configuration
-
-In a narrowly-scoped test, we were able to successfully store 4.32 TiB of logical data per node. The results of this test may not be applicable to your specific situation; testing with your workload is _strongly_ recommended before using it in a production environment.
-
-These results were achieved using the ["bank" workload](cockroach-workload.html#bank-workload) running on AWS using 6x c5d.4xlarge nodes, each with 5 TiB of gp2 EBS storage.
-
-Results:
-
-| Value                 | Result          |
-|-----------------------+-----------------|
-| vCPU per Node         | 16              |
-| Logical Data per Node | 4.32 TiB        |
-| RAM per Node          | 32 GiB          |
-| Data per Core         | ~270 GiB / vCPU |
-| Data per RAM          | ~135 GiB / GiB  |
-
-### Cloud-specific recommendations
-
-Cockroach Labs recommends the following cloud-specific configurations based on our own [internal testing](https://www.cockroachlabs.com/blog/2018_cloud_report/). Before using configurations not recommended here, be sure to test them exhaustively.
-
-#### AWS
-
-- Use `m` (general purpose) or `c` (compute-optimized) [instances](https://aws.amazon.com/ec2/instance-types/).
-
-    For example, Cockroach Labs has used `c5d.4xlarge` (16 vCPUs and 32 GiB of RAM per instance, EBS) for [performance benchmarking](performance-benchmarking-with-tpcc-small.html). Note that the instance type depends on whether EBS is used or not. If you're using EBS, use a `c5` instance.
-
-    {{site.data.alerts.callout_danger}}
-    Do not use ["burstable" `t` instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/burstable-performance-instances.html), which limit the load on CPU resources.
-    {{site.data.alerts.end}}
-
-- Use `c5` instances with EBS as a primary AWS configuration. To simulate bare-metal deployments, use `c5d` with [SSD Instance Store volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ssd-instance-store.html).
-
-    [Provisioned IOPS SSD-backed (`io1`) EBS volumes](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html#EBSVolumeTypes_piops) need to have IOPS provisioned, which can be very expensive. Cheaper `gp2` volumes can be used instead, if your performance needs are less demanding. Allocating more disk space than you will use can improve performance of `gp2` volumes.
-
-#### Azure
-
-- Use compute-optimized [F-series](https://docs.microsoft.com/en-us/azure/virtual-machines/fsv2-series) VMs.
-    For example, Cockroach Labs has used `Standard_F16s_v2` VMs (16 vCPUs and 32 GiB of RAM per VM) for internal testing.
-
-    {{site.data.alerts.callout_danger}}
-    Do not use ["burstable" B-series](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/b-series-burstable) VMs, which limit the load on CPU resources. Also, Cockroach Labs has experienced data corruption issues on A-series VMs and irregular disk performance on D-series VMs, so we recommend avoiding those as well.
-    {{site.data.alerts.end}}
-
-- Use [Premium Storage](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/premium-storage) or local SSD storage with a Linux filesystem such as `ext4` (not the Windows `ntfs` filesystem). Note that [the size of a Premium Storage disk affects its IOPS](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/premium-storage#premium-storage-disk-limits).
-
-- If you choose local SSD storage, on reboot, the VM can come back with the `ntfs` filesystem. Be sure your automation monitors for this and reformats the disk to the Linux filesystem you chose initially.
-
-#### Digital Ocean
-
-- Use any [droplets](https://www.digitalocean.com/pricing/) except standard droplets with only 1 GiB of RAM, which is below our minimum requirement. All Digital Ocean droplets use SSD storage.
-
-#### GCP
-
-- Use `n2-standard` or `n2-highcpu` [predefined VMs](https://cloud.google.com/compute/pricing#predefined_machine_types), or [custom VMs](https://cloud.google.com/compute/pricing#custommachinetypepricing).
-
-    For example, Cockroach Labs has used `n2-standard-16` (16 vCPUs and 64 GiB of RAM per VM, local SSD) for performance benchmarking.
-
-    {{site.data.alerts.callout_danger}}
-    Do not use `f1` or `g1` [shared-core machines](https://cloud.google.com/compute/docs/machine-types#sharedcore), which limit the load on CPU resources.
-    {{site.data.alerts.end}}
-
-- Use [Local SSDs](https://cloud.google.com/compute/docs/disks/#localssds) or [SSD persistent disks](https://cloud.google.com/compute/docs/disks/#pdspecs). Note that [the IOPS of SSD persistent disks depends both on the disk size and number of vCPUs on the machine](https://cloud.google.com/compute/docs/disks/performance#optimizessdperformance).
-- `nobarrier` can be used with SSDs, but only if it has battery-backed write cache. Without one, data can be corrupted in the event of a crash.
-
-    Cockroach Labs conducts most of our [internal performance tests](https://www.cockroachlabs.com/blog/2018_cloud_report/) using `nobarrier` to demonstrate the best possible performance, but understand that not all use cases can support this option.
-
-## Security
-
-An insecure cluster comes with serious risks:
-
-- Your cluster is open to any client that can access any node's IP addresses.
-- Any user, even `root`, can log in without providing a password.
-- Any user, connecting as `root`, can read or write any data in your cluster.
-- There is no network encryption or authentication, and thus no confidentiality.
-
-Therefore, to deploy CockroachDB in production, it is strongly recommended to [use TLS certificates to authenticate](authentication.html) the identity of nodes and clients and to encrypt in-flight data between nodes and clients. You can use either the built-in [`cockroach cert` commands](cockroach-cert.html) or [`openssl` commands](create-security-certificates-openssl.html) to generate security certificates for your deployment. Regardless of which option you choose, you'll need the following files:
-
-- A certificate authority (CA) certificate and key, used to sign all of the other certificates.
-- A separate certificate and key for each node in your deployment, with the common name `node`.
-- A separate certificate and key for each client and user you want to connect to your nodes, with the common name set to the username. The default user is `root`.
-
-    Alternatively, CockroachDB supports [password authentication](authentication.html#client-authentication), although we typically recommend using client certificates instead.
-
-For more information, see the [Security Overview](security-overview.html).
-
-## Networking
-
-### Networking flags
-
-When [starting a node](cockroach-start.html), two main flags are used to control its network connections:
-
-- `--listen-addr` determines which address(es) to listen on for connections from other nodes and clients.
-- `--advertise-addr` determines which address to tell other nodes to use.
-
-The effect depends on how these two flags are used in combination:
-
-| | `--listen-addr` not specified | `--listen-addr` specified |
-|-|----------------------------|------------------------|
-| **`--advertise-addr` not specified** | Node listens on all of its IP addresses on port `26257` and advertises its canonical hostname to other nodes. | Node listens on the IP address/hostname and port specified in `--listen-addr` and advertises this value to other nodes.
-| **`--advertise-addr` specified** | Node listens on all of its IP addresses on port `26257` and advertises the value specified in `--advertise-addr` to other nodes. **Recommended for most cases.** | Node listens on the IP address/hostname and port specified in `--listen-addr` and advertises the value specified in `--advertise-addr` to other nodes. If the `--advertise-addr` port number is different than the one used in `--listen-addr`, port forwarding is required.
-
-{{site.data.alerts.callout_success}}
-When using hostnames, make sure they resolve properly (e.g., via DNS or `etc/hosts`). In particular, be careful about the value advertised to other nodes, either via `--advertise-addr` or via `--listen-addr` when `--advertise-addr` is not specified.
-{{site.data.alerts.end}}
-
-### Cluster on a single network
-
-When running a cluster on a single network, the setup depends on whether the network is private. In a private network, machines have addresses restricted to the network, not accessible to the public internet. Using these addresses is more secure and usually provides lower latency than public addresses.
-
-Private? | Recommended setup
----------|------------------
-Yes | Start each node with `--listen-addr` set to its private IP address and do not specify `--advertise-addr`. This will tell other nodes to use the private IP address advertised. Load balancers/clients in the private network must use it as well.
-No | Start each node with `--advertise-addr` set to a stable public IP address that routes to the node and do not specify `--listen-addr`. This will tell other nodes to use the specific IP address advertised, but load balancers/clients will be able to use any address that routes to the node.<br><br>If load balancers/clients are outside the network, also configure firewalls to allow external traffic to reach the cluster.
-
-### Cluster spanning multiple networks
-
-When running a cluster across multiple networks, the setup depends on whether nodes can reach each other across the networks.
-
-Nodes reachable across networks? | Recommended setup
----------------------------------|------------------
-Yes | This is typical when all networks are on the same cloud. In this case, use the relevant [single network setup](#cluster-on-a-single-network) above.
-No | This is typical when networks are on different clouds. In this case, set up a [VPN](https://en.wikipedia.org/wiki/Virtual_private_network), [VPC](https://en.wikipedia.org/wiki/Virtual_private_cloud), [NAT](https://en.wikipedia.org/wiki/Network_address_translation), or another such solution to provide unified routing across the networks. Then start each node with `--advertise-addr` set to the address that is reachable from other networks and do not specify `--listen-addr`. This will tell other nodes to use the specific IP address advertised, but load balancers/clients will be able to use any address that routes to the node.<br><br>Also, if a node is reachable from other nodes in its network on a private or local address, set [`--locality-advertise-addr`](cockroach-start.html#networking) to that address. This will tell nodes within the same network to prefer the private or local address to improve performance. Note that this feature requires that each node is started with the [`--locality`](cockroach-start.html#locality) flag. For more details, see this [example](cockroach-start.html#start-a-multi-node-cluster-across-private-networks).
-
-## Load balancing
-
-Each CockroachDB node is an equally suitable SQL gateway to a cluster, but to ensure client performance and reliability, it's important to use load balancing:
-
-- **Performance:** Load balancers spread client traffic across nodes. This prevents any one node from being overwhelmed by requests and improves overall cluster performance (queries per second).
-
-- **Reliability:** Load balancers decouple client health from the health of a single CockroachDB node. To ensure that traffic is not directed to failed nodes or nodes that are not ready to receive requests, load balancers should use [CockroachDB's readiness health check](monitoring-and-alerting.html#health-ready-1).
-    {{site.data.alerts.callout_success}}
-    With a single load balancer, client connections are resilient to node failure, but the load balancer itself is a point of failure. It's therefore best to make load balancing resilient as well by using multiple load balancing instances, with a mechanism like floating IPs or DNS to select load balancers for clients.
-    {{site.data.alerts.end}}
-
-For guidance on load balancing, see the tutorial for your deployment environment:
-
-Environment | Featured Approach
-------------|---------------------
-[On-Premises](deploy-cockroachdb-on-premises.html#step-6-set-up-load-balancing) | Use HAProxy.
-[AWS](deploy-cockroachdb-on-aws.html#step-4-set-up-load-balancing) | Use Amazon's managed load balancing service.
-[Azure](deploy-cockroachdb-on-microsoft-azure.html#step-4-set-up-load-balancing) | Use Azure's managed load balancing service.
-[Digital Ocean](deploy-cockroachdb-on-digital-ocean.html#step-3-set-up-load-balancing) | Use Digital Ocean's managed load balancing service.
-[GCP](deploy-cockroachdb-on-google-cloud-platform.html#step-4-set-up-load-balancing) | Use GCP's managed TCP proxy load balancing service.
-
-## Connection pooling
-
-Creating the appropriate size pool of connections is critical to gaining maximum performance in an application. Too few connections in the pool will result in high latency as each operation waits for a connection to open up. But adding too many connections to the pool can also result in high latency as each connection thread is being run in parallel by the system. The time it takes for many threads to complete in parallel is typically higher than the time it takes a smaller number of threads to run sequentially.
-
-For guidance on sizing, validating, and using connection pools with CockroachDB, see [Use Connection Pools](connection-pooling.html).
-
-## Monitoring and alerting
-
-{% include {{ page.version.version }}/prod-deployment/monitor-cluster.md %}
-
-## Clock synchronization
-
-{% include {{ page.version.version }}/faq/clock-synchronization-effects.md %}
-
-## Cache and SQL memory size
-
-Each node has a default cache size of `128MiB` that is passively consumed. The default was chosen to facilitate development and testing, where users are likely to run multiple CockroachDB nodes on a single machine. When running a production cluster with one node per host, we recommend increasing this value.
-
-Each node has a default SQL memory size of `25%`. This memory is used as-needed by active operations to store temporary data for SQL queries.
-
-- Increasing a node's **cache size** will improve the node's read performance.
-- Increasing a node's **SQL memory size** will increase the number of simultaneous client connections it allows, as well as the node's capacity for in-memory processing of rows when using `ORDER BY`, `GROUP BY`, `DISTINCT`, joins, and window functions.
-
-To manually increase a node's cache size and SQL memory size, start the node using the [`--cache`](cockroach-start.html#flags) and [`--max-sql-memory`](cockroach-start.html#flags) flags:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach start --cache=.25 --max-sql-memory=.25 <other start flags>
-~~~
-
-{{site.data.alerts.callout_danger}}
-Avoid setting `--cache` and `--max-sql-memory` to a combined value of more than 75% of a machine's total RAM. Doing so increases the risk of memory-related failures. Also, since CockroachDB manages its own memory caches, disable Linux memory swapping to avoid over-allocating memory.
-{{site.data.alerts.end}}
-
-## Dependencies
-
-The [CockroachDB binary for Linux](install-cockroachdb-linux.html) depends on the following libraries:
-
-Library | Description
------------|------------
-[`glibc`](https://www.gnu.org/software/libc/libc.html) | The standard C library.<br><br>If you build CockroachDB from source, rather than use the official CockroachDB binary for Linux, you can use any C standard library, including MUSL, the C standard library used on Alpine.
-`libncurses` | Required by the [built-in SQL shell](cockroach-sql.html).
-[`tzdata`](https://www.iana.org/time-zones) | Required by certain features of CockroachDB that use time zone data, for example, to support using location-based names as time zone identifiers. This library is sometimes called `tz` or `zoneinfo`. On Windows, time zone data is derived from a `zoneinfo.zip` file.<br><br>If a machine running a CockroachDB node is missing this time zone data, the node will not be able to start. For workaround steps, see this [known limitation](known-limitations.html#location-based-time-zone-names).
-
-These libraries are found by default on nearly all Linux distributions, with Alpine as the notable exception, but it's nevertheless important to confirm that they are installed and kept up-to-date. For the time zone data in particular, it's important for all nodes to have the same version; when updating the library, do so as quickly as possible across all nodes.
-
-{{site.data.alerts.callout_info}}
-In Docker-based deployments of CockroachDB, these dependencies do not need to be manually addressed. The Docker image for CockroachDB includes them and keeps them up to date with each release of CockroachDB.
-{{site.data.alerts.end}}
-
-## File descriptors limit
-
-CockroachDB can use a large number of open file descriptors, often more than is available by default. Therefore, please note the following recommendations.
-
-For each CockroachDB node:
-
-- At a **minimum**, the file descriptors limit must be `1956` (1700 per store plus 256 for networking). If the limit is below this threshold, the node will not start.
-- It is **recommended** to set the file descriptors limit to `unlimited`; otherwise, the recommended limit is at least `15000` (10000 per store plus 5000 for networking). This higher limit ensures performance and accommodates cluster growth.
-- When the file descriptors limit is not high enough to allocate the recommended amounts, CockroachDB allocates 10000 per store and the rest for networking; if this would result in networking getting less than 256, CockroachDB instead allocates 256 for networking and evenly splits the rest across stores.
-
-### Increase the file descriptors limit
-
-<script>
-$(document).ready(function(){
-
-    //detect os and display corresponding tab by default
-    if (navigator.appVersion.indexOf("Mac")!=-1) {
-        $('#os-tabs').find('button').removeClass('current');
-        $('#mac').addClass('current');
-        toggleMac();
-    }
-    if (navigator.appVersion.indexOf("Linux")!=-1) {
-        $('#os-tabs').find('button').removeClass('current');
-        $('#linux').addClass('current');
-        toggleLinux();
-    }
-    if (navigator.appVersion.indexOf("Win")!=-1) {
-        $('#os-tabs').find('button').removeClass('current');
-        $('#windows').addClass('current');
-        toggleWindows();
-    }
-
-    var install_option = $('.install-option'),
-        install_button = $('.install-button');
-
-    install_button.on('click', function(e){
-      e.preventDefault();
-      var hash = $(this).prop("hash");
-
-      install_button.removeClass('current');
-      $(this).addClass('current');
-      install_option.hide();
-      $(hash).show();
-
-    });
-
-    //handle click event for os-tab buttons
-    $('#os-tabs').on('click', 'button', function(){
-        $('#os-tabs').find('button').removeClass('current');
-        $(this).addClass('current');
-
-        if($(this).is('#mac')){ toggleMac(); }
-        if($(this).is('#linux')){ toggleLinux(); }
-        if($(this).is('#windows')){ toggleWindows(); }
-    });
-
-    function toggleMac(){
-        $(".mac-button:first").trigger('click');
-        $("#macinstall").show();
-        $("#linuxinstall").hide();
-        $("#windowsinstall").hide();
-    }
-
-    function toggleLinux(){
-        $(".linux-button:first").trigger('click');
-        $("#linuxinstall").show();
-        $("#macinstall").hide();
-        $("#windowsinstall").hide();
-    }
-
-    function toggleWindows(){
-        $("#windowsinstall").show();
-        $("#macinstall").hide();
-        $("#linuxinstall").hide();
-    }
-});
-</script>
-
-<div id="os-tabs" class="clearfix">
-    <button id="mac" class="current" data-eventcategory="buttonClick-doc-os" data-eventaction="mac">Mac</button>
-    <button id="linux" data-eventcategory="buttonClick-doc-os" data-eventaction="linux">Linux</button>
-    <button id="windows" data-eventcategory="buttonClick-doc-os" data-eventaction="windows">Windows</button>
-</div>
-
-<section id="macinstall" markdown="1">
-
-- [Yosemite and later](#yosemite-and-later)
-- [Older versions](#older-versions)
-
-#### Yosemite and later
-
-To adjust the file descriptors limit for a single process in Mac OS X Yosemite and later, you must create a property list configuration file with the hard limit set to the recommendation mentioned [above](#file-descriptors-limit). Note that CockroachDB always uses the hard limit, so it's not technically necessary to adjust the soft limit, although we do so in the steps below.
-
-For example, for a node with 3 stores, we would set the hard limit to at least 35000 (10000 per store and 5000 for networking) as follows:
-
-1.  Check the current limits:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ launchctl limit maxfiles
-    ~~~
-    ~~~
-    maxfiles    10240          10240
-    ~~~
-
-    The last two columns are the soft and hard limits, respectively. If `unlimited` is listed as the hard limit, note that the hidden default limit for a single process is actually 10240.
-
-2.  Create `/Library/LaunchDaemons/limit.maxfiles.plist` and add the following contents, with the final strings in the `ProgramArguments` array set to 35000:
-
-    ~~~ xml
-    <?xml version="1.0" encoding="UTF-8"?>
-    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
-      <plist version="1.0">
-        <dict>
-          <key>Label</key>
-            <string>limit.maxfiles</string>
-          <key>ProgramArguments</key>
-            <array>
-              <string>launchctl</string>
-              <string>limit</string>
-              <string>maxfiles</string>
-              <string>35000</string>
-              <string>35000</string>
-            </array>
-          <key>RunAtLoad</key>
-            <true/>
-          <key>ServiceIPC</key>
-            <false/>
-        </dict>
-      </plist>
-    ~~~
-
-    Make sure the plist file is owned by `root:wheel` and has permissions `-rw-r--r--`. These permissions should be in place by default.
-
-3.  Restart the system for the new limits to take effect.
-
-4.  Check the current limits:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ launchctl limit maxfiles
-    ~~~
-    ~~~
-    maxfiles    35000          35000
-    ~~~
-
-#### Older versions
-
-To adjust the file descriptors limit for a single process in OS X versions earlier than Yosemite, edit `/etc/launchd.conf` and increase the hard limit to the recommendation mentioned [above](#file-descriptors-limit). Note that CockroachDB always uses the hard limit, so it's not technically necessary to adjust the soft limit, although we do so in the steps below.
-
-For example, for a node with 3 stores, we would set the hard limit to at least 35000 (10000 per store and 5000 for networking) as follows:
-
-1.  Check the current limits:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ launchctl limit maxfiles
-    ~~~
-    ~~~
-    maxfiles    10240          10240
-    ~~~
-
-    The last two columns are the soft and hard limits, respectively. If `unlimited` is listed as the hard limit, note that the hidden default limit for a single process is actually 10240.
-
-2.  Edit (or create) `/etc/launchd.conf` and add a line that looks like the following, with the last value set to the new hard limit:
-
-    ~~~
-    limit maxfiles 35000 35000
-    ~~~
-
-3.  Save the file, and restart the system for the new limits to take effect.
-
-4.  Verify the new limits:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ launchctl limit maxfiles
-    ~~~
-    ~~~
-    maxfiles    35000          35000
-    ~~~
-
-</section>
-
-<section id="linuxinstall" markdown="1">
-
-- [Per-Process Limit](#per-process-limit)
-- [System-Wide Limit](#system-wide-limit)
-
-#### Per-Process Limit
-
-To adjust the file descriptors limit for a single process on Linux, enable PAM user limits and set the hard limit to the recommendation mentioned [above](#file-descriptors-limit). Note that CockroachDB always uses the hard limit, so it's not technically necessary to adjust the soft limit, although we do so in the steps below.
-
-For example, for a node with 3 stores, we would set the hard limit to at least 35000 (10000 per store and 5000 for networking) as follows:
-
-1.  Make sure the following line is present in both `/etc/pam.d/common-session` and `/etc/pam.d/common-session-noninteractive`:
-
-    ~~~ shell
-    session    required   pam_limits.so
-    ~~~
-
-2.  Edit `/etc/security/limits.conf` and append the following lines to the file:
-
-    ~~~
-    *              soft     nofile          35000
-    *              hard     nofile          35000
-    ~~~
-
-    Note that `*` can be replaced with the username that will be running the CockroachDB server.
-
-4.  Save and close the file.
-
-5.  Restart the system for the new limits to take effect.
-
-6.  Verify the new limits:
-
-    ~~~ shell
-    $ ulimit -a
-    ~~~
-
-Alternately, if you're using [Systemd](https://en.wikipedia.org/wiki/Systemd):
-
-1.  Edit the service definition to configure the maximum number of open files:
-
-    ~~~ ini
-    [Service]
-    ...
-    LimitNOFILE=35000
-    ~~~
-
-    {{site.data.alerts.callout_success}}
-    To set the file descriptor limit to "unlimited" in the Systemd service definition file, use `LimitNOFILE=infinity`.
-    {{site.data.alerts.end}}
-
-2.  Reload Systemd for the new limit to take effect:
-
-    ~~~ shell
-    $ systemctl daemon-reload
-    ~~~
-
-#### System-Wide Limit
-
-You should also confirm that the file descriptors limit for the entire Linux system is at least 10 times higher than the per-process limit documented above (e.g., at least 150000).
-
-1. Check the system-wide limit:
-
-    ~~~ shell
-    $ cat /proc/sys/fs/file-max
-    ~~~
-
-2. If necessary, increase the system-wide limit in the `proc` file system:
-
-    ~~~ shell
-    $ echo 150000 > /proc/sys/fs/file-max
-    ~~~
-
-</section>
-<section id="windowsinstall" markdown="1">
-
-CockroachDB does not yet provide a Windows binary. Once that's available, we will also provide documentation on adjusting the file descriptors limit on Windows.
-
-</section>
-
-#### Attributions
-
-This section, "File Descriptors Limit", is in part derivative of the chapter *Open File Limits* From the Riak LV 2.1.4 documentation, used under Creative Commons Attribution 3.0 Unported License.
-
-## Orchestration / Kubernetes
-
-When running CockroachDB on Kubernetes, making the following minimal customizations will result in better, more reliable performance:
-
-* Use [SSDs instead of traditional HDDs](kubernetes-performance.html#disk-type).
-* Configure CPU and memory [resource requests and limits](kubernetes-performance.html#resource-requests-and-limits).
-
-For more information and additional customization suggestions, see our full detailed guide to [CockroachDB Performance on Kubernetes](kubernetes-performance.html).
-
-## Transaction Retries
-
-When several transactions are trying to modify the same underlying data concurrently, they may experience [contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention) that leads to [transaction retries](transactions.html#transaction-retries).  In order to avoid failures in production, your application should be engineered to handle transaction retries using [client-side retry handling](transactions.html#client-side-intervention).
diff --git a/src/current/v20.2/refresh.md b/src/current/v20.2/refresh.md
deleted file mode 100644
index 14b3d8574a5..00000000000
--- a/src/current/v20.2/refresh.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: REFRESH
-summary: The REFRESH statement updates the stored query results of a materialized view.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> Stored query results in [materialized view](views.html#materialized-views) are not automatically updated to reflect the latest state of the table(s) they query. The `REFRESH` [statement](sql-statements.html) updates the stored query results of a materialized view.
-
-{{site.data.alerts.callout_info}}
-CockroachDB does not support materialized views that are refreshed on [transaction commit](commit-transaction.html).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-The user must be the owner of the materialized view.
-
-## Syntax
-
-~~~
-REFRESH MATERIALIZED VIEW [CONCURRENTLY] view_name [WITH [NO] DATA]
-~~~
-
-## Parameters
-
- Parameter | Description
------------|-------------
-`CONCURRENTLY` | (*Default behavior*) This keyword is a no-op, added for PostgreSQL compatibility. All materialized views are refreshed concurrently with other jobs.
-`view_name` | The name of the materialized view to refresh.
-`WITH NO DATA` | Drop the query results of the materialized view from storage.
-`WITH DATA` | (*Default behavior*) Refresh the stored query results.
-
-## Example
-
-The following example uses the [sample `bank` database](cockroach-workload.html#bank-workload), populated with some workload values.
-
-Suppose that you create a materialized view on the `bank` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE MATERIALIZED VIEW overdrawn_accounts
-  AS SELECT id, balance
-  FROM bank
-  WHERE balance < 0;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM overdrawn_accounts;
-~~~
-
-~~~
-  id  | balance
-------+----------
-    1 |  -17643
-    3 |   -5928
-   13 |   -3700
-...
-(402 rows)
-~~~
-
-Now suppose that you update the `balance` values of the `bank` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE bank SET balance = 0 WHERE balance < 0;
-~~~
-
-~~~
-UPDATE 402
-~~~
-
-The changes can be seen in the table with a simple `SELECT` statement against the table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id, balance
-FROM bank
-WHERE balance < 0;
-~~~
-
-~~~
-  id | balance
------+----------
-(0 rows)
-~~~
-
-
-Recall that materialized views do not automatically update their stored results. Selecting from `overdrawn_accounts` returns stored results, which are outdated:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM overdrawn_accounts;
-~~~
-
-~~~
-  id  | balance
-------+----------
-    1 |  -17643
-    3 |   -5928
-   13 |   -3700
-...
-(402 rows)
-~~~
-
-To update the materialized view's results, use a [`REFRESH`](refresh.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REFRESH MATERIALIZED VIEW overdrawn_accounts;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM overdrawn_accounts;
-~~~
-
-~~~
-  id | balance
------+----------
-(0 rows)
-~~~
-
-## See also
-
-- [Materialized views](views.html#materialized-views)
-- [`CREATE VIEW`](create-view.html)
-- [`SHOW TABLES`](show-tables.html)
-- [`ALTER VIEW`](alter-view.html)
-- [`DROP VIEW`](drop-view.html)
diff --git a/src/current/v20.2/release-savepoint.md b/src/current/v20.2/release-savepoint.md
deleted file mode 100644
index 2e7059afd0f..00000000000
--- a/src/current/v20.2/release-savepoint.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: RELEASE SAVEPOINT
-summary: The RELEASE SAVEPOINT statement commits the nested transaction starting at the corresponding SAVEPOINT statement using the same savepoint name.
-toc: true
----
-
- The `RELEASE SAVEPOINT` statement commits the [nested transaction](transactions.html#nested-transactions) starting at the corresponding `SAVEPOINT` statement using the same savepoint name, including all its nested sub-transactions.  This is in addition to continued support for working with [retry savepoints](savepoint.html#savepoints-for-client-side-transaction-retries).
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/release_savepoint.html %}
-</div>
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to release a savepoint. However, privileges are required for each statement within a transaction.
-
-## Parameters
-
-Parameter | Description
---------- | -----------
-name      | The name of the savepoint.  [Retry savepoints](savepoint.html#savepoints-for-client-side-transaction-retries) default to using the name `cockroach_restart`, but this can be customized using a session variable.  For more information, see [Customizing the retry savepoint name](savepoint.html#customizing-the-retry-savepoint-name).
-
-## Handling errors
-
-The `RELEASE SAVEPOINT` statement is invalid after the nested transaction has encountered an error. After an error, the following statements can be used:
-
-- [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html#rollback-a-nested-transaction) to roll back to the previous savepoint.
-- [`ROLLBACK` or `ABORT`](rollback-transaction.html#rollback-a-transaction) to roll back the entire surrounding transaction.
-- [`COMMIT`](commit-transaction.html) to commit the entire surrounding transaction. In case of error, `COMMIT` is synonymous with [`ROLLBACK`/`ABORT`](rollback-transaction.html) and also rolls back the entire transaction.
-
-When a (sub-)transaction encounters a retry error, the client should repeat `ROLLBACK TO SAVEPOINT` and the statements in the transaction until the statements complete without error, then issue `RELEASE`.
-
-To completely remove the marker of a nested transaction after it encounters an error and begin other work in the outer transaction, use [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html#rollback-a-nested-transaction) immediately followed by `RELEASE`.
-
-## Examples
-
-### Commit a nested transaction by releasing a savepoint
-
-{{site.data.alerts.callout_info}}
-This example uses the [MovR data set](movr.html).
-{{site.data.alerts.end}}
-
-In the example below, we roll back the inner [nested transaction](transactions.html#nested-transactions) (marked by the savepoint `lower`) and release (commit) the outer savepoint `higher`, which raises the promo code discount to 15% using CockroachDB's [JSONB functions](jsonb.html#functions).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT higher;
-UPDATE promo_codes SET rules = jsonb_set(rules, '{value}', '"15%"') WHERE rules @> '{"type": "percent_discount"}';
-SAVEPOINT lower;
-UPDATE promo_codes SET rules = jsonb_set(rules, '{value}', '"7.5%"') WHERE rules @> '{"type": "percent_discount"}';
-ROLLBACK TO SAVEPOINT lower;
-RELEASE SAVEPOINT higher;
-COMMIT;
-~~~
-
-~~~
-COMMIT
-~~~
-
-### Commit a transaction by releasing a retry savepoint
-
-{% include {{page.version.version}}/sql/retry-savepoints.md %}
-
-After declaring a retry savepoint, commit the transaction with `RELEASE SAVEPOINT` and then prepare the connection for the next transaction with [`COMMIT`](commit-transaction.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT cockroach_restart;
-UPDATE products SET inventory = 0 WHERE sku = '8675309';
-INSERT INTO orders (customer, sku, status) VALUES (1001, '8675309', 'new');
-RELEASE SAVEPOINT cockroach_restart;
-COMMIT;
-~~~
-
-Applications using `SAVEPOINT` for client-side transaction retries must also include functions to execute retries with [`ROLLBACK TO SAVEPOINT `](rollback-transaction.html#retry-a-transaction).
-
-Note that you can [customize the retry savepoint name](savepoint.html#customizing-the-retry-savepoint-name) to something other than `cockroach_restart` with a session variable if you need to.
-
-## See also
-
-- [Transactions](transactions.html)
-- [`SAVEPOINT`](savepoint.html)
-- [`SHOW SAVEPOINT STATUS`](show-savepoint-status.html)
-- [`ROLLBACK`](rollback-transaction.html)
-- [`BEGIN`](begin-transaction.html)
-- [`COMMIT`](commit-transaction.html)
diff --git a/src/current/v20.2/remove-nodes.md b/src/current/v20.2/remove-nodes.md
deleted file mode 100644
index 970a342eb7c..00000000000
--- a/src/current/v20.2/remove-nodes.md
+++ /dev/null
@@ -1,402 +0,0 @@
----
-title: Decommission Nodes
-summary: Remove one or more nodes from a CockroachDB cluster.
-toc: true
----
-
-This page shows you how to decommission one or more nodes. Decommissioning a node removes it from the CockroachDB cluster.
-
-You might do this, for example, when downsizing a cluster or reacting to hardware failures.
-
-{{site.data.alerts.callout_info}}
-Node decommissioning should not be performed when [upgrading your cluster's version of CockroachDB](upgrade-cockroach-version.html) or performing planned maintenance (e.g., upgrading system software). In these scenarios, you will want to temporarily [stop the node](cockroach-quit.html) and restart it later.
-{{site.data.alerts.end}}
-
-## Overview
-
-### How it works
-
-A node is considered to be decommissioned when it meets two criteria:
-
-1. The node has completed the decommissioning process.
-2. The node has been stopped and has not [updated its liveness record](architecture/replication-layer.html#epoch-based-leases-table-data) for the duration configured via [`server.time_until_store_dead`](cluster-settings.html), which defaults to 5 minutes.
-
-The decommissioning process transfers all range replicas on the node to other nodes. During and after this process, the node is considered "decommissioning" and continues to accept new SQL connections. Even without replicas, the node can still function as a gateway to route connections to relevant data. For this reason, the [`/health?ready=1` monitoring endpoint](monitoring-and-alerting.html#health-ready-1) continues to consider the node "ready" so load balancers can continue directing traffic to the node.
-
-After all range replicas have been transferred, a graceful shutdown is initiated by sending `SIGTERM`, during which the node is drained of SQL clients, [distributed SQL](architecture/sql-layer.html#distsql) queries, and range leases. Meanwhile, the [`/health?ready=1` monitoring endpoint](monitoring-and-alerting.html#health-ready-1) starts returning a `503 Service Unavailable` status response code so that load balancers stop directing traffic to the node. Once draining completes and the process is terminated, the node stops updating its liveness record, and after the duration configured via [`server.time_until_store_dead`](cluster-settings.html) is considered to be decommissioned.
-
-You can [check the status of node decommissioning](#check-the-status-of-decommissioning-nodes) with the CLI.
-
-### Considerations
-
-Before decommissioning a node, make sure other nodes are available to take over the range replicas from the node. If no other nodes are available, the decommissioning process will hang indefinitely. See the [Examples](#examples) below for more details.
-
-### Examples
-
-#### 3-node cluster with 3-way replication
-
-In this scenario, each range is replicated 3 times, with each replica on a different node:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-scenario1.1.png' | relative_url }}" alt="Decommission Scenario 1" style="max-width:50%" /></div>
-
-If you try to decommission a node, the process will hang indefinitely because the cluster cannot move the decommissioning node's replicas to the other 2 nodes, which already have a replica of each range:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-scenario1.2.png' | relative_url }}" alt="Decommission Scenario 1" style="max-width:50%" /></div>
-
-To successfully decommission a node in this cluster, you need to add a 4th node. The decommissioning process can then complete:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-scenario1.3.png' | relative_url }}" alt="Decommission Scenario 1" style="max-width:50%" /></div>
-
-#### 5-node cluster with 3-way replication
-
-In this scenario, like in the scenario above, each range is replicated 3 times, with each replica on a different node:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-scenario2.1.png' | relative_url }}" alt="Decommission Scenario 1" style="max-width:50%" /></div>
-
-If you decommission a node, the process will run successfully because the cluster will be able to move the node's replicas to other nodes without doubling up any range replicas:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-scenario2.2.png' | relative_url }}" alt="Decommission Scenario 1" style="max-width:50%" /></div>
-
-#### 5-node cluster with 5-way replication for a specific table
-
-In this scenario, a [custom replication zone](configure-replication-zones.html#create-a-replication-zone-for-a-table) has been set to replicate a specific table 5 times (range 6), while all other data is replicated 3 times:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-scenario3.1.png' | relative_url }}" alt="Decommission Scenario 1" style="max-width:50%" /></div>
-
-If you try to decommission a node, the cluster will successfully rebalance all ranges but range 6. Since range 6 requires 5 replicas (based on the table-specific replication zone), and since CockroachDB will not allow more than a single replica of any range on a single node, the decommissioning process will hang indefinitely:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-scenario3.2.png' | relative_url }}" alt="Decommission Scenario 1" style="max-width:50%" /></div>
-
-To successfully decommission a node in this cluster, you need to add a 6th node. The decommissioning process can then complete:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-scenario3.3.png' | relative_url }}" alt="Decommission Scenario 1" style="max-width:50%" /></div>
-
-## Remove a single node (live)
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div>
-
-### Before decommissioning a node
-
-To ensure your cluster can adequately handle decommissioning nodes:
-
-- Before decommissioning each node verify that there are no [underreplicated or unavailable ranges](ui-replication-dashboard.html).
-- If you have a decommissioning node that appears to be hung, you can [recommission](#recommission-nodes) the node. If you notice any issues persisting, [contact our support team](support-resources.html).
-
-    If possible, keep the node running instead of stopping it, because a hung decommissioning process might be a symptom of a problem that could result in data loss.
-- Confirm that there are enough nodes to take over the replicas from the node you want to remove. See some [Example scenarios](#examples) above.
-
-### Step 1. Check the node before decommissioning
-
-Open the DB Console, click **Metrics** on the left, select the **Replication** dashboard, and hover over the **Replicas per Store** and **Leaseholders per Store** graphs:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/before-decommission1.png' | relative_url }}" alt="Decommission a single live node" style="border:1px solid #eee;max-width:100%" /></div>
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/before-decommission2.png' | relative_url }}" alt="Decommission a single live node" style="border:1px solid #eee;max-width:100%" /></div>
-
-### Step 2. Start the decommissioning process on the node
-
-Run the [`cockroach node decommission`](cockroach-node.html) command against the address of the node to decommission:
-
-<div class="filter-content" markdown="1" data-scope="secure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node decommission --self --certs-dir=certs --host=<address of node to decommission>
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node decommission --self --insecure --host=<address of node to decommission>
-~~~
-</div>
-
-You'll then see the decommissioning status print to `stderr` as it changes:
-
-~~~
- id | is_live | replicas | is_decommissioning | is_draining  
-+---+---------+----------+--------------------+-------------+
-  4 |  true   |       45 |        true        |    false     
-(1 row)
-~~~
-
-Once the node has completed the decommissioning process, you'll see a confirmation:
-
-~~~
- id | is_live | replicas | is_decommissioning | is_draining  
-+---+---------+----------+--------------------+-------------+
-  4 |  true   |        0 |        true        |    false     
-(1 row)
-
-No more data reported on target nodes. Please verify cluster health before removing the nodes.
-~~~
-
-Note that `is_decommissioning` will remain `true` after all replicas have been transferred from the node.
-
-### Step 3. Check the node and cluster after the decommissioning process
-
-In the DB Console **Replication** dashboard, again hover over the **Replicas per Store** and **Leaseholders per Store** graphs. For the decommissioning node, the counts should be 0:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/after-decommission1.png' | relative_url }}" alt="Decommission a single live node" style="border:1px solid #eee;max-width:100%" /></div>
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/after-decommission2.png' | relative_url }}" alt="Decommission a single live node" style="border:1px solid #eee;max-width:100%" /></div>
-
-Return to the [**Node List**](ui-cluster-overview-page.html#node-list) on the Overview page. The `DECOMMISSIONING` node should have 0 replicas, and all other nodes should be healthy (`LIVE`):
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/cluster-status-after-decommission1.png' | relative_url }}" alt="Decommission a single live node" style="border:1px solid #eee;max-width:100%" /></div>
-
-{{site.data.alerts.callout_success}}
-Even with zero replicas on a node, its [status](ui-cluster-overview-page.html#node-status) on the Node List will be `DECOMMISSIONING` until you stop the node. It is also counted as a "Suspect" node in the [Cluster Overview panel](ui-cluster-overview-page.html#cluster-overview-panel) until being shut down.
-{{site.data.alerts.end}}
-
-### Step 4. Stop the decommissioning node
-
-Drain and stop the node using one of the following methods:
-
-{% include {{ page.version.version }}/prod-deployment/node-shutdown.md %}
-
-After the duration configured via [`server.time_until_store_dead`](cluster-settings.html), you'll see the stopped node listed under **Recently Decommissioned Nodes**:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/cluster-status-after-decommission2.png' | relative_url }}" alt="Decommission a single live node" style="border:1px solid #eee;max-width:100%" /></div>
-
-At this point, the node is `DECOMMISSIONED` and will no longer appear in timeseries graphs unless you view a time range during which the node was live. However, it will never disappear from the historical list of decommissioned nodes, linked beneath Recently Decommissioned Nodes.
-
-## Remove a single node (dead)
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div>
-
-After a node has been dead for 5 minutes, CockroachDB transfers the range replicas and range leases on the node to available live nodes. However, if the dead node is restarted, the cluster will rebalance replicas and leases to the node.
-
-To prevent the cluster from rebalancing data to a dead node if it comes back online, do the following:
-
-{{site.data.alerts.callout_success}}
-You can check that a node is dead and find its internal ID by either running [`cockroach node status`](cockroach-node.html) or opening the DB Console and scrolling to the [**Node List**](ui-cluster-overview-page.html#node-list) on the **Overview** page.
-{{site.data.alerts.end}}
-
-### Step 1. Mark the dead node as decommissioned
-
-Run the [`cockroach node decommission`](cockroach-node.html) command against the address of any live node, specifying the ID of the dead node:
-
-<div class="filter-content" markdown="1" data-scope="secure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node decommission <id of the dead node> --certs-dir=certs --host=<address of any live node>
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node decommission <id of the dead node> --insecure --host=<address of any live node>
-~~~
-</div>
-
-~~~
- id | is_live | replicas | is_decommissioning | is_draining  
-+---+---------+----------+--------------------+-------------+
-  4 |  false  |        0 |        true        |    true      
-(1 row)
-
-No more data reported on target nodes. Please verify cluster health before removing the nodes.
-~~~
-
-Within 5 minutes, you'll see the node move from the Node List to the **Recently Decommissioned Nodes** list in the DB Console, with its status changed from `DEAD` to `DECOMMISSIONED`.
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/cluster-status-after-decommission2.png' | relative_url }}" alt="Decommission a single live node" style="border:1px solid #eee;max-width:100%" /></div>
-
-At this point, the node is `DECOMMISSIONED` and will no longer appear in timeseries graphs unless you view a time range during which the node was live. However, it will never disappear from the historical list of decommissioned nodes, linked beneath Recently Decommissioned Nodes.
-
-## Remove multiple nodes
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div>
-
-### Before decommissioning nodes
-
-- Before decommissioning each node verify that there are no [underreplicated or unavailable ranges](ui-replication-dashboard.html).
-- If you have a decommissioning node that appears to be hung, you can [recommission](#recommission-nodes) the node. If you notice any issues persisting, [contact our support team](support-resources.html).
-
-    If possible, keep the node running instead of stopping it, because a hung decommissioning process might be a symptom of a problem that could result in data loss.
-- Confirm that there are enough nodes to take over the replicas from the node you want to remove. See some [Example scenarios](#examples) above.
-
-### Step 1. Check the nodes before decommissioning
-
-Open the DB Console, click **Metrics** on the left, select the **Replication** dashboard, and hover over the **Replicas per Store** and **Leaseholders per Store** graphs:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-multiple2.png' | relative_url }}" alt="Decommission multiple nodes" style="border:1px solid #eee;max-width:100%" /></div>
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-multiple3.png' | relative_url }}" alt="Decommission multiple nodes" style="border:1px solid #eee;max-width:100%" /></div>
-
-### Step 2. Start the decommissioning process on the nodes
-
-Run the [`cockroach node decommission`](cockroach-node.html) command against the address of each node to decommission:
-
-<div class="filter-content" markdown="1" data-scope="secure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node decommission --self --certs-dir=certs --host=<address of node to decommission>
-~~~
-
-~~~ shell
-$ cockroach node decommission --self --certs-dir=certs --host=<address of another node to decommission>
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node decommission --self --insecure --host=<address of node to decommission>
-~~~
-
-~~~ shell
-$ cockroach node decommission --self --insecure --host=<address of another node to decommission>
-~~~
-</div>
-
-You'll then see the decommissioning status print to `stderr` as it changes:
-
-~~~
- id | is_live | replicas | is_decommissioning | is_draining  
-+---+---------+----------+--------------------+-------------+
-  4 |  true   |       18 |        true        |    false     
-  5 |  true   |       16 |        true        |    false     
-(2 rows)
-~~~
-
-Once the nodes have been fully decommissioned, you'll see a confirmation:
-
-~~~
- id | is_live | replicas | is_decommissioning | is_draining  
-+---+---------+----------+--------------------+-------------+
-  4 |  true   |        0 |        true        |    false     
-  5 |  true   |        0 |        true        |    false     
-(2 rows)
-
-No more data reported on target nodes. Please verify cluster health before removing the nodes.
-~~~
-
-Note that `is_decommissioning` will remain `true` after all replicas have been transferred from each node.
-
-### Step 3. Check the nodes and cluster after the decommissioning process
-
-In the DB Console **Replication** dashboard, again hover over the **Replicas per Store** and **Leaseholders per Store** graphs. For the decommissioning nodes, the counts should be 0:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-multiple4.png' | relative_url }}" alt="Decommission multiple nodes" style="border:1px solid #eee;max-width:100%" /></div>
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-multiple5.png' | relative_url }}" alt="Decommission multiple nodes" style="border:1px solid #eee;max-width:100%" /></div>
-
-Return to the [**Node List**](ui-cluster-overview-page.html#node-list) on the Overview page. The `DECOMMISSIONING` nodes should each have 0 replicas, and all other nodes should be healthy (`LIVE`):
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-multiple6.png' | relative_url }}" alt="Decommission multiple nodes" style="border:1px solid #eee;max-width:100%" /></div>
-
-{{site.data.alerts.callout_success}}
-Even with zero replicas on a node, its [status](ui-cluster-overview-page.html#node-status) on the Node List will be `DECOMMISSIONING` until you stop the node. It is also counted as a "Suspect" node in the [Cluster Overview panel](ui-cluster-overview-page.html#cluster-overview-panel) until being shut down.
-{{site.data.alerts.end}}
-
-### Step 4. Stop the decommissioning nodes
-
-Drain and stop each node using one of the following methods:
-
-{% include {{ page.version.version }}/prod-deployment/node-shutdown.md %}
-
-After the duration configured via [`server.time_until_store_dead`](cluster-settings.html), you'll see the stopped nodes listed under **Recently Decommissioned Nodes**:
-
-<div style="text-align: center;"><img src="{{ 'images/v20.2/decommission-multiple7.png' | relative_url }}" alt="Decommission multiple nodes" style="border:1px solid #eee;max-width:100%" /></div>
-
-At this point, the nodes are `DECOMMISSIONED` and will no longer appear in timeseries graphs unless you view a time range during which the nodes were live. However, they will never disappear from the historical list of decommissioned nodes, linked beneath Recently Decommissioned Nodes.
-
-## Recommission nodes
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div>
-
-If you accidentally started decommissioning a node, or have a node with a hung decommissioning process, you can recommission the node. This cancels the process of transferring replicas on the node to other nodes.
-
-{{site.data.alerts.callout_info}}
-Recommissioning is intended to cancel an active decommissioning process. If all ranges have been removed from a node, you must start a new node. As of v20.2, a fully decommissioned node is permanently decommissioned, and cannot be recommissioned.
-{{site.data.alerts.end}}
-
-### Step 1. Cancel the decommissioning process
-
-Press `ctrl-c` in each terminal with an ongoing decommissioning process that you want to cancel.
-
-### Step 2. Recommission the decommissioning nodes
-
-Execute the [`cockroach node recommission`](cockroach-node.html) command against the address of the node to recommission:
-
-<div class="filter-content" markdown="1" data-scope="secure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node recommission --self --certs-dir=certs --host=<address of node to recommission>
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node recommission --self --insecure --host=<address of node to recommission>
-~~~
-</div>
-
-The value of `is_decommissioning` will change back to `false`:
-
-~~~
- id | is_live | replicas | is_decommissioning | is_draining  
-+---+---------+----------+--------------------+-------------+
-  4 |  false  |        0 |       false        |    false      
-(1 row)
-~~~
-
-On the [**Node List**](ui-cluster-overview-page.html#node-list), you should soon see the recommissioned nodes listed as `LIVE`. After a few minutes, you should see replicas rebalanced to the nodes.
-
-## Check the status of decommissioning nodes
-
-To check the progress of decommissioning nodes, run the [`cockroach node status`](cockroach-node.html) command with the `--decommission` flag:
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="secure">Secure</button>
-  <button style="width: 15%" class="filter-button" data-scope="insecure">Insecure</button>
-</div><br>
-
-<div class="filter-content" markdown="1" data-scope="secure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node status --decommission --certs-dir=certs --host=<address of any live node>
-~~~
-</div>
-
-<div class="filter-content" markdown="1" data-scope="insecure">
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach node status --decommission --insecure --host=<address of any live node>
-~~~
-</div>
-
-~~~
- id |        address         |  build  |            started_at            |            updated_at            | is_available | is_live | gossiped_replicas | is_decommissioning | is_draining  
-+---+------------------------+---------+----------------------------------+----------------------------------+--------------+---------+-------------------+--------------------+-------------+
-  1 | 165.227.60.76:26257    | 91a299d | 2018-10-01 16:53:10.946245+00:00 | 2018-10-02 14:04:39.280249+00:00 |         true |  true   |                26 |       false        |    false     
-  2 | 192.241.239.201:26257  | 91a299d | 2018-10-01 16:53:24.22346+00:00  | 2018-10-02 14:04:39.415235+00:00 |         true |  true   |                26 |       false        |    false     
-  3 | 67.207.91.36:26257     | 91a299d | 2018-10-01 17:34:21.041926+00:00 | 2018-10-02 14:04:39.233882+00:00 |         true |  true   |                25 |       false        |    false     
-  4 | 138.197.12.74:26257    | 91a299d | 2018-10-01 17:09:11.734093+00:00 | 2018-10-02 14:04:37.558204+00:00 |         true |  true   |                25 |       false        |    false     
-  5 | 174.138.50.192:26257   | 91a299d | 2018-10-01 17:14:01.480725+00:00 | 2018-10-02 14:04:39.293121+00:00 |         true |  true   |                 0 |        true        |    false          
-(5 rows)
-~~~
-
-- `is_decommissioning == true` implies that replicas are being or have been transferred to other nodes. The node is either undergoing or has completed the decommissioning process.
-- `is_draining == true` implies that the node is no longer accepting SQL connections. The node is either in the process of shutting down or has already done so.
-
-## See also
-
-- [`cockroach start`](cockroach-start.html)
-- [Node status](ui-cluster-overview-page.html#node-status)
diff --git a/src/current/v20.2/rename-column.md b/src/current/v20.2/rename-column.md
deleted file mode 100644
index c2670cda475..00000000000
--- a/src/current/v20.2/rename-column.md
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: RENAME COLUMN
-summary: The RENAME COLUMN statement changes the name of a column in a table.
-toc: true
----
-
-The `RENAME COLUMN` [statement](sql-statements.html) changes the name of a column in a table.
-
-{{site.data.alerts.callout_info}}
-It is not possible to rename a column referenced by a view. For more details, see [View Dependencies](views.html#view-dependencies).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/rename_column.html %}
-</div>
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the table.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `IF EXISTS` | Rename the column only if a table of `table_name` exists; if one does not exist, do not return an error.
- `table_name` | The name of the table with the column you want to use.
- `current_name` | The current name of the column.
- `name` | The [`name`](sql-grammar.html#name) you want to use for the column, which must be unique to its table and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-### Rename a column
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-    id INT PRIMARY KEY,
-    first_name STRING,
-    family_name STRING
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users RENAME COLUMN family_name TO last_name;
-~~~
-
-~~~
-  table_name |                 create_statement
-+------------+--------------------------------------------------+
-  users      | CREATE TABLE users (
-             |     id INT8 NOT NULL,
-             |     first_name STRING NULL,
-             |     last_name STRING NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     FAMILY "primary" (id, first_name, last_name)
-             | )
-(1 row)
-~~~
-
-### Add and rename columns atomically
-
-Some subcommands can be used in combination in a single [`ALTER TABLE`](alter-table.html) statement. For example, let's say you create a `users` table with 2 columns, an `id` column for the primary key and a `name` column for each user's last name:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-    id INT PRIMARY KEY,
-    name STRING
-  );
-~~~
-
-Then you decide you want distinct columns for each user's first name, last name, and full name, so you execute a single `ALTER TABLE` statement renaming `name` to `last_name`, adding `first_name`, and adding a [computed column](computed-columns.html) called `name` that concatenates `first_name` and `last_name`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users
-    RENAME COLUMN name TO last_name,
-    ADD COLUMN first_name STRING,
-    ADD COLUMN name STRING
-      AS (CONCAT(first_name, ' ', last_name)) STORED;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                           create_statement
-+------------+----------------------------------------------------------------------+
-  users      | CREATE TABLE users (
-             |     id INT8 NOT NULL,
-             |     last_name STRING NULL,
-             |     first_name STRING NULL,
-             |     name STRING NULL AS (concat(first_name, ' ', last_name)) STORED,
-             |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-             |     FAMILY "primary" (id, last_name, first_name, name)
-             | )
-(1 row)
-~~~
-
-## See also
-
-- [`ALTER TABLE`](alter-table.html)
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`RENAME DATABASE`](rename-database.html)
-- [`RENAME TABLE`](rename-table.html)
-- [`RENAME CONSTRAINT`](rename-constraint.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/rename-constraint.md b/src/current/v20.2/rename-constraint.md
deleted file mode 100644
index 0324cbefdab..00000000000
--- a/src/current/v20.2/rename-constraint.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: RENAME CONSTRAINT
-summary: The RENAME CONSTRAINT statement changes the name of a constraint on a column.
-toc: true
----
-
-The `RENAME CONSTRAINT` [statement](sql-statements.html) changes the name of a constraint on a column.
-
-{{site.data.alerts.callout_info}}
-It is not possible to rename a constraint for a column referenced by a view. For more details, see [View Dependencies](views.html#view-dependencies).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/rename_constraint.html %}
-</div>
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the table.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `IF EXISTS` | Rename the constraint only if a constraint of `current_name` exists; if one does not exist, do not return an error.
- `table_name` | The name of the table with the constraint you want to rename.
- `current_name` | The current name of the constraint.
- `name` | The new [`name`](sql-grammar.html#name) you want to use for the constraint, which must be unique to its table and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Example
-
-### Rename a constraint
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE logon (
-    login_id INT PRIMARY KEY,
-    customer_id INT NOT NULL,
-    sales_id INT,
-    UNIQUE (customer_id, sales_id)
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS FROM logon;
-~~~
-
-~~~
-  table_name |        constraint_name         | constraint_type |                details                 | validated
-+------------+--------------------------------+-----------------+----------------------------------------+-----------+
-  logon      | logon_customer_id_sales_id_key | UNIQUE          | UNIQUE (customer_id ASC, sales_id ASC) |   true
-  logon      | primary                        | PRIMARY KEY     | PRIMARY KEY (login_id ASC)             |   true
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE logon RENAME CONSTRAINT logon_customer_id_sales_id_key TO unique_customer_id_sales_id;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS FROM logon;
-~~~
-
-~~~
-  table_name |       constraint_name       | constraint_type |                details                 | validated
-+------------+-----------------------------+-----------------+----------------------------------------+-----------+
-  logon      | primary                     | PRIMARY KEY     | PRIMARY KEY (login_id ASC)             |   true
-  logon      | unique_customer_id_sales_id | UNIQUE          | UNIQUE (customer_id ASC, sales_id ASC) |   true
-(2 rows)
-~~~
-
-## See also
-
-- [`ALTER TABLE`](alter-table.html)
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`VALIDATE CONSTRAINT`](validate-constraint.html)
-- [`RENAME DATABASE`](rename-database.html)
-- [`RENAME TABLE`](rename-table.html)
-- [`RENAME COLUMN`](rename-column.html)
diff --git a/src/current/v20.2/rename-database.md b/src/current/v20.2/rename-database.md
deleted file mode 100644
index 792c381f3c2..00000000000
--- a/src/current/v20.2/rename-database.md
+++ /dev/null
@@ -1,148 +0,0 @@
----
-title: ALTER DATABASE ... RENAME TO
-summary: The ALTER DATABASE ... RENAME TO statement changes the name of a database.
-toc: true
----
-
-The `RENAME TO` clause is part of [`ALTER DATABASE`](alter-database.html), and changes the name of a database. 
-
-{% include {{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/rename_database.html %}
-</div>
-
-## Required privileges
-
-To rename a database, the user must be a member of the `admin` role or must have the [`CREATEDB`](create-role.html#create-a-role-that-can-create-and-rename-databases) parameter set.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`name` | The first instance of `name` is the current name of the database. The second instance is the new name for the database. The new name [must be unique](#rename-fails-new-name-already-in-use) and follow these [identifier rules](keywords-and-identifiers.html#identifiers). You cannot rename a database if it is set as the [current database](sql-name-resolution.html#current-database) or if [`sql_safe_updates = true`](set-vars.html).
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Limitations
-
-It is not possible to rename a database if:
-
-- The database is referenced by a [view](views.html). For more details, see [View Dependencies](views.html#view-dependencies).
-- The database is explicitly specified in a reference to a [sequence](create-sequence.html). In this case, you can drop the column in the table that references the sequence, or you can modify the reference so that it does not specify the database name.
-
-    For example, suppose you create a database `db`, and in that database, a sequence `seq`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE db;
-      USE db;
-      CREATE SEQUENCE seq;
-    ~~~
-
-    Then you reference the sequence in a table `tab`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE tab (
-      id UUID DEFAULT gen_random_uuid(),
-      count INT DEFAULT nextval('db.seq')
-    );
-    ~~~
-
-    Attempting to rename the database will result in an error:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET sql_safe_updates=false;
-      ALTER DATABASE db RENAME TO mydb;
-    ~~~
-
-    ~~~
-    ERROR: cannot rename database because relation "db.public.tab" depends on relation "db.public.seq"
-    SQLSTATE: 2BP01
-    HINT: you can drop the column default "count" of "db.public.seq" referencing "db.public.tab" or modify the default to not reference the database name "db"
-    ~~~
-
-    In order to rename the database `db`, you need to drop or change the reference in the default value for the `seq` column to not explicitly name the database `db`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE tab ALTER COLUMN count SET DEFAULT nextval('seq');
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > USE defaultdb;
-      ALTER DATABASE db RENAME TO mydb;
-    ~~~
-
-## Examples
-
-### Rename a database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE db1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW DATABASES;
-~~~
-
-~~~
-  database_name
------------------
-  db1
-  defaultdb
-  movr
-  postgres
-  system
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER DATABASE db1 RENAME TO db2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW DATABASES;
-~~~
-
-~~~
-  database_name
------------------
-  db2
-  defaultdb
-  movr
-  postgres
-  system
-(5 rows)
-~~~
-
-### Rename fails (new name already in use)
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER DATABASE db2 RENAME TO movr;
-~~~
-
-~~~
-ERROR: the new database name "movr" already exists
-SQLSTATE: 42P04
-~~~
-
-## See also
-
-- [`CREATE DATABASE`](create-database.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`SET DATABASE`](set-vars.html)
-- [`DROP DATABASE`](drop-database.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/rename-index.md b/src/current/v20.2/rename-index.md
deleted file mode 100644
index c782a488285..00000000000
--- a/src/current/v20.2/rename-index.md
+++ /dev/null
@@ -1,80 +0,0 @@
----
-title: RENAME INDEX
-summary: The RENAME INDEX statement changes the name of an index for a table.
-toc: true
----
-
-The `RENAME INDEX` [statement](sql-statements.html) changes the name of an index for a table.
-
-{{site.data.alerts.callout_info}}It is not possible to rename an index referenced by a view. For more details, see <a href="views.html#view-dependencies">View Dependencies</a>.{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/rename_index.html %}
-</div>
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the table.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `IF EXISTS` | Rename the index only if an index `current_name` exists; if one does not exist, do not return an error.
- `table_name` | The name of the table with the index you want to use
- `index_name` | The current name of the index
- `name` | The [`name`](sql-grammar.html#name) you want to use for the index, which must be unique to its table and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
-
-## Example
-
-### Rename an Index
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM users;
-~~~
-
-~~~
-+------------+------------+------------+--------------+-------------+-----------+---------+----------+
-| table_name | index_name | non_unique | seq_in_index | column_name | direction | storing | implicit |
-+------------+------------+------------+--------------+-------------+-----------+---------+----------+
-| users      | primary    |   false    |            1 | id          | ASC       |  false  |  false   |
-| users      | name_idx   |    true    |            1 | name        | ASC       |  false  |  false   |
-| users      | name_idx   |    true    |            2 | id          | ASC       |  false  |   true   |
-+------------+------------+------------+--------------+-------------+-----------+---------+----------+
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX users@name_idx RENAME TO users_name_idx;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM users;
-~~~
-
-~~~
-+------------+----------------+------------+--------------+-------------+-----------+---------+----------+
-| table_name |   index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit |
-+------------+----------------+------------+--------------+-------------+-----------+---------+----------+
-| users      | primary        |   false    |            1 | id          | ASC       |  false  |  false   |
-| users      | users_name_idx |    true    |            1 | name        | ASC       |  false  |  false   |
-| users      | users_name_idx |    true    |            2 | id          | ASC       |  false  |   true   |
-+------------+----------------+------------+--------------+-------------+-----------+---------+----------+
-(3 rows)
-~~~
-
-## See also
-
-- [Indexes](indexes.html)
-- [`CREATE INDEX`](create-index.html)
-- [`RENAME COLUMN`](rename-column.html)
-- [`RENAME DATABASE`](rename-database.html)
-- [`RENAME TABLE`](rename-table.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/rename-sequence.md b/src/current/v20.2/rename-sequence.md
deleted file mode 100644
index 5c194726928..00000000000
--- a/src/current/v20.2/rename-sequence.md
+++ /dev/null
@@ -1,138 +0,0 @@
----
-title: RENAME SEQUENCE
-summary: The RENAME SEQUENCE statement changes the name of a sequence.
-toc: true
----
-
-The `RENAME TO` [statement](sql-statements.html) is part of [`ALTER SEQUENCE`](alter-sequence.html), and changes the name of a sequence.
-
-{{site.data.alerts.callout_danger}}
-You cannot rename a sequence that's being used in a table. To rename the sequence, <a href="alter-column.html#remove-default-constraint">drop the <code>DEFAULT</code> expressions</a> that reference the sequence, rename the sequence, and <a href="alter-column.html#set-or-change-a-default-value">add the <code>DEFAULT</code> expressions</a> back.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-`ALTER SEQUENCE ... RENAME TO` can be used to move a sequence from one database to another, but it cannot be used to move a sequence from one schema to another. To change a sequence's schema, use [`SET SCHEMA`](set-schema.html).
-
-Note that, in a future release, `ALTER SEQUENCE ... RENAME TO` will be limited to changing the name of a sequence, and will not have to the ability to change a sequence's database.
-{{site.data.alerts.end}}
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the parent database.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/rename_sequence.html %}</div>
-
-## Parameters
-
-<style>
-table td:first-child {
-    min-width: 225px;
-}
-</style>
-
- Parameter | Description
------------|------------
-`IF EXISTS` | Rename the sequence only if it exists; if it does not exist, do not return an error.
-`current_name` | The current name of the sequence you want to modify.
-`new_name` | The new name of the sequence, which must be unique to its database and follow these [identifier rules](keywords-and-identifiers.html#identifiers). <br><br>Name changes do not propagate to the  table(s) using the sequence.
-
-## Examples
-
-### Rename a Sequence
-
-In this example, we will change the name of sequence.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE even_numbers INCREMENT 2 START 2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-  public          | even_numbers
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER SEQUENCE even_numbers RENAME TO even_sequence;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-  public          | even_sequence
-(1 row)
-~~~
-
-### Move a Sequence
-
-In this example, we will move the sequence we renamed in the first example (`even_sequence`) from `defaultdb` (i.e., the default database) to a different database.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES FROM defaultdb;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-  public          | even_sequence
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE mydb;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER SEQUENCE even_sequence RENAME TO newdb.even_sequence;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES FROM defaultdb;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-(0 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES FROM mydb;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-  public          | even_sequence
-(1 row)
-~~~
-
-## See also
-
-- [`CREATE SEQUENCE`](create-sequence.html)
-- [`ALTER SEQUENCE`](alter-sequence.html)
-- [`DROP SEQUENCE`](drop-sequence.html)
-- [`SHOW SEQUENCES`](show-sequences.html)
-- [Functions and Operators](functions-and-operators.html)
diff --git a/src/current/v20.2/rename-table.md b/src/current/v20.2/rename-table.md
deleted file mode 100644
index 5fc8644206b..00000000000
--- a/src/current/v20.2/rename-table.md
+++ /dev/null
@@ -1,167 +0,0 @@
----
-title: ALTER TABLE ... RENAME TO
-summary: The ALTER TABLE ... RENAME TO statement changes the name of a table.
-toc: true
----
-
-The `RENAME TO` [statement](sql-statements.html) is part of [`ALTER TABLE`](alter-table.html), and changes the name of a table.
-
-{{site.data.alerts.callout_info}}
-`ALTER TABLE ... RENAME TO` can be used to move a table from one database to another, but it cannot be used to move a table from one schema to another. To change a table's schema, use [`SET SCHEMA`](set-schema.html).
-
-Note that, in a future release, `ALTER TABLE ... RENAME TO` will be limited to changing the name of a table, and will not have to the ability to change a table's database.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-It is not possible to rename a table referenced by a view. For more details, see <a href="views.html#view-dependencies">View Dependencies</a>.
-{{site.data.alerts.end}}
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the table and the `CREATE` on the parent database. When moving a table from one database to another, the user must have the `CREATE` privilege on both the source and target databases.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/rename_table.html %}
-</div>
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `IF EXISTS` | Rename the table only if a table with the current name exists; if one does not exist, do not return an error.
- `current_name` | The current name of the table.
- `new_name` | The new name of the table, which must be unique within its database and follow these [identifier rules](keywords-and-identifiers.html#identifiers). When the parent database is not set as the default, the name must be formatted as `database.name`.<br><br>The [`UPSERT`](upsert.html) and [`INSERT ON CONFLICT`](insert.html) statements use a temporary table called `excluded` to handle uniqueness conflicts during execution. It's therefore not recommended to use the name `excluded` for any of your tables.
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Rename a table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users RENAME TO riders;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | riders                     | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-To avoid an error in case the table does not exist, you can include `IF EXISTS`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE IF EXISTS customers RENAME TO clients;
-~~~
-
-### Move a table
-
-To move a table from one database to another, use the above syntax but specify the source database after `ALTER TABLE` and the target database after `RENAME TO`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | riders                     | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM defaultdb;
-~~~
-
-~~~
-  schema_name | table_name | type | estimated_row_count
---------------+------------+------+----------------------
-(0 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE movr.promo_codes RENAME TO defaultdb.promos;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | riders                     | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM defaultdb;
-~~~
-
-~~~
-  schema_name | table_name | type  | estimated_row_count
---------------+------------+-------+----------------------
-  public      | promos     | table |                1000
-(1 row)
-~~~
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`SHOW TABLES`](show-tables.html)
-- [`DROP TABLE`](drop-table.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/reset-cluster-setting.md b/src/current/v20.2/reset-cluster-setting.md
deleted file mode 100644
index eaae6ab2047..00000000000
--- a/src/current/v20.2/reset-cluster-setting.md
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: RESET CLUSTER SETTING
-summary: The RESET CLUSTER SETTING statement resets a cluster setting to its default value for the client session.
-toc: true
----
-
-The `RESET` [statement](sql-statements.html) resets a [cluster setting](set-cluster-setting.html) to its default value for the client session..
-
-
-## Required privileges
-
-Only members of the `admin` role can modify cluster settings. By default, the `root` user belongs to the `admin` role.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/reset_csetting.html %}
-</div>
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `var_name` | The name of the [cluster setting](cluster-settings.html) (case-insensitive).
-
-## Example
-
-{{site.data.alerts.callout_success}}You can use <a href="set-cluster-setting.html"><code>SET CLUSTER SETTING .. TO DEFAULT</code></a> to reset a cluster setting as well.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.metrics.statement_details.enabled = false;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING sql.metrics.statement_details.enabled;
-~~~
-
-~~~
-+---------------------------------------+
-| sql.metrics.statement_details.enabled |
-+---------------------------------------+
-| false                                 |
-+---------------------------------------+
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESET CLUSTER SETTING sql.metrics.statement_details.enabled;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING sql.metrics.statement_details.enabled;
-~~~
-
-~~~
-+---------------------------------------+
-| sql.metrics.statement_details.enabled |
-+---------------------------------------+
-| true                                  |
-+---------------------------------------+
-(1 row)
-~~~
-
-## See also
-
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`SHOW CLUSTER SETTING`](show-cluster-setting.html)
-- [Cluster settings](cluster-settings.html)
diff --git a/src/current/v20.2/reset-vars.md b/src/current/v20.2/reset-vars.md
deleted file mode 100644
index ccff9cc415d..00000000000
--- a/src/current/v20.2/reset-vars.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: RESET (session variable)
-summary: The SET statement resets a session variable to its default value.
-toc: true
----
-
-The `RESET` [statement](sql-statements.html) resets a [session variable](set-vars.html) to its default value for the client session.
-
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to reset a session setting.
-
-## Synopsis
-
-<div>{% include {{ page.version.version }}/sql/diagrams/reset_session.html %}</div>
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `session_var` | The name of the [session variable](set-vars.html#supported-variables).
-
-## Example
-
-{{site.data.alerts.callout_success}}You can use <a href="set-vars.html#reset-a-variable-to-its-default-value"><code>SET .. TO DEFAULT</code></a> to reset a session variable as well.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET extra_float_digits = -10;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW extra_float_digits;
-~~~
-
-~~~
- extra_float_digits
---------------------
- -10
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT random();
-~~~
-
-~~~
- random
----------
- 0.20286
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESET extra_float_digits;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW extra_float_digits;
-~~~
-
-~~~
- extra_float_digits
---------------------
- 0
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT random();
-~~~
-
-~~~
-      random
--------------------
- 0.561354028296755
-(1 row)
-~~~
-
-## See also
-
-- [`SET` (session variable)](set-vars.html)
-- [`SHOW` (session variables)](show-vars.html)
diff --git a/src/current/v20.2/restore.md b/src/current/v20.2/restore.md
deleted file mode 100644
index bf3eb4896d9..00000000000
--- a/src/current/v20.2/restore.md
+++ /dev/null
@@ -1,344 +0,0 @@
----
-title: RESTORE
-summary: Restore your CockroachDB cluster to a cloud storage services such as AWS S3, Google Cloud Storage, or other NFS.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> `RESTORE` no longer requires an Enterprise license, regardless of the options passed to it or to the backup it is restoring.
-{{site.data.alerts.end}}
-
-The `RESTORE` [statement](sql-statements.html) restores your cluster's schemas and data from [a `BACKUP`][backup] stored on a services such as AWS S3, Google Cloud Storage, NFS, or HTTP storage.
-
-Because CockroachDB is designed with high fault tolerance, restores are designed primarily for disaster recovery, i.e., restarting your cluster if it loses a majority of its nodes. Isolated issues (such as small-scale node outages) do not require any intervention.
-
-You can restore:
-
-- [A full cluster](#full-cluster)
-- [Databases](#databases)
-- [Tables](#tables)
-
-{{site.data.alerts.callout_info}}
-`RESTORE` is a blocking statement. To run a restore job asynchronously, use the `DETACHED` option. See the [options](#options) below.
-{{site.data.alerts.end}}
-
-## Required privileges
-
-- Full cluster restores can only be run by members of the [`admin` role](authorization.html#admin-role). By default, the `root` user belongs to the `admin` role.
-- For all other restores, the user must have [write access](authorization.html#assign-privileges) (`CREATE` or `INSERT`) on all objects affected.
-
-### Source privileges
-
-{% include {{ page.version.version }}/misc/source-privileges.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/restore.html %}
-</div>
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `table_pattern` | The table or [view](views.html) you want to restore.
- `database_name` | The name of the database you want to restore (i.e., restore all tables and views in the database). You can restore an entire database only if you had backed up the entire database.
- `full_backup_location` | The URL where the full backup is stored. <br/><br/>For information about this URL structure, see [Backup File URLs](#backup-file-urls).
- `incremental_backup_location` | The URL where an incremental backup is stored.  <br/><br/>Lists of incremental backups must be sorted from oldest to newest. The newest incremental backup's timestamp must be within the table's garbage collection period.<br/><br/>For information about this URL structure, see [Backup File URLs](#backup-file-urls). <br/><br/>For more information about garbage collection, see [Configure Replication Zones](configure-replication-zones.html#replication-zone-variables).
- `AS OF SYSTEM TIME timestamp` | Restore data as it existed as of [`timestamp`](as-of-system-time.html). You can restore point-in-time data only if you had taken full or incremental backup [with revision history](take-backups-with-revision-history-and-restore-from-a-point-in-time.html).
- `restore_options_list` | Control your backup's behavior with [these options](#options).
-
-### Options
-
-You can control `RESTORE` behavior using any of the following in the `restore_options_list`. To set multiple `RESTORE` options, use a comma-separated list:
-
- Option                                                             | <div style="width:75px">Value</div>         | Description
- -------------------------------------------------------------------+---------------+-------------------------------------------------------
-<a name="into_db"></a>`into_db`                                     | Database name                               | Use to [change the target database](#restore-tables-into-a-different-database) for table restores. (Does not apply to database or cluster restores.)<br><br>Example: `WITH into_db = 'newdb'`
-<a name="skip_missing_foreign_keys"></a>`skip_missing_foreign_keys` | N/A                                         | Use to remove the missing [foreign key](foreign-key.html) constraints before restoring.<br><br>Example: `WITH skip_missing_foreign_keys`
-<a name="skip_missing_sequences"></a>`skip_missing_sequences`       | N/A                                         | Use to ignore [sequence](show-sequences.html) dependencies (i.e., the `DEFAULT` expression that uses the sequence).<br><br>Example: `WITH skip_missing_sequences`
-`skip_missing_sequence_owners`                                      | N/A                                         | <span class="version-tag">New in v20.2:</span> Must be used when restoring either a table that was previously a [sequence owner](create-sequence.html#owned-by) or a sequence that was previously owned by a table.<br><br>Example: `WITH skip_missing_sequence_owners`
-`skip_missing_views`                                                | N/A                                         | Use to skip restoring [views](views.html) that cannot be restored because their dependencies are not being restored at the same time.<br><br>Example: `WITH skip_missing_views`
-`encryption_passphrase`                                             | Passphrase used to create the [encrypted backup](take-and-restore-encrypted-backups.html) |  The passphrase used to decrypt the file(s) that were encrypted by the [`BACKUP`](take-and-restore-encrypted-backups.html) statement.
-`DETACHED`                                                          | N/A                                         | <span class="version-tag">New in v20.2:</span> When `RESTORE` runs with `DETACHED`, the job will execute asynchronously. The job ID is returned after the restore job creation completes. Note that with `DETACHED` specified, further job information and the job completion status will not be returned. For more on the differences between the returned job data, see the [example](restore.html#restore-a-backup-asynchronously) below. To check on the job status, use the [`SHOW JOBS`](show-jobs.html) statement. <br><br>To run a restore within a [transaction](transactions.html), use the `DETACHED` option.
-
-### Backup file URLs
-
-CockroachDB uses the URL provided to construct a secure API call to the service you specify. The URL structure depends on the type of file storage you are using. For more information, see the following:
-
-- [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html)
-- [Use a Local File Server for Bulk Operations](use-a-local-file-server-for-bulk-operations.html)
-
-## Functional details
-
-You can restore:
-
-- [A full cluster](#full-cluster)
-- [Databases](#databases)
-- [Tables](#tables)
-
-#### Full cluster
-
- A full cluster restore can only be run on a target cluster with no user-created databases or tables. Restoring a full cluster includes:
-
-- All user tables
-- Relevant system tables
-- All [databases](create-database.html)
-- All [tables](create-table.html) (which automatically includes their [indexes](indexes.html))
-- All [views](views.html)
-
-{{site.data.alerts.callout_info}}
-When you restore a full cluster with an Enterprise license, it will restore the [Enterprise license](enterprise-licensing.html) of the cluster you are restoring from. If you want to use a different license in the new cluster, make sure to [update the license](licensing-faqs.html#set-a-license) _after_ the restore is complete.
-{{site.data.alerts.end}}
-
-#### Databases
-
-**The database cannot already exist in the target cluster.** Restoring a database will create a new database and restore all of its tables and views. The created database will have the name of the database in the backup.
-
-~~~ sql
-RESTORE DATABASE backup_database_name FROM 'your_backup_location';
-~~~
-
-{{site.data.alerts.callout_success}}
-If [dropping](drop-database.html) or [renaming](rename-database.html) an existing database is not an option, you can use _table_ restore to restore all tables into a specific database by using the [`WITH into_db` option](#options).
-{{site.data.alerts.end}}
-
-#### Tables
-
-You can also restore individual tables (which automatically includes their indexes) or [views](views.html) from a backup. This process uses the data stored in the backup to create entirely new tables or views in the target database.
-
-By default, tables and views are restored into a target database matching the name of the database from which they were backed up. If the target database does not exist, you must [create it](create-database.html). You can choose to change the target database with the [`into_db` option](#into_db).
-
-The target database must not have tables or views with the same name as the tables or views you're restoring. If any of the restore target's names are being used, you can:
-
-- [`DROP TABLE`](drop-table.html), [`DROP VIEW`](drop-view.html), or [`DROP SEQUENCE`](drop-sequence.html) and then restore them. Note that a sequence cannot be dropped while it is being used in a column's `DEFAULT` expression, so those expressions must be dropped before the sequence is dropped, and recreated after the sequence is recreated. The `setval` [function](functions-and-operators.html#sequence-functions) can be used to set the value of the sequence to what it was previously.
-- [Restore the table or view into a different database](#into_db).
-
-{{site.data.alerts.callout_info}}
-`RESTORE` only offers table-level granularity; it _does not_ support restoring subsets of a table.
-{{site.data.alerts.end}}
-
-<span class="version-tag">New in v20.2:</span> When restoring an individual table that references a user-defined type (e.g., [`ENUM`](enum.html)), CockroachDB will first check to see if the type already exists. The restore will attempt the following for each user-defined type within a table backup:
-
-- If there is _not_ an existing type in the cluster with the same name, CockroachDB will create the user-defined type as it exists in the backup.
-- If there is an existing type in the cluster with the same name that is compatible with the type in the backup, CockroachDB will map the type in the backup to the type in the cluster.
-- If there is an existing type in the cluster with the same name but it is _not_ compatible with the type in the backup, the restore will not succeed and you will be asked to resolve the naming conflict. You can do this by either [dropping](drop-type.html) or [renaming](alter-type.html) the existing user-defined type.
-
-In general, two types are compatible if they are the same kind (e.g., an enum is only compatible with other enums). Additionally, enums are only compatible if they have the same ordered set of elements that have also been [created in the same way](https://github.com/cockroachdb/cockroach/blob/master/docs/RFCS/20200331_enums.md#physical-layout). For example:
-
-- `CREATE TYPE t1 AS ENUM ('yes', 'no')` and `CREATE TYPE t2 AS ENUM ('yes', 'no')` are compatible.
-- `CREATE TYPE t1 AS ENUM ('yes', 'no')` and `CREATE TYPE t2 AS ENUM ('no', 'yes')` are not compatible.
-- `CREATE TYPE t1 AS ENUM ('yes', 'no')` and `CREATE TYPE t2 AS ENUM ('yes'); ALTER TYPE t2 ADD VALUE ('no')` are not compatible because they were not created in the same way.
-
-
-### Object dependencies
-
-Dependent objects must be restored at the same time as the objects they depend on.
-
-Object | Depends On
--------|-----------
-Table with [foreign key](foreign-key.html) constraints | The table it `REFERENCES` (however, this dependency can be [removed during the restore](#skip_missing_foreign_keys)).
-Table with a [sequence](create-sequence.html) | The sequence.
-[Views](views.html) | The tables used in the view's `SELECT` statement.
-[Interleaved tables](interleave-in-parent.html) | The parent table in the [interleaved hierarchy](interleave-in-parent.html#interleaved-hierarchy).
-
-### Users and privileges
-
-To restore your users and privilege [grants](grant.html), you can do a cluster backup and restore the cluster to a fresh cluster with no user data.
-
-If you are not doing a full cluster restore, the table-level privileges need to be granted to the users after the restore is complete. To do this, backup the `system.users` table, [restore users and their passwords](restore.html#restoring-users-from-system-users-backup), and then [grant](grant.html) the table-level privileges.
-
-### Restore types
-
-You can either restore from a full backup or from a full backup with incremental backups, based on the backup files you include:
-
-Restore Type | Parameters
--------------|----------
-Full backup | Include only the path to the full backup.
-Full backup + <br>incremental backups | If the full backup and incremental backups were sent to the same destination, include only the path to the full backup (e.g., `RESTORE FROM 'full_backup_location';`).<br><br>If the incremental backups were sent to a different destination from the full backup, include the path to the full backup as the first argument and the subsequent incremental backups from oldest to newest as the following arguments (e.g., `RESTORE FROM 'full_backup_location', 'incremental_location_1', 'incremental_location_2';`).
-
-## Performance
-
-The `RESTORE` process minimizes its impact to the cluster's performance by distributing work to all nodes. Subsets of the restored data (known as ranges) are evenly distributed among randomly selected nodes, with each range initially restored to only one node. Once the range is restored, the node begins replicating it others.
-
-{{site.data.alerts.callout_info}}
-When a `RESTORE` fails or is canceled, partially restored data is properly cleaned up. This can have a minor, temporary impact on cluster performance.
-{{site.data.alerts.end}}
-
-## Viewing and controlling restore jobs
-
-After CockroachDB successfully initiates a restore, it registers the restore as a job, which you can view with [`SHOW JOBS`](show-jobs.html).
-
-After the restore has been initiated, you can control it with [`PAUSE JOB`](pause-job.html), [`RESUME JOB`](resume-job.html), and [`CANCEL JOB`](cancel-job.html).
-
-{{site.data.alerts.callout_info}}
-If initiated correctly, the statement returns when the restore is finished or if it encounters an error. In some cases, the restore can continue after an error has been returned (the error message will tell you that the restore has resumed in background).
-{{site.data.alerts.end}}
-
-## Known limitations
-
-{% include {{ page.version.version }}/known-limitations/restore-aost.md %}
-
-## Examples
-
-### Restore a cluster
-
- To restore a full cluster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM 'gs://acme-co-backup/test-cluster';
-~~~
-
-### Restore a database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE DATABASE bank FROM 'gs://acme-co-backup/database-bank-2017-03-27-weekly';
-~~~
-
-{{site.data.alerts.callout_info}}
-`RESTORE DATABASE` can only be used if the entire database was backed up.
-{{site.data.alerts.end}}
-
-### Restore a table
-
-To restore a single table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE bank.customers FROM 'gs://acme-co-backup/database-bank-2017-03-27-weekly';
-~~~
-
-To restore multiple tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE bank.customers, bank.accounts FROM 'gs://acme-co-backup/database-bank-2017-03-27-weekly';
-~~~
-
-### Restore from incremental backups
-
-Restoring from incremental backups requires previous full and incremental backups. To restore from a destination containing the full backup, as well as the incremental backups (stored as subdirectories):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM 'gs://acme-co-backup/test-cluster';
-~~~
-
-To explicitly point to where your incremental backups are, provide the previous full and incremental backup locations in a comma-separated list. In this example, `-weekly` is the full backup and the two `-nightly` are incremental backups.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE bank.customers \
-FROM 'gs://acme-co-backup/database-bank-2017-03-27-weekly', 'gs://acme-co-backup/database-bank-2017-03-28-nightly', 'gs://acme-co-backup/database-bank-2017-03-29-nightly';
-~~~
-
-{{site.data.alerts.callout_info}}
-If you are restoring from HTTP storage, provide the previous full and incremental backup locations in a comma-separated list. You cannot use the simplified syntax.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-`RESTORE` will re-validate [indexes](indexes.html) when [incremental backups](take-full-and-incremental-backups.html) are created from an older version, but restored from a newer version.
-
-Incremental backups created by v20.2.2 and prior v20.2.x releases or v20.1.4 and prior v20.1.x releases may include incomplete data for indexes that were in the process of being created. Therefore, when incremental backups taken by these versions are restored by v20.2.8+, any indexes created during those incremental backups will be re-validated by `RESTORE`.
-{{site.data.alerts.end}}
-
-### Restore a backup asynchronously
-
-<span class="version-tag">New in v20.2:</span> Use the `DETACHED` [option](#options) to execute the restore job asynchronously:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM \
-'gs://acme-co-backup/test-cluster' \
-WITH DETACHED;
-~~~
-
-The job ID is returned after the restore job creation completes: 
-
-~~~
-        job_id
-----------------------
-  592786066399264769
-(1 row)
-~~~
-
-**Without** the `DETACHED` option, `RESTORE` will block the SQL connection until the job completes. Once finished, the job status and more detailed job data is returned:
-
-~~~
-job_id             |  status   | fraction_completed | rows | index_entries | bytes
----------------------+-----------+--------------------+------+---------------+--------
-652471804772712449 | succeeded |                  1 |   50 |             0 |  4911
-(1 row)
-~~~
-
-### Other restore usages
-
-#### Restore tables into a different database
-
-By default, tables and views are restored to the database they originally belonged to. However, using the [`into_db` option](#into_db), you can control the target database.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE bank.customers \
-FROM 'gs://acme-co-backup/database-bank-2017-03-27-weekly' \
-WITH into_db = 'newdb';
-~~~
-
-#### Remove the foreign key before restore
-
-By default, tables with [Foreign Key](foreign-key.html) constraints must be restored at the same time as the tables they reference. However, using the [`skip_missing_foreign_keys`](restore.html#skip_missing_foreign_keys) option you can remove the Foreign Key constraint from the table and then restore it.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE bank.accounts \
-FROM 'gs://acme-co-backup/database-bank-2017-03-27-weekly' \
-WITH skip_missing_foreign_keys;
-~~~
-
-#### Restoring users from `system.users` backup
-
-The `system.users` table stores your cluster's usernames and their hashed passwords. To restore them, you must restore the `system.users` table into a new database because you cannot drop the existing `system.users` table.
-
-After it's restored into a new database, you can write the restored `users` table data to the cluster's existing `system.users` table.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE newdb;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE system.users \
-FROM 'azure://acme-co-backup/table-users-2017-03-27-full?AZURE_ACCOUNT_KEY=hash&AZURE_ACCOUNT_NAME=acme-co' \
-WITH into_db = 'newdb';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO system.users SELECT * FROM newdb.users;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TABLE newdb.users;
-~~~
-
-## See also
-
-- [`BACKUP`][backup]
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Take and Restore Encrypted Backups](take-and-restore-encrypted-backups.html)
-- [Take and Restore Locality-aware Backups](take-and-restore-locality-aware-backups.html)
-- [Take Backups with Revision History and Restore from a Point-in-time](take-backups-with-revision-history-and-restore-from-a-point-in-time.html)
-- <span class="version-tag">New in v20.2:</span> [Manage a Backup Schedule](manage-a-backup-schedule.html)
-- [Configure Replication Zones](configure-replication-zones.html)
-- [`ENUM`](enum.html)
-- [`CREATE TYPE`](create-type.html)
-- [`DROP TYPE`](drop-type.html)
-
-<!-- Reference links -->
-
-[backup]:  backup.html
-[restore]: restore.html
diff --git a/src/current/v20.2/resume-job.md b/src/current/v20.2/resume-job.md
deleted file mode 100644
index a5ada7a434f..00000000000
--- a/src/current/v20.2/resume-job.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: RESUME JOB
-summary: The RESUME JOB statement lets you resume jobs that were previously paused with PAUSE JOB.
-toc: true
----
-
- The `RESUME JOB` [statement](sql-statements.html) lets you resume the following types of jobs:
-
- - [`IMPORT`](import.html) jobs
- - [`BACKUP`](backup.html) and [`RESTORE`](restore.html) jobs
- - [User-created table statistics](create-statistics.html) jobs
- - [Automatic table statistics](cost-based-optimizer.html#table-statistics) jobs
- - [Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html)
- - [Schema change](online-schema-changes.html) jobs
- - <span class="version-tag">New in v20.2:</span> [Scheduled backup](manage-a-backup-schedule.html) jobs
-
-## Required privileges
-
-To resume a job, the user must be a member of the `admin` role or must have the [`CONTROLJOB`](create-user.html#create-a-user-that-can-pause-resume-and-cancel-non-admin-jobs) parameter set.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/resume_job.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`job_id` | The ID of the job you want to resume, which can be found with [`SHOW JOBS`](show-jobs.html).
-`select_stmt` | A [selection query](selection-queries.html) that returns `job_id`(s) to resume.
-`for_schedules_clause` | <span class="version-tag">New in v20.2:</span> The schedule you want to resume jobs for. You can resume jobs for a specific schedule (`FOR SCHEDULE id`) or resume jobs for multiple schedules by nesting a [`SELECT` clause](select-clause.html) in the statement (`FOR SCHEDULES <select_clause>`). See the [examples](#resume-jobs-for-a-schedule) below.
-
-## Examples
-
-### Pause a job
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW JOBS;
-~~~
-
-~~~
-      job_id     |  job_type |               description                 |...
------------------+-----------+-------------------------------------------+...
-  27536791415282 |  RESTORE  | RESTORE db.* FROM 'azure://backup/db/tbl' |...
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOB 27536791415282;
-~~~
-
-### Resume a single job
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOB 27536791415282;
-~~~
-
-### Resume multiple jobs
-
-To resume multiple jobs, nest a [`SELECT` clause](select-clause.html) that retrieves `job_id`(s) inside the `RESUME JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOBS (SELECT job_id FROM [SHOW JOBS]
-      WHERE user_name = 'maxroach');
-~~~
-
-All jobs created by `maxroach` will be resumed.
-
-### Resume jobs for a schedule
-
-<span class="version-tag">New in v20.2:</span> To resume jobs for a specific [backup schedule](create-schedule-for-backup.html), use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOBS FOR SCHEDULE 590204387299262465;
-~~~
-~~~
-RESUME JOBS FOR SCHEDULES 1
-~~~
-
-You can also resume multiple schedules by nesting a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `PAUSE JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOBS FOR SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'test_schedule';
-~~~
-
-~~~
-RESUME JOBS FOR SCHEDULES 2
-~~~
-
-## See also
-
-- [`PAUSE JOB`](pause-job.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`IMPORT`](import.html)
-- [`CREATE CHANGEFEED`](create-changefeed.html)
diff --git a/src/current/v20.2/resume-schedules.md b/src/current/v20.2/resume-schedules.md
deleted file mode 100644
index 533f68cfecc..00000000000
--- a/src/current/v20.2/resume-schedules.md
+++ /dev/null
@@ -1,82 +0,0 @@
----
-title: RESUME SCHEDULES
-summary: The RESUME SCHEDULES statement lets you resume jobs that were previously paused with PAUSE SCHEDULE.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `RESUME SCHEDULES` [statement](sql-statements.html) can be used to resume [paused backup schedules](pause-schedules.html). When a schedule is resumed, the `next_run` will be set to the next `TIMESTAMP` that conforms to the schedule.
-
-## Required privileges
-
-Only members of the [`admin` role](authorization.html#default-roles) can resume a schedule. By default, the `root` user belongs to the `admin` role.
-
-## Synopsis
-
-~~~
-RESUME SCHEDULES <selectclause>
- selectclause: select statement returning schedule IDs to resume.
-
-RESUME SCHEDULE <scheduleID>
-~~~
-
-## Parameters
-
- Parameter     | Description
----------------+------------
-`selectclause` | A [selection query](selection-queries.html) that returns `id`(s) to resume.
-`scheduleID`   | The `id` of the schedule you want to resume, which can be found with [`SHOW SCHEDULES`](show-schedules.html).
-
-## Examples
-
-### Pause a schedule
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE SCHEDULE 589963390487363585;
-~~~
-
-~~~
-PAUSE SCHEDULES 1
-~~~
-
-### Resume a single schedule
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME SCHEDULE 589963390487363585;
-~~~
-
-~~~
-RESUME SCHEDULES 1
-~~~
-
-### Resume multiple schedules
-
-To resume multiple schedules, nest a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `RESUME SCHEDULES` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'schedule_database';
-~~~
-
-~~~
-RESUME SCHEDULES 4
-~~~
-
-All schedules with the label `schedule_database` are resumed.
-
-## See also
-
-- [Manage a Backup Schedule](manage-a-backup-schedule.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`SHOW BACKUP`](show-backup.html)
-- [`SHOW SCHEDULES`](show-schedules.html)
-- [`PAUSE SCHEDULES`](pause-schedules.html)
-- [`DROP SCHEDULES`](drop-schedules.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`RESUME JOB`](pause-job.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/revoke-roles.md b/src/current/v20.2/revoke-roles.md
deleted file mode 100644
index 78e12ea6394..00000000000
--- a/src/current/v20.2/revoke-roles.md
+++ /dev/null
@@ -1,106 +0,0 @@
----
-title: REVOKE &lt;roles&gt;
-summary: The REVOKE <roles> statement revokes privileges from users and/or roles.
-toc: true
----
-
-The `REVOKE <roles>` [statement](sql-statements.html) lets you revoke a [role](authorization.html#create-and-manage-roles) or [user's](authorization.html#create-and-manage-users) membership to a role.
-
-{{site.data.alerts.callout_info}}
- <code>REVOKE &lt;roles&gt;</code> is no longer an Enterprise feature and is now freely available in the core version of CockroachDB.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/revoke_roles.html %}
-</div>
-
-## Required privileges
-
-The user revoking role membership must be a role admin (i.e., members with the `WITH ADMIN OPTION`) or a member of the `admin` role.
-
-To remove membership to the `admin` role, the user must have `WITH ADMIN OPTION` on the `admin` role.
-
-## Considerations
-
-- The `root` user cannot be revoked from the `admin` role.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`ADMIN OPTION` | Revoke the user's role admin status.
-`role_name` | The name of the role from which you want to remove members. To revoke members from multiple roles, use a comma-separated list of role names.
-`user_name` | The name of the [user](authorization.html#create-and-manage-users) or [role](authorization.html#create-and-manage-roles) from whom you want to revoke membership. To revoke multiple members, use a comma-separated list of user and/or role names.
-
-## Examples
-
-### Revoke role membership
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON ROLE design;
-~~~
-
-~~~
-+--------+---------+---------+
-|  role  | member  | isAdmin |
-+--------+---------+---------+
-| design | barkley | false   |
-| design | ernie   | true    |
-| design | lola    | false   |
-| design | lucky   | false   |
-+--------+---------+---------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE design FROM lola;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON ROLE design;
-~~~
-
-~~~
-+--------+---------+---------+
-|  role  | member  | isAdmin |
-+--------+---------+---------+
-| design | barkley | false   |
-| design | ernie   | true    |
-| design | lucky   | false   |
-+--------+---------+---------+
-~~~
-
-### Revoke the admin option
-
-To revoke a user or role's admin option from a role (without revoking the membership):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE ADMIN OPTION FOR design FROM ernie;
-~~~
-
-~~~
-+--------+---------+---------+
-|  role  | member  | isAdmin |
-+--------+---------+---------+
-| design | barkley | false   |
-| design | ernie   | false   |
-| design | lucky   | false   |
-+--------+---------+---------+
-~~~
-
-## See also
-
-- [Authorization](authorization.html)
-- [`GRANT <roles>`](grant-roles.html)
-- [`GRANT <privileges>`](grant.html)
-- [`REVOKE <privileges>`](revoke.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [`SHOW ROLES`](show-roles.html)
-- [`CREATE USER`](create-user.html)
-- [`DROP USER`](drop-user.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/revoke.md b/src/current/v20.2/revoke.md
deleted file mode 100644
index c0cc5d171f3..00000000000
--- a/src/current/v20.2/revoke.md
+++ /dev/null
@@ -1,328 +0,0 @@
----
-title: REVOKE &lt;privileges&gt;
-summary: The REVOKE statement revokes privileges from users and/or roles.
-toc: true
----
-
-The `REVOKE <privileges>` [statement](sql-statements.html) revokes [privileges](authorization.html#assign-privileges) from [users](authorization.html#create-and-manage-users) and/or [roles](authorization.html#create-and-manage-roles).
-
-For the list of privileges that can be granted to and revoked from users and roles, see [`GRANT`](grant.html).
-
-## Syntax
-
-### Revoke privileges
-
-To revoke privileges from a user or role, use the following syntax:
-
-~~~
-REVOKE {ALL | <privileges...> } ON {DATABASE | SCHEMA | TABLE | TYPE} <targets...> FROM <grantees...>
-~~~
-
-### Revoke `admin`
-
-To revoke the [`admin`](authorization.html#role-admin) privileges from a role, use the following syntax:
-
-~~~
-REVOKE [ADMIN OPTION FOR] <roles...> FROM <grantees...>
-~~~
-
-## Parameters
-
-Parameter       | Description
-----------------|------------
-`ALL`           | Revoke all [privileges](#supported-privileges).
-`privileges`    | A comma-separated list of privileges to revoke. For a list of supported privileges, see [Supported privileges](#supported-privileges).
-`targets`       | A comma-separated list of database, schema, table, or user-defined type names.<br><br>{{site.data.alerts.callout_info}}To revoke privileges from all tables in a database or schema, you can use `REVOKE ... ON TABLE *`. For an example, see [Revoke privileges on all tables in a database or schema](#revoke-privileges-on-all-tables-in-a-database-or-schema).{{site.data.alerts.end}}
-`grantees`         | A comma-separated list of [users](authorization.html#create-and-manage-users) and/or [roles](authorization.html#create-and-manage-roles) from whom to revoke privileges.
-
-## Supported privileges
-
-The following privileges can be revoked:
-
-{% include {{ page.version.version }}/sql/privileges.md %}
-
-## Required privileges
-
-The user revoking privileges must have the `GRANT` privilege on the target [database](create-database.html), [schema](create-schema.html), [table](create-table.html), or [user-defined type](enum.html).
-
-In addition to the `GRANT` privilege, the user revoking privileges must have the privilege being revoked on the target object. For example, a user revoking the `SELECT` privilege on a table to another user must have the `GRANT` and `SELECT` privileges on that table.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Revoke privileges on databases
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE USER max WITH PASSWORD roach;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT CREATE ON DATABASE movr TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON DATABASE movr;
-~~~
-
-~~~
-  database_name |    schema_name     | grantee | privilege_type
-----------------+--------------------+---------+-----------------
-  movr          | crdb_internal      | admin   | ALL
-  movr          | crdb_internal      | max     | CREATE
-  movr          | crdb_internal      | root    | ALL
-  movr          | information_schema | admin   | ALL
-  movr          | information_schema | max     | CREATE
-  movr          | information_schema | root    | ALL
-  movr          | pg_catalog         | admin   | ALL
-  movr          | pg_catalog         | max     | CREATE
-  movr          | pg_catalog         | root    | ALL
-  movr          | pg_extension       | admin   | ALL
-  movr          | pg_extension       | max     | CREATE
-  movr          | pg_extension       | root    | ALL
-  movr          | public             | admin   | ALL
-  movr          | public             | max     | CREATE
-  movr          | public             | root    | ALL
-(15 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE CREATE ON DATABASE movr FROM max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON DATABASE movr;
-~~~
-
-~~~
-  database_name |    schema_name     | grantee | privilege_type
-----------------+--------------------+---------+-----------------
-  movr          | crdb_internal      | admin   | ALL
-  movr          | crdb_internal      | root    | ALL
-  movr          | information_schema | admin   | ALL
-  movr          | information_schema | root    | ALL
-  movr          | pg_catalog         | admin   | ALL
-  movr          | pg_catalog         | root    | ALL
-  movr          | pg_extension       | admin   | ALL
-  movr          | pg_extension       | root    | ALL
-  movr          | public             | admin   | ALL
-  movr          | public             | root    | ALL
-(10 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-Any tables that previously inherited the database-level privileges retain the privileges.
-{{site.data.alerts.end}}
-
-### Revoke privileges on specific tables in a database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT DELETE ON TABLE rides TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE rides;
-~~~
-
-~~~
-  database_name | schema_name | table_name | grantee | privilege_type
-----------------+-------------+------------+---------+-----------------
-  movr          | public      | rides      | admin   | ALL
-  movr          | public      | rides      | max     | DELETE
-  movr          | public      | rides      | root    | ALL
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE DELETE ON TABLE rides FROM max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE rides;
-~~~
-
-~~~
-  database_name | schema_name | table_name | grantee | privilege_type
-----------------+-------------+------------+---------+-----------------
-  movr          | public      | rides      | admin   | ALL
-  movr          | public      | rides      | root    | ALL
-(2 rows)
-~~~
-
-### Revoke privileges on all tables in a database or schema
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT CREATE, SELECT, DELETE ON TABLE rides, users TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE movr.*;
-~~~
-
-~~~
-  database_name | schema_name |         table_name         | grantee | privilege_type
-----------------+-------------+----------------------------+---------+-----------------
-  movr          | public      | promo_codes                | admin   | ALL
-  movr          | public      | promo_codes                | root    | ALL
-  movr          | public      | rides                      | admin   | ALL
-  movr          | public      | rides                      | max     | CREATE
-  movr          | public      | rides                      | max     | DELETE
-  movr          | public      | rides                      | max     | SELECT
-  movr          | public      | rides                      | root    | ALL
-  movr          | public      | user_promo_codes           | admin   | ALL
-  movr          | public      | user_promo_codes           | root    | ALL
-  movr          | public      | users                      | admin   | ALL
-  movr          | public      | users                      | max     | CREATE
-  movr          | public      | users                      | max     | DELETE
-  movr          | public      | users                      | max     | SELECT
-  movr          | public      | users                      | root    | ALL
-  movr          | public      | vehicle_location_histories | admin   | ALL
-  movr          | public      | vehicle_location_histories | root    | ALL
-  movr          | public      | vehicles                   | admin   | ALL
-  movr          | public      | vehicles                   | root    | ALL
-(18 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE DELETE ON movr.* FROM max;
-~~~
-
-~~~
-  database_name | schema_name |         table_name         | grantee | privilege_type
-----------------+-------------+----------------------------+---------+-----------------
-  movr          | public      | promo_codes                | admin   | ALL
-  movr          | public      | promo_codes                | root    | ALL
-  movr          | public      | rides                      | admin   | ALL
-  movr          | public      | rides                      | max     | CREATE
-  movr          | public      | rides                      | max     | SELECT
-  movr          | public      | rides                      | root    | ALL
-  movr          | public      | user_promo_codes           | admin   | ALL
-  movr          | public      | user_promo_codes           | root    | ALL
-  movr          | public      | users                      | admin   | ALL
-  movr          | public      | users                      | max     | CREATE
-  movr          | public      | users                      | max     | SELECT
-  movr          | public      | users                      | root    | ALL
-  movr          | public      | vehicle_location_histories | admin   | ALL
-  movr          | public      | vehicle_location_histories | root    | ALL
-  movr          | public      | vehicles                   | admin   | ALL
-  movr          | public      | vehicles                   | root    | ALL
-(16 rows)
-~~~
-
-
-### Revoke privileges on schemas
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA cockroach_labs;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON SCHEMA cockroach_labs TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON SCHEMA cockroach_labs;
-~~~
-
-~~~
-  database_name |  schema_name   | grantee | privilege_type
-----------------+----------------+---------+-----------------
-  movr          | cockroach_labs | admin   | ALL
-  movr          | cockroach_labs | max     | ALL
-  movr          | cockroach_labs | root    | ALL
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE CREATE ON SCHEMA cockroach_labs FROM max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON SCHEMA cockroach_labs;
-~~~
-
-~~~
-  database_name |  schema_name   | grantee | privilege_type
-----------------+----------------+---------+-----------------
-  movr          | cockroach_labs | admin   | ALL
-  movr          | cockroach_labs | max     | GRANT
-  movr          | cockroach_labs | max     | USAGE
-  movr          | cockroach_labs | root    | ALL
-(4 rows)
-~~~
-
-### Revoke privileges on user-defined types
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE status AS ENUM ('available', 'unavailable');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON TYPE status TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TYPE status;
-~~~
-
-~~~
-  database_name | schema_name | type_name | grantee | privilege_type
-----------------+-------------+-----------+---------+-----------------
-  movr          | public      | status    | admin   | ALL
-  movr          | public      | status    | max     | ALL
-  movr          | public      | status    | public  | USAGE
-  movr          | public      | status    | root    | ALL
-(4 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REVOKE GRANT ON TYPE status FROM max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TYPE status;
-~~~
-
-~~~
-  database_name | schema_name | type_name | grantee | privilege_type
-----------------+-------------+-----------+---------+-----------------
-  movr          | public      | status    | admin   | ALL
-  movr          | public      | status    | max     | USAGE
-  movr          | public      | status    | public  | USAGE
-  movr          | public      | status    | root    | ALL
-(4 rows)
-~~~
-
-## See also
-
-- [Authorization](authorization.html)
-- [`GRANT <privileges>`](grant.html)
-- [`GRANT <roles>`](grant-roles.html)
-- [`REVOKE <roles>`](revoke-roles.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [`SHOW ROLES`](show-roles.html)
-- [`CREATE USER`](create-user.html)
-- [`DROP USER`](drop-user.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/rollback-transaction.md b/src/current/v20.2/rollback-transaction.md
deleted file mode 100644
index 3c0ce711e38..00000000000
--- a/src/current/v20.2/rollback-transaction.md
+++ /dev/null
@@ -1,116 +0,0 @@
----
-title: ROLLBACK
-summary: Rolls back the current transaction and all of its nested sub-transactions, discarding all transactional updates made by statements inside the transaction.
-toc: true
----
-
-The `ROLLBACK` [statement](sql-statements.html) aborts the current [transaction](transactions.html) and all of its [nested transactions](transactions.html#nested-transactions), discarding all transactional updates made by statements included in the transaction.
-
-There are two ways to use `ROLLBACK`:
-
-- The `ROLLBACK` statement [rolls back the entire transaction](#rollback-a-transaction).
-
--  The `ROLLBACK TO SAVEPOINT` statement [rolls back and restarts the nested transaction](#rollback-a-nested-transaction) started at the corresponding `SAVEPOINT` statement, for working with [standard savepoints](savepoint.html#savepoints-for-nested-transactions).  This is in addition to the existing support for working with [client-side transaction retries](transactions.html#client-side-intervention).  For examples of each usage, see:
-
-  - [Rollback a nested transaction](#rollback-a-nested-transaction)
-  - [Retry a transaction](#retry-a-transaction)
-
-{% include {{page.version.version}}/sql/savepoint-ddl-rollbacks.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/rollback_transaction.html %}
-</div>
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to rollback a transaction. However, privileges are required for each statement within a transaction.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `TO SAVEPOINT cockroach_restart` | If using [advanced client-side transaction retries](advanced-client-side-transaction-retries.html), retry the transaction. You should execute this statement when a transaction returns a `40001` / `retry transaction` error.
- `TO SAVEPOINT <name>` | If using [nested transactions](savepoint.html#savepoints-for-nested-transactions), roll back and restart the [nested transaction](transactions.html#nested-transactions) started at the corresponding `SAVEPOINT` statement.
-
-## Savepoints and row locks
-
-{% include {{page.version.version}}/sql/savepoints-and-row-locks.md %}
-
-## Savepoints and high priority transactions
-
-{% include {{page.version.version}}/sql/savepoints-and-high-priority-transactions.md %}
-
-## Examples
-
-### Rollback a transaction
-
-Typically, an application conditionally executes rollbacks, but we can see their behavior by using `ROLLBACK` instead of `COMMIT` directly through SQL:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-+----------+---------+
-|   name   | balance |
-+----------+---------+
-| Marciela |    1000 |
-+----------+---------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE accounts SET balance = 2500 WHERE name = 'Marciela';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ROLLBACK;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-+----------+---------+
-|   name   | balance |
-+----------+---------+
-| Marciela |    1000 |
-+----------+---------+
-~~~
-
-### Rollback a nested transaction
-
-The `ROLLBACK TO SAVEPOINT` statement rolls back and restarts the [nested transaction](transactions.html#nested-transactions) started at the corresponding `SAVEPOINT` statement.
-
-For examples showing how to use `ROLLBACK TO SAVEPOINT` to rollback a nested transaction, see [the `SAVEPOINT` documentation on nested savepoints](savepoint.html#savepoints-for-nested-transactions).
-
-### Retry a transaction
-
-When using [advanced client-side transaction retries](advanced-client-side-transaction-retries.html), use `ROLLBACK TO SAVEPOINT` to handle a transaction that needs to be retried (identified via the `40001` error code or `restart transaction` string in the error message), and then re-execute the statements you want the transaction to contain.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ROLLBACK TO SAVEPOINT cockroach_restart;
-~~~
-
-For examples of retrying transactions in an application, check out the transaction code samples in our [Build an App with CockroachDB](example-apps.html) tutorials.
-
-## See also
-
-- [`SAVEPOINT`](savepoint.html)
-- [Transactions](transactions.html)
-- [`BEGIN`](begin-transaction.html)
-- [`COMMIT`](commit-transaction.html)
-- [`RELEASE SAVEPOINT`](release-savepoint.html)
-- [`SHOW SAVEPOINT STATUS`](show-savepoint-status.html)
diff --git a/src/current/v20.2/rotate-certificates.md b/src/current/v20.2/rotate-certificates.md
deleted file mode 100644
index 7f6475b605f..00000000000
--- a/src/current/v20.2/rotate-certificates.md
+++ /dev/null
@@ -1,151 +0,0 @@
----
-title: Rotate Security Certificates
-summary: Rotate the security certificates of a secure CockroachDB cluster by creating and reloading new certificates.
-toc: true
----
-
-CockroachDB allows you to rotate security certificates without restarting nodes.
-
-{{site.data.alerts.callout_success}}For an introduction to how security certificates work in a secure CockroachDB cluster, see <a href="cockroach-cert.html">Create Security Certificates</a>.{{site.data.alerts.end}}
-
-
-## When to rotate certificates
-
-You may need to rotate the node, client, or CA certificates in the following scenarios:
-
-- The node, client, or CA certificates are expiring soon.
-- Your organization's compliance policy requires periodical certificate rotation.
-- The key (for a node, client, or CA) is compromised.
-- You need to modify the contents of a certificate, for example, to add another DNS name or the IP address of a load balancer through which a node can be reached. In this case, you would need to rotate only the node certificates.
-
-### Rotate client certificates
-
-1. Create a new client certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-client <username> \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-2. Upload the new client certificate and key to the client using your preferred method.
-
-3. Have the client use the new client certificate.
-
-    This step is application-specific and may require restarting the client.
-
-### Rotate node certificates
-
-To rotate a node certificate, you create a new node certificate and key and reload them on the node.
-
-1. Create a new node certificate and key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    <node hostname> \
-    <node other hostname> \
-    <node yet another hostname> \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key \
-    --overwrite
-    ~~~
-
-    Since you must create the new certificate and key in the same directory as the existing certificate and key, use the `--overwrite` flag to overwrite the existing files. Also, be sure to specify all addresses at which node can be reached.
-
-2. Upload the node certificate and key to the node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp certs/node.crt \
-    certs/node.key \
-    <username>@<node address>:~/certs
-    ~~~
-
-3. Reload the node certificate without restarting the node by issuing a `SIGHUP` signal to the `cockroach` process:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    pkill -SIGHUP -x cockroach
-    ~~~
-
-    The `SIGHUP` signal must be sent by the same user running the process (e.g., run with `sudo` if the `cockroach` process is running under user `root`).
-
-4. Verify that certificate rotation was successful using the **Local Node Certificates** page in the DB Console: `https://<address of node with new certs>:8080/#/reports/certificates/local`.
-
-    Scroll to the node certificate details and confirm that the **Valid Until** field shows the new certificate expiration time.
-
-### Rotate the CA certificate
-
-To rotate the CA certificate, you create a new CA key and a combined CA certificate that contains the new CA certificate followed by the old CA certificate, and then you reload the new combined CA certificate on the nodes and clients. Once all nodes and clients have the combined CA certificate, you then create new node and client certificates signed with the new CA certificate and reload those certificates on the nodes and clients as well.
-
-For more background, see [Why CockroachDB creates a combined CA certificate](rotate-certificates.html#why-cockroachdb-creates-a-combined-ca-certificate) and [Why rotate CA certificate in advance](rotate-certificates.html#why-rotate-ca-certificates-in-advance).
-
-1. Rename the existing CA key:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mv  my-safe-directory/ca.key my-safe-directory/ca.old.key
-    ~~~
-
-2. Create a new CA certificate and key, using the `--overwrite` flag to overwrite the old CA certificate:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-ca \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key \
-    --overwrite
-    ~~~
-
-    This results in the [combined CA certificate](rotate-certificates.html#why-cockroachdb-creates-a-combined-ca-certificate), `ca.crt`, which contains the new certificate followed by the old certificate.
-
-    {{site.data.alerts.callout_danger}}The CA key is never loaded automatically by <code>cockroach</code> commands, so it should be created in a separate directory, identified by the <code>--ca-key</code> flag.{{site.data.alerts.end}}
-
-2. Upload the new CA certificate to each node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ scp certs/ca.crt
-    <username>@<node1 address>:~/certs
-    ~~~
-
-3. Upload the new CA certificate to each client using your preferred method.
-
-4. On each node, reload the CA certificate without restarting the node by issuing a `SIGHUP` signal to the `cockroach` process:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    pkill -SIGHUP -x cockroach
-    ~~~
-
-    The `SIGHUP` signal must be sent by the same user running the process (e.g., run with `sudo` if the `cockroach` process is running under user `root`).
-
-5. Reload the CA certificate on each client.
-
-    This step is application-specific and may require restarting the client.
-
-6. Verify that certificate rotation was successful using the **Local Node Certificates** page in the DB Console: `https://<address of node with new certs>:8080/#/reports/certificates/local`.
-
-    The details of the old as well as new CA certificates should be shown. Confirm that the **Valid Until** field of the new CA certificate shows the new certificate expiration time.
-
-7. Once you are confident that all nodes and clients have the new CA certificate, [rotate the node certificates](#rotate-node-certificates) and [rotate the client certificates](#rotate-client-certificates).
-
-## Why CockroachDB creates a combined CA certificate
-
-On rotating the CA certificate, the nodes have the new CA certificate after certs directory is rescanned, and the clients have the new CA certificates when they are restarted. However, until the node and client certificates are rotated, the nodes and client certificates are still signed with the old CA certificate. Thus the nodes and clients are unable to verify each other's identity using the new CA certificate.
-
-To overcome the issue, we take advantage of the fact that multiple CA certificates can be active at the same time. While verifying the identity of another node or a client, they can check with multiple CA certificates uploaded to them. Thus instead of creating only the new certificate while rotating the CA certificates, CockroachDB creates a combined CA certificate that contains the new CA certificate followed by the old CA certificate. When node and client certificates are rotated, the combined CA certificate is used to verify old as well as new node and client certificates.
-
-## Why rotate CA certificates in advance
-
-On rotating node and client certificates after rotating the CA certificate, the node and client certificates are signed using new CA certificates. The nodes use the new node and CA certificates as soon as the certs directory on the node is rescanned. However, the clients use the new CA and client certificates only when the clients are restarted. Thus node certificates signed by the new CA certificate are not accepted by clients that do not have the new CA certificate yet. To ensure all nodes and clients have the latest CA certificate, rotate CA certificates on a completely different schedule; ideally, months before changing the node and client certificates.
-
-## See also
-
-- [Create Security Certificates](cockroach-cert.html)
-- [Manual Deployment](manual-deployment.html)
-- [Orchestrated Deployment](orchestration.html)
-- [Local Deployment](secure-a-cluster.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/run-multi-statement-transactions.md b/src/current/v20.2/run-multi-statement-transactions.md
deleted file mode 100644
index c5ae95dd763..00000000000
--- a/src/current/v20.2/run-multi-statement-transactions.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: Run Multi-Statement Transactions
-summary: How to use multi-statement transactions during application development
-toc: true
----
-
-This page has instructions for running [multi-statement transactions](transactions.html#batched-statements) against CockroachDB from various programming languages.
-
-## Before you begin
-
-Make sure you have already:
-
-- Set up a [local cluster](secure-a-cluster.html).
-- [Installed a Postgres client](install-client-drivers.html).
-- [Connected to the database](connect-to-the-database.html).
-- [Inserted data](insert-data.html) that you now want to run queries against.
-
-{% include {{page.version.version}}/app/retry-errors.md %}
-
-
-## Run a transaction
-
-<div class="filters filters__code clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go</button>
-  <button class="filter-button" data-scope="java">Java</button>
-  <button class="filter-button" data-scope="python">Python</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ sql
-BEGIN;
-DELETE FROM customers WHERE id = 1;
-DELETE orders WHERE customer = 1;
-COMMIT;
-~~~
-
-For more information about how to use the built-in SQL client, see the [`cockroach sql`](cockroach-sql.html) reference docs.
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-The best way to run a multi-statement transaction from Go code is to use one of the following approaches:
-
-- Use the [`crdb` transaction wrapper](https://github.com/cockroachdb/cockroach-go/tree/master/crdb) which automatically handles transaction retry errors if they occur, as shown in [Build a Go App with CockroachDB](build-a-go-app-with-cockroachdb.html).
-
-- Write your own retry loop wrapper, as shown in [Build a Go App with CockroachDB and GORM](build-a-go-app-with-cockroachdb-gorm.html)
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-The best way to run a multi-statement transaction from Java is to write a wrapper method that automatically handles transaction retry errors.
-
-For complete examples showing how to write and use such wrapper methods, see [Build a Java App with CockroachDB](build-a-java-app-with-cockroachdb.html).
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-The best way to run a multi-statement transaction from Python code is to use one of the following approaches:
-
-- Use the [sqlalchemy-cockroachdb](https://github.com/cockroachdb/sqlalchemy-cockroachdb) SQLAlchemy dialect, which automatically handles transaction retry errors if they occur, as shown in [Build a Python App with CockroachDB and SQLAlchemy](build-a-python-app-with-cockroachdb-sqlalchemy.html).
-
-- Write your own retry loop wrapper, as shown in [Build a Python App with CockroachDB](build-a-python-app-with-cockroachdb.html).
-
-</section>
-
-## See also
-
-Reference information related to this task:
-
-- [Transactions](transactions.html)
-- [Transaction retries](transactions.html#client-side-intervention)
-- [Batched statements](transactions.html#batched-statements)
-- [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention)
-- [`BEGIN`](begin-transaction.html)
-- [`COMMIT`](commit-transaction.html)
-
-Other common tasks:
-
-- [Connect to the Database](connect-to-the-database.html)
-- [Insert Data](insert-data.html)
-- [Query Data](query-data.html)
-- [Update Data](update-data.html)
-- [Delete Data](delete-data.html)
-- [Optimize Query Performance][fast]
-- [Error Handling and Troubleshooting](error-handling-and-troubleshooting.html)
-- [Hello World Example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[selection]: selection-queries.html
-[manual]: manual-deployment.html
-[orchestrated]: orchestration.html
-[fast]: make-queries-fast.html
-[paginate]: pagination.html
-[joins]: joins.html
diff --git a/src/current/v20.2/savepoint.md b/src/current/v20.2/savepoint.md
deleted file mode 100644
index 70f3080d0e1..00000000000
--- a/src/current/v20.2/savepoint.md
+++ /dev/null
@@ -1,300 +0,0 @@
----
-title: SAVEPOINT
-summary: A savepoint is a marker that defines the beginning of a nested transaction.
-toc: true
----
-
-A savepoint is a marker that defines the beginning of a [nested transaction](transactions.html#nested-transactions). This marker can be later used to commit or roll back just the effects of the nested transaction without affecting the progress of the enclosing transaction.
-
- CockroachDB supports [general purpose savepoints for nested transactions](#savepoints-for-nested-transactions), in addition to continued support for [special-purpose retry savepoints](#savepoints-for-client-side-transaction-retries).
-
-{% include {{page.version.version}}/sql/savepoint-ddl-rollbacks.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/savepoint.html %}
-</div>
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to create a savepoint. However, privileges are required for each statement within a transaction.
-
-## Parameters
-
-Parameter | Description
---------- | -----------
-name      | The name of the savepoint.  [Nested transactions](savepoint.html#savepoints-for-nested-transactions) can use any name for the savepoint. [Retry savepoints](savepoint.html#savepoints-for-client-side-transaction-retries) default to using the name `cockroach_restart`, but this can be customized using a session variable.  For more information, see [Customizing the retry savepoint name](savepoint.html#customizing-the-retry-savepoint-name).
-
-## Savepoints and row locks
-
-{% include {{page.version.version}}/sql/savepoints-and-row-locks.md %}
-
-## Savepoints and high priority transactions
-
-{% include {{page.version.version}}/sql/savepoints-and-high-priority-transactions.md %}
-
-## Examples
-
-The examples below use the following table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE kv (k INT PRIMARY KEY, v INT);
-~~~
-
-### Basic usage
-
-To establish a savepoint inside a transaction:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SAVEPOINT foo;
-~~~
-
-{{site.data.alerts.callout_info}}
-Due to the [rules for identifiers in our SQL grammar](keywords-and-identifiers.html#identifiers), `SAVEPOINT foo` and `SAVEPOINT Foo` define the same savepoint, whereas `SAVEPOINT "Foo"` defines another.
-{{site.data.alerts.end}}
-
-To roll back a transaction partially to a previously established savepoint:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ROLLBACK TO SAVEPOINT foo;
-~~~
-
-To forget a savepoint, and keep the effects of statements executed after the savepoint was established, use [`RELEASE SAVEPOINT`](release-savepoint.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RELEASE SAVEPOINT foo;
-~~~
-
-For example, the transaction below will insert the values `(1,1)` and `(3,3)` into the table, but not `(2,2)`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-INSERT INTO kv VALUES (1,1);
-SAVEPOINT my_savepoint;
-INSERT INTO kv VALUES (2,2);
-ROLLBACK TO SAVEPOINT my_savepoint;
-INSERT INTO kv VALUES (3,3);
-COMMIT;
-~~~
-
-### Savepoints for nested transactions
-
-Transactions can be nested using named savepoints.  [`RELEASE SAVEPOINT`](release-savepoint.html) and [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html) can both refer to a savepoint "higher" in the nesting hierarchy. When this occurs, all of the savepoints "under" the nesting are automatically released / rolled back too.  Specifically:
-
-- When a previous savepoint is rolled back, the statements entered after that savepoint are also rolled back.
-
-- When a previous savepoint is released, it commits; the statements entered after that savepoint are also committed.
-
-For more information about nested transactions, see [Nested transactions](transactions.html#nested-transactions).
-
-### Multi-level rollback with `ROLLBACK TO SAVEPOINT`
-
-Savepoints can be arbitrarily nested, and rolled back to the outermost level so that every subsequent statement is rolled back.
-
-For example, this transaction does not insert anything into the table.  Both `INSERT`s are rolled back:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT foo;
-INSERT INTO kv VALUES (5,5);
-SAVEPOINT bar;
-INSERT INTO kv VALUES (6,6);
-ROLLBACK TO SAVEPOINT foo;
-COMMIT;
-~~~
-
-### Multi-level commit with `RELEASE SAVEPOINT`
-
-Changes committed by releasing a savepoint commit all of the statements entered after that savepoint.
-
-For example, the following transaction inserts both `(2,2)` and `(4,4)` into the table when it releases the outermost savepoint:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT foo;
-INSERT INTO kv VALUES (2,2);
-SAVEPOINT bar;
-INSERT INTO kv VALUES (4,4);
-RELEASE SAVEPOINT foo;
-COMMIT;
-~~~
-
-### Multi-level rollback and commit in the same transaction
-
-Changes partially committed by a savepoint release can be rolled back by an outer savepoint.
-
-For example, the following transaction inserts only value `(5, 5)`. The values `(6,6)` and `(7,7)` are rolled back.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-INSERT INTO kv VALUES (5,5);
-SAVEPOINT foo;
-INSERT INTO kv VALUES (6,6);
-SAVEPOINT bar;
-INSERT INTO kv VALUES (7,7);
-RELEASE SAVEPOINT bar;
-ROLLBACK TO SAVEPOINT foo;
-COMMIT;
-~~~
-
-### Error recovery in nested transactions with `ROLLBACK TO SAVEPOINT`
-
-If `ROLLBACK TO SAVEPOINT` is used after a database error, it can also cancel the error state of the transaction.  Database errors move a transaction (or nested transaction) into an "Aborted" state.  In this state, the transaction will not execute any further SQL statements.
-
-You can use `ROLLBACK TO SAVEPOINT` to recover from a logical error in a nested transaction.  Logical errors include:
-
-- Unique index error (duplicate row)
-- Failed foreign key constraint check (row does not exist in referenced table)
-- Mistakes in queries (reference a column that does not exist)
-
-In addition, you can check the status of a nested transaction using the `SHOW TRANSACTION STATUS` statement as shown below.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT error1;
-INSERT INTO kv VALUES (5,5); -- Duplicate key error
-~~~
-
-~~~
-ERROR: duplicate key value (k)=(5) violates unique constraint "primary"
-SQLSTATE: 23505
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-SHOW TRANSACTION STATUS;
-~~~
-
-~~~
-  TRANSACTION STATUS
-----------------------
-  Aborted
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-ROLLBACK TO SAVEPOINT error1;
-INSERT INTO kv VALUES (6,6);
-COMMIT;
-~~~
-
-### Savepoint name visibility
-
-The name of a savepoint that was rolled back over is no longer visible afterward.
-
-For example, in the transaction below, the name "bar" is not visible after it was rolled back over:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT foo;
-SAVEPOINT bar;
-ROLLBACK TO SAVEPOINT foo;
-RELEASE SAVEPOINT bar;
-COMMIT;
-~~~
-
-~~~
-ERROR: savepoint bar does not exist
-SQLSTATE: 3B001
-~~~
-
-The [SQL client](cockroach-sql.html) prompt will now display an error state, which you can clear by entering [`ROLLBACK`](rollback-transaction.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-? ERROR> ROLLBACK;
-~~~
-
-~~~
-ROLLBACK
-~~~
-
-#### Savepoints and prepared statements
-
-Prepared statements (`PREPARE` / `EXECUTE`) are not transactional.  Therefore, prepared statements are not invalidated upon savepoint rollback.  As a result, the prepared statement was saved and executed inside the transaction, despite the rollback to the prior savepoint:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT foo;
-PREPARE bar AS SELECT 1;
-ROLLBACK TO SAVEPOINT foo;
-EXECUTE bar;
-COMMIT;
-~~~
-
-~~~
-  ?column?
-------------
-         1
-(1 row)
-~~~
-
-### Savepoints for client-side transaction retries
-
-{% include {{page.version.version}}/sql/retry-savepoints.md %}
-
-The example below shows basic usage of a retry savepoint.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT cockroach_restart;
-UPDATE products SET inventory = 0 WHERE sku = '8675309';
-INSERT INTO orders (customer, sku, status) VALUES (1001, '8675309', 'new');
-RELEASE SAVEPOINT cockroach_restart;
-COMMIT;
-~~~
-
-Applications using `SAVEPOINT` for client-side transaction retries must also include functions to execute retries with [`ROLLBACK TO SAVEPOINT `](rollback-transaction.html#retry-a-transaction).
-
-Note that you can [customize the retry savepoint name](#customizing-the-retry-savepoint-name) to something other than `cockroach_restart` with a session variable if you need to.
-
-#### Customizing the retry savepoint name
-
-{% include {{page.version.version}}/misc/customizing-the-savepoint-name.md %}
-
-### Showing savepoint status
-
-Use the [`SHOW SAVEPOINT STATUS`](show-savepoint-status.html) statement to see how many savepoints are active in the current transaction:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SAVEPOINT STATUS;
-~~~
-
-~~~
-  savepoint_name | is_initial_savepoint
------------------+-----------------------
-  foo            |        true
-  bar            |        false
-  baz            |        false
-(3 rows)
-~~~
-
-Note that the `is_initial_savepoint` column will be true if the savepoint is the outermost savepoint in the transaction.
-
-## See also
-
-- [`SHOW SAVEPOINT STATUS`](show-savepoint-status.html)
-- [`RELEASE SAVEPOINT`](release-savepoint.html)
-- [`ROLLBACK`](rollback-transaction.html)
-- [`BEGIN`](begin-transaction.html)
-- [`COMMIT`](commit-transaction.html)
-- [Transactions](transactions.html)
-- [Retryable transaction example code in Java using JDBC](build-a-java-app-with-cockroachdb.html)
-- [CockroachDB Architecture: Transaction Layer](architecture/transaction-layer.html)
diff --git a/src/current/v20.2/scalar-expressions.md b/src/current/v20.2/scalar-expressions.md
deleted file mode 100644
index a46666197f3..00000000000
--- a/src/current/v20.2/scalar-expressions.md
+++ /dev/null
@@ -1,890 +0,0 @@
----
-title: Scalar Expressions
-summary: Scalar expressions allow the computation of new values from basic parts.
-toc: true
-key: sql-expressions.html
----
-
-Most SQL statements can contain *scalar expressions* that compute new
-values from data.  For example, in the query `SELECT ceil(price) FROM
-items`, the expression `ceil(price)` computes the rounded-up value of
-the values from the `price` column.
-
-Scalar expressions produce values suitable to store in a single table
-cell (one column of one row). They can be contrasted with
-[table expressions](table-expressions.html) and [selection queries](selection-queries.html), which produce results
-structured as a table.
-
-The following sections provide details on each of these options.
-
-
-## Constants
-
-Constant expressions represent a simple value that doesn't change.
-They are described further in section [SQL Constants](sql-constants.html).
-
-## Column references
-
-An expression in a query can refer to columns in the current data source in two ways:
-
-- Using the name of the column, e.g., `price` in `SELECT price FROM
-  items`.
-
-  - If the name of a column is also a
-  [SQL keyword](keywords-and-identifiers.html#keywords), the name
-  must be appropriately quoted. For example: `SELECT "Default" FROM
-  configuration`.
-
-  - If the name is ambiguous (e.g., when joining across multiple
-  tables), it is possible to disambiguate by prefixing the column
-  name by the table name. For example, `SELECT items.price FROM
-  items`.
-
-- Using the ordinal position of the column. For example, `SELECT @1
-  FROM items` selects the first column in `items`.
-
-  *This is a CockroachDB SQL extension.*
-
-  {{site.data.alerts.callout_danger}}
-  Ordinal references should be used with care in production
-  code! During schema updates, column ordinal positions can change and
-  invalidate existing queries that use ordinal positions based on a
-  previous version of the schema.
-  {{site.data.alerts.end}}
-
-## Unary and binary operations
-
-An expression prefixed by a unary operator, or two expressions
-separated by a binary operator, form a new expression.
-
-For a full list of CockroachDB operators, with details about their order of precedence and which data types are valid operands for each operator, see [Functions and Operators](functions-and-operators.html#operators).
-
-### Value comparisons
-
-The standard operators `<` (smaller than), `>` (greater than), `<=`
-(lower than or equal to), `>=` (greater than or equal to), `=`
-(equals), `<>` and `!=` (not equal to), `IS` (identical to), and `IS
-NOT` (not identical to) can be applied to any pair of values from a
-single data type, as well as some pairs of values from different data
-types.
-
-See also [this section over which data types are valid operands
-for each operator](functions-and-operators.html#operators).
-
-The following special rules apply:
-
-- `NULL` is always ordered smaller than every other value, even itself.
-- `NULL` is never equal to anything via `=`, even `NULL`. To check
-  whether a value is `NULL`, use the `IS` operator or the conditional
-  expression `IFNULL(..)`.
-
-See also [NULLs and Ternary Logic](null-handling.html#nulls-and-ternary-logic).
-
-#### Typing rule
-
-All comparisons accept any combination of argument types and result in type `BOOL`.
-
-#### Comparison with `NaN`
-
-CockroachDB recognizes the special value `NaN`
-([Not-a-Number](https://en.wikipedia.org/wiki/NaN)) for scalars of
-type [`FLOAT`](float.html) or [`DECIMAL`](decimal.html).
-
-As per the [IEEE 754](https://en.wikipedia.org/wiki/IEEE_754)
-standard, `NaN` is considered to be different from every other numeric
-value in comparisons.
-
-There are two exceptions however, made for compatibility with PostgreSQL:
-
-- `NaN` is considered to be equal with itself in comparisons. IEEE 754
-  specifies that `NaN` is different from itself.
-- `NaN` is considered to be smaller than every other value, including
-  `-INFINITY`. IEEE 754 specifies that `NaN` does not order with any
-  other value, i.e., `x <= NaN` and `x >= NaN` are both false for every
-  value of `x` including infinities.
-
-These exceptions exist so that the value `NaN` can be used in `WHERE`
-clauses and indexes.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT FLOAT 'NaN' < 1, 1 < FLOAT 'NaN', FLOAT 'NaN' < FLOAT 'NaN';
-~~~
-
-~~~
-  ?column? | ?column? | ?column?
------------+----------+-----------
-    true   |  false   |  false
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT FLOAT 'NaN' = FLOAT 'NaN' AS result;
-~~~
-
-~~~
-  result
-----------
-   true
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT FLOAT 'NaN' < FLOAT '-INFINITY' AS result;
-~~~
-
-~~~
-  result
-----------
-   true
-(1 row)
-~~~
-
-### Multi-valued comparisons
-
-Syntax:
-
-~~~
-<expr> <comparison> ANY <expr>
-<expr> <comparison> SOME <expr>
-<expr> <comparison> ALL <expr>
-~~~
-
-The value comparison operators `<`, `>`, `=`, `<=`, `>=`, `<>` and
-`!=`, as well as the pattern matching operators `[NOT] LIKE` and
-`[NOT] ILIKE`, can be applied to compare a single value on the left to
-multiple values on the right.
-
-This is done by combining the operator using the keywords `ANY`/`SOME` or `ALL`.
-
-The right operand can be either an array, a tuple or [subquery](subqueries.html).
-
-The result of the comparison is true if and only if:
-
-- For `ANY`/`SOME`, the comparison of the left value is true for any
-  element on the right.
-- For `ALL`, the comparison of the left value is true for every
-  element on the right.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT 12 = ANY (10, 12, 13);
-~~~
-
-~~~
-  ?column?
-------------
-    true
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT 12 = ALL (10, 12, 13);
-~~~
-
-~~~
-  ?column?
-------------
-   false
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT 1 = ANY ARRAY[2, 3, 1];
-~~~
-
-~~~
-  ?column?
-------------
-    true
-(1 row)
-~~~
-
-
-#### Typing rule
-
-The comparison between the type on the left and the element type of
-the right operand must be possible.
-
-### Set membership
-
-Syntax:
-
-~~~
-<expr> IN <expr>
-<expr> IN ( ... subquery ... )
-
-<expr> NOT IN <expr>
-<expr> NOT IN ( ... subquery ... )
-~~~
-
-Returns `TRUE` if and only if the value of the left operand is part of
-the result of evaluating the right operand. In the subquery form, any
-[selection query](selection-queries.html) can be used.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT a IN (1, 2, 3) FROM sometable;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT a IN (SELECT * FROM allowedvalues) FROM sometable;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ('x', 123) IN (SELECT * FROM rows);
-~~~
-
-{{site.data.alerts.callout_info}}See <a href="subqueries.html">Subqueries</a> for more details and performance best practices.{{site.data.alerts.end}}
-
-#### Typing rule
-
-`IN` requires its right operand to be a homogeneous tuple type and its left operand
-to match the tuple element type. The result has type `BOOL`.
-
-### String pattern matching
-
-Syntax:
-
-~~~
-<expr> LIKE <expr>
-<expr> ILIKE <expr>
-<expr> NOT LIKE <expr>
-<expr> NOT ILIKE <expr>
-~~~
-
-Evaluates both expressions as strings, then tests whether the string   on the left
-matches the pattern given on the right. Returns `TRUE` if a match is found
-or `FALSE` otherwise, or the inverted value for the `NOT` variants.
-
-Patterns can contain `_` to match any single
-character, or `%` to match any sequence of zero or more characters.
-`ILIKE` causes the match to be tested case-insensitively.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT 'monday' LIKE '%day' AS a, 'tuesday' LIKE 'tue_day' AS b, 'wednesday' ILIKE 'W%' AS c;
-~~~
-
-~~~
-   a   |  b   |  c
--------+------+-------
-  true | true | true
-(1 row)
-~~~
-
-#### Typing rule
-
-The operands must be either both `STRING` or both `BYTES`. The result has type `BOOL`.
-
-### String matching using POSIX regular expressions
-
-Syntax:
-
-~~~
-<expr> ~ <expr>
-<expr> ~* <expr>
-<expr> !~ <expr>
-<expr> !~* <expr>
-~~~
-
-Evaluates both expressions as strings, then tests whether the string
-on the left matches the pattern given on the right. Returns `TRUE` if
-a match is found or `FALSE` otherwise, or the inverted value for the
-`!` variants.
-
-The variants with an asterisk `*` use case-insensitive matching;
-otherwise the matching is case-sensitive.
-
-The pattern is expressed using
-[POSIX regular expression syntax](https://en.wikipedia.org/wiki/Regular_expression). Unlike
-`LIKE` patterns, a regular expression is allowed to match anywhere
-inside a string, not only at the beginning.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT 'monday' ~ 'onday' AS a, 'tuEsday' ~ 't[uU][eE]sday' AS b, 'wednesday' ~* 'W.*y' AS c;
-~~~
-
-~~~
-   a   |  b   |  c
--------+------+-------
-  true | true | true
-(1 row)
-~~~
-
-#### Typing rule
-
-The operands must be either both `STRING` or both `BYTES`. The result has type `BOOL`.
-
-### String matching using SQL regular expressions
-
-Syntax:
-
-~~~
-<expr> SIMILAR TO <expr>
-<expr> NOT SIMILAR TO <expr>
-~~~
-
-Evaluates both expressions as strings, then tests whether the string   on the left
-matches the pattern given on the right. Returns `TRUE` if a match is found
-or `FALSE` otherwise, or the inverted value for the `NOT`  variant.
-
-The pattern is expressed using the SQL standard's definition of a regular expression.
-This is a mix of SQL `LIKE` patterns and POSIX regular expressions:
-
-- `_` and `%` denote any character or any string, respectively.
-- `.` matches specifically the period character, unlike in POSIX where it is a wildcard.
-- Most of the other POSIX syntax applies as usual.
-- The pattern matches the entire string (as in `LIKE`, unlike POSIX regular expressions).
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT 'monday' SIMILAR TO '_onday' AS a, 'tuEsday' SIMILAR TO 't[uU][eE]sday' AS b, 'wednesday' SIMILAR TO 'w%y' AS c;
-~~~
-
-~~~
-   a   |  b   |  c
--------+------+-------
-  true | true | true
-(1 row)
-~~~
-
-#### Typing rule
-
-The operands must be either both `STRING` or both `BYTES`. The result has type `BOOL`.
-
-## Function calls and SQL special forms
-
-General syntax:
-
-~~~
-<name> ( <arguments...> )
-~~~
-
-A built-in function name followed by an opening parenthesis, followed
-by a comma-separated list of expressions, followed by a closing
-parenthesis.
-
-This applies the named function to the arguments between
-parentheses. When the function's namespace is not prefixed, the
-[name resolution rules](sql-name-resolution.html) determine which
-function is called.
-
-See also [the separate section on supported built-in functions](functions-and-operators.html).
-
-In addition, the following SQL special forms are also supported:
-
-{% include {{ page.version.version }}/sql/function-special-forms.md %}
-
-#### Typing rule
-
-In general, a function call requires the arguments to be of the types
-accepted by the function, and returns a value of the type determined
-by the function.
-
-However, the typing of function calls is complicated by the fact
-SQL supports function overloading. [See our blog post for more details](https://www.cockroachlabs.com/blog/revisiting-sql-typing-in-cockroachdb/).
-
-## Subscripted expressions
-
-It is possible to access one item in an array value using the `[` ... `]` operator.
-
-For example, if the name `a` refers to an array of 10
-values, `a[3]` will retrieve the 3rd value. The first value has index
-1.
-
-If the index is smaller or equal to 0, or larger than the size of the array, then
-the result of the subscripted expression is `NULL`.
-
-#### Typing rule
-
-The subscripted expression must have an array type; the index expression
-must have type `INT`.  The result has the element type of the
-subscripted expression.
-
-## Conditional expressions
-
-Expressions can test a conditional expression and, depending on whether
-or which condition is satisfied, evaluate to one or more additional
-operands.
-
-These expression formats share the following property: some of their
-operands are only evaluated if a condition is true. This matters
-especially when an operand would be invalid otherwise. For example,
-`IF(a=0, 0, x/a)` returns 0 if `a` is 0, and `x/a` otherwise.
-
-### `IF` expressions
-
-Syntax:
-
-~~~
-IF ( <cond>, <expr1>, <expr2> )
-~~~
-
-Evaluates `<cond>`, then evaluates `<expr1>` if the condition is true,
-or `<expr2>` otherwise.
-
-The expression corresponding to the case when the condition is false
-is not evaluated.
-
-#### Typing rule
-
-The condition must have type `BOOL`, and the two remaining expressions
-must have the same type. The result has the same type as the
-expression that was evaluated.
-
-### Simple `CASE` expressions
-
-Syntax:
-
-~~~
-CASE <cond>
-  WHEN <condval1> THEN <expr1>
-  [ WHEN <condvalx> THEN <exprx> ] ...
-  [ ELSE <expr2> ]
-END
-~~~
-
-Evaluates `<cond>`, then picks the `WHEN` branch where `<condval>` is
-equal to `<cond>`, then evaluates and returns the corresponding `THEN`
-expression. If no `WHEN` branch matches, the `ELSE` expression is
-evaluated and returned, if any. Otherwise, `NULL` is returned.
-
-Conditions and result expressions after the first match are not evaluated.
-
-#### Typing rule
-
-The condition and the `WHEN` expressions must have the same type.
-The `THEN` expressions and the `ELSE` expression, if any, must have the same type.
-The result has the same type as the `THEN`/`ELSE` expressions.
-
-### Searched `CASE` expressions
-
-Syntax:
-
-~~~
-CASE WHEN <cond1> THEN <expr1>
-   [ WHEN <cond2> THEN <expr2> ] ...
-   [ ELSE <expr> ]
-END
-~~~
-
-In order, evaluates each `<cond>` expression; at the first `<cond>`
-expression that evaluates to `TRUE`, returns the result of evaluating the
-corresponding `THEN` expression.  If none of the `<cond>` expressions
-evaluates to true, then evaluates and returns the value of the `ELSE`
-expression, if any, or `NULL` otherwise.
-
-Conditions and result expressions after the first match are not evaluated.
-
-#### Typing rule
-
-All the `WHEN` expressions must have type `BOOL`.
-The `THEN` expressions and the `ELSE` expression, if any, must have the same type.
-The result has the same type as the `THEN`/`ELSE` expressions.
-
-### `NULLIF` expressions
-
-Syntax:
-
-~~~
-NULLIF ( <expr1>, <expr2> )
-~~~
-
-Equivalent to: `IF ( <expr1> = <expr2>, NULL, <expr1> )`
-
-#### Typing rule
-
-Both operands must have the same type, which is also the type of the result.
-
-### `COALESCE` and `IFNULL` expressions
-
-Syntax:
-
-~~~
-IFNULL ( <expr1>, <expr2> )
-COALESCE ( <expr1> [, <expr2> [, <expr3> ] ...] )
-~~~
-
-`COALESCE` evaluates the first expression first. If its value is not
-`NULL`, its value is returned directly. Otherwise, it returns the
-result of applying `COALESCE` on the remaining expressions. If all the
-expressions are `NULL`, `NULL` is returned.
-
-Arguments to the right of the first non-null argument are not evaluated.
-
-`IFNULL(a, b)` is equivalent to `COALESCE(a, b)`.
-
-#### Typing rule
-
-The operands must have the same type, which is also the type of the result.
-
-## Logical operators
-
-The Boolean operators `AND`, `OR` and `NOT` are available.
-
-Syntax:
-
-~~~
-NOT <expr>
-<expr1> AND <expr2>
-<expr1> OR <expr2>
-~~~
-
-`AND` and `OR` are commutative. Moreover, the input to `AND`
-and `OR` is not evaluated in any particular order. Some operand may
-not even be evaluated at all if the result can be fully ascertained using
-only the other operand.
-
-{{site.data.alerts.callout_info}}This is different from the left-to-right "short-circuit logic" found in other programming languages. When it is essential to force evaluation order, use <a href="#conditional-expressions">a conditional expression</a>.{{site.data.alerts.end}}
-
-See also [NULLs and Ternary Logic](null-handling.html#nulls-and-ternary-logic).
-
-### Typing rule
-
-The operands must have type `BOOL`. The result has type `BOOL`.
-
-## Aggregate expressions
-
-An aggregate expression has the same syntax as a function call, with a special
-case for `COUNT`:
-
-~~~
-<name> ( <arguments...> )
-COUNT ( * )
-~~~
-
-The difference between aggregate expressions and function calls is
-that the former use
-[aggregate functions](functions-and-operators.html#aggregate-functions)
-and can only appear in the list of rendered expressions in a
-[`SELECT` clause](select-clause.html).
-
-An aggregate expression computes a combined value, depending on
-which aggregate function is used, across all the rows currently
-selected.
-
-#### Typing rule
-
-[The operand and return types are determined like for regular function calls](#function-calls-and-sql-special-forms).
-
-## Window function calls
-
-A window function call has the syntax of a function call followed by an `OVER` clause:
-
-~~~
-<name> ( <arguments...> ) OVER <window>
-<name> ( * ) OVER <window>
-~~~
-
-It represents the application of a window or aggregate function over a
-subset ("window") of the rows selected by a query.
-
-#### Typing rule
-
-[The operand and return types are determined like for regular function calls](#function-calls-and-sql-special-forms).
-
-## Explicit type coercions
-
-Syntax:
-
-~~~
-<expr> :: <type>
-CAST (<expr> AS <type>)
-~~~
-
-Evaluates the expression and converts the resulting value to the
-specified type. An error is reported if the conversion is invalid.
-
-For example: `CAST(now() AS DATE)`
-
-Note that in many cases a type annotation is preferrable to a type
-coercion. See the section on
-[type annotations](#explicitly-typed-expressions) below for more
-details.
-
-#### Typing rule
-
-The operand can have any type.
-The result has the type specified in the `CAST` expression.
-
-As a special case, if the operand is a literal, a constant expression
-or a placeholder, the `CAST` type is used to guide the typing of the
-operand. [See our blog post for more details](https://www.cockroachlabs.com/blog/revisiting-sql-typing-in-cockroachdb/).
-
-## Collation expressions
-
-Syntax:
-
-~~~
-<expr> COLLATE <collation>
-~~~
-
-Evaluates the expression and converts its result to a collated string
-with the specified collation.
-
-For example: `'a' COLLATE de`
-
-#### Typing rule
-
-The operand must have type `STRING`. The result has type `COLLATEDSTRING`.
-
-## Array constructors
-
-Syntax:
-
-~~~
-ARRAY[ <expr>, <expr>, ... ]
-~~~
-
-Evaluates to an array containing the specified values.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ARRAY[1,2,3] AS a;
-~~~
-
-~~~
-     a
------------
-  {1,2,3}
-(1 row)
-~~~
-
-The data type of the array is inferred from the values of the provided
-expressions. All the positions in the array must have the same data type.
-
-If there are no expressions specified (empty array), or
-all the values are `NULL`, then the type of the array must be
-specified explicitly using a type annotation. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ARRAY[]:::int[];
-~~~
-
-{{site.data.alerts.callout_success}}To convert the results of a subquery to an array, use <a href="#conversion-of-subquery-results-to-an-array"><code>ARRAY(...)</code></a> instead.{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}CockroachDB also recognizes the syntax <code>ARRAY(a, b, c)</code> as an alias for <code>ARRAY[a, b, c]</code>. This is an experimental, CockroachDB-specific SQL extension and may be removed in a later version of CockroachDB.{{site.data.alerts.end}}
-
-#### Typing rule
-
-The operands must all have the same type.
-The result has the array type with the operand type as element type.
-
-## Tuple constructor
-
-Syntax:
-
-~~~
-(<expr>, <expr>, ...)
-ROW (<expr>, <expr>, ...)
-~~~
-
-Evaluates to a tuple containing the values of the provided expressions.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ('x', 123, 12.3) AS a;
-~~~
-
-~~~
-       a
-----------------
-  (x,123,12.3)
-(1 row)
-~~~
-
-The data type of the resulting tuple is inferred from the values.
-Each position in a tuple can have a distinct data type.
-
-CockroachDB supports accessing the Nth element in a tuple as a single table cell using the syntax `(...).@N`. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT (t).@2 FROM (SELECT (1,'b',2.3) AS t);
-~~~
-
-~~~
-  ?column?
-------------
-  b
-(1 row)
-~~~
-
-CockroachDB also supports expanding all elements of a tuple as a single row in a table with the `(<tuple>).*` notation. This notation works as the inverse of the tuple-creating notation `(<table>.*)`. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH tuples AS (SELECT (t.*) AS tuple FROM (SELECT 1,'b',2.3) AS t(x,y,z))  -- Build the tuples, with labels
-   SELECT (tuple).* FROM tuples;  -- Expands the tuples and restore the column labels
-~~~
-
-~~~
-  x | y |  z
-----+---+------
-  1 | b | 2.3
-(1 row)
-~~~
-
-
-#### Typing rule
-
-The operands can have any type.
-The result has a tuple type whose item types are the types of the operands.
-
-## Explicitly typed expressions
-
-Syntax:
-
-~~~
-<expr>:::<type>
-ANNOTATE_TYPE(<expr>, <type>)
-~~~
-
-Evaluates to the given expression, requiring the expression to have
-the given type. If the expression doesn't have the given type, an
-error is returned.
-
-Type annotations are specially useful to guide the arithmetic on
-numeric values. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT (1 / 0):::FLOAT;
-~~~
-
-~~~
-ERROR: division by zero
-SQLSTATE: 22012
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT (1 / 0);
-~~~
-
-~~~
-ERROR: division by zero
-SQLSTATE: 22012
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT (1 / 0)::FLOAT;
-~~~
-
-~~~
-ERROR: division by zero
-SQLSTATE: 22012
-~~~
-
-Type annotations are also different from cast expressions (see above) in
-that they do not cause the value to be converted. For example,
-`now()::DATE` converts the current timestamp to a date value (and
-discards the current time), whereas `now():::DATE` triggers an error
-message (that `now()` does not have type `DATE`).
-
-Check our blog for
-[more information about context-dependent typing](https://www.cockroachlabs.com/blog/revisiting-sql-typing-in-cockroachdb/).
-
-#### Typing rule
-
-The operand must be implicitly coercible to the given type.
-The result has the given type.
-
-## Subquery expressions
-
-### Scalar subqueries
-
-Syntax:
-
-~~~
-( ... subquery ... )
-~~~
-
-Evaluates the subquery, asserts that it returns a single row and single column,
-and then evaluates to the value of that single cell. Any [selection query](selection-queries.html)
-can be used as subquery.
-
-For example, the following query returns `TRUE` if there are more rows in table `users` than in table
-`admins`:
-
-{% include copy-clipboard.html %}
-~~~sql
-> SELECT (SELECT COUNT(*) FROM users) > (SELECT COUNT(*) FROM admins);
-~~~
-
-{{site.data.alerts.callout_info}}See <a href="subqueries.html">Subqueries</a> for more details and performance best practices.{{site.data.alerts.end}}
-
-#### Typing rule
-
-The operand must have a table type with only one column.
-The result has the type of that single column.
-
-### Existence test on the result of subqueries
-
-Syntax:
-
-~~~
-EXISTS ( ... subquery ... )
-NOT EXISTS ( ... subquery ... )
-~~~
-
-Evaluates the subquery and then returns `TRUE` or `FALSE` depending on
-whether the subquery returned any row (for `EXISTS`) or didn't return
-any row (for `NOT EXISTS`). Any [selection query](selection-queries.html)
-can be used as subquery.
-
-{{site.data.alerts.callout_info}}See <a href="subqueries.html">Subqueries</a> for more details and performance best practices.{{site.data.alerts.end}}
-
-#### Typing rule
-
-The operand can have any table type. The result has type `BOOL`.
-
-### Conversion of subquery results to an array
-
-Syntax:
-
-~~~
-ARRAY( ... subquery ... )
-~~~
-
-Evaluates the subquery and converts its results to an array. Any
-[selection query](selection-queries.html) can be used as subquery.
-
-{{site.data.alerts.callout_info}}See <a href="subqueries.html">Subqueries</a> for more details and performance best practices.{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}To convert a list of scalar expressions to an array, use <a href="#array-constructors"><code>ARRAY[...]</code></a> instead.{{site.data.alerts.end}}
-
-## See also
-
-- [Constants](sql-constants.html)
-- [Selection Queries](selection-queries.html)
-- [Table Expressions](table-expressions.html)
-- [Data Types](data-types.html)
-- [Functions and Operators](functions-and-operators.html)
-- [Subqueries](subqueries.html)
diff --git a/src/current/v20.2/schema-design-database.md b/src/current/v20.2/schema-design-database.md
deleted file mode 100644
index a55c58b0a9f..00000000000
--- a/src/current/v20.2/schema-design-database.md
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: Create a Database
-summary: Best practices for creating databases in CockroachDB.
-toc: true
----
-
-This page provides best-practice guidance on creating databases, with a couple examples based on Cockroach Labs' fictional vehicle-sharing company, [MovR](movr.html).
-
-{{site.data.alerts.callout_success}}
-For reference documentation on the `CREATE DATABASE` statement, including additional examples, see the [`CREATE DATABASE` syntax page](create-database.html).
-{{site.data.alerts.end}}
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Review the database schema objects](schema-design-overview.html).
-
-## Create a database
-
-Database objects make up the first level of the [CockroachDB naming hierarchy](sql-name-resolution.html#naming-hierarchy).
-
-To create a database, use a [`CREATE DATABASE` statement](create-database.html), following [the database best practices](#database-best-practices). After reviewing the best practices, see the examples we provide [below](#example).
-
-### Database best practices
-
-Here are some best practices to follow when creating and using databases:
-
-- Do not use the preloaded `defaultdb` database. Instead, create your own database with a `CREATE DATABASE` statement, and change it to the SQL session's [current database](sql-name-resolution.html#current-database) by executing a `USE {databasename};` statement, by passing the `--database={databasename}` flag to the [`cockroach sql` command](cockroach-sql.html#general), or by specifying the `database` parameter in the [connection string](connection-parameters.html#connect-using-a-url) passed to your database schema migration tool.
-
-- Create databases and [user-defined schemas](schema-design-schema.html) as a member of [the `admin` role](authorization.html#admin-role) (e.g., as the [`root` user](authorization.html#root-user)), and create all other lower-level objects as a [different user](schema-design-overview.html#controlling-access-to-objects), with fewer privileges, following [authorization best practices](authorization.html#authorization-best-practices).
-
-- Limit the number of databases you create. If you need to create multiple tables with the same name in your cluster, do so in different [user-defined schemas](schema-design-schema.html), in the same database.
-
-- {% include {{page.version.version}}/sql/dev-schema-changes.md %}
-
-### Example
-
-Create an empty file with the `.sql` file extension at the end of the filename. This file will initialize the database that will store all of the data for the MovR application.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ touch dbinit.sql
-~~~
-
-Open `dbinit.sql` in a text editor, and, at the top of the file, add a `CREATE DATABASE` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE DATABASE IF NOT EXISTS movr;
-~~~
-
-This statement will create a database named `movr`, if one does not already exist.
-
-To execute the statement in the `dbinit.sql` file as the `root` user, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=root \
-< dbinit.sql
-~~~
-
-To view the database in the cluster, execute a [`SHOW DATABASES`](show-databases.html) statement from the command line:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=root \
---execute="SHOW DATABASES;"
-~~~
-
-~~~
-  database_name | owner | primary_region | regions | survival_goal
-----------------+-------+----------------+---------+----------------
-  defaultdb     | root  | NULL           | {}      | NULL
-  movr          | root  | NULL           | {}      | NULL
-  postgres      | root  | NULL           | {}      | NULL
-  system        | node  | NULL           | {}      | NULL
-(4 rows)
-~~~
-
-You're now ready to start adding user-defined schemas to the `movr` database.
-
-For guidance on creating user-defined schemas, see at [Create a User-defined Schema](schema-design-schema.html).
-
-## What's next?
-
-- [Create a User-defined Schema](schema-design-schema.html)
-- [Create a Table](schema-design-table.html)
-
-You might also be interested in the following pages:
-
-- [`CREATE DATABASE`](create-database.html)
-- [Cockroach Commands](cockroach-commands.html)
-- [Schema Design Overview](schema-design-overview.html)
-- [CockroachDB naming hierarchy](sql-name-resolution.html#naming-hierarchy)
diff --git a/src/current/v20.2/schema-design-indexes.md b/src/current/v20.2/schema-design-indexes.md
deleted file mode 100644
index a7791578542..00000000000
--- a/src/current/v20.2/schema-design-indexes.md
+++ /dev/null
@@ -1,271 +0,0 @@
----
-title: Add Secondary Indexes
-summary: Best practices for working with secondary indexes in CockroachDB.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-This page provides best-practice guidance on creating indexes, with a simple example based on Cockroach Labs' fictional vehicle-sharing company, [MovR](movr.html).
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `CREATE INDEX` statement, including additional examples, see the [`CREATE INDEX` syntax page](create-index.html).
-{{site.data.alerts.end}}
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Review the database schema objects](schema-design-overview.html).
-- [Create a database](schema-design-database.html).
-- [Create a user-defined schema](schema-design-schema.html).
-- [Create a table](schema-design-table.html).
-
-## Create a secondary index
-
-Indexes are [logical objects in a cluster](schema-design-overview.html#database-schema-objects) that help [CockroachDB queries](query-data.html) find data more efficiently. When you create an index, CockroachDB creates a copy of the columns selected for the index, and then sorts the rows of data by indexed column values, without sorting the values in the table itself.
-
-CockroachDB automatically creates an index on the table's [primary key](primary-key.html) key columns. This index is called the *primary index*. The primary index helps CockroachDB more efficiently scan rows, as sorted by the table's primary key columns, but it does not help find values as identified by any other columns.
-
-*Secondary indexes* (i.e., all indexes that are not the primary index) improve the performance of queries that identify rows with columns that are not in a table's primary key. CockroachDB automatically creates secondary indexes for columns with a [`UNIQUE` constraint](unique.html).
-
-To add a secondary index to a table, do one of the following, following the [best practices listed below](#best-practices):
-
-- Add an `INDEX` clause to the end of a [`CREATE TABLE`](create-table.html#create-a-table-with-secondary-and-gin-indexes) statement.
-
-    `INDEX` clauses generally take the following form:
-
-    ~~~
-    INDEX {index_name} ({column_names});
-    ~~~
-
-    Parameter | Description
-    ----------|------------
-    `{index_name}` | The name of the index.
-    `{column_names}` | The name of the column to index, or a comma-separated list of names of the columns to index.
-
-- Use a [`CREATE INDEX`](create-index.html) statement.
-
-    `CREATE INDEX` statements generally take the following form:
-
-    ~~~
-    CREATE INDEX {index_name} ON {table_name} ({column_names});
-    ~~~
-
-    Parameter | Description
-    ----------|------------
-    `{index_name}` | The name of the index.
-    `{table_name}` | The name of the table.
-    `{column_names}` | The name of the column to index, or a comma-separated list of names of the columns to index.
-
-For an example, see [below](#example).
-
-{{site.data.alerts.callout_info}}
-If you do not specify a name for an index, CockroachDB will generate a name.
-
-After creation, the notation for referring to indexes in CockroachDB is `{table_name}@{index_name}`.
-{{site.data.alerts.end}}
-
-### Best practices
-
-Here are some best practices for creating indexes:
-
-- Index all columns that you plan to use for [sorting](order-by.html) or [filtering](select-clause.html#filter-rows) data.
-
-    Note that columns listed in a filtering [`WHERE` clause](select-clause.html#parameters) with the equality operators (`=` or `IN`) should come first in the index, before those referenced with inequality operators (`<`, `>`).
-
-- Avoid indexing on sequential values.
-
-    Writes to indexes with sequential keys can result in range hotspots that negatively affect performance. Instead, use [randomly generated unique IDs](performance-best-practices-overview.html#unique-id-best-practices), or [multi-column keys](performance-best-practices-overview.html#use-multi-column-primary-keys).
-
-    If you are working with a table that *must* be indexed on sequential keys, use [hash-sharded indexes](hash-sharded-indexes.html). For details about the mechanics and performance improvements of hash-sharded indexes in CockroachDB, see our [Hash Sharded Indexes Unlock Linear Scaling for Sequential Workloads](https://www.cockroachlabs.com/blog/hash-sharded-indexes-unlock-linear-scaling-for-sequential-workloads/) blog post.
-
-- Avoid creating secondary indexes that you do not need, and [drop unused indexes](drop-index.html) whenever possible. Secondary indexes can slow down write performance and take up node memory.
-
-    Note that queries can benefit from an index even if they only filter a prefix of its columns. For example, if you create an index of columns `(A, B, C)`, queries filtering `(A)` or `(A, B)` can still use the index. However, queries that do not filter `(A)` will not benefit from the index. This feature also lets you avoid using single-column indexes. Instead, use the column as the first column in a multiple-column index, which is useful to more queries.
-
-    Also note that [`ALTER PRIMARY KEY`](alter-primary-key.html) creates a secondary index from the old primary key. If you need to [change a primary key](constraints.html#change-constraints), and you do not plan to filter queries on the old primary key column(s), do not use `ALTER PRIMARY KEY`. Instead, use [`DROP CONSTRAINT ... PRIMARY KEY`/`ADD CONSTRAINT ... PRIMARY KEY`](add-constraint.html#changing-primary-keys-with-add-constraint-primary-key), which does not create a secondary index.
-
-- Use a [`STORING` clause](create-index.html#parameters) to store columns of data that you want returned by common queries, but that you do not plan to use in query filters.
-
-    The `STORING` clause specifies columns that are not part of the index key but should be stored in the index, without being sorted. If a column is specified in a query, and the column is neither indexed nor stored in an index, CockroachDB will perform a full scan of the table, which can result in poor performance. For an example, see [below](#example).
-
-- Review the [specialized indexes that CockroachDB supports](schema-design-overview.html#specialized-indexes), and decide if you need to create a specialized index instead of a standard index.
-
-- Do not create indexes as the `root` user. Instead, create indexes as a [different user](schema-design-overview.html#controlling-access-to-objects), with fewer privileges, following [authorization best practices](authorization.html#authorization-best-practices). This will likely be the same user that created the table to which the index belongs.
-
-- {% include {{page.version.version}}/sql/dev-schema-changes.md %}
-
-- {% include {{page.version.version}}/sql/dev-schema-change-limits.md %}
-
-### Example
-
-Suppose you want the MovR application to display all of the bikes available to the users of the MovR platform.
-
-Recall that the `vehicles` table that you created in [Create a Table](schema-design-table.html) stores rows of data for each vehicle registered with MovR. Your application will need to read any data about vehicles into the application's persistence layer from this table. To display available bikes, the reads will need to filter on the `available` and `type` columns.
-
-Open `max_init.sql`, and, under the `CREATE TABLE` statement for the `vehicles` table, add a `CREATE INDEX` statement for an index on the `type` and `available` columns of the `vehicles` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX type_available_idx ON movr.vehicles (type, available));
-~~~
-
-This statement creates a secondary index named `type_available_idx`, on the `vehicles` table.
-
-The MovR app might also need to display the vehicle's location and ID, but the app will not be filtering or sorting on those values. If any of the columns referenced in or returned by a query are not in a primary or secondary index key, CockroachDB will need to perform [a full scan of the table](sql-tuning-with-explain.html#issue-full-table-scans) to find the value. Full table scans can be costly, and should be avoided whenever possible.
-
-To help avoid unnecessary full table scans, add a `STORING` clause to the index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX type_available_idx ON movr.vehicles (type, available) STORING (last_location);
-~~~
-
-The index will now store the values in `last_location`, which will improve the performance of reads from the `vehicles` table that return `type`, `available`, `id`, and `last_location` values and do not filter or sort on the `last_location` column.
-
-The `max_init.sql` file should now look similar to the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.users (
-    first_name STRING,
-    last_name STRING,
-    email STRING UNIQUE,
-    CONSTRAINT "primary" PRIMARY KEY (first_name, last_name)
-  );
-
-CREATE TYPE movr.max_schema.vtype AS ENUM ('bike', 'scooter', 'skateboard');
-
-CREATE TABLE movr.max_schema.vehicles (
-      id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-      type movr.max_schema.vtype,
-      creation_time TIMESTAMPTZ DEFAULT now(),
-      available BOOL,
-      last_location STRING
-  );
-
-CREATE INDEX type_available_idx ON movr.max_schema.vehicles (type, available) STORING (last_location);
-
-CREATE TABLE movr.max_schema.rides (
-      id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-      vehicle_id UUID REFERENCES movr.max_schema.vehicles(id),
-      start_address STRING,
-      end_address STRING,
-      start_time TIMESTAMPTZ DEFAULT now(),
-      end_time TIMESTAMPTZ
-  );
-~~~
-
-If you executed this file when following the [Create a Table](schema-design-table.html) example, then all of these objects already exist. To clear the database and re-initialize the schemas, first execute the statements in the `dbinit.sql` file as the `root` user:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=root \
-< dbinit.sql
-~~~
-
-Then, execute the statements in the `max_init.sql` and `abbey_init.sql` files:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=max \
---database=movr
-< max_init.sql
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=abbey \
---database=movr
-< abbey_init.sql
-~~~
-
-After the statements have been executed, you can see the new index in the [CockroachDB SQL shell](cockroach-sql.html#sql-shell).
-
-Open the SQL shell to your cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=max \
---database=movr
-~~~
-
-To view the indexes in the `vehicles` table, issue a [`SHOW INDEXES`](show-index.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM movr.max_schema.vehicles;
-~~~
-
-~~~
-  table_name |     index_name     | non_unique | seq_in_index |  column_name  | direction | storing | implicit
--------------+--------------------+------------+--------------+---------------+-----------+---------+-----------
-  vehicles   | primary            |   false    |            1 | id            | ASC       |  false  |  false
-  vehicles   | type_available_idx |    true    |            1 | type          | ASC       |  false  |  false
-  vehicles   | type_available_idx |    true    |            2 | available     | ASC       |  false  |  false
-  vehicles   | type_available_idx |    true    |            3 | last_location | N/A       |  true   |  false
-  vehicles   | type_available_idx |    true    |            4 | id            | ASC       |  false  |   true
-(5 rows)
-~~~
-
-The output from this `SHOW` statement displays the names and columns of the two indexes on the table (i.e., `primary` and `type_available_idx`).
-
-Note that the `last_location` column's `storing` value is `true` in the `type_available_idx` index, and is therefore not sorted. Also note that the primary key column `id` is implicit in the index, meaning the `id` column is implicitly indexed in `type_available_idx`.
-
-To see an index definition, use a [`SHOW CREATE`](show-create.html) statement on the table that contains the index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE movr.max_schema.vehicles;
-~~~
-
-~~~
-         table_name        |                                create_statement
----------------------------+----------------------------------------------------------------------------------
-  movr.max_schema.vehicles | CREATE TABLE max_schema.vehicles (
-                           |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-                           |     type max_schema.vtype NULL,
-                           |     creation_time TIMESTAMPTZ NULL DEFAULT now():::TIMESTAMPTZ,
-                           |     available BOOL NULL,
-                           |     last_location STRING NULL,
-                           |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-                           |     INDEX type_available_idx (available ASC, type ASC) STORING (last_location),
-                           |     FAMILY "primary" (id, type, creation_time, available, last_location)
-                           | )
-(1 row)
-~~~
-
-After creating a database, a user-defined schema, some tables, and secondary indexes, the database schema should be ready for your application to [write](insert-data.html) and [read data](query-data.html).
-
-It's likely that you will need to update your database schema at some point. For an overview on how to update a database schema, see [Change and Remove Objects in a Database Schema](schema-design-update.html). We also recommend reading about [how online schema changes work in CockroachDB](online-schema-changes.html).
-
-## What's next?
-
-- [Change and Remove Objects in a Database Schema](schema-design-update.html)
-- Read about [how schema changes work](online-schema-changes.html)
-- [Insert Data](schema-design-indexes.html)
-- [Query Data](online-schema-changes.html)
-
-You might also be interested in the following pages:
-
-- [`CREATE INDEX`](create-index.html)
-- [Indexes](indexes.html)
-- [Index a Subset of Rows](partial-indexes.html)
-- [Index Sequential Keys](hash-sharded-indexes.html)
-- [Index JSON and Array Data](inverted-indexes.html)
-- [Index Spatial Data](spatial-indexes.html)
-- [Cockroach Commands](cockroach-commands.html)
-- [Create a User-defined Schema](schema-design-schema.html)
-- [Create a Database](schema-design-database.html)
-- [Schema Design Overview](schema-design-overview.html)
-- [CockroachDB naming hierarchy](sql-name-resolution.html#naming-hierarchy)
diff --git a/src/current/v20.2/schema-design-overview.md b/src/current/v20.2/schema-design-overview.md
deleted file mode 100644
index 3bb9ffa6ad0..00000000000
--- a/src/current/v20.2/schema-design-overview.md
+++ /dev/null
@@ -1,144 +0,0 @@
----
-title: Database Schemas
-summary: An overview of the objects that make up a logical schema
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-This page provides an overview of database schemas in CockroachDB.
-
-In later **Design a Database Schema** sections, we provide best practices for designing a database schema that optimizes performance and storage resources.
-
-## Database schema objects
-
-The sections below provide a brief overview of the logical objects that make up a database schema in CockroachDB, for the purpose of orienting application developers.
-
-For detailed documentation on object name resolution, see [Name Resolution](sql-name-resolution.html).
-
-### Databases
-
-Database objects make up the first level of the [CockroachDB naming hierarchy](sql-name-resolution.html#naming-hierarchy). They contain [schemas](#schemas).
-
-All CockroachDB clusters include a preloaded database named `defaultdb`. Rather than using the `defaultdb` database, we recommend creating your own database.
-
-For guidance on creating databases, see [Create a Database](schema-design-database.html).
-
-{% include {{page.version.version}}/sql/db-terms.md %}
-
-### Schemas
-
-Schemas make up the second level of the naming hierarchy. Each schema belongs to a single database. Schemas contain [tables](#tables) and other objects, like [views](#views) and [sequences](#sequences).
-
-All CockroachDB clusters include a preloaded schema named `public`. CockroachDB also supports creating your own *user-defined schema*.
-
-For guidance on creating user-defined schemas, see [Create a User-defined Schema](schema-design-schema.html).
-
-{% include {{page.version.version}}/sql/schema-terms.md %}
-
-### Tables
-
-Tables, belong to the third and lowest level of the naming hierarchy. Each table can belong to a single [user-defined schema](#schemas).
-
-Tables contain *rows* of data. Each value in a row of data belongs to a particular *column*. Each column allows values of data of a single data type. Columns can be further qualified with [column-level constraints](constraints.html), or computed with [scalar expressions](computed-columns.html).
-
-For guidance on defining tables, see [Tables](schema-design-table.html).
-
-### Indexes
-
-An index is a copy of the rows in a single table, sorted by a column or set of columns. CockroachDB queries use indexes to find data more efficiently in a table, given the values of a particular column. Each index belongs to a single table.
-
-The two main types of indexes are the `primary` index, an index on the row-identifying [primary key columns](primary-key.html), and the secondary index, an index created on non-primary-key columns of your choice.
-
-For guidance on defining primary keys, see [Select Primary Key Columns](schema-design-table.html#select-primary-key-columns). For guidance on defining secondary indexes, see [Add a Secondary Index](schema-design-indexes.html).
-
-#### Specialized indexes
-
-CockroachDB supports some specialized types of indexes, designed to improve query performance in specific use cases. For guidance on specialized indexes, see the following pages:
-
-- [Index a Subset of Rows](partial-indexes.html)
-- [Index Sequential Keys](hash-sharded-indexes.html)
-- [Index JSON and Array Data](inverted-indexes.html)
-- [Index Spatial Data](spatial-indexes.html)
-
-### Other objects
-
-CockroachDB supports several other objects at the third level of the naming hierarchy, including reusable [views](#views), [sequences](#sequences), and [temporary objects](#temporary-objects).
-
-#### Views
-
-A view is a stored and named selection query.
-
-For guidance on using views, see [Views](views.html).
-
-#### Sequences
-
-Sequences create and store sequential data.
-
-For guidance on using sequences, see [the `CREATE SEQUENCE` syntax page](create-sequence.html).
-
-#### Temporary objects
-
-A temporary object is an object, such as a table, view, or sequence, that is not stored to persistent memory.
-
-For guidance on using temporary objects, see [Temporary Tables](temporary-tables.html).
-
-## Controlling access to objects
-
-CockroachDB supports both user-based and role-based access control. With roles, or with direct assignment, you can grant a [SQL user](authorization.html#users) the [privileges](authorization.html#privileges) required to view, modify, and delete database schema objects.
-
-By default, the user that creates an object is that object's *owner*. [Object owners](authorization.html#object-ownership) have all privileges required to view, modify, or delete that object and the data stored within it.
-
-For more information about ownership, privileges, and authorization, see [Authorization](authorization.html).
-
-## Executing database schema changes
-
-We do not recommend using client drivers or ORM frameworks to execute database schema changes. As a best practice, we recommend creating database schemas and performing database schema changes with one of the following methods:
-
-- Use a database schema migration tool.
-
-    CockroachDB is compatible with most PostgreSQL database schema migration tools, including [Flyway](https://flywaydb.org/) and [Liquibase](https://www.liquibase.com). For a tutorial on performing database schema changes using Liquibase, see our [Liquibase tutorial](liquibase.html). For a tutorial on performing schema changes with Flyway, see our [Flyway tutorial](flyway.html).
-
-- Use the [CockroachDB SQL client](cockroach-sql.html#execute-sql-statements-from-a-file).
-
-    The CockroachDB SQL client allows you to execute commands from the command line, or through the [CockroachDB SQL shell](cockroach-sql.html#sql-shell) interface. From the command line, you can pass a string to the client for execution, or you can pass a `.sql` file populated with SQL commands. From the SQL shell, you can execute SQL commands directly. Throughout the guide, we pass a `.sql` file to the SQL client to perform most database schema changes.
-
-## Object size and scaling considerations
-
-CockroachDB does not place hard limits on most database objects. Extremely large attributes are not supported in certain scenarios as described in this section.
-
-### Hard limits
-
-The following table lists specific limits imposed by CockroachDB.
-
-| Object | Limit | Comments |
-| ------ | ----- | -------- |
-| Role names | 63 bytes | Other [restrictions](create-role.html#role-name-limitations) apply. |
-| User names | 63 bytes | These are [equivalent](create-user.html) to role names. |
-| Identifier length | 128 bytes | This limit is specified in the `max_identifier_length` variable for compatibility with other databases, but is not currently enforced. It may be enforced in future versions of CockroachDB, so we recommended remaining within this limit. |
-
-### Quantity of tables and other schema objects
-
-CockroachDB has been shown to perform well with clusters containing 2,500 tables. Greater numbers are possible, depending on the complexity of the tables (number of columns and indexes) and hardware specifications.
-
-As you scale to a large number of tables, note that:
-
-- The amount of RAM per node is the limiting factor for the number of tables and other schema objects the cluster can support. This includes columns, indexes, GIN indexes, constraints, and partitions. Increasing RAM is likely to have the greatest impact on the number of these objects that a cluster can support, while increasing the number of nodes will not have a substantial effect.
-- The number of databases or schemas on the cluster has minimal impact on the total number of tables that it can support.
-
-See the [Hardware](recommended-production-settings.html#hardware) section for additional recommendations based on your expected workloads.
-
-### Quantity of rows
-
-CockroachDB can support any number of rows by adding additional nodes and [storage](recommended-production-settings.html#storage).
-
-## What's next?
-
-- [Create a Database](schema-design-database.html)
-- [Create a User-defined Schema](schema-design-database.html)
-
-You might also be interested in the following pages:
-
-- [CockroachDB naming hierarchy](sql-name-resolution.html#naming-hierarchy)
-- [Authorization](authorization.html)
-- [Liquibase](liquibase.html)
-- [Flyway](flyway.html)
diff --git a/src/current/v20.2/schema-design-schema.md b/src/current/v20.2/schema-design-schema.md
deleted file mode 100644
index 47c51a8d8e5..00000000000
--- a/src/current/v20.2/schema-design-schema.md
+++ /dev/null
@@ -1,168 +0,0 @@
----
-title: Create a User-defined Schema
-summary: Create a user-defined schema for your CockroachDB cluster
-toc: true
----
-
-This page provides best-practice guidance on creating user-defined schemas, with some simple examples based on Cockroach Labs' fictional vehicle-sharing company, [MovR](movr.html).
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `CREATE SCHEMA` statement, including additional examples, see the [`CREATE SCHEMA` syntax page](create-schema.html).
-{{site.data.alerts.end}}
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Review the database schema objects](schema-design-overview.html).
-- [Create a database](schema-design-database.html).
-
-## Create a user-defined schema
-
-User-defined schemas belong to the second level of the [CockroachDB naming hierarchy](sql-name-resolution.html#naming-hierarchy).
-
-To create a user-defined schema, use a [`CREATE SCHEMA` statement](create-schema.html), following [the user-defined schema best practices](#user-defined-schema-best-practices). After reviewing the best practices, see the example we provide [below](#examples).
-
-### User-defined schema best practices
-
-Here are some best practices to follow when creating and using user-defined schemas:
-
-- If you want to create multiple objects (e.g., tables or views) with the same name in your cluster, do so in different user-defined schemas in the same database.
-
-- If you want to separate lower-level objects (e.g., a set of [tables](schema-design-table.html) or [views](views.html)) for access or organizational purposes, do not create those objects in the preloaded [`public` schema](sql-name-resolution.html#naming-hierarchy). Instead, create user-defined schemas, and then create the objects in the user-defined schemas.
-
-- Create user-defined schemas as a member of [the `admin` role](authorization.html#admin-role) (e.g., as the [`root` user](authorization.html#root-user)), and then give ownership of them to a [different user](schema-design-overview.html#controlling-access-to-objects), with fewer privileges across the database, following [authorization best practices](authorization.html#authorization-best-practices).
-
-- When you create a user-defined schema, take note of the [object's owner](authorization.html#object-ownership). You can specify the owner in a `CREATE SCHEMA` statement with the [`AUTHORIZATION` keyword](create-schema.html#parameters). If `AUTHORIZATION` is not specified, the owner will be the user creating the user-defined schema.
-
-- Do not create user-defined schemas in the preloaded `defaultdb` database. Instead, use a database [you have created](schema-design-database.html). User-defined schemas can only be created in your SQL session's [current database](sql-name-resolution.html#current-database), so be sure to [change the session's database](schema-design-database.html#database-best-practices) to a database that you have created before creating a user-defined schema.
-
-- When referring to a lower-level object in a database (e.g., a table), include the object's schema name (e.g., `schema_name.table_name`). Specifying the schema name in a lower-level object reference can prevent users from attempting to access the wrong object, if there are multiple objects with the same name in a database.
-
-- {% include {{page.version.version}}/sql/dev-schema-changes.md %}
-
-### Examples
-
-Suppose you want to separate the tables and indexes in your cluster such that one user manages a group of tables, and another user manages a different group of tables. You can do this with two different user-defined schemas, owned by two different SQL users, with fewer privileges than the `root` user.
-
-Open the `dbinit.sql` file that you created in the [Create a Database](schema-design-database.html) example, and add the following statements under the `CREATE DATABASE` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-USE movr;
-
-CREATE USER IF NOT EXISTS max;
-GRANT CREATE ON DATABASE movr TO max;
-
-CREATE USER IF NOT EXISTS abbey;
-GRANT CREATE ON DATABASE movr TO abbey;
-~~~
-
-The first statement sets the `movr` database as the [current database](sql-name-resolution.html#current-database). The next two sets of statements create SQL users named `max` and `abbey` in the `movr` database, with [`CREATE` privileges on the database](authorization.html#supported-privileges). `CREATE` privileges will allow each user to create tables in the database.
-
-Now, under the `CREATE USER` statements, add `DROP SCHEMA` and `CREATE SCHEMA` statements for each user's user-defined schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-DROP SCHEMA IF EXISTS max_schema CASCADE;
-CREATE SCHEMA max_schema AUTHORIZATION max;
-
-DROP SCHEMA IF EXISTS abbey_schema CASCADE;
-CREATE SCHEMA abbey_schema AUTHORIZATION abbey;
-~~~
-
-The first set of statement clears the database of any existing schema named `max_schema`, and then creates a schema named `max_schema` with the owner `max`. The next set of statements does the same, but for `abbey_schema`, with `abbey` as the owner.
-
-It might also be a good idea to [grant the `USAGE` privilege](grant.html#supported-privileges) on each schema to the other user in the database. This will allow the other user to access objects in the schema, but it will not let them delete the schema, or create objects inside of it.
-
-Under the `CREATE SCHEMA` statements for each user-defined schema, add a `GRANT` statement granting `USAGE` privileges on the schema to the other user.
-
-The `dbinit.sql` file should now look something link this:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE DATABASE IF NOT EXISTS movr;
-
-USE movr;
-
-CREATE USER IF NOT EXISTS max;
-GRANT CREATE ON DATABASE movr TO max;
-
-CREATE USER IF NOT EXISTS abbey;
-GRANT CREATE ON DATABASE movr TO abbey;
-
-DROP SCHEMA IF EXISTS max_schema CASCADE;
-CREATE SCHEMA max_schema AUTHORIZATION max;
-GRANT USAGE ON SCHEMA max_schema TO abbey;
-
-DROP SCHEMA IF EXISTS abbey_schema CASCADE;
-CREATE SCHEMA abbey_schema AUTHORIZATION abbey;
-GRANT USAGE ON SCHEMA abbey_schema TO max;
-~~~
-
-To execute the statements in the `dbinit.sql` file as the `root` user, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=root \
-< dbinit.sql
-~~~
-
-Before the new users can connect to the cluster and start creating objects, they each need a [user certificate](authentication.html#client-authentication). To create a user certificate for `max`, open a new terminal, and run the following [`cockroach cert`](cockroach-cert.html) command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client max --certs-dir={certs-directory} --ca-key={my-safe-directory}/ca.key
-~~~
-
-Create a user certificate for `abbey` as well:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach cert create-client abbey --certs-dir={certs-directory} --ca-key={my-safe-directory}/ca.key
-~~~
-
-As one of the new users, use a [`SHOW SCHEMAS` statement](show-schemas.html) to show the preloaded and user-defined schemas in the `movr` database:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=abbey \
---database=movr \
---execute="SHOW SCHEMAS;"
-~~~
-
-~~~
-     schema_name     | owner
----------------------+--------
-  abbey_schema       | abbey
-  crdb_internal      | NULL
-  information_schema | NULL
-  max_schema         | max
-  pg_catalog         | NULL
-  pg_extension       | NULL
-  public             | admin
-(7 rows)
-~~~
-
-You're now ready to start adding tables to the `max_schema` user-defined schema as the `max` user, and to the `abbey_schema` user-defined schema as the `abbey` user.
-
-For guidance on creating tables, see at [Create a Table](schema-design-table.html).
-
-## What's next?
-
-- [Create a Table](schema-design-table.html)
-- [Add Secondary Indexes](schema-design-indexes.html)
-
-You might also be interested in the following pages:
-
-- [`CREATE SCHEMA`](create-schema.html)
-- [Cockroach Commands](cockroach-commands.html)
-- [Create a Database](schema-design-database.html)
-- [Schema Design Overview](schema-design-overview.html)
-- [CockroachDB naming hierarchy](sql-name-resolution.html#naming-hierarchy)
diff --git a/src/current/v20.2/schema-design-table.md b/src/current/v20.2/schema-design-table.md
deleted file mode 100644
index 62570cbcf93..00000000000
--- a/src/current/v20.2/schema-design-table.md
+++ /dev/null
@@ -1,604 +0,0 @@
----
-title: Create a Table
-summary: Best practices for working with tables in CockroachDB.
-toc: true
----
-
-This page provides best-practice guidance on creating tables, with some simple examples based on Cockroach Labs' fictional vehicle-sharing company, [MovR](movr.html).
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `CREATE TABLE` statement, including additional examples, see the [`CREATE TABLE` syntax page](create-table.html).
-{{site.data.alerts.end}}
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Review the database schema objects](schema-design-overview.html).
-- [Create a database](schema-design-database.html).
-- [Create a user-defined schema](schema-design-schema.html).
-
-## Create a table
-
-Tables are the [logical objects in a cluster](schema-design-overview.html#database-schema-objects) that store data sent from your application's persistence layer. Tables organize records of data in rows and columns.
-
-To create a table, use a [`CREATE TABLE` statement](create-table.html), following the best practices that we have listed in the following sections:
-
-- [Name a table](#name-a-table)
-- [Define columns](#define-columns)
-- [Select primary key columns](#select-primary-key-columns)
-- [Add additional constraints](#add-additional-constraints)
-- [Execute `CREATE TABLE` statements](#execute-create-table-statements)
-
-After reviewing the best practices in each section, see the example provided in that section.
-
-### Name a table
-
-Naming a table is the first step in table creation.
-
-`CREATE TABLE` statements generally take the form:
-
-~~~
-CREATE TABLE {schema_name}.{table_name} (
-  {elements}
-  );
-~~~
-
-Parameter | Description
-----------|------------
-`{schema_name}` | The name of the user-defined schema.
-`{table_name}` | The name of the table.
-`{elements}` | A comma-separated list of table elements, such as column definitions.
-
-For an example, see [below](#table-naming-example).
-
-#### Table naming best practices
-
-Here are some best practices to follow when naming tables:
-
-- Use a [fully-qualified name](sql-name-resolution.html#how-name-resolution-works) (i.e., `CREATE TABLE database_name.schema_name.table_name`). If you do not specify the database name, CockroachDB will use the SQL session's [current database](sql-name-resolution.html#current-database) (`defaultdb`, by default). If you do not specify the user-defined schema in the table name, CockroachDB will create the table in the preloaded `public` schema.
-
-- Use a table name that reflects the contents of the table. For example, for a table containing information about orders, you could use the name `orders` (as opposed to naming the table something like `table1`).
-
-#### Table naming example
-
-Suppose you want to create a table to store information about users of the [MovR](movr.html) platform, and you want the SQL user `max` to manage that table.
-
-Create an empty `.sql` file for `max`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ touch max_init.sql
-~~~
-
-This file will initialize the objects in the `max_schema` user-defined schema that you created in [Create a Schema](schema-design-schema.html), starting with a `users` table.
-
-In a text editor, open `max_init.sql`, and add an empty `CREATE TABLE` statement for the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.users (
-);
-~~~
-
-Next, [define the table's columns](#define-columns).
-
-### Define columns
-
-Column definitions give structure to a table by separating the values in each row into columns of a single data type.
-
-Column definitions generally take the following form:
-
-~~~
-{column_name} {DATA_TYPE} {column_qualification}
-~~~
-
-Parameter | Description
-----------|------------
-`{column_name}` | The name of the column.
-`{DATA_TYPE}` | The [data type](data-types.html) of the row values in the column.
-`{column_qualification}` | Some column qualification, such as a [column-level constraint](#add-additional-constraints), or a [computed column clause](computed-columns.html).
-
-For examples, see [below](#column-definition-examples).
-
-#### Column definition best practices
-
-Here are some best practices to follow when defining table columns:
-
-- Review the supported column [data types](data-types.html), and select the appropriate type for the data you plan to store in a column, following the best practices listed on the data type's reference page.
-
-- Use column data types with a fixed size limit, or set a maximum size limit on column data types of variable size (e.g., [`VARBIT(n)`](bit.html#size)). Values exceeding 1MB can lead to [write amplification](https://en.wikipedia.org/wiki/Write_amplification) and cause significant performance degradation.
-
-- Review the [primary key best practices](#select-primary-key-columns) and [examples](#primary-key-examples), decide if you need to define any dedicated primary key columns.
-
-- Review the best practices and examples for [adding additional constraints](#add-additional-constraints), and decide if you need to add any additional constraints to your columns.
-
-#### Column definition examples
-
-In the `max_init.sql` file, add a few column definitions to the `users` table's `CREATE TABLE` statement, for user names and email addresses:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.users (
-    first_name STRING,
-    last_name STRING,
-    email STRING
-);
-~~~
-
-All of the columns shown above use the [`STRING`](string.html) data type, meaning that any value in any of the columns must be of the data type `STRING`.
-
-CockroachDB supports a number of other column data types, including [`DECIMAL`](decimal.html), [`INT`](int.html), [`TIMESTAMP`](timestamp.html), [`UUID`](uuid.html), and [enumerated data types](enum.html) and [spatial data types](spatial-data.html). We recommend that you review the [supported types](data-types.html), and create columns with data types that correspond to the types of data that you intend to persist to the cluster from your application.
-
-Let's add another example table to our `max_schema` schema, with more column data types.
-
-As a vehicle-sharing platform, MovR needs to store data about its vehicles. In `max_init.sql`, add a `CREATE TABLE` statement for a `vehicles` table, under the `CREATE TABLE` statement for `users`. This table should probably include information about the type of vehicle, when it was created, what its availability is, and where it is located:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.vehicles (
-      id UUID,
-      type STRING,
-      creation_time TIMESTAMPTZ,
-      available BOOL,
-      last_location STRING
-  );
-~~~
-
-This table includes a few more data types than the `users` table:
-
-- [`UUID`](uuid.html), which we recommend for columns with [values that uniquely identify rows](https://en.wikipedia.org/wiki/Unique_key) (like an "id" column).
-- [`TIMESTAMPTZ`](timestamp.html), which we recommend for [timestamp values](https://en.wikipedia.org/wiki/Timestamp).
-- [`BOOL`](bool.html), which we recommend for columns that will only take one of two possible values.
-
-The rest of the columns are `STRING`-typed.
-
-Note that values in the `type` column will likely only be `STRING` values from a fixed list of values. Specifically, the vehicle type can only be one of the vehicle types supported by the MovR platform (e.g., a `bike`, a `scooter`, or a `skateboard`). For values like this, we recommend using a [user-defined, enumerated type](enum.html).
-
-To create a user-defined type, use a `CREATE TYPE` statement. For example, above the `CREATE TABLE` statement for the `vehicles` table, add the following statements:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TYPE movr.max_schema.vtype AS ENUM ('bike', 'scooter', 'skateboard');
-~~~
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `CREATE TYPE` statement, including additional examples, see the [`CREATE TYPE` syntax page](create-type.html).<br>For detailed reference documentation on enumerated data types, including additional examples, see [`ENUM`](enum.html).
-{{site.data.alerts.end}}
-
-You can then use `vtype` as the `type` column's data type:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.vehicles (
-      id UUID,
-      type vtype,
-      creation_time TIMESTAMPTZ,
-      available BOOL,
-      last_location STRING
-  );
-~~~
-
-Only values in the set of `vtype` values will be allowed in the `type` column.
-
-The `users` and `vehicles` tables now have syntactically valid column definitions. As a best practice, you should explicitly [select primary key columns](#select-primary-key-columns) and add any [additional constraints](#add-additional-constraints) before executing the `CREATE TABLE` statements.
-
-### Select primary key columns
-
-A primary key is a column, or set of columns, whose values uniquely identify rows of data. Every table requires a primary key.
-
-Primary keys are defined in `CREATE TABLE` statements with the `PRIMARY KEY` [column constraint](constraints.html). The `PRIMARY KEY` constraint requires that all the constrained column(s) contain only unique and non-`NULL` values.
-
-When a table is created, CockroachDB creates an index (called the `primary` index) on the column(s) constrained by the `PRIMARY KEY` constraint. CockroachDB uses this [index](indexes.html) to find rows in a table more efficiently.
-
-To add a single column to a primary key, add the `PRIMARY KEY` keyword to the end of the column definition. To add multiple columns to a primary key (i.e., to create a [composite primary key](https://en.wikipedia.org/wiki/Composite_key)), add a separate `CONSTRAINT "primary" PRIMARY KEY` clause after the column definitions in the `CREATE TABLE` statement.
-
-For examples, see [below](#primary-key-examples).
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `PRIMARY KEY` constraint, including additional examples, see the [`PRIMARY KEY` constraint page](primary-key.html).
-{{site.data.alerts.end}}
-
-#### Primary key best practices
-
-Here are some best practices to follow when selecting primary key columns:
-
-- Avoid defining primary keys over a single column of sequential data.
-
-    Querying a table with a primary key on a single sequential column (e.g., an auto-incrementing [`INT`](int.html) column, or a [`TIMESTAMP`](timestamp.html) value) can result in single-range hotspots that negatively affect performance, or cause [transaction contention](transactions.html#transaction-contention).
-
-    If you are working with a table that *must* be indexed on sequential keys, use [hash-sharded indexes](hash-sharded-indexes.html). For details about the mechanics and performance improvements of hash-sharded indexes in CockroachDB, see our [Hash Sharded Indexes Unlock Linear Scaling for Sequential Workloads](https://www.cockroachlabs.com/blog/hash-sharded-indexes-unlock-linear-scaling-for-sequential-workloads/) blog post.
-
-- Define a primary key for every table.
-
-    If you create a table without defining a primary key, CockroachDB will automatically create a primary key over a hidden, [`INT`](int.html)-typed column named `rowid`. By default, sequential, unique identifiers are generated for each row in the `rowid` column with the [`unique_rowid()` function](functions-and-operators.html#built-in-functions). The sequential nature of the `rowid` values can lead to a poor distribution of the data across a cluster, which can negatively affect performance. Furthermore, because you cannot meaningfully use the `rowid` column to filter table data, the primary key index on `rowid` does not offer any performance optimization. This means you will always have improved performance by defining a primary key for a table.
-
-- When possible, define primary key constraints over multiple columns (i.e., use [composite primary keys](https://en.wikipedia.org/wiki/Composite_key)).
-
-    When defining composite primary keys, make sure the data in the first column of the primary key prefix is well-distributed across the nodes in the cluster. To improve the performance of [ordered queries](order-by.html), you can add monotonically increasing primary key columns after the first column of the primary key prefix. For an example, see [below](#primary-key-examples).
-
-- For single-column primary keys, use [`UUID`](uuid.html)-typed columns with default values randomly-generated, using the `gen_random_uuid()` [SQL function](functions-and-operators.html#id-generation-functions).
-
-    Randomly generating `UUID` values ensures that the primary key values will be unique and well-distributed across a cluster. For an example, see [below](#primary-key-examples).
-
-#### Primary key examples
-
-To follow a [primary key best practice](#primary-key-best-practices), the `CREATE TABLE` statements in `max_init.sql` for the `users` and `vehicles` tables need to explicitly define a primary key.
-
-In the `max_init.sql` file, add a composite primary key on the `first_name` and `last_name` columns of the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.users (
-    first_name STRING,
-    last_name STRING,
-    email STRING,
-    CONSTRAINT "primary" PRIMARY KEY (first_name, last_name)
-);
-~~~
-
-This primary key will uniquely identify rows of user data.
-
-Because `PRIMARY KEY` constraints imply `UNIQUE` indexes, only one unique combination of `first_name` and `last_name` will be allowed in rows of the `users` table. Additionally, because `PRIMARY KEY` implies the `NOT NULL` constraint, all rows of data inserted into the `users` table must include values for `first_name` and `last_name`.
-
-Primary key columns can also be single columns, if those columns are guaranteed to uniquely identify the row. Their values should also be well-distributed across the cluster.
-
-In the `vehicles` table definition, add a `PRIMARY KEY` constraint on the `id` column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.vehicles (
-      id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-      type vtype,
-      creation_time TIMESTAMPTZ,
-      available BOOL,
-      last_location STRING
-  );
-~~~
-
-Note that, in addition to the `PRIMARY KEY` constraint, the `id` column has a `DEFAULT` constraint. This constraint sets a default value for the column to a value generated by the `gen_random_uuid()` [function](functions-and-operators.html), following [`UUID`](uuid.html) best practices. The values generated by this function are guaranteed to be unique and well-distributed across the cluster. We discuss the `DEFAULT` constraint more [below](#populate-with-default-values).
-
-### Add additional constraints
-
-In addition to the `PRIMARY KEY` constraint, CockroachDB supports a number of other [column-level constraints](constraints.html), including [`CHECK`](check.html), [`DEFAULT`](#populate-with-default-values), [`FOREIGN KEY`](#reference-other-tables), [`UNIQUE`](#prevent-duplicates), and [`NOT NULL`](#prevent-null-values). Using constraints can simplify table queries, improve query performance, and ensure that data remains semantically valid.
-
-To constrain a single column, add a constraint keyword to the column's definition, as shown in the [single-column `PRIMARY KEY` example above](#primary-key-examples). To constrain more than one column, add the entire constraint's definition after the list of columns in the `CREATE TABLE` statement, also shown in the [composite `PRIMARY KEY` example above](#primary-key-examples).
-
-For guidance and examples for each constraint, see the sections below.
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation for each supported constraint, see [the constraint's syntax page](constraints.html).
-{{site.data.alerts.end}}
-
-#### Populate with default values
-
-To set default values on columns, use the `DEFAULT` constraint. Default values enable you to write queries without the need to specify values for every column.
-
-When combined with [supported SQL functions](functions-and-operators.html), default values can save resources in your application's persistence layer by offloading computation onto CockroachDB. For example, rather than using an application library to generate unique `UUID` values, you can set a default value to be an automatically-generated `UUID` value with the `gen_random_uuid()` SQL function. Similarly, you could use a default value to populate a `TIMESTAMP` column with the current time of day, using the `now()` function.
-
-For example, in the `vehicles` table definition in `max_init.sql`, you added a `DEFAULT gen_random_uuid()` clause to the `id` column definition. This set the default value to a generated `UUID` value. Now, add a default value to the `creation_time` column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.vehicles (
-      id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-      type vtype,
-      creation_time TIMESTAMPTZ DEFAULT now(),
-      available BOOL,
-      last_location STRING
-  );
-~~~
-
-When a row is inserted into the `vehicles` table, CockroachDB generates a random default value for the vehicle `id`, and uses the current timestamp for the vehicle's `creation_time`. Rows inserted into the `vehicles` table do not need to include an explicit value for `id` or `creation_time`.
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `DEFAULT` constraint, including additional examples, see [the `DEFAULT` syntax page](default-value.html).
-{{site.data.alerts.end}}
-
-#### Reference other tables
-
-To reference values in another table, use a `FOREIGN KEY` constraint. `FOREIGN KEY` constraints enforce [referential integrity](https://en.wikipedia.org/wiki/Referential_integrity), which means that a column can only refer to an existing column.
-
-For example, suppose you want to add a new table that contains data about the rides that MovR users are taking on vehicles. This table should probably include information about the location and duration of the ride, as well as information about the vehicle used for the ride.
-
-In `max_init.sql`, under the `CREATE TABLE` statement for `vehicles`, add a definition for a `rides` table, with a foreign key dependency on the `vehicles` table. To define a foreign key constraint, use the `REFERENCES` keyword:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.rides (
-      id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-      vehicle_id UUID REFERENCES movr.max_schema.vehicles(id),
-      start_address STRING,
-      end_address STRING,
-      start_time TIMESTAMPTZ DEFAULT now(),
-      end_time TIMESTAMPTZ
-  );
-~~~
-
-The `vehicle_id` column will be identical to the `id` column in the `vehicles` table. Any queries that insert a `vehicle_id` that does not exist in the `id` column of the `vehicles` table will return an error.
-
-Foreign keys cannot reference tables in a different database. They can, however reference tables in a different schema.
-
-Suppose that you want to introduce promotional codes for users on the MovR platform, but you want the user promo code data to be managed by the `abbey` user that you created in [Create a Database](schema-design-database.html).
-
-Create an empty `.sql` initialization file for `abbey`.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ touch abbey_init.sql
-~~~
-
-This file will initialize the objects in the `abbey_schema` user-defined schema that you created in [Create a Schema](schema-design-schema.html).
-
-In a text editor, open `abbey_init.sql`, and add a `CREATE TABLE` statement for a table called `user_promo_codes`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.abbey_schema.user_promo_codes (
-    code STRING,
-    user_email STRING REFERENCES movr.max_schema.users(email),
-    valid BOOL,
-    CONSTRAINT "primary" PRIMARY KEY (code, user_email)
-  );
-~~~
-
-This new table references the `email` column of the `users` table in `max_schema`. Because the `user_promo_codes` table depends on the `users` table, you'll need to execute `max_init.sql` before `abbey_init.sql`.
-
-{{site.data.alerts.callout_info}}
-Foreign key dependencies can significantly impact query performance, as queries involving tables with foreign keys, or tables referenced by foreign keys, require CockroachDB to check two separate tables. We recommend using them sparingly.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `FOREIGN KEY` constraint, including additional examples, see [the `FOREIGN KEY` syntax page](foreign-key.html).
-{{site.data.alerts.end}}
-
-#### Prevent duplicates
-
-To prevent duplicate values in a column, use the `UNIQUE` constraint.
-
-For example, suppose that you want to ensure that the email addresses of all users are different, to prevent users from registering for two accounts with the same email address. Add a `UNIQUE` constraint to the `email` column of the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.users (
-    first_name STRING,
-    last_name STRING,
-    email STRING UNIQUE,
-    CONSTRAINT "primary" PRIMARY KEY (first_name, last_name)
-);
-~~~
-
-Attempting to insert `email` values that already exist in the `users` table will return an error.
-
-{{site.data.alerts.callout_info}}
-When you add a `UNIQUE` constraint to a column, CockroachDB creates a secondary index on that column, to help speed up checks on a column value's uniqueness.
-
-Also note that the `UNIQUE` constraint is implied by the `PRIMARY KEY` constraint.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `UNIQUE` constraint, including additional examples, see [the `UNIQUE` syntax page](unique.html).
-{{site.data.alerts.end}}
-
-#### Prevent `NULL` values
-
-To prevent `NULL` values in a column, use the `NOT NULL` constraint. If you specify a `NOT NULL` constraint, all queries against the table with that constraint must specify a value for that column, or have a default value specified with a `DEFAULT` constraint.
-
-For example, if you require all users of the MovR platform to have an email on file, you can add a `NOT NULL` constraint to the `email` column of the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.users (
-    first_name STRING,
-    last_name STRING,
-    email STRING UNIQUE NOT NULL,
-    CONSTRAINT "primary" PRIMARY KEY (first_name, last_name)
-);
-~~~
-
-{{site.data.alerts.callout_info}}
-Note that the `NOT NULL` constraint is implied by the `PRIMARY KEY` constraint.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `NOT NULL` constraint, including additional examples, see [the `NOT NULL` syntax page](not-null.html).
-{{site.data.alerts.end}}
-
-### Execute `CREATE TABLE` statements
-
-After you have defined `CREATE TABLE` statements for your tables, you can execute the statements.
-
-#### `CREATE TABLE` execution best practices
-
-Here are some general best practices to follow when executing `CREATE TABLE` statements:
-
-- Do not create tables as the `root` user. Instead, create tables as a [different user](schema-design-overview.html#controlling-access-to-objects), with fewer privileges, following [authorization best practices](authorization.html#authorization-best-practices). The user that creates an object becomes that [object's owner](authorization.html#object-ownership).
-
-- {% include {{page.version.version}}/sql/dev-schema-changes.md %}
-
-- {% include {{page.version.version}}/sql/dev-schema-change-limits.md %}
-
-#### Execute the example `CREATE TABLE` statements
-
-After following the examples provided in the sections above, the `max_init.sql` file should look similar to the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.max_schema.users (
-    first_name STRING,
-    last_name STRING,
-    email STRING UNIQUE NOT NULL,
-    CONSTRAINT "primary" PRIMARY KEY (first_name, last_name)
-  );
-
-CREATE TYPE movr.max_schema.vtype AS ENUM ('bike', 'scooter', 'skateboard');
-
-CREATE TABLE movr.max_schema.vehicles (
-      id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-      type movr.max_schema.vtype,
-      creation_time TIMESTAMPTZ DEFAULT now(),
-      available BOOL,
-      last_location STRING
-  );
-
-CREATE TABLE movr.max_schema.rides (
-      id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
-      vehicle_id UUID REFERENCES movr.max_schema.vehicles(id),
-      start_address STRING,
-      end_address STRING,
-      start_time TIMESTAMPTZ DEFAULT now(),
-      end_time TIMESTAMPTZ
-  );
-~~~
-
-To execute the statements in the `max_init.sql` file, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=max \
---database=movr
-< max_init.sql
-~~~
-
-The SQL client will execute any statements in `max_init.sql`, with `movr` as the database and `max` as the user. `max` is now the owner of all objects created by the statements in the `max_init.sql` file.
-
-After the statements have been executed, you can see the tables in the [CockroachDB SQL shell](cockroach-sql.html#sql-shell).
-
-Open the SQL shell to your cluster, with `movr` as the database and `max` as the user:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=max \
---database=movr
-~~~
-
-To view the tables in the `max_schema` user-defined schema, issue a [`SHOW TABLES`](show-tables.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM max_schema;
-~~~
-
-~~~
-  schema_name | table_name | type  | owner | estimated_row_count
---------------+------------+-------+-------+----------------------
-  max_schema  | rides      | table | max   |                   0
-  max_schema  | users      | table | max   |                   0
-  max_schema  | vehicles   | table | max   |                   0
-(3 rows)
-~~~
-
-To see the individual `CREATE TABLE` statements for each table, use a [`SHOW CREATE`](show-create.html) statement. For example, to see the `vehicles` `CREATE TABLE` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE movr.max_schema.vehicles;
-~~~
-
-~~~
-         table_name        |                             create_statement
----------------------------+---------------------------------------------------------------------------
-  movr.max_schema.vehicles | CREATE TABLE max_schema.vehicles (
-                           |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-                           |     type max_schema.vtype NULL,
-                           |     creation_time TIMESTAMPTZ NULL DEFAULT now():::TIMESTAMPTZ,
-                           |     available BOOL NULL,
-                           |     last_location STRING NULL,
-                           |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-                           |     FAMILY "primary" (id, type, creation_time, available, last_location)
-                           | )
-(1 row)
-~~~
-
-After following the examples provided in the sections above, the `abbey_init.sql` file should look similar to the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE movr.abbey_schema.user_promo_codes (
-    code STRING,
-    user_email STRING REFERENCES movr.max_schema.users(email),
-    valid BOOL,
-    CONSTRAINT "primary" PRIMARY KEY (code, user_email)
-  );
-~~~
-
-To execute the statement in the `abbey_init.sql` file, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=abbey \
---database=movr
-< abbey_init.sql
-~~~
-
-After the statements have been executed, you can see the table in the [CockroachDB SQL shell](cockroach-sql.html#sql-shell).
-
-Open the SQL shell to your cluster, with `movr` as the database and `abbey` as the user, and view the table:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=abbey \
---database=movr
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM abbey_schema;
-~~~
-
-~~~
-  schema_name  |    table_name    | type  | owner | estimated_row_count
----------------+------------------+-------+-------+----------------------
-  abbey_schema | user_promo_codes | table | abbey |                   0
-(1 row
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE movr.abbey_schema.user_promo_codes;
-~~~
-
-~~~
-              table_name             |                                          create_statement
--------------------------------------+------------------------------------------------------------------------------------------------------
-  movr.abbey_schema.user_promo_codes | CREATE TABLE abbey_schema.user_promo_codes (
-                                     |     code STRING NOT NULL,
-                                     |     user_email STRING NOT NULL,
-                                     |     valid BOOL NULL,
-                                     |     CONSTRAINT "primary" PRIMARY KEY (code ASC, user_email ASC),
-                                     |     CONSTRAINT fk_user_email_ref_users FOREIGN KEY (user_email) REFERENCES max_schema.users(email),
-                                     |     FAMILY "primary" (code, user_email, usage_count)
-                                     | )
-(1 row)
-~~~
-
-Note that none of the tables that you have created thus far have secondary indexes. For guidance on adding secondary indexes, see at [Add Secondary Indexes](schema-design-indexes.html).
-
-## What's next?
-
-- [Add Secondary Indexes](schema-design-indexes.html)
-- [Online Schema Changes](online-schema-changes.html)
-
-You might also be interested in the following pages:
-
-- [Computed Columns](computed-columns.html)
-- [Column Families](column-families.html)
-- [`CREATE TABLE`](create-table.html)
-- [Data Types](data-types.html)
-- [`PRIMARY KEY`](primary-key.html)
-- [Constraints](constraints.html)
-- [Cockroach Commands](cockroach-commands.html)
-- [Create a User-defined Schema](schema-design-schema.html)
-- [Create a Database](schema-design-database.html)
-- [Schema Design Overview](schema-design-overview.html)
-- [CockroachDB naming hierarchy](sql-name-resolution.html#naming-hierarchy)
diff --git a/src/current/v20.2/schema-design-update.md b/src/current/v20.2/schema-design-update.md
deleted file mode 100644
index 654626e18ae..00000000000
--- a/src/current/v20.2/schema-design-update.md
+++ /dev/null
@@ -1,340 +0,0 @@
----
-title: Change and Remove Objects in a Database Schema
-summary: How to change and remove objects in a CockroachDB database schema.
-toc: true
----
-
-This page provides an overview on changing and removing the objects in a database schema, with some simple examples based on Cockroach Labs' fictional vehicle-sharing company, [MovR](movr.html).
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Review the database schema objects](schema-design-overview.html).
-- [Create a database](schema-design-database.html).
-- [Create a user-defined schema](schema-design-schema.html).
-- [Create a table](schema-design-table.html).
-- [Add secondary indexes](schema-design-indexes.html).
-
-## Alter database schema objects
-
-To change an existing object in a database schema, use an `ALTER` statement.
-
-`ALTER` statements generally take the following form:
-
-~~~
-ALTER {OBJECT_TYPE} {object_name} {SUBCOMMAND};
-~~~
-
-Parameter | Description
-----------|------------
-`{OBJECT_TYPE}` | The type of the object.
-`{object_name}` | The name of the object.
-`{SUBCOMMAND}` | The subcommand for the change that you would like to make.
-
-For examples, see [below](#altering-objects-examples).
-
-CockroachDB supports the following `ALTER` statements:
-
-- [`ALTER DATABASE`](alter-database.html)
-- [`ALTER SCHEMA`](alter-schema.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`ALTER INDEX`](alter-index.html)
-- [`ALTER VIEW`](alter-view.html)
-- [`ALTER SEQUENCE`](alter-sequence.html)
-- [`ALTER TYPE`](alter-type.html)
-- [`ALTER USER/ROLE`](alter-user.html)
-
-### Best practices for altering objects
-
-- After you initialize a database schema, make any additional database schema changes in a separate set of changes (e.g., for the Cockroach SQL client, a separate `.sql` file; for Liquibase, a separate *changeset*).
-
-- For `ALTER TABLE` statements, combine multiple subcommands in a single `ALTER TABLE` statement, where possible.
-
-- {% include {{page.version.version}}/sql/dev-schema-changes.md %}
-
-- {% include {{page.version.version}}/sql/dev-schema-change-limits.md %}
-
-### Altering objects examples
-
-Suppose you want to make some changes to the `users` table that you created in [Create a Table](schema-design-table.html). In specific, you want to do the following:
-
-- Add a new `username` column.
-- Change the columns in the table's primary key to `username` column and `email`.
-- Move the table to the `abbey_schema` user-defined schema.
-- Change the owner of the table to `abbey`.
-
-The `ALTER TABLE` statement has subcommands for all of these changes:
-
-- To add a new column, use the [`ADD COLUMN` subcommand](add-column.html).
-- To change the primary key columns of a table, use the [`ALTER PRIMARY KEY` subcommand](alter-primary-key.html).
-- To move a table to a different schema, use the [`SET SCHEMA`](set-schema.html) subcommand.
-- To change the owner of a table, use the [`OWNER  TO`](owner-to.html) subcommand.
-
-Create a new `.sql` file for the changes that you plan to make to the table:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ touch update_users_table.sql
-~~~
-
-Open `update_users_table.sql` in a text editor, and add the `ALTER TABLE` statement for adding the `username` column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE IF EXISTS movr.max_schema.users ADD COLUMN username STRING;
-~~~
-
-Under that first `ALTER TABLE` statement, add another `ALTER TABLE` statement for changing the primary key columns to `username` and `email`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE IF EXISTS movr.max_schema.users ALTER PRIMARY KEY USING COLUMNS (username, email);
-~~~
-
-In order to add a column to an existing table's primary key index, the column must have an existing [`NOT NULL` constraint](not-null.html). Neither the `username` nor the `email` columns have `NOT NULL` constraints.
-
-Add a `NOT NULL` constraint to the `ADD COLUMN` subcommand for `username`. In the same `ALTER TABLE` statement, add an [`ALTER COLUMN` subcommand](alter-column.html) to set the `NOT NULL` constraint on the `email` column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE IF EXISTS movr.max_schema.users
-  ADD COLUMN username STRING NOT NULL,
-  ALTER COLUMN email SET NOT NULL;
-~~~
-
-The file should now look something like this:
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE IF EXISTS movr.max_schema.users
-  ADD COLUMN username STRING NOT NULL,
-  ALTER COLUMN email SET NOT NULL;
-
-ALTER TABLE IF EXISTS movr.max_schema.users ALTER PRIMARY KEY USING COLUMNS (username, email);
-~~~
-
-The remaining changes that you want to make will require `ALTER TABLE` statements with the `SET SCHEMA` and `OWNER TO` subcommands. An `ALTER TABLE ... SET SCHEMA` statement will change the contents of two schemas, and an `ALTER TABLE ... OWNER TO` statement will change the privileges of two users. To follow [authorization best practices](authorization.html#authorization-best-practices), you should execute any statements that change databases, user-defined schemas, or user privileges as a member of the `admin` role (e.g., as `root`).
-
-Create a new `.sql` file for the remaining `ALTER TABLE` statements, to be executed by `root`:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ touch update_users_owner.sql
-~~~
-
-Add the following statements to the file:
-
-{% include copy-clipboard.html %}
-~~~ sql
-ALTER TABLE IF EXISTS movr.max_schema.users SET SCHEMA abbey_schema;
-
-ALTER TABLE IF EXISTS movr.abbey_schema.users OWNER TO abbey;
-~~~
-
-To execute the statements in the `update_users_table.sql` file as `max`, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=max \
---database=movr
-< update_users_table.sql
-~~~
-
-To execute the statements in the `update_users_owner.sql` file as `root`, run the following command:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=root \
---database=movr
-< update_users_owner.sql
-~~~
-
-The `users` table should now have a new column, a different primary key, a different schema, and a different owner.
-
-You can verify with some `SHOW` statements:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=abbey \
---database=movr \
---execute="SHOW SCHEMAS; SHOW TABLES; SHOW CREATE TABLE movr.abbey_schema.users;"
-~~~
-
-~~~
-     schema_name     | owner
----------------------+--------
-  abbey_schema       | abbey
-  crdb_internal      | NULL
-  information_schema | NULL
-  max_schema         | max
-  pg_catalog         | NULL
-  pg_extension       | NULL
-  public             | admin
-(7 rows)
-
-  schema_name  |    table_name    | type  | owner | estimated_row_count
----------------+------------------+-------+-------+----------------------
-  abbey_schema | user_promo_codes | table | abbey |                   0
-  abbey_schema | users            | table | abbey |                   0
-  max_schema   | rides            | table | max   |                   0
-  max_schema   | vehicles         | table | max   |                   0
-(4 rows)
-
-        table_name        |                                 create_statement
---------------------------+-----------------------------------------------------------------------------------
-  movr.abbey_schema.users | CREATE TABLE abbey_schema.users (
-                          |     first_name STRING NOT NULL,
-                          |     last_name STRING NOT NULL,
-                          |     email STRING NOT NULL,
-                          |     username STRING NOT NULL,
-                          |     CONSTRAINT "primary" PRIMARY KEY (username ASC, email ASC),
-                          |     UNIQUE INDEX users_first_name_last_name_key (first_name ASC, last_name ASC),
-                          |     UNIQUE INDEX users_email_key (email ASC),
-                          |     FAMILY "primary" (first_name, last_name, email, username)
-                          | )
-(1 row)
-~~~
-
-## Drop database schema objects
-
-To drop an object from a database schema, use a `DROP` statement.
-
-`DROP` statements generally take the following form:
-
-~~~
-DROP {OBJECT_TYPE} {object_name} CASCADE;
-~~~
-
-Parameter | Description
-----------|------------
-`{OBJECT_TYPE}` | The type of the object.
-`{object_name}` | The name of the object.
-`{CASCADE}` | An optional keyword that will drop all objects dependent on the object being dropped.
-
-For examples, see [below](#altering-objects-examples).
-
-CockroachDB supports the following `DROP` statements:
-
-- [`DROP DATABASE`](drop-database.html)
-- [`DROP SCHEMA`](drop-schema.html)
-- [`DROP TABLE`](drop-table.html)
-- [`DROP INDEX`](drop-index.html)
-- [`DROP SEQUENCE`](drop-sequence.html)
-- [`DROP VIEW`](drop-view.html)
-- [`DROP USER/ROLE`](drop-user.html)
-
-{{site.data.alerts.callout_info}}
-To drop columns and column constraints from a table, use the `DROP COLUMN` and `DROP CONSTRAINT` subcommands of the [`ALTER TABLE`](alter-table.html) statement.
-{{site.data.alerts.end}}
-
-### Drop best practices
-
-- Check the contents and dependencies of the object that you want to drop before using the `CASCADE` option. `CASCADE` drops all of the contents of an object, and should be used sparingly after a schema has been initialized.
-
-### Drop example
-
-Suppose that you want to drop an index that isn't being used very much. In particular, you want to drop the index on `first_name` and `last_name` from the `users` table.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=abbey \
---database=movr \
---execute="SHOW INDEXES FROM movr.abbey_schema.users; SHOW CREATE TABLE movr.abbey_schema.users;"
-~~~
-
-~~~
-  table_name |           index_name           | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+--------------------------------+------------+--------------+-------------+-----------+---------+-----------
-  users      | primary                        |   false    |            1 | username    | ASC       |  false  |  false
-  users      | primary                        |   false    |            2 | email       | ASC       |  false  |  false
-  users      | users_first_name_last_name_key |   false    |            1 | first_name  | ASC       |  false  |  false
-  users      | users_first_name_last_name_key |   false    |            2 | last_name   | ASC       |  false  |  false
-  users      | users_first_name_last_name_key |   false    |            3 | username    | ASC       |  false  |   true
-  users      | users_first_name_last_name_key |   false    |            4 | email       | ASC       |  false  |   true
-  users      | users_email_key                |   false    |            1 | email       | ASC       |  false  |  false
-  users      | users_email_key                |   false    |            2 | username    | ASC       |  false  |   true
-(8 rows)
-
-        table_name        |                                 create_statement
---------------------------+-----------------------------------------------------------------------------------
-  movr.abbey_schema.users | CREATE TABLE abbey_schema.users (
-                          |     first_name STRING NOT NULL,
-                          |     last_name STRING NOT NULL,
-                          |     email STRING NOT NULL,
-                          |     username STRING NOT NULL,
-                          |     CONSTRAINT "primary" PRIMARY KEY (username ASC, email ASC),
-                          |     UNIQUE INDEX users_first_name_last_name_key (first_name ASC, last_name ASC),
-                          |     UNIQUE INDEX users_email_key (email ASC),
-                          |     FAMILY "primary" (first_name, last_name, email, username)
-                          | )
-(1 row)
-~~~
-
-Note that `users_first_name_last_name_key` is a `UNIQUE` index, which means that it implies a dependent, `UNIQUE` constraint. To [drop indexes with dependencies](drop-index.html#remove-an-index-and-dependent-objects-with-cascade), you can use the `CASCADE` keyword.
-
-Create a new file, and add the `DROP` statement:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ touch drop_unique_users_idx.sql
-~~~
-
-{{site.data.alerts.callout_info}}
-After creation, the notation for referring to indexes in CockroachDB is `[table_name]@[index_name]`.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~
-DROP INDEX movr.abbey_schema.users@users_first_name_last_name_key CASCADE;
-~~~
-
-To drop the index, execute the file:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=abbey \
---database=movr
-< drop_unique_users_idx.sql
-~~~
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach sql \
---certs-dir={certs-directory} \
---user=abbey \
---database=movr \
---execute="SHOW INDEXES FROM movr.abbey_schema.users;"
-~~~
-
-~~~
-  table_name |   index_name    | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+-----------------+------------+--------------+-------------+-----------+---------+-----------
-  users      | primary         |   false    |            1 | username    | ASC       |  false  |  false
-  users      | primary         |   false    |            2 | email       | ASC       |  false  |  false
-  users      | users_email_key |   false    |            1 | email       | ASC       |  false  |  false
-  users      | users_email_key |   false    |            2 | username    | ASC       |  false  |   true
-(4 rows)
-~~~
-
-## What's next?
-
-- Read about [Online Schema Changes in CockroachDB](online-schema-changes.html).
-- [Write data](insert-data.html)
-- [Read data](query-data.html)
-
-You might also be interested in the following pages:
-
-- [Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/secure-a-cluster.md b/src/current/v20.2/secure-a-cluster.md
deleted file mode 100644
index 5520f5170bc..00000000000
--- a/src/current/v20.2/secure-a-cluster.md
+++ /dev/null
@@ -1,447 +0,0 @@
----
-title: Start a Local Cluster (Secure)
-summary: Run a secure multi-node CockroachDB cluster locally, using TLS certificates to encrypt network communication.
-toc: true
----
-
-<div class="filters filters-big clearfix">
-    <a href="secure-a-cluster.html"><button class="filter-button current"><strong>Secure</strong></button></a>
-    <a href="start-a-local-cluster.html"><button class="filter-button">Insecure</button></a>
-</div>
-
-Once you've [installed CockroachDB](install-cockroachdb.html), it's simple to run a secure multi-node cluster locally, using [TLS certificates](cockroach-cert.html) to encrypt network communication.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-- Make sure you have already [installed CockroachDB](install-cockroachdb.html).
-- For quick SQL testing or app development, consider [running a single-node cluster](cockroach-start-single-node.html) instead.
-- Note that running multiple nodes on a single host is useful for testing CockroachDB, but it's not suitable for production. To run a physically distributed cluster, see [Manual Deployment](manual-deployment.html) or [Orchestrated Deployment](orchestration.html), and review the [Production Checklist](recommended-production-settings.html).
-
-## Step 1. Generate certificates
-
-You can use either [`cockroach cert`](cockroach-cert.html) commands or [`openssl` commands](create-security-certificates-openssl.html) to generate security certificates. This section features the `cockroach cert` commands.
-
-1. Create two directories:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ mkdir certs my-safe-directory
-    ~~~
-
-    Directory | Description
-    ----------|------------
-    `certs` | You'll generate your CA certificate and all node and client certificates and keys in this directory.
-    `my-safe-directory` | You'll generate your CA key in this directory and then reference the key when generating node and client certificates.
-
-2. Create the CA (Certificate Authority) certificate and key pair:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-ca \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-3. Create the certificate and key pair for your nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-node \
-    localhost \
-    $(hostname) \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-    Because you're running a local cluster and all nodes use the same hostname (`localhost`), you only need a single node certificate. Note that this is different than running a production cluster, where you would need to generate a certificate and key for each node, issued to all common names and IP addresses you might use to refer to the node as well as to any load balancer instances.
-
-4. Create a client certificate and key pair for the `root` user:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach cert create-client \
-    root \
-    --certs-dir=certs \
-    --ca-key=my-safe-directory/ca.key
-    ~~~
-
-## Step 2. Start the cluster
-
-1. Use the [`cockroach start`](cockroach-start.html) command to start the first node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=node1 \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    You'll see a message like the following:
-
-    ~~~
-    *
-    * INFO: initial startup completed.
-    * Node will now attempt to join a running cluster, or wait for `cockroach init`.
-    * Client connections will be accepted after this completes successfully.
-    * Check the log file(s) for progress.
-    *
-    ~~~
-
-2. Take a moment to understand the [flags](cockroach-start.html#flags) you used:
-    - The `--certs-dir` directory points to the directory holding certificates and keys.
-    - Since this is a purely local cluster, `--listen-addr=localhost:26257` and `--http-addr=localhost:8080` tell the node to listen only on `localhost`, with port `26257` used for internal and client traffic and port `8080` used for HTTP requests from the DB Console.
-    - The `--store` flag indicates the location where the node's data and logs are stored.
-    - The `--join` flag specifies the addresses and ports of the nodes that will initially comprise your cluster. You'll use this exact `--join` flag when starting other nodes as well.
-
-        {% include {{ page.version.version }}/prod-deployment/join-flag-single-region.md %}
-    - The `--background` flag starts the `cockroach` process in the background so you can continue using the same terminal for other operations.
-
-3. Start two more nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=node2 \
-    --listen-addr=localhost:26258 \
-    --http-addr=localhost:8081 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=node3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    These commands are the same as before but with unique `--store`, `--listen-addr`, and `--http-addr` flags.
-
-4. Use the [`cockroach init`](cockroach-init.html) command to perform a one-time initialization of the cluster, sending the request to any node on the `--join` list:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --certs-dir=certs --host=localhost:26257
-    ~~~
-
-    You'll see the following message:
-
-    ~~~
-    Cluster successfully initialized
-    ~~~
-
-    At this point, each node also prints helpful [startup details](cockroach-start.html#standard-output) to its log. For example, the following command retrieves node 1's startup details:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ grep 'node starting' node1/logs/cockroach.log -A 11
-    ~~~
-
-    The output will look something like this:
-
-    ~~~
-    CockroachDB node starting at {{ now | date: "%Y-%m-%d %H:%M:%S.%6 +0000 UTC" }}
-    build:               CCL {{page.release_info.version}} @ {{page.release_info.build_time}} (go1.12.6)
-    webui:               https://localhost:8080
-    sql:                 postgresql://root@localhost:26257?sslcert=certs%2Fclient.root.crt&sslkey=certs%2Fclient.root.key&sslmode=verify-full&sslrootcert=certs%2Fca.crt
-    RPC client flags:    cockroach <client cmd> --host=localhost:26257 --certs-dir=certs
-    logs:                /Users/<username>/node1/logs
-    temp dir:            /Users/<username>/node1/cockroach-temp966687937
-    external I/O path:   /Users/<username>/node1/extern
-    store[0]:            path=/Users/<username>/node1
-    status:              initialized new cluster
-    clusterID:           b2537de3-166f-42c4-aae1-742e094b8349
-    nodeID:              1
-    ~~~    
-
-## Step 3. Use the built-in SQL client
-
-Now that your cluster is live, you can use any node as a SQL gateway. To test this out, let's use CockroachDB's built-in SQL client.
-
-1. Run the [`cockroach sql`](cockroach-sql.html) command against node 1:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs --host=localhost:26257
-    ~~~
-
-2. Run some basic [CockroachDB SQL statements](learn-cockroachdb-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE bank;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE bank.accounts (id INT PRIMARY KEY, balance DECIMAL);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO bank.accounts VALUES (1, 1000.50);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.accounts;
-    ~~~
-
-    ~~~
-      id | balance
-    +----+---------+
-       1 | 1000.50
-    (1 row)
-    ~~~
-
-3. Now exit the SQL shell on node 1 and open a new shell on node 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs --host=localhost:26258
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    In a real deployment, all nodes would likely use the default port `26257`, and so you wouldn't need to set the port portion of `--host`.
-    {{site.data.alerts.end}}
-
-4. Run the same `SELECT` query as before:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.accounts;
-    ~~~
-
-    ~~~
-      id | balance
-    +----+---------+
-       1 | 1000.50
-    (1 row)
-    ~~~
-
-    As you can see, node 1 and node 2 behaved identically as SQL gateways.
-
-5. Now [create a user with a password](create-user.html#create-a-user-with-a-password), which you will need to [access the DB Console](#step-5-access-the-db-console):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER max WITH PASSWORD 'roach';
-    ~~~
-
-6. Exit the SQL shell on node 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-## Step 4. Run a sample workload
-
-CockroachDB also comes with a number of [built-in workloads](cockroach-workload.html) for simulating client traffic. Let's run the workload based on CockroachDB's sample vehicle-sharing application, [MovR](movr.html).
-
-1. Load the initial dataset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init movr \
-    'postgresql://root@localhost:26257?sslcert=certs%2Fclient.root.crt&sslkey=certs%2Fclient.root.key&sslmode=verify-full&sslrootcert=certs%2Fca.crt'
-    ~~~
-
-    ~~~
-    I190926 16:50:35.663708 1 workload/workloadsql/dataload.go:135  imported users (0s, 50 rows)
-    I190926 16:50:35.682583 1 workload/workloadsql/dataload.go:135  imported vehicles (0s, 15 rows)
-    I190926 16:50:35.769572 1 workload/workloadsql/dataload.go:135  imported rides (0s, 500 rows)
-    I190926 16:50:35.836619 1 workload/workloadsql/dataload.go:135  imported vehicle_location_histories (0s, 1000 rows)
-    I190926 16:50:35.915498 1 workload/workloadsql/dataload.go:135  imported promo_codes (0s, 1000 rows)
-    ~~~
-
-2. Run the workload for 5 minutes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run movr \
-    --duration=5m \
-    'postgresql://root@localhost:26257?sslcert=certs%2Fclient.root.crt&sslkey=certs%2Fclient.root.key&sslmode=verify-full&sslrootcert=certs%2Fca.crt'
-    ~~~
-
-## Step 5. Access the DB Console
-
-The CockroachDB [DB Console](ui-overview.html) gives you insight into the overall health of your cluster as well as the performance of the client workload.
-
-1. On secure clusters, [certain pages of the DB Console](ui-overview.html#db-console-access) can only be accessed by `admin` users.
-
-    Run the [`cockroach sql`](cockroach-sql.html) command against node 1:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs --host=localhost:26257
-    ~~~
-
-2.  Assign `max` to the `admin` role (you only need to do this once):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > GRANT admin TO max;
-    ~~~
-
-3. Exit the SQL shell:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-4. Go to <a href="https://localhost:8080" data-proofer-ignore>https://localhost:8080</a>. Note that your browser will consider the CockroachDB-created certificate invalid; you'll need to click through a warning message to get to the UI.
-
-    {% include {{ page.version.version }}/misc/chrome-localhost.md %}
-
-5. Log in with the username and password you created earlier (`max`/`roach`).
-
-6. On the [**Cluster Overview**](ui-cluster-overview-page.html), notice that three nodes are live, with an identical replica count on each node:
-
-    <img src="{{ 'images/v20.2/ui_cluster_overview_3_nodes.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    This demonstrates CockroachDB's [automated replication](demo-replication-and-rebalancing.html) of data via the Raft consensus protocol.    
-
-    {{site.data.alerts.callout_info}}
-    Capacity metrics can be incorrect when running multiple nodes on a single machine. For more details, see this [limitation](known-limitations.html#available-capacity-metric-in-the-db-console).
-    {{site.data.alerts.end}}
-
-7. Click [**Metrics**](ui-overview-dashboard.html) to access a variety of time series dashboards, including graphs of SQL queries and service latency over time:
-
-    <img src="{{ 'images/v20.2/ui_overview_dashboard_3_nodes.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-8. Use the [**Databases**](ui-databases-page.html), [**Statements**](ui-statements-page.html), and [**Jobs**](ui-jobs-page.html) pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively.
-
-## Step 6. Simulate node failure
-
-1. In a new terminal, run the [`cockroach quit`](cockroach-quit.html) command against a node to simulate a node failure:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --certs-dir=certs --host=localhost:26259
-    ~~~
-
-2. Back in the DB Console, despite one node being "suspect", notice the continued SQL traffic:
-
-    <img src="{{ 'images/v20.2/ui_overview_dashboard_1_suspect.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    This demonstrates CockroachDB's use of the Raft consensus protocol to [maintain availability and consistency in the face of failure](demo-fault-tolerance-and-recovery.html); as long as a majority of replicas remain online, the cluster and client traffic continue uninterrupted.
-
-4. Restart node 3:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=node3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-## Step 7. Scale the cluster
-
-Adding capacity is as simple as starting more nodes with `cockroach start`.
-
-1. Start 2 more nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=node4 \
-    --listen-addr=localhost:26260 \
-    --http-addr=localhost:8083 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --store=node5 \
-    --listen-addr=localhost:26261 \
-    --http-addr=localhost:8084 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    Again, these commands are the same as before but with unique `--store`, `--listen-addr`, and `--http-addr` flags.
-
-2. Back on the **Cluster Overview** in the DB Console, you'll now see 5 nodes listed:
-
-    <img src="{{ 'images/v20.2/ui_cluster_overview_5_nodes.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    At first, the replica count will be lower for nodes 4 and 5. Very soon, however, you'll see those numbers even out across all nodes, indicating that data is being [automatically rebalanced](demo-replication-and-rebalancing.html) to utilize the additional capacity of the new nodes.
-
-## Step 8. Stop the cluster
-
-1. When you're done with your test cluster, use the [`cockroach quit`](cockroach-quit.html) command to gracefully shut down each node.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --certs-dir=certs --host=localhost:26257
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --certs-dir=certs --host=localhost:26258
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --certs-dir=certs --host=localhost:26259
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    For nodes 4 and 5, the shutdown process will take longer (about a minute each) and will eventually force the nodes to stop. This is because, with only 2 of 5 nodes left, a majority of replicas are not available, and so the cluster is no longer operational.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --certs-dir=certs --host=localhost:26260
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --certs-dir=certs --host=localhost:26261
-    ~~~
-
-2. To restart the cluster at a later time, run the same `cockroach start` commands as earlier from the directory containing the nodes' data stores.  
-
-    If you do not plan to restart the cluster, you may want to remove the nodes' data stores and the certificate directories:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -rf node1 node2 node3 node4 node5 certs my-safe-directory
-    ~~~
-
-## What's next?
-
-- [Install the client driver](install-client-drivers.html) for your preferred language
-- Learn more about [CockroachDB SQL](learn-cockroachdb-sql.html) and the [built-in SQL client](cockroach-sql.html)
-- Further explore CockroachDB capabilities like [fault tolerance and automated repair](demo-fault-tolerance-and-recovery.html), [geo-partitioning](demo-low-latency-multi-region-deployment.html), [serializable transactions](demo-serializable.html), and [JSON support](demo-json-support.html)
-
-You might also be interested in the following pages:
-
-- [CockroachDB SQL client](cockroach-sql.html)
-- [Hello World Example Apps](example-apps.html)
diff --git a/src/current/v20.2/security-overview.md b/src/current/v20.2/security-overview.md
deleted file mode 100644
index affdfcb4016..00000000000
--- a/src/current/v20.2/security-overview.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: CockroachDB Security
-summary: Learn about the authentication, encryption, authorization, and audit log features for secure CockroachDB clusters.
-toc: true
----
-
-An insecure CockroachDB cluster comes with serious risks:
-
-- Your cluster is open to any client that can access any node's IP addresses.
-- Any user, even `root`, can log in without providing a password.
-- Any user, connecting as `root`, can read or write any data in your cluster.
-- There is no network encryption or authentication, and thus no confidentiality.
-
-To avoid these security risks, CockroachDB provides authentication, encryption, authorization, and audit logging features to deploy secure clusters. Before we deep-dive into how these features work, let's discuss why we need each of these features.
-
-## Security overview
-
-It all starts with the desire for two parties to communicate securely over an insecure computer network. A conventional solution to ensure secure communication is **symmetric encryption** that involves encrypting and decrypting a plaintext message using a shared key. This seems like the logical solution until you realize that you need a secure communication channel to share the encryption key. This is a Catch-22 situation: How do you establish a secure channel to share the encryption key?
-
-An elegant solution is to use **Public Key Cryptography (PKI)** (also called **asymmetric encryption**) to establish a secure communication channel, and then sharing the symmetric encryption key over the secure channel.
-
-Asymmetric encryption involves a pair of keys instead of a single key. The two keys are called the **public key** and the **private key**. The keys consist of very long numbers linked mathematically in a way such that a message encrypted using a public key can only be decrypted using the private key and vice versa. The message cannot be decrypted using the same key that was used to encrypt the message.
-
-CockroachDB uses the [TLS 1.2](https://en.wikipedia.org/wiki/Transport_Layer_Security) security protocol that takes advantage of both symmetric as well as asymmetric encryption. The TLS 1.2 protocol uses asymmetric encryption to establish a secure channel as well as **authenticate** the communicating parties. It then uses symmetric encryption to protect data in flight.
-
-However, it's not enough to protect data in flight; you also need to protect data at rest. That's where CockroachDB's **Encryption at Rest** feature comes into the picture. Encryption at Rest is an Enterprise feature that allows encryption of all files on disk using [AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard) in [counter mode](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Counter_(CTR)), with all key
-sizes allowed.
-
-Along with authentication and encryption, we also need to allow CockroachDB to restrict access to **authorized** clients (or nodes acting as clients). CockroachDB allows you to create, manage, and remove your cluster's [users](authorization.html#create-and-manage-users) and assign SQL-level [privileges](authorization.html#assign-privileges) to the users. Additionally, you can use [role-based access management (RBAC)](authorization.html#create-and-manage-roles) for simplified user management.
-
-Finally, CockroachDB's **SQL audit logging** gives you detailed information about queries being executed against your system. This feature is especially useful when you want to log all queries that are run against a table containing personally identifiable information (PII).
-
-The following section summarizes the CockroachDB security features and provides links to detailed documentation for each feature.
-
-## Security features in CockroachDB
-
-Security feature | Description
--------------|------------
-[Authentication](authentication.html) | <ul><li>Inter-node and node identity authentication using TLS 1.2</li><li>Client identity authentication using TLS 1.2 or username/password</li></ul>
-[Encryption](encryption.html) | <ul><li>Encryption in flight using TLS 1.2</li><li> Encryption at Rest using AES in counter mode (Enterprise feature)</li></ul>
-[Authorization](authorization.html) | <ul><li>Users and privileges</li><li> Role-based access control</li></ul>
-[Audit logging](sql-audit-logging.html) | `ALTER TABLE...EXPERIMENTAL AUDIT` to get detailed information about queries being executed against your system
diff --git a/src/current/v20.2/select-clause.md b/src/current/v20.2/select-clause.md
deleted file mode 100644
index 146e74287c4..00000000000
--- a/src/current/v20.2/select-clause.md
+++ /dev/null
@@ -1,569 +0,0 @@
----
-title: Simple SELECT Clause
-summary: The Simple SELECT clause loads or computes data from various sources.
-toc: true
-key: select.html
----
-
-The simple `SELECT` clause is the main SQL syntax to read and process
-existing data.
-
-When used as a stand-alone statement, the simple `SELECT` clause is
-also called "the `SELECT` statement". However, it is also a
-[selection clause](selection-queries.html#selection-clauses) that can be combined
-with other constructs to form more complex [selection queries](selection-queries.html).
-
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/simple_select_clause.html %}
-</div>
-
-
-{{site.data.alerts.callout_success}}
-The simple `SELECT` clause also has other applications not covered here, such as executing [functions](functions-and-operators.html) like `SELECT current_timestamp();`.
-{{site.data.alerts.end}}
-
-## Required privileges
-
-The user must have the `SELECT` [privilege](authorization.html#assign-privileges) on the tables used as operands.
-
-## Parameters
-
-Parameter | Description
-----------|-------------
-`DISTINCT` or `ALL` | See [Eliminate Duplicate Rows](#eliminate-duplicate-rows).
-`DISTINCT ON ( a_expr [, ...] )` | `DISTINCT ON` followed by a list of [scalar expressions](scalar-expressions.html) within parentheses. See [Eliminate Duplicate Rows](#eliminate-duplicate-rows).
-`target_elem` | A [scalar expression](scalar-expressions.html) to compute a column in each result row, or `*` to automatically retrieve all columns from the `FROM` clause.<br><br>If `target_elem` contains an [aggregate function](functions-and-operators.html#aggregate-functions), a `GROUP BY` clause can be used to further control the aggregation.
-`table_ref` | The [table expression](table-expressions.html) you want to retrieve data from.<br><br>Using two or more table expressions in the `FROM` sub-clause, separated with a comma, is equivalent to a [`CROSS JOIN`](joins.html) expression.
-`AS OF SYSTEM TIME timestamp` | Retrieve data as it existed [as of `timestamp`](as-of-system-time.html). <br><br>**Note**: Because `AS OF SYSTEM TIME` returns historical data, your reads might be stale.
-`WHERE a_expr` | Only retrieve rows that return `TRUE` for `a_expr`, which must be a [scalar expression](scalar-expressions.html) that returns Boolean values using columns (e.g., `<column> = <value>`).
-`GROUP BY a_expr` | Group results on one or more columns.<br><br>When an [aggregate function](functions-and-operators.html#aggregate-functions) follows `SELECT` as a `target_elem`, or `HAVING` as an `a_expr`, you can [create aggregate groups](#create-aggregate-groups) on column groupings listed after `GROUP BY`.<br> You can group columns by an alias (i.e., a label assigned to the column with an `AS` clause) rather than the column name.<br> If aggregate groups are created on a full primary key, any column in the table can be selected as a `target_elem`, or specified in a `HAVING` clause.<br> If a selected column is in a [subquery](subqueries.html), and the column references a higher scope, the column does not need to be included in the `GROUP BY` clause (if one exists).<br><br>Using a `GROUP BY` clause in a statement without an aggregate function is equivalent to using a [`DISTINCT ON`](#eliminate-duplicate-rows) clause on the grouping columns.
-`HAVING a_expr` | Only retrieve aggregate function groups that return `TRUE` for `a_expr`, which must be a [scalar expression](scalar-expressions.html) that returns Boolean values using an aggregate function (e.g., `<aggregate function> = <value>`). <br/><br/>`HAVING` works like the `WHERE` clause, but for aggregate functions.
-`WINDOW window_definition_list` | A list of [window definitions](window-functions.html#window-definitions).
-
-## Eliminate duplicate rows
-
-The `DISTINCT` subclause specifies to remove duplicate rows.
-
-By default, or when `ALL` is specified, `SELECT` returns all the rows
-selected, without removing duplicates. When `DISTINCT` is specified,
-duplicate rows are eliminated.
-
-Without `ON`, two rows are considered duplicates if they are equal on
-all the results computed by `SELECT`.
-
-With `ON`, two rows are considered duplicates if they are equal only
-using the [scalar expressions](scalar-expressions.html) listed with `ON`. When two rows are considered duplicates according to `DISTINCT ON`, the values from the first `FROM` row in the order specified by [`ORDER BY`](order-by.html) are used to compute the remaining target expressions. If `ORDER BY` is not specified, CockroachDB will pick any one of the duplicate rows as first row, non-deterministically.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Choose columns
-
-#### Retrieve specific columns
-
-Retrieve specific columns by naming them in a comma-separated list:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id, city, name FROM users LIMIT 10;
-~~~
-
-~~~
-                   id                  |     city      |       name
-+--------------------------------------+---------------+------------------+
-  7ae147ae-147a-4000-8000-000000000018 | los angeles   | Alfred Garcia
-  570a3d70-a3d7-4c00-8000-000000000011 | san francisco | Amy Cobb
-  428f5c28-f5c2-4000-8000-00000000000d | seattle       | Anita Atkinson
-  1eb851eb-851e-4800-8000-000000000006 | boston        | Brian Campbell
-  23d70a3d-70a3-4800-8000-000000000007 | boston        | Carl Mcguire
-  a8f5c28f-5c28-4800-8000-000000000021 | detroit       | Carl Russell
-  147ae147-ae14-4b00-8000-000000000004 | new york      | Catherine Nelson
-  99999999-9999-4800-8000-00000000001e | detroit       | Charles Montoya
-  e147ae14-7ae1-4800-8000-00000000002c | paris         | Cheyenne Smith
-  2e147ae1-47ae-4400-8000-000000000009 | washington dc | Cindy Medina
-(10 rows)
-~~~
-
-#### Retrieve all columns
-
-Retrieve all columns by using `*`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users LIMIT 10;
-~~~
-
-~~~
-                   id                  |   city    |        name        |            address             | credit_card
-+--------------------------------------+-----------+--------------------+--------------------------------+-------------+
-  c28f5c28-f5c2-4000-8000-000000000026 | amsterdam | Maria Weber        | 14729 Karen Radial             | 5844236997
-  c7ae147a-e147-4000-8000-000000000027 | amsterdam | Tina Miller        | 97521 Mark Extensions          | 8880478663
-  cccccccc-cccc-4000-8000-000000000028 | amsterdam | Taylor Cunningham  | 89214 Jennifer Well            | 5130593761
-  d1eb851e-b851-4800-8000-000000000029 | amsterdam | Kimberly Alexander | 48474 Alfred Hollow            | 4059628542
-  19999999-9999-4a00-8000-000000000005 | boston    | Nicole Mcmahon     | 11540 Patton Extensions        | 0303726947
-  1eb851eb-851e-4800-8000-000000000006 | boston    | Brian Campbell     | 92025 Yang Village             | 9016427332
-  23d70a3d-70a3-4800-8000-000000000007 | boston    | Carl Mcguire       | 60124 Palmer Mews Apt. 49      | 4566257702
-  28f5c28f-5c28-4600-8000-000000000008 | boston    | Jennifer Sanders   | 19121 Padilla Brooks Apt. 12   | 1350968125
-  80000000-0000-4000-8000-000000000019 | chicago   | Matthew Clay       | 49220 Lisa Junctions           | 9132291015
-  851eb851-eb85-4000-8000-00000000001a | chicago   | Samantha Coffey    | 6423 Jessica Underpass Apt. 87 | 9437219051
-(10 rows)
-~~~
-
-### Filter rows
-
-#### Filter on a single condition
-
-Filter rows with expressions that use columns and return Boolean values in the `WHERE` clause:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name, id FROM users WHERE city='seattle';
-~~~
-
-~~~
-        name       |                  id
-+------------------+--------------------------------------+
-  Anita Atkinson   | 428f5c28-f5c2-4000-8000-00000000000d
-  Patricia Herrera | 47ae147a-e147-4000-8000-00000000000e
-  Holly Williams   | 4ccccccc-cccc-4c00-8000-00000000000f
-  Ryan Hickman     | 51eb851e-b851-4c00-8000-000000000010
-(4 rows)
-~~~
-
-#### Filter on multiple conditions
-
-To use multiple `WHERE` filters join them with `AND` or `OR`. You can also create negative filters with `NOT`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM vehicles WHERE city = 'seattle' AND status = 'available';
-~~~
-
-~~~
-                   id                  |  city   | type |               owner_id               |       creation_time       |  status   |    current_location    |                  ext
-+--------------------------------------+---------+------+--------------------------------------+---------------------------+-----------+------------------------+----------------------------------------+
-  44444444-4444-4400-8000-000000000004 | seattle | bike | 428f5c28-f5c2-4000-8000-00000000000d | 2019-01-02 03:04:05+00:00 | available | 37754 Farmer Extension | {"brand": "Merida", "color": "yellow"}
-(1 row)
-~~~
-
-#### Filter values with a list
-
-Using `WHERE <column> IN (<comma separated list of values>)` performs an `OR` search for listed values in the specified column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name, id FROM users WHERE city IN ('new york', 'chicago', 'seattle');
-~~~
-
-~~~
-        name       |                  id
-+------------------+--------------------------------------+
-  Matthew Clay     | 80000000-0000-4000-8000-000000000019
-  Samantha Coffey  | 851eb851-eb85-4000-8000-00000000001a
-  Jessica Martinez | 8a3d70a3-d70a-4000-8000-00000000001b
-  John Hines       | 8f5c28f5-c28f-4000-8000-00000000001c
-  Kenneth Barnes   | 947ae147-ae14-4800-8000-00000000001d
-  Robert Murphy    | 00000000-0000-4000-8000-000000000000
-  James Hamilton   | 051eb851-eb85-4ec0-8000-000000000001
-  Judy White       | 0a3d70a3-d70a-4d80-8000-000000000002
-  Devin Jordan     | 0f5c28f5-c28f-4c00-8000-000000000003
-  Catherine Nelson | 147ae147-ae14-4b00-8000-000000000004
-  Anita Atkinson   | 428f5c28-f5c2-4000-8000-00000000000d
-  Patricia Herrera | 47ae147a-e147-4000-8000-00000000000e
-  Holly Williams   | 4ccccccc-cccc-4c00-8000-00000000000f
-  Ryan Hickman     | 51eb851e-b851-4c00-8000-000000000010
-(14 rows)
-~~~
-
-#### Select distinct rows
-
-Columns without the [Primary Key](primary-key.html) or [Unique](unique.html) constraints can have multiple instances of the same value:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name FROM users WHERE city in ('los angeles', 'washington dc');
-~~~
-
-~~~
-         name
-+---------------------+
-  Ricky Beck
-  Michael Brown
-  William Wood
-  Alfred Garcia
-  Cindy Medina
-  Daniel Hernandez MD
-  Sarah Wang DDS
-  Michael Brown
-(8 rows)
-~~~
-
-Using `DISTINCT`, you can remove all but one instance of duplicate values from your retrieved data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT DISTINCT name FROM users WHERE city in ('los angeles', 'washington dc');
-~~~
-
-~~~
-         name
-+---------------------+
-  Ricky Beck
-  Michael Brown
-  William Wood
-  Alfred Garcia
-  Cindy Medina
-  Daniel Hernandez MD
-  Sarah Wang DDS
-(7 rows)
-~~~
-
-### Rename columns in output
-
-Instead of outputting a column's name in the retrieved table, you can change its label using `AS`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT current_location AS ny_address, id, type, status FROM vehicles WHERE city = 'new york';
-~~~
-
-~~~
-        ny_address       |                  id                  |    type    | status
-+------------------------+--------------------------------------+------------+--------+
-  64110 Richard Crescent | 00000000-0000-4000-8000-000000000000 | skateboard | in_use
-  86667 Edwards Valley   | 11111111-1111-4100-8000-000000000001 | scooter    | in_use
-(2 rows)
-~~~
-
-This *does not* change the name of the column in the table. To do that, use [`RENAME COLUMN`](rename-column.html).
-
-### Search for string values
-
-Search for partial [string](string.html) matches in columns using `LIKE`, which supports the following wildcard operators:
-
-- `%` matches 0 or more characters.
-- `_` matches exactly 1 character.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, status, id FROM vehicles WHERE type LIKE 'scoot%';
-~~~
-
-~~~
-      city      |  status   |                  id
-+---------------+-----------+--------------------------------------+
-  boston        | in_use    | 22222222-2222-4200-8000-000000000002
-  detroit       | in_use    | 99999999-9999-4800-8000-000000000009
-  minneapolis   | in_use    | aaaaaaaa-aaaa-4800-8000-00000000000a
-  minneapolis   | available | bbbbbbbb-bbbb-4800-8000-00000000000b
-  new york      | in_use    | 11111111-1111-4100-8000-000000000001
-  san francisco | available | 55555555-5555-4400-8000-000000000005
-  washington dc | in_use    | 33333333-3333-4400-8000-000000000003
-(7 rows)
-~~~
-
-### Aggregate functions
-
-[Aggregate functions](functions-and-operators.html#aggregate-functions) perform calculations on retrieved rows.
-
-#### Perform aggregate function on entire column
-
-By using an aggregate function as a `target_elem`, you can perform the calculation on the entire column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT MIN(revenue) FROM rides;
-~~~
-
-~~~
-  min
-+------+
-  0.00
-(1 row)
-~~~
-
-You can also use the retrieved value as part of an expression. For example, you can use the result in the `WHERE` clause to select additional rows that were not part of the aggregate function itself:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id, city, vehicle_id, rider_id
-FROM rides
-WHERE revenue = (
-      SELECT
-      MIN(revenue)
-      FROM rides
-);
-~~~
-
-~~~
-                   id                  |    city     |              vehicle_id              |               rider_id
-+--------------------------------------+-------------+--------------------------------------+--------------------------------------+
-  1f3b645a-1cac-4800-8000-00000000003d | boston      | 22222222-2222-4200-8000-000000000002 | 19999999-9999-4a00-8000-000000000005
-  23d70a3d-70a3-4800-8000-000000000046 | boston      | 22222222-2222-4200-8000-000000000002 | 19999999-9999-4a00-8000-000000000005
-  851eb851-eb85-4000-8000-000000000104 | chicago     | 88888888-8888-4800-8000-000000000008 | 851eb851-eb85-4000-8000-00000000001a
-  85a1cac0-8312-4000-8000-000000000105 | chicago     | 88888888-8888-4800-8000-000000000008 | 947ae147-ae14-4800-8000-00000000001d
-  722d0e56-0418-4400-8000-0000000000df | los angeles | 77777777-7777-4800-8000-000000000007 | 7ae147ae-147a-4000-8000-000000000018
-  ae147ae1-47ae-4800-8000-000000000154 | minneapolis | aaaaaaaa-aaaa-4800-8000-00000000000a | b851eb85-1eb8-4000-8000-000000000024
-  0dd2f1a9-fbe7-4c80-8000-00000000001b | new york    | 11111111-1111-4100-8000-000000000001 | 00000000-0000-4000-8000-000000000000
-  f4bc6a7e-f9db-4000-8000-0000000001de | rome        | eeeeeeee-eeee-4000-8000-00000000000e | f0a3d70a-3d70-4000-8000-00000000002f
-(8 rows)
-~~~
-
-#### Perform aggregate function on retrieved rows
-
-By filtering the statement, you can perform the calculation only on retrieved rows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT SUM(revenue) FROM rides WHERE city IN ('new york', 'chicago');
-~~~
-
-~~~
-    sum
-+---------+
-  4079.00
-(1 row)
-~~~
-
-#### Filter columns fed into aggregate functions
-
-You can use `FILTER (WHERE <Boolean expression>)` in the `target_elem` to filter which rows are processed by an aggregate function; those that return `FALSE` or `NULL` for the `FILTER` clause's Boolean expression are not fed into the aggregate function:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT count(*) AS unfiltered, count(*) FILTER (WHERE revenue > 50) AS filtered FROM rides;
-~~~
-
-~~~
-  unfiltered | filtered
-+------------+----------+
-         500 |      252
-(1 row)
-~~~
-
-#### Create aggregate groups
-
-Instead of performing aggregate functions on an the entire set of retrieved rows, you can split the rows into groups and then perform the aggregate function on each of them.
-
-When creating aggregate groups, each column selected as a `target_elem` must be included in a `GROUP BY` clause.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, SUM(revenue) AS city_revenue FROM rides
-WHERE city IN ('new york', 'chicago', 'seattle') GROUP BY city;
-~~~
-
-~~~
-    city   | city_revenue
-+----------+--------------+
-  chicago  |      1990.00
-  new york |      2089.00
-  seattle  |      2029.00
-(3 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
- If the group is created on a primary key column, any column in the table can be selected as a `target_elem`. If a selected column is in a [subquery](subqueries.html) that references a higher scope, a `GROUP BY` clause is not needed.
-{{site.data.alerts.end}}
-
-#### Filter aggregate groups
-
-To filter aggregate groups, use `HAVING`, which is the equivalent of the `WHERE` clause for aggregate groups, which must evaluate to a Boolean value.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, AVG(revenue) as avg FROM rides GROUP BY city
-HAVING AVG(revenue) BETWEEN 50 AND 60;
-~~~
-
-~~~
-      city      |          avg
-+---------------+-----------------------+
-  amsterdam     |                 52.50
-  boston        | 52.666666666666666667
-  los angeles   | 55.951219512195121951
-  minneapolis   | 55.146341463414634146
-  washington dc | 58.756097560975609756
-(5 rows)
-~~~
-
-#### Use aggregate functions in having clause
-
-Aggregate functions can also be used in the `HAVING` clause without needing to be included as a `target_elem`.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT vehicle_id, city FROM rides WHERE city IN ('new york', 'chicago', 'seattle')
-GROUP BY vehicle_id, city HAVING COUNT(vehicle_id) > 20;
-~~~
-
-~~~
-               vehicle_id              |   city
-+--------------------------------------+----------+
-  88888888-8888-4800-8000-000000000008 | chicago
-  11111111-1111-4100-8000-000000000001 | new york
-  44444444-4444-4400-8000-000000000004 | seattle
-(3 rows)
-~~~
-
-#### Order aggregate function input rows by column
-
-Non-commutative aggregate functions are sensitive to the order in which the rows are processed in the surrounding `SELECT` clause. To specify the order in which input rows are processed, you can add an [`ORDER BY`](order-by.html) clause within the function argument list.
-
-For example, suppose you want to create an array of `name` values, ordered alphabetically, and grouped by `city`. You can use the following statement to do so:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, array_agg(name ORDER BY name) AS users FROM users WHERE city IN ('new york', 'chicago', 'seattle') GROUP BY city;
-~~~
-
-~~~
-    city   |                                        users
-+----------+-------------------------------------------------------------------------------------+
-  new york | {"Catherine Nelson","Devin Jordan","James Hamilton","Judy White","Robert Murphy"}
-  seattle  | {"Anita Atkinson","Holly Williams","Patricia Herrera","Ryan Hickman"}
-  chicago  | {"Jessica Martinez","John Hines","Kenneth Barnes","Matthew Clay","Samantha Coffey"}
-(3 rows)
-~~~
-
-You can also order input rows using a column different than the input row column. The following statement returns an array of `revenue` values from high-revenue rides, ordered by ride `end_time`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, array_agg(revenue ORDER BY end_time) as revenues FROM rides WHERE revenue > 80 GROUP BY city;
-~~~
-
-~~~
-      city      |                                    revenues
-+---------------+---------------------------------------------------------------------------------+
-  amsterdam     | {87.00,95.00,87.00,85.00,87.00,85.00,88.00,95.00,86.00,97.00,98.00,87.00,82.00}
-  boston        | {92.00,92.00,86.00,87.00,94.00}
-  detroit       | {89.00,96.00,94.00,92.00,84.00}
-  minneapolis   | {84.00,98.00,86.00,92.00,81.00,99.00,87.00,86.00,88.00,81.00}
-  new york      | {83.00,94.00,86.00,95.00,81.00,91.00,94.00,81.00,81.00,90.00}
-  san francisco | {96.00,85.00,96.00,84.00,94.00,87.00,93.00}
-  chicago       | {82.00,98.00,84.00,99.00,91.00,90.00,83.00,82.00,91.00}
-  los angeles   | {92.00,98.00,92.00,99.00,93.00,87.00,98.00,91.00,89.00,81.00,87.00}
-  paris         | {87.00,94.00,98.00,98.00,95.00,81.00,99.00,94.00,95.00,82.00}
-  rome          | {83.00,96.00,90.00,98.00,95.00,87.00,86.00,97.00}
-  seattle       | {88.00,88.00,82.00,86.00,91.00,81.00,99.00}
-  washington dc | {96.00,94.00,97.00,96.00,88.00,97.00,93.00}
-(12 rows)
-~~~
-
-If you include multiple aggregate functions in a single `SELECT` clause, you can order the input rows of the multiple functions on different columns. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, array_agg(revenue ORDER BY revenue) as revenues_by_revenue, array_agg(revenue ORDER BY end_time) as revenues_by_end_time FROM rides WHERE revenue > 90 GROUP BY city;
-~~~
-~~~
-      city      |             revenues_by_revenue             |            revenues_by_end_time
-+---------------+---------------------------------------------+---------------------------------------------+
-  amsterdam     | {95.00,95.00,97.00,98.00}                   | {95.00,95.00,97.00,98.00}
-  boston        | {92.00,92.00,94.00}                         | {92.00,92.00,94.00}
-  minneapolis   | {92.00,98.00,99.00}                         | {98.00,92.00,99.00}
-  new york      | {91.00,94.00,94.00,95.00}                   | {94.00,95.00,91.00,94.00}
-  paris         | {94.00,94.00,95.00,95.00,98.00,98.00,99.00} | {94.00,98.00,98.00,95.00,99.00,94.00,95.00}
-  san francisco | {93.00,94.00,96.00,96.00}                   | {96.00,96.00,94.00,93.00}
-  chicago       | {91.00,91.00,98.00,99.00}                   | {98.00,99.00,91.00,91.00}
-  detroit       | {92.00,94.00,96.00}                         | {96.00,94.00,92.00}
-  los angeles   | {91.00,92.00,92.00,93.00,98.00,98.00,99.00} | {92.00,98.00,92.00,99.00,93.00,98.00,91.00}
-  rome          | {95.00,96.00,97.00,98.00}                   | {96.00,98.00,95.00,97.00}
-  seattle       | {91.00,99.00}                               | {91.00,99.00}
-  washington dc | {93.00,94.00,96.00,96.00,97.00,97.00}       | {96.00,94.00,97.00,96.00,97.00,93.00}
-(12 rows)
-~~~
-
-### Group by an alias
-
- If a query includes an alias (i.e., a [label assigned to the column with an `AS` clause](#rename-columns-in-output)), you can group the aggregations in the query by the alias rather than by the column name. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city AS c, SUM(revenue) AS c_rev FROM rides GROUP BY c;
-~~~
-~~~
-        c       |  c_rev
-----------------+----------
-  amsterdam     | 2966.00
-  boston        | 3019.00
-  los angeles   | 2772.00
-  new york      | 2923.00
-  paris         | 2849.00
-  rome          | 2653.00
-  san francisco | 2857.00
-  seattle       | 2792.00
-  washington dc | 2797.00
-(9 rows)
-~~~
-
-### Select from a specific index
-
-{% include {{page.version.version}}/misc/force-index-selection.md %}
-
-### Select historical data (time-travel)
-
-CockroachDB lets you find data as it was stored at a given point in
-time using `AS OF SYSTEM TIME` with various [supported
-formats](as-of-system-time.html). This can be also advantageous for
-performance. For more details, see [`AS OF SYSTEM
-TIME`](as-of-system-time.html).
-
-## Advanced uses of `SELECT` clauses
-
-CockroachDB supports numerous ways to combine results from `SELECT`
-clauses together.
-
-See [Selection Queries](selection-queries.html) for
-details. A few examples follow.
-
-### Sorting and limiting query results
-
-To order the results of a `SELECT` clause or limit the number of rows
-in the result, you can combine it with `ORDER BY` or `LIMIT` /
-`OFFSET` to form a [selection query](selection-queries.html) or
-[subquery](table-expressions.html#subqueries-as-table-expressions).
-
-See [Ordering Query Results](order-by.html) and [Limiting Query
-Results](limit-offset.html) for more details.
-
-{{site.data.alerts.callout_info}}When <code>ORDER BY</code> is not included in a query, rows are not sorted by any consistent criteria. Instead, CockroachDB returns them as the coordinating node receives them.<br><br>Also, CockroachDB sorts <a href="null-handling.html#nulls-and-sorting"><code>NULL</code> values</a> first with <code>ASC</code> and last with <code>DESC</code>. This differs from PostgreSQL, which sorts <code>NULL</code> values last with <code>ASC</code> and first with <code>DESC</code>.{{site.data.alerts.end}}
-
-### Combining results from multiple queries
-
-Results from two or more queries can be combined together as follows:
-
-- Using [`JOIN` expressions](joins.html) to combine rows
-  according to conditions on specific columns.
-- Using [set operations](selection-queries.html#set-operations) to combine rows
-  using inclusion/exclusion rules.
-
-### Row-level locking for concurrency control with `SELECT FOR UPDATE`
-
-{% include {{page.version.version}}/sql/select-for-update-overview.md %}
-
-For an example showing how to use it, see  [`SELECT FOR UPDATE`](select-for-update.html).
-
-## See also
-
-- [Scalar Expressions](scalar-expressions.html)
-- [Selection Clauses](selection-queries.html#selection-clauses)
-- [`SELECT FOR UPDATE`](select-for-update.html)
-- [Set Operations](selection-queries.html#set-operations)
-- [Table Expressions](table-expressions.html)
-- [Ordering Query Results](order-by.html)
-- [Limiting Query Results](limit-offset.html)
-- [SQL Performance Best Practices](performance-best-practices-overview.html)
diff --git a/src/current/v20.2/select-for-update.md b/src/current/v20.2/select-for-update.md
deleted file mode 100644
index b2a47672f32..00000000000
--- a/src/current/v20.2/select-for-update.md
+++ /dev/null
@@ -1,157 +0,0 @@
----
-title: SELECT FOR UPDATE
-summary: The SELECT FOR UPDATE statement is used to order transactions under contention.
-keywords: concurrency control, locking, transactions, update locking, update, contention
-toc: true
----
-
-{% include {{page.version.version}}/sql/select-for-update-overview.md %}
-
-## Syntax
-
-The following diagram shows the supported syntax for the optional `FOR` locking clause of a `SELECT` statement.
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/for_locking.html %}
-</div>
-
-For the full `SELECT` statement syntax documentation, see [Selection Queries](selection-queries.html).
-
-## Parameters
-
-### Locking strengths
-
-Locking strength dictates the row-level locking behavior on rows retrieved by a `SELECT` statement.
-
-Parameter | Description
-----------|------------
-`FOR SHARE`/`FOR KEY SHARE` | This syntax is a no-op, allowed for PostgreSQL compatibility. Specifying `FOR SHARE`/`FOR KEY SHARE` does not cause CockroachDB to use shared locks over the rows retrieved by a statement.<br><br>Note that CockroachDB always [ensures serializability](demo-serializable.html), regardless of the specified locking strength.
-`FOR UPDATE`/`FOR NO KEY UPDATE` | Lock the rows returned by the [`SELECT`](selection-queries.html) statement, such that other transactions trying to access the rows must wait for the transaction to finish.<br><br>Note that in CockroachDB, the `FOR NO KEY UPDATE` locking strength is identical to the `FOR UPDATE` locking strength.
-
-### Wait policies
-
-<span class="version-tag">New in v20.2:</span> Wait policies determine how a `SELECT FOR UPDATE` statement handles conflicts with locks held by other active transactions. By default, `SELECT FOR UPDATE` queries on rows that are already locked by an active transaction must wait for the transaction to finish.
-
-Parameter | Description
-----------|------------
-`SKIP LOCKED` | This syntax is not supported, as skipping locked rows is not yet supported by CockroachDB.
-`NOWAIT` | Return an error if a row cannot be locked immediately.
-
-For documentation on all other parameters of a `SELECT` statement, see [Selection Queries](selection-queries.html).
-
-## Required privileges
-
-The user must have the `SELECT` and `UPDATE` [privileges](authorization.html#assign-privileges) on the tables used as operands.
-
-## Examples
-
-### Enforce transaction order when updating the same rows
-
-In this example, we'll use `SELECT FOR UPDATE` to lock a row inside a transaction, forcing other transactions that want to update the same row to wait for the first transaction to complete. The other transactions that want to update the same row are effectively put into a queue based on when they first try to read the value of the row.
-
-This example assumes you are running a [local unsecured cluster](start-a-local-cluster.html).
-
-First, let's connect to the running cluster (we'll call this Terminal 1):
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach sql --insecure
-~~~
-
-Next, let's create a table and insert some rows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE kv (k INT PRIMARY KEY, v INT);
-INSERT INTO kv (k, v) VALUES (1, 5), (2, 10), (3, 15);
-~~~
-
-Next, we'll start a [transaction](transactions.html) and lock the row we want to operate on:
-
-{% include copy-clipboard.html %}
-~~~ sql
-BEGIN;
-SELECT * FROM kv WHERE k = 1 FOR UPDATE;
-~~~
-
-Hit enter twice in the [SQL client](cockroach-sql.html) to send the input so far to be evaluated.  This will result in the following output:
-
-~~~
-  k | v
-+---+----+
-  1 | 5
-(1 row)
-~~~
-
-Now let's open another terminal and connect to the database from a second client (we'll call this Terminal 2):
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach sql --insecure
-~~~
-
-From Terminal 2, start a transaction and try to lock the same row for updates that is already being accessed by the transaction we opened in Terminal 1:
-
-{% include copy-clipboard.html %}
-~~~ sql
-BEGIN;
-SELECT * FROM kv WHERE k = 1 FOR UPDATE;
-~~~
-
-Hit enter twice to send the input so far to be evaluated. Because Terminal 1 has already locked this row, the `SELECT FOR UPDATE` statement from Terminal 2 will appear to "wait".
-
-Back in Terminal 1, let's update the row and commit the transaction:
-
-{% include copy-clipboard.html %}
-~~~ sql
-UPDATE kv SET v = v + 5 WHERE k = 1;
-COMMIT;
-~~~
-
-~~~
-COMMIT
-~~~
-
-Now that the transaction in Terminal 1 has committed, the transaction in Terminal 2 will be "unblocked", generating the following output, which shows the value left by the transaction in Terminal 1:
-
-~~~
-  k | v
-+---+----+
-  1 | 10
-(1 row)
-~~~
-
-The transaction in Terminal 2 can now receive input, so let's update the row in question again:
-
-{% include copy-clipboard.html %}
-~~~ sql
-UPDATE kv SET v = v + 5 WHERE k = 1;
-COMMIT;
-~~~
-
-~~~
-UPDATE 1
-~~~
-
-Finally, we commit the transaction in Terminal 2:
-
-{% include copy-clipboard.html %}
-~~~ sql
-COMMIT;
-~~~
-
-~~~
-COMMIT
-~~~
-
-## See also
-
-- [`SELECT`](select-clause.html)
-- [Selection Queries](selection-queries.html)
-- [Understanding and avoiding transaction contention][transaction_contention]
-
-<!-- Reference links -->
-
-[transaction_contention]: performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention
-[retries]: transactions.html#client-side-intervention
-[select]: select-clause.html
diff --git a/src/current/v20.2/selection-queries.md b/src/current/v20.2/selection-queries.md
deleted file mode 100644
index f4bccdea1b1..00000000000
--- a/src/current/v20.2/selection-queries.md
+++ /dev/null
@@ -1,451 +0,0 @@
----
-title: Selection Queries
-summary: Selection queries can read and process data in CockroachDB.in CockroachDB.
-toc: true
-key: selection-clauses.html
----
-
-Selection queries read and process data in CockroachDB.  They are more
-general than [simple `SELECT` clauses](select-clause.html): they can
-group one or more [selection clauses](#selection-clauses) with [set
-operations](#set-operations) and can request a [specific
-ordering](order-by.html) or [row limit](limit-offset.html).
-
-Selection queries can occur:
-
-- At the top level of a query like other [SQL statements](sql-statements.html).
-- Between parentheses as a [subquery](table-expressions.html#subqueries-as-table-expressions).
-- As [operand to other statements](#using-selection-queries-with-other-statements) that take tabular data as input, for example [`INSERT`](insert.html), [`UPSERT`](upsert.html),  [`CREATE TABLE AS`](create-table-as.html) or [`ALTER ... SPLIT AT`](split-at.html).
-
-
-## Synopsis
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/select.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`common_table_expr` | See [Common Table Expressions](common-table-expressions.html).
-`select_clause` | A valid [selection clause](#selection-clauses), either simple or using [set operations](#set-operations).
-`sort_clause` | An optional `ORDER BY` clause. See [Ordering Query Results](order-by.html) for details.
-`limit_clause` | An optional `LIMIT` clause. See [Limiting Query Results](limit-offset.html) for details.
-`offset_clause` | An optional `OFFSET` clause. See [Limiting Query Results](limit-offset.html) for details.
-`for_locking_clause` |  The `FOR UPDATE` locking clause is used to order transactions by controlling concurrent access to one or more rows of a table.  For more information, see [`SELECT FOR UPDATE`](select-for-update.html).
-
-The optional `LIMIT` and `OFFSET` clauses can appear in any order, but must appear after `ORDER BY`, if also present.
-
-{{site.data.alerts.callout_info}}Because the <code>WITH</code>, <code>ORDER BY</code>, <code>LIMIT</code> and <code>OFFSET</code> sub-clauses are all optional, any simple <a href="#selection-clauses">selection clause</a> is also a valid selection query.{{site.data.alerts.end}}
-
-## Selection clauses
-
-Selection clauses are the main component of a selection query. They
-define tabular data. There are four specific syntax forms collectively named selection clauses:
-
-Form | Usage
------|--------
-[`SELECT`](#select-clause) | Load or compute tabular data from various sources. This is the most common selection clause.
-[`VALUES`](#values-clause) | List tabular data by the client.
-[`TABLE`](#table-clause) | Load tabular data from the database.
-[Set Operations](#set-operations) | Combine tabular data from two or more selection clauses.
-
-{{site.data.alerts.callout_info}}To perform joins or other relational operations over selection clauses, use a <a href="table-expressions.html">table expression</a> and <a href="#composability">convert it back</a> into a selection clause with <a href="#table-clause"><code>TABLE</code></a> or <a href="#select-clause"><code>SELECT</code></a>.{{site.data.alerts.end}}
-
-### Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/select_clause.html %}
-</div>
-
-### `VALUES` clause
-
-#### Syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/values_clause.html %}
-</div>
-
-A `VALUES` clause defines tabular data defined by the expressions
-listed within parentheses. Each parenthesis group defines a single row
-in the resulting table.
-
-The columns of the resulting table data have automatically generated
-names. [These names can be modified with
-`AS`](table-expressions.html#aliased-table-expressions) when the
-`VALUES` clause is used as a sub-query.
-
-#### Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> VALUES (1, 2, 3), (4, 5, 6);
-~~~
-
-~~~
-+---------+---------+---------+
-| column1 | column2 | column3 |
-+---------+---------+---------+
-|       1 |       2 |       3 |
-|       4 |       5 |       6 |
-+---------+---------+---------+
-~~~
-
-### `TABLE` clause
-
-#### Syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/table_clause.html %}
-</div>
-
-A `TABLE` clause reads tabular data from a specified table. The
-columns of the resulting table data are named after the schema of the
-table.
-
-In general, `TABLE x` is equivalent to `SELECT * FROM x`, but it is
-shorter to type.
-
-{{site.data.alerts.callout_info}}Any <a href="table-expressions.html">table expression</a> between parentheses is a valid operand for <code>TABLE</code>, not just <a href="table-expressions.html#table-or-view-names">simple table or view names</a>.{{site.data.alerts.end}}
-
-#### Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE employee_copy AS TABLE employee;
-~~~
-
-This statement copies the content from table `employee` into a new
-table. However, note that the `TABLE` clause does not preserve the indexing,
-foreign key, or constraint and default information from the schema of the
-table it reads from, so in this example, the new table `employee_copy`
-will likely have a simpler schema than `employee`.
-
-Other examples:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> TABLE employee;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO employee_copy TABLE employee;
-~~~
-
-### `SELECT` clause
-
-See [Simple `SELECT` Clause](select-clause.html) for more
-details.
-
-## Set operations
-
-Set operations combine data from two [selection
-clauses](#selection-clauses). They are valid as operand to other
-set operations or as main component in a selection query.
-
-### Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/set_operation.html %}
-</div>
-
-### Set operators
-
-SQL lets you compare the results of multiple [selection clauses](#selection-clauses). You can think of each of the set operators as representing a Boolean operator:
-
-- `UNION` = OR
-- `INTERSECT` = AND
-- `EXCEPT` = NOT
-
-By default, each of these comparisons displays only one copy of each value (similar to `SELECT DISTINCT`). However, each function also lets you add an `ALL` to the clause to display duplicate values.
-
-### Union: Combine two queries
-
-`UNION` combines the results of two queries into one result.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name
-FROM accounts
-WHERE state_opened IN ('AZ', 'NY')
-UNION
-SELECT name
-FROM mortgages
-WHERE state_opened IN ('AZ', 'NY');
-~~~
-~~~
-+-----------------+
-|      name       |
-+-----------------+
-| Naseem Joossens |
-| Ricarda Caron   |
-| Carola Dahl     |
-| Aygün Sanna     |
-+-----------------+
-~~~
-
-To show duplicate rows, you can use `ALL`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name
-FROM accounts
-WHERE state_opened IN ('AZ', 'NY')
-UNION ALL
-SELECT name
-FROM mortgages
-WHERE state_opened IN ('AZ', 'NY');
-~~~
-~~~
-+-----------------+
-|      name       |
-+-----------------+
-| Naseem Joossens |
-| Ricarda Caron   |
-| Carola Dahl     |
-| Naseem Joossens |
-| Aygün Sanna     |
-| Carola Dahl     |
-+-----------------+
-~~~
-
-### Intersect: Retrieve intersection of two queries
-
-`INTERSECT` finds only values that are present in both query operands.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name
-FROM accounts
-WHERE state_opened IN ('NJ', 'VA')
-INTERSECT
-SELECT name
-FROM mortgages;
-~~~
-~~~
-+-----------------+
-|      name       |
-+-----------------+
-| Danijel Whinery |
-| Agar Archer     |
-+-----------------+
-~~~
-
-### Except: Exclude one query's results from another
-
-`EXCEPT` finds values that are present in the first query operand but not the second.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name
-FROM mortgages
-EXCEPT
-SELECT name
-FROM accounts;
-~~~
-~~~
-+------------------+
-|       name       |
-+------------------+
-| Günay García     |
-| Karla Goddard    |
-| Cybele Seaver    |
-+------------------+
-~~~
-
-## Ordering results
-
-The following sections provide examples. For more details, see [Ordering Query Results](order-by.html).
-
-### Order retrieved rows by one column
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT *
-FROM accounts
-WHERE balance BETWEEN 350 AND 500
-ORDER BY balance DESC;
-~~~
-~~~
-+----+--------------------+---------+----------+--------------+
-| id |        name        | balance |   type   | state_opened |
-+----+--------------------+---------+----------+--------------+
-| 12 | Raniya Žitnik      |     500 | savings  | CT           |
-| 59 | Annibale Karga     |     500 | savings  | ND           |
-| 27 | Adelbert Ventura   |     500 | checking | IA           |
-| 86 | Theresa Slaski     |     500 | checking | WY           |
-| 73 | Ruadh Draganov     |     500 | checking | TN           |
-| 16 | Virginia Ruan      |     400 | checking | HI           |
-| 43 | Tahirih Malinowski |     400 | checking | MS           |
-| 50 | Dusan Mallory      |     350 | savings  | NV           |
-+----+--------------------+---------+----------+--------------+
-~~~
-
-### Order retrieved rows by multiple columns
-
-Columns are sorted in the order you list them in `sortby_list`. For example, `ORDER BY a, b` sorts the rows by column `a` and then sorts rows with the same `a` value by their column `b` values.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT *
-FROM accounts
-WHERE balance BETWEEN 350 AND 500
-ORDER BY balance DESC, name ASC;
-~~~
-~~~
-+----+--------------------+---------+----------+--------------+
-| id |        name        | balance |   type   | state_opened |
-+----+--------------------+---------+----------+--------------+
-| 27 | Adelbert Ventura   |     500 | checking | IA           |
-| 59 | Annibale Karga     |     500 | savings  | ND           |
-| 12 | Raniya Žitnik      |     500 | savings  | CT           |
-| 73 | Ruadh Draganov     |     500 | checking | TN           |
-| 86 | Theresa Slaski     |     500 | checking | WY           |
-| 43 | Tahirih Malinowski |     400 | checking | MS           |
-| 16 | Virginia Ruan      |     400 | checking | HI           |
-| 50 | Dusan Mallory      |     350 | savings  | NV           |
-+----+--------------------+---------+----------+--------------+
-~~~
-
-## Limiting row count
-
-You can reduce the number of results with `LIMIT`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id, name
-FROM accounts
-LIMIT 5;
-~~~
-~~~
-+----+------------------+
-| id |       name       |
-+----+------------------+
-|  1 | Bjorn Fairclough |
-|  2 | Bjorn Fairclough |
-|  3 | Arturo Nevin     |
-|  4 | Arturo Nevin     |
-|  5 | Naseem Joossens  |
-+----+------------------+
-~~~
-
-## Row-level locking for concurrency control with `SELECT FOR UPDATE`
-
-{% include {{page.version.version}}/sql/select-for-update-overview.md %}
-
-For an example showing how to use it, see  [`SELECT FOR UPDATE`](select-for-update.html).
-
-## Composability
-
-[Selection clauses](#selection-clauses) are defined in the context of selection queries. [Table expressions](table-expressions.html) are defined in the context of the `FROM` sub-clause of [`SELECT`](select-clause.html). Nevertheless, they can be integrated with one another to form more complex queries or statements.
-
-### Using any selection clause as a selection query
-
-Any [selection clause](#selection-clauses) can be used as a
-selection query with no change.
-
-For example, the construct [`SELECT * FROM accounts`](select-clause.html) is a selection clause. It is also a valid selection query, and thus can be used as a stand-alone statement by appending a semicolon:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-~~~
-+----+-----------------------+---------+----------+--------------+
-| id |         name          | balance |   type   | state_opened |
-+----+-----------------------+---------+----------+--------------+
-|  1 | Bjorn Fairclough      |    1200 | checking | AL           |
-|  2 | Bjorn Fairclough      |    2500 | savings  | AL           |
-|  3 | Arturo Nevin          |     250 | checking | AK           |
-[ truncated ]
-+----+-----------------------+---------+----------+--------------+
-~~~
-
-Likewise, the construct [`VALUES (1), (2), (3)`](#values-clause) is also a selection
-clause and thus can also be used as a selection query on its own:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> VALUES (1), (2), (3);
-~~~
-~~~
-+---------+
-| column1 |
-+---------+
-|       1 |
-|       2 |
-|       3 |
-+---------+
-(3 rows)
-~~~
-
-### Using any table expression as selection clause
-
-Any [table expression](table-expressions.html) can be used as a selection clause (and thus also a selection query) by prefixing it with `TABLE` or by using it as an operand to `SELECT * FROM`.
-
-For example, the [simple table name](table-expressions.html#table-or-view-names) `customers` is a table expression, which designates all rows in that table. The expressions [`TABLE accounts`](selection-queries.html#table-clause) and [`SELECT * FROM accounts`](select-clause.html) are valid selection clauses.
-
-Likewise, the [SQL join expression](joins.html) `customers c JOIN orders o ON c.id = o.customer_id` is a table expression. You can turn it into a valid selection clause, and thus a valid selection query as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> TABLE (customers c JOIN orders o ON c.id = o.customer_id);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers c JOIN orders o ON c.id = o.customer_id;
-~~~
-
-### Using any selection query as table expression
-
-Any selection query (or [selection clause](#selection-clauses)) can be used as a [table
-expression](table-expressions.html) by enclosing it between parentheses, which forms a
-[subquery](table-expressions.html#subqueries-as-table-expressions).
-
-For example, the following construct is a selection query, but is not a valid table expression:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers ORDER BY name LIMIT 5
-~~~
-
-To make it valid as operand to `FROM` or another table expression, you can enclose it between parentheses as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id FROM (SELECT * FROM customers ORDER BY name LIMIT 5);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT o.id
-    FROM orders o
-    JOIN (SELECT * FROM customers ORDER BY name LIMIT 5) AS c
-	  ON o.customer_id = c.id;
-~~~
-
-### Using selection queries with other statements
-
-Selection queries are also valid as operand in contexts that require tabular data.
-
-For example:
-
- Statement | Example using `SELECT` | Example using `VALUES` | Example using `TABLE` |
-|----------------|-----------------------------------|------------------------------------|-------------------------------
- [`INSERT`](insert.html) | `INSERT INTO foo SELECT * FROM bar` | `INSERT INTO foo VALUES (1), (2), (3)` | `INSERT INTO foo TABLE bar`
- [`UPSERT`](upsert.html) | `UPSERT INTO foo SELECT * FROM bar` | `UPSERT INTO foo VALUES (1), (2), (3)` | `UPSERT INTO foo TABLE bar`
- [`CREATE TABLE AS`](create-table-as.html) | `CREATE TABLE foo AS SELECT * FROM bar`  `CREATE TABLE foo AS VALUES (1),(2),(3)` | `CREATE TABLE foo AS TABLE bar`
- [`ALTER ... SPLIT AT`](split-at.html) | `ALTER TABLE foo SPLIT AT SELECT * FROM bar`  `ALTER TABLE foo SPLIT AT VALUES (1),(2),(3)` | `ALTER TABLE foo SPLIT AT TABLE bar`
- Subquery in a [table expression](table-expressions.html) | `SELECT * FROM (SELECT * FROM bar)` | `SELECT * FROM (VALUES (1),(2),(3))` | `SELECT * FROM (TABLE bar)`
- Subquery in a [scalar expression](scalar-expressions.html) | `SELECT * FROM foo WHERE x IN (SELECT * FROM bar)` | `SELECT * FROM foo WHERE x IN (VALUES (1),(2),(3))` | `SELECT * FROM foo WHERE x IN (TABLE bar)`
-
-## See also
-
-- [Simple `SELECT` Clause](select-clause.html)
-- [`SELECT FOR UPDATE`](select-for-update.html)
-- [Table Expressions](table-expressions.html)
-- [Ordering Query Results](order-by.html)
-- [Limiting Query Results](limit-offset.html)
diff --git a/src/current/v20.2/serial.md b/src/current/v20.2/serial.md
deleted file mode 100644
index 13cf7ff60fe..00000000000
--- a/src/current/v20.2/serial.md
+++ /dev/null
@@ -1,272 +0,0 @@
----
-title: SERIAL
-summary: The SERIAL pseudo-type produces integer values automatically.
-toc: true
----
-
-The `SERIAL` pseudo [data type](data-types.html) is a keyword that can
-be used *in lieu* of a real data type when defining table columns. It
-is approximately equivalent to using an [integer type](int.html) with
-a [`DEFAULT` expression](default-value.html) that generates different
-values every time it is evaluated. This default expression in turn
-ensures that inserts that do not specify this column will receive an
-automatically generated value instead of `NULL`.
-
-{{site.data.alerts.callout_info}}
-`SERIAL` is provided only for compatibility with PostgreSQL. New applications should use real data types and a suitable `DEFAULT` expression.
-
-In most cases, we recommend using the [`UUID`](uuid.html) data type with the `gen_random_uuid()` function as the default value, which generates 128-bit values (larger than `SERIAL`'s maximum of 64 bits) and more uniformly scatters them across all of a table's underlying key-value ranges. UUIDs ensure more effectively that multiple nodes share the insert load when a UUID column is used in an index or primary key.
-
-See [this FAQ entry](sql-faqs.html#how-do-i-auto-generate-unique-row-ids-in-cockroachdb) for more details.
-{{site.data.alerts.end}}
-
-## Modes of operation
-
-The keyword `SERIAL` is recognized in `CREATE TABLE` and is
-automatically translated to a real data type and a [`DEFAULT`
-expression](default-value.html) during table creation.
-The result of this translation is then used internally by CockroachDB,
-and can be observed using [`SHOW CREATE`](show-create.html).
-
-The chosen `DEFAULT` expression ensures that different values are
-automatically generated for the column during row insertion.  These
-are not guaranteed to increase monotonically, see [this section
-below](#auto-incrementing-is-not-always-sequential) for details.
-
-There are three possible translation modes for `SERIAL`:
-
- Mode               | Description                                                                                                                       
---------------------|-----------------------------------------------------------------------------------------------------------------------------------
-`rowid` (default)   | `SERIAL` implies `DEFAULT unique_rowid()`. The real data type is always `INT8`, regardless of the `default_int_size` [session variable](set-vars.html) or `sql.defaults.default_int_size` [cluster setting](cluster-settings.html).
-`virtual_sequence`  | `SERIAL` creates a virtual sequence and implies `DEFAULT nextval(<seqname>)`. The real data type is always `INT8`, regardless of the `default_int_size` session variable or `sql.defaults.default_int_size` cluster setting.
-`sql_sequence`      | `SERIAL` creates a regular SQL sequence and implies `DEFAULT nextval(<seqname>)`. The real data type depends on `SERIAL` variant.
-
-These modes can be configured with the [session variable](set-vars.html) `serial_normalization`.
-
-{{site.data.alerts.callout_info}}
-The particular choice of `DEFAULT` expression when clients use the
-`SERIAL` keyword is subject to change in future versions of
-CockroachDB. Applications that wish to use `unique_rowid()`
-specifically must use the full explicit syntax `INT DEFAULT
-unique_rowid()` and avoid `SERIAL` altogether.
-{{site.data.alerts.end}}
-
-### Generated values for modes `rowid` and `virtual_sequence`
-
-In both modes `rowid` and `virtual_sequence`, a value is automatically
-generated using the `unique_rowid()` function.
-This produces a 64-bit integer from the current timestamp and ID of
-the node executing the [`INSERT`](insert.html) or [`UPSERT`](upsert.html) operation.
-This behavior is statistically likely to be globally unique except in
-extreme cases (see [this FAQ
-entry](sql-faqs.html#how-do-i-auto-generate-unique-row-ids-in-cockroachdb)
-for more details).
-
-Also, because value generation using `unique_rowid()` does not require
-inter-node coordination, it is much faster than the other mode
-`sql_sequence` discussed below when multiple SQL clients are writing to
-the table from different nodes.
-
-{{site.data.alerts.callout_info}}
-The difference between `rowid` and `virtual_sequence` is that the
-latter setting also creates a virtual (pseudo) sequence in the
-database. However in both cases the `unique_rowid()` function is
-ultimately used to generate new values.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Values generated by the `unique_rowid()` function do not respect the `default_int_size` [session variable](set-vars.html) or `sql.defaults.default_int_size` [cluster setting](cluster-settings.html).
-{{site.data.alerts.end}}
-
-### Generated values for mode `sql_sequence`
-
-In this mode, a regular [SQL sequence](create-sequence.html) is
-automatically created alongside the table where `SERIAL` is specified.
-
-The actual data type is determined as follows:
-
-| `SERIAL` variant | Real data type |
-|---|---|
-| `SERIAL2`, `SMALLSERIAL` | `INT2` |
-| `SERIAL4` | `INT4` |
-| `SERIAL` | `INT` |
-| `SERIAL8`, `BIGSERIAL` | `INT8` |
-
-Every insert or upsert into the table will then use `nextval()` to
-increment the sequence and produce increasing values.
-
-Because SQL sequences persist the current sequence value in the
-database, inter-node coordination is required when multiple clients
-use the sequence concurrently via different nodes. This can cause
-[contention](sql-faqs.html#what-is-transaction-contention) and impact
-performance negatively.
-
-Therefore, applications should consider using `unique_rowid()` or
-`gen_random_uuid()` as discussed in [this FAQ
-entry](sql-faqs.html#how-do-i-auto-generate-unique-row-ids-in-cockroachdb)
-instead of sequences when possible.
-
-## Examples
-
-### Use `SERIAL` to auto-generate primary keys
-
-In this example, we create a table with the `SERIAL` column as the primary key so we can auto-generate unique IDs on insert.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE serial (a SERIAL PRIMARY KEY, b STRING, c BOOL);
-~~~
-
-The [`SHOW COLUMNS`](show-columns.html) statement shows that the `SERIAL` type is just an alias for `INT` with `unique_rowid()` as the default.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM serial;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  a           | INT8      |    false    | unique_rowid() |                       | {primary} |   false
-  b           | STRING    |    true     | NULL           |                       | {}        |   false
-  c           | BOOL      |    true     | NULL           |                       | {}        |   false
-(3 rows)
-~~~
-
-When we insert rows without values in column `a` and display the new rows, we see that each row has defaulted to a unique value in column `a`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO serial (b,c) VALUES ('red', true), ('yellow', false), ('pink', true);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO serial (a,b,c) VALUES (123, 'white', false);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM serial;
-~~~
-
-~~~
-          a          |   b    |   c
----------------------+--------+--------
-                 123 | white  | false
-  645993277462937601 | red    | true
-  645993277462970369 | yellow | false
-  645993277463003137 | pink   | true
-(4 rows)
-~~~
-
-## Auto-incrementing is not always sequential
-
-It's a common misconception that the auto-incrementing types in PostgreSQL and MySQL generate strictly sequential values. However, there can be gaps and the order is not completely guaranteed:
-
-- Each insert increases the sequence by one, even when the insert is not committed. This means that auto-incrementing types may leave gaps in a sequence.
-- Two concurrent transactions can commit in a different order than their use of sequences, and thus "observe" the values to decrease relative to each other. This effect is amplified by automatic transaction retries.
-
-These are fundamental properties of a transactional system with non-transactional sequences. PostgreSQL, MySQL, and CockroachDB do not increase sequences transactionally with other SQL statements, so these effects can happen in any case.
-
-To experience this for yourself, run through the following example in PostgreSQL:
-
-1. Create a table with a `SERIAL` column:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE increment (a SERIAL PRIMARY KEY);
-    ~~~
-
-2. Run four transactions for inserting rows:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    > INSERT INTO increment DEFAULT VALUES;
-    > ROLLBACK;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    > INSERT INTO increment DEFAULT VALUES;
-    > COMMIT;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    > INSERT INTO increment DEFAULT VALUES;
-    > ROLLBACK;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    > INSERT INTO increment DEFAULT VALUES;
-    > COMMIT;
-    ~~~
-
-3. View the rows created:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * from increment;
-    ~~~
-
-    ~~~
-              a
-    ----------------------
-      645994218934534145
-      645994218978082817
-    (2 rows)
-    ~~~
-
-    Since each insert increased the sequence in column `a` by one, the first committed insert got the value `645994218934534145`, and the second committed insert got the value `645994218978082817`. As you can see, the values aren't strictly sequential, and the last value doesn't give an accurate count of rows in the table.
-
-In summary, the `SERIAL` type in PostgreSQL and CockroachDB, and the `AUTO_INCREMENT` type in MySQL, all behave the same in that they do not create strict sequences. CockroachDB will likely create more gaps than these other databases, but will generate these values much faster. An alternative is to use [`SEQUENCE`](create-sequence.html).
-
-### Additional examples
-
-If two transactions occur concurrently, CockroachDB cannot guarantee monotonically increasing IDs (i.e., first commit is smaller than second commit). Here are three more scenarios that demonstrate this:
-
-Scenario 1:
-
-- At time 1, transaction `T1` `BEGIN`s.
-- At time 2, transaction `T2` `BEGIN`s on the same node (from a different client).
-- At time 3, transaction `T1` creates a `SERIAL` value, `x`.
-- At time 3 + 2 microseconds, transaction `T2` creates a `SERIAL` value, `y`.
-- At time 4, transaction `T1` `COMMIT`s.
-- At time 5, transaction `T2` `COMMIT`s.
-
-If this happens, CockroachDB cannot guarantee whether `x < y` or `x > y`, despite the fact `T1` and `T2` began and were committed in different times. In this particular example, it's even likely that `x = y` because there is less than a 10-microsecond difference and the `SERIAL` values are constructed from the number of microseconds in the current time.
-
-Scenario 2:
-
-- At time 1, transaction `T1` `BEGIN`s.
-- At time 1, transaction `T2` `BEGIN`s somewhere else, on a different node.
-- At time 2, transaction `T1` creates a `SERIAL` value, `x`.
-- At time 3, transaction `T2` creates a `SERIAL` value, `y`.
-- At time 4, transaction `T1` `COMMIT`s.
-- At time 4, transaction `T2` `COMMIT`s.
-
-If this happens, CockroachDB cannot guarantee whether `x < y` or `x > y`. Both can happen, even though the transactions began and committed at the same time. However it's sure that `x != y` because the values were generated on different nodes.
-
-Scenario 3:
-
-- At time 1, transaction `T1` `BEGIN`s.
-- At time 2, transaction `T1` creates a `SERIAL` value, `x`.
-- At time 3, transaction `T1` `COMMIT`s.
-- At time 4, transaction `T2` `BEGIN`s somewhere else, on a different node.
-- At time 5, transaction `T2` creates a `SERIAL` value, `y`.
-- At time 6, transaction `T2` `COMMIT`s.
-
-There is less than a 250-microsecond difference between the system clocks of the two nodes.
-
-If this happens, CockroachDB cannot guarantee whether `x < y` or `x > y`. Even though the transactions "clearly" occurred one "after" the other, perhaps there was a clock skew between the two nodes and the system time of the second node is set earlier than the first node.
-
-## See also
-
-- [FAQ: How do I auto-generate unique row IDs in CockroachDB?](sql-faqs.html#how-do-i-auto-generate-unique-row-ids-in-cockroachdb)
-- [Data Types](data-types.html)
diff --git a/src/current/v20.2/set-cluster-setting.md b/src/current/v20.2/set-cluster-setting.md
deleted file mode 100644
index 47d4e370411..00000000000
--- a/src/current/v20.2/set-cluster-setting.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: SET CLUSTER SETTING
-summary: The SET CLUSTER SETTING statement configures one cluster setting.
-toc: true
----
-
-The `SET CLUSTER SETTING` [statement](sql-statements.html) modifies a [cluster-wide setting](cluster-settings.html).
-
-{{site.data.alerts.callout_danger}}Many cluster settings are intended for tuning CockroachDB internals. Before changing these settings, we strongly encourage you to discuss your goals with CockroachDB; otherwise, you use them at your own risk.{{site.data.alerts.end}}
-
-
-## Required privileges
-
-Only members of the `admin` role can modify cluster settings. By default, the `root` user belongs to the `admin` role.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/set_cluster_setting.html %}
-</div>
-
-{{site.data.alerts.callout_info}}The <code>SET CLUSTER SETTING</code> statement is unrelated to the other <a href="set-transaction.html"><code>SET TRANSACTION</code></a> and <a href="set-vars.html"><code>SET (session variable)</code></a> statements.{{site.data.alerts.end}}
-
-## Parameters
-
-| Parameter | Description |
-|-----------|-------------|
-| `var_name` | The name of the [cluster setting](cluster-settings.html) (case-insensitive). |
-| `var_value` | The value for the [cluster setting](cluster-settings.html). |
-| `DEFAULT` | Reset the [cluster setting](cluster-settings.html) to its default value.<br><br>The [`RESET CLUSTER SETTING`](reset-cluster-setting.html) resets a cluster setting as well. |
-
-## Examples
-
-### Change the default distributed execution parameter
-
-To configure a cluster so that new sessions automatically try to run queries [in a distributed fashion](https://www.cockroachlabs.com/blog/local-and-distributed-processing-in-cockroachdb/):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.defaults.distsql = 1;
-~~~
-
-To disable distributed execution for all new sessions:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.defaults.distsql = 0;
-~~~
-
-### Disable automatic diagnostic reporting
-
-To opt out of [automatic diagnostic reporting](diagnostics-reporting.html) of usage data to Cockroach Labs:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING diagnostics.reporting.enabled = false;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING diagnostics.reporting.enabled;
-~~~
-
-~~~
-+-------------------------------+
-| diagnostics.reporting.enabled |
-+-------------------------------+
-| false                         |
-+-------------------------------+
-(1 row)
-~~~
-
-### Reset a setting to its default value
-
-{{site.data.alerts.callout_success}}You can use <a href="reset-cluster-setting.html"><code>RESET CLUSTER SETTING</code></a> to reset a cluster setting as well.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.metrics.statement_details.enabled = false;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING sql.metrics.statement_details.enabled;
-~~~
-
-~~~
-+---------------------------------------+
-| sql.metrics.statement_details.enabled |
-+---------------------------------------+
-| false                                 |
-+---------------------------------------+
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING sql.metrics.statement_details.enabled = DEFAULT;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING sql.metrics.statement_details.enabled;
-~~~
-
-~~~
-+---------------------------------------+
-| sql.metrics.statement_details.enabled |
-+---------------------------------------+
-| true                                  |
-+---------------------------------------+
-(1 row)
-~~~
-
-## See also
-
-- [`SET` (session variable)](set-vars.html)
-- [`SHOW CLUSTER SETTING`](show-cluster-setting.html)
-- [Cluster settings](cluster-settings.html)
diff --git a/src/current/v20.2/set-schema.md b/src/current/v20.2/set-schema.md
deleted file mode 100644
index 6fb5498c0c2..00000000000
--- a/src/current/v20.2/set-schema.md
+++ /dev/null
@@ -1,253 +0,0 @@
----
-title: SET SCHEMA
-summary: The SET SCHEMA statement changes the schema of a table, sequence, or view.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: The `SET SCHEMA` [statement](sql-statements.html) changes the [schema](sql-name-resolution.html) of a [table](create-table.html), [sequence](create-sequence.html), or [view](create-view.html).
-
-{{site.data.alerts.callout_info}}
-`SET SCHEMA` is a subcommand of [`ALTER TABLE`](alter-table.html), [`ALTER SEQUENCE`](alter-sequence.html), and [`ALTER VIEW`](alter-view.html).
-
-CockroachDB also supports `SET SCHEMA` as an [alias for setting the `search_path` session variable](set-vars.html#supported-variables).
-{{site.data.alerts.end}}
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the table, sequence, or view, and the `CREATE` privilege on the schema.
-
-## Syntax
-
-### Tables
-
-~~~
-ALTER TABLE [IF EXISTS] <name> SET SCHEMA <newschemaname>
-~~~
-
-### Sequences
-
-~~~
-ALTER SEQUENCE [IF EXISTS] <name> SET SCHEMA <newschemaname>
-~~~
-
-### Views
-
-~~~
-ALTER [MATERIALIZED] VIEW [IF EXISTS] <name> SET SCHEMA <newschemaname>
-~~~
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `name` | The name of the table, sequence, or view to alter.
- `newschemaname` | The name of the table's new schema.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Change the schema of a table
-
-Suppose you want to add the `promo_codes` table to a new schema called `cockroach_labs`.
-
-By default, [unqualified tables](sql-name-resolution.html#lookup-with-unqualified-names) created in the database belong to the `public` schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-If the new schema does not already exist, [create it](create-schema.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA IF NOT EXISTS cockroach_labs;
-~~~
-
-Then, change the table's schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE promo_codes SET SCHEMA cockroach_labs;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-   schema_name   |         table_name         | type  | estimated_row_count
------------------+----------------------------+-------+----------------------
-  cockroach_labs | promo_codes                | table |                1000
-  public         | rides                      | table |                 500
-  public         | user_promo_codes           | table |                   0
-  public         | users                      | table |                  50
-  public         | vehicle_location_histories | table |                1000
-  public         | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-### Change the schema of a sequence
-
-Suppose you [create a sequence](create-sequence.html) that you would like to add to a new schema called `cockroach_labs`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE even_numbers INCREMENT 2 START 2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-  public          | even_numbers
-(1 row)
-~~~
-
-By default, [unqualified sequences](sql-name-resolution.html#lookup-with-unqualified-names) created in the database belong to the `public` schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE public.even_numbers;
-~~~
-
-~~~
-      table_name      |                                        create_statement
-----------------------+--------------------------------------------------------------------------------------------------
-  public.even_numbers | CREATE SEQUENCE public.even_numbers MINVALUE 1 MAXVALUE 9223372036854775807 INCREMENT 2 START 2
-(1 row)
-~~~
-
-If the new schema does not already exist, [create it](create-schema.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA IF NOT EXISTS cockroach_labs;
-~~~
-
-Then, change the sequence's schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER SEQUENCE even_numbers SET SCHEMA cockroach_labs;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE public.even_numbers;
-~~~
-
-~~~
-ERROR: relation "public.even_numbers" does not exist
-SQLSTATE: 42P01
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-  cockroach_labs  | even_numbers
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE cockroach_labs.even_numbers;
-~~~
-
-~~~
-          table_name          |                                            create_statement
-------------------------------+----------------------------------------------------------------------------------------------------------
-  cockroach_labs.even_numbers | CREATE SEQUENCE cockroach_labs.even_numbers MINVALUE 1 MAXVALUE 9223372036854775807 INCREMENT 2 START 2
-(1 row)
-~~~
-
-### Change the schema of a view
-
-Suppose you create a new view that you want to add to a schema called `cockroach_labs`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE VIEW expensive_rides (id, revenue) AS SELECT id, revenue FROM rides WHERE revenue > 50;
-~~~
-
-By default, [unqualified views](sql-name-resolution.html#lookup-with-unqualified-names) created in the database belong to the `public` schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE public.expensive_rides;
-~~~
-
-~~~
-        table_name       |                                                 create_statement
--------------------------+-------------------------------------------------------------------------------------------------------------------
-  public.expensive_rides | CREATE VIEW public.expensive_rides (id, revenue) AS SELECT id, revenue FROM movr.public.rides WHERE revenue > 50
-(1 row)
-~~~
-
-If the new schema does not already exist, [create it](create-schema.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA IF NOT EXISTS cockroach_labs;
-~~~
-
-Then, change the view's schema:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER VIEW expensive_rides SET SCHEMA cockroach_labs;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE public.expensive_rides;
-~~~
-
-~~~
-ERROR: relation "public.expensive_rides" does not exist
-SQLSTATE: 42P01
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE cockroach_labs.expensive_rides;
-~~~
-
-~~~
-            table_name           |                                                     create_statement
----------------------------------+---------------------------------------------------------------------------------------------------------------------------
-  cockroach_labs.expensive_rides | CREATE VIEW cockroach_labs.expensive_rides (id, revenue) AS SELECT id, revenue FROM movr.public.rides WHERE revenue > 50
-(1 row)
-~~~
-
-## See also
-
-- [`ALTER TABLE`](alter-table.html)
-- [`ALTER SEQUENCE`](alter-sequence.html)
-- [`ALTER VIEW`](alter-view.html)
-- [`CREATE SCHEMA`](drop-table.html)
-- [`SHOW SCHEMAS`](show-jobs.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/set-transaction.md b/src/current/v20.2/set-transaction.md
deleted file mode 100644
index d20c18665f0..00000000000
--- a/src/current/v20.2/set-transaction.md
+++ /dev/null
@@ -1,105 +0,0 @@
----
-title: SET TRANSACTION
-summary: The SET TRANSACTION statement sets the transaction priority for the current session or an individual transaction.
-toc: true
----
-
-The `SET TRANSACTION` [statement](sql-statements.html) sets the transaction priority, access mode, and "as of" timestamp after you [`BEGIN`](begin-transaction.html) it but before executing the first statement that manipulates a database.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/set_transaction.html %}
-</div>
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to set the transaction priority. However, privileges are required for each statement within a transaction.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`PRIORITY` | If you do not want the transaction to run with `NORMAL` priority, you can set it to `LOW` or `HIGH`. Transactions with higher priority are less likely to need to be retried. For more information, see [Transactions: Priorities](transactions.html#transaction-priorities).<br><br>The current priority is also exposed as the read-only [session variable](show-vars.html) `transaction_priority`.<br><br>**Default**: `NORMAL`
-`READ` | Set the transaction access mode to `READ ONLY` or `READ WRITE`. The current transaction access mode is also exposed as the [session variable](show-vars.html) `transaction_read_only`.<br><br>**Default**: `READ WRITE`
-`AS OF SYSTEM TIME` | Execute the transaction using the database contents "as of" a specified time in the past.<br/><br/> The `AS OF SYSTEM TIME` clause can be used only when the transaction is read-only. If the transaction contains any writes, or if the `READ WRITE` mode is specified, an error will be returned.<br/><br/>For more information, see [AS OF SYSTEM TIME](as-of-system-time.html).
-`NOT DEFERRABLE`<br>`DEFERRABLE` | <span class="version-tag">New in v20.2:</span> This clause is supported for compatibility with PostgreSQL. `NOT DEFERRABLE` is a no-op and the default behavior for CockroachDB. `DEFERRABLE` returns an `unimplemented` error.
-
-CockroachDB now only supports `SERIALIZABLE` isolation, so transactions can no longer be meaningfully set to any other `ISOLATION LEVEL`. In previous versions of CockroachDB, you could set transactions to `SNAPSHOT` isolation, but that feature has been removed.
-
-## Examples
-
-### Set priority
-
-{{site.data.alerts.callout_danger}}This example assumes you're using <a href="transactions.html#client-side-intervention">client-side intervention to handle transaction retries</a>.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET TRANSACTION PRIORITY HIGH;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SAVEPOINT cockroach_restart;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE products SET inventory = 0 WHERE sku = '8675309';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders (customer, sku, status) VALUES (1001, '8675309', 'new');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RELEASE SAVEPOINT cockroach_restart;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMIT;
-~~~
-
-### Use the `AS OF SYSTEM TIME` option
-
-You can execute the transaction using the database contents "as of" a specified time in the past.
-
-{% include {{ page.version.version }}/sql/set-transaction-as-of-system-time-example.md %}
-
-### Set the default transaction priority for a session
-
-<span class="version-tag">New in v20.2:</span> To set the default transaction priority for all transactions in a session, use the `default_transaction_priority` [session variable](set-vars.html). For example:
-
-~~~ sql
-> SET default_transaction_priority 'high';
-~~~
-
-~~~ sql
-> SHOW transaction_priority;
-~~~
-
-~~~
-  transaction_priority
-------------------------
-  high
-~~~
-
-Note that `transaction_priority` is a read-only [session variable](show-vars.html) that cannot be set directly.
-
-## See also
-
-- [`SET`](set-vars.html)
-- [Transactions: Priority levels](transactions.html#transaction-priorities)
-- [`BEGIN`](begin-transaction.html)
-- [`COMMIT`](commit-transaction.html)
-- [`SAVEPOINT`](savepoint.html)
-- [`RELEASE SAVEPOINT`](release-savepoint.html)
-- [`ROLLBACK`](rollback-transaction.html)
diff --git a/src/current/v20.2/set-vars.md b/src/current/v20.2/set-vars.md
deleted file mode 100644
index 652cbcec239..00000000000
--- a/src/current/v20.2/set-vars.md
+++ /dev/null
@@ -1,241 +0,0 @@
----
-title: SET (session variable)
-summary: The SET statement modifies the current configuration variables for the client session.
-toc: true
----
-
-The `SET` [statement](sql-statements.html) can modify one of the session configuration variables. These can also be queried via [`SHOW`](show-vars.html).
-
-{{site.data.alerts.callout_danger}}In some cases, client drivers can drop and restart the connection to the server. When this happens, any session configurations made with <code>SET</code> statements are lost. It is therefore more reliable to configure the session in the client's connection string. For examples in different languages, see the <a href="example-apps.html">Build an App with CockroachDB</a> tutorials.{{site.data.alerts.end}}
-
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to modify the session settings.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/set_var.html %}
-</div>
-
-{{site.data.alerts.callout_info}}The <code>SET</code> statement for session settings is unrelated to the other <a href="set-transaction.html"><code>SET TRANSACTION</code></a> and <a href="cluster-settings.html#change-a-cluster-setting"><code>SET CLUSTER SETTING</code></a> statements.{{site.data.alerts.end}}
-
-## Parameters
-
-The `SET <session variable>` statement accepts two parameters: the
-variable name and the value to use to modify the variable.
-
-The variable name is case insensitive. The value can be a list of one or more items. For example, the variable `search_path` is multi-valued.
-
-### Supported variables
-
-{% include {{ page.version.version }}/misc/session-vars.html %}
-
-Special syntax cases:
-
- Syntax | Equivalent to | Notes
---------|---------------|-------
- `USE ...` | `SET database = ...` | This is provided as convenience for users with a MySQL/MSSQL background.
- `SET NAMES ...` | `SET client_encoding = ...` | This is provided for compatibility with PostgreSQL clients.
- `SET SCHEMA <name>` | `SET search_path = <name>` | This is provided for better compatibility with PostgreSQL.
- `SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL ...` | `SET default_transaction_isolation = ...` | This is provided for compatibility with standard SQL.
- `SET TIME ZONE ...` | `SET timezone = ...` | This is provided for compatibility with PostgreSQL clients.
-
-## Examples
-
-### Set simple variables
-
-The following demonstrates how `SET` can be used to configure the
-default database for the current session:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET database = movr;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW database;
-~~~
-
-~~~
-  database
-+----------+
-  movr
-(1 row)
-~~~
-
-### Set variables to values containing spaces
-
-The following demonstrates how to use quoting to use values containing spaces:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET database = "database name with spaces";
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW database;
-~~~
-
-~~~
-  database
-+----------+
-  database name with spaces
-(1 row)
-~~~
-
-### Set variables to a list of values
-
-The following demonstrates how to assign a list of values:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET search_path = pg_catalog,public;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW search_path;
-~~~
-
-~~~
-     search_path
-+--------------------+
-  pg_catalog, public
-(1 row)
-~~~
-
-### Reset a variable to its default value
-
-{{site.data.alerts.callout_success}}You can use <a href="reset-vars.html"><code>RESET</code></a> to reset a session variable as well.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW search_path;
-~~~
-
-~~~
-  search_path
-+-------------+
-  public
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET search_path = 'app';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW search_path;
-~~~
-
-~~~
-  search_path
-+-------------+
-  app
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET search_path = DEFAULT;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW search_path;
-~~~
-
-~~~
-  search_path
-+-------------+
-  public
-(1 row)
-~~~
-
-## `SET TIME ZONE`
-
-{{site.data.alerts.callout_danger}}
-As a best practice, we recommend not using this setting and avoid setting a session time for your database. We instead recommend converting UTC values to the appropriate time zone on the client side.
-{{site.data.alerts.end}}
-
-You can control the default time zone for a session with `SET TIME ZONE`. This will apply an offset to all [`TIMESTAMPTZ`/`TIMESTAMP WITH TIME ZONE`](timestamp.html) and [`TIMETZ`/`TIME WITH TIME ZONE`](time.html) values in the session. By default, CockroachDB uses UTC as the time zone for `SET TIME ZONE` offsets.
-
-### Parameters
-
-The input passed to `SET TIME ZONE` indicates the time zone for the current session. This value can be a string representation of a local system-defined time zone (e.g., `'EST'`, `'America/New_York'`) or a positive or negative numeric offset from UTC (e.g., `-7`, `+7`, or `UTC-7`, `UTC+7`) or GMT (e.g., `GMT-7`, `GMT+7`). The numeric offset input can also be colon-delimited (e.g., `-7:00`, `GMT+7:00`).
-
-{{site.data.alerts.callout_info}}
-Only offsets specified by integers (e.g., `-7`, `7`) use the [ISO 8601 time offset](https://en.wikipedia.org/wiki/ISO_8601#Time_offsets_from_UTC) (i.e., the offset input is parsed as hours *east* of UTC). If you explicitly specify `UTC` or `GMT` for the time zone offset (e.g., `UTC-7`,`GMT+7`), or if the numeric input is colon-delimited (e.g.,  `-7:00`, `GMT+7:00`), CockroachDB uses the [POSIX time offset](https://www.postgresql.org/docs/current/datetime-posix-timezone-specs.html) (i.e., hours *west* of the specified time zone). This means that specifying an offset of `-7` (i.e., -7 *east* of UTC) is equivalent to specifying `GMT+7` (i.e., 7 *west* of UTC).
-{{site.data.alerts.end}}
-
-All timezone abbreviations are case-sensitive and must be uppercase, with the exception of `UTC`, for which `utc` is an alias.
-
-`DEFAULT`, `LOCAL`, or `0` sets the session time zone to `UTC`.
-
-### Example: Set the default time zone via `SET TIME ZONE`
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET TIME ZONE 'EST'; -- same as SET "timezone" = 'EST'
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TIME ZONE;
-~~~
-
-~~~
-  timezone
-+----------+
-  EST
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET TIME ZONE DEFAULT; -- same as SET "timezone" = DEFAULT
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TIME ZONE;
-~~~
-
-~~~
-  timezone
-+----------+
-  UTC
-(1 row)
-~~~
-
-## `SET TRACING`
-
-`SET TRACING` changes the trace recording state of the current session. A trace recording can be inspected with the [`SHOW TRACE FOR SESSION`](show-trace.html) statement.
-
- Value | Description
--------|------------
-`off` | Trace recording is disabled.
-`cluster` | Trace recording is enabled; distributed traces are collected.
-`on`  | Same as `cluster`.
-`kv`  | Same as `cluster` except that "kv messages" are collected instead of regular trace messages. See [`SHOW TRACE FOR SESSION`](show-trace.html).
-`local` | Trace recording is enabled; only trace messages issued by the local node are collected.
-`results` | Result rows and row counts are copied to the session trace. This must be specified to in order for the output of a query to be printed in the session trace.<br><br>Example: `SET tracing = kv, results;`
-
-## Known Limitations
-
-{% include {{page.version.version}}/known-limitations/set-transaction-no-rollback.md %}
-
-## See also
-
-- [`RESET`](reset-vars.html)
-- [`SET TRANSACTION`](set-transaction.html)
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`SHOW` (session variable)](show-vars.html)
-- [The `TIMESTAMP` and `TIMESTAMPTZ` data types.](timestamp.html)
-- [`SHOW TRACE FOR SESSION`](show-trace.html)
diff --git a/src/current/v20.2/show-backup.md b/src/current/v20.2/show-backup.md
deleted file mode 100644
index 16724ae087a..00000000000
--- a/src/current/v20.2/show-backup.md
+++ /dev/null
@@ -1,228 +0,0 @@
----
-title: SHOW BACKUP
-summary: The SHOW BACKUP statement lists the contents of a backup.
-toc: true
----
-
-The `SHOW BACKUP` [statement](sql-statements.html) lists the contents of a backup created with the [`BACKUP`](backup.html) statement.
-
-## Required privileges
-
-Only members of the `admin` role can run `SHOW BACKUP`. By default, the `root` user belongs to the `admin` role.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_backup.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`SHOW BACKUP location` | Show the details of the backup in the given [`location`](backup.html#backup-file-urls). [See the example below](#show-a-backup).
-`SHOW BACKUP SCHEMAS location` | Show the schema details of the backup in the given [`location`](backup.html#backup-file-urls). [See the example below](#show-a-backup-with-schemas).
-`SHOW BACKUPS IN location` | <span class="version-tag">New in v20.2:</span> List the full backup's subdirectories in the given [`location`](backup.html#backup-file-urls). [See the example below](#show-details-for-scheduled-backups).
-`SHOW BACKUP subdirectory IN location` | <span class="version-tag">New in v20.2:</span> List the full and incremental backups that are stored in the given full backup's `subdirectory` within a [`location`](backup.html#backup-file-urls). [See the example below](#show-details-for-scheduled-backups).
-`kv_option_list` | Control the behavior of `SHOW BACKUP` with a comma-separated list of [these options](#options).
-
-### Options
-
-Option       | Value | Description
--------------+-------+-----------------------------------------------------
-`privileges` | N/A   |  List which users and roles had which privileges on each table in the backup.
-`encryption_passphrase`<a name="with-encryption-passphrase"></a> | [`STRING`](string.html) |  The passphrase used to [encrypt the files](take-and-restore-encrypted-backups.html) (`BACKUP` manifest and data files) that the `BACKUP` statement generates.
-
-## Response
-
-The following fields are returned:
-
-Field | Description
-------|------------
-`database_name` | The database name.
-`parent_schema_name` | <span class="version-tag">New in v20.2:</span> The name of the parent schema.
-`object_name` | <span class="version-tag">New in v20.2:</span> The name of the [database](create-database.html), [table](create-table.html), [type](create-type.html), or schema. Note: This column was called `table_name` in previous versions of CockroachDB. **Note: This is a breaking change.**
-`object_type` | <span class="version-tag">New in v20.2:</span> The type of object: [database](create-database.html), [table](create-table.html), [type](create-type.html), or schema.
-`start_time` | The time of the earliest data encapsulated in the backup. Note that this only displays for incremental backups. For a full backup, this is `NULL`.
-`end_time` | The time to which data can be restored. This is equivalent to the [`AS OF SYSTEM TIME`](as-of-system-time.html) of the backup. If the backup was _not_ taken with [revision history](take-backups-with-revision-history-and-restore-from-a-point-in-time.html), the `end_time` is the _only_ time the data can be restored to. If the backup was taken with revision history, the `end_time` is the latest time the data can be restored to.
-`size_bytes` | The size of the backup, in bytes.
-`create_statement` | The `CREATE` statement used to create [table(s)](create-table.html), [view(s)](create-view.html), or [sequence(s)](create-sequence.html) that are stored within the backup. This displays when `SHOW BACKUP SCHEMAS` is used. Note that tables with references to [foreign keys](foreign-key.html) will only display foreign key constraints if the table to which the constraint relates to is also included in the backup.
-`is_full_cluster` |  Whether the backup is of a full cluster or not.
-`path` | <span class="version-tag">New in v20.2:</span> The list of the full backup's subdirectories. This field is returned for `SHOW BACKUPS IN LOCATION` only. The path format is `<year>/<month>/<day>-<timestamp>`.
-
-## Example
-
-### Show a backup
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW BACKUP 's3://test/backup-test?AWS_ACCESS_KEY_ID=[placeholder]&AWS_SECRET_ACCESS_KEY=[placeholder]';
-~~~
-
-~~~
-  database_name | parent_schema_name |        object_name         | object_type | start_time |             end_time             | size_bytes | rows | is_full_cluster
-----------------+--------------------+----------------------------+-------------+------------+----------------------------------+------------+------+------------------
-  NULL          | NULL               | system                     | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true
-  system        | public             | users                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        144 |    3 |      true
-  system        | public             | zones                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        201 |    7 |      true
-  system        | public             | settings                   | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        431 |    6 |      true
-  system        | public             | ui                         | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |          0 |    0 |      true
-  system        | public             | jobs                       | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |     434302 |   62 |      true
-  system        | public             | locations                  | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        261 |    5 |      true
-  system        | public             | role_members               | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        184 |    2 |      true
-  system        | public             | comments                   | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |          0 |    0 |      true
-  system        | public             | scheduled_jobs             | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        875 |    2 |      true
-  NULL          | NULL               | defaultdb                  | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true
-  NULL          | NULL               | postgres                   | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true
-  NULL          | NULL               | movr                       | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true
-  movr          | public             | users                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |       4911 |   50 |      true
-  movr          | public             | vehicles                   | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |       3182 |   15 |      true
-  movr          | public             | rides                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |     156387 |  500 |      true
-  movr          | public             | vehicle_location_histories | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |      73918 | 1000 |      true
-  movr          | public             | promo_codes                | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |     216083 | 1000 |      true
-  movr          | public             | user_promo_codes           | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |          0 |    0 |      true
-  defaultdb     | NULL               | org_one                    | schema      | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true
-(20 rows)
-~~~
-
-### Show a backup with schemas
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW BACKUP SCHEMAS 's3://test/backup-test?AWS_ACCESS_KEY_ID=[placeholder]&AWS_SECRET_ACCESS_KEY=[placeholder]';
-~~~
-
-~~~
-  database_name | parent_schema_name |        object_name         | object_type | start_time |             end_time             | size_bytes | rows | is_full_cluster |                                                        create_statement
-----------------+--------------------+----------------------------+-------------+------------+----------------------------------+------------+------+-----------------+----------------------------------------------------------------------------------------------------------------------------------
-  NULL          | NULL               | system                     | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true       | NULL
-  system        | public             | users                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        144 |    3 |      true       | CREATE TABLE users (
-                |                    |                            |             |            |                                  |            |      |                 |     username STRING NOT NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     "hashedPassword" BYTES NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     "isRole" BOOL NOT NULL DEFAULT false,
-                |                    |                            |             |            |                                  |            |      |                 |     CONSTRAINT "primary" PRIMARY KEY (username ASC),
-                |                    |                            |             |            |                                  |            |      |                 |     FAMILY "primary" (username),
-                |                    |                            |             |            |                                  |            |      |                 |     FAMILY "fam_2_hashedPassword" ("hashedPassword"),
-                |                    |                            |             |            |                                  |            |      |                 |     FAMILY "fam_3_isRole" ("isRole")
-                |                    |                            |             |            |                                  |            |      |                 | )
-...
-  system        | public             | jobs                       | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |     434302 |   62 |      true       | CREATE TABLE jobs (
-                |                    |                            |             |            |                                  |            |      |                 |     id INT8 NOT NULL DEFAULT unique_rowid(),
-                |                    |                            |             |            |                                  |            |      |                 |     status STRING NOT NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     created TIMESTAMP NOT NULL DEFAULT now():::TIMESTAMP,
-                |                    |                            |             |            |                                  |            |      |                 |     payload BYTES NOT NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     progress BYTES NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     created_by_type STRING NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     created_by_id INT8 NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     claim_session_id BYTES NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     claim_instance_id INT8 NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-                |                    |                            |             |            |                                  |            |      |                 |     INDEX jobs_status_created_idx (status ASC, created ASC),
-                |                    |                            |             |            |                                  |            |      |                 |     INDEX jobs_created_by_type_created_by_id_idx (created_by_type ASC, created_by_id ASC) STORING (status),
-                |                    |                            |             |            |                                  |            |      |                 |     FAMILY fam_0_id_status_created_payload (id, status, created, payload, created_by_type, created_by_id),
-                |                    |                            |             |            |                                  |            |      |                 |     FAMILY progress (progress),
-                |                    |                            |             |            |                                  |            |      |                 |     FAMILY claim (claim_session_id, claim_instance_id)
-                |                    |                            |             |            |                                  |            |      |                 | )
-  system        | public             | locations                  | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        261 |    5 |      true       | CREATE TABLE locations (
-                |                    |                            |             |            |                                  |            |      |                 |     "localityKey" STRING NOT NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     "localityValue" STRING NOT NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     latitude DECIMAL(18,15) NOT NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     longitude DECIMAL(18,15) NOT NULL,
-                |                    |                            |             |            |                                  |            |      |                 |     CONSTRAINT "primary" PRIMARY KEY ("localityKey" ASC, "localityValue" ASC),
-                |                    |                            |             |            |                                  |            |      |                 |     FAMILY "fam_0_localityKey_localityValue_latitude_longitude" ("localityKey", "localityValue", latitude, longitude)
-                |                    |                            |             |            |                                  |            |      |                 | )
-...
-~~~
-
-### Show a backup with privileges
-
-To view a list of which users and roles had which privileges on each database and table in the backup, use the `WITH privileges` [option](#options):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW BACKUP 's3://test/backup-test?AWS_ACCESS_KEY_ID=[placeholder]&AWS_SECRET_ACCESS_KEY=[placeholder]' WITH privileges;
-~~~
-
-~~~
-  database_name | parent_schema_name |        object_name         | object_type | start_time |             end_time             | size_bytes | rows | is_full_cluster |                                                                               privileges
-----------------+--------------------+----------------------------+-------------+------------+----------------------------------+------------+------+-----------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  NULL          | NULL               | system                     | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true       | GRANT GRANT, SELECT ON system TO admin; GRANT GRANT, SELECT ON system TO root;
-  system        | public             | users                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        144 |    3 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON users TO admin; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON users TO root;
-  system        | public             | zones                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        201 |    7 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON zones TO admin; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON zones TO root;
-  system        | public             | settings                   | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        431 |    6 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON settings TO admin; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON settings TO root;
-  system        | public             | ui                         | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |          0 |    0 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON ui TO admin; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON ui TO root;
-  system        | public             | jobs                       | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |     434302 |   62 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON jobs TO admin; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON jobs TO root;
-  system        | public             | locations                  | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        261 |    5 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON locations TO admin; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON locations TO root;
-  system        | public             | role_members               | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        184 |    2 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON role_members TO admin; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON role_members TO root;
-  system        | public             | comments                   | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |          0 |    0 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON comments TO admin; GRANT SELECT ON comments TO public; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON comments TO root;
-  system        | public             | scheduled_jobs             | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |        875 |    2 |      true       | GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON scheduled_jobs TO admin; GRANT DELETE, GRANT, INSERT, SELECT, UPDATE ON scheduled_jobs TO root;
-  NULL          | NULL               | defaultdb                  | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true       | GRANT ALL ON defaultdb TO admin; GRANT CREATE ON defaultdb TO max; GRANT ALL ON defaultdb TO root;
-  NULL          | NULL               | postgres                   | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true       | GRANT ALL ON postgres TO admin; GRANT ALL ON postgres TO root;
-  NULL          | NULL               | movr                       | database    | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true       | GRANT ALL ON movr TO admin; GRANT ALL ON movr TO root;
-  movr          | public             | users                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |       4911 |   50 |      true       | GRANT ALL ON users TO admin; GRANT ALL ON users TO root;
-  movr          | public             | vehicles                   | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |       3182 |   15 |      true       | GRANT ALL ON vehicles TO admin; GRANT ALL ON vehicles TO root;
-  movr          | public             | rides                      | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |     156387 |  500 |      true       | GRANT ALL ON rides TO admin; GRANT ALL ON rides TO root;
-  movr          | public             | vehicle_location_histories | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |      73918 | 1000 |      true       | GRANT ALL ON vehicle_location_histories TO admin; GRANT ALL ON vehicle_location_histories TO root;
-  movr          | public             | promo_codes                | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |     216083 | 1000 |      true       | GRANT ALL ON promo_codes TO admin; GRANT ALL ON promo_codes TO root;
-  movr          | public             | user_promo_codes           | table       | NULL       | 2020-09-24 19:05:40.542168+00:00 |          0 |    0 |      true       | GRANT ALL ON user_promo_codes TO admin; GRANT ALL ON user_promo_codes TO root;
-  defaultdb     | NULL               | org_one                    | schema      | NULL       | 2020-09-24 19:05:40.542168+00:00 |       NULL | NULL |      true       |
-(20 rows)
-~~~
-
-### Show details for scheduled backups
-
-<span class="version-tag">New in v20.2:</span> When a [backup is created by a schedule](create-schedule-for-backup.html), it is stored within a collection of backups in the given location. To view details for a backup created by a schedule, you can use the following:
-
-- `SHOW BACKUPS IN y` statement to [view a list of the full backup's subdirectories](#view-a-list-of-the-full-backups-subdirectories).
-- `SHOW BACKUP x IN y` statement to [view a list of the full and incremental backups that are stored in a specific full backup's subdirectory](#view-a-list-of-the-full-and-incremental-backups-in-a-specific-full-backup-subdirectory).
-
-{% include {{ page.version.version }}/backups/show-scheduled-backups.md %}
-
-### Show an encrypted backup
-
-Depending on how the backup was [encrypted](take-and-restore-encrypted-backups.html), use the [`encryption_passphrase` option](backup.html#with-encryption-passphrase) and the same passphrase that was used to create the backup:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW BACKUP 's3://test/backup-test?AWS_ACCESS_KEY_ID=[placeholder]&AWS_SECRET_ACCESS_KEY=[placeholder]'
-      WITH encryption_passphrase = 'password123';
-~~~
-
-Or, use the `kms` option and the same KMS URI that was used to create the backup:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW BACKUP 's3://test/backups/test_explicit_kms?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=123'
-      WITH kms = 'aws:///arn:aws:kms:us-east-1:123456789:key/1234-abcd-5678-efgh-90ij?AWS_ACCESS_KEY_ID=123456&AWS_SECRET_ACCESS_KEY=123456&REGION=us-east-1';
-~~~
-
-~~~
-  database_name | parent_schema_name |        object_name         | object_type | start_time |             end_time             | size_bytes | rows | is_full_cluster
-----------------+--------------------+----------------------------+-------------+------------+----------------------------------+------------+------+------------------
-  NULL          | NULL               | system                     | database    | NULL       | 2020-09-29 18:24:55.784364+00:00 |       NULL | NULL |      true
-  system        | public             | users                      | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |        144 |    3 |      true
-  system        | public             | zones                      | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |        201 |    7 |      true
-  system        | public             | settings                   | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |        431 |    6 |      true
-  system        | public             | ui                         | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |          0 |    0 |      true
-  system        | public             | jobs                       | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |     962415 |   97 |      true
-  system        | public             | locations                  | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |        261 |    5 |      true
-  system        | public             | role_members               | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |        184 |    2 |      true
-  system        | public             | comments                   | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |          0 |    0 |      true
-  system        | public             | scheduled_jobs             | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |       1991 |    4 |      true
-  NULL          | NULL               | defaultdb                  | database    | NULL       | 2020-09-29 18:24:55.784364+00:00 |       NULL | NULL |      true
-  NULL          | NULL               | postgres                   | database    | NULL       | 2020-09-29 18:24:55.784364+00:00 |       NULL | NULL |      true
-  NULL          | NULL               | movr                       | database    | NULL       | 2020-09-29 18:24:55.784364+00:00 |       NULL | NULL |      true
-  movr          | public             | users                      | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |       4911 |   50 |      true
-  movr          | public             | vehicles                   | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |       3182 |   15 |      true
-  movr          | public             | rides                      | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |     156387 |  500 |      true
-  movr          | public             | vehicle_location_histories | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |      73918 | 1000 |      true
-  movr          | public             | promo_codes                | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |     216083 | 1000 |      true
-  movr          | public             | user_promo_codes           | table       | NULL       | 2020-09-29 18:24:55.784364+00:00 |          0 |    0 |      true
-  defaultdb     | NULL               | org_one                    | schema      | NULL       | 2020-09-29 18:24:55.784364+00:00 |       NULL | NULL |      true
-(20 rows)
-~~~
-
-## See also
-
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
diff --git a/src/current/v20.2/show-cluster-setting.md b/src/current/v20.2/show-cluster-setting.md
deleted file mode 100644
index 99fea0499ba..00000000000
--- a/src/current/v20.2/show-cluster-setting.md
+++ /dev/null
@@ -1,135 +0,0 @@
----
-title: SHOW CLUSTER SETTING
-summary: The SHOW CLUSTER SETTING statement displays the current cluster settings.
-toc: true
----
-
-The `SHOW CLUSTER SETTING` [statement](sql-statements.html) displays the values of [cluster settings](cluster-settings.html).
-
-To configure cluster settings, use [`SET CLUSTER SETTING`](set-cluster-setting.html).
-
-{{site.data.alerts.callout_info}}
-The `SHOW` statement for cluster settings is unrelated to the other `SHOW` statements: <a href="show-vars.html"><code>SHOW (session variable)</code></a>, <a href="show-create.html"><code>SHOW CREATE</code></a>, <a href="show-users.html"><code>SHOW USERS</code></a>, <a href="show-databases.html"><code>SHOW DATABASES</code></a>, <a href="show-columns.html"><code>SHOW COLUMNS</code></a>, <a href="show-grants.html"><code>SHOW GRANTS</code></a>, and <a href="show-constraints.html"><code>SHOW CONSTRAINTS</code></a>.
-{{site.data.alerts.end}}
-
-## Details
-
-- To display the value of a specific cluster setting, use the following syntax:
-
-    ~~~ sql
-    SHOW CLUSTER SETTING <setting>;
-    ~~~
-
-- To display the values of *public* cluster settings (i.e., cluster settings that are documented and for which tuning is supported), use one of the following:
-
-    ~~~ sql
-    SHOW CLUSTER SETTINGS;
-    ~~~
-    ~~~ sql
-    SHOW PUBLIC CLUSTER SETTINGS;
-    ~~~
-
--  To display the values of all cluster settings use one of the following:
-
-    ~~~ sql
-    SHOW ALL CLUSTER SETTINGS;
-    ~~~
-    ~~~ sql
-    SHOW CLUSTER SETTING ALL;
-    ~~~
-
-    When you display all cluster settings, the table output includes a `public` column that denotes whether a setting is public or not.
-
-## Required privileges
-
-Only members of the `admin` role can display cluster settings. By default, the `root` user belongs to the `admin` role.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_cluster_setting.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`var_name` | The name of the [cluster setting](cluster-settings.html) (case-insensitive).
-`ALL` | Display all cluster settings.
-`PUBLIC` | Display only the public cluster settings.<br>By default, only public settings are listed by `SHOW CLUSTER SETTINGS`. `SHOW PUBLIC CLUSTER SETTINGS` and `SHOW CLUSTER SETTINGS` are equivalent.
-
-## Response
-
-When you query multiple cluster settings (e.g., with `SHOW CLUSTER SETTINGS`, or with `SHOW ALL CLUSTER SETTINGS`), the following fields are returned:
-
-Field | Description
-------|------------
-`variable` | The name of the cluster setting.
-`value` | The value of the cluster setting.
-`setting_type` | The type of the cluster setting.<br>Possible values for `setting_type` include:<ul><li>`b` (`true` or `false`)</li><li>`z` (size, in bytes)</li><li>`d` (duration)</li><li>`e` (one of a set of possible values)</li><li>`f` (floating-point value)</li><li>`i` (integer)</li><li>`s` (string)</li></ul>
-`description` | A brief description of the cluster setting, including possible values.
-`public` | `true` if the cluster setting is public.<br>This field is only included only if all cluster settings are displayed.
-
-## Examples
-
-### Show the value of a single cluster setting
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING diagnostics.reporting.enabled;
-~~~
-
-~~~
-  diagnostics.reporting.enabled
----------------------------------
-              true
-(1 row)
-~~~
-
-### Show the values of all public cluster settings
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTINGS;
-~~~
-
-~~~
-           variable           |     value      | setting_type |                                                   description
-------------------------------+----------------+--------------+-------------------------------------------------------------------------------------------------------------------
-  cloudstorage.gs.default.key |                | s            | if set, JSON key to use during Google Cloud Storage operations
-  cloudstorage.http.custom_ca |                | s            | custom root CA (appended to system's default CAs) for verifying certificates when interacting with HTTPS storage
-  cloudstorage.timeout        | 10m0s          | d            | the timeout for import/export storage operations
-  cluster.organization        | Cockroach Demo | s            | organization name
-  ...
-~~~
-
-### Show the values of all cluster settings
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ALL CLUSTER SETTINGS;
-~~~
-
-~~~
-                variable                | value | setting_type | public |                                                   description
-----------------------------------------+-------+--------------+--------+-------------------------------------------------------------------------------------------------------------------
-  changefeed.experimental_poll_interval | 1s    | d            | false  | polling interval for the table descriptors
-  cloudstorage.gs.default.key           |       | s            |  true  | if set, JSON key to use during Google Cloud Storage operations
-  cloudstorage.http.custom_ca           |       | s            |  true  | custom root CA (appended to system's default CAs) for verifying certificates when interacting with HTTPS storage
-  cloudstorage.timeout                  | 10m0s | d            |  true  | the timeout for import/export storage operations
-  ...
-~~~
-
-## See also
-
-- [`SET CLUSTER SETTING`](set-cluster-setting.html)
-- [`RESET CLUSTER SETTING`](reset-cluster-setting.html)
-- [Cluster settings](cluster-settings.html)
-- [`SHOW` (session variable)](show-vars.html)
-- [`SHOW COLUMNS`](show-columns.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`SHOW CREATE`](show-create.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [`SHOW INDEX`](show-index.html)
-- [`SHOW USERS`](show-users.html)
diff --git a/src/current/v20.2/show-columns.md b/src/current/v20.2/show-columns.md
deleted file mode 100644
index 386db9c633b..00000000000
--- a/src/current/v20.2/show-columns.md
+++ /dev/null
@@ -1,109 +0,0 @@
----
-title: SHOW COLUMNS
-summary: The SHOW COLUMNS statement shows details about columns in a table, including each column's name, type, default value, and whether or not it's nullable.
-toc: true
----
-
-The `SHOW COLUMNS` [statement](sql-statements.html) shows details about columns in a table, including each column's name, type, default value, and whether or not it's nullable.
-
-## Required privileges
-
-The user must have any [privilege](authorization.html#assign-privileges) on the target table.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_columns.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table for which to show columns.
-
-## Response
-
-The following fields are returned for each column.
-
-Field | Description
-------|------------
-`column_name` | The name of the column.
-`data_type` | The [data type](data-types.html) of the column.
-`is_nullable` | Whether or not the column accepts `NULL`. Possible values: `true` or `false`.
-`column_default` | The default value for the column, or an expression that evaluates to a default value.
-`generation_expression` | The expression used for a [computed column](computed-columns.html).
-`indices` | The list of [indexes](indexes.html) that the column is involved in, as an array.
-`is_hidden` | Whether or not the column is hidden. Possible values: `true` or `false`.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Show columns in a table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  city        | VARCHAR   |    false    | NULL           |                       | {primary} |   false
-  name        | VARCHAR   |    true     | NULL           |                       | {}        |   false
-  address     | VARCHAR   |    true     | NULL           |                       | {}        |   false
-  credit_card | VARCHAR   |    true     | NULL           |                       | {}        |   false
-(5 rows)
-~~~
-
-Alternatively, within the built-in SQL shell, you can use the `\d <table>` [shell command](cockroach-sql.html#commands):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \d users
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false
-  city        | VARCHAR   |    false    | NULL           |                       | {primary} |   false
-  name        | VARCHAR   |    true     | NULL           |                       | {}        |   false
-  address     | VARCHAR   |    true     | NULL           |                       | {}        |   false
-  credit_card | VARCHAR   |    true     | NULL           |                       | {}        |   false
-(5 rows)
-~~~
-
-### Show columns with comments
-
-You can use [`COMMENT ON`](comment-on.html) to add comments on a column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMENT ON COLUMN users.credit_card IS 'This column contains user payment information.';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM users WITH COMMENT;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden |                    comment
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+------------------------------------------------+
-  id          | UUID      |    false    | NULL           |                       | {primary} |   false   | NULL
-  city        | VARCHAR   |    false    | NULL           |                       | {primary} |   false   | NULL
-  name        | VARCHAR   |    true     | NULL           |                       | {}        |   false   | NULL
-  address     | VARCHAR   |    true     | NULL           |                       | {}        |   false   | NULL
-  credit_card | VARCHAR   |    true     | NULL           |                       | {}        |   false   | This column contains user payment information.
-(5 rows)
-~~~
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [Information Schema](information-schema.html)
-- [Other SQL Statements](sql-statements.html)
-- [`COMMENT ON`](comment-on.html)
diff --git a/src/current/v20.2/show-constraints.md b/src/current/v20.2/show-constraints.md
deleted file mode 100644
index a6174866124..00000000000
--- a/src/current/v20.2/show-constraints.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: SHOW CONSTRAINTS
-summary: The SHOW CONSTRAINTS statement lists the constraints on a table.
-toc: true
----
-
-The `SHOW CONSTRAINTS` [statement](sql-statements.html) lists all named [constraints](constraints.html) as well as any unnamed [`CHECK`](check.html) constraints on a table.
-
-## Required privileges
-
-The user must have any [privilege](authorization.html#assign-privileges) on the target table.
-
-## Aliases
-
-`SHOW CONSTRAINT` is an alias for `SHOW CONSTRAINTS`.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_constraints.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table for which to show constraints.
-
-## Response
-
-The following fields are returned for each constraint.
-
-Field | Description
-------|------------
-`table_name` | The name of the table.
-`constraint_name` | The name of the constraint.
-`constraint_type` | The type of constraint.
-`details` | The definition of the constraint, including the column(s) to which it applies.
-`validated` | Whether values in the column(s) match the constraint.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders (
-    id INT PRIMARY KEY,
-    date TIMESTAMP NOT NULL,
-    priority INT DEFAULT 1,
-    customer_id INT UNIQUE,
-    status STRING DEFAULT 'open',
-    CHECK (priority BETWEEN 1 AND 5),
-    CHECK (status in ('open', 'in progress', 'done', 'cancelled')),
-    FAMILY (id, date, priority, customer_id, status)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CONSTRAINTS FROM orders;
-~~~
-
-~~~
-+------------+------------------------+-----------------+--------------------------------------------------------------------------+-----------+
-| table_name |    constraint_name     | constraint_type |                                 details                                  | validated |
-+------------+------------------------+-----------------+--------------------------------------------------------------------------+-----------+
-| orders     | check_priority         | CHECK           | CHECK (priority BETWEEN 1 AND 5)                                         |   true    |
-| orders     | check_status           | CHECK           | CHECK (status IN ('open':::STRING, 'in progress':::STRING,               |   true    |
-|            |                        |                 | 'done':::STRING, 'cancelled':::STRING))                                  |           |
-| orders     | orders_customer_id_key | UNIQUE          | UNIQUE (customer_id ASC)                                                 |   true    |
-| orders     | primary                | PRIMARY KEY     | PRIMARY KEY (id ASC)                                                     |   true    |
-+------------+------------------------+-----------------+--------------------------------------------------------------------------+-----------+
-(4 rows)
-~~~
-
-## See also
-
-- [Constraints](constraints.html)
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`RENAME CONSTRAINT`](rename-constraint.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`VALIDATE CONSTRAINT`](validate-constraint.html)
-- [`CREATE TABLE`](create-table.html)
-- [Information Schema](information-schema.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-create.md b/src/current/v20.2/show-create.md
deleted file mode 100644
index 2c0acdf71d8..00000000000
--- a/src/current/v20.2/show-create.md
+++ /dev/null
@@ -1,243 +0,0 @@
----
-title: SHOW CREATE
-summary: The SHOW CREATE statement shows the CREATE statement for an existing table, view, or sequence.
-toc: true
----
-
-The `SHOW CREATE` [statement](sql-statements.html) shows the `CREATE` statement for an existing [table](create-table.html), [view](create-view.html), or [sequence](create-sequence.html).
-
-## Required privileges
-
-The user must have any [privilege](authorization.html#assign-privileges) on the target table, view, or sequence.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_create.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`object_name` | The name of the table, view, or sequence for which to show the `CREATE` statement.
-
-## Response
-
-Field | Description
-------|------------
-`table_name` | The name of the table, view, or sequence.
-`create_statement` | The `CREATE` statement for the table, view, or sequence.
-
-## Example
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Show the `CREATE TABLE` statement for a table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE drivers (
-    id UUID NOT NULL,
-    city STRING NOT NULL,
-    name STRING,
-    dl STRING UNIQUE,
-    address STRING,
-    CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE drivers;
-~~~
-
-~~~
-  table_name |                     create_statement
--------------+-----------------------------------------------------------
-  drivers    | CREATE TABLE public.drivers (
-             |     id UUID NOT NULL,
-             |     city STRING NOT NULL,
-             |     name STRING NULL,
-             |     dl STRING NULL,
-             |     address STRING NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     UNIQUE INDEX drivers_dl_key (dl ASC),
-             |     FAMILY "primary" (id, city, name, dl, address)
-             | )
-(1 row)
-~~~
-
-To return just the `create_statement` value:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT create_statement FROM [SHOW CREATE TABLE drivers];
-~~~
-
-~~~
-                      create_statement
-------------------------------------------------------------
-  CREATE TABLE public.drivers (
-      id UUID NOT NULL,
-      city STRING NOT NULL,
-      name STRING NULL,
-      dl STRING NULL,
-      address STRING NULL,
-      CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-      UNIQUE INDEX drivers_dl_key (dl ASC),
-      FAMILY "primary" (id, city, name, dl, address)
-  )
-(1 row)
-~~~
-
-{{site.data.alerts.callout_info}}
-`SHOW CREATE TABLE` also lists any partitions and zone configurations defined on primary and secondary indexes of a table. If partitions are defined, but no zones are configured, the `SHOW CREATE TABLE` output includes a warning.
-{{site.data.alerts.end}}
-
-### Show the `CREATE VIEW` statement for a view
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE VIEW user_view (city, name) AS SELECT city, name FROM users;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE user_view;
-~~~
-
-~~~
-  table_name |                                   create_statement
--------------+----------------------------------------------------------------------------------------
-  user_view  | CREATE VIEW public.user_view (city, name) AS SELECT city, name FROM movr.public.users
-(1 row)
-~~~
-
-To return just the `create_statement` value:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT create_statement FROM [SHOW CREATE VIEW user_view];
-~~~
-
-~~~
-                                    create_statement
------------------------------------------------------------------------------------------
-  CREATE VIEW public.user_view (city, name) AS SELECT city, name FROM movr.public.users
-(1 row)
-~~~
-
-### Show just a view's `SELECT` statement
-
-To get just a view's `SELECT` statement, you can query the `views` table in the built-in `information_schema` database and filter on the view name:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT view_definition
-  FROM information_schema.views
-  WHERE table_name = 'user_view';
-~~~
-
-~~~
-              view_definition
---------------------------------------------
-  SELECT city, name FROM movr.public.users
-(1 row)
-~~~
-
-### Show the `CREATE SEQUENCE` statement for a sequence
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE desc_customer_list START -1 INCREMENT -2;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE desc_customer_list;
-~~~
-
-~~~
-      table_name     |                                             create_statement
----------------------+------------------------------------------------------------------------------------------------------------
-  desc_customer_list | CREATE SEQUENCE public.desc_customer_list MINVALUE -9223372036854775808 MAXVALUE -1 INCREMENT -2 START -1
-(1 row)
-~~~
-
-To return just the `create_statement` value:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT create_statement FROM [SHOW CREATE desc_customer_list];
-~~~
-
-~~~
-                                              create_statement
--------------------------------------------------------------------------------------------------------------
-  CREATE SEQUENCE public.desc_customer_list MINVALUE -9223372036854775808 MAXVALUE -1 INCREMENT -2 START -1
-(1 row)
-~~~
-
-### Show the `CREATE TABLE` statement for a table with a comment
-
- If you [add a comment](comment-on.html) on a table, `SHOW CREATE TABLE` will display the comment.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMENT ON TABLE users IS 'This table contains information about users.';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                                create_statement
--------------+----------------------------------------------------------------------------------
-  users      | CREATE TABLE public.users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | );
-             | COMMENT ON TABLE public.users IS 'This table contains information about users.'
-(1 row)
-~~~
-
-To return just the `create_statement` value:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT create_statement FROM [SHOW CREATE TABLE users];
-~~~
-
-~~~
-                                 create_statement
------------------------------------------------------------------------------------
-  CREATE TABLE public.users (
-      id UUID NOT NULL,
-      city VARCHAR NOT NULL,
-      name VARCHAR NULL,
-      address VARCHAR NULL,
-      credit_card VARCHAR NULL,
-      CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-      FAMILY "primary" (id, city, name, address, credit_card)
-  );
-  COMMENT ON TABLE public.users IS 'This table contains information about users.'
-(1 row)
-~~~
-
-For more information, see [`COMMENT ON`](comment-on.html).
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [`CREATE VIEW`](create-view.html)
-- [`CREATE TABLE`](create-sequence.html)
-- [Information Schema](information-schema.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-databases.md b/src/current/v20.2/show-databases.md
deleted file mode 100644
index 8ddd7ed31b4..00000000000
--- a/src/current/v20.2/show-databases.md
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: SHOW DATABASES
-summary: The SHOW DATABASES statement lists all database in the CockroachDB cluster.
-keywords: reflection
-toc: true
----
-
-The `SHOW DATABASES` [statement](sql-statements.html) lists all databases in the CockroachDB cluster.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_databases.html %}
-</div>
-
-## Required privileges
-
-The user must be granted the `SELECT` [privilege](authorization.html#assign-privileges) to specific databases in order to list those databases in the CockroachDB cluster.
-
-## Example
-
-### Show databases
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW DATABASES;
-~~~
-
-~~~
-  database_name
-+---------------+
-  defaultdb
-  movr
-  postgres
-  startrek
-  system
-(5 rows)
-~~~
-
-Alternatively, within the built-in SQL shell, you can use the `\l` [shell command](cockroach-sql.html#commands) to list all databases:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \l
-~~~
-
-~~~
-  database_name
-+---------------+
-  defaultdb
-  movr
-  postgres
-  startrek
-  system
-(5 rows)
-~~~
-
-### Show databases with comments
-
-You can use [`COMMENT ON`](comment-on.html) to add comments on a database.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMENT ON DATABASE movr IS 'This database holds information about users, vehicles, and rides.';
-~~~
-
-To view a database's comments:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW DATABASES WITH COMMENT;
-~~~
-
-~~~
-  database_name |                              comment
-+---------------+-------------------------------------------------------------------+
-  defaultdb     | NULL
-  movr          | This database holds information about users, vehicles, and rides.
-  postgres      | NULL
-  startrek      | NULL
-  system        | NULL
-(5 rows)
-~~~
-
-For more information, see [`COMMENT ON`](comment-on.html).
-
-## Preloaded databases
-
-New clusters and existing clusters [upgraded](upgrade-cockroach-version.html) to v2.1 or later will include three auto-generated databases, with the following purposes:
-
-- The empty `defaultdb` database is used if a client does not specify a database in the [connection parameters](connection-parameters.html).
-
-- The `movr` database contains data about users, vehicles, and rides for the vehicle-sharing app [MovR](movr.html).
-
-- An empty database called `postgres` is provided for compatibility with Postgres client applications that require it.
-
-- The `startrek` database contains quotes from episodes.
-
-- The `system` database contains CockroachDB metadata and is read-only.
-
-The `postgres` and `defaultdb` databases can be [deleted](drop-database.html) if they are not needed.
-
-## See also
-
-- [`COMMENT ON`](comment-on.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [Information Schema](information-schema.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-enums.md b/src/current/v20.2/show-enums.md
deleted file mode 100644
index e39a42dc4a0..00000000000
--- a/src/current/v20.2/show-enums.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: SHOW ENUMS
-summary: The SHOW ENUMS statement lists the enumerated data types in a database.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `SHOW ENUMS` statement lists the [enumerated data types](enum.html) in the current database.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_enums.html %}
-</div>
-
-## Examples
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE weekday AS ENUM ('monday', 'tuesday', 'wednesday', 'thursday', 'friday');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE weekend AS ENUM ('sunday', 'saturday');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ENUMS;
-~~~
-
-~~~
-  schema |  name   |                  value
----------+---------+-------------------------------------------
-  public | weekday | monday|tuesday|wednesday|thursday|friday
-  public | weekend | sunday|saturday
-(2 rows)
-~~~
-
-
-## See also
-
-- [`ENUM`](enum.html)
-- [Data types](data-types.html)
-- [`CREATE TYPE`](create-type.html)
-- [`ALTER TYPE`](alter-type.html)
-- [`DROP TYPE`](drop-type.html)
diff --git a/src/current/v20.2/show-grants.md b/src/current/v20.2/show-grants.md
deleted file mode 100644
index 3720584e7c0..00000000000
--- a/src/current/v20.2/show-grants.md
+++ /dev/null
@@ -1,398 +0,0 @@
----
-title: SHOW GRANTS
-summary: The SHOW GRANTS statement lists the privileges granted to users.
-keywords: reflection
-toc: true
----
-
-The `SHOW GRANTS` [statement](sql-statements.html) lists one of the following:
-
-- The [roles](authorization.html#roles) granted to [users](authorization.html#users) in a cluster.
-- The [privileges](authorization.html#assign-privileges) [granted](grant.html) to [users](authorization.html#users) on [databases](create-database.html), [schemas](create-schema.html), [tables](create-table.html), or [user-defined types](enum.html).
-
-## Syntax
-
-### Show privilege grants
-
-Use the following syntax to show the privileges granted to users on database objects:
-
-~~~
-SHOW GRANTS [ON [DATABASE | SCHEMA | TABLE | TYPE] <targets...>] [FOR <users...>]
-~~~
-
-### Show role grants
-
-Use the following syntax to show the role grants for users in a cluster.
-
-~~~
-SHOW GRANTS ON ROLE [<roles...>] [FOR <users...>]
-~~~
-
-## Parameters
-
-Parameter    | Description
--------------|-----------------------------------------------------------------------------------------------------
-`targets`    | A comma-separated list of database, schema, table, or user-defined type names.<br><br>{{site.data.alerts.callout_info}}To list the privilege grants for all tables in the current database, you can use `SHOW GRANTS ON TABLE *`.{{site.data.alerts.end}}
-`users`      | A comma-separated list of the [users](authorization.html#users) whose privileges or roles you want to show.
-`roles`      | A comma-separated list of the roles whose grants you want to show.
-
-## Response
-
-### Privilege grants
-
-The `SHOW GRANTS ON [DATABASE | SCHEMA | TABLE | TYPE]` statement can return the following fields, depending on the target object specified:
-
-Field            | Description
------------------|-----------------------------------------------------------------------------------------------------
-`database_name`  | The name of the database.
-`schema_name`    | The name of the schema.
-`table_name`     | The name of the table.
-`type_name`      | The name of the user-defined type.
-`grantee`        | The name of the user or role that was granted the [privilege](authorization.html#assign-privileges).
-`privilege_type` | The name of the privilege.
-
-### Role grants
-
-The `SHOW GRANTS ON ROLE` statement returns the following fields:
-
-Field        |  Description
--------------|-----------------------------------------------------------------------------------------------------
-`role_name`  | The name of the role.
-`member`     | The users in the role.
-`is_admin`   | If `true`, the role is an [admin](authorization.html#role-admin) role.
-
-## Required privileges
-
-- No [privileges](authorization.html#assign-privileges) are required to view privileges granted to users.
-
-- For `SHOW GRANTS ON ROLES`, the user must have the [`SELECT`](select-clause.html) [privilege](authorization.html#assign-privileges) on the system table.
-
-## Examples
-
-### Show all grants
-
-To list all grants for all users and roles on the current database and its tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS;
-~~~
-
-~~~
-  database_name |    schema_name     |           relation_name           | grantee | privilege_type
-----------------+--------------------+-----------------------------------+---------+-----------------
-  movr          | crdb_internal      | NULL                              | admin   | ALL
-  movr          | crdb_internal      | NULL                              | root    | ALL
-  movr          | crdb_internal      | backward_dependencies             | public  | SELECT
-  movr          | crdb_internal      | builtin_functions                 | public  | SELECT
-...
-(365 rows)
-~~~
-
-### Show a specific user or role's grants
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE USER max WITH PASSWORD roach;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON DATABASE movr TO max;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS FOR max;
-~~~
-
-~~~
-  database_name |    schema_name     | relation_name | grantee | privilege_type
-----------------+--------------------+---------------+---------+-----------------
-  movr          | crdb_internal      | NULL          | max     | ALL
-  movr          | information_schema | NULL          | max     | ALL
-  movr          | pg_catalog         | NULL          | max     | ALL
-  movr          | pg_extension       | NULL          | max     | ALL
-  movr          | public             | NULL          | max     | ALL
-(5 rows)
-~~~
-
-### Show grants on databases
-
-**Specific database, all users and roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON DATABASE movr;
-~~~
-
-~~~
-  database_name |    schema_name     | grantee | privilege_type
-----------------+--------------------+---------+-----------------
-  movr          | crdb_internal      | admin   | ALL
-  movr          | crdb_internal      | max     | ALL
-  movr          | crdb_internal      | root    | ALL
-  movr          | information_schema | admin   | ALL
-  movr          | information_schema | max     | ALL
-  movr          | information_schema | root    | ALL
-  movr          | pg_catalog         | admin   | ALL
-  movr          | pg_catalog         | max     | ALL
-  movr          | pg_catalog         | root    | ALL
-  movr          | pg_extension       | admin   | ALL
-  movr          | pg_extension       | max     | ALL
-  movr          | pg_extension       | root    | ALL
-  movr          | public             | admin   | ALL
-  movr          | public             | max     | ALL
-  movr          | public             | root    | ALL
-(15 rows)
-~~~
-
-**Specific database, specific user or role:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON DATABASE movr FOR max;
-~~~
-
-~~~
-  database_name |    schema_name     | grantee | privilege_type
-----------------+--------------------+---------+-----------------
-  movr          | crdb_internal      | max     | ALL
-  movr          | information_schema | max     | ALL
-  movr          | pg_catalog         | max     | ALL
-  movr          | pg_extension       | max     | ALL
-  movr          | public             | max     | ALL
-(5 rows)
-~~~
-
-### Show grants on tables
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON TABLE users TO max;
-~~~
-
-**Specific table, all users and roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE users;
-~~~
-
-~~~
-  database_name | schema_name | table_name | grantee | privilege_type
-----------------+-------------+------------+---------+-----------------
-  movr          | public      | users      | admin   | ALL
-  movr          | public      | users      | max     | ALL
-  movr          | public      | users      | root    | ALL
-(3 rows)
-~~~
-
-**Specific table, specific role or user:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE users FOR max;
-~~~
-
-~~~
-  database_name | schema_name | table_name | grantee | privilege_type
-----------------+-------------+------------+---------+-----------------
-  movr          | public      | users      | max     | ALL
-(1 row)
-~~~
-
-**All tables, all users and roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE *;
-~~~
-
-~~~
-  database_name | schema_name |         table_name         | grantee | privilege_type
-----------------+-------------+----------------------------+---------+-----------------
-  movr          | public      | promo_codes                | admin   | ALL
-  movr          | public      | promo_codes                | root    | ALL
-  movr          | public      | rides                      | admin   | ALL
-  movr          | public      | rides                      | root    | ALL
-  movr          | public      | user_promo_codes           | admin   | ALL
-  movr          | public      | user_promo_codes           | root    | ALL
-  movr          | public      | users                      | admin   | ALL
-  movr          | public      | users                      | max     | ALL
-  movr          | public      | users                      | root    | ALL
-  movr          | public      | vehicle_location_histories | admin   | ALL
-  movr          | public      | vehicle_location_histories | root    | ALL
-  movr          | public      | vehicles                   | admin   | ALL
-  movr          | public      | vehicles                   | root    | ALL
-(13 rows)
-~~~
-
-**All tables, specific users or roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TABLE * FOR max;
-~~~
-
-~~~
-  database_name | schema_name | table_name | grantee | privilege_type
-----------------+-------------+------------+---------+-----------------
-  movr          | public      | users      | max     | ALL
-(1 row)
-~~~
-
-### Show grants on schemas
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA cockroach_labs;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON SCHEMA cockroach_labs TO max;
-~~~
-
-**Specific schema, all users or roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON SCHEMA cockroach_labs;
-~~~
-
-~~~
-  database_name |  schema_name   | grantee | privilege_type
-----------------+----------------+---------+-----------------
-  movr          | cockroach_labs | admin   | ALL
-  movr          | cockroach_labs | max     | ALL
-  movr          | cockroach_labs | root    | ALL
-(3 rows)
-~~~
-
-**Specific schema, specific users or roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON SCHEMA cockroach_labs FOR max;
-~~~
-
-~~~
-  database_name |  schema_name   | grantee | privilege_type
-----------------+----------------+---------+-----------------
-  movr          | cockroach_labs | max     | ALL
-(1 row)
-~~~
-
-### Show grants on user-defined types
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE status AS ENUM ('available', 'unavailable');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT ALL ON TYPE status TO max;
-~~~
-
-**Specific type, all users or roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TYPE status;
-~~~
-
-~~~
-  database_name | schema_name | type_name | grantee | privilege_type
-----------------+-------------+-----------+---------+-----------------
-  movr          | public      | status    | admin   | ALL
-  movr          | public      | status    | max     | ALL
-  movr          | public      | status    | public  | USAGE
-  movr          | public      | status    | root    | ALL
-(4 rows)
-~~~
-
-**Specific type, specific users or roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON TYPE status FOR max;
-~~~
-
-~~~
-  database_name | schema_name | type_name | grantee | privilege_type
-----------------+-------------+-----------+---------+-----------------
-  movr          | public      | status    | max     | ALL
-(1 row)
-~~~
-
-### Show role memberships
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE ROLE moderator;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT moderator TO max;
-~~~
-
-**All members of all roles:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON ROLE;
-~~~
-
-~~~
-  role_name | member | is_admin
-------------+--------+-----------
-  admin     | root   |   true
-  moderator | max    |  false
-(2 rows)
-~~~
-
-**Members of a specific role:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON ROLE moderator;
-~~~
-
-~~~
-  role_name | member | is_admin
-------------+--------+-----------
-  moderator | max    |  false
-(1 row)
-~~~
-
-**Roles of a specific user or role:**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON ROLE FOR max;
-~~~
-
-~~~
-  role_name | member | is_admin
-------------+--------+-----------
-  moderator | max    |  false
-(1 row)
-~~~
-
-## See also
-
-- [Authorization](authorization.html)
-- [`CREATE ROLE`](create-role.html)
-- [`DROP ROLE`](drop-role.html)
-- [`SHOW ROLES`](show-roles.html)
-- [`GRANT <privileges>`](grant.html)
-- [`GRANT <roles>`](grant-roles.html)
-- [`REVOKE <privileges>`](revoke.html)
-- [`REVOKE <roles>`](revoke-roles.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [Manage Users](authorization.html#create-and-manage-users)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [Information Schema](information-schema.html)
diff --git a/src/current/v20.2/show-index.md b/src/current/v20.2/show-index.md
deleted file mode 100644
index e90a36274e2..00000000000
--- a/src/current/v20.2/show-index.md
+++ /dev/null
@@ -1,119 +0,0 @@
----
-title: SHOW INDEX
-summary: The SHOW INDEX statement returns index information for a table or database.
-toc: true
----
-
-The `SHOW INDEX` [statement](sql-statements.html) returns index information for a table or database.
-
-
-## Required privileges
-
-The user must have any [privilege](authorization.html#assign-privileges) on the target table or database.
-
-## Aliases
-
-In CockroachDB, the following are aliases for `SHOW INDEX`:
-
-- `SHOW INDEXES`
-- `SHOW KEYS`
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_indexes.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table for which you want to show indexes.
-`database_name` | The name of the database for which you want to show indexes.
-
-## Response
-
-The following fields are returned for each column in each index.
-
-Field | Description
-----------|------------
-`table_name` | The name of the table.
-`index_name` | The name of the index.
-`non_unique` | Whether or not values in the indexed column are unique. Possible values: `true` or `false`.
-`seq_in_index` | The position of the column in the index, starting with 1.
-`column_name` | The indexed column.
-`direction` | How the column is sorted in the index. Possible values: `ASC` or `DESC` for indexed columns; `N/A` for stored columns.
-`storing` | Whether or not the `STORING` clause was used to index the column during [index creation](create-index.html). Possible values: `true` or `false`.
-`implicit` | Whether or not the column is part of the index despite not being explicitly included during [index creation](create-index.html). Possible values: `true` or `false`<br><br>At this time, [primary key](primary-key.html) columns are the only columns that get implicitly included in secondary indexes. The inclusion of primary key columns improves performance when retrieving columns not in the index.
-
-## Example
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Show indexes for a table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (name);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM users;
-~~~
-
-~~~
-  table_name |   index_name   | non_unique | seq_in_index | column_name | direction | storing | implicit
-+------------+----------------+------------+--------------+-------------+-----------+---------+----------+
-  users      | primary        |   false    |            1 | city        | ASC       |  false  |  false
-  users      | primary        |   false    |            2 | id          | ASC       |  false  |  false
-  users      | users_name_idx |    true    |            1 | name        | ASC       |  false  |  false
-  users      | users_name_idx |    true    |            2 | city        | ASC       |  false  |   true
-  users      | users_name_idx |    true    |            3 | id          | ASC       |  false  |   true
-(5 rows)
-~~~
-
-### Show indexes for a database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEXES FROM DATABASE movr;
-~~~
-
-~~~
-          table_name         |                  index_name                   | non_unique | seq_in_index | column_name  | direction | storing | implicit
-+----------------------------+-----------------------------------------------+------------+--------------+--------------+-----------+---------+----------+
-  users                      | primary                                       |   false    |            1 | city         | ASC       |  false  |  false
-  users                      | primary                                       |   false    |            2 | id           | ASC       |  false  |  false
-  vehicles                   | primary                                       |   false    |            1 | city         | ASC       |  false  |  false
-  vehicles                   | primary                                       |   false    |            2 | id           | ASC       |  false  |  false
-  vehicles                   | vehicles_auto_index_fk_city_ref_users         |    true    |            1 | city         | ASC       |  false  |  false
-  vehicles                   | vehicles_auto_index_fk_city_ref_users         |    true    |            2 | owner_id     | ASC       |  false  |  false
-  vehicles                   | vehicles_auto_index_fk_city_ref_users         |    true    |            3 | id           | ASC       |  false  |   true
-  rides                      | primary                                       |   false    |            1 | city         | ASC       |  false  |  false
-  rides                      | primary                                       |   false    |            2 | id           | ASC       |  false  |  false
-  rides                      | rides_auto_index_fk_city_ref_users            |    true    |            1 | city         | ASC       |  false  |  false
-  rides                      | rides_auto_index_fk_city_ref_users            |    true    |            2 | rider_id     | ASC       |  false  |  false
-  rides                      | rides_auto_index_fk_city_ref_users            |    true    |            3 | id           | ASC       |  false  |   true
-  rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles |    true    |            1 | vehicle_city | ASC       |  false  |  false
-  rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles |    true    |            2 | vehicle_id   | ASC       |  false  |  false
-  rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles |    true    |            3 | city         | ASC       |  false  |   true
-  rides                      | rides_auto_index_fk_vehicle_city_ref_vehicles |    true    |            4 | id           | ASC       |  false  |   true
-  vehicle_location_histories | primary                                       |   false    |            1 | city         | ASC       |  false  |  false
-  vehicle_location_histories | primary                                       |   false    |            2 | ride_id      | ASC       |  false  |  false
-  vehicle_location_histories | primary                                       |   false    |            3 | timestamp    | ASC       |  false  |  false
-  promo_codes                | primary                                       |   false    |            1 | code         | ASC       |  false  |  false
-  user_promo_codes           | primary                                       |   false    |            1 | city         | ASC       |  false  |  false
-  user_promo_codes           | primary                                       |   false    |            2 | user_id      | ASC       |  false  |  false
-  user_promo_codes           | primary                                       |   false    |            3 | code         | ASC       |  false  |  false
-(23 rows)
-~~~
-
-## See also
-
-- [`CREATE INDEX`](create-index.html)
-- [`COMMENT ON`](comment-on.html)
-- [`DROP INDEX`](drop-index.html)
-- [`RENAME INDEX`](rename-index.html)
-- [Information Schema](information-schema.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-jobs.md b/src/current/v20.2/show-jobs.md
deleted file mode 100644
index 4b4e23939d7..00000000000
--- a/src/current/v20.2/show-jobs.md
+++ /dev/null
@@ -1,201 +0,0 @@
----
-title: SHOW JOBS
-summary: The SHOW JOBS statement lists all currently active schema changes and backup/restore jobs.
-toc: true
----
-
-The `SHOW JOBS` [statement](sql-statements.html) lists all of the types of long-running tasks your cluster has performed in the last 12 hours, including:
-
-{% include {{ page.version.version }}/sql/schema-changes.md %}
-- [`IMPORT`](import.html)
-- Enterprise [`BACKUP`](backup.html) and [`RESTORE`](restore.html)
-- [User-created table statistics](create-statistics.html) created for use by the [cost-based optimizer](cost-based-optimizer.html)
-- <span class="version-tag">New in v20.2:</span> [Scheduled backups](manage-a-backup-schedule.html)
-
-These details can help you understand the status of crucial tasks that can impact the performance of your cluster, as well as help you control them.
-
-To view the [automatic table statistics](cost-based-optimizer.html#table-statistics), use [`SHOW AUTOMATIC JOBS`](#show-automatic-jobs).
-
-To block a call to `SHOW JOBS` that returns after all specified job ID(s) have a terminal state, use [`SHOW JOBS WHEN COMPLETE`](#show-job-when-complete). The statement will return a row per job ID, which provides details of the job execution. Note that while this statement is blocking, it will time out after 24 hours.
-
-## Considerations
-
-- The `SHOW JOBS` statement shows only long-running tasks.
-- For jobs older than 12 hours, query the `crdb_internal.jobs` table.
-- Jobs are deleted after 14 days. This interval can be changed via the `jobs.retention_time` [cluster setting](cluster-settings.html).
-- While the `SHOW JOBS WHEN COMPLETE` statement is blocking, it will time out after 24 hours.
-- Garbage collection jobs are created for [dropped tables](drop-table.html) and [dropped indexes](drop-index.html), and will execute after the [GC TTL](configure-replication-zones.html#replication-zone-variables) has elapsed (default is 25 hours). These jobs cannot be canceled.
-
-## Required privileges
-
-By default, only the `root` user can execute `SHOW JOBS`.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_jobs.html %}
-</div>
-
-## Parameters
-
- Parameter | Description
------------|-------------
-`SHOW AUTOMATIC JOBS` | Show [automatic table statistics](cost-based-optimizer.html#table-statistics). For an example, see [Show automatic jobs](#show-automatic-jobs).
-`SHOW JOBS WHEN COMPLETE` | Block `SHOW JOB` until the provided job ID reaches a terminal state. For an example, see [Show job when complete](#show-job-when-complete).
-`select_stmt` | A [selection query](selection-queries.html) that specifies the `job_id`(s) to view.
-`job_id` | The ID of the job you want to view.
-`for_schedules_clause` | <span class="version-tag">New in v20.2:</span> The schedule you want to view jobs for. You can view jobs for a specific schedule (`FOR SCHEDULE id`) or view jobs for multiple schedules by nesting a [`SELECT` clause](select-clause.html) in the statement (`FOR SCHEDULES <select_clause>`). See the [examples](#show-jobs-for-a-schedule) below.
-
-## Response
-
-The output of `SHOW JOBS` lists ongoing jobs first, then completed jobs within the last 12 hours. The list of ongoing jobs is sorted by starting time, whereas the list of completed jobs is sorted by finished time.
-
-The following fields are returned for each job:
-
-Field | Description
-------|------------
-`job_id` | A unique ID to identify each job. This value is used if you want to control jobs (i.e., [pause](pause-job.html), [resume](resume-job.html), or [cancel](cancel-job.html) it).
-`job_type` | The type of job. Possible values: `SCHEMA CHANGE`, [`BACKUP`](backup.html), [`RESTORE`](restore.html), [`IMPORT`](import.html), and [`CREATE STATS`](create-statistics.html). <br><br> For `SHOW AUTOMATIC JOBS`, the possible value is [`AUTO CREATE STATS`](cost-based-optimizer.html#table-statistics).
-`description` | The statement that started the job, or a textual description of the job.
-`statement` | When `description` is a textual description of the job, the statement that started the job is returned in this column. Currently, this field is populated only for the automatic table statistics jobs.
-`user_name` | The name of the [user](authorization.html#create-and-manage-users) who started the job.
-`status` | The job's current state. Possible values: `pending`, `running`, `paused`, `failed`, `succeeded`, or `canceled`.
-`running_status` | The job's detailed running status, which provides visibility into the progress of the dropping or truncating of tables (i.e., [`DROP TABLE`](drop-table.html), [`DROP DATABASE`](drop-database.html), or [`TRUNCATE`](truncate.html)). For dropping or truncating jobs, the detailed running status is determined by the status of the table at the earliest stage of the schema change. The job is completed when the GC TTL expires and both the table data and ID is deleted for each of the tables involved. Possible values: `draining names`, `waiting for GC TTL`, `RocksDB compaction`, or `NULL` (when the status cannot be determined). <br><br>For the `SHOW AUTOMATIC JOBS` statement, the value of this field is `NULL`.
-`created` | The `TIMESTAMP` when the job was created.
-`started` | The `TIMESTAMP` when the job began running first.
-`finished` | The `TIMESTAMP` when the job was `succeeded`, `failed`, or `canceled`.
-`modified` | The `TIMESTAMP` when the job had anything modified.
-`fraction_completed` | The fraction (between `0.00` and `1.00`) of the job that's been completed.
-`error` | If the job `failed`, the error generated by the failure.
-`coordinator_id` | The ID of the node running the job.
-
-## Examples
-
-### Show jobs
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW JOBS;
-~~~
-
-~~~
-     job_id     | job_type  |               description                 |...
-+---------------+-----------+-------------------------------------------+...
- 27536791415282 |  RESTORE  | RESTORE db.* FROM 'azure://backup/db/tbl' |...
-~~~
-
-### Filter jobs
-
-You can filter jobs by using `SHOW JOBS` as the data source for a [`SELECT`](select-clause.html) statement, and then filtering the values with the `WHERE` clause.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW JOBS] WHERE job_type = 'RESTORE' AND status IN ('running', 'failed') ORDER BY created DESC;
-~~~
-
-~~~
-     job_id     | job_type  |              description                  |...
-+---------------+-----------+-------------------------------------------+...
- 27536791415282 |  RESTORE  | RESTORE db.* FROM 'azure://backup/db/tbl' |...
-
-~~~
-
-### Show automatic jobs
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW AUTOMATIC JOBS;
-~~~
-
-~~~
-        job_id       |       job_type      |                    description                      |...
-+--------------------+---------------------+-----------------------------------------------------+...
-  438235476849557505 | AUTO CREATE STATS   | Table statistics refresh for defaultdb.public.users |...
-(1 row)
-~~~
-
-### Filter automatic jobs
-
-You can filter jobs by using `SHOW AUTOMATIC JOBS` as the data source for a [`SELECT`](select-clause.html) statement, and then filtering the values with the `WHERE` clause.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW AUTOMATIC JOBS] WHERE status = ('succeeded') ORDER BY created DESC;
-~~~
-
-~~~
-        job_id       |       job_type      |                    description                      | ...
-+--------------------+---------------------+-----------------------------------------------------+ ...
-  438235476849557505 | AUTO CREATE STATS   | Table statistics refresh for defaultdb.public.users | ...
-(1 row)
-~~~
-
-### Show schema changes
-
-You can show just schema change jobs by using `SHOW JOBS` as the data source for a [`SELECT`](select-clause.html) statement, and then filtering the `job_type` value with the `WHERE` clause:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW JOBS] WHERE job_type = 'SCHEMA CHANGE';
-~~~
-
-~~~
-     job_id     | job_type        |              description                           |...
-+---------------+-----------------+----------------------------------------------------+...
- 27536791415282 |  SCHEMA CHANGE  | ALTER TABLE test.public.foo ADD COLUMN bar VARCHAR |...
-~~~
-
- [Scheme change](online-schema-changes.html) jobs can be [paused](pause-job.html), [resumed](resume-job.html), and [canceled](cancel-job.html).
-
-### Show job when complete
-
-To block `SHOW JOB` until the provided job ID reaches a terminal state, use `SHOW JOB WHEN COMPLETE`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW JOB WHEN COMPLETE 27536791415282;
-~~~
-~~~
-     job_id     | job_type  |               description                 |...
-+---------------+-----------+-------------------------------------------+...
- 27536791415282 |  RESTORE  | RESTORE db.* FROM 'azure://backup/db/tbl' |...
-~~~
-
-### Show jobs for a schedule
-
-<span class="version-tag">New in v20.2:</span> To view jobs for a specific [backup schedule](create-schedule-for-backup.html), use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW JOBS FOR SCHEDULE 590204387299262465;
-~~~
-~~~
-        job_id       | job_type |                                                                                                             description                                                                                   | statement | user_name | status  | running_status |             created              | started | finished |             modified             | fraction_completed | error | coordinator_id
----------------------+----------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+-----------+---------+----------------+----------------------------------+---------+----------+----------------------------------+--------------------+-------+-----------------
-  590205481558802434 | BACKUP   | BACKUP INTO '/2020/09/15-161444.99' IN 's3://test/scheduled-backup-0915?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' AS OF SYSTEM TIME '2020-09-15 16:20:00+00:00' WITH revision_history, detached |           | root      | running | NULL           | 2020-09-15 16:20:18.347383+00:00 | NULL    | NULL     | 2020-09-15 16:20:18.347383+00:00 |                  0 |       |              0
-(1 row)
-~~~
-
-You can also view multiple schedules by nesting a [`SELECT` clause](select-clause.html) that retrieves `id`(s) inside the `SHOW JOBS` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW JOBS FOR SCHEDULES SELECT id FROM [SHOW SCHEDULES] WHERE label = 'test_schedule';
-~~~
-
-~~~
-        job_id       | job_type |                                                                                                                 description                                                                                      | statement | user_name |  status   | running_status |             created              | started |             finished             |             modified             | fraction_completed | error | coordinator_id
----------------------+----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------+-----------+-----------+----------------+----------------------------------+---------+----------------------------------+----------------------------------+--------------------+-------+-----------------
-  590204496007299074 | BACKUP   | BACKUP INTO '/2020/09/15-161444.99' IN 's3://test/scheduled-backup-0915?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' AS OF SYSTEM TIME '2020-09-15 16:14:44.991631+00:00' WITH revision_history, detached |           | root      | succeeded | NULL           | 2020-09-15 16:15:17.720725+00:00 | NULL    | 2020-09-15 16:15:20.913789+00:00 | 2020-09-15 16:15:20.910594+00:00 |                  1 |       |              0
-  590205481558802434 | BACKUP   | BACKUP INTO '/2020/09/15-161444.99' IN 's3://test/scheduled-backup-0915?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' AS OF SYSTEM TIME '2020-09-15 16:20:00+00:00' WITH revision_history, detached        |           | root      | succeeded | NULL           | 2020-09-15 16:20:18.347383+00:00 | NULL    | 2020-09-15 16:20:48.37873+00:00  | 2020-09-15 16:20:48.374256+00:00 |                  1 |       |              0
-(2 rows)
-~~~
-
-## See also
-
-- [`PAUSE JOB`](pause-job.html)
-- [`RESUME JOB`](pause-job.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
diff --git a/src/current/v20.2/show-locality.md b/src/current/v20.2/show-locality.md
deleted file mode 100644
index b7a3de58026..00000000000
--- a/src/current/v20.2/show-locality.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: SHOW LOCALITY
-summary: The SHOW LOCALITY statement returns the locality of the current node.
-toc: true
----
-
-The `SHOW LOCALITY` [statement](sql-statements.html) returns the [locality](cockroach-start.html#locality) of the current node.
-
-If locality was not specified on node startup, the statement returns an empty row.
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to list the locality of the current node.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_locality.html %}
-</div>
-
-## Example
-
-### Setup
-
-The following example uses MovR, a fictional vehicle-sharing application, to demonstrate CockroachDB SQL statements. For more information about the MovR example application and dataset, see [MovR: A Global Vehicle-sharing App](movr.html).
-
-To follow along, run [`cockroach demo movr`](cockroach-demo.html) with the `--nodes` and `--demo-locality` tags. This command opens an interactive SQL shell to a temporary, multi-node in-memory cluster with the `movr` database preloaded and set as the [current database](sql-name-resolution.html#current-database).
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo movr --nodes=3 --demo-locality=region=us-east,az=a:region=us-central,az=b:region=us-west1,az=c
-~~~
-
-### Show locality
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW LOCALITY;
-~~~
-
-~~~
-       locality
-+---------------------+
-  region=us-east,az=a
-(1 row)
-~~~
-
-### Show locality with a built-in function
-
-If you know the locality key, you can use the [`crdb_internal.locality_value`](functions-and-operators.html#system-info-functions) built-in function to return the locality value for the current node:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM crdb_internal.locality_value('region');
-~~~
-
-~~~
-  crdb_internal.locality_value
-+------------------------------+
-  us-east
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM crdb_internal.locality_value('az');
-~~~
-
-~~~
-  crdb_internal.locality_value
-+------------------------------+
-  a
-(1 row)
-~~~
-
-For a more extensive example, see [Create a table with node locality information](cockroach-start.html#create-a-table-with-node-locality-information).
-
-
-## See also
-
-- [Geo-Partitioning](demo-low-latency-multi-region-deployment.html)
-- [Locality](cockroach-start.html#locality)
-- [Orchestrated Deployment](orchestration.html)
-- [Manual Deployment](manual-deployment.html)
diff --git a/src/current/v20.2/show-partitions.md b/src/current/v20.2/show-partitions.md
deleted file mode 100644
index 8f2974107f2..00000000000
--- a/src/current/v20.2/show-partitions.md
+++ /dev/null
@@ -1,237 +0,0 @@
----
-title: SHOW PARTITIONS
-summary: Use the SHOW PARTITIONS statement to list details about existing partitions.
-toc: true
----
-
-Use the `SHOW PARTITIONS` [statement](sql-statements.html) to view details about existing [partitions](partitioning.html).
-
-{% include enterprise-feature.md %}
-
-{% include {{page.version.version}}/sql/crdb-internal-partitions.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_partitions.html %}
-</div>
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to list partitions.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`database_name` | The name of the [database](create-database.html) for which to show [partitions](partitioning.html).
-`table_name` | The name of the [table](create-table.html) for which to show [partitions](partitioning.html).
-`table_index_name` | The name of the [index](create-index.html) for which to show [partitions](partitioning.html).
-
-## Response
-
-The following fields are returned for each partition:
-
-Field | Description
-------|------------
-`database_name` | The name of the database that contains the partition.
-`table_name` | The name of the table that contains the partition.
-`partition_name` | The name of the partition.
-`parent_partition` | The name of the parent partition, if the partition is a [subpartition](partitioning.html#define-subpartitions-on-a-table).
-`column_names` | The names of the columns in the partition definition expression.
-`index_name` | The name of the index for the partition.
-`partition_value` | The value that defines the partition.
-`zone_constraints` | The [zone constraints](configure-replication-zones.html), if replication zones are configured for the partition.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements-geo-partitioned-replicas.md %}
-
-The `movr` database in this example is pre-partitioned. For information about partitioning tables, see [Define Table Partitions](partitioning.html) or [`PARTITION BY`](partition-by.html).
-
-### Show table partitions
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW PARTITIONS FROM TABLE users;
-~~~
-
-~~~
-  database_name | table_name | partition_name | parent_partition | column_names |  index_name   |                 partition_value                 |              zone_config               |            full_zone_config
-+---------------+------------+----------------+------------------+--------------+---------------+-------------------------------------------------+----------------------------------------+-----------------------------------------+
-  movr          | users      | us_west        | NULL             | city         | users@primary | ('seattle'), ('san francisco'), ('los angeles') | constraints = '[+region=us-west1]'     | range_min_bytes = 134217728,
-                |            |                |                  |              |               |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |               |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |               |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |               |                                                 |                                        | constraints = '[+region=us-west1]',
-                |            |                |                  |              |               |                                                 |                                        | lease_preferences = '[]'
-  movr          | users      | us_east        | NULL             | city         | users@primary | ('new york'), ('boston'), ('washington dc')     | constraints = '[+region=us-east1]'     | range_min_bytes = 134217728,
-                |            |                |                  |              |               |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |               |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |               |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |               |                                                 |                                        | constraints = '[+region=us-east1]',
-                |            |                |                  |              |               |                                                 |                                        | lease_preferences = '[]'
-  movr          | users      | europe_west    | NULL             | city         | users@primary | ('amsterdam'), ('paris'), ('rome')              | constraints = '[+region=europe-west1]' | range_min_bytes = 134217728,
-                |            |                |                  |              |               |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |               |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |               |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |               |                                                 |                                        | constraints = '[+region=europe-west1]',
-                |            |                |                  |              |               |                                                 |                                        | lease_preferences = '[]'
-(3 rows)
-~~~
-
-You can also use [`SHOW CREATE TABLE`](show-create.html) to view partitions on a table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                                  create_statement
-+------------+-------------------------------------------------------------------------------------+
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | ) PARTITION BY LIST (city) (
-             |     PARTITION us_west VALUES IN (('seattle'), ('san francisco'), ('los angeles')),
-             |     PARTITION us_east VALUES IN (('new york'), ('boston'), ('washington dc')),
-             |     PARTITION europe_west VALUES IN (('amsterdam'), ('paris'), ('rome'))
-             | );
-             | ALTER PARTITION europe_west OF INDEX movr.public.users@primary CONFIGURE ZONE USING
-             |     constraints = '[+region=europe-west1]';
-             | ALTER PARTITION us_east OF INDEX movr.public.users@primary CONFIGURE ZONE USING
-             |     constraints = '[+region=us-east1]';
-             | ALTER PARTITION us_west OF INDEX movr.public.users@primary CONFIGURE ZONE USING
-             |     constraints = '[+region=us-west1]'
-(1 row)
-~~~
-
-If a partitioned table has no zones configured, the `SHOW CREATE TABLE` output includes a warning.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER PARTITION us_west OF TABLE users CONFIGURE ZONE DISCARD;
-  ALTER PARTITION us_east OF TABLE users CONFIGURE ZONE DISCARD;
-  ALTER PARTITION europe_west OF TABLE users CONFIGURE ZONE DISCARD;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                                  create_statement
-+------------+-------------------------------------------------------------------------------------+
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | ) PARTITION BY LIST (city) (
-             |     PARTITION us_west VALUES IN (('seattle'), ('san francisco'), ('los angeles')),
-             |     PARTITION us_east VALUES IN (('new york'), ('boston'), ('washington dc')),
-             |     PARTITION europe_west VALUES IN (('amsterdam'), ('paris'), ('rome'))
-             | )
-             | -- Warning: Partitioned table with no zone configurations.
-(1 row)
-~~~
-
-
-### Show partitions by index
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW PARTITIONS FROM INDEX vehicles@vehicles_auto_index_fk_city_ref_users;
-~~~
-
-~~~
-  database_name | table_name | partition_name | parent_partition | column_names |                   index_name                   |                 partition_value                 |              zone_config               |            full_zone_config
-+---------------+------------+----------------+------------------+--------------+------------------------------------------------+-------------------------------------------------+----------------------------------------+-----------------------------------------+
-  movr          | vehicles   | us_west        | NULL             | city         | vehicles@vehicles_auto_index_fk_city_ref_users | ('seattle'), ('san francisco'), ('los angeles') | constraints = '[+region=us-west1]'     | range_min_bytes = 134217728,
-                |            |                |                  |              |                                                |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                                                |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                                                |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                                                |                                                 |                                        | constraints = '[+region=us-west1]',
-                |            |                |                  |              |                                                |                                                 |                                        | lease_preferences = '[]'
-  movr          | vehicles   | us_east        | NULL             | city         | vehicles@vehicles_auto_index_fk_city_ref_users | ('new york'), ('boston'), ('washington dc')     | constraints = '[+region=us-east1]'     | range_min_bytes = 134217728,
-                |            |                |                  |              |                                                |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                                                |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                                                |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                                                |                                                 |                                        | constraints = '[+region=us-east1]',
-                |            |                |                  |              |                                                |                                                 |                                        | lease_preferences = '[]'
-  movr          | vehicles   | europe_west    | NULL             | city         | vehicles@vehicles_auto_index_fk_city_ref_users | ('amsterdam'), ('paris'), ('rome')              | constraints = '[+region=europe-west1]' | range_min_bytes = 134217728,
-                |            |                |                  |              |                                                |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                                                |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                                                |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                                                |                                                 |                                        | constraints = '[+region=europe-west1]',
-                |            |                |                  |              |                                                |                                                 |                                        | lease_preferences = '[]'
-(3 rows)
-~~~
-
-### Show partitions by database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW PARTITIONS FROM DATABASE movr;
-~~~
-
-~~~
-  database_name | table_name | partition_name | parent_partition | column_names |    index_name    |                 partition_value                 |              zone_config               |            full_zone_config
-+---------------+------------+----------------+------------------+--------------+------------------+-------------------------------------------------+----------------------------------------+-----------------------------------------+
-  movr          | users      | us_west        | NULL             | city         | users@primary    | ('seattle'), ('san francisco'), ('los angeles') | NULL                                   | range_min_bytes = 134217728,
-                |            |                |                  |              |                  |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                  |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                  |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                  |                                                 |                                        | constraints = '[]',
-                |            |                |                  |              |                  |                                                 |                                        | lease_preferences = '[]'
-  movr          | users      | us_east        | NULL             | city         | users@primary    | ('new york'), ('boston'), ('washington dc')     | NULL                                   | range_min_bytes = 134217728,
-                |            |                |                  |              |                  |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                  |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                  |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                  |                                                 |                                        | constraints = '[]',
-                |            |                |                  |              |                  |                                                 |                                        | lease_preferences = '[]'
-  movr          | users      | europe_west    | NULL             | city         | users@primary    | ('amsterdam'), ('paris'), ('rome')              | NULL                                   | range_min_bytes = 134217728,
-                |            |                |                  |              |                  |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                  |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                  |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                  |                                                 |                                        | constraints = '[]',
-                |            |                |                  |              |                  |                                                 |                                        | lease_preferences = '[]'
-  movr          | vehicles   | us_west        | NULL             | city         | vehicles@primary | ('seattle'), ('san francisco'), ('los angeles') | constraints = '[+region=us-west1]'     | range_min_bytes = 134217728,
-                |            |                |                  |              |                  |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                  |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                  |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                  |                                                 |                                        | constraints = '[+region=us-west1]',
-                |            |                |                  |              |                  |                                                 |                                        | lease_preferences = '[]'
-  movr          | vehicles   | us_east        | NULL             | city         | vehicles@primary | ('new york'), ('boston'), ('washington dc')     | constraints = '[+region=us-east1]'     | range_min_bytes = 134217728,
-                |            |                |                  |              |                  |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                  |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                  |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                  |                                                 |                                        | constraints = '[+region=us-east1]',
-                |            |                |                  |              |                  |                                                 |                                        | lease_preferences = '[]'
-  movr          | vehicles   | europe_west    | NULL             | city         | vehicles@primary | ('amsterdam'), ('paris'), ('rome')              | constraints = '[+region=europe-west1]' | range_min_bytes = 134217728,
-                |            |                |                  |              |                  |                                                 |                                        | range_max_bytes = 536870912,
-                |            |                |                  |              |                  |                                                 |                                        | gc.ttlseconds = 90000,
-                |            |                |                  |              |                  |                                                 |                                        | num_replicas = 3,
-                |            |                |                  |              |                  |                                                 |                                        | constraints = '[+region=europe-west1]',
-                |            |                |                  |              |                  |                                                 |                                        | lease_preferences = '[]'
-...
-(24 rows)
-~~~
-
-{% include {{page.version.version}}/sql/crdb-internal-partitions-example.md %}
-
-## See also
-
-- [Define Table Partitions](partitioning.html)
-- [SQL Statements](sql-statements.html)
-- [Geo-Partitioning](demo-low-latency-multi-region-deployment.html)
diff --git a/src/current/v20.2/show-queries.md b/src/current/v20.2/show-queries.md
deleted file mode 100644
index 7019b2aeef9..00000000000
--- a/src/current/v20.2/show-queries.md
+++ /dev/null
@@ -1,172 +0,0 @@
----
-title: SHOW QUERIES
-summary: The SHOW QUERIES statement lists all currently active queries across the cluster or on the local node.
-toc: true
----
-
-The `SHOW QUERIES` [statement](sql-statements.html) lists details about currently active SQL queries, including:
-
-- The internal ID of the query
-- The node executing the query
-- The SQL query itself
-- How long the query has been running
-- The client address, application name, and user that issued the query
--  The ID for the current session
-
-These details let you monitor the progress of active queries and, if necessary, identify those that may need to be [cancelled](cancel-query.html) to prevent unwanted resource consumption.
-
-{{site.data.alerts.callout_info}}
-Schema changes and [`BACKUP`](backup.html)/[`RESTORE`](restore.html) statements are not executed as queries internally and so are not listed by `SHOW QUERIES`. To monitor such statements, use [`SHOW JOBS`](show-jobs.html) instead.
-{{site.data.alerts.end}}
-
-## Required privileges
-
-All users can see their own currently active queries. All users belonging to the `admin` role can view see all users' currently active queries. To view other non-admin users' queries, the non-admin user must have the [`VIEWACTIVITY`](create-user.html#create-a-user-that-can-see-and-cancel-non-admin-queries-and-sessions) parameter set. 
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_queries.html %}
-</div>
-
-- To list the active queries across all nodes of the cluster, use `SHOW QUERIES` or `SHOW CLUSTER QUERIES`.
-- To list the active queries just on the local node, use `SHOW LOCAL QUERIES`.
-
-## Response
-
-The following fields are returned for each query:
-
-Field | Description
-------|------------
-`query_id` | The ID of the query.
-`node_id` | The ID of the node.
-`session_id` | The ID of the session.
-`user_name` | The username of the connected user.
-`start` | The timestamp at which the query started.
-`query` | The SQL query.
-`client_address` | The address and port of the client that issued the SQL query.
-`application_name` | The [application name](set-vars.html#supported-variables) specified by the client, if any. For queries from the [built-in SQL client](cockroach-sql.html), this will be `$ cockroach sql`.
-`distributed` | If `true`, the query is being executed by the Distributed SQL (DistSQL) engine. If `false`, the query is being executed by the standard "local" SQL engine. If `NULL`, the query is being prepared and it's not yet known which execution engine will be used.
-`phase` | The phase of the query's execution. If `preparing`, the statement is being parsed and planned. If `executing`, the statement is being executed.
-
-## Examples
-
-### List queries across the cluster
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER QUERIES;
-~~~
-
-~~~
-              query_id             | node_id |            session_id            | user_name |              start               |                                 query                                 | client_address  | application_name | distributed |   phase
-+----------------------------------+---------+----------------------------------+-----------+----------------------------------+-----------------------------------------------------------------------+-----------------+------------------+-------------+-----------+
-  15f92b12b2fb95b00000000000000002 |       2 | 15f92b10b92ed4080000000000000002 | root      | 2020-03-04 17:48:23.309592+00:00 | SELECT city, id FROM vehicles WHERE city = $1                         | 127.0.0.1:65092 |                  |    false    | executing
-  15f92b12b2ea5f700000000000000001 |       1 | 15f92adefd48d8a00000000000000001 | root      | 2020-03-04 17:48:23.3085+00:00   | SHOW CLUSTER QUERIES                                                  | 127.0.0.1:64970 | $ cockroach sql  |    false    | executing
-  15f92b12b2ffeb100000000000000003 |       3 | 15f92b0e4ea399680000000000000003 | root      | 2020-03-04 17:48:23.30989+00:00  | UPSERT INTO vehicle_location_histories VALUES ($1, $2, now(), $3, $4) | 127.0.0.1:65088 |                  |    NULL     | preparing
-(3 rows)
-~~~
-
-Alternatively, you can use `SHOW QUERIES` to receive the same response.
-
-### List queries on the local node
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW LOCAL QUERIES;
-~~~
-
-~~~
-              query_id             | node_id |            session_id            | user_name |              start               |                           query                            | client_address  | application_name | distributed |   phase
-+----------------------------------+---------+----------------------------------+-----------+----------------------------------+------------------------------------------------------------+-----------------+------------------+-------------+-----------+
-  15f92b15bece88900000000000000001 |       1 | 15f92aefb240d2980000000000000001 | root      | 2020-03-04 17:48:36.392919+00:00 | INSERT INTO user_promo_codes VALUES ($1, $2, $3, now(), 1) | 127.0.0.1:65044 |                  |    false    | executing
-  15f92b15bed80a280000000000000001 |       1 | 15f92adefd48d8a00000000000000001 | root      | 2020-03-04 17:48:36.393495+00:00 | SHOW LOCAL QUERIES                                         | 127.0.0.1:64970 | $ cockroach sql  |    false    | executing
-(2 rows)
-~~~
-
-### Filter for specific queries
-
-You can use a [`SELECT`](select-clause.html) statement to filter the list of active queries by one or more of the [response fields](#response).
-
-#### Show all queries on node 2
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER QUERIES]
-      WHERE node_id = 2;
-~~~
-
-~~~
-              query_id             | node_id |            session_id            | user_name |              start               |                                 query                                 | client_address  | application_name | distributed |   phase
-+----------------------------------+---------+----------------------------------+-----------+----------------------------------+-----------------------------------------------------------------------+-----------------+------------------+-------------+-----------+
-  15f92b1cb931f6900000000000000002 |       2 | 15f92b10b92ed4080000000000000002 | root      | 2020-03-04 17:49:06.363515+00:00 | UPSERT INTO vehicle_location_histories VALUES ($1, $2, now(), $3, $4) | 127.0.0.1:65092 |                  |    NULL     | preparing
-(1 row)
-~~~
-
-#### Show all queries from a specific address and user
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER QUERIES]
-      WHERE client_address = '127.0.0.1:65196' AND user_name = 'maxroach';
-~~~
-
-~~~
-              query_id             | node_id |            session_id            | user_name |              start               |                     query                     | client_address  | application_name | distributed |   phase
-+----------------------------------+---------+----------------------------------+-----------+----------------------------------+-----------------------------------------------+-----------------+------------------+-------------+-----------+
-  15f92bf4b27f0b480000000000000002 |       2 | 15f92b7dc85b7ba80000000000000002 | maxroach  | 2020-03-04 18:04:33.964083+00:00 | SELECT city, id FROM vehicles WHERE city = $1 | 127.0.0.1:65196 |                  |    false    | executing
-(1 row)
-~~~
-
-#### Exclude queries from the built-in SQL client
-
-To exclude queries from the [built-in SQL client](cockroach-sql.html), filter for queries that do not show `$ cockroach sql` as the `application_name`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER QUERIES]
-      WHERE application_name != '$ cockroach sql';
-~~~
-
-~~~
-              query_id             | node_id |            session_id            | user_name |              start               |                                 query                                 | client_address  | application_name | distributed |   phase
-+----------------------------------+---------+----------------------------------+-----------+----------------------------------+-----------------------------------------------------------------------+-----------------+------------------+-------------+-----------+
-  15f92c0dd24bec200000000000000003 |       3 | 15f92b0e4ea399680000000000000003 | root      | 2020-03-04 18:06:21.871708+00:00 | SELECT city, id FROM vehicles WHERE city = $1                         | 127.0.0.1:65088 |                  |    false    | executing
-  15f92c0dd26655d80000000000000001 |       1 | 15f92be36964ac800000000000000001 | root      | 2020-03-04 18:06:21.873515+00:00 | UPSERT INTO vehicle_location_histories VALUES ($1, $2, now(), $3, $4) | 127.0.0.1:65240 |                  |    false    | executing
-  15f92c0dd25882c80000000000000001 |       1 | 15f92aefb240d2980000000000000001 | root      | 2020-03-04 18:06:21.872608+00:00 | UPSERT INTO vehicle_location_histories VALUES ($1, $2, now(), $3, $4) | 127.0.0.1:65044 |                  |    false    | executing
-  15f92c0dd262cb980000000000000002 |       2 | 15f92b7dc85b7ba80000000000000002 | maxroach  | 2020-03-04 18:06:21.873286+00:00 | SELECT city, id FROM vehicles WHERE city = $1                         | 127.0.0.1:65196 |                  |    false    | executing
-~~~
-
-### Cancel a query
-
-When you see a query that is taking too long to complete, you can use the [`CANCEL QUERY`](cancel-query.html) statement to end it.
-
-For example, let's say you use `SHOW CLUSTER QUERIES` to find queries that have been running for more than 3 hours:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER QUERIES]
-      WHERE start < (now() - INTERVAL '3 hours');
-~~~
-
-~~~
-              query_id             | node_id |            session_id            | user_name |              start              |        query        | client_address  | application_name | distributed |   phase
-+----------------------------------+---------+----------------------------------+-----------+---------------------------------+---------------------+-----------------+------------------+-------------+-----------+
-  15f92c745fe203600000000000000001 |       1 | 15f92c63d4b393b80000000000000001 | root      | 2020-03-04 18:13:42.33385+00:00 | SELECT * FROM rides | 127.0.0.1:65287 | $ cockroach sql  |    true     | executing
-(1 row)
-~~~
-
-To cancel this long-running query, and stop it from consuming resources, you note the `query_id` and use it with the `CANCEL QUERY` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL QUERY '15f92c745fe203600000000000000001';
-~~~
-
-## See also
-
-- [Manage Long-Running Queries](manage-long-running-queries.html)
-- [`CANCEL QUERY`](cancel-query.html)
-- [`SHOW SESSIONS`](show-sessions.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-range-for-row.md b/src/current/v20.2/show-range-for-row.md
deleted file mode 100644
index fe069120c7d..00000000000
--- a/src/current/v20.2/show-range-for-row.md
+++ /dev/null
@@ -1,162 +0,0 @@
----
-title: SHOW RANGE FOR ROW
-summary: The SHOW RANGE FOR ROW statement shows information about the range for a single row.
-toc: true
----
-
-The `SHOW RANGE ... FOR ROW` [statement](sql-statements.html) shows information about a [range](architecture/overview.html#glossary) for a single row in a table or index. This information is useful for verifying how SQL data maps to underlying ranges, and where the replicas for a range are located.
-
-{% include {{ page.version.version }}/misc/experimental-warning.md %}
-
-{{site.data.alerts.callout_info}}
-To show information about the ranges for all data in a table, index, or database, use the [`SHOW RANGES`](show-ranges.html) statement.
-{{site.data.alerts.end}}
-
-## Syntax
-
-~~~
-SHOW RANGE FROM TABLE <tablename> FOR ROW (value1, value2, ...)
-SHOW RANGE FROM INDEX [ <tablename> @ ] <indexname> FOR ROW (value1, value2, ...)
-~~~
-
-## Required privileges
-
-The user must have the `SELECT` [privilege](authorization.html#assign-privileges) on the target table.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`tablename` | The name of the table that contains the row that you want range information about.
-`indexname` | The name of the index that contains the row that you want range information about.
-`(value1, value2, ...)` | <span class="version-tag">New in v20.2</span>: The values of the indexed columns of the row that you want range information about, as a tuple. In previous releases, this statement required the values of all columns of a row.
-
-## Response
-
-The following fields are returned:
-
-Field | Description
-------|------------
-`start_key` | The start key for the range.
-`end_key` | The end key for the range.
-`range_id` | The range ID.
-`lease_holder` | The node that contains the range's [leaseholder](architecture/overview.html#glossary).
-`lease_holder_locality` | The [locality](cockroach-start.html#locality) of the leaseholder.
-`replicas` | The nodes that contain the range [replicas](architecture/overview.html#glossary).
-`replica_localities` | The [locality](cockroach-start.html#locality) of the range.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Show range information for a row in a table
-
-To show information about a row in a table, you must know the values of the columns in the row's primary key:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM vehicles;
-~~~
-
-~~~
-  table_name |              index_name               | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+---------------------------------------+------------+--------------+-------------+-----------+---------+-----------
-  vehicles   | primary                               |   false    |            1 | city        | ASC       |  false  |  false
-  vehicles   | primary                               |   false    |            2 | id          | ASC       |  false  |  false
-  vehicles   | vehicles_auto_index_fk_city_ref_users |    true    |            1 | city        | ASC       |  false  |  false
-  vehicles   | vehicles_auto_index_fk_city_ref_users |    true    |            2 | owner_id    | ASC       |  false  |  false
-  vehicles   | vehicles_auto_index_fk_city_ref_users |    true    |            3 | id          | ASC       |  false  |   true
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, id FROM vehicles LIMIT 5;
-~~~
-
-~~~
-     city     |                  id
---------------+---------------------------------------
-  amsterdam   | bbbbbbbb-bbbb-4800-8000-00000000000b
-  amsterdam   | aaaaaaaa-aaaa-4800-8000-00000000000a
-  boston      | 22222222-2222-4200-8000-000000000002
-  boston      | 33333333-3333-4400-8000-000000000003
-  los angeles | 99999999-9999-4800-8000-000000000009
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGE FROM TABLE vehicles FOR ROW (
-    'boston',
-    '22222222-2222-4200-8000-000000000002'
-  );
-~~~
-
-~~~
-                            start_key                           |                         end_key                         | range_id | lease_holder | lease_holder_locality | replicas |    replica_localities
-----------------------------------------------------------------+---------------------------------------------------------+----------+--------------+-----------------------+----------+---------------------------
-  /"boston"/"\"\"\"\"\"\"B\x00\x80\x00\x00\x00\x00\x00\x00\x02" | /"boston"/"333333D\x00\x80\x00\x00\x00\x00\x00\x00\x03" |       57 |            1 | region=us-east1,az=b  | {1}      | {"region=us-east1,az=b"}
-(1 row)
-~~~
-
-### Show range information for a row by a secondary index
-
-To show information about a row in a secondary index, you must know the values of the indexed columns:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW INDEX FROM vehicles;
-~~~
-
-~~~
-  table_name |              index_name               | non_unique | seq_in_index | column_name | direction | storing | implicit
--------------+---------------------------------------+------------+--------------+-------------+-----------+---------+-----------
-  vehicles   | primary                               |   false    |            1 | city        | ASC       |  false  |  false
-  vehicles   | primary                               |   false    |            2 | id          | ASC       |  false  |  false
-  vehicles   | vehicles_auto_index_fk_city_ref_users |    true    |            1 | city        | ASC       |  false  |  false
-  vehicles   | vehicles_auto_index_fk_city_ref_users |    true    |            2 | owner_id    | ASC       |  false  |  false
-  vehicles   | vehicles_auto_index_fk_city_ref_users |    true    |            3 | id          | ASC       |  false  |   true
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT city, owner_id, id FROM vehicles@vehicles_auto_index_fk_city_ref_users LIMIT 5;
-~~~
-
-~~~
-     city     |               owner_id               |                  id
---------------+--------------------------------------+---------------------------------------
-  amsterdam   | bd70a3d7-0a3d-4000-8000-000000000025 | bbbbbbbb-bbbb-4800-8000-00000000000b
-  amsterdam   | c28f5c28-f5c2-4000-8000-000000000026 | aaaaaaaa-aaaa-4800-8000-00000000000a
-  boston      | 2e147ae1-47ae-4400-8000-000000000009 | 22222222-2222-4200-8000-000000000002
-  boston      | 33333333-3333-4400-8000-00000000000a | 33333333-3333-4400-8000-000000000003
-  los angeles | 9eb851eb-851e-4800-8000-00000000001f | 99999999-9999-4800-8000-000000000009
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGE FROM INDEX vehicles@vehicles_auto_index_fk_city_ref_users FOR ROW (
-    'boston',
-    '2e147ae1-47ae-4400-8000-000000000009',
-    '22222222-2222-4200-8000-000000000002'
-  );
-~~~
-
-~~~
-  start_key | end_key | range_id | lease_holder | lease_holder_locality | replicas |    replica_localities
-------------+---------+----------+--------------+-----------------------+----------+---------------------------
-  NULL      | NULL    |       53 |            1 | region=us-east1,az=b  | {1}      | {"region=us-east1,az=b"}
-~~~
-
-## See also
-
-- [`SHOW RANGES`](show-ranges.html)
-- [`SPLIT AT`](split-at.html)
-- [`CREATE TABLE`](create-table.html)
-- [`CREATE INDEX`](create-index.html)
-- [Indexes](indexes.html)
-- [Partitioning tables](partitioning.html)
-- [Architecture Overview](architecture/overview.html)
diff --git a/src/current/v20.2/show-ranges.md b/src/current/v20.2/show-ranges.md
deleted file mode 100644
index 972e4990fb1..00000000000
--- a/src/current/v20.2/show-ranges.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: SHOW RANGES
-summary: The SHOW RANGES statement shows information about the ranges that comprise the data for a table, index, or entire database.
-toc: true
----
-
-The `SHOW RANGES` [statement](sql-statements.html) shows information about the [ranges](architecture/overview.html#glossary) that comprise the data for a table, index, or entire database. This information is useful for verifying how SQL data maps to underlying ranges, and where the replicas for ranges are located. If `SHOW RANGES` displays `NULL` for both the start and end keys of a range, the range is empty and has no splits.
-
-{{site.data.alerts.callout_info}}
-To show range information for a specific row in a table or index, use the [`SHOW RANGE ... FOR ROW`](show-range-for-row.html) statement.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_ranges.html %}
-</div>
-
-## Required privileges
-
-Only members of the [`admin` role](authorization.html#admin-role) can run `SHOW RANGES`. By default, the `root` user belongs to the `admin` role.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-[`table_name`](sql-grammar.html#table_name) | The name of the table you want range information about.
-[`table_index_name`](sql-grammar.html#table_index_name) | The name of the index you want range information about.
-[`database_name`](sql-grammar.html#database_name) | The name of the database you want range information about.
-
-## Response
-
-The following fields are returned for each partition:
-
-Field | Description
-------|------------
-`table_name` | The name of the table.
-`start_key` | The start key for the range.
-`end_key` | The end key for the range.
-`range_id` | The range ID.
-`range_size_mb` | The size of the range.
-`lease_holder` | The node that contains the range's [leaseholder](architecture/overview.html#glossary).
-`lease_holder_locality` | The [locality](cockroach-start.html#locality) of the leaseholder.
-`replicas` | The nodes that contain the range [replicas](architecture/overview.html#glossary).
-`replica_localities` | The [locality](cockroach-start.html#locality) of the range.
-
-{{site.data.alerts.callout_info}}
-If both `start_key` and `end_key` show `NULL`, the range is empty and has no splits.
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements-geo-partitioned-replicas.md %}
-
-### Show ranges for a table (primary index)
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW RANGES FROM TABLE vehicles] WHERE "start_key" NOT LIKE '%Prefix%';
-~~~
-~~~
-     start_key     |          end_key           | range_id | range_size_mb | lease_holder |  lease_holder_locality   | replicas |                                 replica_localities
-+------------------+----------------------------+----------+---------------+--------------+--------------------------+----------+------------------------------------------------------------------------------------+
-  /"new york"      | /"new york"/PrefixEnd      |       58 |      0.000304 |            2 | region=us-east1,az=c     | {1,2,5}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-west1,az=b"}
-  /"washington dc" | /"washington dc"/PrefixEnd |      102 |      0.000173 |            2 | region=us-east1,az=c     | {1,2,3}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-east1,az=d"}
-  /"boston"        | /"boston"/PrefixEnd        |       63 |      0.000288 |            3 | region=us-east1,az=d     | {1,2,3}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-east1,az=d"}
-  /"seattle"       | /"seattle"/PrefixEnd       |       97 |      0.000295 |            4 | region=us-west1,az=a     | {4,5,6}  | {"region=us-west1,az=a","region=us-west1,az=b","region=us-west1,az=c"}
-  /"los angeles"   | /"los angeles"/PrefixEnd   |       55 |      0.000156 |            5 | region=us-west1,az=b     | {4,5,6}  | {"region=us-west1,az=a","region=us-west1,az=b","region=us-west1,az=c"}
-  /"san francisco" | /"san francisco"/PrefixEnd |       71 |      0.000309 |            6 | region=us-west1,az=c     | {1,5,6}  | {"region=us-east1,az=b","region=us-west1,az=b","region=us-west1,az=c"}
-  /"amsterdam"     | /"amsterdam"/PrefixEnd     |       59 |      0.000305 |            9 | region=europe-west1,az=d | {7,8,9}  | {"region=europe-west1,az=b","region=europe-west1,az=c","region=europe-west1,az=d"}
-  /"paris"         | /"paris"/PrefixEnd         |       62 |      0.000299 |            9 | region=europe-west1,az=d | {7,8,9}  | {"region=europe-west1,az=b","region=europe-west1,az=c","region=europe-west1,az=d"}
-  /"rome"          | /"rome"/PrefixEnd          |       67 |      0.000168 |            9 | region=europe-west1,az=d | {7,8,9}  | {"region=europe-west1,az=b","region=europe-west1,az=c","region=europe-west1,az=d"}
-(9 rows)
-~~~
-
-### Show ranges for an index
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW RANGES FROM INDEX vehicles_auto_index_fk_city_ref_users] WHERE "start_key" NOT LIKE '%Prefix%';
-~~~
-~~~
-     start_key     |          end_key           | range_id | range_size_mb | lease_holder |  lease_holder_locality   | replicas |                                 replica_localities
-+------------------+----------------------------+----------+---------------+--------------+--------------------------+----------+------------------------------------------------------------------------------------+
-  /"washington dc" | /"washington dc"/PrefixEnd |      188 |      0.000089 |            2 | region=us-east1,az=c     | {1,2,3}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-east1,az=d"}
-  /"boston"        | /"boston"/PrefixEnd        |      141 |      0.000164 |            3 | region=us-east1,az=d     | {1,2,3}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-east1,az=d"}
-  /"new york"      | /"new york"/PrefixEnd      |      168 |      0.000174 |            3 | region=us-east1,az=d     | {1,2,3}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-east1,az=d"}
-  /"los angeles"   | /"los angeles"/PrefixEnd   |      165 |      0.000087 |            6 | region=us-west1,az=c     | {4,5,6}  | {"region=us-west1,az=a","region=us-west1,az=b","region=us-west1,az=c"}
-  /"san francisco" | /"san francisco"/PrefixEnd |      174 |      0.000183 |            6 | region=us-west1,az=c     | {4,5,6}  | {"region=us-west1,az=a","region=us-west1,az=b","region=us-west1,az=c"}
-  /"seattle"       | /"seattle"/PrefixEnd       |      186 |      0.000166 |            6 | region=us-west1,az=c     | {4,5,6}  | {"region=us-west1,az=a","region=us-west1,az=b","region=us-west1,az=c"}
-  /"amsterdam"     | /"amsterdam"/PrefixEnd     |      137 |       0.00017 |            9 | region=europe-west1,az=d | {7,8,9}  | {"region=europe-west1,az=b","region=europe-west1,az=c","region=europe-west1,az=d"}
-  /"paris"         | /"paris"/PrefixEnd         |      170 |      0.000162 |            9 | region=europe-west1,az=d | {7,8,9}  | {"region=europe-west1,az=b","region=europe-west1,az=c","region=europe-west1,az=d"}
-  /"rome"          | /"rome"/PrefixEnd          |      172 |       0.00008 |            9 | region=europe-west1,az=d | {7,8,9}  | {"region=europe-west1,az=b","region=europe-west1,az=c","region=europe-west1,az=d"}
-(9 rows)
-~~~
-
-### Show ranges for a database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW RANGES FROM database movr] WHERE "start_key" NOT LIKE '%Prefix%';
-~~~
-~~~
-          table_name         |    start_key     |          end_key           | range_id | range_size_mb | lease_holder |  lease_holder_locality   | replicas |                                 replica_localities
-+----------------------------+------------------+----------------------------+----------+---------------+--------------+--------------------------+----------+------------------------------------------------------------------------------------+
-  users                      | /"amsterdam"     | /"amsterdam"/PrefixEnd     |       47 |      0.000562 |            7 | region=europe-west1,az=b | {7,8,9}  | {"region=europe-west1,az=b","region=europe-west1,az=c","region=europe-west1,az=d"}
-  users                      | /"boston"        | /"boston"/PrefixEnd        |       51 |      0.000665 |            3 | region=us-east1,az=d     | {1,2,3}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-east1,az=d"}
-  users                      | /"chicago"       | /"los angeles"             |       83 |             0 |            4 | region=us-west1,az=a     | {2,4,8}  | {"region=us-east1,az=c","region=us-west1,az=a","region=europe-west1,az=c"}
-  users                      | /"los angeles"   | /"los angeles"/PrefixEnd   |       45 |      0.000697 |            4 | region=us-west1,az=a     | {4,5,6}  | {"region=us-west1,az=a","region=us-west1,az=b","region=us-west1,az=c"}
-  users                      | /"new york"      | /"new york"/PrefixEnd      |       48 |      0.000664 |            1 | region=us-east1,az=b     | {1,2,3}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-east1,az=d"}
-  users                      | /"paris"         | /"paris"/PrefixEnd         |       52 |      0.000628 |            8 | region=europe-west1,az=c | {7,8,9}  | {"region=europe-west1,az=b","region=europe-west1,az=c","region=europe-west1,az=d"}
-
-  ...
-
-  user_promo_codes           | /"washington dc" | /"washington dc"/PrefixEnd |      144 |             0 |            2 | region=us-east1,az=c     | {1,2,3}  | {"region=us-east1,az=b","region=us-east1,az=c","region=us-east1,az=d"}
-(73 rows)
-~~~
-
-## See also
-
-- [`SHOW RANGE ... FOR ROW`](show-range-for-row.html)
-- [`SPLIT AT`](split-at.html)
-- [`CREATE TABLE`](create-table.html)
-- [`CREATE INDEX`](create-index.html)
-- [Indexes](indexes.html)
-- [Partitioning tables](partitioning.html)
-- [Architecture Overview](architecture/overview.html)
diff --git a/src/current/v20.2/show-roles.md b/src/current/v20.2/show-roles.md
deleted file mode 100644
index aa61d086a8c..00000000000
--- a/src/current/v20.2/show-roles.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: SHOW ROLES
-summary: The SHOW ROLES statement lists the roles for all databases.
-toc: true
----
-
-The `SHOW ROLES` [statement](sql-statements.html) lists the roles for all databases.
-
-{{site.data.alerts.callout_info}}
- Since the keywords `ROLES` and `USERS` can now be used interchangeably in SQL statements for enhanced Postgres compatibility, `SHOW ROLES` is now an alias for [`SHOW USERS`](show-users.html).
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_roles.html %}
-</div>
-
-## Required privileges
-
-The role must have the [`SELECT`](select-clause.html) [privilege](authorization.html#assign-privileges) on the `system.users` and `system.role_members` tables.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ROLES;
-~~~
-
-~~~
-  username |  options   | member_of
------------+------------+------------
-  admin    | CREATEROLE | {}
-  carl     | NOLOGIN    | {}
-  petee    |            | {}
-  root     | CREATEROLE | {admin}
-(4 rows)
-~~~
-
-## See also
-
-- [Authorization](authorization.html)
-- [`CREATE ROLE`](create-role.html)
-- [`DROP ROLE`](drop-role.html)
-- [`GRANT <privileges>`](grant.html)
-- [`REVOKE <privileges`](revoke.html)
-- [`GRANT <roles>`](grant-roles.html)
-- [`REVOKE <roles`](revoke-roles.html)
-- [Manage Users](authorization.html#create-and-manage-users)
diff --git a/src/current/v20.2/show-savepoint-status.md b/src/current/v20.2/show-savepoint-status.md
deleted file mode 100644
index c6a08daf4ba..00000000000
--- a/src/current/v20.2/show-savepoint-status.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: SHOW SAVEPOINT STATUS
-summary: The SHOW SAVEPOINT STATUS statement lists the active savepoints in the current transaction.
-toc: true
----
-
-The `SHOW SAVEPOINT STATUS` [statement](sql-statements.html) lists the active [savepoints](savepoint.html) in the current [transaction](transactions.html).
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to create or show a savepoint. However, privileges are required for each statement within a transaction.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_savepoint_status.html %}
-</div>
-
-## Response
-
-The following fields are returned for each savepoint.
-
-Field | Description
-------|------------
-`savepoint_name` | The name of the savepoint.
-`is_initial_savepoint` | Whether the savepoint is the outermost savepoint in the transaction.
-
-## Example
-
-First, open a [transaction](transactions.html) using [`BEGIN`](begin-transaction.html), and create a [nested transaction](transactions.html#nested-transactions) using a [savepoint](savepoint.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-SAVEPOINT foo;
-~~~
-
-Next, use the `SHOW SAVEPOINT STATUS` statement to list the active savepoints in the current nested transaction.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SAVEPOINT STATUS;
-~~~
-
-~~~
-  savepoint_name | is_initial_savepoint
------------------+-----------------------
-  foo            |        true
-(1 row)
-~~~
-
-Currently, there is only one savepoint.
-
-We can commit this nested transaction by issuing the [`RELEASE SAVEPOINT`](release-savepoint.html) statement.  Then, we clear the connection for the next transaction by issuing a [`COMMIT`](commit-transaction.html) statement.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RELEASE SAVEPOINT foo;
-COMMIT;
-~~~
-
-If we did not want to commit this nested transaction, but restart it instead, we would have issued a [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html#rollback-a-nested-transaction).
-
-## See also
-
-- [`SAVEPOINT`](savepoint.html)
-- [`RELEASE SAVEPOINT`](release-savepoint.html)
-- [`ROLLBACK`](rollback-transaction.html)
-- [`BEGIN`](begin-transaction.html)
-- [`COMMIT`](commit-transaction.html)
-- [Transactions](transactions.html)
diff --git a/src/current/v20.2/show-schedules.md b/src/current/v20.2/show-schedules.md
deleted file mode 100644
index 9e8da4ee347..00000000000
--- a/src/current/v20.2/show-schedules.md
+++ /dev/null
@@ -1,129 +0,0 @@
----
-title: SHOW SCHEDULES
-summary: The SHOW SCHEDULES statement lists all currently active backup schedules.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `SHOW SCHEDULES` [statement](sql-statements.html) lists all of the currently active [backup schedules](create-schedule-for-backup.html).
-
-## Required privileges
-
-Only members of the [`admin` role](authorization.html#default-roles) can resume a schedule. By default, the `root` user belongs to the `admin` role.
-
-## Synopsis
-
-~~~
-SHOW [RUNNING | PAUSED] SCHEDULES [FOR BACKUP];
-SHOW SCHEDULE <schedule_id>;
-~~~
-
-## Parameters
-
- Parameter      | Description
-----------------+-------------
-`schedule_id`   | The ID of the schedule you want to view.
-
-## Response
-
-The output of `SHOW SCHEDULES` is sorted by creation time. The following fields are returned for each schedule:
-
-Field | Description
-------+------------
-`id` | A unique ID to identify each schedule. This value is used if you want to control schedules (i.e., [pause](pause-schedules.html), [resume](resume-schedules.html), or [drop](drop-schedules.html) it).
-`label` | The name used to identify the backup schedule, given at the time of schedule creation.
-`schedule_status` | The schedule's current status.
-`next_run`  | The [`TIMESTAMP`](timestamp.html) at which the next backup in the schedule is slated to run.
-`state` | Displays last-known errors or messages about the backup schedule. Cleared on retry of a scheduled job.
-`recurrence` | How often the backup is taken, which is set at the time of schedule creation.
-`jobsrunning` | The number of [jobs](show-jobs.html) currently running for the schedule.
-`owner` | The [user](create-user.html) who created the backup schedule. Users with active schedules cannot be dropped.
-`created` | The [`TIMESTAMP`](timestamp.html) when the job was created.
-`command` | The command that the schedule will run to take the backup. This is derived from the [`CREATE SCHEDULE FOR BACKUP`](create-schedule-for-backup.html) statement used.
-
-## Examples
-
-### Show schedules
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEDULES;
-~~~
-
-~~~
-          id         |        label        | schedule_status |         next_run          |                 state                  | recurrence | jobsrunning | owner |             created              |                                                                                                                     command
----------------------+---------------------+-----------------+---------------------------+----------------------------------------+------------+-------------+-------+----------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  588796190000218113 | schedule_name       | ACTIVE          | 2020-09-15 00:00:00+00:00 |                  NULL                  | @daily     |           0 | root  | 2020-09-10 16:52:16.846944+00:00 | {"backup_statement": "BACKUP INTO LATEST IN 's3://test/schedule-test2?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached", "backup_type": 1}
-  588819866656997377 | schedule_database   | ACTIVE          | 2020-09-15 00:01:00+00:00 |                  NULL                  | 1 0 * * *  |           0 | root  | 2020-09-10 18:52:42.339026+00:00 | {"backup_statement": "BACKUP DATABASE movr INTO LATEST IN 's3://test/schedule-database?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached", "backup_type": 1}
-  588820615348027393 | schedule_database   | ACTIVE          | 2020-09-14 22:00:00+00:00 |                  NULL                  | @hourly    |           0 | root  | 2020-09-10 18:56:30.919388+00:00 | {"backup_statement": "BACKUP TABLE movr.vehicles INTO LATEST IN 's3://test/schedule-table?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached", "backup_type": 1}
-  589963390457741313 | scheduled_first_run | PAUSED          | NULL                      | Waiting for initial backup to complete | @hourly    |           0 | root  | 2020-09-14 19:48:58.042612+00:00 | {"backup_statement": "BACKUP TABLE movr.vehicles INTO LATEST IN 's3://test/scheduled-first-run?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached", "backup_type": 1}
-  588796190012702721 | schedule_name       | ACTIVE          | 2020-09-20 00:00:00+00:00 |                  NULL                  | @weekly    |           0 | root  | 2020-09-10 16:52:16.846944+00:00 | {"backup_statement": "BACKUP INTO 's3://test/schedule-test2?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached"}
-  588819866674233345 | schedule_database   | ACTIVE          | 2020-09-20 00:00:00+00:00 |                  NULL                  | @weekly    |           0 | root  | 2020-09-10 18:52:42.339026+00:00 | {"backup_statement": "BACKUP DATABASE movr INTO 's3://test/schedule-database?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached"}
-  588820615382302721 | schedule_database   | ACTIVE          | 2020-09-15 00:00:00+00:00 |                  NULL                  | @daily     |           0 | root  | 2020-09-10 18:56:30.919388+00:00 | {"backup_statement": "BACKUP TABLE movr.vehicles INTO 's3://test/schedule-table?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached"}
-  589963390487363585 | scheduled_first_run | ACTIVE          | 2020-09-15 00:00:00+00:00 |                  NULL                  | @daily     |           0 | root  | 2020-09-14 19:48:58.042612+00:00 | {"backup_statement": "BACKUP TABLE movr.vehicles INTO 's3://test/scheduled-first-run?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached", "unpause_on_success": 589963390457741313}
-(8 rows)
-~~~
-
-### Show running schedules
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RUNNING SCHEDULES;
-~~~
-
-~~~
-          id         |        label        | schedule_status |         next_run          |   state  | recurrence | jobsrunning | owner |             created              |                                                                                      command
----------------------+---------------------+-----------------+---------------------------+----------+------------+-------------+-------+----------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------
-  588796190000218113 | schedule_name       | ACTIVE          | 2020-09-15 00:00:00+00:00 |   NULL   | @daily     |           0 | root  | 2020-09-10 16:52:16.846944+00:00 | BACKUP INTO LATEST IN 's3://test/schedule-test2?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached
-  588819866656997377 | schedule_database   | ACTIVE          | 2020-09-15 00:01:00+00:00 |   NULL   | 1 0 * * *  |           0 | root  | 2020-09-10 18:52:42.339026+00:00 | BACKUP DATABASE movr INTO LATEST IN 's3://test/schedule-database?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached
-  588820615348027393 | schedule_database   | ACTIVE          | 2020-09-14 22:00:00+00:00 |   NULL   | @hourly    |           0 | root  | 2020-09-10 18:56:30.919388+00:00 | BACKUP TABLE movr.vehicles INTO LATEST IN 's3://test/schedule-table?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached
-  588796190012702721 | schedule_name       | ACTIVE          | 2020-09-20 00:00:00+00:00 |   NULL   | @weekly    |           0 | root  | 2020-09-10 16:52:16.846944+00:00 | BACKUP INTO 's3://test/schedule-test2?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached
-  588819866674233345 | schedule_database   | ACTIVE          | 2020-09-20 00:00:00+00:00 |   NULL   | @weekly    |           0 | root  | 2020-09-10 18:52:42.339026+00:00 | BACKUP DATABASE movr INTO 's3://test/schedule-database?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached
-  588820615382302721 | schedule_database   | ACTIVE          | 2020-09-15 00:00:00+00:00 |   NULL   | @daily     |           0 | root  | 2020-09-10 18:56:30.919388+00:00 | BACKUP TABLE movr.vehicles INTO 's3://test/schedule-table?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached
-  589963390487363585 | scheduled_first_run | ACTIVE          | 2020-09-15 00:00:00+00:00 |   NULL   | @daily     |           0 | root  | 2020-09-14 19:48:58.042612+00:00 | BACKUP TABLE movr.vehicles INTO 's3://test/scheduled-first-run?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached
-(7 rows)
-~~~
-
-### Show paused schedules
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW PAUSED SCHEDULES;
-~~~
-~~~
-          id         |        label        | schedule_status | next_run |                 state                  | recurrence | jobsrunning | owner |             created              |                                                                                                              command
----------------------+---------------------+-----------------+----------+----------------------------------------+------------+-------------+-------+----------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  589963390457741313 | scheduled_first_run | PAUSED          | NULL     | Waiting for initial backup to complete | @hourly    |           0 | root  | 2020-09-14 19:48:58.042612+00:00 | {"backup_statement": "BACKUP TABLE movr.vehicles INTO LATEST IN 's3://test/scheduled-first-run?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached", "backup_type": 1}
-(1 row)
-~~~
-
-### Show a specific schedule
-
-To view a specific schedule, use the schedule's `id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEDULE 588796190012702721;
-~~~
-
-~~~
-          id         |     label     | schedule_status |         next_run          |  state  | recurrence | jobsrunning | owner |             created              |                                                                                   command
----------------------+---------------+-----------------+---------------------------+---------+------------+-------------+-------+----------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------
-  588796190012702721 | schedule_name | ACTIVE          | 2020-09-20 00:00:00+00:00 |  NULL   | @weekly    |           0 | root  | 2020-09-10 16:52:16.846944+00:00 | {"backup_statement": "BACKUP INTO 's3://test/schedule-test2?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=redacted' WITH revision_history, detached"}
-(1 row)
-~~~
-
-## See also
-
-- [Manage a Backup Schedule](manage-a-backup-schedule.html)
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`SHOW BACKUP`](show-backup.html)
-- [`PAUSE SCHEDULES`](pause-schedules.html)
-- [`RESUME SCHEDULES`](resume-schedules.html)
-- [`DROP SCHEDULES`](drop-schedules.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`RESUME JOB`](pause-job.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
diff --git a/src/current/v20.2/show-schemas.md b/src/current/v20.2/show-schemas.md
deleted file mode 100644
index fd441ceb785..00000000000
--- a/src/current/v20.2/show-schemas.md
+++ /dev/null
@@ -1,59 +0,0 @@
----
-title: SHOW SCHEMAS
-summary: The SHOW SCHEMAS statement lists the schemas in a database.
-toc: true
----
-
-The `SHOW SCHEMAS` [statement](sql-statements.html) lists all [schemas](sql-name-resolution.html#naming-hierarchy) in a database.
-
-## Required privileges
-
-The `SELECT` [privilege](authorization.html#assign-privileges) on the database is required to list the schemas in a database.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_schemas.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`name` | The name of the database for which to show [schemas](sql-name-resolution.html#naming-hierarchy). When omitted, the schemas in the [current database](sql-name-resolution.html#current-database) are listed.
-
-## Example
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Show schemas in the current database
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEMA org_one;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name
-----------------------
-  crdb_internal
-  information_schema
-  org_one
-  pg_catalog
-  pg_extension
-  public
-(6 rows)
-~~~
-
-## See also
-
-- [Logical Schemas and Namespaces](sql-name-resolution.html)
-- [`CREATE SCHEMA`](create-schema.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [Information Schema](information-schema.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-sequences.md b/src/current/v20.2/show-sequences.md
deleted file mode 100644
index 4c05f468a99..00000000000
--- a/src/current/v20.2/show-sequences.md
+++ /dev/null
@@ -1,49 +0,0 @@
----
-title: SHOW SEQUENCES
-summary: The SHOW SEQUENCES statement lists the sequences in a database.
-toc: true
----
-
-The `SHOW SEQUENCES` [statement](sql-statements.html) lists all sequences in a database.
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to list the sequences in a database.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_sequences.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`name` | The name of the database for which to list sequences. When omitted, the sequences in the [current database](sql-name-resolution.html#current-database) are listed.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE sequence_test;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SEQUENCES;
-~~~
-
-~~~
-  sequence_schema | sequence_name
-------------------+----------------
-  public          | sequence_test
-(1 row)
-~~~
-
-## See also
-
-- [`RENAME SEQUENCE`](rename-sequence.html)
-- [`CREATE SEQUENCE`](create-sequence.html)
-- [`DROP SEQUENCE`](drop-sequence.html)
-- [`ALTER SEQUENCE`](alter-sequence.html)
diff --git a/src/current/v20.2/show-sessions.md b/src/current/v20.2/show-sessions.md
deleted file mode 100644
index 6b1a921ca0b..00000000000
--- a/src/current/v20.2/show-sessions.md
+++ /dev/null
@@ -1,196 +0,0 @@
----
-title: SHOW SESSIONS
-summary: The SHOW SESSIONS statement lists all currently active sessions across the cluster or on the local node.
-toc: true
----
-
-The `SHOW SESSIONS` [statement](sql-statements.html) lists details about currently active sessions, including:
-
-- The address of the client that opened the session
-- The node connected to
-- How long the connection has been open
-- Which queries are active in the session
-- Which query has been running longest in the session
-
-These details let you monitor the overall state of client connections and identify those that may need further investigation or adjustment.
-
-
-## Required privileges
-
-All users can see their own currently active sessions. All users belonging to the `admin` role can view see all users' currently active sessions. To view other non-admin users' sessions, the non-admin user must have the [`VIEWACTIVITY`](create-user.html#create-a-user-that-can-see-and-cancel-non-admin-queries-and-sessions) parameter set.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_sessions.html %}
-</div>
-
-- To list the active sessions across all nodes of the cluster, use `SHOW SESSIONS` or `SHOW CLUSTER SESSIONS`.
-- To list the active sessions just on the local node, use `SHOW LOCAL SESSIONS`.
-
-## Response
-
-The following fields are returned for each session:
-
-Field | Description
-------|------------
-`node_id` | The ID of the node connected to.
-`session_id` | The ID of the connected session.
-`user_name` | The username of the connected user.
-`client_address` | The address and port of the connected client.
-`application_name` | The [application name](set-vars.html#supported-variables) specified by the client, if any. For sessions from the [built-in SQL client](cockroach-sql.html), this will be `cockroach`.
-`active_queries` | The SQL queries currently active in the session.
-`last_active_query` | The most recently completed SQL query in the session.
-`session_start` | The timestamp at which the session started.
-`oldest_query_start` | The timestamp at which the oldest currently active SQL query in the session started.
-`kv_txn` | The ID of the current key-value transaction for the session.
-
-## Examples
-
-### List active sessions across the cluster
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SESSIONS;
-~~~
-
-~~~
-+---------+----------------------------------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------|----------------------------------+----------------------------------+--------------------------------------+
-| node_id |            session_id            | user_name |   client_address   | application_name |               active_queries                |            last_active_query               |          session_start           |        oldest_query_start        |                kv_txn                
-+---------+----------------------------------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------+----------------------------------+----------------------------------+--------------------------------------|
-|       2 | 1530fd8813ad694b0000000000000001 | mroach    | 192.168.0.72:56194 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878113+00:00 | 2017-08-10 14:08:44.648985+00:00 | 81fbdd4d-394c-4784-b540-97cd73910dba
-|       2 | 1530ce8813ad694b0000000000000001 | mroach    | 192.168.0.72:56201 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878306+00:00 | 2017-08-10 14:08:44.653135+00:00 | 5aa6f141-5cae-468f-b16a-dfe8d4fb4bea
-|       2 | 1520ab8813ad694b0000000000000001 | mroach    | 192.168.0.72:56198 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878464+00:00 | 2017-08-10 14:08:44.643749+00:00 | d8fedb88-fc21-4720-aabe-cd43ec204d88
-|       3 | 1559f68813ad694b0000000000000001 | broach    | 192.168.0.73:56199 | test_app         | SELECT k, v FROM test.kv WHERE k = $1;      | UPSERT INTO test.kv(k, v) VALUES ($1, $2); | 2017-08-10 14:08:22.878048+00:00 | 2017-08-10 14:08:44.655709+00:00 | NULL                                 
-|       3 | 1340rd8813ad694b0000000000000001 | broach    | 192.168.0.73:56196 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878166+00:00 | 2017-08-10 14:08:44.647464+00:00 | aded7717-94e1-4ac4-9d37-8765e3418e32
-|       1 | 1230ab8813ad694b0000000000000001 | lroach    | 192.168.0.71:56180 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.87337+00:00  | 2017-08-10 14:08:44.64788+00:00  | f691c5dd-b29e-48ed-a1dd-6d7f71faa82e
-|       1 | 15234d8813ad694b0000000000000001 | lroach    | 192.168.0.71:56197 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.877932+00:00 | 2017-08-10 14:08:44.644786+00:00 | 86ae25ea-9abf-4f5e-ad96-0522178f4ce6
-|       1 | 14605d8813ad694b0000000000000001 | lroach    | 192.168.0.71:56200 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878534+00:00 | 2017-08-10 14:08:44.653524+00:00 | 8ad972b6-4347-4128-9e52-8553f3491963
-|       1 | 1965lh8813ad694b0000000000000001 | root      | 127.0.0.1:56211    | cockroach        | SHOW CLUSTER SESSIONS;                      |                                            | 2017-08-10 14:08:27.666826+00:00 | 2017-08-10 14:08:44.653355+00:00 | NULL                                 
-+---------+----------------------------------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------+----------------------------------+----------------------------------|--------------------------------------+
-(9 rows)
-~~~
-
-Alternatively, you can use `SHOW SESSIONS` to receive the same response.
-
-### List active sessions on the local node
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW LOCAL SESSIONS;
-~~~
-
-~~~
-+---------+----------------------------------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------|----------------------------------+----------------------------------+--------------------------------------+
-| node_id |            session_id            | user_name |   client_address   | application_name |               active_queries                |            last_active_query               |          session_start           |        oldest_query_start        |                kv_txn                |
-+---------+----------------------------------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------+----------------------------------+----------------------------------+--------------------------------------|
-|       1 | 1230ab8813ad694b0000000000000001 | lroach    | 192.168.0.71:56180 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.87337+00:00  | 2017-08-10 14:08:44.64788+00:00  | f691c5dd-b29e-48ed-a1dd-6d7f71faa82e |
-|       1 | 15234d8813ad694b0000000000000001 | lroach    | 192.168.0.71:56197 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.877932+00:00 | 2017-08-10 14:08:44.644786+00:00 | 86ae25ea-9abf-4f5e-ad96-0522178f4ce6 |
-|       1 | 14605d8813ad694b0000000000000001 | lroach    | 192.168.0.71:56200 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878534+00:00 | 2017-08-10 14:08:44.653524+00:00 | 8ad972b6-4347-4128-9e52-8553f3491963 |
-|       1 | 1965lh8813ad694b0000000000000001 | root      | 127.0.0.1:56211    | cockroach        | SHOW CLUSTER SESSIONS;                      |                                            | 2017-08-10 14:08:27.666826+00:00 | 2017-08-10 14:08:44.653355+00:00 | NULL                                 |
-+---------+----------------------------------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------+----------------------------------+----------------------------------|--------------------------------------+
-(4 rows)
-~~~
-
-### Filter for specific sessions
-
-You can use a [`SELECT`](select-clause.html) statement to filter the list of currently active sessions by one or more of the [response fields](#response).
-
-#### Show sessions associated with a specific user
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER SESSIONS] WHERE user_name = 'mroach';
-~~~
-
-~~~
-+---------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------|----------------------------------+----------------------------------+--------------------------------------+
-| node_id | user_name |   client_address   | application_name |               active_queries                |            last_active_query               |          session_start           |        oldest_query_start        |                kv_txn                |
-+---------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------+----------------------------------+----------------------------------+--------------------------------------|
-|       2 | mroach    | 192.168.0.72:56194 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878113+00:00 | 2017-08-10 14:08:44.648985+00:00 | 81fbdd4d-394c-4784-b540-97cd73910dba |
-|       2 | mroach    | 192.168.0.72:56201 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878306+00:00 | 2017-08-10 14:08:44.653135+00:00 | 5aa6f141-5cae-468f-b16a-dfe8d4fb4bea |
-|       2 | mroach    | 192.168.0.72:56198 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878464+00:00 | 2017-08-10 14:08:44.643749+00:00 | d8fedb88-fc21-4720-aabe-cd43ec204d88 |
-+---------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------+----------------------------------+----------------------------------|--------------------------------------+
-(3 rows)
-~~~
-
-#### Exclude sessions from the built-in SQL client
-
-To exclude sessions from the [built-in SQL client](cockroach-sql.html), filter for sessions that do not show `cockroach` as the `application_name`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER SESSIONS]
-      WHERE application_name != 'cockroach';
-~~~
-
-~~~
-+---------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------|----------------------------------+----------------------------------+--------------------------------------+
-| node_id | user_name |   client_address   | application_name |               active_queries                |            last_active_query               |          session_start           |        oldest_query_start        |                kv_txn                
-+---------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------+----------------------------------+----------------------------------+--------------------------------------|
-|       2 | mroach    | 192.168.0.72:56194 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878113+00:00 | 2017-08-10 14:08:44.648985+00:00 | 81fbdd4d-394c-4784-b540-97cd73910dba
-|       2 | mroach    | 192.168.0.72:56201 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878306+00:00 | 2017-08-10 14:08:44.653135+00:00 | 5aa6f141-5cae-468f-b16a-dfe8d4fb4bea
-|       2 | mroach    | 192.168.0.72:56198 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878464+00:00 | 2017-08-10 14:08:44.643749+00:00 | d8fedb88-fc21-4720-aabe-cd43ec204d88
-|       3 | broach    | 192.168.0.73:56199 | test_app         | SELECT k, v FROM test.kv WHERE k = $1;      | UPSERT INTO test.kv(k, v) VALUES ($1, $2); | 2017-08-10 14:08:22.878048+00:00 | 2017-08-10 14:08:44.655709+00:00 | NULL                                 
-|       3 | broach    | 192.168.0.73:56196 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878166+00:00 | 2017-08-10 14:08:44.647464+00:00 | aded7717-94e1-4ac4-9d37-8765e3418e32
-|       1 | lroach    | 192.168.0.71:56180 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.87337+00:00  | 2017-08-10 14:08:44.64788+00:00  | f691c5dd-b29e-48ed-a1dd-6d7f71faa82e
-|       1 | lroach    | 192.168.0.71:56197 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.877932+00:00 | 2017-08-10 14:08:44.644786+00:00 | 86ae25ea-9abf-4f5e-ad96-0522178f4ce6
-|       1 | lroach    | 192.168.0.71:56200 | test_app         | UPSERT INTO test.kv(k, v) VALUES ($1, $2);  | SELECT k, v FROM test.kv WHERE k = $1;     | 2017-08-10 14:08:22.878534+00:00 | 2017-08-10 14:08:44.653524+00:00 | 8ad972b6-4347-4128-9e52-8553f3491963
-+---------+-----------+--------------------+------------------+---------------------------------------------+--------------------------------------------+----------------------------------+----------------------------------|--------------------------------------+
-(8 rows)
-~~~
-
-### Identify and cancel a problematic query
-
-If a session has been open for a long time and you are concerned that the oldest active SQL query may be problematic, you can use the [`SHOW QUERIES`](show-queries.html) statement to further investigate the query and then, if necessary, use the [`CANCEL QUERY`](cancel-query.html) statement to cancel it.
-
-For example, let's say you run `SHOW SESSIONS` and notice that the following session has been open for more than 2 hours:
-
-~~~
-+---------+----------+--------------------+------------------+------------------------------------+--------------------|----------------------------------+----------------------------------+--------+
-| node_id | user_name |   client_address   | application_name |           active_queries           | last_active_query  |          session_start           |        oldest_query_start        | kv_txn
-+---------+-----------+--------------------+------------------+------------------------------------+--------------------+----------------------------------+----------------------------------|--------+
-|       2 | mroach    | 192.168.0.72:56194 | test_app         | SELECT * FROM test.kv ORDER BY k;  |                    | 2017-08-10 14:08:22.878113+00:00 | 2017-08-10 14:08:22.878113+00:00 | NULL   
-+---------+-----------+--------------------+------------------+------------------------------------+--------------------|----------------------------------+----------------------------------+--------+
-~~~
-
-Since the `oldest_query_start` timestamp is the same as the `session_start` timestamp, you are concerned that the `SELECT` query shown in `active_queries` has been running for too long and may be consuming too many resources. So you use the [`SHOW QUERIES`](show-queries.html) statement to get more information about the query, filtering based on details you already have:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER QUERIES]
-      WHERE client_address = '192.168.0.72:56194'
-          AND user_name = 'mroach'
-          AND query = 'SELECT * FROM test.kv ORDER BY k';
-~~~
-
-~~~
-+----------------------------------+---------+-----------+----------------------------------+----------------------------------+--------------------+------------------+-------------+-----------+
-|             query_id             | node_id | user_name |              start               |              query               |   client_address   | application_name | distributed |   phase   |
-+----------------------------------+---------+-----------+----------------------------------+----------------------------------+--------------------+------------------+-------------+-----------+
-| 14dacc1f9a781e3d0000000000000001 |       2 | mroach    | 2017-08-10 14:08:22.878113+00:00 | SELECT * FROM test.kv ORDER BY k | 192.168.0.72:56194 | test_app         | false       | executing |
-+----------------------------------+---------+-----------+----------------------------------+----------------------------------+--------------------+------------------+-------------+-----------+
-~~~
-
-Using the `start` field, you confirm that the query has been running since the start of the session and decide that is too long. So to cancel the query, and stop it from consuming resources, you note the `query_id` and use it with the [`CANCEL QUERY`](cancel-query.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL QUERY '14dacc1f9a781e3d0000000000000001';
-~~~
-
-Alternatively, if you know that you want to cancel the query based on the details in `SHOW SESSIONS`, you could execute a single [`CANCEL QUERY`](cancel-query.html) statement with a nested `SELECT` statement that returns the `query_id`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL QUERY (SELECT query_id FROM [SHOW CLUSTER QUERIES]
-      WHERE client_address = '192.168.0.72:56194'
-          AND user_name = 'mroach'
-          AND query = 'SELECT * FROM test.kv ORDER BY k');
-~~~
-
-## See also
-
-- [`SHOW QUERIES`](show-queries.html)
-- [`CANCEL QUERY`](cancel-query.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-statistics.md b/src/current/v20.2/show-statistics.md
deleted file mode 100644
index 0cb8a8a07bf..00000000000
--- a/src/current/v20.2/show-statistics.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: SHOW STATISTICS
-summary: The SHOW STATISTICS statement lists table statistics.
-toc: true
----
-The `SHOW STATISTICS` [statement](sql-statements.html) lists [table statistics](create-statistics.html) used by the [cost-based optimizer](cost-based-optimizer.html).
-
-{{site.data.alerts.callout_info}}
-[By default, CockroachDB automatically generates statistics](cost-based-optimizer.html#table-statistics) on all indexed columns, and up to 100 non-indexed columns.
-
-<span class="version-tag">New in v20.2:</span> CockroachDB also automatically collects [multi-column statistics](create-statistics.html#create-statistics-on-multiple-columns) on the columns that prefix each index.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_stats.html %}
-</div>
-
-## Required Privileges
-
-No [privileges](authorization.html#assign-privileges) are required to list table statistics.
-
-## Parameters
-
-Parameter      | Description
----------------+---------------
-`table_name`   | The name of the table you want to view statistics for.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### List table statistics
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW STATISTICS FOR TABLE rides;
-~~~
-
-~~~
-  statistics_name |       column_names        |             created              | row_count | distinct_count | null_count |    histogram_id
-------------------+---------------------------+----------------------------------+-----------+----------------+------------+---------------------
-  __auto__        | {city}                    | 2020-08-26 16:55:24.725089+00:00 |       500 |              9 |          0 | 584550071425531905
-  __auto__        | {id}                      | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071432740865
-  __auto__        | {city,id}                 | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 |               NULL
-  __auto__        | {rider_id}                | 2020-08-26 16:55:24.725089+00:00 |       500 |             50 |          0 | 584550071446732801
-  __auto__        | {city,rider_id}           | 2020-08-26 16:55:24.725089+00:00 |       500 |             50 |          0 |               NULL
-  __auto__        | {vehicle_city}            | 2020-08-26 16:55:24.725089+00:00 |       500 |              9 |          0 | 584550071461019649
-  __auto__        | {vehicle_id}              | 2020-08-26 16:55:24.725089+00:00 |       500 |             15 |          0 | 584550071467966465
-  __auto__        | {vehicle_city,vehicle_id} | 2020-08-26 16:55:24.725089+00:00 |       500 |             15 |          0 |               NULL
-  __auto__        | {start_address}           | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071482122241
-  __auto__        | {end_address}             | 2020-08-26 16:55:24.725089+00:00 |       500 |            500 |          0 | 584550071489167361
-  __auto__        | {start_time}              | 2020-08-26 16:55:24.725089+00:00 |       500 |             30 |          0 | 584550071496671233
-  __auto__        | {end_time}                | 2020-08-26 16:55:24.725089+00:00 |       500 |            367 |          0 | 584550071504437249
-  __auto__        | {revenue}                 | 2020-08-26 16:55:24.725089+00:00 |       500 |            100 |          0 | 584550071512137729
-(13 rows)
-~~~
-
-### Delete statistics
-
-{% include {{ page.version.version }}/misc/delete-statistics.md %}
-
-## See Also
-
-- [Cost-Based Optimizer](cost-based-optimizer.html)
-- [`CREATE STATISTICS`](create-statistics.html)
-- [`CREATE TABLE`](create-table.html)
-- [`INSERT`](insert.html)
-- [`IMPORT`](import.html)
-- [SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-tables.md b/src/current/v20.2/show-tables.md
deleted file mode 100644
index 64d0d4e1274..00000000000
--- a/src/current/v20.2/show-tables.md
+++ /dev/null
@@ -1,225 +0,0 @@
----
-title: SHOW TABLES
-summary: The SHOW TABLES statement lists the tables in a schema or database.
-keywords: reflection
-toc: true
----
-
-The `SHOW TABLES` [statement](sql-statements.html) lists the schema, table name, table type, owner, and estimated row count for the tables or [views](views.html) in a schema or database.
-
-{{site.data.alerts.callout_success}}
-Estimating the number of rows in a table costs resources. To improve the performance of `SHOW TABLES` queries, disable row-count estimation by setting the `sql.show_tables.estimated_row_count.enabled` [cluster setting](cluster-settings.html) to `false` before executing a `SHOW TABLES` statement.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-While a table or view is being [dropped](drop-table.html), `SHOW TABLES` will list the object with a `(dropped)` suffix.
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_tables.html %}
-</div>
-
-## Required privileges
-
-The `SELECT` [privilege](authorization.html#assign-privileges) on a table is required to list it with `SHOW TABLES`.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`database_name` | The name of the database for which to show tables.
-`schema_name` | The name of the schema for which to show tables.
-
-When a `database_name` and `schema_name` are omitted, the tables of the [current schema](sql-name-resolution.html#current-schema) in the [current database](sql-name-resolution.html#current-database) are listed.
-
-`SHOW TABLES` will attempt to find a schema with the specified name first. If that fails, it will try to find a database with that name instead, and list the tables of its `public` schema. For more details, see [Name Resolution](sql-name-resolution.html).
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Show tables in the current database
-
-`SHOW TABLES` uses the [current schema](sql-name-resolution.html#current-schema) `public` set by default in `search_path`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-Alternatively, within the built-in SQL shell, you can use the `\dt` [shell command](cockroach-sql.html#commands):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \dt
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count
---------------+----------------------------+-------+----------------------
-  public      | promo_codes                | table |                1000
-  public      | rides                      | table |                 500
-  public      | user_promo_codes           | table |                   0
-  public      | users                      | table |                  50
-  public      | vehicle_location_histories | table |                1000
-  public      | vehicles                   | table |                  15
-(6 rows)
-~~~
-
-### Show tables in a different schema
-
-You can show the tables in schemas other than the current schema. You can also show the schema by table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr.information_schema;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM information_schema;
-~~~
-
-Because `movr` is the current database, these statements return the same output:
-
-~~~
-     schema_name     |            table_name             | type  | estimated_row_count
----------------------+-----------------------------------+-------+----------------------
-  information_schema | administrable_role_authorizations | table |                NULL
-  information_schema | applicable_roles                  | table |                NULL
-  information_schema | check_constraints                 | table |                NULL
-  information_schema | column_privileges                 | table |                NULL
-  ...
-(23 rows)
-~~~
-
-
-### Show tables in a different database
-
-You can also show tables from a different database.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM system.public;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM system;
-~~~
-
-Because `public` is the current schema, these statements return the same output:
-
-~~~
-  schema_name |           table_name            | type  | estimated_row_count
---------------+---------------------------------+-------+----------------------
-  public      | comments                        | table |                NULL
-  public      | descriptor                      | table |                NULL
-  public      | eventlog                        | table |                NULL
-  public      | jobs                            | table |                NULL
-  ...
-(29 rows)
-~~~
-
-### Show user-defined tables with comments
-
-You can use [`COMMENT ON`](comment-on.html) to add comments on a table.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> COMMENT ON TABLE users IS 'This table contains information about users.';
-~~~
-
-To view a table's comments:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM movr WITH COMMENT;
-~~~
-
-~~~
-  schema_name |         table_name         | type  | estimated_row_count |                   comment
---------------+----------------------------+-------+---------------------+-----------------------------------------------
-  public      | promo_codes                | table |                1000 |
-  public      | rides                      | table |                 500 |
-  public      | user_promo_codes           | table |                   0 |
-  public      | users                      | table |                  50 | This table contains information about users.
-  public      | vehicle_location_histories | table |                1000 |
-  public      | vehicles                   | table |                  15 |
-(6 rows)
-~~~
-
- You can also view comments on a table with [`SHOW CREATE`](show-create.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                             create_statement
--------------+---------------------------------------------------------------------------
-  users      | CREATE TABLE users (
-             |     id UUID NOT NULL,
-             |     city VARCHAR NOT NULL,
-             |     name VARCHAR NULL,
-             |     address VARCHAR NULL,
-             |     credit_card VARCHAR NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address, credit_card)
-             | );
-             | COMMENT ON TABLE users IS 'This table contains information about users.'
-(1 row)
-~~~
-
-For more information, see [`COMMENT ON`](comment-on.html).
-
-### Show virtual tables with comments
-
-The virtual tables in the `pg_catalog`, `information_schema`, and `crdb_internal` schemas contain useful comments, often with links to further documentation.
-
-To view virtual tables with comments and documentation links, use `SHOW TABLES FROM <virtual schema> WITH COMMENT`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM information_schema WITH COMMENT;
-~~~
-
-~~~
-     schema_name     |            table_name             | type  | estimated_row_count |                                                              comment
----------------------+-----------------------------------+-------+---------------------+-------------------------------------------------------------------------------------------------------------------------------------
-  information_schema | administrable_role_authorizations | table |                NULL | roles for which the current user has admin option
-                     |                                   |       |                     | https://www.cockroachlabs.com/docs/v20.2/information-schema.html#administrable_role_authorizations
-                     |                                   |       |                     | https://www.postgresql.org/docs/9.5/infoschema-administrable-role-authorizations.html
-  information_schema | applicable_roles                  | table |                NULL | roles available to the current user
-                     |                                   |       |                     | https://www.cockroachlabs.com/docs/v20.2/information-schema.html#applicable_roles
-                     |                                   |       |                     | https://www.postgresql.org/docs/9.5/infoschema-applicable-roles.html
-  information_schema | check_constraints                 | table |                NULL | check constraints
-                     |                                   |       |                     | https://www.cockroachlabs.com/docs/v20.2/information-schema.html#check_constraints
-                     |                                   |       |                     | https://www.postgresql.org/docs/9.5/infoschema-check-constraints.html
-...
-(23 rows)
-~~~
-
-## See also
-
-- [`SHOW DATABASES`](show-databases.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [`CREATE TABLE`](create-table.html)
-- [`CREATE VIEW`](create-view.html)
-- [`COMMENT ON`](comment-on.html)
-- [Information Schema](information-schema.html)
diff --git a/src/current/v20.2/show-trace.md b/src/current/v20.2/show-trace.md
deleted file mode 100644
index 14c8ed6274c..00000000000
--- a/src/current/v20.2/show-trace.md
+++ /dev/null
@@ -1,220 +0,0 @@
----
-title: SHOW TRACE FOR SESSION
-summary: The SHOW TRACE FOR SESSION statement returns details about how CockroachDB executed a statement or series of statements recorded during a session.
-toc: true
----
-
-The `SHOW TRACE FOR SESSION` [statement](sql-statements.html) returns details about how CockroachDB executed a statement or series of statements recorded during a session. These details include messages and timing information from all nodes involved in the execution, providing visibility into the actions taken by CockroachDB across all of its software layers.
-
-You can use `SHOW TRACE FOR SESSION` to debug why a query is not performing as expected, to add more information to bug reports, or to generally learn more about how CockroachDB works.
-
-{{site.data.alerts.callout_info}}
-Statement traces can be obtained in plaintext, JSON, and [Jaeger-compatible](query-behavior-troubleshooting.html#visualize-statement-traces-in-jaeger) formats by activating [statement diagnostics](ui-statements-page.html#diagnostics) on the DB Console Statements Page or running [`EXPLAIN ANALYZE (DEBUG)`](explain-analyze.html#debug-option).
-{{site.data.alerts.end}}
-
-## Usage overview
-
-`SHOW TRACE FOR SESSION` returns messages and timing information for all statements recorded during a session. It's important to note the following:
-
-- `SHOW TRACE FOR SESSION` only returns the most recently recorded traces, or for a currently active recording of traces.
-    - To start recording traces during a session, enable the `tracing` session variable via [`SET tracing = on;`](set-vars.html#set-tracing).
-    - To stop recording traces during a session, disable the `tracing` session variable via [`SET tracing = off;`](set-vars.html#set-tracing).
-
-- Recording traces during a session does not effect the execution of any statements traced. This means that errors encountered by statements during a recording are returned to clients. CockroachDB will [automatically retry](transactions.html#automatic-retries) individual statements (considered implicit transactions) and multi-statement transactions sent as a single batch when [retry errors](transactions.html#error-handling) are encountered due to contention. Also, clients will receive retry errors required to handle [client-side retries](transactions.html#client-side-intervention). As a result, traces of all transaction retries will be captured during a recording.
-
-
-## Required privileges
-
-For `SHOW TRACE FOR SESSION`, no privileges are required.
-
-## Syntax
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_trace.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`COMPACT` | If specified, fewer columns are returned by the statement. See [Response](#response) for more details.
-`KV` | If specified, the returned messages are restricted to those describing requests to and responses from the underlying key-value [storage layer](architecture/storage-layer.html), including per-result-row messages.<br><br>For `SHOW KV TRACE FOR SESSION`, per-result-row messages are included only if the session was/is recording with `SET tracing = kv;`.
-
-## Trace description
-
-CockroachDB's definition of a "trace" is a specialization of [OpenTracing's](https://opentracing.io/docs/overview/what-is-tracing/#what-is-opentracing) definition. Internally, CockroachDB uses OpenTracing libraries for tracing, which also means that
-it can be easily integrated with OpenTracing-compatible trace collectors; for example, [Jaeger](query-behavior-troubleshooting.html#visualize-statement-traces-in-jaeger), Lightstep, and Zipkin are already supported.
-
-Concept | Description
---------|------------
-**trace** | Information about the sub-operations performed as part of a high-level operation (a query or a transaction). This information is internally represented as a tree of "spans", with a special "root span" representing a whole SQL transaction in the case of `SHOW TRACE FOR SESSION`.
-**span** | A named, timed operation that describes a contiguous segment of work in a trace. Each span links to "child spans", representing sub-operations; their children would be sub-sub-operations of the grandparent span, etc.<br><br>Different spans can represent (sub-)operations that executed either sequentially or in parallel with respect to each other. (This possibly-parallel nature of execution is one of the important things that a trace is supposed to describe.) The operations described by a trace may be _distributed_, that is, different spans may describe operations executed by different nodes.
-**message** | A string with timing information. Each span can contain a list of these. They are produced by CockroachDB's logging infrastructure and are the same messages that can be found in node [log files](debug-and-error-logs.html) except that a trace contains message across all severity levels, whereas log files, by default, do not. Thus, a trace is much more verbose than logs but only contains messages produced in the context of one particular traced operation.
-
-To further clarify these concepts, let's look at a visualization of a trace for one statement. This particular trace is [visualized by Jaeger](query-behavior-troubleshooting.html#visualize-statement-traces-in-jaeger). The image shows spans and log messages. You can see names of operations and sub-operations, along with parent-child relationships and timing information, and it's easy to see which operations are executed in parallel.
-
-<img src="{{ 'images/v20.2/jaeger-trace-log-messages.png' | relative_url }}" alt="Jaeger Trace Log Messages" style="border:1px solid #eee;max-width:100%" />
-
-## Response
-
-{{site.data.alerts.callout_info}}The format of the <code>SHOW TRACE FOR SESSION</code> response may change in future versions.{{site.data.alerts.end}}
-
-CockroachDB outputs traces in linear tabular format. Each result row represents either a span start (identified by the `=== SPAN START: <operation> ===` message) or a log message from a span. Rows are generally listed in their timestamp order (i.e., the order in which the events they represent occurred) with the exception that messages from child spans are interleaved in the parent span according to their timing. Messages from sibling spans, however, are not interleaved with respect to one another.
-
-The following diagram shows the order in which messages from different spans would be interleaved in an example trace. Each box is a span; inner-boxes are child spans. The numbers indicate the order in which the log messages would appear in the virtual table.
-
-~~~
- +-----------------------+
- |           1           |
- | +-------------------+ |
- | |         2         | |
- | |  +----+           | |
- | |  |    | +----+    | |
- | |  | 3  | | 4  |    | |
- | |  |    | |    |  5 | |
- | |  |    | |    | ++ | |
- | |  +----+ |    |    | |
- | |         +----+    | |
- | |          6        | |
- | +-------------------+ |
- |            7          |
- +-----------------------+
-~~~
-
-Each row contains the following columns:
-
-Column | Type | Description
--------|------|------------
-`timestamp` | timestamptz | The absolute time when the message occurred.
-`age` | interval | The age of the message relative to the beginning of the trace (i.e., the beginning of the statement execution in the case of `SHOW TRACE FOR <stmt>` and the beginning of the recording in the case of `SHOW TRACE FOR SESSION`.
-`message` | string | The log message.
-`tag` | string | Meta-information about the message's context. This is the same information that appears in the beginning of log file messages in between square brackets (e.g, `[client=[::1]:49985,user=root,n1]`).
-`location` | string | The file:line location of the line of code that produced the message. Only some of the messages have this field set; it depends on specifically how the message was logged. The `--vmodule` flag passed to the node producing the message also affects what rows get this field populated. Generally, if `--vmodule=<file>=<level>` is specified, messages produced by that file will have the field populated.
-`operation` | string | The name of the operation (or sub-operation) on whose behalf the message was logged.
-`span` | int | The index of the span within the virtual list of all spans if they were ordered by the span's start time.
-
-{{site.data.alerts.callout_info}}If the <code>COMPACT</code> keyword was specified, only the <code>age</code>, <code>message</code>, <code>tag</code> and <code>operation</code> columns are returned. In addition, the value of the <code>location</code> columns is prepended to <code>message</code>.{{site.data.alerts.end}}
-
-## Examples
-
-### Trace a session
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET tracing = on;
-~~~
-
-~~~
-SET TRACING
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TRACE FOR SESSION;
-~~~
-
-~~~
-             timestamp             |       age       |                                                                                                                                  message                                                                                                                                  |                      tag                      |               location               |     operation     | span
------------------------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+-----------------------------------------------+--------------------------------------+-------------------+-------
-  2021-04-13 20:09:03.617303+00:00 | 00:00:00        | === SPAN START: session recording ===                                                                                                                                                                                                                                     |                                               |                                      | session recording |    0
-  2021-04-13 20:09:03.617312+00:00 | 00:00:00.000009 | === SPAN START: sync ===                                                                                                                                                                                                                                                  |                                               |                                      | sync              |    1
-  2021-04-13 20:09:03.617465+00:00 | 00:00:00.000162 | [NoTxn pos:13] executing Sync                                                                                                                                                                                                                                             | [n1,client=127.0.0.1:61283,hostssl,user=root] | sql/conn_executor.go:1428            | sync              |    1
-  2021-04-13 20:09:03.617794+00:00 | 00:00:00.000491 | === SPAN START: exec stmt ===                                                                                                                                                                                                                                             |                                               |                                      | exec stmt         |    2
-  2021-04-13 20:09:03.617836+00:00 | 00:00:00.000533 | [NoTxn pos:14] executing ExecStmt: SHOW LAST QUERY STATISTICS                                                                                                                                                                                                             | [n1,client=127.0.0.1:61283,hostssl,user=root] | sql/conn_executor.go:1428            | exec stmt         |    2
-  2021-04-13 20:09:03.617875+00:00 | 00:00:00.000572 | executing: SHOW LAST QUERY STATISTICS in state: NoTxn                                                                                                                                                                                                                     | [n1,client=127.0.0.1:61283,hostssl,user=root] | sql/conn_executor_exec.go:70         | exec stmt         |    2
-...
-
-(66 rows)
-~~~
-
-### Trace conflicting transactions
-
-In this example, we use two terminals concurrently to generate conflicting transactions.
-
-1. In terminal 1, create a table:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE t (k INT);
-    ~~~
-
-2. Still in terminal 1, open a transaction and perform a write without closing the transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO t VALUES (1);
-    ~~~
-
-    Press enter one more time to send these statements to the server.
-
-3. In terminal 2, turn tracing on:
-
-    ~~~
-    > SET tracing = on;
-    ~~~
-
-4.  Still in terminal 2, execute a conflicting read:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM t;
-    ~~~
-
-    You'll see that this statement is blocked until the transaction in terminal 1 finishes.
-
-4. Back in terminal 1, finish the transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > COMMIT;
-    ~~~
-
-5. In terminal 2, you'll see the completed read:
-
-    ~~~
-      k
-    -----
-      1
-    (1 row)
-    ~~~
-
-6. Still in terminal 2, stop tracing and then view the completed trace:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET tracing = off;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW TRACE FOR SESSION;
-    ~~~
-
-    ~~~
-                  timestamp             |       age       |                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        message                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        |                            tag                             |                         location                          |             operation             | span
-     -----------------------------------+-----------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+------------------------------------------------------------+-----------------------------------------------------------+-----------------------------------+-------
-       2021-04-13 20:10:51.981766+00:00 | 00:00:00        | === SPAN START: session recording ===                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |                                                            |                                                           | session recording                 |    0
-       2021-04-13 20:10:51.981828+00:00 | 00:00:00.000062 | === SPAN START: sync ===                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |                                                            |                                                           | sync                              |    1
-       2021-04-13 20:10:51.981933+00:00 | 00:00:00.000167 | [NoTxn pos:13] executing Sync                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         | [n1,client=127.0.0.1:61293,hostssl,user=root]              | sql/conn_executor.go:1428                                 | sync                              |    1
-       2021-04-13 20:10:51.982373+00:00 | 00:00:00.000607 | === SPAN START: exec stmt ===                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |                                                            |                                                           | exec stmt                         |    2
-       2021-04-13 20:10:51.982438+00:00 | 00:00:00.000672 | [NoTxn pos:14] executing ExecStmt: SHOW LAST QUERY STATISTICS                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         | [n1,client=127.0.0.1:61293,hostssl,user=root]              | sql/conn_executor.go:1428                                 | exec stmt                         |    2
-       2021-04-13 20:10:51.982467+00:00 | 00:00:00.000701 | executing: SHOW LAST QUERY STATISTICS in state: NoTxn                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 | [n1,client=127.0.0.1:61293,hostssl,user=root]              | sql/conn_executor_exec.go:70                              | exec stmt                         |    2
-       2021-04-13 20:10:51.982514+00:00 | 00:00:00.000748 | === SPAN START: sync ===                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |                                                            |                                                           | sync                              |    3
-       2021-04-13 20:10:51.982533+00:00 | 00:00:00.000767 | [NoTxn pos:15] executing Sync                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         | [n1,client=127.0.0.1:61293,hostssl,user=root]              | sql/conn_executor.go:1428                                 | sync                              |    3
-       2021-04-13 20:10:51.982977+00:00 | 00:00:00.001211 | === SPAN START: exec stmt ===                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                         |                                                            |                                                           | exec stmt                         |    4
-       2021-04-13 20:10:51.983035+00:00 | 00:00:00.001269 | [NoTxn pos:16] executing ExecStmt: SHOW TRANSACTION STATUS                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            | [n1,client=127.0.0.1:61293,hostssl,user=root]              | sql/conn_executor.go:1428                                 | exec stmt                         |    4
-       2021-04-13 20:10:51.983055+00:00 | 00:00:00.001289 | executing: SHOW TRANSACTION STATUS in state: NoTxn                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    | [n1,client=127.0.0.1:61293,hostssl,user=root]              | sql/conn_executor_exec.go:70                              | exec stmt                         |    4
-       2021-04-13 20:10:51.983066+00:00 | 00:00:00.0013   | === SPAN START: sync ===                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              |                                                            |                                                           | sync                              |    5
-...
-(210 rows)
-    ~~~
-
-## See also
-
-- [`EXPLAIN`](explain.html)
-- [`SET (session settings)`](set-vars.html)
diff --git a/src/current/v20.2/show-transactions.md b/src/current/v20.2/show-transactions.md
deleted file mode 100644
index b757a445118..00000000000
--- a/src/current/v20.2/show-transactions.md
+++ /dev/null
@@ -1,115 +0,0 @@
----
-title: SHOW TRANSACTIONS
-summary: The SHOW TRANSACTIONS statement lists all currently active transactions across the cluster or on the gateway node.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `SHOW TRANSACTIONS` [statement](sql-statements.html) lists details about currently active transactions, including:
-
-- The node running the transaction
-- The application that initiated the transaction
-- The number of statements that have been executed on the transaction
-- The number of times the transaction was retried (both manually and by the SQL executor)
-
-These details let you monitor the overall state of transactions and identify those that may need further investigation or adjustment.
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to execute this statement. However, note that non-`admin` users see only their own currently active transactions, whereas the `admin` users see all users' currently active transactions.
-
-## Syntax
-
-~~~
-SHOW [ALL] [CLUSTER | LOCAL] TRANSACTIONS
-~~~
-
-- To list the active transactions across all nodes of the cluster, use `SHOW TRANSACTIONS` or `SHOW CLUSTER TRANSACTIONS`.
-- To list the active transactions just on the gateway node, use `SHOW LOCAL TRANSACTIONS`.
-- To list internal transactions (that are issued by the database itself), use `SHOW ALL .. TRANSACTIONS`.
-
-## Response
-
-The following fields are returned for each transaction:
-
- Field             | Description
--------------------+---------------------------------------
-`node_id`          | The ID of the node running the transaction.
-`txn_id`           | The ID of the transaction.
-`application_name` | The [application name](set-vars.html#supported-variables) specified by the client, if any. For transactions from the [built-in SQL client](cockroach-sql.html), this will be `$ cockroach sql`.
-`num_stmts`        | The number of statements that have been executed on the transaction.
-`num_retries`      | The number of times that the transaction was retried.
-`num_auto_retries` | The number of times that the transaction was automatically retried by the SQL executor.
-
-## Examples
-
-### List active transactions across the cluster
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER TRANSACTIONS;
-~~~
-
-~~~
-  node_id |                txn_id                | application_name | num_stmts | num_retries | num_auto_retries
-----------+--------------------------------------+------------------+-----------+-------------+-------------------
-        1 | 1f02ca1c-46c8-491b-8048-daa6b38fc587 | $ cockroach sql  |         1 |           0 |                0
-        2 | 3af3f2e3-d0ed-4fd4-886b-1f5fc67b397d | movr             |         1 |           0 |                0
-(2 rows)
-~~~
-
-Alternatively, you can use `SHOW TRANSACTIONS` to receive the same response.
-
-### List active transactions on the gateway node
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW LOCAL TRANSACTIONS;
-~~~
-
-~~~
-  node_id |                txn_id                | application_name | num_stmts | num_retries | num_auto_retries
-----------+--------------------------------------+------------------+-----------+-------------+-------------------
-        1 | 1f02ca1c-46c8-491b-8048-daa6b38fc587 | $ cockroach sql  |         1 |           0 |                0
-(1 row)
-~~~
-
-### Filter for specific transactions
-
-You can use a [`SELECT`](select-clause.html) statement to filter the list of currently active transactions by one or more of the [response fields](#response).
-
-#### Show transactions associated with a specific application
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER TRANSACTIONS] WHERE application_name = 'movr';
-
-~~~
-
-~~~
-  node_id |                txn_id                | application_name | num_stmts | num_retries | num_auto_retries
-----------+--------------------------------------+------------------+-----------+-------------+-------------------
-        1 | 59891000-260a-44f6-abf9-59c94fefc081 | movr             |         1 |           0 |                0
-(1 row)
-~~~
-
-#### Exclude transactions from the built-in SQL client
-
-To exclude transactions from the [built-in SQL client](cockroach-sql.html), filter for transactions that do not show `$ cockroach sql` as the `application_name`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM [SHOW CLUSTER TRANSACTIONS]
-      WHERE application_name != '$ cockroach sql';
-~~~
-
-~~~
-  node_id |                txn_id                | application_name | num_stmts | num_retries | num_auto_retries
-----------+--------------------------------------+------------------+-----------+-------------+-------------------
-        1 | 8851060b-5e7c-4402-a8cd-487baa63e02e | movr             |         1 |           0 |                0
-(1 row)
-~~~
-
-## See also
-
-- [Transactions](transactions.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/show-types.md b/src/current/v20.2/show-types.md
deleted file mode 100644
index f76fe132d14..00000000000
--- a/src/current/v20.2/show-types.md
+++ /dev/null
@@ -1,55 +0,0 @@
----
-title: SHOW TYPES
-summary: The SHOW TYPES statement lists the user-defined data types in a database.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> The `SHOW TYPES` statement lists the user-defined [data types](data-types.html) in the current database.
-
-{{site.data.alerts.callout_info}}
-CockroachDB currently only supports [enumerated user-defined types](enum.html). As a result, [`SHOW ENUMS`](show-enums.html) and `SHOW TYPES` return the same results.
-{{site.data.alerts.end}}
-
-## Syntax
-
-~~~
-SHOW TYPES
-~~~
-
-## Required privileges
-
-The `SELECT` [privilege](authorization.html#assign-privileges) on the database is required to list any user-defined types in the database.
-
-## Examples
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE weekday AS ENUM ('monday', 'tuesday', 'wednesday', 'thursday', 'friday');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TYPE weekend AS ENUM ('sunday', 'saturday');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TYPES;
-~~~
-
-~~~
-  schema |  name   |                  value
----------+---------+-------------------------------------------
-  public | weekday | monday|tuesday|wednesday|thursday|friday
-  public | weekend | sunday|saturday
-(2 rows)
-~~~
-
-
-## See also
-
-- [`ENUM`](enum.html)
-- [Data types](data-types.html)
-- [`CREATE TYPE`](create-type.html)
-- [`ALTER TYPE`](alter-type.html)
-- [`DROP TYPE`](drop-type.html)
diff --git a/src/current/v20.2/show-users.md b/src/current/v20.2/show-users.md
deleted file mode 100644
index 481ff0926bb..00000000000
--- a/src/current/v20.2/show-users.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: SHOW USERS
-summary: The SHOW USERS statement lists the users for all databases.
-toc: true
----
-
-The `SHOW USERS` [statement](sql-statements.html) lists the users for all databases.
-
-{{site.data.alerts.callout_info}}
- Since the keywords `ROLES` and `USERS` can now be used interchangeably in SQL statements for enhanced Postgres compatibility, `SHOW USERS` is now an alias for [`SHOW ROLES`](show-roles.html).
-{{site.data.alerts.end}}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_users.html %}
-</div>
-
-## Required privileges
-
-The user must have the [`SELECT`](select-clause.html) [privilege](authorization.html#assign-privileges) on the `system.users` and `system.role_members` tables.
-
-## Example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW USERS;
-~~~
-
-~~~
-  username |  options   | member_of
------------+------------+------------
-  admin    | CREATEROLE | {}
-  carl     | NOLOGIN    | {}
-  petee    |            | {}
-  root     | CREATEROLE | {admin}
-(4 rows)
-~~~
-
-Alternatively, within the built-in SQL shell, you can use the `\du` [shell command](cockroach-sql.html#commands):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> \du
-~~~
-
-~~~
-  username |  options   | member_of
------------+------------+------------
-  admin    | CREATEROLE | {}
-  carl     | NOLOGIN    | {}
-  petee    |            | {}
-  root     | CREATEROLE | {admin}
-(4 rows)
-~~~
-
-## See also
-
-- [`CREATE USER`](create-user.html)
-- [Manage Users](authorization.html#create-and-manage-users)
diff --git a/src/current/v20.2/show-vars.md b/src/current/v20.2/show-vars.md
deleted file mode 100644
index 6866b4d71ec..00000000000
--- a/src/current/v20.2/show-vars.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: SHOW (session settings)
-summary: The SHOW statement displays the current settings for the client session.
-toc: true
----
-
-The `SHOW` [statement](sql-statements.html) can display the value of either one or all of
-the session setting variables. Some of these can also be configured via [`SET`](set-vars.html).
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to display the session settings.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/show_var.html %}
-</div>
-
-{{site.data.alerts.callout_info}}The <code>SHOW</code> statement for session settings is unrelated to the other <code>SHOW</code> statements: <a href="cluster-settings.html#view-current-cluster-settings"><code>SHOW CLUSTER SETTING</code></a>, <a href="show-create.html"><code>SHOW CREATE</code></a>, <a href="show-users.html"><code>SHOW USERS</code></a>, <a href="show-databases.html"><code>SHOW DATABASES</code></a>, <a href="show-columns.html"><code>SHOW COLUMNS</code></a>, <a href="show-grants.html"><code>SHOW GRANTS</code></a>, and <a href="show-constraints.html"><code>SHOW CONSTRAINTS</code></a>.{{site.data.alerts.end}}
-
-## Parameters
-
-The `SHOW <session variable>` statement accepts a single parameter: the variable name.
-
-The variable name is case insensitive. It may be enclosed in double quotes; this is useful if the variable name itself contains spaces.
-
-### Supported variables
-
-{% include {{ page.version.version }}/misc/session-vars.html %}
-
-For session variables on experimental features, see [Experimental Features](experimental-features.html).
-
-Special syntax cases supported for compatibility:
-
- Syntax | Equivalent to
---------|---------------
-`SHOW TRANSACTION PRIORITY` | `SHOW "transaction priority"`
-`SHOW TRANSACTION ISOLATION LEVEL` | `SHOW "transaction isolation level"`
-`SHOW TIME ZONE` | `SHOW "timezone"`
-`SHOW TRANSACTION STATUS` | `SHOW "transaction status"`
-
-## Examples
-
-### Showing the value of a single session variable
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW DATABASE;
-~~~
-
-~~~
-  database
-------------
-  movr
-(1 row)
-~~~
-
-### Showing the value of all session variables
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ALL;
-~~~
-
-~~~
-       variable       |      value
-----------------------+-------------------
-  application_name    | $ cockroach demo
-  bytea_output        | hex
-  client_encoding     | UTF8
-  client_min_messages | notice
-...
-~~~
-
-## See also
-
-- [`SET` (session variable)](set-vars.html)
-- [Transactions](transactions.html), including [Priority levels](transactions.html#transaction-priorities)
-- [`SHOW CLUSTER SETTING`](show-cluster-setting.html)
-- [`SHOW COLUMNS`](show-columns.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`SHOW CREATE`](show-create.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`SHOW GRANTS`](show-grants.html)
-- [`SHOW INDEX`](show-index.html)
-- [`SHOW USERS`](show-users.html)
diff --git a/src/current/v20.2/show-zone-configurations.md b/src/current/v20.2/show-zone-configurations.md
deleted file mode 100644
index 5533685d971..00000000000
--- a/src/current/v20.2/show-zone-configurations.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: SHOW ZONE CONFIGURATIONS
-summary: Use the SHOW ZONE CONFIGURATIONS statement to list details about existing replication zones.
-toc: true
----
-
-Use the `SHOW ZONE CONFIGURATIONS` [statement](sql-statements.html) to view details about existing [replication zones](configure-replication-zones.html).
-
-## Synopsis
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/show_zone.html %}
-</div>
-
-## Required privileges
-
-No [privileges](authorization.html#assign-privileges) are required to list replication zones.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`zone_name` | The name of the system [range](architecture/overview.html#glossary) for which to show [replication zone configurations](configure-replication-zones.html).
-`database_name` | The name of the [database](create-database.html) for which to show [replication zone configurations](configure-replication-zones.html).
-`table_name` | The name of the [table](create-table.html) for which to show [replication zone configurations](configure-replication-zones.html).
-`partition_name` | The name of the [partition](partitioning.html) for which to show [replication zone configurations](configure-replication-zones.html).
-`index_name` | The name of the [index](indexes.html) for which to show [replication zone configurations](configure-replication-zones.html).
-
-## Examples
-
-{% include {{ page.version.version }}/sql/movr-statements-geo-partitioned-replicas.md %}
-
-### View all replication zones
-
-{% include {{ page.version.version }}/zone-configs/view-all-replication-zones.md %}
-
-### View the default replication zone for the cluster
-
-{% include {{ page.version.version }}/zone-configs/view-the-default-replication-zone.md %}
-
-### View the replication zone for a database
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-database.md %}
-
-### View the replication zone for a table
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-table.md %}
-
-You can also use [`SHOW CREATE TABLE`](show-create.html) to view zone configurations for a table. If a table is partitioned, but no zones are configured, the `SHOW CREATE TABLE` output includes a warning.
-
-### View the replication zone for an index
-
-To control replication for a specific table,  use the `ALTER INDEX ... CONFIGURE ZONE` statement to define the relevant values (other values will be inherited from the parent zone):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX vehicles@vehicles_auto_index_fk_city_ref_users CONFIGURE ZONE USING num_replicas = 5, gc.ttlseconds = 100000;
-~~~
-
-~~~
-CONFIGURE ZONE 1
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW ZONE CONFIGURATION FOR INDEX vehicles@vehicles_auto_index_fk_city_ref_users;
-~~~
-
-~~~
-                         target                        |                                 raw_config_sql
-+------------------------------------------------------+---------------------------------------------------------------------------------+
-  INDEX vehicles@vehicles_auto_index_fk_city_ref_users | ALTER INDEX vehicles@vehicles_auto_index_fk_city_ref_users CONFIGURE ZONE USING
-                                                       |     range_min_bytes = 134217728,
-                                                       |     range_max_bytes = 536870912,
-                                                       |     gc.ttlseconds = 100000,
-                                                       |     num_replicas = 5,
-                                                       |     constraints = '[]',
-                                                       |     lease_preferences = '[]'
-(1 row)
-~~~
-
-### View the replication zone for a partition
-
-{% include {{ page.version.version }}/zone-configs/create-a-replication-zone-for-a-table-partition.md %}
-
-## See also
-
-- [Configure Replication Zones](configure-replication-zones.html)
-- [`CONFIGURE ZONE`](configure-zone.html)
-- [`ALTER DATABASE`](alter-database.html)
-- [`ALTER INDEX`](alter-index.html)
-- [`ALTER RANGE`](alter-range.html)
-- [`ALTER TABLE`](alter-table.html)
-- [SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/spatial-data.md b/src/current/v20.2/spatial-data.md
deleted file mode 100644
index 57b1ddefca5..00000000000
--- a/src/current/v20.2/spatial-data.md
+++ /dev/null
@@ -1,183 +0,0 @@
----
-title: Working with Spatial Data
-summary: CockroachDB has special support for efficiently storing and querying spatial data.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-This page provides information about working with spatial data in CockroachDB.
-
-## Supported data types
-
-Supported [spatial](spatial-features.html) data types include:
-
-- Geometric objects such as [points](point.html), [lines](linestring.html), and [polygons](polygon.html) in 2-dimensional space. These are projected onto the flat surface of a plane and are represented in SQL by the `GEOMETRY` data type.
-
-- Geographic objects, which are also made up of [points](point.html), [lines](linestring.html), [polygons](polygon.html), etc., in 2-dimensional space. They are projected onto the surface of a sphere and are represented in SQL by the `GEOGRAPHY` data type. (Technically, they are projected onto a spheroid: "a sphere with a bulge"). The spheroid projection means that:
-
-    - The X and Y coordinates of 2-dimensional points are actually Longitude and Latitude values.
-    - The paths between geographic objects are not straight lines; they are curves, and so the distances between objects are calculated using [great circle math](https://en.wikipedia.org/wiki/Great-circle_distance).
-
-## Compatibility
-
-Just as CockroachDB strives for [Postgres compatibility](postgresql-compatibility.html), our spatial data support is designed to be as compatible as possible with the functionality provided by the [PostGIS](https://postgis.net) extension.
-
-However, we do not yet implement the full list of PostGIS built-in functions and operators. Also, our [spatial indexing works differently](spatial-indexes.html) (see the [Performance](#performance) section below). For a list of the spatial functions we support, see [Geospatial functions](functions-and-operators.html#spatial-functions).
-
-If your application needs support for functions that are not yet implemented, please check out [our meta-issue for built-in function support on GitHub](https://github.com/cockroachdb/cockroach/issues/49203), which describes how to find an issue for the built-in function(s) you need.
-
-For a list of other known limitations, see [Known Limitations](known-limitations.html#spatial-support-limitations).
-
-### ORM compatibility
-
-The following ORM spatial libraries are fully compatible with CockroachDB's spatial features:
-
-- [Hibernate Spatial](https://docs.jboss.org/hibernate/orm/current/userguide/html_single/Hibernate_User_Guide.html#spatial)
-
-    [Hibernate 5.4.30.Final](https://in.relation.to/2021/03/19/hibernate-orm-5430-final-release/) added the `CockroachDB202SpatialDialect` dialect to the `hibernate-spatial` module. The `CockroachDB202SpatialDialect` dialect supports spatial features available in CockroachDB v20.2 and later.
-
-- [RGeo/RGeo-ActiveRecord](https://github.com/rgeo/rgeo-activerecord)
-
-    CockroachDB's ActiveRecord adapter ([`activerecord-cockroachdb-adapter`](https://github.com/cockroachdb/activerecord-cockroachdb-adapter)) uses [RGeo](https://github.com/rgeo/rgeo) and [RGeo-ActiveRecord](https://github.com/rgeo/rgeo-activerecord) for spatial support with ActiveRecord v5.2.2+ and v6.0.0+. For information about using CockroachDB spatial features with ActiveRecord, see the [`activerecord-cockroachdb-adapter` README](https://github.com/cockroachdb/activerecord-cockroachdb-adapter#working-with-spatial-data).
-
-- [GeoDjango](https://github.com/cockroachdb/django-cockroachdb#gis-support)
-
-    Starting with CockroachDB 20.2.x and [`django-cockroachdb`](https://github.com/cockroachdb/django-cockroachdb) 3.1.3, CockroachDB is compatible with [GeoDjango](https://docs.djangoproject.com/en/3.1/ref/contrib/gis/). For information about using CockroachDB spatial features with GeoDjango, see the [`django-cockroachdb` README](https://github.com/cockroachdb/django-cockroachdb#gis-support).
-
-{{site.data.alerts.callout_info}}
-Most PostGIS-compatible client libraries are incompatible with CockroachDB's spatial features without an adapter.
-{{site.data.alerts.end}}
-
-## Troubleshooting
-
-For general CockroachDB troubleshooting information, see [this troubleshooting overview](troubleshooting-overview.html).
-
-If you need help troubleshooting an issue with our spatial support, please get in touch using our [Support resources](support-resources.html).
-
-## Performance
-
-In order to avoid full table scans, make sure to add [indexes](spatial-indexes.html) to any columns that are accessed as part of a predicate in the [`WHERE`](select-clause.html#filter-on-a-single-condition) clause. For geospatial columns, the index will only be used if the column is accessed using an index-accelerated geospatial function from the list below (all of these functions work on `GEOMETRY` data types; a `*` means that a function also works on `GEOGRAPHY` data types):
-
-- [`ST_Covers`](st_covers.html) (*)
-- [`ST_CoveredBy`](st_coveredby.html) (*)
-- [`ST_Contains`](st_contains.html)
-- `ST_ContainsProperly`
-- `ST_Crosses`
-- `ST_DWithin` (*)
-- `ST_DFullyWithin`
-- [`ST_Equals`](st_equals.html)
-- [`ST_Intersects`](st_intersects.html) (*)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_Within`](st_within.html)
-
-To use a version of a function from the list above that will explicitly *not* use the index, add an underscore (`_`) to the beginning of the function name, e.g., [`_ST_Covers`](st_covers.html).
-
-You can check which queries are using which indexes using the [`EXPLAIN`](explain.html) statement. For more information about general query tuning (including index usage), see [Optimize Query Performance](make-queries-fast.html).
-
-The syntax for adding an [index](spatial-indexes.html) to a geometry column is `CREATE INDEX index_name ON table_name USING GIST (column_name)`.
-
-For example, to add an index to the `geom` column of the [sample `tornadoes` table](migrate-from-shapefiles.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX tornado_geom_idx ON tornadoes USING GIST (geom);
-~~~
-
-This creates a (spatial) [GIN index](inverted-indexes.html) on the `geom` column.
-
-Because CockroachDB is a scale-out, multi-node database, our spatial indexing strategy is based on a [space-filling curve](https://en.wikipedia.org/wiki/Space-filling_curve)/quad-tree design (also known as "divide the space"), rather than the [R-Tree](https://en.wikipedia.org/wiki/R-tree) data structure used by some other spatial databases (also known as "divide the objects"). Other databases that use a "divide the space" strategy include Microsoft SQL Server and MongoDB.
-
-For more detailed information about how CockroachDB's spatial indexes work, see [Spatial indexes](spatial-indexes.html).
-
-If you encounter behavior that you think is due to a performance issue, please get in touch using our [Support resources](support-resources.html).
-
-## Example: Load NYC data for the PostGIS tutorial
-
-Follow the steps below to load the SQL for the NYC data used in the [Introduction to PostGIS](https://postgis.net/workshops/postgis-intro/) tutorial.
-
-{{site.data.alerts.callout_info}}
-CockroachDB can work with the tutorial up to Chapter 22, with the following exceptions:
-
-- Do not try to load Shapefiles via the GUI as shown in the tutorial. Instead, follow the steps below to load the SQL data directly into CockroachDB. (We have already converted the tutorial Shapefiles to SQL for you.)
-- We do not support GML or KML data.
-- We do not support SVG.
-{{site.data.alerts.end}}
-
-### Before you begin
-
-- Install a build of CockroachDB with support for spatial data by following the instructions at [Install CockroachDB](install-cockroachdb.html).
-
-- [Start a local insecure cluster](start-a-local-cluster.html) and connect to that cluster from a [SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    cockroach sql --insecure --host=localhost --port=26257
-    ~~~
-
-    Leave this shell open for use in the examples below.
-
-### Step 1. Load the NYC data
-
-Clone the data set:
-
-{% include copy-clipboard.html %}
-~~~ shell
-git clone https://github.com/otan-cockroach/otan-scripts
-~~~
-
-Load the SQL files into your CockroachDB cluster:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cat otan-scripts/geospatial_sql/*.sql | cockroach sql --insecure --host=localhost --port=26257
-~~~
-
-The command above will take a few minutes to run.
-
-### Step 2. Follow the PostGIS tutorial
-
-When the cluster is finished loading the data, open a SQL shell and start working through the [Introduction to PostGIS](https://postgis.net/workshops/postgis-intro/) tutorial:
-
-{% include copy-clipboard.html %}
-~~~ shell
-cockroach sql --insecure --host=localhost --port=26257
-~~~
-
-## See also
-
-- [Install CockroachDB](install-cockroachdb.html)
-- [Spatial Features](spatial-features.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial & GIS Glossary of Terms](spatial-glossary.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Well known text](well-known-text.html)
-- [Well known binary](well-known-binary.html)
-- [GeoJSON](geojson.html)
-- [SRID 4326 - longitude and latitude](srid-4326.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_Union`](st_union.html)
-- [`ST_Within`](st_within.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
-- [Troubleshooting overview](troubleshooting-overview.html)
-- [Support resources](support-resources.html)
diff --git a/src/current/v20.2/spatial-features.md b/src/current/v20.2/spatial-features.md
deleted file mode 100644
index 55c924a8548..00000000000
--- a/src/current/v20.2/spatial-features.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: Spatial Features
-summary: A summary of CockroachDB's support for storing and querying spatial data.
-toc: true
----
-
-<span class="version-tag">New in v20.2</span>: CockroachDB supports efficiently storing and querying spatial data.
-
-See the links below for more information about how to use CockroachDB for spatial use cases.
-
-## Getting Started
-
-- [Install CockroachDB](install-cockroachdb.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial tutorial](spatial-tutorial.html)
-
-## Migrating spatial data into and out of CockroachDB
-
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Export Spatial Data](export-spatial-data.html)
-
-## Reference
-
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Known Limitations](known-limitations.html#spatial-support-limitations)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [Client library compatibility](spatial-data.html#compatibility)
-
-### Spatial objects
-
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-
-### Data representations
-
-- [Well known text](well-known-text.html)
-- [Well known binary](well-known-binary.html)
-- [GeoJSON](geojson.html)
-- [SRID 4326 - longitude and latitude](srid-4326.html)
-
-### Spatial functions
-
-In addition to the [generated reference documentation for spatial functions](functions-and-operators.html#spatial-functions), we have written additional documentation for the following functions, including examples:
-
-- [`ST_Contains`](st_contains.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_Union`](st_union.html)
-- [`ST_Within`](st_within.html)
-
-## See also
-
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/spatial-glossary.md b/src/current/v20.2/spatial-glossary.md
deleted file mode 100644
index 539184cdaba..00000000000
--- a/src/current/v20.2/spatial-glossary.md
+++ /dev/null
@@ -1,229 +0,0 @@
----
-title: Spatial and GIS Glossary of Terms
-summary: A summary of CockroachDB's support for storing and querying spatial data.
-toc: true
----
-
-This page contains a glossary of terms common to spatial databases and geographic information systems (GIS). Where possible, we provide links to further information.
-
-{{site.data.alerts.callout_info}}
-This page is provided for reference purposes only. The inclusion of a term in this glossary does not imply that CockroachDB has support for any feature(s) related to that term. For more information about the specific spatial and GIS features supported by CockroachDB, see [Working with Spatial Data](spatial-data.html).
-{{site.data.alerts.end}}
-
-## Geometry Terms
-
-<a name="bounding-box"></a>
-
-- _Bounding box_: Given a set of points, a bounding box is the smallest rectangle that encloses all of the points in the set. Due to edge cases in how geographic points are mapped to [cartographic projections](#cartographic-projection), a bounding box for a given set of points may be larger than expected.
-
-<a name="spheroid"></a>
-
-- _Spheroid_: A spheroid (also known as an ellipsoid) is essentially a "slightly squished" sphere. Spheroids are used to represent almost-but-not-quite spherical objects. For example, a spheroid is used to represent the Earth in the [World Geodetic System](#wgs84) standard.
-
-<a name="cartographic-projection"></a>
-
-- _Cartographic projection_: A cartographic projection, or map projection, is the process used to represent 3-dimensional (or higher) data on a 2-dimensional surface. This is usually related to how we might display 3-dimensional shapes represented in a database by the [`GEOGRAPHY` data type](#geography) on the surface of a map, which is a flat plane. For more information, see the GIS Lounge article [What is a Map Projection?](https://www.gislounge.com/map-projection/) by Caitlin Dempsey.
-
-<a name="covering"></a>
-
-- _Covering_: The covering of a shape _A_ is a set of locations (in CockroachDB, [S2 cell IDs](#s2)) that comprise another shape _B_ such that no points of _A_ lie outside of _B_.
-
-<a name="geocoder"></a>
-
-- _Geocoder_: Takes an address or the name of a place, and returns latitude and longitude coordinates. For more information, see [the wikipedia article on Geocoding](https://en.wikipedia.org/wiki/Geocoding).
-
-<a name="nearest-neighbor-search"></a>
-
-- _Nearest-neighbor search_: Given a starting point on a map and a set of search criteria, find the specified number of points nearest the starting point that meet the criteria. For example, a nearest-neighbor search can be used to answer the question, "What are the 10 closest [Waffle House restaurants](https://www.wafflehouse.com) to my current location?"  This is also sometimes referred to as "_k_ nearest-neighbor" search.
-
-<a name="srid"></a>
-
-- _SRID_: The Spatial Referencing System Identifier (a.k.a. SRID) is used to tell which spatial reference system will be used to interpret each spatial object. A [commonly used SRID is 4326](srid-4326.html), which represents spatial data using longitude and latitude coordinates on the Earth's surface as defined in the [WGS84](#wgs84) standard.
-
-<a name="spatial-reference-system"></a>
-
-- _Spatial reference system_: Used to define what a spatial object "means". For example, a spatial object could use [geographic](#geography) coordinates using latitude and longitude, or a [geometry](#geometry) projection using points with X,Y coordinates in a 2-dimensional plane.
-
-## Data types
-
-<a name="geometry"></a>
-
-- `GEOMETRY`: Used to represent shapes relative to 2-, 3-, or higher-dimensional plane geometry.
-
-<a name="geography"></a>
-
-- `GEOGRAPHY`: Used to represent shapes relative to locations on the Earth's [spheroidal](#spheroid) surface.
-
-## Data Formats
-
-<a name="ewkt"></a>
-
-
-<a name="wkt"></a>
-
-- _WKT_: The "Well Known Text" data format is a convenient human-readable notation for representing [spatial objects](#spatial-objects). For example a 2-dimensional point object with x- and y-coordinates is represented in WKT as `POINT(123,456)`. This format is defined by the [OGC](#ogc). For more information, see the [Well Known Text](well-known-text.html) documentation.
-
-- _EWKT_: The "Extended Well Known Text" data format extends [WKT](#wkt) by prepending an [SRID](#srid) to the shape's description.  For more information, see the [Well Known Text](well-known-text.html#ewkt) documentation.
-
-<a name="ewkb"></a>
-
-
-<a name="wkb"></a>
-
-- _WKB_: The "Well Known Binary" data format is a convenient machine-readable binary representation for [spatial objects](#spatial-objects). For efficiency, an application may choose to use this data format, but humans may prefer to read [WKT](#wkt). This format is defined by the [OGC](#ogc).  For more information, see [Well Known Binary](well-known-binary.html).
-
-- _EWKB_: The "Extended Well Known Binary" data format extends [WKB](#wkb) by prepending [SRID](#srid) information to the shape's description.  For more information, see [Well Known Binary](well-known-binary.html#ewkb).
-
-## Organizations
-
-<a name="osgeo"></a>
-
-- _OSGeo_: The Open Source Geospatial Foundation. For more information, see <https://www.osgeo.org>.
-
-<a name="ogc"></a>
-
-- _OGC_: The [Open Geospatial Consortium](https://www.ogc.org) was formerly known as the "Open GIS Consortium". The organization is still referred to colloquially as "OpenGIS" in many places online. The OGC is a consortium of businesses, government agencies, universities, etc., described as "a worldwide community committed to improving access to geospatial (location) information."
-
-<a name="mapbox"></a>
-
-- _MapBox_: A company providing a location data platform for mobile and web applications. For more information, see <https://www.mapbox.com/>.
-
-<a name="esri"></a>
-
-- _Esri_: A company providing "location intelligence" services. Esri develops spatial and [GIS](#gis) software, including the popular [ArcGIS](#arcgis) package. For more information about Esri, see <https://www.esri.com>.
-
-## Industry Standards
-
-<a name="sql-mm"></a>
-
-- _SQL/MM_: The SQL Multimedia Applications specification. The part of this standard that applies to SQL geospatial data types is defined in [part 3 of the ISO/IEC 13249 document](https://www.iso.org/standard/60343.html). For a freely available paper discussing the geospatial data types and functions defined by the standard, see the (PDF) paper [SQL/MM Spatial: The Standard to Manage Spatial Data in Relational Database Systems](http://doesen0.informatik.uni-leipzig.de/proceedings/paper/68.pdf), by Knut Stolze.
-
-<a name="wgs84"></a>
-
-- _WGS84_: The latest revision of the [World Geodetic System](http://wiki.gis.com/wiki/index.php/World_Geodetic_System) standard (from 1984 CE), which defines a standard spheroidal reference system for mapping the Earth. See also: [spheroid](#spheroid), [cartographic projection](#cartographic-projection).
-
-<a name="de-9IM"></a>
-
-- _DE-9IM_: The [Dimensionally Extended nine-Intersection Model (DE-9IM)](https://en.wikipedia.org/wiki/DE-9IM) defines a method that uses a 3x3 matrix to determine whether two shapes (1) touch along a boundary, (2), intersect (overlap), or (3) are equal to each other - that is, they are the same shape that covers the same area. This notation is used by the `ST_Relate` built-in function. Almost all other spatial predicate functions can be logically implemented using this model. However, in practice, most are not, and `ST_Relate` is reserved for advanced use cases.
-
-## File Formats
-
-<a name="shapefile"></a>
-
-- _Shapefile_: A spatial data file format developed by [Esri](#esri) and used by [GIS](#gis) software for storing geospatial data. It can be automatically converted to SQL by tools like [shp2pgsql](https://manpages.debian.org/stretch/postgis/shp2pgsql.1.en.html) for use by a database that can run spatial queries.
-
-<a name="vector-file"></a>
-
-- _Vector file_: A file format that uses a non-pixel-based, abstract coordinate representation for geospatial data. Because it is abstract and not tied to pixels, the vector format is scalable. The motivation is similar to that behind the [Scalable Vector Graphics (SVG)](https://en.wikipedia.org/wiki/Scalable_Vector_Graphics) image format: scaling the image up or down does not reveal any "jaggedness" (due to loss of information) such as might be revealed by a pixel representation. However, vector files are usually much larger in size and more expensive (in terms of CPU, memory, and disk) to work with than [Raster files](#raster-file).
-
-<a name="raster-file"></a>
-
-- _Raster file_: A file format that uses a non-scalable, pixel-based representation for geospatial data. Raster files are smaller and generally faster to read, write, or generate than [Vector files](#vector-file). However, raster files have inferior image quality and/or accuracy when compared to vector files: they can appear "jagged" due to the reduced information available when compared to vector files.
-
-<a name="geojson"></a>
-
-- _GeoJSON_: A format for encoding geometric and geographic data as [JSON](https://www.json.org). For more information, see [GeoJSON](geojson.html).
-
-## Software and Code Libraries
-
-<a name="gis"></a>
-
-- _GIS_: A "Geographic Information System" (or GIS) is used to store geographic information in a computer for processing and interaction by humans and/or other software. Some systems provide graphical "point and click" user interfaces, and some are embedded in programming languages or data query languages like SQL. For example, CockroachDB versions 20.2 and later provide support for [executing spatial queries from SQL](spatial-data.html).
-
-<a name="arcgis"></a>
-
-- _ArcGIS_: A commercial [GIS](#gis) software package developed by the location intelligence company [Esri](#esri). For more information, see Esri's [ArcGIS overview](https://www.esri.com/en-us/arcgis/about-arcgis/overview).
-
-<a name="postgis"></a>
-
-- _PostGIS_: An extension to the [Postgres](https://postgresql.org/) database that adds support for geospatial queries. For more information, see [postgis.net](https://postgis.net).
-
-<a name="geos"></a>
-
-- _GEOS_: An open source geometry library used by CockroachDB, [PostGIS](#postgis), and other projects to provide the calculations underlying various spatial predicate functions and operators. For more information, see <http://trac.osgeo.org/geos/>.
-
-<a name="geographiclib"></a>
-
-- _GeographicLib_: A C++ library for performing various geographic and other calculations used by CockroachDB and other projects. For more information, see <https://geographiclib.sourceforge.io>.
-
-<a name="gdal"></a>
-
-- _GDAL_: A Geospatial Data Abstraction Library used to provide support for many types of [raster file formats](#raster-file). Used in [PostGIS](#postgis). For more information, see <https://www.gdal.org/>.
-
-<a name="proj"></a>
-
-- _PROJ_: A [cartographic projection](#cartographic-projection) library. Used by CockroachDB and other projects. For more information, see <https://proj.org/>.
-
-<a name="geobuf"></a>
-
-- _GeoBuf_: A compact binary encoding developed by [MapBox](#mapbox) that provides nearly lossless compression of [GeoJSON](#geojson) data into [protocol buffers](https://developers.google.com/protocol-buffers/). For more information, see <https://github.com/mapbox/geobuf>.
-
-<a name="cgal"></a>
-
-- _CGAL_: The computational geometry algorithms library. For more information, see <https://www.cgal.org>.
-
-<a name="sfcgal"></a>
-
-- _SFCGAL_: A C++ wrapper library around [CGAL](#cgal). For more information, see <http://www.sfcgal.org>.
-
-<a name="tiger"></a>
-
-- _TIGER_: The "Topographically Integrated Geographic Encoding and Referencing System" released by the [U.S. Census Bureau](https://www.census.gov/programs-surveys/geography/guidance/tiger-data-products-guide.html).
-
-<a name="s2"></a>
-
-- _S2_: The [S2 Geometry Library](http://s2geometry.io) is a C++ code library for performing spherical geometry computations.  It models a sphere using a [quadtree](https://en.wikipedia.org/wiki/Quadtree) "divide the space" approach, and is used by CockroachDB.
-
-## Spatial objects
-
-This section has information about the representation of geometric and geographic "shapes" according to the [SQL/MM](#sql-mm) standard.
-
-<a name="point"></a>
-
-- _Point_: A point is a sizeless location identified by its X and Y coordinates. These coordinates are then translated according to the [spatial reference system](#spatial-reference-system) to determine what the point "is", or what it "means" relative to the other geometric objects (if any) in the data set. A point can be created in SQL by the `ST_Point()` function.
-
-<a name="linestring"></a>
-
-- _LineString_: A linestring is a collection of [points](#point) that are "strung together" into one geometric object, like a necklace. If the "necklace" were "closed", it could also represent a [polygon](#polygon). A linestring can also be used to represent an arbitrary curve, such as a [Bézier curve](https://en.wikipedia.org/wiki/Bézier_curve).
-
-<a name="polygon"></a>
-
-- _Polygon_: A polygon is a closed shape that can be made up of straight or curved lines. It can be thought of as a "closed" [linestring](#linestring). Irregular polygons can take on almost any arbitrary shape. Common regular polygons include: squares, rectangles, hexagons, and so forth. For more information about regular polygons, see the ['Regular polygon' Wikipedia article](https://en.wikipedia.org/wiki/Regular_polygon).
-
-<a name="geometrycollection"></a>
-
-- _GeometryCollection_: A geometry collection is a "box" or "bag" used for gathering 1 or more of the other types of objects defined above into a collection: namely, points, linestrings, or polygons. In the particular case of SQL, it provides a way of referring to a group of spatial objects as one "thing" so that you can operate on it/them more conveniently, using various SQL functions.
-
-## Spatial System tables
-
-<a name="pg_extension"></a>
-
-- `pg_extension`: A table used by the Postgres database to store information about extensions to that database. Provided for compatibility by CockroachDB. For more information, see [the Postgres documentation](https://www.postgresql.org/docs/current/catalog-pg-extension.html).
-
-<a name="spatial_ref_sys"></a>
-
-- `spatial_ref_sys`: A SQL table defined by the [OGC](#ogc) that holds the list of [SRID](#srid)s supported by a database, e.g., `SELECT count(*) FROM spatial_ref_sys;`
-
-<a name="geometry_columns"></a>
-
-- `geometry_columns`: Used to list all of the columns in a database with the [`GEOMETRY`](#geometry) data type, e.g., `SELECT * from geometry_columns`.
-
-<a name="geography_columns"></a>
-
-- `geography_columns`: Used to list all of the columns in a database with the [`GEOGRAPHY`](#geography) data type, e.g., `SELECT * from geography_columns`.
-
-## See also
-
-- [Spatial Features](spatial-features.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Well known text](well-known-text.html)
-- [Well known binary](well-known-binary.html)
-- [GeoJSON](geojson.html)
-- [SRID 4326 - longitude and latitude](srid-4326.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/spatial-indexes.md b/src/current/v20.2/spatial-indexes.md
deleted file mode 100644
index a267e0a4882..00000000000
--- a/src/current/v20.2/spatial-indexes.md
+++ /dev/null
@@ -1,256 +0,0 @@
----
-title: Spatial Indexes
-summary: How CockroachDB uses spatial indexes for efficiently storing and querying spatial data.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-This page describes CockroachDB's support for indexing [spatial data](spatial-data.html), including:
-
-- What spatial indexes are
-- How they work
-- How to create and tune spatial indexes in CockroachDB
-
-{{site.data.alerts.callout_info}}
-CockroachDB does not support indexing geospatial types in default [primary keys](primary-key.html), nor in [unique secondary indexes](indexes.html#unique-secondary-indexes).
-{{site.data.alerts.end}}
-
-## What is a spatial index?
-
-At a high level, a spatial index is just like any other [index](indexes.html). Its purpose is to improve your database's performance by helping SQL locate data without having to look through every row of a table.
-
-Spatial indexes store information about spatial objects, but they are used for the same tasks as any other index type, i.e.:
-
-- Fast filtering of lists of shapes based on spatial predicate functions such as `ST_Contains`.
-
-- Speeding up joins that involve spatial data columns.
-
-Spatial indexes differ from other types of indexes as follows:
-
-- They are specialized to operate on 2-dimensional `GEOMETRY` and `GEOGRAPHY` data types. They are stored by CockroachDB as a special type of [GIN index](inverted-indexes.html). For more details, [see below](#details).
-
-- If needed, they can be tuned to store looser or tighter coverings of the shapes being indexed, depending on the needs of your application. Tighter coverings are more expensive to generate, store, and update, but can perform better in some cases because they return fewer false positives during the initial index lookup. Tighter coverings can also lead to worse performance due to more rows in the index, and more scans at the storage layer.  That's why we recommend that most users should not need to change the default settings. For more information, see [Tuning spatial indexes](#tuning-spatial-indexes) below.
-
-## How CockroachDB's spatial indexing works
-
-### Overview
-
-There are two main approaches to building geospatial indexes:
-
-- One approach is to "divide the objects" by inserting the objects into a tree (usually an [R-tree](https://en.wikipedia.org/wiki/R-tree)) whose shape depends on the data being indexed. This is the approach taken by [PostGIS](https://postgis.net).
-
-- The other approach is to "divide the space" by creating a decomposition of the space being indexed into buckets of various sizes.
-
-CockroachDB takes the "divide the space" approach to spatial indexing. This is necessary to preserve CockroachDB's ability to [scale horizontally](frequently-asked-questions.html#how-does-cockroachdb-scale) by [adding nodes to a running cluster](cockroach-start.html#add-a-node-to-a-cluster).
-
-CockroachDB uses the "divide the space" approach for the following reasons:
-
-- It's easy to scale horizontally.
-- It requires no balancing operations, unlike [R-tree indexes](https://en.wikipedia.org/wiki/R-tree).
-- Inserts under this approach require no locking.
-- Bulk ingest is simpler to implement than under other approaches.
-- It allows advanced users to make a per-object tradeoff between index size and false positives during index creation. (See [Tuning spatial indexes](#tuning-spatial-indexes) below.)
-
-Whichever approach to indexing is used, when an object is indexed, a "covering" shape (i.e., a bounding box) is constructed that completely encompasses the indexed object. Index queries work by looking for containment or intersection between the covering shape for the query object and the indexed covering shapes. This retrieves false positives but no false negatives.
-
-### Details
-
-Under the hood, CockroachDB uses the [S2 geometry library](https://s2geometry.io/) to divide the space being indexed into a [quadtree](https://en.wikipedia.org/wiki/Quadtree) data structure with a set number of levels and a data-independent shape. Each node in the quadtree (really, [S2 cell](https://s2geometry.io/devguide/s2cell_hierarchy.html)) represents some part of the indexed space and is divided once horizontally and once vertically to produce 4 child cells in the next level. The image below shows visually how a location (marked in red) is represented using levels of a quadtree:
-
-<img style="display: block; margin-left: auto; margin-right: auto; width: 50%" src="{{ 'images/v20.2/geospatial/quadtree.png' | relative_url }}" alt="Quadtree">
-
-Visually, you can think of the S2 library as enclosing a sphere in a cube. We map from points on each face of the cube to points on the face of the sphere. As you can see in the 2-dimensional picture below, there is a projection that occurs in this mapping: the lines entering from the left mark points on the cube face, and are "refracted" by the material of the cube face before touching the surface of the sphere. This projection reduces the distortion that would occur if the points on the cube face were projected straight onto the sphere.
-
-<img style="display: block; margin-left: auto; margin-right: auto; width: 50%" src="{{ 'images/v20.2/geospatial/s2-cubed-sphere-2d.png' | relative_url }}" alt="S2 Cubed Sphere - 2D">
-
-Next, let's look at a 3-dimensional image that shows the cube and sphere more clearly. Each cube face is mapped to the quadtree data structure mentioned above, and each node in the quadtree is numbered using a [Hilbert space-filling curve](https://en.wikipedia.org/wiki/Hilbert_curve) which preserves locality of reference. In the image below, you can imagine the points of the Hilbert curve on the rear face of the cube being projected onto the sphere in the center. The use of a space-filling curve means that two shapes that are near each other on the sphere are very likely to be near each other on the line that makes up the Hilbert curve. This is good for performance.
-
-<img style="display: block; margin-left: auto; margin-right: auto; width: 50%" src="{{ 'images/v20.2/geospatial/s2-cubed-sphere-3d.png' | relative_url }}" alt="S2 Cubed Sphere - 3D">
-
-When you index a spatial object, a covering is computed using some number of the cells in the quadtree. The number of covering cells can vary per indexed object by passing special arguments to `CREATE INDEX` that tell CockroachDB how many levels of S2 cells to use. The leaf nodes of the S2 quadtree are at level 30, and for `GEOGRAPHY` measure 1cm across the Earth's surface. By default, `GEOGRAPHY` indexes use up to level 30, and get this level of precision. We also use S2 cell coverings in a slightly different way for `GEOMETRY` indexes. The precision you get there is the bounding length of the `GEOMETRY` index divided by 4^30. For more information, see [Tuning spatial indexes](#tuning-spatial-indexes) below.
-
-CockroachDB stores spatial indexes as a special type of [GIN index](inverted-indexes.html). The spatial index maps from a location, which is a square cell in the quadtree, to one or more shapes whose [coverings](spatial-glossary.html#covering) include that location. Since a location can be used in the covering for multiple shapes, and each shape can have multiple locations in its covering, there is a many-to-many relationship between locations and shapes.
-
-## Tuning spatial indexes
-
-{{site.data.alerts.callout_danger}}
-The information in this section is for advanced users doing performance optimization. Most users should not need to change the default settings. Without careful testing, you can get worse performance by changing the default settings.
-{{site.data.alerts.end}}
-
-When an object is indexed, a "covering" shape (e.g., a bounding box) is constructed that completely encompasses the indexed object. Index queries work by looking for containment or intersection between the covering shape for the query object and the indexed covering shapes. This retrieves false positives but no false negatives.
-
-This leads to a tradeoff when creating spatial indexes. The number of cells used to represent an object in the index is tunable: fewer cells use less space, but create a looser covering. A looser covering retrieves a larger amount of false positives from the index, which is expensive because the exact answer computation that's run after the index query can be expensive. However, at some point the benefits of retrieving fewer false positives is outweighed by how long it takes to scan a large index.
-
-Another consideration is that the larger index created for a tighter covering is more expensive to scan and to update, especially for write-heavy workloads.
-
-We strongly recommend leaving your spatial indexes at the default settings unless you can take at least the following steps:
-
-1. Verify the coverings that will be generated meet your accuracy expectations by using the `st_s2covering` function as shown in [Viewing an object's S2 covering](#viewing-an-objects-s2-covering) below.
-2. Do extensive performance tests to make sure the indexes that use the non-default coverings actually provide a performance benefit.
-
-### Visualizing index coverings
-
-In what follows we will visualize how index coverings change as we change the `s2_max_cells` parameter, which determines how much work CockroachDB will perform to find a tight covering of a shape.
-
-We will generate coverings for the following geometry object, which describes a shape whose vertices land on some small cities in the Northeastern US:
-
-~~~
-'SRID=4326;LINESTRING(-76.4955 42.4405,  -75.6608 41.4102,-73.5422 41.052, -73.929 41.707, -76.4955 42.4405)'
-~~~
-
-The animated image below shows the S2 coverings that are generated as we increase the `s2_max_cells` parameter (described below) from the 1 to 30 (minimum to maximum):
-
-<img style="display: block; margin-left: auto; margin-right: auto; width: 50%" src="{{ 'images/v20.2/geospatial/s2-coverings.gif' | relative_url }}" alt="Animated GIF of S2 Coverings - Levels 1 to 30">
-
-Below are the same images presented in a grid. You can see that as we turn up the `s2_max_cells` parameter, more work is done by CockroachDB to discover a tighter and tighter covering (that is, a covering using more and smaller cells). The covering for this particular shape reaches a reasonable level of accuracy when `s2_max_cells` reaches 10, and stops improving much past 12.
-
-<img style="display: block; margin-left: auto; margin-right: auto; width: 50%" src="{{ 'images/v20.2/geospatial/s2-coverings-tiled.png' | relative_url }}" alt="Static image of S2 Coverings - Levels 1 to 30">
-
-### Index tuning parameters
-
-The following parameters are supported by both `CREATE INDEX` and the [built-in function](functions-and-operators.html#spatial-functions) `st_s2covering`. The latter is useful for seeing what kinds of coverings would be generated by an index with various tuning parameters if you were to create it. For an example showing how to use these parameters with `st_s2covering`, see [viewing an object's S2 covering](#viewing-an-objects-s2-covering) below.
-
-{{site.data.alerts.callout_info}}
-If a shape falls outside the bounding coordinates determined by the `geometry_*` settings below, there will be a performance loss in that such shapes may not be eliminated by the index lookup, but the database will still return the correct answers.
-{{site.data.alerts.end}}
-
-| Option           | Default value                                 | Description                                                                                                                                                                                                                                                                                                                                                                                                                                     |
-|------------------+-----------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| `s2_max_level`   | 30                                            | The maximum level of S2 cell used in the covering. Allowed values: 1-30. Setting it to less than the default means that CockroachDB will be forced to generate coverings using larger cells.                                                                                                                                                                                                                                                    |
-| `s2_max_cells`   | 4                                             | The maximum number of S2 cells used in the covering. Provides a limit on how much work is done exploring the possible coverings. Allowed values: 1-30. You may want to use higher values for odd-shaped regions such as skinny rectangles.                                                                                                                                                                                                      |
-| `geometry_min_x` | Derived from SRID bounds, else `-(1 << 31)`   | Minimum X-value of the [spatial reference system](spatial-glossary.html#spatial-reference-system) for the object(s) being covered. This only needs to be set if the default bounds of the SRID are too large/small for the given data, or SRID = 0 and you wish to use a smaller range (unfortunately this is currently not exposed, but is viewable on <https://epsg.io/3857>). By default, SRID = 0 assumes `[-min int32, max int32]` ranges. |
-| `geometry_max_x` | Derived from SRID bounds, else `(1 << 31) -1` | Maximum X-value of the [spatial reference system](spatial-glossary.html#spatial-reference-system) for the object(s) being covered. This only needs to be set if you are using a custom [SRID](spatial-glossary.html#srid).                                                                                                                                                                                                                      |
-| `geometry_min_y` | Derived from SRID bounds, else `-(1 << 31)`   | Minimum Y-value of the [spatial reference system](spatial-glossary.html#spatial-reference-system) for the object(s) being covered. This only needs to be set if you are using a custom [SRID](spatial-glossary.html#srid).                                                                                                                                                                                                                      |
-| `geometry_max_y` | Derived from SRID bounds, else `(1 << 31) -1` | Maximum Y-value of the [spatial reference system](spatial-glossary.html#spatial-reference-system) for the object(s) being covered. This only needs to be set if you are using a custom [SRID](spatial-glossary.html#srid).                                                                                                                                                                                                                      |
-
-## Examples
-
-### Viewing an object's S2 covering
-
-Here is an example showing how to pass the [spatial index tuning parameters](#index-tuning-parameters) to `st_s2covering`. It generates [GeoJSON](https://geojson.org) output showing both a shape and the S2 covering that would be generated for that shape in your index, if you passed the same parameters to `CREATE INDEX`. You can paste this output into [geojson.io](http://geojson.io) to see what it looks like.
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE tmp_viz (id INT8, geom GEOMETRY);
-
-INSERT INTO tmp_viz (id, geom)
-VALUES (1, st_geomfromtext('LINESTRING(-76.8261 42.1727,  -75.6608 41.4102,-73.5422 41.052, -73.929 41.707,  -76.8261 42.1727)'));
-
-INSERT INTO tmp_viz (id, geom) VALUES (2, st_s2covering(st_geomfromtext('LINESTRING(-76.8261 42.1727,  -75.6608 41.4102,-73.5422 41.052, -73.929 41.707,  -76.8261 42.1727)'), 's2_max_cells=20,s2_max_level=12,s2_level_mod=3,geometry_min_x=-180,geometry_max_x=180,geometry_min_y=-180,geometry_max_y=180'));
-
-SELECT ST_AsGeoJSON(st_collect(geom)) FROM tmp_viz;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ json
-{"type":"GeometryCollection","geometries":[{"type":"LineString","coordinates":[[-76.8261,42.1727],[-75.6608,41.4102],[-73.5422,41.052],[-73.929,41.707],[-76.8261,42.1727]]},{"type":"MultiPolygon","coordinates":[[[[-76.904296875,42.099609375],[-76.81640625,42.099609375],[-76.81640625,42.1875],[-76.904296875,42.1875],[-76.904296875,42.099609375]]],[[[-76.81640625,42.099609375],[-76.728515625,42.099609375],[-76.728515625,42.1875],[-76.81640625,42.1875],[-76.81640625,42.099609375]]],[[[-76.728515625,42.099609375],[-76.640625,42.099609375],[-76.640625,42.1875],[-76.728515625,42.1875],[-76.728515625,42.099609375]]],[[[-76.728515625,42.01171875],[-76.640625,42.01171875],[-76.640625,42.099609375],[-76.728515625,42.099609375],[-76.728515625,42.01171875]]],[[[-76.640625,41.484375],[-75.9375,41.484375],[-75.9375,42.1875],[-76.640625,42.1875],[-76.640625,41.484375]]],[[[-74.53125,40.78125],[-73.828125,40.78125],[-73.828125,41.484375],[-74.53125,41.484375],[-74.53125,40.78125]]],[[[-73.828125,40.78125],[-73.125,40.78125],[-73.125,41.484375],[-73.828125,41.484375],[-73.828125,40.78125]]],[[[-73.828125,41.484375],[-73.740234375,41.484375],[-73.740234375,41.572265625],[-73.828125,41.572265625],[-73.828125,41.484375]]],[[[-74.53125,41.484375],[-73.828125,41.484375],[-73.828125,42.1875],[-74.53125,42.1875],[-74.53125,41.484375]]],[[[-75.234375,41.484375],[-74.53125,41.484375],[-74.53125,42.1875],[-75.234375,42.1875],[-75.234375,41.484375]]],[[[-75.234375,40.78125],[-74.53125,40.78125],[-74.53125,41.484375],[-75.234375,41.484375],[-75.234375,40.78125]]],[[[-75.322265625,41.30859375],[-75.234375,41.30859375],[-75.234375,41.396484375],[-75.322265625,41.396484375],[-75.322265625,41.30859375]]],[[[-75.41015625,41.30859375],[-75.322265625,41.30859375],[-75.322265625,41.396484375],[-75.41015625,41.396484375],[-75.41015625,41.30859375]]],[[[-75.5859375,41.396484375],[-75.498046875,41.396484375],[-75.498046875,41.484375],[-75.5859375,41.484375],[-75.5859375,41.396484375]]],[[[-75.5859375,41.30859375],[-75.498046875,41.30859375],[-75.498046875,41.396484375],[-75.5859375,41.396484375],[-75.5859375,41.30859375]]],[[[-75.498046875,41.30859375],[-75.41015625,41.30859375],[-75.41015625,41.396484375],[-75.498046875,41.396484375],[-75.498046875,41.30859375]]],[[[-75.673828125,41.396484375],[-75.5859375,41.396484375],[-75.5859375,41.484375],[-75.673828125,41.484375],[-75.673828125,41.396484375]]],[[[-75.76171875,41.396484375],[-75.673828125,41.396484375],[-75.673828125,41.484375],[-75.76171875,41.484375],[-75.76171875,41.396484375]]],[[[-75.849609375,41.396484375],[-75.76171875,41.396484375],[-75.76171875,41.484375],[-75.849609375,41.484375],[-75.849609375,41.396484375]]],[[[-75.9375,41.484375],[-75.234375,41.484375],[-75.234375,42.1875],[-75.9375,42.1875],[-75.9375,41.484375]]]]}]}
-~~~
-
-When you paste the JSON output above into [geojson.io](http://geojson.io), it generates the picture below, which shows both the `LINESTRING` and its S2 covering based on the options you passed to `st_s2covering`.
-
-<img style="display: block; margin-left: auto; margin-right: auto; width: 50%" src="{{ 'images/v20.2/geospatial/s2-linestring-example-covering.png' | relative_url }}" alt="S2 LINESTRING example covering">
-
-### Create a spatial index
-
-The example below shows how to create a spatial index on a `GEOMETRY` object using the default settings:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX geom_idx_1 ON some_spatial_table USING GIST(geom);
-~~~
-
-~~~
-CREATE INDEX
-~~~
-
-### Create a spatial index with non-default tuning parameters
-
-The examples below show how to create spatial indexes with non-default settings for some of the [spatial index tuning parameters](#index-tuning-parameters):
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX geom_idx_1 ON geo_table1 USING GIST(geom) WITH (s2_level_mod=3);
-CREATE INDEX geom_idx_2 ON geo_table2 USING GIST(geom) WITH (geometry_min_x=0, s2_max_level=15)
-CREATE INDEX geom_idx_3 ON geo_table3 USING GIST(geom) WITH (s2_max_level=10)
-CREATE INDEX geom_idx_4 ON geo_table4 USING GIST(geom) WITH (geometry_min_x=0, s2_max_level=15);
-~~~
-
-~~~
-CREATE INDEX
-~~~
-
-### Create spatial indexes during table definition
-
-This example shows how to [create a table](create-table.html) with spatial indexes on `GEOMETRY` and `GEOGRAPHY` types that use non-default settings for some of the [spatial index tuning parameters](#index-tuning-parameters):
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE TABLE public.geo_table (
-   id INT8 NOT NULL,
-   geog GEOGRAPHY(GEOMETRY,4326) NULL,
-   geom GEOMETRY(GEOMETRY,3857) NULL,
-   CONSTRAINT "primary" PRIMARY KEY (id ASC),
-   INVERTED INDEX geom_idx_1 (geom) WITH (s2_max_level=15, geometry_min_x=0),
-   INVERTED INDEX geom_idx_2 (geom) WITH (geometry_min_x=0),
-   INVERTED INDEX geom_idx_3 (geom) WITH (s2_max_level=10),
-   INVERTED INDEX geom_idx_4 (geom),
-   INVERTED INDEX geog_idx_1 (geog) WITH (s2_level_mod=2),
-   INVERTED INDEX geog_idx_2 (geog),
-   FAMILY fam_0_geog (geog),
-   FAMILY fam_1_geom (geom),
-   FAMILY fam_2_id (id)
-)
-~~~
-
-~~~
-CREATE TABLE
-~~~
-
-### Create a spatial index that uses all of the tuning parameters
-
-This example shows how to set all of the [spatial index tuning parameters](#index-tuning-parameters) at the same time. It is extremely unlikely you will ever need to set all of the options at once; this example is being provided to show the syntax.
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX geom_idx
-  ON some_spatial_table USING GIST(geom)
-  WITH (s2_max_cells = 20, s2_max_level = 12, s2_level_mod = 3,
-        geometry_min_x = -180, geometry_max_x = 180,
-        geometry_min_y = -180, geometry_max_y = 180);
-~~~
-
-~~~
-CREATE INDEX
-~~~
-
-{{site.data.alerts.callout_danger}}
-As noted above, most users should not change the default settings. There is a risk that you will get worse performance by changing the default settings.
-{{site.data.alerts.end}}
-
-### Create a spatial index on a `GEOGRAPHY` object
-
-The example below shows how to create a spatial index on a `GEOGRAPHY` object using the default settings:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX geog_idx_3 ON geo_table USING GIST(geog);
-~~~
-
-~~~
-CREATE INDEX
-~~~
-
-## See also
-
-- [GIN Indexes](inverted-indexes.html)
-- [S2 Geometry Library](https://s2geometry.io/)
-- [Indexes](indexes.html)
-- [Spatial Features](spatial-features.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/spatial-tutorial.md b/src/current/v20.2/spatial-tutorial.md
deleted file mode 100644
index ba62b8d342d..00000000000
--- a/src/current/v20.2/spatial-tutorial.md
+++ /dev/null
@@ -1,1857 +0,0 @@
----
-title: Spatial Data
-summary: Tutorial for working with spatial data in CockroachDB.
-toc: true
-toc_not_nested: true
----
-
-In this tutorial, you will plan a vacation from New York City to the [Adirondack Mountains](https://visitadirondacks.com/about) in northern New York State to do some birdwatching while visiting local independent bookstores. In the process, you will explore several of CockroachDB's [spatial capabilities](spatial-features.html):
-
-+ Importing spatial data from SQL files (including how to build spatial geometries from data in CSV files).
-+ Putting together separate spatial data sets to ask and answer potentially interesting questions.
-+ Using various [built-in functions](functions-and-operators.html#spatial-functions) for operating on spatial data.
-+ Creating [indexes](spatial-indexes.html) on spatial data.
-+ Performing [joins](joins.html) on spatial data, and using [`EXPLAIN`](explain.html) to make sure indexes are effective.
-+ Visualizing the output of your queries using free tools like <https://geojson.io>
-
-## Step 1. Review the scenario
-
-You live in New York City and are an avid birdwatcher and reader of books. You are going on a vacation up to the [Adirondack Mountains](https://visitadirondacks.com/about) in northern New York State. Although you are interested in many bird species, you are most interested in seeing (and [hearing](https://macaulaylibrary.org/asset/107964)) the <a href="https://ebird.org/species/comloo" data-proofer-ignore>Common Loon</a>, a bird that can be found near the lakes and ponds of the north woods.
-
-As a connoisseur of bookstores, you also want to make sure to visit as many of the local independent bookstores as possible on your trip, as long as they are nearby to Loon habitat.
-
-Therefore, in order to plan your vacation trip effectively and optimize for having the most fun, you want to make sure to visit:
-
-+ Loon habitat (at minimum -- ideally you would like to go on the "hunt" for other interesting bird species).
-+ Independent bookstores that are located within the approximate home range of the loon.
-
-To accomplish the above, you have put together a data set that consists of what are normally several different data sets, namely:
-
-+ NY State bird sighting data from the years 2000-2019, taken from the [North American Breeding Bird Survey (NABBS)](https://www.sciencebase.gov/catalog/item/52b1dfa8e4b0d9b325230cd9). The full survey covers the US and Canada from the years 1966-2019 and is very large, so you have decided to import just the recent NY data since that is all you need to plan your trip.
-
-+ Road data from the [US National Atlas - Major Roads of the United States](https://www.sciencebase.gov/catalog/item/581d052be4b08da350d524ce) data set. This consists of a full road map of the United States. It was last modified in 2016, so it should be reasonably accurate.
-
-+ Bookstore information (name, address, website, etc.) you scraped from the [American Booksellers Association website's member directory](https://bookweb.org/member_directory/search/ABAmember).
-
-For more information about how this data set is put together, see the [Data set description](#data-set-description).
-
-## Step 2. Start CockroachDB
-
-This tutorial can be accomplished in any CockroachDB cluster running [v20.2](../releases/v20.2.html#v20-2-0) or later.
-
-The simplest way to get up and running is with [`cockroach demo`](cockroach-demo.html), which starts a temporary, in-memory CockroachDB cluster and opens an interactive SQL shell:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach demo
-~~~
-
-You will see a [SQL client prompt](cockroach-sql.html) that looks like the one shown below. You will use this prompt for the rest of the tutorial.
-
-~~~
-root@127.0.0.1:34839/movr>
-~~~
-
-## Step 3. Load the data set
-
-1. Create a `tutorial` database, and use it.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    CREATE DATABASE tutorial;
-    USE tutorial;
-    ~~~
-
-2. [`IMPORT`](import.html) the parts of [the data set](#data-set-description) that live in the `tutorial` database.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    IMPORT PGDUMP ('https://spatial-tutorial.s3.us-east-2.amazonaws.com/bookstores-and-roads-20210125.sql');
-    ~~~
-
-    ~~~
-            job_id       |  status   | fraction_completed |  rows  | index_entries |  bytes
-    ---------------------+-----------+--------------------+--------+---------------+-----------
-      629565276454256641 | succeeded |                  1 | 228807 |             0 | 75952972
-    (1 row)
-
-    Time: 17.745s total (execution 17.744s / network 0.000s)
-    ~~~
-
-3. Create a `birds` database, and use it.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    CREATE DATABASE birds;
-    USE birds;
-    ~~~
-
-4. [`IMPORT`](import.html) the parts of [the data set](#data-set-description) that live in the `birds` database.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    IMPORT PGDUMP ('https://spatial-tutorial.s3.us-east-2.amazonaws.com/birds-20210125.sql');
-    ~~~
-
-    ~~~
-            job_id       |  status   | fraction_completed | rows  | index_entries |  bytes
-    ---------------------+-----------+--------------------+-------+---------------+----------
-      629565605599412225 | succeeded |                  1 | 86616 |             0 | 4096847
-    (1 row)
-    ~~~
-
-5. Switch back to the `tutorial` database. All of the queries in this tutorial assume you are in the `tutorial` database.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    USE tutorial;
-    ~~~
-
-## Step 4. Scout loon locations
-
-### (1) Where has the Common Loon been sighted by the NABBS in the years 2000-2019 in NY state?
-
-As a first step, you'd like to know where exactly the Common Loon has been sighted in New York State. You know that many of the loon sightings will have taken place in the Adirondacks (our overall destination) due to the nature of the loon's preferred habitat of northern lakes and ponds, but it will be useful to know the precise locations for trip planning, and for asking further related questions about other bird habitats as well as nearby bookstores you'd like to visit.
-
-Because of the structure of [the `birds` database](#the-birds-database), you will wrap the results of a [subquery](subqueries.html) against the `birds` database in a [common table expression (CTE)](common-table-expressions.html) to provide a shorthand name for referring to this data. This step will be necessary every time you want to get information about bird sightings. Therefore, the general pattern for many of these queries will be something like:
-
-1. Get bird information (usually including location data) and store the results in a named CTE.
-2. Using the named CTE, perform additional processing against the results of the CTE combined with other data you have (e.g., bookstores, roads). Depending on the complexity of the questions asked, you may even need to create multiple CTEs.
-
-In the query below, to answer the question "where are the loons?", take the following steps:
-
-1. Join `birds.birds`, `birds.routes`, and `birds.observations` on the bird ID and route IDs where the bird name is "Common Loon".
-2. Collect the resulting birdwatcher route geometries (`routes.geom`) into one geometry (a [MultiPoint](multipoint.html)).
-3. Give the resulting table a name, `loon_sightings`, and query against it. In this case the query is rather simple: since the geometries have been collected into one in step 2 above, output the geometry as [GeoJSON](geojson.html) so the result can be pasted into <https://geojson.io> to generate a map of the sightings.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_sightings
-		AS (
-			SELECT
-				st_collect(routes.geom) AS the_geom
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	st_asgeojson(the_geom)
-FROM
-	loon_sightings;
-~~~
-
-~~~
-                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                        st_asgeojson
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  {"type":"MultiPoint","coordinates":[[-75.078218,43.662991],[-75.078218,43.662991],[-75.078218,43.662991],[-75.078218,43.662991],[-75.078218,43.662991],[-75.078218,43.662991],[-75.078218,43.662991],[-74.389678,43.652701],[-74.389678,43.652701],[-74.389678,43.652701],[-74.389678,43.652701],[-74.389678,43.652701],[-74.389678,43.652701],[-74.389678,43.652701],[-74.389678,43.652701],[-74.389678,43.652701],[-74.9492509,43.6625207],[-74.473788,43.726581],[-74.473788,43.726581],[-74.473788,43.726581],[-74.234828,43.971271],[-74.234828,43.971271],[-74.234828,43.971271],[-74.234828,43.971271],[-74.234828,43.971271],[-74.234828,43.971271],[-74.3975289,43.5654587],[-74.3975289,43.5654587],[-74.7918689,43.7217467],[-74.7918689,43.7217467],[-74.7918689,43.7217467],[-74.7918689,43.7217467],[-74.7918689,43.7217467],[-74.7918689,43.7217467],[-74.7918689,43.7217467],[-74.7918689,43.7217467],[-74.0622389,43.6884937],[-74.0622389,43.6884937],[-73.7371009,43.6098217],[-75.0557089,44.4354227],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.9230359,44.1319167],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.1807169,44.4319917],[-74.7210849,44.5376687],[-74.7210849,44.5376687],[-74.7210849,44.5376687],[-73.4887779,44.4433387],[-73.4887779,44.4433387],[-75.7014799,44.1487467],[-75.7014799,44.1487467],[-75.7014799,44.1487467],[-75.7014799,44.1487467],[-75.7014799,44.1487467],[-74.9852279,42.0781957],[-74.9852279,42.0781957],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.966888,43.679941],[-74.492148,44.522881],[-74.492148,44.522881],[-74.492148,44.522881],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587],[-74.6305979,44.1294587]]}
-(1 row)
-~~~
-
-Paste the result above into <https://geojson.io> and you should see the following map, with gray markers for each loon sighting from the bird survey.
-
-<img src="{{ 'images/v21.1/geospatial/tutorial/query-01.png' | relative_url }}" alt="Common Loon sightings in the years 2000-2019 in NY state" style="max-width:100%" />
-
-### (2) What is the total area of Loon sightings?
-
-Now that you have some sense of how loon sightings are distributed across the state, you may wonder: What is the area of the loon's approximate habitat (per these sightings) in New York State?
-
-To find the answer:
-
-1. Collect the geometries of all loon sightings together in a CTE as one geometry.
-2. Get the area of the [convex hull](st_convexhull.html) of the resulting geometry.
-3. Because the `birds.routes` data uses [SRID 4326](srid-4326.html), the resulting area is measured in degrees, which can be converted to square miles by casting the data to a `GEOGRAPHY` type and dividing by 1609 (the number of meters in a mile) squared.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_sightings
-		AS (
-			SELECT
-				st_collect(routes.geom) AS the_geom
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	st_area(st_convexhull(the_geom)::GEOGRAPHY) / 1609 ^ 2
-FROM
-	loon_sightings;
-~~~
-
-The result is an area of about 10,000 square miles, which can be visualized by a box with sides that are a little over 100 miles long. This answer can be verified by looking at the map output from [#1][q_01] and noting that most of the observation locations are well within 100 miles of each other.
-
-~~~
-       ?column?
-----------------------
-  10430.691899422598
-(1 row)
-~~~
-
-### (3) How many Loon sightings have there been in NY state in the years 2000-2019?
-
-In addition to the [loon observation point locations][q_01] and the [area of those observations][q_02] (which you can take as a proxy for the size of the loon's local habitat), you may want to know exactly how many times a loon has been sighted in the area.
-
-To find the answer:
-
-1. Join `birds.birds` and `birds.observations` on the bird ID where the bird name is "Common Loon".
-2. Sum all of the sightings; the `GROUP BY` on bird names is necessary due to the use of the `sum` aggregate function.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	birds.name, sum(observations.count) AS sightings
-FROM
-	birds.birds, birds.observations
-WHERE
-	birds.name = 'Common Loon'
-	AND birds.id = observations.bird_id
-GROUP BY
-	birds.name;
-~~~
-
-~~~
-     name     | sightings
---------------+------------
-  Common Loon |       269
-(1 row)
-~~~
-
-### (4) How many Loon sightings were there in NY state in just the year 2019?
-
-You might like to get a sense of how many of the loon sightings were more recent. For example, if there have been fewer sightings of loons in recent years, you might wonder if the population were declining in NY State.
-
-To determine how many sightings there were in NY state in 2019, re-use the query from [#3][q_03], with the additional constraint that the observation year is 2019.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	birds.name, sum(observations.count) AS sightings
-FROM
-	birds.birds, birds.observations
-WHERE
-	birds.name = 'Common Loon'
-	AND birds.id = observations.bird_id
-	AND observations.year = 2019
-GROUP BY
-	birds.name;
-~~~
-
-If the sightings are evenly distributed, you might expect this to yield about 13 sightings. In fact, it's pretty close. This suggests that the loon population may have remained fairly stable over the years 2000-2019.
-
-~~~
-     name     | sightings
---------------+------------
-  Common Loon |        12
-(1 row)
-~~~
-
-### (5) What is the density of Loon sightings per square mile in its range as defined by this data set in 2019?
-
-Since you are planning to do some hiking back into the woods to find the actual loons, you may get curious as to how densely the loon population is scattered over its habitat. From a practical perspective, the distribution is not actually even, since loons are most frequently located on lakes and ponds. Even so, it may serve as a useful proxy for the general areas in which to focus your birdwatching travels.
-
-To answer this question:
-
-1. Build a CTE that returns both the convex hull of loon habitat, as well as the sum of all loon observations in NY.
-2. Query the result table of the CTE from step 1 to divide the number of sightings by the area of the loon's habitat (the convex hull). As in [#2][q_02], do some arithmetic to convert from the unit of degrees returned by [SRID 4326](srid-4326.html) to square miles.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				sum(observations.count) AS sightings,
-				st_convexhull(st_collect(routes.geom))
-					AS the_hull
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-				AND observations.year = 2019
-		)
-SELECT
-	loon_habitat.sightings::FLOAT8
-	/ (
-			SELECT
-				st_area(loon_habitat.the_hull::GEOGRAPHY)
-				/ 1609 ^ 2
-		)
-FROM
-	loon_habitat;
-~~~
-
-It turns out that this is a pretty small number. There are not very many loon sightings per square mile within its overall habitat area, since lakes and ponds make up a small portion of the physical space inside the convex hull of observations.
-
-~~~
-        ?column?
-------------------------
-  0.005078531189694916
-(1 row)
-~~~
-
-## Step 5. Find bookstores to visit
-
-### (6) What are the bookstores that lie within the Loon's habitat range in NY state?
-
-Now that you have asked (and answered) some exploratory questions that may inform your birdwatching activities while on vacation, it would be good to start thinking about what bookstores to visit as part of your travels.
-
-A natural question that arises is: given that you are looking for loon habitat, what are the bookstores located within that habitat?
-
-To answer this question:
-
-1. Build a CTE that returns the [convex hull](st_convexhull.html) of Common Loon habitat.
-2. Join the results of the above CTE with a query against [the `bookstores` table](#the-bookstores-and-bookstore_routes-tables) that checks whether a bookstore's location is [contained](st_contains.html) by the loon habitat. Note that the query below [orders by](order-by.html) the store geometries so that stores in the list are clustered by location. This ordering may be useful if you want to travel between nearby stores. For more information about how this ordering is calculated, see [How CockroachDB's spatial indexing works](spatial-indexes.html#how-cockroachdbs-spatial-indexing-works).
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_sightings
-		AS (
-			SELECT
-				st_convexhull(st_collect(routes.geom))
-					AS loon_hull
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	name, street, city, state, url, phone
-FROM
-	tutorial.bookstores, loon_sightings
-WHERE
-	st_contains(loon_hull, geom)
-ORDER BY
-	geom;
-~~~
-
-~~~
-                        name                       |        street         |      city      | state |                       url                       |     phone
----------------------------------------------------+-----------------------+----------------+-------+-------------------------------------------------+-----------------
-  Blacktree Books                                  | 5006 State Highway 23 | Oneonta        | NY    | https://blacktreeoneonta.square.site/           | 6074321200
-  The Green Toad Bookstore                         | 198 Main St           | Oneonta        | NY    | http://www.greentoadbookstore.com               | (607) 433-8898
-  The Treehouse Reading and Arts Center            | 587 Main St Ste 304   | New York Mills | NY    | http://treehousebookshop.com                    | 315-765-6262
-  Gansevoort House Books at Gems Along the Mohawk  | 800 Mohawk St         | Herkimer       | NY    |                                                 |
-  Gansevoort House Books at The Shoppes at 25 West | 25 W Mill Street      | Little Falls   | NY    | http://www.gansevoorthouse.com/bookstore/       |
-  Mysteries On Main Street                         | 144 W Main St         | Johnstown      | NY    | https://www.facebook.com/MysteriesOnMainStreet/ | (518) 736-2665
-  The Bookstore Plus Music &amp; Art               | 2491 Main St          | Lake Placid    | NY    | http://www.thebookstoreplus.com                 | (518) 523-2950
-  The Book Nook (Saranac Lake, NY)                 | 7 Broadway            | Saranac Lake   | NY    | https://www.facebook.com/slbooknook/            | 6315999511
-(8 rows)
-~~~
-
-### (7) How many different species of bird habitats contain the location of the Book Nook in Saranac Lake, NY?
-
-As a birdwatcher, you probably do not want to only see the Common Loon. As long as you are spending time outside, it would be nice to see what other species of bird are in the area. This may provide even more birdwatching fun.
-
-Since you know you will want to hit up [The Book Nook in Saranac Lake, NY](https://www.facebook.com/slbooknook/) at least once on your trip, you decide to see what bird species' habitats contain the store's location. That way you can get a sense of the diversity of bird species in the area.
-
-To answer this question:
-
-1. Build a CTE that returns some information about the bookstore you want to visit.
-2. Build another CTE that returns information about the habitats of birds observed in NY state, and collects the habitat geometries together into one geometry.
-3. Join the results of the above CTEs and query the count of birds whose habitats contain the location of the bookstore.
-
-{{site.data.alerts.callout_info}}
-The final [`SELECT`](selection-queries.html) in the query below is doing a join that will not benefit from [spatial indexing](spatial-indexes.html), since both sides of the join are the results of [CTEs](common-table-expressions.html), and are therefore not indexed.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	the_book_nook
-		AS (
-			SELECT
-				bookstores.name, street, city, state, geom
-			FROM
-				tutorial.bookstores
-			WHERE
-				state = 'NY' AND city = 'Saranac Lake'
-		),
-	local_birds
-		AS (
-			SELECT
-				birds.name,
-				st_convexhull(st_collect(routes.geom))
-					AS the_hull
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-			GROUP BY
-				birds.name
-		)
-SELECT
-	count(local_birds.name)
-FROM
-	local_birds, the_book_nook
-WHERE
-	st_contains(local_birds.the_hull, the_book_nook.geom);
-~~~
-
-This is encouraging; there are over 120 species of birds for you to choose from whose habitats include the bookstore you want to visit!
-
-~~~
-  count
----------
-    124
-(1 row)
-~~~
-
-You can verify the results by checking how many bird species have been sighted by the bird survey overall; you should expect that this number will be much larger than 124, and indeed it is:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT COUNT(name) FROM birds.birds;
-~~~
-
-~~~
-  count
----------
-    756
-(1 row)
-~~~
-
-### (8) Which 25 birds were most often sighted within 10 miles of the Book Nook in Saranac Lake, NY during the 2000-2019 observation period?
-
-It's great that you [know how many bird species may be near a given bookstore][q_07]; however, that query didn't tell you which birds you have the best chance of seeing. Therefore, you'd like to figure out what birds are the most commonly seen in the area near a bookstore you want to visit: The Book Nook in Saranac Lake, NY.
-
-To answer this question:
-
-1. Build a CTE that returns some information about the bookstore you want to visit.
-2. Join the results of the above CTE and a query against the `birds` database that lists the names and observation totals (sums) of birds whose habitats are within 10 miles of the location of the bookstore.
-
-{{site.data.alerts.callout_info}}
-The query below can also be written using an explicit `ST_DWithin`, which is an [index-accelerated function](spatial-data.html#performance). CockroachDB optimizes `ST_Distance(...) < $some_value` to use `ST_DWithin` (see this query's [`EXPLAIN`](explain.html) output for details).
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	the_book_nook
-		AS (
-			SELECT
-				bookstores.name, street, city, state, geom
-			FROM
-				tutorial.bookstores
-			WHERE
-				state = 'NY' AND city = 'Saranac Lake'
-		)
-SELECT
-	birds.name, sum(observations.count) AS sightings
-FROM
-	birds.birds,
-	birds.observations,
-	birds.routes,
-	the_book_nook
-WHERE
-	birds.id = observations.bird_id
-	AND observations.route_id = routes.id
-	AND st_distance(
-			the_book_nook.geom::GEOGRAPHY,
-			routes.geom::GEOGRAPHY
-		)
-		< (1609 * 10)
-GROUP BY
-	birds.name
-ORDER BY
-	sightings DESC
-LIMIT
-	25;
-~~~
-
-Perhaps surprisingly, the <a href="https://ebird.org/species/reevir1/US-NY" data-proofer-ignore>Red-eyed Vireo</a> is the "winner", followed by a number of other fairly common birds. If you want a birdwatching challenge, you can reverse the sort order of the above query to find the rarest birds.
-
-~~~
-                   name                  | sightings
------------------------------------------+------------
-  Red-eyed Vireo                         |      2557
-  White-throated Sparrow                 |       928
-  Hermit Thrush                          |       924
-  American Robin                         |       691
-  Ovenbird                               |       650
-  American Crow                          |       528
-  (Myrtle Warbler) Yellow-rumped Warbler |       506
-  Chipping Sparrow                       |       465
-  Black-capped Chickadee                 |       390
-  Yellow-bellied Sapsucker               |       359
-  Blue-headed Vireo                      |       357
-  Blue Jay                               |       345
-  Winter Wren                            |       344
-  Cedar Waxwing                          |       272
-  Blackburnian Warbler                   |       248
-  Magnolia Warbler                       |       236
-  Black-throated Green Warbler           |       226
-  Common Grackle                         |       218
-  Red-breasted Nuthatch                  |       209
-  Common Yellowthroat                    |       184
-  Northern Parula                        |       175
-  Nashville Warbler                      |       164
-  Red-winged Blackbird                   |       152
-  Least Flycatcher                       |       128
-  American Redstart                      |       123
-(25 rows)
-~~~
-
-### (9) What does the shape of all bookstore locations that lie within the Loon's habitat look like?
-
-You [already discovered which bookstores are located within loon habitat][q_06]. However, you cannot really tell where these stores are located based on reading that query's output. You need to see them on the map. Therefore, for trip planning purposes, you decide you would like to look at the shape of the convex hull of the store locations.
-
-To answer this question:
-
-1. Build a CTE that returns the [convex hull](st_convexhull.html) of Common Loon habitat.
-2. Join the results of the above CTE with a query against [the `bookstores` table](#the-bookstores-and-bookstore_routes-tables) that checks whether a bookstore's location is [contained](st_contains.html) by the loon habitat.
-3. Collect the geometries that result from the step above into a single geometry, calculate its convex hull, and return the results as [GeoJSON](geojson.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_convexhull(st_collect(routes.geom))
-					AS the_hull
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	st_asgeojson(st_convexhull(st_collect(geom)))
-FROM
-	tutorial.bookstores, loon_habitat
-WHERE
-	st_contains(the_hull, geom);
-~~~
-
-~~~
-                                                                                              st_asgeojson
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  {"type":"Polygon","coordinates":[[[-75.036815,42.448793],[-75.062138,42.454003],[-75.296575,43.098322],[-74.131673,44.326892],[-73.980251,44.279377],[-74.374175,43.006495],[-75.036815,42.448793]]]}
-(1 row)
-~~~
-
-Paste the result above into <https://geojson.io> and you should see the following map:
-
-<img src="{{ 'images/v21.1/geospatial/tutorial/query-09.png' | relative_url }}" alt="Convex hull of bookstore locations within Common Loon habitat" style="max-width:100%" />
-
-### (10) What is the area of the shape of all bookstore locations that are in the Loon's habitat range within NY state?
-
-You have already [visualized the convex hull][q_09], but now you would like to calculate its area in square miles.
-
-To answer this question:
-
-1. Build a CTE that returns the [convex hull](st_convexhull.html) of Common Loon habitat.
-2. Join the results of the above CTE with a query against [the `bookstores` table](#the-bookstores-and-bookstore_routes-tables) that checks whether a bookstore's location is [contained](st_contains.html) by the loon habitat.
-2. Get the area of the [convex hull](st_convexhull.html) of the resulting geometry.
-3. Collect the geometries that result from the step above into a single geometry, calculate its convex hull, and calculate the area of the hull. As in previous examples, note that because the `birds.routes` data uses [SRID 4326](srid-4326.html), the resulting area is measured in degrees, which is converted to square miles by casting the data to a `GEOGRAPHY` type and dividing by 1609 (the number of meters in a mile) squared.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_convexhull(st_collect(routes.geom))
-					AS the_hull
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	st_area(st_convexhull(st_collect(geom))::GEOGRAPHY)
-	/ 1609 ^ 2
-FROM
-	tutorial.bookstores, loon_habitat
-WHERE
-	st_contains(the_hull, geom);
-~~~
-
-The result is an area of about 3,500 square miles, which can be visualized by a box with sides that are approximately 60 miles long. This answer can be verified by looking at the map output from [#9][q_09] and noting that most of the points on the hull are within about 60 miles of each other.
-
-~~~
-       ?column?
-----------------------
-  3564.1722404508437
-(1 row)
-~~~
-
-## Step 6. Plan your route
-
-### (11) How long is the route from Mysteries on Main Street in Johnstown, NY to The Book Nook in Saranac Lake, NY?
-
-So far, you have written queries that ask questions about bird habitats, bookstore locations, or some combination of the two. Because you are planning a trip, you want to think about how to travel between the bookstores in the loon habitat area. Depending on how far apart the bookstores are, you may want to visit more than one of them in a day, perhaps doing some birdwatching along the way.
-
-In order to accomplish this, you start looking at [the `bookstore_routes` table](#the-bookstores-and-bookstore_routes-tables) to see how far the distance is in miles between two of the bookstores you'd like to visit.
-
-To answer this question:
-
-1. Issue subqueries that find the IDs of two of the bookstores you'd like to travel between, as start and end points.
-2. Measure the length of the geometry that corresponds to those start and end IDs. Note that because the `bookstore_routes.geom` column has a SRID of 0 (which it inherited from the `roads` database from which it was created), you can convert to miles by casting the data to a `GEOGRAPHY` type, which uses meters, and then dividing by 1609 (the number of meters in a mile).
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	st_length(geom::GEOGRAPHY) / 1609
-FROM
-	bookstore_routes
-WHERE
-	end_store_id
-	= (
-			SELECT
-				id
-			FROM
-				tutorial.bookstores
-			WHERE
-				city = 'Johnstown' AND state = 'NY'
-		)
-	AND start_store_id
-		= (
-				SELECT
-					id
-				FROM
-					tutorial.bookstores
-				WHERE
-					city = 'Saranac Lake' AND state = 'NY'
-			);
-~~~
-
-The answer is: these two stores are about 132 miles apart, measured in road miles.
-
-~~~
-      ?column?
----------------------
-  132.6837073049756
-(1 row)
-~~~
-
-### (12) What does the route from Mysteries on Main Street in Johnstown, NY to The Book Nook in Saranac Lake, NY look like?
-
-You have [determined how long the drive between these two stores will be][q_11], but you would like to see what it looks like on the map.
-
-To find this out, you can re-use the query from the previous question, using `ST_AsGeoJSON` instead of `ST_Length`, and skipping the distance math to generate output in miles.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT
-	st_asgeojson(geom)
-FROM
-	bookstore_routes
-WHERE
-	end_store_id
-	= (
-			SELECT
-				id
-			FROM
-				tutorial.bookstores
-			WHERE
-				city = 'Johnstown' AND state = 'NY'
-		)
-	AND start_store_id
-		= (
-				SELECT
-					id
-				FROM
-					tutorial.bookstores
-				WHERE
-					city = 'Saranac Lake' AND state = 'NY'
-			);
-~~~
-
-The result is a very large chunk of JSON:
-
-~~~
-                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                st_asgeojson
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  {"type":"MultiLineString","coordinates":[[[-74.152265,44.317412001],[-74.150683244,44.320361245],[-74.149541,44.322491001]],[[-74.357329,44.244378001],[-74.356093,44.243859001],[-74.354178,44.242898001],[-74.348143,44.239648001],[-74.343626,44.237058001],[-74.342321,44.236058001],[-74.341749001,44.235410001],[-74.33975,44.232579001],[-74.339208,44.231977001],[-74.338667001,44.231599001],[-74.337461,44.231248001],[-74.326169,44.228478001],[-74.324681,44.228200001],[-74.322827,44.228066001],[-74.319936001,44.228040001],[-74.318920999,44.228200001],[-74.316251,44.228909001],[-74.315228,44.229337001],[-74.313824,44.230576001],[-74.310864,44.234299001],[-74.308766,44.236287001],[-74.30769,44.237137001],[-74.306668,44.237778001],[-74.305104,44.238369001],[-74.300305,44.239258001],[-74.298489,44.239849001],[-74.296765,44.240559001],[-74.293965,44.241978001],[-74.285755,44.246469001],[-74.284199,44.246998001],[-74.283496,44.247158001],[-74.278659999,44.246807001],[-74.277065,44.246487001],[-74.27103,44.244926001],[-74.269977,44.244766001],[-74.268862,44.244926001],[-74.267528001,44.245315001],[-74.264667,44.246425001],[-74.263103,44.246887001],[-74.262439,44.246956001],[-74.261516,44.246887001],[-74.258806999,44.246215001],[-74.258105,44.246128001],[-74.256106,44.246376001],[-74.249583,44.248748001],[-74.242563999,44.250486001],[-74.240374,44.251056001],[-74.237955,44.251956001],[-74.236117,44.252757001],[-74.234713,44.253264001],[-74.233477,44.253375001],[-74.232264001,44.253214001],[-74.230066,44.252714001],[-74.228067,44.252554001],[-74.224855,44.252695001],[-74.222374999,44.253027001],[-74.220468,44.253485001],[-74.219284999,44.253916001],[-74.218202,44.254465001],[-74.217285999,44.255606001],[-74.216554001,44.256914001],[-74.216272,44.258444001],[-74.216172,44.260206001],[-74.215837,44.261663001],[-74.215417,44.262537001],[-74.215105,44.262884001],[-74.210526,44.266176001],[-74.209443,44.267164001],[-74.205635,44.272016001],[-74.204712,44.272855001],[-74.203781,44.273633001],[-74.20137,44.275014001],[-74.199875,44.276155001],[-74.189735,44.286454001],[-74.1883,44.287625001],[-74.187415,44.288033001],[-74.186333,44.288353001],[-74.184364869,44.288747417],[-74.184364734,44.288747444],[-74.180854001,44.289451001],[-74.178374,44.290524001],[-74.177191,44.291213001],[-74.176085,44.292084001],[-74.175354,44.292725001],[-74.174521,44.293915001],[-74.173979,44.295353001],[-74.173468,44.297363001],[-74.172934001,44.298374001],[-74.166349,44.306545001],[-74.165144,44.308003001],[-74.160711,44.311824001],[-74.159916999,44.312461001],[-74.157789,44.313514001],[-74.154476999,44.315021001],[-74.153623,44.315642001],[-74.152265,44.317412001]],[[-74.464373,44.224200001],[-74.462122,44.224250001],[-74.461046,44.224318001],[-74.455468999,44.22478],[-74.442636406,44.225904612],[-74.437326,44.226370001],[-74.436273,44.226599001],[-74.416718001,44.232618001],[-74.398811,44.238371001],[-74.396683,44.238729001],[-74.390892,44.239401001],[-74.386916999,44.240198001],[-74.376418001,44.242708001],[-74.37461,44.243078001],[-74.369964,44.243669001],[-74.358573,44.244409001],[-74.357329,44.244378001]],[[-74.538494,44.124160001],[-74.537784999,44.125049001],[-74.534733,44.128341001],[-74.533054,44.129662001],[-74.531116,44.130992001],[-74.528957,44.132541001],[-74.527345325,44.134460927],[-74.527338703,44.134468817],[-74.527332393,44.134476334],[-74.525867,44.136222001],[-74.525164999,44.137359001],[-74.524524,44.138992001],[-74.524012999,44.140750001],[-74.522853,44.151859001],[-74.522876,44.154721001],[-74.523166,44.156341001],[-74.523501999,44.157512001],[-74.523822,44.158702001],[-74.523914,44.160320001],[-74.523753999,44.161079001],[-74.523371,44.161991001],[-74.521656,44.164352001],[-74.518795,44.167732001],[-74.517734,44.168800001],[-74.515415,44.170791001],[-74.512392,44.173229001],[-74.511211,44.174079001],[-74.507396,44.176181001],[-74.500621,44.180629001],[-74.492266,44.190040001],[-74.487185,44.193339001],[-74.485827,44.194141001],[-74.480456,44.196220001],[-74.478991,44.196551001],[-74.474985,44.197211001],[-74.472384001,44.197902001],[-74.471864933,44.198667258],[-74.471781,44.198791001],[-74.471609775,44.199419986],[-74.47160767,44.199427717],[-74.471357398,44.200347074],[-74.471238999,44.200782001],[-74.470742999,44.204081001],[-74.470324,44.205100001],[-74.470011,44.205630001],[-74.468932391,44.207118271],[-74.468927664,44.207124794],[-74.467852,44.208609001],[-74.464525,44.213050001],[-74.462816,44.215560001],[-74.462626,44.216022001],[-74.462687,44.217509001],[-74.46288977,44.21846686],[-74.46306,44.219271001],[-74.463861,44.220321001],[-74.464914999,44.221049001],[-74.465776999,44.221599001],[-74.466311,44.222030001],[-74.466249999,44.222491001],[-74.465655,44.223059001],[-74.464373,44.224200001]],[[-74.529117,44.099819001],[-74.531985,44.102500001],[-74.532741,44.103572001],[-74.533183,44.104492001],[-74.533435,44.106109001],[-74.533527,44.108600001],[-74.534061,44.111190001],[-74.534503,44.112152001],[-74.535045,44.113109001],[-74.536502999,44.115379001],[-74.537357,44.116381001],[-74.537456,44.116455001]],[[-74.472935039,44.000000001],[-74.479534023,44.002542684],[-74.479984937,44.002716429],[-74.480005378,44.002724305],[-74.480329,44.002849001],[-74.48677,44.005149001],[-74.49295,44.007480001],[-74.496628,44.009689001],[-74.498024,44.010719001],[-74.499611,44.012371001],[-74.501511,44.014541001],[-74.503151,44.016508001],[-74.508523,44.023811001],[-74.511529,44.027950001],[-74.514778999,44.032821001],[-74.515222,44.034469001],[-74.515473999,44.036991001],[-74.516015,44.039112001],[-74.517175,44.041202001],[-74.517816,44.042251001],[-74.519449,44.044540001],[-74.520181,44.045272001],[-74.521486,44.046760001],[-74.52189,44.047332001],[-74.522234,44.048221],[-74.522074,44.052341001],[-74.521654,44.055591001],[-74.520983,44.059932001],[-74.520051,44.065921001],[-74.519023544,44.072237853],[-74.519022043,44.072247084],[-74.518511,44.075389001],[-74.518381,44.076869001],[-74.518374,44.078979001],[-74.518503,44.079730001],[-74.518976,44.081382001],[-74.519572001,44.082641001],[-74.52122,44.085311001],[-74.525523,44.093051001],[-74.52682,44.095809001],[-74.528056,44.098220001],[-74.5291102,44.099808753],[-74.529115821,44.099817225],[-74.529117,44.099819001]],[[-74.419277,43.968522001],[-74.420169,43.969804001],[-74.420413,43.970281001],[-74.420604,43.971353001],[-74.420643889,43.971779185],[-74.420644773,43.971788634],[-74.42081,43.973554001],[-74.421245,43.974141001],[-74.421848,43.974301001],[-74.426426993,43.974695925],[-74.42644422,43.974697411],[-74.427425,43.974782001],[-74.42815,43.975010001],[-74.428618155,43.975309199],[-74.428626193,43.975314337],[-74.429577,43.975922001],[-74.43047,43.976590001],[-74.431927,43.977391001],[-74.435977,43.978982001],[-74.437787,43.979302001],[-74.439526,43.979302001],[-74.443196,43.979050001],[-74.444340001,43.979092001],[-74.445003999,43.979191001],[-74.446484,43.979640001],[-74.449117,43.980812001],[-74.451276,43.981953001],[-74.453779,43.983780001],[-74.456640001,43.986951001],[-74.460989,43.992531001],[-74.461897,43.993790001],[-74.4634,43.995430001],[-74.464407001,43.996460001],[-74.465362,43.997082001],[-74.472935039,44.000000001]],[[-74.430422635,43.855487245],[-74.430823844,43.859778886],[-74.432091,43.864603001],[-74.430741,43.872534001],[-74.430741,43.873312001],[-74.431092,43.874205001],[-74.431824999,43.875052001],[-74.432267,43.875433001],[-74.433274,43.876513001],[-74.433854,43.877634001],[-74.433946,43.878454001],[-74.433725001,43.879091001],[-74.432962,43.880034001],[-74.431573,43.881113001],[-74.427842,43.882784001],[-74.424844,43.884363001],[-74.424027,43.884882001],[-74.418244,43.889235],[-74.417732,43.889895001],[-74.417481,43.890444001],[-74.417428,43.891023001],[-74.417481,43.891981001],[-74.417992999,43.893305001],[-74.418686999,43.894175001],[-74.419221,43.894613001],[-74.420586,43.895502001],[-74.422838,43.896364001],[-74.424661,43.896803001],[-74.428651,43.896982001],[-74.434976,43.898191001],[-74.435762,43.898394001],[-74.436464,43.898992001],[-74.436815,43.899541001],[-74.437037001,43.900682001],[-74.437006,43.902284001],[-74.436844816,43.902957433],[-74.436815,43.903082001],[-74.436568249,43.903468348],[-74.436564,43.903475001],[-74.435687001,43.905462001],[-74.435648,43.906812001],[-74.435877,43.907381001],[-74.436884,43.908254001],[-74.437456,43.908434001],[-74.439768,43.909033001],[-74.440714,43.909444001],[-74.442675,43.910814001],[-74.443247,43.911241001],[-74.443949,43.912252001],[-74.444194,43.912843001],[-74.444163,43.913831001],[-74.443477,43.917234001],[-74.443286,43.917814001],[-74.442683,43.918993001],[-74.442408,43.919753002],[-74.441707,43.924302001],[-74.442027,43.925031001],[-74.44321,43.926824001],[-74.444118,43.927891001],[-74.444727999,43.928422001],[-74.455486001,43.936163001],[-74.457503769,43.936996535],[-74.457628577,43.938124354],[-74.456197485,43.939437358],[-74.452444415,43.94344539],[-74.450565344,43.945532689],[-74.449504442,43.946317113],[-74.446375524,43.948497454],[-74.446308501,43.948545699],[-74.4417465,43.951936699],[-74.441713582,43.95196156],[-74.441577106,43.952073562],[-74.44144825,43.95219425],[-74.441440603,43.952201926],[-74.440944602,43.952701927],[-74.440831562,43.952823108],[-74.440719559,43.952959582],[-74.440616724,43.953103091],[-74.440523492,43.953253017],[-74.440440267,43.95340872],[-74.440417621,43.953455787],[-74.440279357,43.953750403],[-74.439810963,43.954070359],[-74.438161986,43.954733199],[-74.435710574,43.955480195],[-74.435629767,43.955506216],[-74.435464532,43.955568406],[-74.435303719,43.955641268],[-74.435303325,43.955641463],[-74.434326325,43.956123464],[-74.434253446,43.956160804],[-74.429912445,43.958468803],[-74.429830017,43.958514493],[-74.429792382,43.958536629],[-74.428869382,43.95908963],[-74.428757089,43.959160725],[-74.428613582,43.959263561],[-74.428602976,43.959271742],[-74.425443975,43.961720742],[-74.425061746,43.963823434],[-74.423999,43.966344001],[-74.419277,43.968522001]],[[-74.430422635,43.855487245],[-74.422981,43.853304001],[-74.422035,43.852503001],[-74.421463,43.851863001],[-74.42086,43.850794001],[-74.420173,43.849055001],[-74.417701001,43.847792001],[-74.416725,43.847434001],[-74.411512999,43.845713001],[-74.410461,43.845374001],[-74.405379,43.845622001],[-74.404302999,43.845653001],[-74.402564,43.845443001],[-74.391691,43.843593001],[-74.389043999,43.842933001],[-74.386389,43.842044001],[-74.383202099,43.84067843],[-74.383194658,43.840675242],[-74.383008908,43.840595648],[-74.380788,43.839644001],[-74.378271,43.838885001],[-74.370183,43.837283001],[-74.369199,43.836986001],[-74.367238,43.835895001],[-74.366452,43.835223001],[-74.362378,43.829894001],[-74.361927,43.829215001],[-74.360920001,43.826236001],[-74.360073,43.825275001],[-74.359158,43.824615001],[-74.356823,43.823444001],[-74.351642,43.821704001],[-74.350788,43.821453001],[-74.345065,43.820084001],[-74.339946,43.819373001],[-74.338977001,43.819164001],[-74.33768,43.818595001],[-74.336580999,43.817832001],[-74.334681,43.816055001],[-74.333987,43.815483001],[-74.33301,43.815112001],[-74.332346,43.815025001],[-74.328997,43.815135001],[-74.328265,43.815044001],[-74.32606,43.814525001],[-74.324885,43.814014001],[-74.323565,43.813075001],[-74.317789,43.807224001],[-74.316904,43.805984001],[-74.315865999,43.804916001],[-74.314164,43.803356001],[-74.312616,43.802234001],[-74.309617,43.800743001],[-74.304787,43.798774001],[-74.303597,43.798156002],[-74.302544,43.797374001],[-74.302017,43.796764001],[-74.301766,43.795703001],[-74.301293,43.789993001],[-74.301239,43.788345001],[-74.30156,43.787366001],[-74.301964,43.786903001],[-74.303009,43.785984001],[-74.303856,43.785053001],[-74.303766,43.784523001],[-74.303169,43.783584001],[-74.30237657,43.782755241],[-74.302368102,43.782746385],[-74.301773,43.782124001],[-74.300392,43.781143001],[-74.299507001,43.780723001],[-74.298248001,43.780403001],[-74.296165,43.780174001],[-74.294173999,43.780174001],[-74.293197,43.780403001],[-74.289786,43.781475001],[-74.283652001,43.782913001],[-74.281074,43.783226001],[-74.276053,43.783065001],[-74.266203,43.782344001],[-74.265295,43.782203001]],[[-74.363938,43.502013001],[-74.366326,43.504158001],[-74.367432,43.504927001],[-74.368592001,43.505598001],[-74.3695,43.506236001],[-74.369966,43.506716001],[-74.371263,43.508746001],[-74.371728,43.510188002],[-74.371759,43.510878001],[-74.371072,43.513346001],[-74.371126,43.514128001],[-74.371263001,43.514609001],[-74.371606001,43.515086001],[-74.372988,43.516226001],[-74.37459,43.516986001],[-74.377199,43.518266001],[-74.385432,43.522406001],[-74.386088,43.523017001],[-74.386408999,43.523497001],[-74.386691,43.524646001],[-74.386532553,43.526017531],[-74.38653144,43.526027172],[-74.386442444,43.526797514],[-74.386409,43.527087001],[-74.385913,43.528948001],[-74.385119,43.531458001],[-74.383929,43.534228001],[-74.383212,43.535826001],[-74.383021,43.537089001],[-74.382983,43.538138001],[-74.383334,43.538897001],[-74.384273,43.540125001],[-74.385593,43.541586001],[-74.390468001,43.545298001],[-74.391071,43.546008002],[-74.391918,43.547678001],[-74.395001,43.555265001],[-74.395131,43.556048001],[-74.395283,43.557879001],[-74.395321,43.561217001],[-74.395543,43.562746001],[-74.395909,43.563776],[-74.396512,43.564509001],[-74.397519,43.565466001],[-74.398803582,43.566517366],[-74.398814559,43.56652635],[-74.399221,43.566859001],[-74.399824,43.567705001],[-74.399944999,43.568259001],[-74.399945,43.569647001],[-74.399221,43.572188001],[-74.39919,43.573626001],[-74.399662,43.574797001],[-74.40064,43.575918001],[-74.404486,43.579416001],[-74.405202999,43.580538001],[-74.405584,43.581227001],[-74.405916539,43.5819675],[-74.405920409,43.581976118],[-74.406069135,43.582307303],[-74.407255,43.584948001],[-74.407721,43.586386001],[-74.408263,43.588358001],[-74.408606,43.591215001],[-74.408484,43.592638001],[-74.408454,43.594439001],[-74.408896,43.595877001],[-74.409934,43.596907001],[-74.410712,43.597319001],[-74.414336,43.598826001],[-74.418052,43.600195001],[-74.418937,43.600676001],[-74.419784,43.601568001],[-74.420166,43.602099001],[-74.420356,43.602716001],[-74.420326,43.603445001],[-74.419976,43.604178001],[-74.417839,43.607267001],[-74.416397,43.610147001],[-74.414604,43.614607001],[-74.414423322,43.616825244],[-74.412448675,43.618905862],[-74.40718547,43.621568425],[-74.402912985,43.623921388],[-74.397525939,43.62776043],[-74.395234896,43.628936913],[-74.392262735,43.632218675],[-74.39075766,43.634708852],[-74.389909772,43.637358042],[-74.388159464,43.640096794],[-74.387494889,43.644231168],[-74.387252,43.646085001],[-74.387122,43.646905001],[-74.387222,43.647615001],[-74.387664,43.648465001],[-74.388618,43.649698001],[-74.388953999,43.650544001],[-74.389282339,43.651568593],[-74.389285046,43.651577041],[-74.389527445,43.652333453],[-74.389847852,43.655810221],[-74.388573718,43.658372116],[-74.385712295,43.660061454],[-74.378887271,43.663353982],[-74.375864153,43.663837969],[-74.373971827,43.663959237],[-74.371619282,43.665055508],[-74.369785751,43.66516015],[-74.365134387,43.665658299],[-74.363288,43.666715001],[-74.362213,43.667745001],[-74.360854,43.669385001],[-74.360518,43.669934001],[-74.360167,43.670827001],[-74.356002,43.676476001],[-74.349882999,43.683015001],[-74.344527,43.687794001],[-74.343077,43.689374001],[-74.342131,43.691105001],[-74.340582,43.694836001],[-74.339514,43.696484],[-74.335066,43.700436001],[-74.334242,43.701874001],[-74.333174,43.704007001],[-74.331496,43.707844001],[-74.330802,43.709084001],[-74.330076,43.709927001],[-74.329352001,43.710366001],[-74.328215,43.710705001],[-74.324652001,43.710957001],[-74.320875,43.711563001],[-74.319922,43.711865001],[-74.319266,43.712277001],[-74.313734,43.718174001],[-74.313069,43.719135001],[-74.312566999,43.720524001],[-74.311713,43.722103001],[-74.309912,43.724556001],[-74.302595001,43.732204001],[-74.299216,43.735523001],[-74.297856999,43.736393001],[-74.294798006,43.740837095],[-74.294792616,43.740844925],[-74.292921,43.743564001],[-74.290266,43.747505001],[-74.289922999,43.747887001],[-74.287932,43.748733001],[-74.287207,43.749325001],[-74.286703,43.750084001],[-74.285567,43.752563001],[-74.285345,43.753802001],[-74.284903,43.754875001],[-74.283926,43.756206001],[-74.282431,43.757225001],[-74.278173999,43.761955001],[-74.276846,43.763714001],[-74.27561,43.764866001],[-74.274252,43.765823001],[-74.270308,43.768245001],[-74.265844,43.770633001],[-74.264074,43.773136001],[-74.263722,43.773906001],[-74.263662,43.775093001],[-74.263884,43.776195001],[-74.264570001,43.777404001],[-74.264853,43.778395001],[-74.265265,43.781635001],[-74.265295,43.782203001]],[[-74.538405,43.399411001],[-74.534987,43.400719001],[-74.533636,43.401360001],[-74.531745,43.402501001],[-74.530805999,43.403229001],[-74.529921,43.404080001],[-74.527311,43.407731001],[-74.526495,43.409058001],[-74.524985001,43.412920001],[-74.524451,43.413998001],[-74.523793,43.414979001],[-74.523108,43.415730001],[-74.522154001,43.416398001],[-74.521093999,43.417008001],[-74.518043001,43.418500001],[-74.513304,43.420670001],[-74.508344,43.422768001],[-74.507361,43.423131001],[-74.499571001,43.426739001],[-74.497915,43.427628001],[-74.495504,43.429299001],[-74.488104,43.434572002],[-74.486913001,43.435559001],[-74.483991,43.437459001],[-74.480543,43.439400001],[-74.476689,43.440937001],[-74.474523,43.441449001],[-74.473745,43.441516001],[-74.472646,43.441288001],[-74.47054,43.440808001],[-74.468564,43.440540001],[-74.467183,43.440702001],[-74.465771,43.441201001],[-74.457173,43.447567001],[-74.453511,43.450928001],[-74.452411999,43.452049001],[-74.451405,43.452919001],[-74.445484001,43.457390001],[-74.440525,43.460407001],[-74.43845,43.461510001],[-74.435283,43.462418001],[-74.432674,43.463798001],[-74.430072,43.466109001],[-74.428562001,43.466999001],[-74.423259001,43.469658001],[-74.421505,43.470231001],[-74.420529,43.470428001],[-74.414973,43.471008001],[-74.412081,43.470958001],[-74.411082001,43.470890001],[-74.408251,43.470256001],[-74.407214,43.470119001],[-74.406328,43.470231001],[-74.405237,43.470639001],[-74.404421,43.471187001],[-74.403751968,43.471760018],[-74.40374812,43.471763313],[-74.402247,43.473049001],[-74.398798,43.475128001],[-74.397257,43.475996001],[-74.395281,43.476959001],[-74.394808,43.477138001],[-74.39409,43.477649001],[-74.392458,43.479358001],[-74.392168001,43.479747001],[-74.389879,43.481849001],[-74.388879,43.482417001],[-74.388063,43.482768001],[-74.384286001,43.483890001],[-74.38231,43.484687001],[-74.379548,43.485988001],[-74.378007,43.487247001],[-74.37459,43.490497001],[-74.371728001,43.493628001],[-74.368516,43.497519001],[-74.368081,43.498088001],[-74.366921,43.499526001],[-74.363938,43.502013001]],[[-74.517516,43.229490001],[-74.517511546,43.229491206],[-74.51715,43.229589001],[-74.516121,43.230180001],[-74.515517999,43.231168001],[-74.515166985,43.234115798],[-74.516126976,43.235651784],[-74.516352909,43.23601328],[-74.516358236,43.236021803],[-74.516627882,43.236453236],[-74.517407028,43.237621954],[-74.517309635,43.23869328],[-74.516725275,43.241225503],[-74.516335703,43.242783794],[-74.516451181,43.24314947],[-74.516596508,43.243609679],[-74.516599124,43.243617961],[-74.517504421,43.246484736],[-74.517504421,43.249114353],[-74.517789825,43.250826773],[-74.517791285,43.250835533],[-74.517991388,43.25203615],[-74.517699208,43.253497048],[-74.517991387,43.25447098],[-74.519257499,43.255152732],[-74.522958442,43.255931877],[-74.528899427,43.255931877],[-74.534353447,43.255055339],[-74.534409397,43.255065212],[-74.534613985,43.255101316],[-74.534616201,43.255101707],[-74.536009132,43.255347518],[-74.539125714,43.256224057],[-74.540781399,43.258464101],[-74.541755331,43.259340641],[-74.543216229,43.260119786],[-74.544190161,43.261483291],[-74.544287555,43.263236368],[-74.545346767,43.265596244],[-74.547662904,43.26791238],[-74.54885406,43.269831465],[-74.549383463,43.271419675],[-74.550640795,43.272809358],[-74.551104022,43.274265215],[-74.552295179,43.275654897],[-74.553486335,43.276846053],[-74.553817212,43.277706333],[-74.55342016,43.278831314],[-74.552824581,43.280088646],[-74.553023108,43.281015101],[-74.553684861,43.282338608],[-74.553817212,43.283926816],[-74.553883387,43.286242954],[-74.553618685,43.287764988],[-74.553287809,43.289353196],[-74.553221634,43.291272281],[-74.553817213,43.293654593],[-74.556202148,43.296330374],[-74.55620838,43.296337366],[-74.556530402,43.296698659],[-74.557439202,43.297789221],[-74.557853909,43.298286869],[-74.561625903,43.299875077],[-74.563942041,43.300603006],[-74.565265548,43.301198584],[-74.567250809,43.303316195],[-74.566593,43.306008001],[-74.565959,43.306329001],[-74.565021001,43.306668001],[-74.564342,43.306809001],[-74.562518,43.306870001],[-74.561672,43.307118001],[-74.560832,43.307580001],[-74.56026,43.308179001],[-74.559603999,43.309251001],[-74.559513,43.310868001],[-74.557223999,43.314487001],[-74.556812,43.314969001],[-74.556179,43.315419001],[-74.551799,43.317689001],[-74.550791999,43.318028001],[-74.550205,43.318139001],[-74.54932,43.318120001],[-74.548602,43.317998001],[-74.546553305,43.317435031],[-74.546540117,43.317431407],[-74.546535,43.317430001],[-74.545314,43.317448001],[-74.543769359,43.317982042],[-74.54346,43.318089001],[-74.541895334,43.319480577],[-74.541874268,43.319499312],[-74.541227786,43.320074278],[-74.537982,43.322961001],[-74.536966999,43.324059001],[-74.534404,43.326890001],[-74.534053,43.327348001],[-74.534023,43.328469001],[-74.534145,43.329949001],[-74.53445,43.331300001],[-74.534633,43.335969001],[-74.534572,43.336610001],[-74.533748,43.339700001],[-74.532902,43.341908001],[-74.532711,43.342562001],[-74.532711,43.344109001],[-74.533154001,43.347749001],[-74.533329,43.348180001],[-74.534245,43.348569001],[-74.535931,43.348920001],[-74.539784,43.352101001],[-74.540059001,43.352578001],[-74.5425,43.359578001],[-74.542431,43.360329001],[-74.544652,43.365231001],[-74.545285,43.366009001],[-74.546719999,43.368889001],[-74.546911,43.369328],[-74.546941,43.370099001],[-74.546910434,43.37081979],[-74.546910043,43.370828991],[-74.546743,43.374768001],[-74.54523859,43.380839868],[-74.545236318,43.380849039],[-74.544607,43.383389001],[-74.544165,43.384350001],[-74.543592,43.385129001],[-74.543226,43.386269001],[-74.543211,43.387047001],[-74.543211,43.393700001],[-74.543363,43.395100001],[-74.543692001,43.395955001]],[[-74.523337,43.190378001],[-74.523589,43.190599001],[-74.524406,43.191679001],[-74.524398,43.193460001],[-74.526046,43.199522001],[-74.526756,43.201952001],[-74.526946,43.202500001],[-74.527358,43.203001001],[-74.528816,43.204241001],[-74.529228,43.204851001],[-74.530654,43.209131001],[-74.530807,43.211530001],[-74.531021,43.219041001],[-74.53099,43.219652001],[-74.530456,43.220411001],[-74.530075,43.220682001],[-74.529297,43.220998001],[-74.527389,43.221368001],[-74.526168,43.222299],[-74.52523,43.223351001],[-74.524131,43.225301],[-74.523285,43.226121001],[-74.520644999,43.228219001],[-74.519776,43.228719001],[-74.518394,43.229248001],[-74.517552345,43.229479983],[-74.517516,43.229490001]],[[-74.489522,43.144732001],[-74.487653,43.146842001],[-74.486974,43.147891001],[-74.486386,43.149222001],[-74.486196,43.149931001],[-74.486257,43.151370001],[-74.486982,43.157683001],[-74.487302,43.158499001],[-74.487553068,43.15885108],[-74.487558704,43.158858983],[-74.487645,43.158980001],[-74.488584,43.159922001],[-74.488995999,43.160261001],[-74.492902,43.163321001],[-74.493688,43.163782001],[-74.494749,43.164259001],[-74.498129,43.165240001],[-74.499593,43.166041002],[-74.506094,43.169752001],[-74.50688,43.170550001],[-74.507994,43.172289001],[-74.508909,43.172949001],[-74.509619,43.173319001],[-74.511809,43.174372001],[-74.512953,43.174563001],[-74.514395,43.174440001],[-74.516836999,43.174101001],[-74.517744999,43.174101001],[-74.522367999,43.174429001],[-74.525397,43.174822001],[-74.526427,43.175142001],[-74.527365999,43.175741001],[-74.527617001,43.176222001],[-74.527709,43.177180001],[-74.526206,43.180349001],[-74.524421,43.182619001],[-74.523757,43.183832001],[-74.523505,43.184771001],[-74.523482798,43.184871668],[-74.523481108,43.184879335],[-74.523350626,43.185470982],[-74.522689,43.188471001],[-74.522567,43.189432001],[-74.522849,43.189939001],[-74.523337,43.190378001]],[[-74.481137,43.137126001],[-74.477955,43.136122001],[-74.474796,43.133918001],[-74.473491999,43.132907001],[-74.469212,43.127990001],[-74.467541,43.125544001],[-74.462276001,43.121722001],[-74.461239002,43.120872001],[-74.451899999,43.111972001],[-74.44482,43.104675001],[-74.442248,43.100520001],[-74.441287,43.099738001],[-74.438442511,43.098239949],[-74.43842793,43.098232271],[-74.433276,43.095519001],[-74.427227,43.092842001],[-74.424792,43.092453001],[-74.423205,43.091941001],[-74.422495,43.091514001],[-74.421168,43.090263001],[-74.420733,43.089435001],[-74.420069,43.087520001],[-74.419657,43.084262001],[-74.418360001,43.081066001],[-74.416842,43.078594001],[-74.416178,43.077903001],[-74.409875999,43.074226001],[-74.402719,43.070606001],[-74.401857,43.070297001],[-74.396333,43.069805001],[-74.389688,43.068142001],[-74.388277001,43.067131001],[-74.383843,43.061993001],[-74.382844,43.060459001],[-74.381737,43.057114001],[-74.380936,43.055908001],[-74.37941,43.054917001],[-74.374505,43.053871001],[-74.373430143,43.05371745],[-74.372559,43.053593001],[-74.367921,43.052548001],[-74.366035999,43.051289001]],[[-74.366035999,43.051289001],[-74.365227,43.050747001],[-74.3619,43.050244001],[-74.360909,43.050106001],[-74.359956,43.050152001],[-74.354088001,43.051007001],[-74.352554,43.051045001],[-74.351057999,43.050888001],[-74.348739,43.050381001],[-74.346245,43.050488001]],[[-74.352012,43.027703001],[-74.350357,43.028802001],[-74.34217,43.035565001],[-74.335830001,43.039841001]],[[-74.360901,43.013665001],[-74.358557,43.013592001],[-74.357467,43.013772001],[-74.356567,43.014214001],[-74.353729,43.016545001],[-74.351463001,43.017712001]],[[-74.385208,43.015484001],[-74.384799414,43.015297285],[-74.374367565,43.010530139],[-74.374315078,43.009100739],[-74.374314756,43.009091976],[-74.374214,43.006348001]]]}
-(1 row)
-~~~
-
-Paste the result above into <https://geojson.io> and you should see the following map:
-
-<img src="{{ 'images/v21.1/geospatial/tutorial/query-12.png' | relative_url }}" alt="What does the route from Mysteries on Main Street in Johnstown, NY to The Book Nook in Saranac Lake, NY look like?" style="max-width:100%" />
-
-### (13) What were the 25 most-commonly-sighted birds in 2019 within 10 miles of the route between Mysteries on Main Street in Johnstown, NY and The Bookstore Plus in Lake Placid, NY?
-
-A natural question that arises once you start traveling between stores is: if I decide to visit two of these stores in a day, and do some birdwatching in between, what are some of the bird species I may expect to find? In this case you are looking at what species are near the route between [Mysteries on Main Street in Johnstown, NY](https://www.facebook.com/MysteriesOnMainStreet), and [The Bookstore Plus in Lake Placid, NY](http://www.thebookstoreplus.com).
-
-To answer this question:
-
-1. Build a CTE that returns the route between the two stores of interest (a geometry).
-2. Join the results of the above CTE with a query against [the `birds` database](#the-birds-database) that checks whether the distance between the route geometry and the location of the bird observation (`birds.routes.geom`) bookstore's location is less than the desired length of 10 miles. Note that because the call to `ST_Distance` is operating on shapes cast to `GEOGRAPHY` data type, the results are in meters, which then have to be converted to miles by dividing the result by 1609 (the number of meters in a mile).
-
-{{site.data.alerts.callout_info}}
-The query below can also be written using an explicit `ST_DWithin`, which is an [index-accelerated function](spatial-data.html#performance). CockroachDB optimizes `ST_Distance(...) < $some_value` to use `ST_DWithin` (see this query's [`EXPLAIN`](explain.html) output for details).
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	bookstore_trip
-		AS (
-			SELECT
-				geom
-			FROM
-				bookstore_routes
-			WHERE
-				start_store_id
-				= (
-						SELECT
-							id
-						FROM
-							tutorial.bookstores
-						WHERE
-							city = 'Johnstown'
-							AND state = 'NY'
-					)
-				AND end_store_id
-					= (
-							SELECT
-								id
-							FROM
-								tutorial.bookstores
-							WHERE
-								city = 'Lake Placid'
-								AND state = 'NY'
-						)
-		)
-SELECT
-	birds.birds.name,
-	sum(birds.observations.count) AS sightings
-FROM
-	birds.birds,
-	birds.observations,
-	birds.routes,
-	bookstore_trip
-WHERE
-	birds.birds.id = birds.observations.bird_id
-	AND observations.route_id = routes.id
-	AND observations.year = 2019
-	AND st_distance(
-			bookstore_trip.geom::GEOGRAPHY,
-			birds.routes.geom::GEOGRAPHY
-		)
-		< (1609 * 10)
-GROUP BY
-	birds.name
-ORDER BY
-	sightings DESC
-LIMIT
-	25;
-~~~
-
-~~~
-                   name                  | sightings
------------------------------------------+------------
-  Red-eyed Vireo                         |       124
-  Ovenbird                               |        98
-  Blue Jay                               |        56
-  Black-capped Chickadee                 |        44
-  American Robin                         |        43
-  American Crow                          |        31
-  White-throated Sparrow                 |        26
-  Common Yellowthroat                    |        25
-  Red-breasted Nuthatch                  |        19
-  Blue-headed Vireo                      |        18
-  Red-winged Blackbird                   |        16
-  Veery                                  |        16
-  Winter Wren                            |        16
-  American Redstart                      |        15
-  Blackburnian Warbler                   |        15
-  Chipping Sparrow                       |        14
-  Least Flycatcher                       |        13
-  Northern Parula                        |        13
-  American Goldfinch                     |        13
-  Magnolia Warbler                       |        12
-  Cedar Waxwing                          |        12
-  Song Sparrow                           |        11
-  Hermit Thrush                          |        11
-  Common Raven                           |        10
-  (Myrtle Warbler) Yellow-rumped Warbler |        10
-(25 rows)
-~~~
-
-### (14) What are the 25 least often sighted other species of birds in the loon's sightings range?
-
-Since you are already looking for loons, you would like to know if there are other, more challenging birdwatching opportunities available within the loon habitat you are already visiting. Specifically, you would like to know: What are the least-often-observed bird species in the loon's habitat?
-
-To answer this question:
-
-1. Build a CTE that returns the [convex hull](st_convexhull.html) of Common Loon habitat.
-2. Join the results of the above CTE and a query against [the `birds` database](#the-birds-database) that lists the names and observation totals (sums) of birds whose habitats are contained within the convex hull of loon habitat.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_convexhull(st_collect(routes.geom))
-					AS loon_hull
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	birds.name, sum(birds.observations.count) AS sightings
-FROM
-	birds.birds,
-	birds.observations,
-	birds.routes,
-	loon_habitat
-WHERE
-	birds.id = observations.bird_id
-	AND observations.route_id = routes.id
-	AND st_contains(loon_hull, routes.geom)
-GROUP BY
-	birds.name
-ORDER BY
-	sightings ASC
-LIMIT
-	25;
-~~~
-
-~~~
-                        name                       | sightings
----------------------------------------------------+------------
-  Vesper Sparrow                                   |         1
-  Northern Saw-whet Owl                            |         1
-  Sora                                             |         1
-  Least Bittern                                    |         1
-  Palm Warbler                                     |         1
-  Ring-necked Duck                                 |         1
-  American Three-toed Woodpecker                   |         1
-  unid. Yellow-billed Cuckoo / Black-billed Cuckoo |         1
-  unid. Accipiter hawk                             |         1
-  Eastern Whip-poor-will                           |         1
-  Golden-winged Warbler                            |         1
-  Eastern Screech-Owl                              |         1
-  Northern Goshawk                                 |         1
-  Upland Sandpiper                                 |         1
-  Hooded Warbler                                   |         2
-  Grasshopper Sparrow                              |         2
-  Gadwall                                          |         2
-  Brewster Warbler (Golden-winged x Blue-winged)   |         2
-  Double-crested Cormorant                         |         3
-  White-winged Crossbill                           |         3
-  Marsh Wren                                       |         3
-  Pine Siskin                                      |         3
-  Great Horned Owl                                 |         3
-  Northern Mockingbird                             |         3
-  Red-shouldered Hawk                              |         4
-(25 rows)
-~~~
-
-## Step 7. Get road and travel info
-
-### (15) What are the top 10 roads nearest to a Loon sighting location in NY?
-
-So far, you have learned [where the birds are](#step-4-scout-loon-locations), [where the overlaps are between birds and bookstores](#step-5-find-bookstores-to-visit), and [how to travel between bookstores while finding birds](#step-6-plan-your-route).
-
-Now you will start asking questions that involve looking at [the `roads` table](#the-roads-table) as well.
-
-Specifically, you would like to know: What are the 10 roads that are closest to a loon observation site?  The answer to this question may help you figure out exactly which roads you should travel down to start the search for loons. The closer a road is to the sighting location, the better: it means there is probably less work to do to see the birds you are looking for.
-
-To answer this question:
-
-1. Build a CTE called `loon_habitat` that collects all of the Common Loon sightings into a single geometry.
-2. Build another CTE called `nearby_roads` that joins the results of the subquery above with [the `roads` table](#the-roads-table) and pulls out the roads in NY state that are within a degree (about 60 nautical miles). Order the roads returned by their distance from a loon sighting. This will return some duplicate roads (since loons can be sighted multiple times along a single road), which is why you need to `LIMIT` to 20 here so you can get the list down to 10 later. Because the data in the `roads` table has an SRID of 0, you need to use `ST_SetSRID` to set its SRID to [4326](srid-4326.html). This step is necessary because `ST_Distance` cannot operate on geometries with differing SRIDs.
-3. Finally, query the results of the `nearby_roads` subquery to get a list of 10 distinct road names that you can plan to visit.
-
-{{site.data.alerts.callout_info}}
-The query below can also be written using an explicit `ST_DWithin`, which is an [index-accelerated function](spatial-data.html#performance). CockroachDB optimizes `ST_Distance(...) < $some_value` to use `ST_DWithin` (see this query's [`EXPLAIN`](explain.html) output for details).
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_collect(routes.geom) AS geom
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		),
-	nearby_roads
-		AS (
-			SELECT
-				roads.prime_name AS road_name
-			FROM
-				roads, loon_habitat
-			WHERE
-				st_distance(
-					loon_habitat.geom,
-					st_setsrid(roads.geom, 4326)
-				)
-				< 1
-			ORDER BY
-				st_distance(
-					loon_habitat.geom,
-					st_setsrid(roads.geom, 4326)
-				)
-					ASC
-			LIMIT
-				20
-		)
-SELECT
-	DISTINCT road_name
-FROM
-	nearby_roads
-LIMIT
-	10;
-~~~
-
-~~~
-      prime_name
------------------------
-  US Route 9
-  State Route 30
-  State Route 22 Spur
-  State Route 22
-  State Route 28
-  State Route 86
-  State Route 28N
-  Interstate 87
-  US Route 11
-  State Route 421
-(10 rows)
-
-Time: 1.447s total (execution 1.446s / network 0.000s)
-~~~
-
-Unfortunately, this query is a bit slower than you would like: about 1.5 seconds on a single-node [`cockroach demo`](cockroach-demo.html) cluster on a laptop. There are several reasons for this:
-
-1. You haven't created any indexes at all yet. The query is likely to be doing full table scans, which you will need to hunt down with [`EXPLAIN`](explain.html).
-2. CockroachDB does not yet have built-in support for index-based nearest neighbor queries. If this feature is important to you, please comment with some information about your use case on [cockroachdb/cockroach#55227](https://github.com/cockroachdb/cockroach/issues/55227).
-
-Let's look at the `EXPLAIN` output to see if there is something that can be done to improve this query's performance:
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPLAIN WITH loon_habitat AS (SELECT st_collect(routes.geom) AS geom FROM birds.birds, birds.observations, birds.routes WHERE birds.name = 'Common Loon' AND birds.id = observations.bird_id AND observations.route_id = routes.id), nearby_roads AS (SELECT roads.prime_name AS road_name FROM roads, loon_habitat WHERE st_distance(loon_habitat.geom, st_setsrid(roads.geom, 4326)) < 1 ORDER BY st_distance(loon_habitat.geom, st_setsrid(roads.geom, 4326)) ASC LIMIT 20) SELECT DISTINCT road_name FROM nearby_roads LIMIT 10;
-~~~
-
-{% include copy-clipboard.html %}
-~~~
-                                tree                               |        field        |                      description
--------------------------------------------------------------------+---------------------+---------------------------------------------------------
-                                                                   | distribution        | full
-                                                                   | vectorized          | true
-  limit                                                            |                     |
-   │                                                               | count               | 10
-   └── distinct                                                    |                     |
-        │                                                          | distinct on         | road_name
-        └── render                                                 |                     |
-             └── limit                                             |                     |
-                  │                                                | count               | 20
-                  └── sort                                         |                     |
-                       │                                           | order               | +column48
-                       └── render                                  |                     |
-                            └── cross join                         |                     |
-                                 │                                 | pred                | st_dwithinexclusive(geom, st_setsrid(geom, 4326), 1.0)
-                                 ├── scan                          |                     |
-                                 │                                 | estimated row count | 225838
-                                 │                                 | table               | roads@primary
-                                 │                                 | spans               | FULL SCAN
-                                 └── render                        |                     |
-                                      └── group (scalar)           |                     |
-                                           └── hash join           |                     |
-                                                │                  | equality            | (route_id) = (id)
-                                                │                  | right cols are key  |
-                                                ├── hash join      |                     |
-                                                │    │             | equality            | (bird_id) = (id)
-                                                │    │             | right cols are key  |
-                                                │    ├── scan      |                     |
-                                                │    │             | Estimated row count | 85731
-                                                │    │             | table               | observations@primary
-                                                │    │             | spans               | FULL SCAN
-                                                │    └── filter    |                     |
-                                                │         │        | filter              | name = 'Common Loon'
-                                                │         └── scan |                     |
-                                                │                  | estimated row count | 756
-                                                │                  | table               | birds@primary
-                                                │                  | spans               | FULL SCAN
-                                                └── scan           |                     |
-                                                                   | estimated row count | 129
-                                                                   | table               | routes@primary
-                                                                   | spans               | FULL SCAN
-(40 rows)
-~~~
-
-As you can see above, there are several full table scans being performed (see `FULL SCAN`). For each table, you have a hypothesis on what is causing the scan; usually the hypothesis is that the table is missing an index.
-
-- For [the `roads` table](#the-roads-table), there is no [spatial index](spatial-indexes.html) on the `road.geom` column. This is probably the worst performance offender of the bunch, since this table has almost a quarter of a million rows. It makes sense that it's quite large, since it represents a road map of the entire United States.
-  - In addition to adding an index to `roads.geom`, you will need to update the SRID of the `roads.geom` column to use [SRID 4326](srid-4326.html) so it matches the SRID of the loon habitat geometry. Updating the SRID to match will allow you to stop using `ST_SetSRID` on `roads.geom` as shown above, which will keep CockroachDB from taking advantage of the spatial index on that column.
-- On [the `birds.observations` table](#the-birds-database), there is no index on the `birds.observations.route_id` or `birds.observations.bird_id` columns, which are used for all bird information lookups.
-- On the [`birds.birds` table](#the-birds-database), there is no index on the `birds.birds.name` column which you're filtering on (this is also used by almost all of your other bird-related queries).
-
-Based on these hypotheses, you take the following steps:
-
-1. Add an index to the `roads.geom` column. Note that creating the index on `roads.geom` takes about a minute on a single-node [`cockroach demo`](cockroach-demo.html) cluster, since the table is relatively large.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    CREATE INDEX ON roads USING GIST(geom);
-    ~~~
-
-2. Update the SRID of the `roads.geom` column from 0 to [4326](srid-4326.html). This will take a few seconds.
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    UPDATE roads SET geom = st_transform(st_setsrid(geom, 4326), 4326) WHERE gid IS NOT NULL RETURNING NOTHING;
-    ~~~
-
-3. Add indexes on the `birds.observations.route_id` and `birds.observations.bird_id` columns:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    CREATE INDEX ON birds.observations(bird_id);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    CREATE INDEX ON birds.observations(route_id);
-    ~~~
-
-4. Add an index on the `birds.birds.name` column:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    CREATE INDEX ON birds.birds(name);
-    ~~~
-
-Did adding all of these indexes and updating the road geometry SRIDs make this query any faster?  Let's check. Note that the query below has been modified to no longer use the `ST_SetSRID` function.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_collect(routes.geom) AS geom
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		),
-	nearby_roads
-		AS (
-			SELECT
-				roads.prime_name AS road_name
-			FROM
-				roads, loon_habitat
-			WHERE
-				st_distance(loon_habitat.geom, roads.geom)
-				< 1
-			ORDER BY
-				st_distance(loon_habitat.geom, roads.geom)
-					ASC
-			LIMIT
-				20
-		)
-SELECT
-	DISTINCT road_name
-FROM
-	nearby_roads
-LIMIT
-	10;
-~~~
-
-It looks like the answer is yes; you have sped up this query by about 30%:
-
-~~~
-      prime_name
------------------------
-  US Route 9
-  State Route 30
-  State Route 22 Spur
-  State Route 22
-  State Route 28
-  State Route 86
-  State Route 28N
-  Interstate 87
-  US Route 11
-  State Route 421
-(10 rows)
-
-Time: 998ms total (execution 998ms / network 0ms)
-~~~
-
-To see why, look at the [`EXPLAIN`](explain.html) output:
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPLAIN WITH loon_habitat AS (SELECT st_collect(routes.geom) AS geom FROM birds.birds, birds.observations, birds.routes WHERE birds.name = 'Common Loon' AND birds.id = observations.bird_id AND observations.route_id = routes.ID), nearby_roads AS (SELECT roads.prime_name AS road_name FROM roads, loon_habitat WHERE st_distance(loon_habitat.geom, roads.geom) < 1 ORDER BY st_distance(loon_habitat.geom, roads.geom) ASC LIMIT 20) SELECT DISTINCT road_name FROM nearby_roads LIMIT 10;
-~~~
-
-~~~
-                                   tree                                   |         field         |              description
---------------------------------------------------------------------------+-----------------------+----------------------------------------
-                                                                          | distribution          | full
-                                                                          | vectorized            | false
-  limit                                                                   |                       |
-   │                                                                      | count                 | 10
-   └── distinct                                                           |                       |
-        │                                                                 | distinct on           | road_name
-        └── render                                                        |                       |
-             └── limit                                                    |                       |
-                  │                                                       | count                 | 20
-                  └── sort                                                |                       |
-                       │                                                  | order                 | +column49
-                       └── render                                         |                       |
-                            └── lookup join                               |                       |
-                                 │                                        | table                 | roads@primary
-                                 │                                        | equality              | (gid) = (gid)
-                                 │                                        | equality cols are key |
-                                 │                                        | pred                  | st_dwithinexclusive(geom, geom, 1.0)
-                                 └── inverted join                        |                       |
-                                      │                                   | table                 | roads@roads_geom_idx
-                                      └── render                          |                       |
-                                           └── group (scalar)             |                       |
-                                                └── hash join             |                       |
-                                                     │                    | equality              | (route_id) = (id)
-                                                     │                    | right cols are key    |
-                                                     ├── lookup join      |                       |
-                                                     │    │               | table                 | observations@primary
-                                                     │    │               | equality              | (id) = (id)
-                                                     │    │               | equality cols are key |
-                                                     │    └── lookup join |                       |
-                                                     │         │          | table                 | observations@observations_bird_id_idx
-                                                     │         │          | equality              | (id) = (bird_id)
-                                                     │         └── scan   |                       |
-                                                     │                    | estimated row count   | 1
-                                                     │                    | table                 | birds@birds_name_idx
-                                                     │                    | spans                 | [/'Common Loon' - /'Common Loon']
-                                                     └── scan             |                       |
-                                                                          | estimated row count   | 129
-                                                                          | table                 | routes@primary
-                                                                          | spans                 | FULL SCAN
-(39 rows)
-~~~
-
-Based on the output above, you notice the following improvements:
-
-- The [spatial index](spatial-indexes.html) on `roads.geom` is being used by the join between that column and the loon habitat geometry. This is the biggest reason for improved performance, since [the `roads` table](#the-roads-table) has ~225,000 rows.
-- You no longer appear to be scanning all ~85,000 rows of [the `birds.observations` table](#the-birds-database) thanks to the index on the `birds.observations.bird_id` column.
-- You are probably getting a small speedup from the index on [`birds.birds.name`](#the-birds-database) (although that table is not very large, only about 750 rows).
-
-### (16) How many miles of roads are contained within the portion of the Loon habitat that lies within NY state?
-
-It may not be immediately relevant to your birdwatching or book-buying travels, but a question of general interest that could arise is: How many miles of roads are contained within loon habitat?
-
-To answer this:
-
-1. Build a CTE that returns the [convex hull](st_convexhull.html) of Common Loon habitat.
-2. Join the results of the above CTE and a query against [the `roads` table](#the-roads-table) that sums the mileage of all roads that are contained within the convex hull of loon habitat.
-
-{{site.data.alerts.callout_info}}
-Because you are using `ST_Contains`, the query below only sums the road mileages of roads whose geometries lie entirely within the loon habitat.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_convexhull(st_collect(routes.geom))
-					AS hull
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	sum(roads.miles)
-FROM
-	roads, loon_habitat
-WHERE
-	roads.state = 'NY'
-	AND st_contains(
-			loon_habitat.hull,
-			roads.geom
-		);
-~~~
-
-The answer to your question is that there are about 1,700 miles of roads within the Common Loon's habitat. Further, you can change the `WHERE` clause of the above query slightly to say `AND (NOT (ST_Contains(...)))` to find out how many miles of roads in NY state are _not_ within loon habitat (it's about 14,600).
-
-~~~
-          sum
------------------------
-  1704.65731711040306
-(1 row)
-~~~
-
-### (17) Which bookstore in the Loon's region in NY has the fewest miles of roads within a 10 mile radius of the store?
-
-As you are driving around the Adirondacks, searching for loons as well as your next great read, the question occurs to you: Which bookstore is the most remotely located?  This is important since one of your goals for this vacation is to "get away from it all." You do not have population density data, but you do have road data. Therefore you decide to use "miles of roads near the store" as a rough proxy for which store location is the most remote: the fewer miles of roads near the store, the more remote you can assume it is.
-
-To answer this question:
-
-1. Build a CTE that returns the [convex hull](st_convexhull.html) of Common Loon habitat.
-2. Build a CTE that joins [the `bookstores` table](#the-bookstores-and-bookstore_routes-tables) and the results of the above subquery to generate a set of bookstores inside the loon's habitat area.
-3. Finally, generate a query that joins the results of the above subquery against [the `roads` table](#the-roads-table) based on which roads are within a 10 mile radius. This generates a list of bookstores and the number of miles of nearby roads, sorted in order of which store has the fewest miles of road nearby.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_convexhull(st_collect(routes.geom))
-					AS geom
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		),
-	loon_bookstores
-		AS (
-			SELECT
-				bookstores.name,
-				address,
-				bookstores.geom AS geom
-			FROM
-				bookstores, loon_habitat
-			WHERE
-				st_contains(
-					loon_habitat.geom,
-					bookstores.geom
-				)
-		)
-SELECT
-	loon_bookstores.name,
-	address,
-	sum(roads.miles)::INT AS nearby_road_miles
-FROM
-	roads, loon_bookstores
-WHERE
-	st_distance(
-		loon_bookstores.geom,
-		roads.geom
-	)
-	< (10 / 69)
-GROUP BY
-	loon_bookstores.name, address
-ORDER BY
-	nearby_road_miles ASC;
-~~~
-
-You get an answer, but unfortunately it's rather slow: about 6 seconds!
-
-~~~
-                        name                       |                    address                     | nearby_road_miles
----------------------------------------------------+------------------------------------------------+--------------------
-  The Bookstore Plus Music &amp; Art               | 2491 Main St, Lake Placid, NY, 12946           |                40
-  The Book Nook (Saranac Lake, NY)                 | 7 Broadway, Saranac Lake, NY, 12983            |                81
-  Blacktree Books                                  | 5006 State Highway 23, Oneonta, NY, 13820      |               106
-  The Green Toad Bookstore                         | 198 Main St, Oneonta, NY, 13820                |               107
-  Gansevoort House Books at Gems Along the Mohawk  | 800 Mohawk St, Herkimer, NY, 13350             |               136
-  Gansevoort House Books at The Shoppes at 25 West | 25 W Mill Street, Little Falls, NY, 13365      |               155
-  The Treehouse Reading and Arts Center            | 587 Main St Ste 304, New York Mills, NY, 13417 |               156
-  Mysteries On Main Street                         | 144 W Main St, Johnstown, NY, 12095            |               172
-(8 rows)
-
-Time: 6.214s total (execution 6.214s / network 0.000s)
-~~~
-
-Let's look at the `EXPLAIN` output to see if there is something that can be done to improve this query's performance:
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPLAIN WITH loon_habitat AS (SELECT st_convexhull(st_collect(routes.geom)) AS geom FROM birds.birds, birds.observations, birds.routes WHERE birds.name = 'Common Loon' AND birds.id = observations.bird_id AND observations.route_id = routes.id), loon_bookstores AS (SELECT bookstores.name, address, bookstores.geom AS geom FROM bookstores, loon_habitat WHERE st_contains(loon_habitat.geom, bookstores.geom)) SELECT loon_bookstores.name, address, sum(roads.miles)::INT AS nearby_road_miles FROM roads, loon_bookstores WHERE st_distance(loon_bookstores.geom, roads.geom) < (10 / 69) GROUP BY loon_bookstores.name, address ORDER BY nearby_road_miles ASC;
-~~~
-
-~~~
-                              tree                              |         field         |                     description
-----------------------------------------------------------------+-----------------------+-------------------------------------------------------
-                                                                | distribution          | full
-                                                                | vectorized            | true
-  sort                                                          |                       |
-   │                                                            | order                 | +nearby_road_miles
-   └── render                                                   |                       |
-        └── group                                               |                       |
-             │                                                  | group by              | name, address
-             └── cross join                                     |                       |
-                  │                                             | pred                  | st_dwithinexclusive(geom, geom, 0.14492753623188406)
-                  ├── scan                                      |                       |
-                  │                                             | estimated row count   | 225838
-                  │                                             | table                 | roads@primary
-                  │                                             | spans                 | FULL SCAN
-                  └── render                                    |                       |
-                       └── cross join                           |                       |
-                            │                                   | pred                  | st_contains(geom, geom)
-                            ├── scan                            |                       |
-                            │                                   | estimated row count   | 2913
-                            │                                   | table                 | bookstores@primary
-                            │                                   | spans                 | FULL SCAN
-                            └── render                          |                       |
-                                 └── group (scalar)             |                       |
-                                      └── hash join             |                       |
-                                           │                    | equality              | (route_id) = (id)
-                                           │                    | right cols are key    |
-                                           ├── lookup join      |                       |
-                                           │    │               | table                 | observations@primary
-                                           │    │               | equality              | (id) = (id)
-                                           │    │               | equality cols are key |
-                                           │    └── lookup join |                       |
-                                           │         │          | table                 | observations@observations_bird_id_idx
-                                           │         │          | equality              | (id) = (bird_id)
-                                           │         └── scan   |                       |
-                                           │                    | estimated row count   | 1
-                                           │                    | table                 | birds@birds_name_idx
-                                           │                    | spans                 | [/'Common Loon' - /'Common Loon']
-                                           └── scan             |                       |
-                                                                | estimated row count   | 129
-                                                                | table                 | routes@primary
-                                                                | spans                 | FULL SCAN
-(40 rows)
-~~~
-
-Looking at these results from the bottom up, you can see that:
-
-1. There is a full table scan happening on the `birds.birds.routes` table. Since it's so small (129 rows), let's move on for now.
-2. There is a full table scan on the `bookstores` table. Since the predicate is [`ST_Contains`](st_contains.html), you probably need to add a [spatial index](spatial-indexes.html) on `bookstores.geom`.
-3. There is a full table scan happening on the `roads` table. This is a serious problem due to the size of that table: ~225,000 rows. You already have an index on the `roads.geom` column for the `ST_DWithin` predicate to use, so you need to find another way to reduce the number of rows scanned. You can do what you did in [query 16][q_16] and add a check that the `roads.state = 'NY'`, since you are only looking at roads inside New York State.
-
-Based on these observations, you add an index to the `bookstores.geom` column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-CREATE INDEX ON bookstores USING GIST(geom);
-~~~
-
-After adding the index, you modify your query as shown below to filter on `roads.state`.  This looks only at roads in New York (as in [query 16][q_16]):
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_convexhull(st_collect(routes.geom))
-					AS geom
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		),
-	loon_bookstores
-		AS (
-			SELECT
-				bookstores.name,
-				address,
-				bookstores.geom AS geom
-			FROM
-				bookstores, loon_habitat
-			WHERE
-				st_contains(
-					loon_habitat.geom,
-					bookstores.geom
-				)
-		)
-SELECT
-	loon_bookstores.name,
-	address,
-	sum(roads.miles)::INT8 AS nearby_road_miles
-FROM
-	roads, loon_bookstores
-WHERE
-	roads.state = 'NY'
-	AND st_distance(
-			roads.geom,
-			loon_bookstores.geom
-		)
-		< (10 / 69)
-GROUP BY
-	loon_bookstores.name, address
-ORDER BY
-	nearby_road_miles ASC;
-~~~
-
-The steps above brings your query execution down to about 400ms!
-
-~~~
-                        name                       |                    address                     | nearby_road_miles
----------------------------------------------------+------------------------------------------------+--------------------
-  The Bookstore Plus Music &amp; Art               | 2491 Main St, Lake Placid, NY, 12946           |                40
-  The Book Nook (Saranac Lake, NY)                 | 7 Broadway, Saranac Lake, NY, 12983            |                81
-  Blacktree Books                                  | 5006 State Highway 23, Oneonta, NY, 13820      |               106
-  The Green Toad Bookstore                         | 198 Main St, Oneonta, NY, 13820                |               107
-  Gansevoort House Books at Gems Along the Mohawk  | 800 Mohawk St, Herkimer, NY, 13350             |               136
-  Gansevoort House Books at The Shoppes at 25 West | 25 W Mill Street, Little Falls, NY, 13365      |               155
-  The Treehouse Reading and Arts Center            | 587 Main St Ste 304, New York Mills, NY, 13417 |               156
-  Mysteries On Main Street                         | 144 W Main St, Johnstown, NY, 12095            |               172
-(8 rows)
-
-Time: 376ms total (execution 376ms / network 0ms)
-~~~
-
-When you look at `EXPLAIN` for the modified query, you see why: the filter on `roads.state='NY'` means you are scanning far fewer columns of the `roads` table (~8,900), and the index on `bookstores.geom` means you are using that index now as well:
-
-{% include copy-clipboard.html %}
-~~~ sql
-EXPLAIN WITH loon_habitat AS (SELECT st_convexhull(st_collect(routes.geom)) AS geom FROM birds.birds, birds.observations, birds.routes WHERE birds.name = 'Common Loon' AND birds.id = observations.bird_id AND observations.route_id = routes.id), loon_bookstores AS (SELECT bookstores.name, address, bookstores.geom AS geom FROM bookstores, loon_habitat WHERE st_contains(loon_habitat.geom, bookstores.geom)) SELECT loon_bookstores.name, address, sum(roads.miles)::INT8 AS nearby_road_miles FROM roads, loon_bookstores WHERE roads.state = 'NY' AND st_distance(roads.geom, loon_bookstores.geom) < (10 / 69) GROUP BY loon_bookstores.name, address ORDER BY nearby_road_miles ASC;
-~~~
-
-~~~
-                                 tree                                |         field         |                              description
----------------------------------------------------------------------+-----------------------+-------------------------------------------------------------------------
-                                                                     | distribution          | full
-                                                                     | vectorized            | true
-  sort                                                               |                       |
-   │                                                                 | order                 | +nearby_road_miles
-   └── render                                                        |                       |
-        └── group                                                    |                       |
-             │                                                       | group by              | name, address
-             └── cross join                                          |                       |
-                  │                                                  | pred                  | st_dwithinexclusive(geom, geom, 0.14492753623188406)
-                  ├── index join                                     |                       |
-                  │    │                                             | table                 | roads@primary
-                  │    └── scan                                      |                       |
-                  │                                                  | estimated row count   | 8899
-                  │                                                  | table                 | roads@roads_state_idx
-                  │                                                  | spans                 | [/'NY' - /'NY']
-                  └── render                                         |                       |
-                       └── lookup join                               |                       |
-                            │                                        | table                 | bookstores@primary
-                            │                                        | equality              | (id) = (id)
-                            │                                        | equality cols are key |
-                            │                                        | pred                  | st_contains(geom, geom)
-                            └── inverted join                        |                       |
-                                 │                                   | table                 | bookstores@bookstores_geom_idx
-                                 └── render                          |                       |
-                                      └── group (scalar)             |                       |
-                                           └── hash join             |                       |
-                                                │                    | equality              | (route_id) = (id)
-                                                │                    | right cols are key    |
-                                                ├── lookup join      |                       |
-                                                │    │               | table                 | observations@primary
-                                                │    │               | equality              | (id) = (id)
-                                                │    │               | equality cols are key |
-                                                │    └── lookup join |                       |
-                                                │         │          | table                 | observations@observations_bird_id_idx
-                                                │         │          | equality              | (id) = (bird_id)
-                                                │         └── scan   |                       |
-                                                │                    | estimated row count   | 1
-                                                │                    | table                 | birds@birds_name_idx
-                                                │                    | spans                 | [/'Common Loon' - /'Common Loon']
-                                                └── scan             |                       |
-                                                                     | estimated row count   | 129
-                                                                     | table                 | routes@primary
-                                                                     | spans                 | FULL SCAN
-~~~
-
-## Step 8. Find other birds
-
-### (18) What are the hawks sighted in the same region as the Common Loon?
-
-If you get tired of looking for Common Loons (and it's understandable that you might), you may want to widen your search to other types of birds. You have already looked at [different bird species based on frequency of observation][q_13]. Now you turn your attention to a specific type of bird: hawks.
-
-Due to your long birdwatching experience, you recall that hawks are in the family "Accipitridae". You can use this knowledge to answer the question: What hawks live in the same region as the Common Loon in New York State?
-
-To answer this question:
-
-1. Build a CTE that returns the [convex hull](st_convexhull.html) of Common Loon habitat.
-2. Join the results of the above subquery with [the `birds` database](#the-birds-database) to find the names and observation counts of the birds that:
-  1. Are in the family "Accipitridae".
-  2. Have sighting locations whose geometry is contained by the hull describing the Common Loon's habitat.
-3. Order the birds in the list by how frequently they are sighted, since you may want to look for the most common hawks first.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_collect(routes.geom) AS geom
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	birds.name, sum(birds.observations.count) AS sightings
-FROM
-	birds.birds,
-	birds.observations,
-	birds.routes,
-	loon_habitat
-WHERE
-	birds.family = 'Accipitridae'
-	AND birds.id = observations.bird_id
-	AND observations.route_id = routes.id
-	AND st_contains(loon_habitat.geom, routes.geom)
-GROUP BY
-	birds.name
-ORDER BY
-	sightings DESC;
-~~~
-
-Based on this data, it looks like the most commonly sighted hawk by far in the area over the years 2000-2019 is the <a href="https://ebird.org/species/brwhaw" data-proofer-ignore>Broad-winged Hawk</a>:
-
-~~~
-          name         | sightings
------------------------+------------
-  Broad-winged Hawk    |       115
-  Red-tailed Hawk      |        33
-  Northern Harrier     |        12
-  Red-shouldered Hawk  |        11
-  Sharp-shinned Hawk   |         9
-  Bald Eagle           |         9
-  Cooper Hawk          |         7
-  Northern Goshawk     |         5
-  unid. Accipiter hawk |         1
-(9 rows)
-~~~
-
-### (19) What if you also want to look for owls as well as hawks?
-
-If you are a fan of owls as well as hawks, you can make several updates to [the previous query][q_18], which just looked for hawks. In particular, you want to group the hawks together and the owls together.
-
-To answer this question:
-
-1. Build a CTE that returns the [convex hull](st_convexhull.html) of Common Loon habitat.
-2. Join the results of the above subquery with [the `birds` database](#the-birds-database) to find the names and observation counts of the birds that:
-  1. Are in the family "Accipitridae" (hawks) _or_ the family "Strigidae" (owls).
-  2. Have sighting locations whose geometry is contained by the hull describing the Common Loon's habitat.
-3. Group the birds by name and family, and within each grouping order the birds by how frequently they are sighted, since you may want to look for the most common hawks or owls first.
-
-{% include copy-clipboard.html %}
-~~~ sql
-WITH
-	loon_habitat
-		AS (
-			SELECT
-				st_collect(routes.geom) AS geom
-			FROM
-				birds.birds,
-				birds.observations,
-				birds.routes
-			WHERE
-				birds.name = 'Common Loon'
-				AND birds.id = observations.bird_id
-				AND observations.route_id = routes.id
-		)
-SELECT
-	birds.name,
-	birds.family,
-	sum(birds.observations.count) AS sightings
-FROM
-	birds.birds,
-	birds.observations,
-	birds.routes,
-	loon_habitat
-WHERE
-	(
-		birds.family = 'Accipitridae'
-		OR birds.family = 'Strigidae'
-	)
-	AND birds.id = observations.bird_id
-	AND observations.route_id = routes.id
-	AND st_contains(loon_habitat.geom, routes.geom)
-GROUP BY
-	birds.name, birds.family
-ORDER BY
-	birds.family, sightings DESC;
-~~~
-
-~~~
-          name          |    family    | sightings
-------------------------+--------------+------------
-  Broad-winged Hawk     | Accipitridae |       115
-  Red-tailed Hawk       | Accipitridae |        33
-  Northern Harrier      | Accipitridae |        12
-  Red-shouldered Hawk   | Accipitridae |        11
-  Sharp-shinned Hawk    | Accipitridae |         9
-  Bald Eagle            | Accipitridae |         9
-  Cooper Hawk           | Accipitridae |         7
-  Northern Goshawk      | Accipitridae |         5
-  unid. Accipiter hawk  | Accipitridae |         1
-  Barred Owl            | Strigidae    |        44
-  Eastern Screech-Owl   | Strigidae    |         3
-  Great Horned Owl      | Strigidae    |         1
-  Northern Saw-whet Owl | Strigidae    |         1
-(13 rows)
-~~~
-
-## Next steps
-
-Now that you are familiar with writing and tuning spatial queries, you are ready for the following steps:
-
-- Learn more details about the [spatial features](spatial-features.html) supported by CockroachDB.
-
-- Learn how to migrate spatial data from [shapefiles](migrate-from-shapefiles.html), [GeoPackages](migrate-from-geopackage.html), [GeoJSON](migrate-from-geojson.html), or [OpenStreetMap](migrate-from-openstreetmap.html) into CockroachDB.
-
-- Learn how CockroachDB's [spatial indexes](spatial-indexes.html) work.
-
-## Appendix
-
-### Spatial features and corresponding queries
-
-The queries are presented above in a "narrative order" that corresponds roughly to the order in which you might ask questions about bookstores and loon habitat as you plan for your vacation.
-
-However, you may just want to see what queries are exercising a specific [spatial feature](spatial-features.html) supported by CockroachDB. The table below provides a mapping from a feature (such as 'spatial indexing' or 'spatial joins') to the queries that use that feature.
-
-| Feature                      | Queries                                                                                                                                                | Description(s)                                                                                                                                                            |
-|------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Spatial data set preparation | N/A                                                                                                                                                    | For information about how this data set was prepared, see the relevant portions of the [Data set description](#data-set-description).                                     |
-| Loading spatial data         | N/A                                                                                                                                                    | For loading instructions on loading the data set, see [Loading the data set](#step-3-load-the-data-set).                                                                      |
-| Spatial joins                | [#6][q_06], [#7][q_07], [#8][q_08], [#9][q_09], [#10][q_10], [#13][q_13], [#14][q_14], [#15][q_15], [#16][q_16], [#17][q_17], [#18][q_18], [#19][q_19] | Joins that involve comparing spatial features from two or more tables, usually with a predicate such as [`ST_Contains`](st_contains.html).                                |
-| Spatial indexing             | [#15][q_15], [#17][q_17]                                                                                                                               | These queries show explicit spatial index creation; many of the spatial join queries listed above could use these indexes, once created.                                  |
-| Spatial relationships        | [#6][q_06], [#7][q_07], [#8][q_08], [#9][q_09], [#10][q_10], [#13][q_13], [#14][q_14], [#15][q_15], [#16][q_16], [#17][q_17], [#18][q_18], [#19][q_19] | Comparing spatial relationships with predicates such as [`ST_Contains`](st_contains.html) and `ST_DWithin`.                                                               |
-| Nearest-neighbor searching   | [#15][q_15]                                                                                                                                            | This query shows how to execute a nearest-neighbor search using CockroachDB. |
-
-### Data set description
-
-This section contains an overview of the data sets and how they were constructed and put together. Because this data set is a "compound data set" that is built from several other data sets, there is some complexity to the schema that you will have to navigate.
-
-The data set contains two databases:
-
-- [The `tutorial` database](#the-tutorial-database)
-- [The `birds` database](#the-birds-database)
-
-#### The `tutorial` database
-
-The `tutorial` database contains the following tables:
-
-- [The `bookstores` table](#the-bookstores-and-bookstore_routes-tables) stores the independent bookstore information such as name, address, geo-location, etc.
-- [The `bookstore_routes` table](#the-bookstores-and-bookstore_routes-tables) is a small table containing just the routes between the local bookstores that lie within the loon's Adirondack habitat (this will be explained in more detail below).
-- [The `roads` table](#the-roads-table) is where the U.S. National Atlas road data is kept.
-
-##### The `bookstores` and `bookstore_routes` tables
-
-Below is an entity-relationship diagram showing the `bookstores` and `bookstore_routes` tables (generated using [DBeaver](dbeaver.html)):
-
-<img src="{{ 'images/v21.1/geospatial/tutorial/er-bookstores.png' | relative_url }}" alt="tutorial.bookstores and tutorial.bookstore_routes ER diagrams" style="max-width:100%" />
-
-As mentioned above, the `bookstores` table was created by scraping web data from the [American Booksellers Association website's member directory](https://bookweb.org/member_directory/search/ABAmember). In addition, the `geom` column was constructed by doing some [address geocoding](https://en.wikipedia.org/wiki/Address_geocoding) that converted each bookstore's address to a lon/lat pair and converted to a spatial object using `ST_MakePoint`. For each bookstore, the script did a bit of parsing and geocoding and ran essentially the following query:
-
-{% include copy-clipboard.html %}
-~~~ sql
-INSERT
-INTO
-	bookstores
-		(
-			name,
-			url,
-			phone,
-			address,
-			street,
-			city,
-			state,
-			zip,
-			description,
-			geom
-		)
-VALUES
-	(
-		'$name',
-		'$url',
-		'$phone',
-		'$address',
-		'$street',
-		'$city',
-		'$state',
-		'$zip',
-		'$description',
-		(
-			SELECT
-				st_setsrid(
-					st_makepoint('$lon', '$lat'),
-					4326
-				)
-		)
-	);
-~~~
-
-Similarly, the paths (specifically [MultiLinestrings](multilinestring.html)) between bookstores in the `bookstore_routes` table were also calculated using a script that made use of a simple greedy algorithm to find paths between the bookstores using the `roads` table (described below). The algorithm always looks for the next road that will bring you closer to the destination. It is fine for this small use case, but it is not robust enough for any kind of production use, since it does not perform any backtracking when it gets stuck in a local optimum. The algorithm works as follows, and assumes a starting bookstore _A_ and an ending bookstore _B_:
-
-1. (Start) Find the road nearest _A_; call this road _R_<sub>A</sub>.
-2. Find the road nearest the destination _B_; call this road _R_<sub>B</sub>.
-3. Do _R_<sub>A</sub> and _R_<sub>B</sub> intersect?  If so, the algorithm is done. You have arrived at your destination. (This is the recursive base case.)
-4. Otherwise, find the roads that intersect with _R_<sub>A</sub>. Of these roads, choose the one that passes closest to _R_<sub>B</sub>. Call it _R_<sub>A'</sub>.
-5. Do _R_<sub>A'</sub> and _R_<sub>B</sub> intersect?  If so, the algorithm is done. You have arrived at your destination.
-6. If the algorithm has arrived at this step without finishing, it goes back to step 4 and applies that step to the current "closest road to destination" _R_<sub>A'</sub>, and keeps operating steps 4-6 recursively until it has found a complete path or it hits some kind of heuristic timeout.
-
-{{site.data.alerts.callout_info}}
-For more information about production quality map routing software that uses OpenStreetMap, see [the OpenStreetMap wiki page on Routing](https://wiki.openstreetmap.org/wiki/Routing).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-There are multiple ways to do geocoding. You can use REST API-based services or do the geocoding yourself by processing [TIGER/LINE address data](https://www2.census.gov/geo/tiger/tigerua/) using a library for that purpose. For more information about some of the options available to you, see [this OpenStreetMap wiki page on geocoders](https://wiki.openstreetmap.org/wiki/Search_engines) or [this list of open source geocoding software](http://www.tsusiatsoftware.net/geocode.html).
-{{site.data.alerts.end}}
-
-##### The `roads` table
-
-Meanwhile, the `roads` table has many columns; the most important ones used in this tutorial are `state`, `geom`, `miles`, and `prime_name` (the human-readable name of the road).
-
-<img src="{{ 'images/v21.1/geospatial/tutorial/er-roads.png' | relative_url }}" alt="tutorial.roads ER diagrams" style="max-width:100%" />
-
-For more information about what the other columns in `roads` mean, see the [full data set description](https://www.sciencebase.gov/catalog/file/get/581d052be4b08da350d524ce?f=__disk__60%2F6b%2F4e%2F606b4e564884da8cca57ffeb229cd817006616e0&transform=1&allowOpen=true).
-
-{{site.data.alerts.callout_info}}
-The `roads` table was imported from a [shapefile](https://prd-tnm.s3.amazonaws.com/StagedProducts/Small-scale/data/Transportation/roadtrl010g.shp_nt00920.tar.gz) using the method described in [Migrate from Shapefiles](migrate-from-shapefiles.html).
-{{site.data.alerts.end}}
-
-#### The `birds` database
-
-The `birds` database contains several tables that you will have to [join](joins.html) together in most of the queries shown elsewhere on this page. The multi-table design reflects [the schema of the actual data set](https://www.sciencebase.gov/catalog/file/get/5ea04e9a82cefae35a129d65?f=__disk__b4%2F2f%2Fcf%2Fb42fcfe28a799db6e8c97200829ea1ebaccbf8ea&transform=1&allowOpen=true), which is split across files that map to these tables.
-
-The tables in the `birds` database are diagrammed below:
-
-- `birds` is a list of ~750 bird species. Most queries will use the `name` column.
-- `routes` is a list of ~130 prescribed locations that the birdwatchers helping with the survey visit each year. The `geom` associated with each route is a [Point](point.html) marking the latitude and longitude of the route's starting point. For details, see the [schema](https://www.sciencebase.gov/catalog/file/get/5ea04e9a82cefae35a129d65?f=__disk__b4%2F2f%2Fcf%2Fb42fcfe28a799db6e8c97200829ea1ebaccbf8ea&transform=1&allowOpen=true) (search for the text "routes.csv").
-- `observations` describes the ~85,000 times and places in which birds of various species were actually seen. The `bird_id` is a [foreign key](foreign-key.html) to the ID in the `birds` table, and the `route_id` points to the ID of the `routes` table.
-
-<img src="{{ 'images/v21.1/geospatial/tutorial/er-birds.png' | relative_url }}" alt="birds.birds, birds.routes, and birds.observations ER diagrams" style="max-width:100%" />
-
-Each of these tables were populated using a script that parsed [the CSV files available for download](https://www.sciencebase.gov/catalog/item/52b1dfa8e4b0d9b325230cd9) and added the data using [`INSERT`](insert.html) statements. For the `routes` table, once again the `ST_MakePoint` function was used to create a geometry from the lon/lat values in the CSV as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-INSERT
-INTO
-	routes (id, name, country, state, geom)
-VALUES
-	(
-		'$route_id',
-		'$route_name',
-		'$country',
-		'$state',
-		(
-			SELECT
-				st_setsrid(
-					st_makepoint('$lon', '$lat'),
-					4326
-				)
-		)
-	);
-~~~
-
-{{site.data.alerts.callout_info}}
-This data is stored in a separate `birds` database due to the fact that it is split into several tables. It could also have been added to the `tutorial` database by naming the tables something like `bird_species`, `bird_routes`, and `bird_observations`.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Install CockroachDB](install-cockroachdb.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial Features](spatial-features.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial & GIS Glossary of Terms](spatial-glossary.html)
-- [Working with Spatial Data](spatial-data.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [POINT](point.html)
-- [LINESTRING](linestring.html)
-- [POLYGON](polygon.html)
-- [MULTIPOINT](multipoint.html)
-- [MULTILINESTRING](multilinestring.html)
-- [MULTIPOLYGON](multipolygon.html)
-- [GEOMETRYCOLLECTION](geometrycollection.html)
-- [Well known text](well-known-text.html)
-- [Well known binary](well-known-binary.html)
-- [GeoJSON](geojson.html)
-- [SRID 4326 - longitude and latitude](srid-4326.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_Union`](st_union.html)
-- [`ST_Within`](st_within.html)
-- [Troubleshooting overview](troubleshooting-overview.html)
-- [Support resources](support-resources.html)
-
-<!-- Reference links -->
-
-[q_01]: #1-where-has-the-common-loon-been-sighted-by-the-nabbs-in-the-years-2000-2019-in-ny-state
-[q_02]: #2-what-is-the-total-area-of-loon-sightings
-[q_03]: #3-how-many-loon-sightings-have-there-been-in-ny-state-in-the-years-2000-2019
-[q_04]: #4-how-many-loon-sightings-were-there-in-ny-state-in-just-the-year-2019
-[q_05]: #5-what-is-the-density-of-loon-sightings-per-square-mile-in-its-range-as-defined-by-this-data-set-in-2019
-[q_06]: #6-what-are-the-bookstores-that-lie-within-the-loons-habitat-range-in-ny-state
-[q_07]: #7-how-many-different-species-of-bird-habitats-contain-the-location-of-the-book-nook-in-saranac-lake-ny
-[q_08]: #8-which-25-birds-were-most-often-sighted-within-10-miles-of-the-book-nook-in-saranac-lake-ny-during-the-2000-2019-observation-period
-[q_09]: #9-what-does-the-shape-of-all-bookstore-locations-that-lie-within-the-loons-habitat-look-like
-[q_10]: #10-what-is-the-area-of-the-shape-of-all-bookstore-locations-that-are-in-the-loons-habitat-range-within-ny-state
-[q_11]: #11-how-long-is-the-route-from-mysteries-on-main-street-in-johnstown-ny-to-the-book-nook-in-saranac-lake-ny
-[q_12]: #12-what-does-the-route-from-mysteries-on-main-street-in-johnstown-ny-to-the-book-nook-in-saranac-lake-ny-look-like
-[q_13]: #13-what-were-the-25-most-commonly-sighted-birds-in-2019-within-10-miles-of-the-route-between-mysteries-on-main-street-in-johnstown-ny-and-the-bookstore-plus-in-lake-placid-ny
-[q_14]: #14-what-are-the-25-least-often-sighted-other-species-of-birds-in-the-loons-sightings-range
-[q_15]: #15-what-are-the-top-10-roads-nearest-to-a-loon-sighting-location-in-ny
-[q_16]: #16-how-many-miles-of-roads-are-contained-within-the-portion-of-the-loon-habitat-that-lies-within-ny-state
-[q_17]: #17-which-bookstore-in-the-loons-region-in-ny-has-the-fewest-miles-of-roads-within-a-10-mile-radius-of-the-store
-[q_18]: #18-what-are-the-hawks-sighted-in-the-same-region-as-the-common-loon
-[q_19]: #19-what-if-you-also-want-to-look-for-owls-as-well-as-hawks
-
-<!-- EOF -->
diff --git a/src/current/v20.2/split-at.md b/src/current/v20.2/split-at.md
deleted file mode 100644
index 8730f02b259..00000000000
--- a/src/current/v20.2/split-at.md
+++ /dev/null
@@ -1,264 +0,0 @@
----
-title: SPLIT AT
-summary: The SPLIT AT statement forces a range split at the specified row in a table or index.
-toc: true
----
-
-The `SPLIT AT` [statement](sql-statements.html) forces a range split at the specified row in a table or index.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/split_table_at.html %}
-</div>
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/split_index_at.html %}
-</div>
-
-## Required privileges
-
-The user must have the `INSERT` [privilege](authorization.html#assign-privileges) on the table or index.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `table_name`<br>`table_name @ index_name` | The name of the table or index that should be split.
- `select_stmt` | A [selection query](selection-queries.html) that produces one or more rows at which to split the table or index.
- `a_expr` | The expiration of the split enforcement on the table or index. This can be a [`DECIMAL`](decimal.html), [`INTERVAL`](interval.html), [`TIMESTAMP`](timestamp.html), or [`TIMESTAMPZ`](timestamp.html).
-
-## Why manually split a range?
-
-CockroachDB breaks data into ranges. By default, CockroachDB attempts to keep ranges below
-a size of 512 MiB. To do this, the system will automatically [split](architecture/distribution-layer.html#range-splits)
-a range if it grows larger than this limit. For most use cases, this automatic
-range splitting is sufficient, and you should never need to worry about
-when or where the system decides to split ranges.
-
-However, there are reasons why you may want to perform manual splits on
-the ranges that store tables or indexes:
-
-- When a table only consists of a single range, all writes and reads to the
-  table will be served by that range's [leaseholder](architecture/replication-layer.html#leases).
-  If a table only holds a small amount of data but is serving a large amount of traffic,
-  load distribution can become unbalanced. Splitting the table's ranges manually
-  can allow the load on the table to be more evenly distributed across multiple
-  nodes. For tables consisting of more than a few ranges, load will naturally
-  be distributed across multiple nodes and this will not be a concern.
-
-- When a table is created, it will only consist of a single range. If you know
-  that a new table will immediately receive significant write
-  traffic, you may want to preemptively split the table based on the expected
-  distribution of writes before applying the load. This can help avoid reduced
-  workload performance that results when automatic splits are unable to keep up
-  with write traffic.
-
-Note that when a table is [truncated](truncate.html), it is essentially re-created in a single new empty range, and the old ranges that used to constitute the table are garbage collected. Any pre-splitting you have performed on the old version of the table will not carry over to the new version. The new table will need to be pre-split again.
-
-## Examples
-
-### Setup
-
-{% include {{page.version.version}}/sql/movr-statements-partitioning.md %}
-
-### Split a table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGES FROM TABLE users;
-~~~
-
-~~~
-  start_key | end_key | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+-----------+---------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL      | NULL    |       25 |      0.005563 |            8 | region=us-west1       | {3,5,8}  | {region=us-east1,region=us-central1,region=us-west1}
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users SPLIT AT VALUES ('chicago'), ('new york'), ('seattle');
-~~~
-
-~~~
-              key              |         pretty         |       split_enforced_until
-+------------------------------+------------------------+----------------------------------+
-  \275\211\022chicago\000\001  | /Table/53/1/"chicago"  | 2262-04-11 23:47:16.854776+00:00
-  \275\211\022new york\000\001 | /Table/53/1/"new york" | 2262-04-11 23:47:16.854776+00:00
-  \275\211\022seattle\000\001  | /Table/53/1/"seattle"  | 2262-04-11 23:47:16.854776+00:00
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGES FROM TABLE users;
-~~~
-
-~~~
-   start_key  |   end_key   | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+-------------+-------------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL        | /"chicago"  |       25 |      0.000872 |            8 | region=us-west1       | {3,5,8}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"chicago"  | /"new york" |       45 |      0.001943 |            8 | region=us-west1       | {3,5,8}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"new york" | /"seattle"  |       46 |       0.00184 |            8 | region=us-west1       | {3,5,8}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"seattle"  | NULL        |       47 |      0.000908 |            7 | region=us-west1       | {1,4,7}  | {region=us-east1,region=us-central1,region=us-west1}
-(4 rows)
-~~~
-
-### Split a table with a compound primary key
-
-You may want to split a table with a compound primary key.
-
-Suppose that you want MovR to offer ride-sharing services, in addition to vehicle-sharing services. Some users need to sign up to be drivers, so you need a `drivers` table to store driver information.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE drivers (
-    id UUID DEFAULT gen_random_uuid(),
-    city STRING,
-    name STRING,
-    dl STRING DEFAULT left(md5(random()::text),8) UNIQUE CHECK (LENGTH(dl) < 9),
-    address STRING,
-    CONSTRAINT "primary" PRIMARY KEY (city ASC, dl ASC)
-);
-~~~
-
-The table's compound primary key is on the `city` and `dl` columns. Note that the table automatically generates an `id` and a `dl` [using supported SQL functions](functions-and-operators.html), if they are not provided.
-
-Because this table has several columns in common with the `users` table, you can populate the table with values from the `users` table with an `INSERT` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO drivers (id, city, name, address)
-    SELECT id, city, name, address FROM users;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGES FROM TABLE drivers;
-~~~
-
-~~~
-  start_key | end_key | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+-----------+---------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL      | NULL    |       45 |      0.007222 |            6 | region=us-central1    | {1,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-(1 row)
-~~~
-
-Now you can split the table based on the compound primary key. Note that you do not have to specify the entire value for the primary key, just the prefix.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE drivers SPLIT AT VALUES ('new york', '3'), ('new york', '7'), ('chicago', '3'), ('chicago', '7'), ('seattle', '3'), ('seattle', '7');
-~~~
-
-~~~
-                     key                    |           pretty           |       split_enforced_until
-+-------------------------------------------+----------------------------+----------------------------------+
-  \303\211\022new york\000\001\0223\000\001 | /Table/59/1/"new york"/"3" | 2262-04-11 23:47:16.854776+00:00
-  \303\211\022new york\000\001\0227\000\001 | /Table/59/1/"new york"/"7" | 2262-04-11 23:47:16.854776+00:00
-  \303\211\022chicago\000\001\0223\000\001  | /Table/59/1/"chicago"/"3"  | 2262-04-11 23:47:16.854776+00:00
-  \303\211\022chicago\000\001\0227\000\001  | /Table/59/1/"chicago"/"7"  | 2262-04-11 23:47:16.854776+00:00
-  \303\211\022seattle\000\001\0223\000\001  | /Table/59/1/"seattle"/"3"  | 2262-04-11 23:47:16.854776+00:00
-  \303\211\022seattle\000\001\0227\000\001  | /Table/59/1/"seattle"/"7"  | 2262-04-11 23:47:16.854776+00:00
-(6 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGES FROM TABLE drivers;
-~~~
-
-~~~
-     start_key    |     end_key     | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                   replica_localities
-+-----------------+-----------------+----------+---------------+--------------+-----------------------+----------+---------------------------------------------------------+
-  NULL            | /"chicago"/"3"  |       45 |      0.000792 |            6 | region=us-central1    | {1,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"chicago"/"3"  | /"chicago"/"7"  |       48 |      0.000316 |            1 | region=us-east1       | {1,5,6}  | {region=us-east1,region=us-central1,region=us-central1}
-  /"chicago"/"7"  | /"new york"/"3" |       49 |      0.001452 |            6 | region=us-central1    | {1,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"new york"/"3" | /"new york"/"7" |       46 |      0.000094 |            6 | region=us-central1    | {1,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"new york"/"7" | /"seattle"/"3"  |       47 |      0.001865 |            9 | region=us-west1       | {1,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"seattle"/"3"  | /"seattle"/"7"  |       50 |      0.000106 |            9 | region=us-west1       | {1,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-  /"seattle"/"7"  | NULL            |       51 |      0.002597 |            9 | region=us-west1       | {1,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-(7 rows)
-~~~
-
-### Split an index
-
-Add a new secondary [index](indexes.html) to the `rides` table, on the `revenue` column:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX revenue_idx ON rides(revenue);
-~~~
-
-Then split the table ranges by secondary index values:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX rides@revenue_idx SPLIT AT VALUES (25.00), (50.00), (75.00);
-~~~
-~~~
-         key        |      pretty      |       split_enforced_until
-+-------------------+------------------+----------------------------------+
-  \277\214*2\000    | /Table/55/4/25   | 2262-04-11 23:47:16.854776+00:00
-  \277\214*d\000    | /Table/55/4/5E+1 | 2262-04-11 23:47:16.854776+00:00
-  \277\214*\226\000 | /Table/55/4/75   | 2262-04-11 23:47:16.854776+00:00
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW RANGES FROM INDEX rides@revenue_idx;
-~~~
-~~~
-  start_key | end_key | range_id | range_size_mb | lease_holder | lease_holder_locality | replicas |                  replica_localities
-+-----------+---------+----------+---------------+--------------+-----------------------+----------+------------------------------------------------------+
-  NULL      | /25     |       55 |      0.007446 |            6 | region=us-central1    | {3,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-  /25       | /5E+1   |       56 |      0.008951 |            6 | region=us-central1    | {3,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-  /5E+1     | /75     |       57 |      0.008205 |            2 | region=us-east1       | {2,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-  /75       | NULL    |       60 |      0.009322 |            6 | region=us-central1    | {2,6,9}  | {region=us-east1,region=us-central1,region=us-west1}
-(4 rows)
-~~~
-
-### Set the expiration on a split enforcement
-
-You can specify the time at which a split enforcement expires by adding a `WITH EXPIRATION` clause to your `SPLIT` statement. Supported expiration values include [`DECIMAL`](decimal.html), [`INTERVAL`](interval.html), [`TIMESTAMP`](timestamp.html), and [`TIMESTAMPZ`](timestamp.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE vehicles SPLIT AT VALUES ('chicago'), ('new york'), ('seattle') WITH EXPIRATION '2020-01-10 23:30:00+00:00';
-~~~
-~~~
-              key              |         pretty         |   split_enforced_until
-+------------------------------+------------------------+---------------------------+
-  \276\211\022chicago\000\001  | /Table/54/1/"chicago"  | 2020-01-10 23:30:00+00:00
-  \276\211\022new york\000\001 | /Table/54/1/"new york" | 2020-01-10 23:30:00+00:00
-  \276\211\022seattle\000\001  | /Table/54/1/"seattle"  | 2020-01-10 23:30:00+00:00
-(3 rows)
-~~~
-
-You can see the split's expiration date in the `split_enforced_until` column. The `crdb_internal.ranges` table also contains information about ranges in your CockroachDB cluster, including the `split_enforced_until` column.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT range_id, start_pretty, end_pretty, split_enforced_until FROM crdb_internal.ranges WHERE table_name='vehicles';
-~~~
-
-~~~
-  range_id |      start_pretty      |       end_pretty       |   split_enforced_until
-+----------+------------------------+------------------------+---------------------------+
-        26 | /Table/54              | /Table/54/1/"chicago"  | NULL
-        75 | /Table/54/1/"chicago"  | /Table/54/1/"new york" | 2020-01-10 23:30:00+00:00
-        76 | /Table/54/1/"new york" | /Table/54/1/"seattle"  | 2020-01-10 23:30:00+00:00
-        78 | /Table/54/1/"seattle"  | /Table/55              | 2020-01-10 23:30:00+00:00
-(4 rows)
-~~~
-
-
-## See also
-
-- [Selection Queries](selection-queries.html)
-- [Distribution Layer](architecture/distribution-layer.html)
-- [Replication Layer](architecture/replication-layer.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [`UNSPLIT AT`](unsplit-at.html)
diff --git a/src/current/v20.2/sql-audit-logging.md b/src/current/v20.2/sql-audit-logging.md
deleted file mode 100644
index 57081353856..00000000000
--- a/src/current/v20.2/sql-audit-logging.md
+++ /dev/null
@@ -1,206 +0,0 @@
----
-title: SQL Audit Logging
-summary: Use the EXPERIMENTAL_AUDIT setting to turn SQL audit logging on or off for a table.
-toc: true
----
-
-SQL audit logging gives you detailed information about queries being executed against your system. This feature is especially useful when you want to log all queries that are run against a table containing personally identifiable information (PII).
-
-This page provides an example of SQL audit logging in CockroachDB, including:
-
-- How to turn audit logging on and off.
-- Where the audit log files live.
-- What the audit log files look like.
-
-For a detailed description of the audit log file format, see [Audit log file format](experimental-audit.html#audit-log-file-format) on the [`ALTER TABLE ... EXPERIMENTAL_AUDIT`](experimental-audit.html) reference page.
-
-Note that enabling SQL audit logs can negatively impact performance. As a result, we recommend using SQL audit logs for security purposes only. For more details, see [Performance considerations](experimental-audit.html#performance-considerations), on the [`ALTER TABLE ... EXPERIMENTAL_AUDIT`](experimental-audit.html) reference page.
-
-{% include {{ page.version.version }}/misc/experimental-warning.md %}
-
-{{site.data.alerts.callout_success}}
-To learn about other SQL query logging options, see [SQL logging](query-behavior-troubleshooting.html#sql-logging).
-{{site.data.alerts.end}}
-
-## Step 1. Create sample tables
-
-Use the statements below to create:
-
-- A `customers` table which contains PII such as name, address, etc.
-- An `orders` table with a foreign key into `customers`, which does not expose any PII
-
-Later, we'll show how to turn on audit logs for the `customers` table.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE customers (
-    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    name STRING NOT NULL,
-    address STRING NOT NULL,
-    national_id INT NOT NULL,
-    telephone INT NOT NULL,
-    email STRING UNIQUE NOT NULL
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE orders (
-    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
-    product_id INT NOT NULL,
-    delivery_status STRING check (delivery_status='processing' or delivery_status='in-transit' or delivery_status='delivered') NOT NULL,
-    customer_id UUID NOT NULL REFERENCES customers (id)
-);
-~~~
-
-## Step 2. Turn on auditing for the `customers` table
-
-We turn on auditing for a table using the [`EXPERIMENTAL_AUDIT`](experimental-audit.html) subcommand of [`ALTER TABLE`](alter-table.html).
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE customers EXPERIMENTAL_AUDIT SET READ WRITE;
-~~~
-
-{{site.data.alerts.callout_info}}
-To turn on auditing for more than one table, issue a separate `ALTER` statement for each table.
-{{site.data.alerts.end}}
-
-## Step 3. Populate the `customers` table
-
-Now that we have auditing turned on, let's add some customer data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers (name, address, national_id, telephone, email) VALUES (
-    'Pritchard M. Cleveland',
-    '23 Crooked Lane, Garden City, NY USA 11536',
-    778124477,
-    12125552000,
-    'pritchmeister@aol.com'
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO customers (name, address, national_id, telephone, email) VALUES (
-    'Vainglorious K. Snerptwiddle III',
-    '44 Straight Narrows, Garden City, NY USA 11536',
-    899127890,
-    16465552000,
-    'snerp@snerpy.net'
-);
-~~~
-
-Now let's verify that our customers were added successfully:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers;
-~~~
-
-~~~
-                   id                  |               name               |                    address                     | national_id |  telephone  |         email
----------------------------------------+----------------------------------+------------------------------------------------+-------------+-------------+------------------------
-  859c6aa1-ae36-49c8-9f12-7a952b4e6915 | Vainglorious K. Snerptwiddle III | 44 Straight Narrows, Garden City, NY USA 11536 |   899127890 | 16465552000 | snerp@snerpy.net
-  90810df2-d3c1-4038-8462-132f4df5112b | Pritchard M. Cleveland           | 23 Crooked Lane, Garden City, NY USA 11536     |   778124477 | 12125552000 | pritchmeister@aol.com
-(2 rows)
-~~~
-
-## Step 4. Check the audit log
-
-By default, the active audit log file is prefixed `cockroach-sql-audit` and is stored in CockroachDB's standard [log directory](debug-and-error-logs.html#write-to-file).  To store the audit log files in a specific directory, pass the `--sql-audit-dir` flag to [`cockroach start`](cockroach-start.html).  Like the other log files, it's rotated according to the [`--log-file-max-size` setting](cockroach-start.html#logging).
-
-When we look at the audit log for this example, we see the following lines showing every command we've run so far, as expected.
-
-~~~
-I201028 16:04:36.072075 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 1 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READWRITE}› ‹"ALTER TABLE customers EXPERIMENTAL_AUDIT SET READ WRITE"› ‹{}› 4.463 0 ‹OK› 0
-I201028 16:04:41.897324 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 2 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READWRITE}› ‹"INSERT INTO customers(name, address, national_id, telephone, email) VALUES ('Pritchard M. Cleveland', '23 Crooked Lane, Garden City, NY USA 11536', 778124477, 12125552000, 'pritchmeister@aol.com')"› ‹{}› 40.326 1 ‹OK› 0
-I201028 16:04:45.504038 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 3 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READWRITE}› ‹"INSERT INTO customers(name, address, national_id, telephone, email) VALUES ('Vainglorious K. Snerptwiddle III', '44 Straight Narrows, Garden City, NY USA 11536', 899127890, 16465552000, 'snerp@snerpy.net')"› ‹{}› 11.653 1 ‹OK› 0
-I201028 16:04:49.785126 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 4 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ}› ‹"SELECT * FROM customers"› ‹{}› 0.669 2 ‹OK› 0
-~~~
-
-{{site.data.alerts.callout_info}}
-For reference documentation of the audit log file format, see [`ALTER TABLE ... EXPERIMENTAL_AUDIT`](experimental-audit.html).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-{% include {{ page.version.version }}/ui/ui-log-files.md %}
-{{site.data.alerts.end}}
-
-## Step 5. Populate the `orders` table
-
-Unlike the `customers` table, `orders` doesn't have any PII, just a Product ID and a delivery status.
-
-Let's populate the `orders` table with some placeholder data using [`CREATE SEQUENCE`](create-sequence.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SEQUENCE product_ids_asc START 1 INCREMENT 1;
-~~~
-
-Evaluate the below a few times to generate data; note that this would error if [`SELECT`](select-clause.html) returned multiple results, but it doesn't in this case.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO orders (product_id, delivery_status, customer_id) VALUES (
-    nextval('product_ids_asc'),
-    'processing',
-    (SELECT id FROM customers WHERE name ~ 'Cleve')
-);
-~~~
-
-Let's verify that our orders were added successfully:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders ORDER BY product_id;
-~~~
-
-~~~
-                   id                  | product_id | delivery_status |             customer_id
----------------------------------------+------------+-----------------+---------------------------------------
-  77fa8340-8a65-4ab2-8191-ed87fc049b33 |          1 | processing      | 90810df2-d3c1-4038-8462-132f4df5112b
-  36c8b00d-01f0-4956-bb0e-6e9219f49bae |          2 | processing      | 90810df2-d3c1-4038-8462-132f4df5112b
-  5eebf961-1e4c-41a4-b6c6-441c3d5ef595 |          3 | processing      | 90810df2-d3c1-4038-8462-132f4df5112b
-  2952402e-0cde-438f-a1fb-09e30be26748 |          4 | processing      | 90810df2-d3c1-4038-8462-132f4df5112b
-  a9bf61ee-2c8c-4f77-b684-d943e1a46093 |          5 | processing      | 90810df2-d3c1-4038-8462-132f4df5112b
-(5 rows)
-~~~
-
-## Step 6. Check the audit log again
-
-Because we used a `SELECT` against the `customers` table to generate the placeholder data for `orders`, those queries will also show up in the audit log as follows:
-
-~~~
-I201028 16:07:31.632753 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 6 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ, "customers"[63]:READ}› ‹"INSERT INTO orders(product_id, delivery_status, customer_id) VALUES (nextval('product_ids_asc'), 'processing', (SELECT id FROM customers WHERE name ~ 'Cleve'))"› ‹{}› 30.487 1 ‹OK› 0
-I201028 16:07:37.393162 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 7 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ, "customers"[63]:READ}› ‹"INSERT INTO orders(product_id, delivery_status, customer_id) VALUES (nextval('product_ids_asc'), 'processing', (SELECT id FROM customers WHERE name ~ 'Cleve'))"› ‹{}› 13.479 1 ‹OK› 0
-I201028 16:07:38.429564 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 8 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ, "customers"[63]:READ}› ‹"INSERT INTO orders(product_id, delivery_status, customer_id) VALUES (nextval('product_ids_asc'), 'processing', (SELECT id FROM customers WHERE name ~ 'Cleve'))"› ‹{}› 10.857 1 ‹OK› 0
-I201028 16:07:39.476609 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 9 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ, "customers"[63]:READ}› ‹"INSERT INTO orders(product_id, delivery_status, customer_id) VALUES (nextval('product_ids_asc'), 'processing', (SELECT id FROM customers WHERE name ~ 'Cleve'))"› ‹{}› 14.191 1 ‹OK› 0
-I201028 16:07:40.450879 1376 sql/exec_log.go:207 ⋮ [n1,client=‹[::1]:59646›,hostnossl,user=root] 10 ‹exec› ‹"$ cockroach sql"› ‹{"customers"[63]:READ, "customers"[63]:READ}› ‹"INSERT INTO orders(product_id, delivery_status, customer_id) VALUES (nextval('product_ids_asc'), 'processing', (SELECT id FROM customers WHERE name ~ 'Cleve'))"› ‹{}› 14.408 1 ‹OK› 0
-~~~
-
-{{site.data.alerts.callout_info}}
-For reference documentation of the audit log file format, see [`ALTER TABLE ... EXPERIMENTAL_AUDIT`](experimental-audit.html).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_success}}
-{% include {{ page.version.version }}/ui/ui-log-files.md %}
-{{site.data.alerts.end}}
-
-## Known limitations
-
-SQL audit logs can only be accessed in the DB Console if they are stored in the same directory as the main CockroachDB log files.
-
-For more information, see [`EXPERIMENTAL_AUDIT`](experimental-audit.html#audit-log-file-storage-location).
-
-## See also
-
-- [`ALTER TABLE ... EXPERIMENTAL_AUDIT`](experimental-audit.html)
-- [`cockroach start` logging flags](cockroach-start.html#logging)
-- [SQL FAQ - generating unique row IDs](sql-faqs.html#how-do-i-auto-generate-unique-row-ids-in-cockroachdb)
-- [`CREATE SEQUENCE`](create-sequence.html)
-- [SQL Feature Support](sql-feature-support.html)
-- [Authentication logs](query-behavior-troubleshooting.html#authentication-logs)
-- [Slow query logs](query-behavior-troubleshooting.html#using-the-slow-query-log)
-- [SQL logging](query-behavior-troubleshooting.html#sql-logging)
diff --git a/src/current/v20.2/sql-constants.md b/src/current/v20.2/sql-constants.md
deleted file mode 100644
index 3bd13dd5bf4..00000000000
--- a/src/current/v20.2/sql-constants.md
+++ /dev/null
@@ -1,286 +0,0 @@
----
-title: Constant Values
-summary: SQL Constants represent a simple value that doesn't change.
-toc: true
----
-
-SQL Constants represent a simple value that doesn't change.
-
-
-## Introduction
-
-There are five categories of constants in CockroachDB:
-
-- [String literals](#string-literals): these define string values but their actual data type will
-  be inferred from context, for example, `'hello'`.
-- [Numeric literals](#numeric-literals): these define numeric values but their actual data
-  type will be inferred from context, for example, `-12.3`.
-- [Bit array literals](#bit-array-literals): these define bit array values with data type
-  `BIT`, for example, `B'1001001'`.
-- [Byte array literals](#byte-array-literals): these define byte array values with data type
-  `BYTES`, for example, `b'hello'`.
-- [Interpreted literals](#interpreted-literals): these define arbitrary values with an explicit
-  type, for example, `INTERVAL '3 days'`.
-- [Named constants](#named-constants): these have predefined values with a predefined
-  type, for example, `TRUE` or `NULL`.
-
-## String literals
-
-CockroachDB supports the following formats for string literals:
-
-- [Standard SQL string literals](#standard-sql-string-literals).
-- [String literals with C escape sequences](#string-literals-with-character-escapes).
-- [Dollar-quoted string literals](#dollar-quoted-string-literals)
-
-These formats also allow arbitrary Unicode characters encoded as UTF-8.
-
-In any case, the actual data type of a string literal is determined
-using the context where it appears.
-
-For example:
-
- Expression | Data type of the string literal 
-------------|---------------------------------
- `length('hello')` | `STRING` 
- `now() + '3 day'`  | `INTERVAL` 
- `INSERT INTO tb(date_col) VALUES ('2013-01-02')` | `DATE` 
-
-In general, the data type of a string literal is that demanded by the
-context if there is no ambiguity, or `STRING` otherwise.
-
-Check our blog for
-[more information about the typing of string literals](https://www.cockroachlabs.com/blog/revisiting-sql-typing-in-cockroachdb/).
-
-### Standard SQL string literals
-
-SQL string literals are formed by an arbitrary sequence of characters
-enclosed between single quotes (`'`), for example, `'hello world'`.
-
-To include a single quote in the string, use a double single quote.
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT 'hello' as a, 'it''s a beautiful day' as b;
-~~~
-
-~~~
-+-------+----------------------+
-|   a   |          b           |
-+-------+----------------------+
-| hello | it's a beautiful day |
-+-------+----------------------+
-~~~
-
-For compatibility with the SQL standard, CockroachDB also recognizes
-the following special syntax: two simple string literals separated by
-a newline character are automatically concatenated together to form a
-single constant. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT 'hello'
-' world!' as a;
-~~~
-
-~~~
-+--------------+
-|      a       |
-+--------------+
-| hello world! |
-+--------------+
-~~~
-
-This special syntax only works if the two simple literals are
-separated by a newline character. For example `'hello' ' world!'`
-doesn't work. This is mandated by the SQL standard.
-
-### String literals with character escapes
-
-CockroachDB also supports string literals containing escape sequences
-like in the programming language C. These are constructed by prefixing
-the string literal with the letter `e`, for example,
-`e'hello\nworld!'`.
-
-The following escape sequences are supported:
-
-Escape Sequence | Interpretation
-----------------|---------------
-`\a` | ASCII code 7 (BEL)
-`\b` | backspace (ASCII 8)
-`\t` | tab (ASCII 9)
-`\n` | newline (ASCII 10)
-`\v` | vertical tab (ASCII 11)
-`\f` | form feed (ASCII 12)
-`\r` | carriage return (ASCII 13)
-`\xHH` | hexadecimal byte value
-`\ooo` | octal byte value
-`\uXXXX` | 16-bit hexadecimal Unicode character value
-`\UXXXXXXXX` | 32-bit hexadecimal Unicode character value
-
-For example, the `e'x61\141\u0061'` escape string represents the
-hexadecimal byte, octal byte, and 16-bit hexadecimal Unicode character
-values equivalent to the `'aaa'` string literal.
-
-### Dollar-quoted string literals
-
- To make it easier to write certain types of string constants in SQL code, CockroachDB supports dollar-quoted string literals.  This is particularly useful for strings that need to contain lots of single quotes (`'`) or backslashes (`\`).
-
-At a high level, the dollar-quoting behavior works similarly to ["heredocs"](https://en.wikipedia.org/wiki/Here_document) as used in UNIX shells and some programming languages.
-
-Dollar-quoted strings have the form: `$` + (optional) tag + `$` + arbitrary text + `$` + (optional) tag + `$`
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT char_length($MyCoolString$
-You can put anything you want in this string -- for example, here's a Windows filesystem pathname: 'C:\Users\foo\Downloads\file.zip'
-
-You can even nest additional dollar-quoted strings inside each other.  For example, here is a regular expression using backticks: $myRegex$[foo\tbar]$myRegex$
-
-Finally, you can use $stand-alone dollar signs without the optional tag$.
-$MyCoolString$);
-~~~
-
-~~~
-  char_length
----------------
-          369
-(1 row)
-~~~
-
-## Numeric literals
-
-Numeric literals can have the following forms:
-
-~~~
-[+-]9999
-[+-]9999.[9999][e[+-]999]
-[+-][9999].9999[e[+-]999]
-[+-]9999e[+-]999
-[+-]0xAAAA
-~~~
-
-Some examples:
-
-~~~
-+4269
-3.1415
--.001
-6.626e-34
-50e6
-0xcafe111
-~~~
-
-The actual data type of a numeric constant depends both on the context
-where it is used, its literal format, and its numeric value.
-
- Syntax | Possible data types 
---------|---------------------
- Contains a decimal separator | `FLOAT`, `DECIMAL` 
- Contains an exponent | `FLOAT`, `DECIMAL` 
- Contains a value outside of the range -2^63...(2^63)-1 | `FLOAT`, `DECIMAL` 
- Otherwise | `INT`, `DECIMAL`, `FLOAT` 
-
-Of the possible data types, which one is actually used is then further
-refined depending on context.
-
-Check our blog for
-[more information about the typing of numeric literals](https://www.cockroachlabs.com/blog/revisiting-sql-typing-in-cockroachdb/).
-
-## Bit array literals
-
-Bit array literals consist of the `B` prefix followed by a string of
-binary digits (bits) enclosed in single quotes.
-
-For example: `B'1001010101'`
-
-Bit array literals are acceptable both when values of types
-[`BIT`](bit.html) or [`VARBIT`](bit.html) (`BIT VARYING`) are
-expected.
-
-The number of bits is arbitrary. An empty bit array is denoted `B''`;
-the number of bits need not be a multiple of 8, and bit arrays can
-contain more than 64 bits.
-
-## Byte array literals
-
-CockroachDB supports two formats for byte array literals:
-
-- [Byte array literals with C escape sequences](#byte-array-literals-with-character-escapes)
-- [Hexadecimal-encoded byte array literals](#hexadecimal-encoded-byte-array-literals)
-
-### Byte array literals with character escapes
-
-This uses the same syntax as [string literals containing character escapes](#string-literals-with-character-escapes),
-using a `b` prefix instead of `e`. Any character escapes are interpreted like they
-would be for string literals.
-
-For example: `b'hello,\x32world'`
-
-The two differences between byte array literals and string literals
-with character escapes are as follows:
-
-- Byte array literals always have data type `BYTES`, whereas the data
-  type of a string literal depends on context.
-- Byte array literals may contain invalid UTF-8 byte sequences,
-  whereas string literals must always contain valid UTF-8 sequences.
-
-### Hexadecimal-encoded byte array literals
-
-This is a CockroachDB-specific extension to express byte array
-literals: the delimiter `x'` followed by an arbitrary sequence of
-hexadecimal digits, followed by a closing `'`.
-
-For example, all the following formats are equivalent to `b'cat'`:
-
-- `x'636174'`
-- `X'636174'`
-
-## Interpreted literals
-
-A constant of any data type can be formed using either of the following formats:
-
-~~~
-type 'string'
-'string':::type
-~~~
-
-The value of the string part is used as input for the conversion function to the
-specified data type, and the result is used as a constant with that data type.
-
-Examples:
-
-~~~
-DATE '2013-12-23'
-BOOL 'FALSE'
-'42.69':::INT
-'TRUE':::BOOL
-'3 days':::INTERVAL
-~~~
-
-Additionally, for compatibility with PostgreSQL, the notation
-`'string'::type` and `CAST('string' AS type)` is also recognized as an
-interpreted literal. These are special cases of
-[cast expressions](scalar-expressions.html).
-
-For more information about the allowable format of interpreted
-literals, refer to the "Syntax" section of the respective data types:
-[`DATE`](date.html#syntax), [`INET`](inet.html#syntax), [`INTERVAL`](interval.html#syntax), [`TIME`](time.html#syntax),
-[`TIMESTAMP`/`TIMESTAMPTZ`](timestamp.html#syntax).
-
-## Named constants
-
-CockroachDB recognizes the following SQL named constants:
-
-- `TRUE` and `FALSE`, the two possible values of data type `BOOL`.
-- `NULL`, the special SQL symbol that indicates "no value present".
-
-Note that `NULL` is a valid constant for any type: its actual data
-type during expression evaluation is determined based on context.
-
-## See also
-
-- [Scalar Expressions](scalar-expressions.html)
-- [Data Types](data-types.html)
diff --git a/src/current/v20.2/sql-faqs.md b/src/current/v20.2/sql-faqs.md
deleted file mode 100644
index 1cc9269a039..00000000000
--- a/src/current/v20.2/sql-faqs.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: SQL FAQs
-summary: Get answers to frequently asked questions about CockroachDB SQL.
-toc: true
-toc_not_nested: true
----
-
-## How do I bulk insert data into CockroachDB?
-
-- To bulk-insert data into an existing table, batch multiple rows in one [multi-row `INSERT`](insert.html#insert-multiple-rows-into-an-existing-table) statement and do not include the `INSERT` statements within a transaction. Experimentally determine the optimal batch size for your application by monitoring the performance for different batch sizes (10 rows, 100 rows, 1000 rows).
-
-    {{site.data.alerts.callout_info}}
-    You can also use the [`IMPORT INTO`](import-into.html) statement to bulk-insert CSV data into an existing table.
-    {{site.data.alerts.end}}
-- To bulk-insert data into a new table, the [`IMPORT`](import.html) statement performs better than `INSERT`. `IMPORT` can also be used to [migrate data from other databases](migration-overview.html) like MySQL, Oracle, and Postgres.  
-
-## How do I auto-generate unique row IDs in CockroachDB?
-
-{% include {{ page.version.version }}/faq/auto-generate-unique-ids.html %}
-
-## How do I generate unique, slowly increasing sequential numbers in CockroachDB?
-
-{% include {{ page.version.version }}/faq/sequential-numbers.md %}
-
-## What are the differences between `UUID`, sequences, and `unique_rowid()`?
-
-{% include {{ page.version.version }}/faq/differences-between-numberings.md %}
-
-## How do I order writes to a table to closely follow time in CockroachDB?
-
-{% include {{ page.version.version }}/faq/sequential-transactions.md %}
-
-## How do I get the last ID/SERIAL value inserted into a table?
-
-There’s no function in CockroachDB for returning last inserted values, but you can use the [`RETURNING` clause](insert.html#insert-and-return-values) of the `INSERT` statement.
-
-For example, this is how you’d use `RETURNING` to return a value auto-generated via `unique_rowid()` or [`SERIAL`](serial.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (id INT DEFAULT unique_rowid(), name STRING);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO users (name) VALUES ('mike') RETURNING id;
-~~~
-
-## What is transaction contention?
-
-Transaction contention occurs when transactions issued from multiple
-clients at the same time operate on the same data.
-This can cause transactions to wait on each other and decrease
-performance, like when many people try to check out with the same
-cashier at a store.
-
-For more information about contention, see [Understanding and Avoiding
-Transaction
-Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-
-## Does CockroachDB support `JOIN`?
-
-[CockroachDB supports SQL joins](joins.html).
-
-## Does CockroachDB support JSON or Protobuf datatypes?
-
-Yes, the [`JSONB`](jsonb.html) data type is supported.
-
-## How do I know which index CockroachDB will select for a query?
-
-To see which indexes CockroachDB is using for a given query, you can use the [`EXPLAIN`](explain.html) statement, which will print out the query plan, including any indexes that are being used:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT col1 FROM tbl1;
-~~~
-
-If you'd like to tell the query planner which index to use, you can do so via some [special syntax for index hints](table-expressions.html#force-index-selection):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT col1 FROM tbl1@idx1;
-~~~
-
-## How do I log SQL queries?
-
-{% include {{ page.version.version }}/faq/sql-query-logging.md %}
-
-## Does CockroachDB support a UUID type?
-
-Yes. For more details, see [`UUID`](uuid.html).
-
-## How does CockroachDB sort results when `ORDER BY` is not used?
-
-When an [`ORDER BY`](order-by.html) clause is not used in a query, rows are processed or returned in a
-non-deterministic order. "Non-deterministic" means that the actual order
-can depend on the logical plan, the order of data on disk, the topology
-of the CockroachDB cluster, and is generally variable over time.
-
-## Why are my `INT` columns returned as strings in JavaScript?
-
-In CockroachDB, all `INT`s are represented with 64 bits of precision, but JavaScript numbers only have 53 bits of precision. This means that large integers stored in CockroachDB are not exactly representable as JavaScript numbers. For example, JavaScript will round the integer `235191684988928001` to the nearest representable value, `235191684988928000`. Notice that the last digit is different. This is particularly problematic when using the `unique_rowid()` [function](functions-and-operators.html), since `unique_rowid()` nearly always returns integers that require more than 53 bits of precision to represent.
-
-To avoid this loss of precision, Node's [`pg` driver](https://github.com/brianc/node-postgres) will, by default, return all CockroachDB `INT`s as strings.
-
-{% include copy-clipboard.html %}
-~~~ javascript
-// Schema: CREATE TABLE users (id INT DEFAULT unique_rowid(), name STRING);
-pgClient.query("SELECT id FROM users WHERE name = 'Roach' LIMIT 1", function(err, res) {
-  var idString = res.rows[0].id;
-  // idString === '235191684988928001'
-  // typeof idString === 'string'
-});
-~~~
-
-To perform another query using the value of `idString`, you can simply use `idString` directly, even where an `INT` type is expected. The string will automatically be coerced into a CockroachDB `INT`.
-
-{% include copy-clipboard.html %}
-~~~ javascript
-pgClient.query("UPDATE users SET name = 'Ms. Roach' WHERE id = $1", [idString], function(err, res) {
-  // All should be well!
-});
-~~~
-
-If you instead need to perform arithmetic on `INT`s in JavaScript, you will need to use a big integer library like [Long.js](https://www.npmjs.com/package/long). Do _not_ use the built-in `parseInt` function.
-
-{% include copy-clipboard.html %}
-~~~ javascript
-parseInt(idString, 10) + 1; // WRONG: returns 235191684988928000
-require('long').fromString(idString).add(1).toString(); // GOOD: returns '235191684988928002'
-~~~
-
-## Can I use CockroachDB as a key-value store?
-
-{% include {{ page.version.version }}/faq/simulate-key-value-store.html %}
-
-
-## See also
-
-- [Product FAQs](frequently-asked-questions.html)
-- [Operational FAQS](operational-faqs.html)
diff --git a/src/current/v20.2/sql-feature-support.md b/src/current/v20.2/sql-feature-support.md
deleted file mode 100644
index 43543bbcc7b..00000000000
--- a/src/current/v20.2/sql-feature-support.md
+++ /dev/null
@@ -1,186 +0,0 @@
----
-title: SQL Feature Support in CockroachDB v20.2
-summary: Summary of CockroachDB's conformance to the SQL standard and which common extensions it supports.
-toc: true
-keywords: gin, gin index, gin indexes, inverted index, inverted indexes, accelerated index, accelerated indexes
----
-
-Making CockroachDB easy to use is a top priority for us, so we chose to implement SQL. However, even though SQL has a standard, no database implements all of it, nor do any of them have standard implementations of all features.
-
-To understand which standard SQL features we support (as well as common extensions to the standard), use the table below.
-
-- **Component** lists the components that are commonly considered part of SQL.
-- **Supported** shows CockroachDB's level of support for the component.
-- **Type** indicates whether the component is part of the SQL *Standard* or is an *Extension* created by ourselves or others.
-- **Details** provides greater context about the component.
-
-<style>
-table tr td:nth-child(2) {
-    text-align: center;
-}
-</style>
-
-## Features
-
-### Row values
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- `ARRAY` | ✓ | Standard | [`ARRAY` documentation](array.html)
- `AUTO INCREMENT`<br>(Automatic key generation) | Alternative | Common Extension | [Automatic key generation FAQ](sql-faqs.html#how-do-i-auto-generate-unique-row-ids-in-cockroachdb)
- `BIT` | ✓ | Standard | [`BIT` documentation](bit.html)
- `BYTES` | ✓ | CockroachDB Extension | [`BYTES` documentation](bytes.html)
- `BOOLEAN` | ✓ | Standard | [`BOOL` documentation](bool.html)
- `COLLATE` | ✓ | Standard | [`COLLATE` documentation](collate.html)
- `DATE` | ✓ | Standard | [`DATE` documentation](date.html)
- `DECIMAL`, `NUMERIC` | ✓ | Standard | [`DECIMAL` documentation](decimal.html)
- `ENUM` | ✓ | PostgreSQL Extension | <span class="version-tag">New in v20.2:</span> [`ENUM` documentation](enum.html)
- `FLOAT`, `REAL` | ✓ | Standard | [`FLOAT` documentation](float.html)
- `INET` | ✓ | PostgreSQL Extension | [`INET` documentation](inet.html)
- `INT` | ✓ | Standard | [`INT` documentation](int.html)
- `INTERVAL` | ✓ | Standard | [`INTERVAL` documentation](interval.html)
- `JSON`/`JSONB` | ✓ | Common Extension | [`JSONB` documentation](jsonb.html)
- `NULL` | ✓ | Standard | [*NULL*-handling documentation](null-handling.html)
- `SERIAL`| ✓ | PostgreSQL Extension | [`SERIAL` documentation](serial.html)
- `SET`| ✗ | MySQL| Only allow rows to contain values from a defined set of terms.
- `STRING`, `CHARACTER` | ✓ | Standard | [`STRING` documentation](string.html)
- `TIME` | ✓ | Standard | [`TIME` documentation](time.html)
- `TIMESTAMP`/`TIMESTAMPTZ` | ✓ | Standard | [`TIMESTAMP` documentation](timestamp.html)
- `UNSIGNED INT` | ✗ | Common Extension | `UNSIGNED INT` causes numerous casting issues, so we do not plan to support it.
- `UUID` | ✓ | PostgreSQL Extension | [`UUID` documentation](uuid.html)
-  Identifiers | ✓ | Standard | [Identifiers documentation](keywords-and-identifiers.html#identifiers)
-  Key-value pairs | Alternative | Extension | [Key-Value FAQ](sql-faqs.html#can-i-use-cockroachdb-as-a-key-value-store)
-  XML | ✗ | Standard | XML data can be stored as `BYTES`, but we do not offer XML parsing.
-
-### Constraints
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Not Null | ✓ | Standard | [Not Null documentation](not-null.html)
- Unique | ✓ | Standard | [Unique documentation](unique.html)
- Primary Key | ✓ | Standard | [Primary Key documentation](primary-key.html)
- Check | ✓ | Standard | [Check documentation](check.html)
- Foreign Key | ✓ | Standard | [Foreign Key documentation](foreign-key.html)
- Default Value | ✓ | Standard | [Default Value documentation](default-value.html)
-
-### Transactions
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Transactions (ACID semantics) | ✓ | Standard | [Transactions documentation](transactions.html)
- `BEGIN` | ✓ | Standard | [`BEGIN` documentation](begin-transaction.html)
- `COMMIT` | ✓ | Standard | [`COMMIT` documentation](commit-transaction.html)
- `ROLLBACK` | ✓ | Standard | [`ROLLBACK` documentation](rollback-transaction.html)
- `SAVEPOINT` | ✓ | Standard with CockroachDB extensions |  CockroachDB supports nested transactions using [`SAVEPOINT`](savepoint.html)
-
-### Indexes
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Indexes | ✓ | Common Extension | [Indexes documentation](indexes.html)
- Multi-column indexes | ✓ | Common Extension | We do not limit on the number of columns indexes can include
- Covering indexes | ✓ | Common Extension | [Storing Columns documentation](create-index.html#store-columns)
- GIN indexes | ✓ | Common Extension | [GIN Indexes documentation](inverted-indexes.html)
- Partial indexes | ✓ | Common Extension | <span class="version-tag">New in v20.2:</span> [Partial indexes documentation](partial-indexes.html)
- Spatial indexes | ✓ | Common Extension | <span class="version-tag">New in v20.2:</span> [Spatial indexes documentation](spatial-indexes.html)
- Multiple indexes per query | Partial | Common Extension | [Use multiple indexes for a single query](https://github.com/cockroachdb/cockroach/issues/2142)
- Full-text indexes | Planned | Common Extension | [GitHub issue tracking full-text index support](https://github.com/cockroachdb/cockroach/issues/7821)
- Prefix/Expression Indexes | Potential | Common Extension | Apply expressions (such as `LOWER()`) to values before indexing them
- Hash indexes | ✗ | Common Extension | Improves performance of queries looking for single, exact values
-
-### Schema changes
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- `ALTER TABLE` | ✓ | Standard | [`ALTER TABLE` documentation](alter-table.html)
- Database renames | ✓ | Standard | [`RENAME DATABASE` documentation](rename-database.html)
- Table renames | ✓ | Standard | [`RENAME TABLE` documentation](rename-table.html)
- Column renames | ✓ | Standard | [`RENAME COLUMN` documentation](rename-column.html)
- Altering a column's data type | ✓ | Standard | <span class="version-tag">New in v20.2:</span> [`ALTER COLUMN` documentation](alter-column.html#altering-column-types)
- Adding columns | ✓ | Standard | [`ADD COLUMN` documentation](add-column.html)
- Removing columns | ✓ | Standard | [`DROP COLUMN` documentation](drop-column.html)
- Adding constraints | ✓ | Standard | [`ADD CONSTRAINT` documentation](add-constraint.html)
- Removing constraints | ✓ | Standard | [`DROP CONSTRAINT` documentation](drop-constraint.html)
- Index renames | ✓ | Standard | [`RENAME INDEX` documentation](rename-index.html)
- Adding indexes | ✓ | Standard | [`CREATE INDEX` documentation](create-index.html)
- Removing indexes | ✓ | Standard | [`DROP INDEX` documentation](drop-index.html)
- Altering a primary key | ✓ | Standard | [`ALTER PRIMARY KEY` documentation](alter-primary-key.html)
- Adding user-defined schemas | ✓ | Standard | <span class="version-tag">New in v20.2:</span> [`CREATE SCHEMA` documentation](create-schema.html)
- Removing user-defined schemas | ✓ | Standard | <span class="version-tag">New in v20.2:</span> [`DROP SCHEMA` documentation](drop-schema.html)
- Altering user-defined schemas | ✓ | Standard | <span class="version-tag">New in v20.2:</span> [`ALTER SCHEMA` documentation](create-schema.html)
- Converting a database to a user-defined schema | ✓ | CockroachDB Extension | <span class="version-tag">New in v20.2:</span> [`CONVERT TO SCHEMA` documentation](convert-to-schema.html)
-
-### Statements
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Common statements | ✓ | Standard, PostgreSQL/CockroachDB Extension | [SQL Statements documentation](sql-statements.html)
- `UPSERT` | ✓ | PostgreSQL, MSSQL Extension | [`UPSERT` documentation](upsert.html)
- `EXPLAIN` | ✓ | Common Extension | [`EXPLAIN` documentation](explain.html)
- `SELECT INTO` | Alternative | Common Extension | You can replicate similar functionality using [`CREATE TABLE`](create-table.html) and then `INSERT INTO ... SELECT ...`.
- `SELECT FOR UPDATE` | ✓ | Common Extension |  [`SELECT FOR UPDATE` documentation](select-for-update.html)
-
-### Clauses
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Common clauses | ✓ | Standard | [SQL Grammar documentation](sql-grammar.html)  
- `LIMIT` | ✓ | Common Extension | Limit the number of rows a statement returns.
- `LIMIT` with `OFFSET` | ✓ | Common Extension | Skip a number of rows, and then limit the size of the return set.
- `RETURNING` | ✓ | Common Extension | Retrieve a table of rows statements affect.
-
-### Table expressions
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Table and View references | ✓ | Standard | [Table expressions documentation](table-expressions.html#table-or-view-names)
- `AS` in table expressions | ✓ | Standard | [Aliased table expressions documentation](table-expressions.html#aliased-table-expressions)
- `JOIN` (`INNER`, `LEFT`, `RIGHT`, `FULL`, `CROSS`) | [Functional](https://www.cockroachlabs.com/blog/better-sql-joins-in-cockroachdb/) | Standard | [`JOIN` expressions documentation](table-expressions.html#join-expressions)
- Sub-queries as table expressions | Partial | Standard | Non-correlated subqueries are [supported](table-expressions.html#subqueries-as-table-expressions), as are most [correlated subqueries](subqueries.html#correlated-subqueries).
- Table generator functions | Partial | PostgreSQL Extension | [Table generator functions documentation](table-expressions.html#table-generator-functions)
- `WITH ORDINALITY` | ✓ | CockroachDB Extension | [Ordinality annotation documentation](table-expressions.html#ordinality-annotation)
-
-### Scalar expressions and boolean formulas
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Common functions | ✓ | Standard | [Functions calls and SQL special forms documentation](scalar-expressions.html#function-calls-and-sql-special-forms)
- Common operators | ✓ | Standard | [Operators documentation](scalar-expressions.html#unary-and-binary-operations)
- `IF`/`CASE`/`NULLIF` | ✓ | Standard | [Conditional expressions documentation](scalar-expressions.html#conditional-expressions)
- `COALESCE`/`IFNULL` | ✓ | Standard | [Conditional expressions documentation](scalar-expressions.html#conditional-expressions)
-`AND`/`OR` | ✓ | Standard | [Conditional expressions documentation](scalar-expressions.html#conditional-expressions)
- `LIKE`/`ILIKE`  | ✓ | Standard | [String pattern matching documentation](scalar-expressions.html#string-pattern-matching)
- `SIMILAR TO` | ✓ | Standard | [SQL regexp pattern matching documentation](scalar-expressions.html#string-matching-using-sql-regular-expressions)
- Matching using POSIX regular expressions  | ✓ | Common Extension | [POSIX regexp pattern matching documentation](scalar-expressions.html#string-matching-using-posix-regular-expressions)
- `EXISTS` | Partial | Standard | Non-correlated subqueries are [supported](scalar-expressions.html#existence-test-on-the-result-of-subqueries), as are most [correlated subqueries](subqueries.html#correlated-subqueries). Currently works only with small data sets.
- Scalar subqueries | Partial | Standard | Non-correlated subqueries are [supported](scalar-expressions.html#scalar-subqueries), as are most [correlated subqueries](subqueries.html#correlated-subqueries). Currently works only with small data sets.
- Bitwise arithmetic | ✓ | Common Extension | [Operators documentation](scalar-expressions.html#unary-and-binary-operations)
- Array constructors and subscripting | Partial | PostgreSQL Extension | Array expression documentation: [Constructor syntax](scalar-expressions.html#array-constructors) and [Subscripting](scalar-expressions.html#subscripted-expressions)
- `COLLATE`| ✓ | Standard | [Collation expressions documentation](scalar-expressions.html#collation-expressions)
- Column ordinal references | ✓ | CockroachDB Extension | [Column references documentation](scalar-expressions.html#column-references)
- Type annotations | ✓ | CockroachDB Extension | [Type annotations documentation](scalar-expressions.html#explicitly-typed-expressions)
-
-### Permissions
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Users | ✓ | Standard | [Users documentation](authorization.html#users)
- Roles | ✓ | Standard | [Roles documentation](authorization.html#roles)
- Object ownership | ✓ | Common Extension | <span class="version-tag">New in v20.2:</span> [Ownership documentation](authorization.html#object-ownership)
- Privileges | ✓ | Standard | [Privileges documentation](authorization.html#assign-privileges)
-
-### Miscellaneous
-
- Component | Supported | Type | Details
------------|-----------|------|---------
- Column families | ✓ | CockroachDB Extension | [Column Families documentation](column-families.html)
- Interleaved tables | ✓ | CockroachDB Extension | [Interleaved Tables documentation](interleave-in-parent.html)<br>{% include {{ page.version.version }}/misc/interleave-deprecation-note.md %}
- Information Schema | ✓ | Standard | [Information Schema documentation](information-schema.html)
- Views | ✓ | Standard | [Views documentation](views.html)
- Materialized views | ✓ | Common Extension | <span class="version-tag">New in v20.2:</span> [Materialized views documentation](views.html#materialized-views)
- Window functions | ✓ | Standard | [Window Functions documentation](window-functions.html)
- Common Table Expressions | Partial | Common Extension | [Common Table Expressions documentation](common-table-expressions.html)
- Stored Procedures | Planned | Common Extension | Execute a procedure explicitly.
- Cursors | ✗ | Standard | Traverse a table's rows.
- Triggers | ✗ | Standard | Execute a set of commands whenever a specified event occurs.
- Sequences |  ✓ | Common Extension | [`CREATE SEQUENCE` documentation](create-sequence.html)
diff --git a/src/current/v20.2/sql-grammar.md b/src/current/v20.2/sql-grammar.md
deleted file mode 100644
index cb374ffc2a8..00000000000
--- a/src/current/v20.2/sql-grammar.md
+++ /dev/null
@@ -1,43 +0,0 @@
----
-title: SQL Grammar
-summary: The full SQL grammar for CockroachDB, generated automatically from the CockroachDB code.
-toc: true
-back_to_top: true
----
-
-<style>
-/* TODO(mjibson): reduce to header height once it no longer changes on scroll */
-a[name]::before {
-	content: '';
-	display: block;
-	height: 80px;
-	margin: -80px 0 0;
-}
-a[name]:focus {
-	outline: 0;
-}
-</style>
-
-{{site.data.alerts.callout_success}}
-This page describes the full CockroachDB SQL grammar. However, as a starting point, it's best to reference our [SQL statements pages](sql-statements.html) first, which provide detailed explanations and examples.
-{{site.data.alerts.end}}
-
-{% comment %}
-TODO: clean up the SQL diagrams not to link to these missing nonterminals.
-{% endcomment %}
-<a id="col_label"></a>
-<a id="column_constraints"></a>
-<a id="column_name"></a>
-<a id="count"></a>
-<a id="fk_column_name"></a>
-<a id="limit_val"></a>
-<a id="offset_val"></a>
-<a id="ref_column_name"></a>
-<a id="simple_"></a>
-<a id="table_alias_name"></a>
-<a id="target_name"></a>
-<a id="timestamp"></a>
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/stmt_block.html %}
-</div>
diff --git a/src/current/v20.2/sql-name-resolution.md b/src/current/v20.2/sql-name-resolution.md
deleted file mode 100644
index 4c36de563b3..00000000000
--- a/src/current/v20.2/sql-name-resolution.md
+++ /dev/null
@@ -1,274 +0,0 @@
----
-title: Name Resolution
-summary: Object names can exist in multiple places in the naming hierarchy. Resolution decides which one to use.
-toc: true
----
-
-This page documents **name resolution** in CockroachDB.
-
-To reference an object (e.g., a table) in a query, you can specify a database, a schema, both, or neither. To resolve which object a query references, CockroachDB scans the [appropriate namespaces](#naming-hierarchy), following [a set of rules outlined below](#how-name-resolution-works).
-
-## Naming hierarchy
-
-For compatibility with PostgreSQL, CockroachDB supports a **three-level structure for names**. This is called the "naming hierarchy".
-
-In the naming hierarchy, the path to a stored object has three components:
-
-- database name
-- schema name
-- object name
-
-A CockroachDB cluster can store multiple databases. Each database can store multiple schemas, and each schema can store multiple [tables](create-table.html), [views](views.html), [sequences](create-sequence.html), and [user-defined types](enum.html).
-
-When you first [start a cluster](start-a-local-cluster.html), a number of [preloaded databases](show-databases.html#preloaded-databases) and schemas are included, including the `defaultdb` database and the `public` schema. By default, objects (e.g., tables) are stored in the preloaded `public` schema, in the [current database](#current-database) (`defaultdb`, by default).
-
-In addition to the `public` schema, CockroachDB supports a fixed set of [system catalog schemas](system-catalogs.html), available in every database, that provide ancillary, non-stored data to client applications. For example, [`information_schema`](information-schema.html) is provided for compatibility with the SQL standard, and [`pg_catalog`](pg-catalog.html) and [`pg_extension`](spatial-glossary.html#spatial-system-tables) are provided for compatibility with PostgreSQL.
-
-To create a new database, use a [`CREATE DATABASE`](create-database.html) statement. To create a new schema, use a [`CREATE SCHEMA`](create-schema.html) statement. The list of all databases can be obtained with [`SHOW DATABASES`](show-databases.html). The list of all schemas for a given database can be obtained with [`SHOW SCHEMAS`](show-schemas.html). The list of all objects for a given schema can be obtained with other `SHOW` statements.
-
-### Migrating namespaces from previous versions of CockroachDB
-
-In CockroachDB versions < v20.2, [user-defined schemas](create-schema.html) are not supported, and all objects created in a given database use the `public` schema. To provide a multi-level structure for stored objects in earlier versions of CockroachDB, we have recommended using [database](create-database.html) namespaces instead of schema namespaces.
-
-In CockroachDB versions >= v20.2, we recommend using schema namespaces, not database namespaces, to create a naming structure that is more similar to [PostgreSQL](https://www.postgresql.org/docs/current/ddl-schemas.html).
-
-If you are upgrading to v20.2, take any combination of the following actions after the upgrade is complete:
-
-- Use the [`ALTER DATABASE ... CONVERT TO SCHEMA`](convert-to-schema.html) statement to convert databases into schemas. This statement is particularly useful if you created databases for the sole purpose of creating a multi-level naming structure. When you convert a database to a schema, all tables, [sequences](create-sequence.html), and [user-defined types](enum.html) in the database become child objects of a new schema, and the database is deleted. Note that you cannot convert databases that contain user-defined schemas or [views](views.html).
-
-- [Create new schemas](create-schema.html) in databases on your cluster. After the schemas are created, use [`ALTER TABLE ... RENAME`](rename-table.html), [`ALTER SEQUENCE ... RENAME`](rename-sequence.html), [`ALTER TYPE ... RENAME`](alter-type.html), or [`ALTER VIEW ... RENAME`](alter-view.html) statements to move objects between databases as needed. To move objects between schemas, use [`ALTER TABLE ... SET SCHEMA`](set-schema.html), [`ALTER SEQUENCE ... SET SCHEMA`](set-schema.html), or [`ALTER VIEW ... SET SCHEMA`](set-schema.html).
-
-- If your cluster contains cross-database references (e.g., a cross-database foreign key reference, or a cross-database view reference), use the relevant [`ALTER TABLE`](alter-table.html), [`ALTER SEQUENCE`](alter-sequence.html), [`ALTER TYPE`](alter-type.html), or [`ALTER VIEW `](alter-view.html) statements to move any cross-referencing objects to the same database, but different schemas. Cross-database object references were allowed in earlier versions of CockroachDB to make database-object naming hierarchies more flexible for users. In v20.2, creating cross-database references are disabled for [foreign keys](foreign-key.html), [views](views.html), and [sequence ownership](create-sequence.html). For details, see [tracking issue](https://github.com/cockroachdb/cockroach/issues/55791).
-
-## How name resolution works
-
-Name resolution occurs separately to **look up existing objects** and to
-**decide the full name of a new object**.
-
-The rules to look up an existing object are as follows:
-
-1. If the name already fully specifies the database and schema, use that information.
-2. If the name has a single-component prefix (e.g., a schema name), try to find a schema with the prefix name in the [current database](#current-database) and [current schema](#current-schema). If that fails, try to find the object in the `public` schema of a database with the prefix name.
-3. If the name has no prefix, use the [search path](#search-path) with the [current database](#current-database).
-
-Similarly, the rules to decide the full name of a new object are as follows:
-
-1. If the name already fully specifies the database and schema, use that.
-2. If the name has a single-component prefix (e.g., a schema name), try to find a schema with that name. If no such schema exists, use the `public` schema in the database with the prefix name.
-3. If the name has no prefix, use the [current schema](#current-schema) in the [current database](#current-database).
-
-## Parameters for name resolution
-
-### Current database
-
-The current database is used when a name is unqualified or has only one component prefix. It is the current value of the `database` session variable.
-
-- You can view the current value of the `database` session variable with [`SHOW
-database`](show-vars.html) and change it with [`SET database`](set-vars.html).
-
-- You can inspect the list of valid database names that can be specified in `database` with [`SHOW DATABASES`](show-databases.html).
-
-- For client apps that connect to CockroachDB using a URL of the form `postgres://...`, the initial value of the `database` session variable can be set using the path component of the URL. For example, `postgres://node/mydb` sets `database` to `mydb` when the connection is established.
-
-### Search path
-
-The search path is used when a name is unqualified (i.e., has no prefix). It lists the schemas where objects are looked up. Its first element is also the [current schema](#current-schema) where new objects are created.
-
-- You can set the current search path with [`SET search_path`](set-vars.html) and inspected it with [`SHOW
-search_path`](show-vars.html).
-- You can inspect the list of valid schemas that can be listed in `search_path` with [`SHOW SCHEMAS`](show-schemas.html).
-- By default, the search path contains `$user`, `public`, `pg_catalog`, and `pg_extension`. For compatibility with PostgreSQL, `pg_catalog` is forced to be present in `search_path` at all times, even when not specified with `SET search_path`.
-- To mimic the behavior in PostgreSQL, CockroachDB will attempt a resolution to `pg_extension` prior to attempting `public`.
-
-### Current schema
-
-The current schema is used as target schema when creating a new object if the name is unqualified (has no prefix).
-
-- The current schema is always the first value of `search_path`, for compatibility with PostgreSQL.
-
-- You can inspect the current schema using the special built-in function/identifier `current_schema()`.
-
-## Index name resolution
-
-CockroachDB supports the following ways to specify an index name for statements that require one (e.g., [`DROP INDEX`](drop-index.html), [`ALTER INDEX ... RENAME`](alter-index.html), etc.):
-
-1. Index names are resolved relative to a table name using the `@` character, e.g., `DROP INDEX tbl@idx;`.  This is the default and most common syntax.
-2. Index names are resolved by searching all tables in the current schema to find a table with an index named `idx`, e.g., `DROP INDEX idx;` or (with optional schema prefix) `DROP INDEX public.idx;`.  This syntax is necessary for Postgres compatibility because Postgres index names live in the schema namespace such that e.g., `public.idx` will resolve to the index `idx` of some table in the public schema.  This capability is used by some ORMs.
-
-The name resolution algorithm for index names supports both partial and complete qualification, using the same [name resolution rules](#how-name-resolution-works) as other objects.
-
-## Examples
-
-The examples below use the following logical schema as a starting point:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE mydb;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE mydb.mytable(x INT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET database = mydb;
-~~~
-
-### Lookup with unqualified names
-
-An unqualified name is a name with no prefix, that is, a simple identifier.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM mytable;
-~~~
-
-This uses the search path over the current database. The search path is `$user` by default, in the current database. If a `$user` schema does not exist, the search path resolves to the `public` schema. In this case, there is no `$user` schema, and the resolved name is `mydb.public.mytable`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET database = system;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM mytable;
-~~~
-
-~~~
-pq: relation "mytable" does not exist
-~~~
-
-This uses the search path over the current database, which is now
-`system`. No schema in the search path contain table `mytable`, so the
-look up fails with an error.
-
-### Lookup with fully qualified names
-
-A fully qualified name is a name with two prefix components, that is,
-three identifiers separated by periods.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM mydb.public.mytable;
-~~~
-
-Both the database and schema components are specified. The lookup
-succeeds if and only if the object exists at that specific location.
-
-### Lookup with partially qualified names
-
-A partially qualified name is a name with one prefix component, that is, two identifiers separated by a period. When a name is partially qualified, CockroachDB will try to use the prefix as a schema name first; and if that fails, use it as a database name.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM public.mytable;
-~~~
-
-This looks up `mytable` in the `public` schema of the current
-database. If the current database is `mydb`, the lookup succeeds.
-
-To ease development in multi-database scenarios, CockroachDB also allows queries to specify a database name in a partially qualified name. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM mydb.mytable;
-~~~
-
-In that case, CockroachDB will first attempt to find a schema called
-`mydb` in the current database.  When no such schema exists (which is
-the case with the starting point in this section), it then tries to
-find a database called `mydb` and uses the `public` schema in that. In
-this example, this rule applies and the fully resolved name is
-`mydb.public.mytable`.
-
-### Using the search path to use tables across schemas
-
-Suppose that a client frequently accesses a stored table as well as a virtual table in the [Information Schema](information-schema.html). Because `information_schema` is not in the search path by default, all queries that need to access it must mention it explicitly.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM mydb.information_schema.schemata; -- valid
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.schemata; -- valid; uses mydb implicitly
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM schemata; -- invalid; information_schema not in search_path
-~~~
-
-For clients that use `information_schema` often, you can add it to the
-search path to simplify queries. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET search_path = public, information_schema;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM schemata; -- now valid, uses search_path
-~~~
-
-## Databases with special names
-
-When resolving a partially qualified name with just one component
-prefix, CockroachDB will look up a schema with the given prefix name
-first, and only look up a database with that name if the schema lookup
-fails. This matters in the (likely uncommon) case where you wish your
-database to be called `information_schema`, `public`, `pg_catalog`, [`pg_extension`](spatial-glossary.html#spatial-system-tables),
-or `crdb_internal`.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE public;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET database = mydb;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE public.mypublictable (x INT);
-~~~
-
-The [`CREATE TABLE`](create-table.html) statement in this example uses a partially
-qualified name.  Because the `public` prefix designates a valid schema
-in the current database, the full name of `mypublictable` becomes
-`mydb.public.mypublictable`. The table is created in database `mydb`.
-
-To create the table in database `public`, one would instead use a
-fully qualified name, as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE DATABASE public;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE public.public.mypublictable (x INT);
-~~~
-
-## See also
-
-- [`CREATE SCHEMA`](create-schema.html)
-- [`SET`](set-vars.html)
-- [`SHOW`](show-vars.html)
-- [`SHOW DATABASES`](show-databases.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [Information Schema](information-schema.html)
diff --git a/src/current/v20.2/sql-statements.md b/src/current/v20.2/sql-statements.md
deleted file mode 100644
index 691ebc4471b..00000000000
--- a/src/current/v20.2/sql-statements.md
+++ /dev/null
@@ -1,199 +0,0 @@
----
-title: SQL Statements
-summary: Overview of SQL statements supported by CockroachDB.
-toc: true
----
-
-CockroachDB supports the following SQL statements. Click a statement for more details.
-
-{{site.data.alerts.callout_success}}
-In the [built-in SQL shell](cockroach-sql.html#help), use `\h [statement]` to get inline help about a specific statement.
-{{site.data.alerts.end}}
-
-## Data manipulation statements
-
-Statement | Usage
-----------|------------
-[`CREATE TABLE AS`](create-table-as.html) | Create a new table in a database using the results from a [selection query](selection-queries.html).
-[`COPY FROM`](copy-from.html) | Copy data from a third-party client to a CockroachDB cluster.<br>Note that CockroachDB currently only supports `COPY FROM` statements issued from third-party clients, for compatibility with PostgreSQL drivers and ORMs. `COPY FROM` statements cannot be issued from the [`cockroach` SQL shell](cockroach-sql.html). To import data from files, we use an [`IMPORT`](import.html) statement instead.
-[`DELETE`](delete.html) | Delete specific rows from a table.
-[`EXPORT`](export.html) | Export an entire table's data, or the results of a `SELECT` statement, to CSV files. Note that this statement requires an [Enterprise license](enterprise-licensing.html).
-[`IMPORT`](import.html) | Bulk-insert CSV data into a new table.
-[`IMPORT INTO`](import-into.html) | Bulk-insert CSV data into an existing table.
-[`INSERT`](insert.html) | Insert rows into a table.
-[`SELECT`](select-clause.html) | Select specific rows and columns from a table and optionally compute derived values.
-[`SELECT FOR UPDATE`](select-for-update.html) |  Order transactions by controlling concurrent access to one or more rows of a table.
-[`TABLE`](selection-queries.html#table-clause) | Select all rows and columns from a table.
-[`TRUNCATE`](truncate.html) | Delete all rows from specified tables.
-[`UPDATE`](update.html) | Update rows in a table.
-[`UPSERT`](upsert.html) | Insert rows that do not violate uniqueness constraints; update rows that do.
-[`VALUES`](selection-queries.html#values-clause) | Return rows containing specific values.
-
-## Data definition statements
-
-Statement | Usage
-----------|------------
-[`ADD COLUMN`](add-column.html) | Add columns to a table.
-[`ADD CONSTRAINT`](add-constraint.html) | Add a constraint to a column.
-[`ALTER COLUMN`](alter-column.html) | Change a column's [Default constraint](default-value.html), [`NOT NULL` constraint](not-null.html), or [data type](data-types.html).
-[`ALTER DATABASE`](alter-database.html) | Apply a schema change to a database.
-[`ALTER INDEX`](alter-index.html) | Apply a schema change to an index.
-[`ALTER PARTITION`](alter-partition.html) | Configure the replication zone for a partition. Note that [partitioning](partitioning.html) requires an [Enterprise license](enterprise-licensing.html).
-[`ALTER PRIMARY KEY`](alter-primary-key.html) |  Change the [primary key](primary-key.html) of a table.
-[`ALTER RANGE`](alter-range.html) | Configure the replication zone for a system range.
-[`ALTER SCHEMA`](alter-schema.html) | <span class="version-tag">New in v20.2</span>: Alter a user-defined schema.
-[`ALTER SEQUENCE`](alter-sequence.html) | Apply a schema change to a sequence.
-[`ALTER TABLE`](alter-table.html) | Apply a schema change to a table.
-[`ALTER TYPE`](alter-type.html) | <span class="version-tag">New in v20.2:</span> Modify a user-defined, [enumerated data type](enum.html).
-[`ALTER USER`](alter-user.html) | add, change, or remove a user's password and to change the login privileges for a role.
-[`ALTER ROLE`](alter-role.html) | Add, change, or remove a [role's](create-role.html) password and to change the login privileges for a role.
-[`ALTER VIEW`](alter-view.html) | Apply a schema change to a view.
-[`COMMENT ON`](comment-on.html) | Associate a comment to a database, table, or column.
-[`CONFIGURE ZONE`](configure-zone.html) | Add, modify, reset, or remove a [replication zone](configure-replication-zones.html) for a database, table, index, partition, or system range.
-[`CONVERT TO SCHEMA`](convert-to-schema.html) | <span class="version-tag">New in v20.2</span>: Convert a database to a schema.
-[`CREATE DATABASE`](create-database.html) | Create a new database.
-[`CREATE INDEX`](create-index.html) | Create an index for a table.
-[`CREATE SCHEMA`](create-schema.html) | <span class="version-tag">New in v20.2</span>: Create a user-defined schema.
-[`CREATE SEQUENCE`](create-sequence.html) | Create a new sequence.
-[`CREATE TABLE`](create-table.html) | Create a new table in a database.
-[`CREATE TABLE AS`](create-table-as.html) | Create a new table in a database using the results from a [selection query](selection-queries.html).
-[`CREATE TYPE`](create-type.html) | <span class="version-tag">New in v20.2:</span> Create a user-defined, [enumerated data type](enum.html).
-[`CREATE VIEW`](create-view.html) | Create a new [view](views.html) in a database.
-[`DROP COLUMN`](drop-column.html) | Remove columns from a table.
-[`DROP CONSTRAINT`](drop-constraint.html) | Remove constraints from a column.
-[`DROP DATABASE`](drop-database.html) | Remove a database and all its objects.
-[`DROP INDEX`](drop-index.html) | Remove an index for a table.
-[`DROP SCHEMA`](drop-schema.html) | <span class="version-tag">New in v20.2</span>: Drop a user-defined schema.
-[`DROP SEQUENCE`](drop-sequence.html) | Remove a sequence.
-[`DROP TABLE`](drop-table.html) | Remove a table.
-[`DROP TYPE`](drop-type.html) | <span class="version-tag">New in v20.2:</span> Remove a user-defined, [enumerated data type](enum.html).
-[`DROP VIEW`](drop-view.html)| Remove a view.
-[`EXPERIMENTAL_AUDIT`](experimental-audit.html) | Turn SQL audit logging on or off for a table.
-[`PARTITION BY`](partition-by.html) | Partition, re-partition, or un-partition a table or secondary index. Note that [partitioning](partitioning.html) requires an [Enterprise license](enterprise-licensing.html).
-[`REFRESH`](refresh.html) | <span class="version-tag">New in v20.2:</span> Refresh the stored query results of a [materialized view](views.html#materialized-views).
-[`RENAME COLUMN`](rename-column.html) | Rename a column in a table.
-[`RENAME CONSTRAINT`](rename-constraint.html) | Rename a constraint on a column.
-[`RENAME DATABASE`](rename-database.html) | Rename a database.
-[`RENAME INDEX`](rename-index.html) | Rename an index for a table.
-[`RENAME SEQUENCE`](rename-sequence.html) | Rename a sequence.
-[`RENAME TABLE`](rename-table.html) | Rename a table or move a table between databases.
-[`SET SCHEMA`](set-schema.html) | <span class="version-tag">New in v20.2</span>: Change the schema of a table, sequence, or view.
-[`SHOW COLUMNS`](show-columns.html) | View details about columns in a table.
-[`SHOW CONSTRAINTS`](show-constraints.html) | List constraints on a table.
-[`SHOW CREATE`](show-create.html) | View the `CREATE` statement for a table, view, or sequence.
-[`SHOW DATABASES`](show-databases.html) | List databases in the cluster.
-[`SHOW ENUMS`](show-enums.html) |  <span class="version-tag">New in v20.2:</span> List user-defined, [enumerated data types](enum.html) in a database.
-[`SHOW INDEX`](show-index.html) | View index information for a table or database.
-[`SHOW LOCALITY`](show-locality.html) | View the locality of the current node.
-[`SHOW PARTITIONS`](show-partitions.html) | List partitions in a database. Note that [partitioning](partitioning.html) requires an [Enterprise license](enterprise-licensing.html).
-[`SHOW SCHEMAS`](show-schemas.html) | List the schemas in a database.
-[`SHOW SEQUENCES`](show-sequences.html) | List the sequences in a database.
-[`SHOW TABLES`](show-tables.html) | List tables or views in a database or virtual schema.
-[`SHOW TYPES`](show-types.html) |  <span class="version-tag">New in v20.2:</span> List user-defined [data types](data-types.html) in a database.
-[`SHOW RANGES`](show-ranges.html) | Show range information for all data in a table or index.
-[`SHOW RANGE FOR ROW`](show-range-for-row.html) | Show range information for a single row in a table or index.
-[`SHOW ZONE CONFIGURATIONS`](show-zone-configurations.html) | List details about existing [replication zones](configure-replication-zones.html).
-[`SPLIT AT`](split-at.html) | Force a range split at the specified row in the table or index.
-[`UNSPLIT AT`](unsplit-at.html) | Remove a range split enforcement at a specified row in the table or index.
-[`VALIDATE CONSTRAINT`](validate-constraint.html) | Check whether values in a column match a [constraint](constraints.html) on the column.
-
-## Transaction management statements
-
-Statement | Usage
-----------|------------
-[`BEGIN`](begin-transaction.html)| Initiate a [transaction](transactions.html).
-[`COMMIT`](commit-transaction.html) | Commit the current [transaction](transactions.html).
-[`SAVEPOINT`](savepoint.html) |  Start a [nested transaction](transactions.html#nested-transactions).
-[`RELEASE SAVEPOINT`](release-savepoint.html) | Commit a [nested transaction](transactions.html#nested-transactions).
-[`ROLLBACK TO SAVEPOINT`](rollback-transaction.html#rollback-a-nested-transaction) | Roll back and restart the [nested transaction](transactions.html#nested-transactions) started at the corresponding `SAVEPOINT` statement.
-[`ROLLBACK`](rollback-transaction.html) | Roll back the current [transaction](transactions.html) and all of its [nested transaction](transactions.html#nested-transactions), discarding all transactional updates made by statements inside the transaction.
-[`SET TRANSACTION`](set-transaction.html) | Set the priority for the session or for an individual [transaction](transactions.html).
-[`SHOW`](show-vars.html) | View the current [transaction settings](transactions.html).
-[`SHOW TRANSACTIONS`](show-transactions.html) | <span class="version-tag">New in v20.2</span>: View all currently active transactions across the cluster or on the local node.
-
-## Access management statements
-
-Statement | Usage
-----------|------------
-[`CREATE ROLE`](create-role.html) | Create SQL [roles](authorization.html#create-and-manage-roles), which are groups containing any number of roles and users as members.
-[`CREATE USER`](create-user.html) | Create SQL users, which lets you control [privileges](authorization.html#assign-privileges) on your databases and tables.
-[`DROP ROLE`](drop-role.html) | Remove one or more SQL [roles](authorization.html#create-and-manage-roles).
-[`DROP USER`](drop-user.html) | Remove one or more SQL users.
-[`GRANT <privileges>`](grant.html) | Grant privileges to [users](authorization.html#create-and-manage-users) or [roles](authorization.html#create-and-manage-roles).
-[`GRANT <roles>`](grant-roles.html) | Add a [role](authorization.html#create-and-manage-roles) or [user](authorization.html#create-and-manage-users) as a member to a role.
-[`REVOKE <privileges>`](revoke.html) | Revoke privileges from [users](authorization.html#create-and-manage-users) or [roles](authorization.html#create-and-manage-roles).
-[`REVOKE <roles>`](revoke-roles.html) | Revoke a [role](authorization.html#create-and-manage-roles) or [user's](authorization.html#create-and-manage-users) membership to a role.
-[`SHOW GRANTS`](show-grants.html) | View privileges granted to users.
-[`SHOW ROLES`](show-roles.html) | Lists the roles for all databases.
-[`SHOW USERS`](show-users.html) | Lists the users for all databases.
-
-## Session management statements
-
-Statement | Usage
-----------|------------
-[`RESET`](reset-vars.html) | Reset a session variable to its default value.
-[`SET`](set-vars.html) | Set a current session variable.
-[`SET TRANSACTION`](set-transaction.html) | Set the priority for an individual [transaction](transactions.html).
-[`SHOW TRACE FOR SESSION`](show-trace.html) | Return details about how CockroachDB executed a statement or series of statements recorded during a session.
-[`SHOW`](show-vars.html) | List the current session or transaction settings.
-
-## Cluster management statements
-
-Statement | Usage
-----------|------------
-[`RESET CLUSTER SETTING`](reset-cluster-setting.html) | Reset a cluster setting to its default value.
-[`SET CLUSTER SETTING`](set-cluster-setting.html) | Set a cluster-wide setting.
-[`SHOW ALL CLUSTER SETTINGS`](show-cluster-setting.html) | List the current cluster-wide settings.
-[`SHOW SESSIONS`](show-sessions.html) | List details about currently active sessions.
-[`CANCEL SESSION`](cancel-session.html) | Cancel a long-running session.
-
-## Query management statements
-
-Statement | Usage
-----------|------------
-[`CANCEL QUERY`](cancel-query.html) | Cancel a running SQL query.
-[`SHOW QUERIES`](show-queries.html) | List details about current active SQL queries.
-
-## Query planning statements
-
-Statement | Usage
-----------|------------
-[`CREATE STATISTICS`](create-statistics.html) | Create table statistics for the [cost-based optimizer](cost-based-optimizer.html) to use.
-[`EXPLAIN`](explain.html) | View debugging and analysis details for a statement that operates over tabular data.
-[`EXPLAIN ANALYZE`](explain-analyze.html) | Execute the query and generate a physical query plan with execution statistics.
-[`SHOW STATISTICS`](show-statistics.html) | List table statistics used by the [cost-based optimizer](cost-based-optimizer.html).
-
-
-## Job management statements
-
-Jobs in CockroachDB represent tasks that might not complete immediately, such as schema changes or Enterprise backups or restores.
-
-Statement | Usage
-----------|------------
-[`CANCEL JOB`](cancel-job.html) | Cancel a `BACKUP`, `RESTORE`, `IMPORT`, or `CHANGEFEED` job.
-[`PAUSE JOB`](pause-job.html) | Pause a `BACKUP`, `RESTORE`, `IMPORT`, or `CHANGEFEED` job.
-[`RESUME JOB`](resume-job.html) | Resume a paused `BACKUP`, `RESTORE`, `IMPORT`, or `CHANGEFEED` job.
-[`SHOW JOBS`](show-jobs.html) | View information on jobs.
-
-## Backup and restore statements
-
-Statement | Usage
-----------|------------
-[`BACKUP`](backup.html) | Create disaster recovery backups of databases and tables.
-[`RESTORE`](restore.html) | Restore databases and tables using your backups.
-[`SHOW BACKUP`](show-backup.html) | List the contents of a backup.
-[`CREATE SCHEDULE FOR BACKUP`](create-schedule-for-backup.html) | <span class="version-tag">New in v20.2:</span> Create a schedule for periodic backups.
-[`SHOW SCHEDULES`](show-schedules.html) | <span class="version-tag">New in v20.2:</span> View information on backup schedules.
-[`PAUSE SCHEDULES`](pause-schedules.html) | <span class="version-tag">New in v20.2:</span> Pause backup schedules.
-[`RESUME SCHEDULES`](resume-schedules.html) | <span class="version-tag">New in v20.2:</span> Resume paused backup schedules.
-[`DROP SCHEDULES`](drop-schedules.html) | <span class="version-tag">New in v20.2:</span> Drop backup schedules.
-
-
-## Changefeed statements (Enterprise)
-
-[Change data capture](stream-data-out-of-cockroachdb-using-changefeeds.html) (CDC) provides an Enterprise and core version of row-level change subscriptions for downstream processing.
-
-Statement | Usage
-----------|------------
-[`CREATE CHANGEFEED`](create-changefeed.html) | _(Enterprise)_ Create a new changefeed to stream row-level changes in a configurable format to a configurable sink (Kafka or a cloud storage sink).
-[`EXPERIMENTAL CHANGEFEED FOR`](changefeed-for.html) | _(Core)_ Create a new changefeed to stream row-level changes to the client indefinitely until the underlying connection is closed or the changefeed is canceled.
diff --git a/src/current/v20.2/sql-tuning-with-explain.md b/src/current/v20.2/sql-tuning-with-explain.md
deleted file mode 100644
index 4afb82bbbc5..00000000000
--- a/src/current/v20.2/sql-tuning-with-explain.md
+++ /dev/null
@@ -1,380 +0,0 @@
----
-title: SQL Tuning with EXPLAIN
-summary: How to use `EXPLAIN to identify and resolve SQL performance issues
-toc: true
----
-
-This tutorial walks you through the common reasons for [slow SQL statements](query-behavior-troubleshooting.html#identify-slow-queries) and describes how to use [`EXPLAIN`](explain.html) to troubleshoot the issues.
-
-The following examples use [MovR](movr.html), a fictional vehicle-sharing application, to demonstrate CockroachDB SQL statements. Run [`cockroach demo movr`](cockroach-demo.html) to open an interactive SQL shell to a temporary, in-memory cluster with the `movr` database preloaded and set as the [current database](sql-name-resolution.html#current-database).
-
-## Issue: Full table scans
-
-The most common reason for slow queries is sub-optimal `SELECT` statements that include full table scans and incorrect use of indexes.
-
-You'll get generally poor performance when retrieving a single row based on a column that is not in the primary key or any secondary index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users WHERE name = 'Cheyenne Smith';
-~~~
-
-~~~
-                   id                  | city  |      name      |      address      | credit_card
----------------------------------------+-------+----------------+-------------------+--------------
-  e147ae14-7ae1-4800-8000-00000000002c | paris | Cheyenne Smith | 8550 Kelsey Flats | 4374468739
-(1 row)
-
-Server Execution Time: 928µs
-Network Latency: 315µs
-~~~
-
-To understand why this query performs poorly, use [`EXPLAIN`](explain.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM users WHERE name = 'Cheyenne Smith';
-~~~
-
-~~~
-    tree    |        field        |       description
-------------+---------------------+--------------------------
-            | distribution        | full
-            | vectorized          | false
-  filter    |                     |
-   │        | filter              | name = 'Cheyenne Smith'
-   └── scan |                     |
-            | estimated row count | 279
-            | table               | users@primary
-            | spans               | FULL SCAN
-(8 rows)
-~~~
-
-The row with `table | users@primary` indicates the index used (`primary`) to scan the table (`users`). The row with `spans | FULL SCAN` shows you that, without a secondary index on the `name` column, CockroachDB scans every row of the `users` table, ordered by the primary key (`city`/`id`), until it finds the row with the correct `name` value.
-
-### Solution: Filter by a secondary index
-
-To speed up this query, add a secondary index on `name`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX on users (name);
-~~~
-
-The query will now return much faster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users WHERE name = 'Cheyenne Smith';
-~~~
-
-~~~
-                   id                  | city  |      name      |      address      | credit_card
----------------------------------------+-------+----------------+-------------------+--------------
-  e147ae14-7ae1-4800-8000-00000000002c | paris | Cheyenne Smith | 8550 Kelsey Flats | 4374468739
-(1 row)
-
-Server Execution Time: 304µs
-Network Latency: 251µs
-~~~
-
-To understand why the performance improved, use [`EXPLAIN`](explain.html) to see the new query plan:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM users WHERE name = 'Cheyenne Smith';
-~~~
-
-~~~
-     tree    |        field        |               description
--------------+---------------------+------------------------------------------
-             | distribution        | local
-             | vectorized          | false
-  index join |                     |
-   │         | table               | users@primary
-   └── scan  |                     |
-             | estimated row count | 1
-             | table               | users@users_name_idx
-             | spans               | [/'Cheyenne Smith' - /'Cheyenne Smith']
-(8 rows)
-~~~
-
-This shows you that CockroachDB starts with the secondary index (`users@users_name_idx`). Because it is sorted by `name`, the query can jump directly to the relevant value (`/'Cheyenne Smith' - /'Cheyenne Smith'`). However, the query needs to return values not in the secondary index, so CockroachDB grabs the primary key (`city`/`id`) stored with the `name` value (the primary key is always stored with entries in a secondary index), jumps to that value in the primary index, and then returns the full row.
-
-Because the `users` table is under 512 MiB, the primary index and all secondary indexes are contained in a single range with a single leaseholder. If the table were bigger, however, the primary index and secondary index could reside in separate ranges, each with its own leaseholder. In this case, if the leaseholders were on different nodes, the query would require more network hops, further increasing latency.
-
-### Solution: Filter by a secondary index storing additional columns
-
-When you have a query that filters by a specific column but retrieves a subset of the table's total columns, you can improve performance by [storing](indexes.html#storing-columns) those additional columns in the secondary index to prevent the query from needing to scan the primary index as well.
-
-For example, let's say you frequently retrieve a user's name and credit card number:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name, credit_card FROM users WHERE name = 'Cheyenne Smith';
-~~~
-
-~~~
-       name      | credit_card
------------------+--------------
-  Cheyenne Smith | 4374468739
-(1 row)
-
-Server Execution Time: 379µs
-Network Latency: 189µs
-~~~
-
-With the current secondary index on `name`, CockroachDB still needs to scan the primary index to get the credit card number:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT name, credit_card FROM users WHERE name = 'Cheyenne Smith';
-~~~
-
-
-~~~
-     tree    |        field        |               description
--------------+---------------------+------------------------------------------
-             | distribution        | local
-             | vectorized          | false
-  index join |                     |
-   │         | table               | users@primary
-   └── scan  |                     |
-             | estimated row count | 1
-             | table               | users@users_name_idx
-             | spans               | [/'Cheyenne Smith' - /'Cheyenne Smith']
-(8 rows)
-~~~
-
-Let's drop and recreate the index on `name`, this time storing the `credit_card` value in the index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP INDEX users_name_idx;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (name) STORING (credit_card);
-~~~
-
-Now that `credit_card` values are stored in the index on `name`, CockroachDB only needs to scan that index:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT name, credit_card FROM users WHERE name = 'Cheyenne Smith';
-~~~
-
-~~~
-  tree |        field        |               description
--------+---------------------+------------------------------------------
-       | distribution        | local
-       | vectorized          | false
-  scan |                     |
-       | estimated row count | 1
-       | table               | users@users_name_idx
-       | spans               | [/'Cheyenne Smith' - /'Cheyenne Smith']
-(6 rows)
-~~~
-
-This results in even faster performance:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name, credit_card FROM users WHERE name = 'Cheyenne Smith';
-~~~
-
-~~~
-       name      | credit_card
------------------+--------------
-  Cheyenne Smith | 4374468739
-(1 row)
-
-Server Execution Time: 217µs
-Network Latency: 274µs
-~~~
-
-To reset the database for following examples, let's drop the index on `name`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP INDEX users_name_idx;
-~~~
-
-## Issue: Joining data from different tables
-
-Secondary indexes are crucial when [joining](joins.html) data from different tables as well.
-
-For example, let's say you want to count the number of users who started rides on a given day. To do this, you need to use a join to get the relevant rides from the `rides` table and then map the `rider_id` for each of those rides to the corresponding `id` in the `users` table, counting each mapping only once:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT count(DISTINCT users.id) FROM users INNER JOIN rides ON rides.rider_id = users.id WHERE start_time BETWEEN '2020-09-16 00:00:00' AND '2020-09-17 00:00:00';
-~~~
-
-~~~
-  count
----------
-    149
-(1 row)
-
-Server Execution Time: 2.431ms
-Network Latency: 302µs
-~~~
-
-To understand what's happening, use [`EXPLAIN`](explain.html) to see the query plan:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT count(DISTINCT users.id) FROM users INNER JOIN rides ON rides.rider_id = users.id WHERE start_time BETWEEN '2020-09-16 00:00:00' AND '2020-09-17 00:00:00';
-~~~
-
-~~~
-            tree           |        field        |                                   description
----------------------------+---------------------+----------------------------------------------------------------------------------
-                           | distribution        | full
-                           | vectorized          | false
-  group (scalar)           |                     |
-   └── distinct            |                     |
-        │                  | distinct on         | id
-        └── hash join      |                     |
-             │             | equality            | (rider_id) = (id)
-             ├── filter    |                     |
-             │    │        | filter              | (start_time >= '2020-09-16 00:00:00') AND (start_time <= '2020-09-17 00:00:00')
-             │    └── scan |                     |
-             │             | estimated row count | 817
-             │             | table               | rides@primary
-             │             | spans               | FULL SCAN
-             └── scan      |                     |
-                           | estimated row count | 279
-                           | table               | users@primary
-                           | spans               | FULL SCAN
-(17 rows)
-
-Server Execution Time: 202µs
-Network Latency: 296µs
-~~~
-
-CockroachDB does a full table scan first on `rides` to get all rows with a `start_time` in the specified range and then does another full table scan on `users` to find matching rows and calculate the count.
-
-Given the `WHERE` condition of the join, the full table scan of `rides` is particularly wasteful.
-
-### Solution: Create a secondary index on the `WHERE` condition storing the join key
-
-To speed up the query, you can create a secondary index on the `WHERE` condition (`rides.start_time`) storing the join key (`rides.rider_id`):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON rides (start_time) STORING (rider_id);
-~~~
-
-Adding the secondary index reduced the query time:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT count(DISTINCT users.id) FROM users INNER JOIN rides ON rides.rider_id = users.id WHERE start_time BETWEEN '2020-09-16 00:00:00' AND '2020-09-17 00:00:00';
-~~~
-
-~~~
-  count
----------
-    149
-(1 row)
-
-Server Execution Time: 1.562ms
-Network Latency: 311µs
-~~~
-
-To understand why performance improved, again use [`EXPLAIN`](explain.html) to see the new query plan:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT count(DISTINCT users.id) FROM users INNER JOIN rides ON rides.rider_id = users.id WHERE start_time BETWEEN '2020-09-16 00:00:00' AND '2020-09-17 00:00:00';
-~~~
-
-~~~
-         tree         |        field        |                    description
-----------------------+---------------------+----------------------------------------------------
-                      | distribution        | full
-                      | vectorized          | false
-  group (scalar)      |                     |
-   └── distinct       |                     |
-        │             | distinct on         | id
-        └── hash join |                     |
-             │        | equality            | (id) = (rider_id)
-             ├── scan |                     |
-             │        | estimated row count | 279
-             │        | table               | users@primary
-             │        | spans               | FULL SCAN
-             └── scan |                     |
-                      | estimated row count | 2
-                      | table               | rides@rides_start_time_idx
-                      | spans               | [/'2020-09-16 00:00:00' - /'2020-09-17 00:00:00']
-(15 rows)
-~~~
-
-Notice that CockroachDB now starts by using `rides@rides_start_time_idx` secondary index to retrieve the relevant rides without needing to scan the full `rides` table.
-
-## Issue: Inefficient joins
-
-[Hash joins](joins.html#hash-joins) are more expensive and require more memory than [lookup joins](joins.html#lookup-joins). Hence the [cost-based optimizer](cost-based-optimizer.html) uses a lookup join whenever possible.
-
-For the following query, the cost-based optimizer can’t perform a lookup join because the query doesn’t have a prefix of the `rides` table’s primary key available and thus has to read the entire table and search for a match, resulting in a slow query:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM vehicles JOIN rides on rides.vehicle_id = vehicles.id limit 1;
-~~~
-
-~~~
-       tree      |        field        |     description
------------------+---------------------+----------------------
-                 | distribution        | full
-                 | vectorized          | false
-  limit          |                     |
-   │             | count               | 1
-   └── hash join |                     |
-        │        | equality            | (vehicle_id) = (id)
-        ├── scan |                     |
-        │        | estimated row count | 817
-        │        | table               | rides@primary
-        │        | spans               | FULL SCAN
-        └── scan |                     |
-                 | estimated row count | 15
-                 | table               | vehicles@primary
-                 | spans               | FULL SCAN
-(14 rows)
-~~~
-
-### Solution: Provide primary key to allow lookup join
-
-To speed up the query, you can provide the primary key to allow the cost-based optimizer to perform a lookup join instead of a hash join:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN SELECT * FROM vehicles JOIN rides ON rides.vehicle_id = vehicles.id and rides.city = vehicles.city limit 1;
-~~~
-
-~~~
-        tree       |         field         |          description
--------------------+-----------------------+---------------------------------
-                   | distribution          | full
-                   | vectorized            | false
-  limit            |                       |
-   │               | count                 | 1
-   └── lookup join |                       |
-        │          | table                 | vehicles@primary
-        │          | equality              | (city, vehicle_id) = (city,id)
-        │          | equality cols are key |
-        └── scan   |                       |
-                   | estimated row count   | 817
-                   | table                 | rides@primary
-                   | spans                 | FULL SCAN
-(12 rows)
-~~~
-
-## See also
-
-- [SQL Best Practices](performance-best-practices-overview.html)
-- [Troubleshoot SQL Behavior](query-behavior-troubleshooting.html)
-- [Optimize Query Performance](make-queries-fast.html)
\ No newline at end of file
diff --git a/src/current/v20.2/srid-4326.md b/src/current/v20.2/srid-4326.md
deleted file mode 100644
index e78ba14c493..00000000000
--- a/src/current/v20.2/srid-4326.md
+++ /dev/null
@@ -1,127 +0,0 @@
----
-title: SRID 4326 - longitude and latitude
-summary: The Spatial Reference System Identifier (SRID) 4326 represents spatial data using latitude and longitude coordinates on the Earth's surface.
-toc: true
----
-
-Every geometric shape has a spatial reference system associated with it, and each such reference system has a Spatial Reference System ID ([SRID](spatial-glossary.html#srid)).  The SRID is used to tell which spatial reference system will be used to interpret each spatial object.
-
-A common SRID in use is 4326, which represents spatial data using longitude and latitude coordinates on the Earth's surface as defined in the [WGS84](spatial-glossary.html#wgs84) standard, which is also used for the [Global Positioning System (GPS)](https://en.wikipedia.org/wiki/Global_Positioning_System).
-
-Here is an example shape that uses SRID 4326, a line stretching from Milwaukee, WI to Tulsa, OK:
-
-~~~
-SRID=4326;LINESTRING( -87.906471 43.038902, -95.992775 36.153980)
-~~~
-
-Most users should only have to care about SRIDs in the following situations:
-
-- When creating shapes.  By default, shapes which do not have an SRID associated with them will use an SRID of 0, which means "this shape has no SRID".
-- When comparing shapes. If you try to compare two shapes with different SRIDs using a spatial predicate, CockroachDB will signal an error.
-
-## Adding SRIDs to shapes
-
-### Add an SRID with WKT
-
-To add an SRID to a shape you are defining with [Well Known Text](well-known-text.html), prepend the text with `SRID=N;` as shown below:
-
-~~~
-SRID=4326;POLYGON((-79.976111 40.374444, -74.621157 40.323294, -76.609383 39.299236, -79.976111 40.374444))
-~~~
-
-### Add an SRID with SQL
-
-To add an SRID to a shape in SQL, use the `ST_SetSRID` [function](functions-and-operators.html#spatial-functions):
-
-{% include copy-clipboard.html %}
-~~~ sql
-select ST_SetSRID(ST_MakePoint(1,2), 4326);
-~~~
-
-~~~
-                      st_setsrid
-------------------------------------------------------
-  0101000020E6100000000000000000F03F0000000000000040
-(1 row)
-~~~
-
-### Change a shape's SRID
-
-To convert a shape to use a different SRID while maintaining the same reference location, use the `ST_Transform` function.  In the example below, we transform the reference system for a line from Albany, NY to Saranac Lake, NY from 4326 to use the [StatePlane New York East reference (SRID 3101)](https://epsg.io/102715).  This can be useful (or at least interesting) in some situations, since the StatePlane systems give distances in feet.
-
-{% include copy-clipboard.html %}
-~~~ sql
-select ST_Transform(ST_GeomFromText('SRID=4326;LINESTRING(-73.756233 42.652580, -74.130833 44.326111)'),3101);
-~~~
-
-~~~
-                                         st_transform
-----------------------------------------------------------------------------------------------
-  01020000201D0C000002000000487C82CDD54D4D41EC8A5DA9AD726B4181403E98D7B34C417A15F9897C116B41
-(1 row)
-~~~
-
-{{site.data.alerts.callout_danger}}
-When setting a shape's SRID, you can only use SRIDs that are defined in the [`spatial_ref_sys`](spatial-glossary.html#spatial_ref_sys) table.  For more information, see [Getting SRID information](#getting-srid-information).
-{{site.data.alerts.end}}
-
-## Getting SRID information
-
-You can get more detailed information about the SRIDs supported in CockroachDB from the [SQL client](cockroach-sql.html) by querying the [`spatial_ref_sys`](spatial-glossary.html#spatial_ref_sys) table.
-
-To see how many SRIDs are supported, run the following query:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT count(*) FROM spatial_ref_sys;
-~~~
-
-~~~
-  count
----------
-   6139
-(1 row)
-~~~
-
-To get more information about a specific SRID (in this case 4326), run the following query:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM spatial_ref_sys WHERE srid = 4326;
-~~~
-
-~~~
-  srid | auth_name | auth_srid |                                                                                                                              srtext                                                                                                                              |              proj4text
--------+-----------+-----------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------------------------------
-  4326 | EPSG      |      4326 | GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]] | +proj=longlat +datum=WGS84 +no_defs
-(1 row)
-~~~
-
-## Comparing shapes with different SRIDs
-
-If you try to compare two shapes with different SRIDs using a spatial predicate, CockroachDB will signal an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-select ST_Contains(ST_MakePoint(1,2), ST_SetSRID(ST_MakePoint(1,2), 4326));
-~~~
-
-~~~
-ERROR: st_contains(): operation on mixed SRIDs forbidden: (Point, 0) != (Point, 4326)
-~~~
-
-## Known limitations
-
-{{site.data.alerts.callout_info}}
-Defining a custom SRID by inserting rows into [`spatial_ref_sys`](spatial-glossary.html#spatial_ref_sys) is not currently supported.  For more information, please see the tracking issue [cockroachdb/cockroach#55903](https://github.com/cockroachdb/cockroach/issues/55903).
-{{site.data.alerts.end}}
-
-## See also
-
-- [Spatial features](spatial-features.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Well known text](well-known-text.html)
-- [Well known binary](well-known-binary.html)
-- [GeoJSON](geojson.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/sso.md b/src/current/v20.2/sso.md
deleted file mode 100644
index d6e191d1b89..00000000000
--- a/src/current/v20.2/sso.md
+++ /dev/null
@@ -1,149 +0,0 @@
----
-title: Single Sign-on (Enterprise)
-summary: Implement single sign-on (SSO) for DB Console access.
-toc: true
----
-
-Single sign-on (SSO) allows a CockroachDB user to access the DB Console in a secure cluster via an external identity provider. When SSO is configured and enabled, the [DB Console login page](ui-overview.html#db-console-access) will display an OAuth login button in addition to the password access option.
-
-CockroachDB supports SSO via [OpenID Connect (OIDC)](https://openid.net/connect/), an authentication layer built on top of OAuth 2.0.
-
-{{site.data.alerts.callout_info}}
-SSO authentication is an [Enterprise-only](enterprise-licensing.html) feature.
-{{site.data.alerts.end}}
-
-## Requirements
-
-- An external OAuth 2.0 identity provider
-
-## Login flow
-
-This SSO implementation uses the [authorization code grant type](https://tools.ietf.org/html/rfc6749#section-4.1) to authenticate a user.
-
-1. A user opens the DB Console and clicks on the OAuth login button.
-1. The user is redirected to an external identity provider.
-1. The user successfully authenticates with the provider, completing the OAuth flow.
-1. The user is redirected to the CockroachDB cluster via a callback URL.
-1. The authorization code in the callback query is exchanged for an [ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken).
-1. CockroachDB matches the ID Token to a registered SQL user.
-1. CockroachDB creates a web session for the SQL user.
-1. The user is redirected to the [DB Console Cluster Overview](ui-cluster-overview-page.html).
-
-## Cluster settings
-
-The following OIDC [cluster settings](cluster-settings.html) are used to configure and enable SSO.
-
-| Cluster Setting | Example Value
-|-----------------|------
-| `server.oidc_authentication.enabled` | true
-| `server.oidc_authentication.client_id` | '32789079457-g3hdfw8cbw85obi5cb525hsceaqf69unn.apps.googleusercontent.com'
-| `server.oidc_authentication.client_secret` | '6Q_jmRMgrPNOc_mN91boe-9EP'
-| `server.oidc_authentication.redirect_url` | 'https://localhost:8080/oidc/v1/callback'
-| `server.oidc_authentication.provider_url` | 'https://accounts.google.com'
-| `server.oidc_authentication.scopes` | 'openid profile email'
-| `server.oidc_authentication.claim_json_key` | 'email'
-| `server.oidc_authentication.principal_regex` | '^([^@]+)@[^@]+$'
-| `server.oidc_authentication.autologin` | true
-
-- `enabled` is a Boolean that enables or disables SSO.
-- `client_id` and `client_secret` are generated by the external identity provider.
-- `redirect_url` specifies the callback URL that redirects the user to CockroachDB after a successful authentication. This can be the address of a node in the cluster or the address of a load balancer that routes traffic to the nodes. The path must be appended with `/oidc/v1/callback`.
-- `provider_url` specifies the OAuth issuer identifier. Ensure that the URL does not have a terminating `/`. For more information, see the [OIDC specification](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig). Note that CockroachDB appends the required `/.well-known/openid-configuration` by default. You do not need to include it.
-- `scopes` is a space-delimited list of the [OAuth scopes](https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims) being requested for an Access Token. The `openid` scope must be included.
-- `claim_json_key` is the key of the field to be extracted from the external identity provider's [ID Token](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) and mapped to a SQL user. This field is likely to be a [standard claim](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims) such as `email` from which a username is extracted via `principal_regex`.
-- `principal_regex` is a regular expression applied to the field specified by `claim_json_key`. It is used to extract an identifier that can be mapped to a SQL user. For example:
-	- `^([^@]+)@[^@]+$` matches any email address (defined as a string containing one `@` sign) and extracts a username from the string to the left of `@`.
-	- `^(.+)$` maps the claim directly to a principal.
-- `autologin` is a Boolean. When `true`, upon loading the DB Console login page, the browser will automatically initiate the OIDC authentication process by redirecting to `/oidc/v1/login` instead of waiting for the user to log in manually or click the OIDC login button.
-
-## Example (Google OAuth 2.0)
-
-These steps demonstrate how to enable SSO authentication for the DB Console on a [local secure cluster](secure-a-cluster.html) using [Google's OAuth 2.0](https://developers.google.com/identity/protocols/oauth2) implementation.
-
-1. Open the [Credentials page](https://console.developers.google.com/apis/credentials) for your account at Google APIs.
-
-1. Click **+ CREATE CREDENTIALS** and select **OAuth client ID**. Specify a **web application** from the pulldown menu.
-
-1. Note the *client ID* and *client secret* of the OAuth 2.0 client. You can find these in the dialog that appears after you create the client, or in the details view for the client:
-
-	<img src="{{ 'images/v20.2/google-oidc-client.png' | relative_url }}" alt="Google OAuth 2.0 client details" style="border:1px solid #eee;max-width:100%" />
-
-1. Add the callback URL to the list of **Authorized redirect URIs**. On a local cluster, this will be `https://localhost:8080/oidc/v1/callback`. You will later set `server.oidc_authentication.redirect_url` to the same value.
-
-1. Open a SQL shell to the cluster on node 1:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --certs-dir=certs --host=localhost:26257
-    ~~~
-
-1. Specify the client ID and client secret you obtained earlier:
-
-	{% include copy-clipboard.html %}
-	~~~ sql
-	> SET CLUSTER SETTING server.oidc_authentication.client_id = '\<client id\>';
-	~~~
-
-	{% include copy-clipboard.html %}
-	~~~ sql
-	> SET CLUSTER SETTING server.oidc_authentication.client_secret = '\<client secret\>';
-	~~~
-
-1. Specify the OAuth issuer identifier:
-
-	{% include copy-clipboard.html %}
-	~~~ sql
-	> SET CLUSTER SETTING server.oidc_authentication.provider_url = 'https://accounts.google.com';
-	~~~
-
-1. Specify the callback URL to redirect the user to the CockroachDB cluster:
-
-	{% include copy-clipboard.html %}
-	~~~ sql
-	> SET CLUSTER SETTING server.oidc_authentication.redirect_url = 'https://localhost:8080/oidc/v1/callback';
-	~~~
-
-1. Specify the following values to obtain an OIDC identifier that will be mapped to a SQL user.
-
-	Request the `openid` and `email` scopes from the Access Token:
-
-	{% include copy-clipboard.html %}
-	~~~ sql
-	> SET CLUSTER SETTING server.oidc_authentication.scopes = 'openid email';
-	~~~
-
-	Specify the `email` field from the ID Token:
-
-	{% include copy-clipboard.html %}
-	~~~ sql
-	> SET CLUSTER SETTING server.oidc_authentication.claim_json_key = 'email';
-	~~~
-
-	Use a regular expression that will extract a username from `email` that you can match to a SQL user. For example, `'^([^@]+)@cockroachlabs\.com$'` extracts the characters that precede `@cockroachlabs.com` in the email address.
-
-	{% include copy-clipboard.html %}
-	~~~ sql
-	> SET CLUSTER SETTING server.oidc_authentication.principal_regex = '^([^@]+)@cockroachlabs.com$';
-	~~~
-
-1. [Create a SQL user](create-user.html#create-a-user) that will log into the DB Console. The SQL username you specify must match the identifier obtained in the previous step. For example, a user with the email address `maxroach@cockroachlabs.com` will need the SQL username `maxroach`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE USER maxroach;
-    ~~~
-
-1. Finally, enable OIDC authentication:
-
-	{% include copy-clipboard.html %}
-	~~~ sql
-	> SET CLUSTER SETTING server.oidc_authentication.enabled = true;
-	~~~
-
-	When the user [accesses the DB Console](ui-overview.html#db-console-access), they will be able to log in with their Google account.
-
-	<img src="{{ 'images/v20.2/ui_login_sso.png' | relative_url }}" alt="DB Console Single Sign-on" style="border:1px solid #eee;max-width:50%" />
-
-{{site.data.alerts.callout_info}}
-You can optionally enable the [`server.oidc_authentication.autologin` cluster setting](#cluster-settings) to automatically log in an authenticated user who visits the DB Console.
-{{site.data.alerts.end}}
diff --git a/src/current/v20.2/st_contains.md b/src/current/v20.2/st_contains.md
deleted file mode 100644
index 020c996017e..00000000000
--- a/src/current/v20.2/st_contains.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: ST_Contains
-summary: ST_Contains(A, B) returns true if no point in shape B lies outside of shape A, and at least one point in the interior of B lies in the interior of A.
-toc: true
-has_prefixed_variant: true
----
-
-Given two shapes _A_ and _B_, the predicate function `ST_Contains(A, B)` returns `true` if:
-
-- No point in _B_ lies outside of shape _A_, and
-- At least one point in the interior of _B_ lies in the interior of _A_.
-
-In other words, the exterior of shape _A_ must not include any point in _B_, and one or more points of _B_'s interior must lie in the interior of _A_.
-
-This behavior is similar to [`ST_Covers`](st_covers.html), except that the criteria are more exacting, and therefore some pairs of shapes will be rejected by this function that would be accepted by `ST_Covers`.
-
-`ST_Contains` works on the following data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% endif %}
-
-{{site.data.alerts.callout_info}}
-This function is the inverse of [`ST_Within`](st_within.html).
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because:
-
-- No point in the LineString _B_ lies outside of the Polygon _A_, and
-- At least one point in the interior of _B_ lies in the interior of _A_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_Contains(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;LINESTRING(-88.243385 40.116421, -87.906471 43.038902, -95.992775 36.153980)'));
-~~~
-
-~~~
-  st_contains
----------------
-     true
-
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_contains_true.png' | relative_url }}" alt="ST_Contains - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- At least one point in the interior of LineString _B_ does not lie in the interior of the Polygon _A_.  
-
-Note that A query against these shapes with [`ST_Covers`](st_covers.html) will return `true`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_contains(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;LINESTRING( -87.906471 43.038902, -95.992775 36.153980)'));
-~~~
-
-~~~
-  st_contains
----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_contains_false.png' | relative_url }}" alt="ST_Contains - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_convexhull.md b/src/current/v20.2/st_convexhull.md
deleted file mode 100644
index 639b632bf69..00000000000
--- a/src/current/v20.2/st_convexhull.md
+++ /dev/null
@@ -1,268 +0,0 @@
----
-title: ST_ConvexHull
-summary: ST_ConvexHull(A) returns another shape B that is the convex hull of A.
-toc: true
-has_prefixed_variant: false
----
-
-Given a shape _A_, `ST_ConvexHull(A)` returns another shape _B_ that is the [convex hull](https://en.wikipedia.org/wiki/Convex_hull) of _A_.  The convex hull of a shape is the smallest [convex set](https://en.wikipedia.org/wiki/Convex_set) of points that [contains](st_contains.html) every point in the set that comprises that shape.
-
-In other words, given a set of points _A_ in the plane, the convex hull is the shape _B_ created by stretching an imaginary rubber band around the outermost points in _A_.
-
-`ST_ConvexHull` works on the following data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-
-{{site.data.alerts.callout_info}}
-`ST_ConvexHull` is not an aggregate function.  It operates on a single `GEOMETRY` object.  This means that in practice it is most often used in combination with an aggregate function such as [`ST_Union`](st_union.html).
-{{site.data.alerts.end}}
-
-## Examples
-
-In this example, we will generate the convex hull of a single geometry.  The geometry is made from many individual points using [`ST_Union`](st_union.html).
-
-1. Create a temporary table to hold all the points, which will be in [Well Known Text (WKT)](spatial-glossary.html#wkt) format:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    CREATE TABLE tmp (ID UUID DEFAULT gen_random_uuid(), geom_text STRING);
-    ~~~
-
-2. Insert the points with the following statement:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    INSERT INTO tmp (geom_text) VALUES
-    ('POINT (-73.962090000000003 40.609226)'),
-    ('POINT (-74.007309000000006 40.619892)'),
-    ('POINT (-73.949724000000003 41.498103999999998)'),
-    ('POINT (-72.390808000000007 40.961891999999999)'),
-    ('POINT (-77.937476000000004 43.218451000000002)'),
-    ('POINT (-73.842978000000002 40.944997999999998)'),
-    ('POINT (-73.928291999999999 40.680906999999998)'),
-    ('POINT (-73.914484999999999 40.775554)'),
-    ('POINT (-73.993281999999994 40.722833000000001)'),
-    ('POINT (-73.900373999999999 41.691662000000001)'),
-    ('POINT (-73.787897999999998 42.250467)'),
-    ('POINT (-75.062138000000004 42.454003)'),
-    ('POINT (-73.992576 40.753692000000001)'),
-    ('POINT (-75.647559999999999 44.590586000000002)'),
-    ('POINT (-73.698974000000007 40.832500000000003)'),
-    ('POINT (-73.957140999999993 40.728864000000002)'),
-    ('POINT (-73.954773000000003 40.732667999999997)'),
-    ('POINT (-74.024456000000001 41.521116999999997)'),
-    ('POINT (-73.785302000000001 43.081800000000001)'),
-    ('POINT (-74.860436000000007 43.040708000000002)'),
-    ('POINT (-74.001165999999998 40.687367000000002)'),
-    ('POINT (-78.809790000000007 42.845362000000002)'),
-    ('POINT (-75.061370999999994 41.608192000000003)'),
-    ('POINT (-76.499137000000005 42.440623000000002)'),
-    ('POINT (-73.379208000000006 43.027712000000001)'),
-    ('POINT (-73.684466999999998 41.259498000000001)'),
-    ('POINT (-74.003300999999993 40.706865999999998)'),
-    ('POINT (-76.384369000000007 43.034204000000003)'),
-    ('POINT (-73.983408999999995 40.723255000000002)'),
-    ('POINT (-74.670794000000001 42.371471999999997)'),
-    ('POINT (-73.963970000000003 40.804766999999998)'),
-    ('POINT (-73.989228999999995 40.743865)'),
-    ('POINT (-73.487143000000003 42.587166000000003)'),
-    ('POINT (-78.608046999999999 42.767758999999998)'),
-    ('POINT (-78.824476000000004 42.754263999999999)'),
-    ('POINT (-72.185676999999998 40.963121999999998)'),
-    ('POINT (-78.639556999999996 43.001435000000001)'),
-    ('POINT (-77.428916999999998 43.212463)'),
-    ('POINT (-73.964771999999996 40.770071999999999)'),
-    ('POINT (-73.937073999999996 40.578499000000001)'),
-    ('POINT (-74.076237000000006 40.636749000000002)'),
-    ('POINT (-73.923480999999995 41.091296)'),
-    ('POINT (-78.00206 42.718395000000001)'),
-    ('POINT (-74.992647000000005 43.018610000000002)'),
-    ('POINT (-73.991900000000001 40.683962000000001)'),
-    ('POINT (-74.119761999999994 42.040447)'),
-    ('POINT (-73.955706000000006 40.785203000000003)'),
-    ('POINT (-73.698363000000001 42.709778)'),
-    ('POINT (-75.296575000000004 43.098322000000003)'),
-    ('POINT (-73.804747000000006 42.709560000000003)'),
-    ('POINT (-79.326158000000007 42.102457000000001)'),
-    ('POINT (-73.938518000000002 40.837735000000002)'),
-    ('POINT (-73.976410999999999 40.672561999999999)'),
-    ('POINT (-73.978993000000003 40.745123999999997)'),
-    ('POINT (-77.587306999999996 43.159300999999999)'),
-    ('POINT (-74.001251999999994 40.734977000000001)'),
-    ('POINT (-76.206723999999994 43.102012000000002)'),
-    ('POINT (-78.876722000000001 42.922820999999999)'),
-    ('POINT (-73.495369999999994 44.703318000000003)'),
-    ('POINT (-79.052965999999998 43.105055)'),
-    ('POINT (-73.551120999999995 41.189729)'),
-    ('POINT (-73.760520999999997 40.809649999999998)'),
-    ('POINT (-73.952360999999996 42.077744000000003)'),
-    ('POINT (-76.511525000000006 43.456606000000001)'),
-    ('POINT (-75.036815000000004 42.448793000000002)'),
-    ('POINT (-75.544407000000007 42.826815000000003)'),
-    ('POINT (-73.686974000000006 40.724902)'),
-    ('POINT (-77.582922999999994 43.154963000000002)'),
-    ('POINT (-78.836257000000003 42.960456999999998)'),
-    ('POINT (-73.919056999999995 41.091124999999998)'),
-    ('POINT (-73.998487999999995 40.733795999999998)'),
-    ('POINT (-73.939606999999995 40.815913000000002)'),
-    ('POINT (-74.058107000000007 41.083153000000003)'),
-    ('POINT (-73.991060000000004 40.733919)'),
-    ('POINT (-73.967905000000002 40.758032999999998)'),
-    ('POINT (-73.875281000000001 41.016382999999998)'),
-    ('POINT (-77.134634000000005 42.961303000000001)'),
-    ('POINT (-78.885418999999999 42.906629000000002)'),
-    ('POINT (-73.553145999999998 40.665826000000003)'),
-    ('POINT (-73.834867000000003 42.621578999999997)'),
-    ('POINT (-73.982307000000006 40.752575)'),
-    ('POINT (-77.816855000000004 42.795613000000003)'),
-    ('POINT (-73.962288000000001 40.671320999999999)'),
-    ('POINT (-72.354918999999995 41.083874999999999)'),
-    ('POINT (-73.965331000000006 40.806128999999999)'),
-    ('POINT (-74.080895999999996 41.844256000000001)'),
-    ('POINT (-73.942249000000004 40.812187000000002)'),
-    ('POINT (-73.974255999999997 40.783757999999999)'),
-    ('POINT (-73.990206999999998 40.754969000000003)'),
-    ('POINT (-73.601747000000003 41.562685000000002)'),
-    ('POINT (-74.117880999999997 42.040733000000003)'),
-    ('POINT (-73.979851999999994 40.664327999999998)'),
-    ('POINT (-73.960042999999999 40.657589000000002)'),
-    ('POINT (-74.009314000000003 40.715324000000003)'),
-    ('POINT (-73.903509 40.703226000000001)'),
-    ('POINT (-74.030330000000006 40.624713999999997)'),
-    ('POINT (-73.909406000000004 40.814979000000001)'),
-    ('POINT (-73.903160999999997 40.744929999999997)'),
-    ('POINT (-73.504622999999995 41.952860000000001)'),
-    ('POINT (-73.865554000000003 42.219304000000001)'),
-    ('POINT (-73.981960000000001 40.766441)'),
-    ('POINT (-73.913732999999993 40.698230000000002)'),
-    ('POINT (-73.596703000000005 40.874966000000001)'),
-    ('POINT (-73.974082999999993 40.686098000000001)'),
-    ('POINT (-73.996341999999999 40.725087000000002)'),
-    ('POINT (-73.595579999999998 42.363210000000002)'),
-    ('POINT (-73.952259999999995 40.674118999999997)'),
-    ('POINT (-73.993341000000001 40.730010999999998)'),
-    ('POINT (-73.989086999999998 40.721902)'),
-    ('POINT (-73.955855999999997 40.655028000000001)'),
-    ('POINT (-74.002930000000006 40.731848999999997)'),
-    ('POINT (-76.086753000000002 44.242874)'),
-    ('POINT (-73.839067 42.681877999999998)'),
-    ('POINT (-74.020105000000001 41.935105)'),
-    ('POINT (-73.980250999999996 44.279376999999997)'),
-    ('POINT (-74.085936000000004 41.747742000000002)'),
-    ('POINT (-77.227361999999999 43.063468)'),
-    ('POINT (-74.093547000000001 40.924697999999999)'),
-    ('POINT (-74.986999999999995 44.669899999999998)'),
-    ('POINT (-73.793597000000005 41.135866)'),
-    ('POINT (-78.889482000000001 42.924545000000002)'),
-    ('POINT (-73.914946 41.936036999999999)'),
-    ('POINT (-73.9071 41.721612999999998)'),
-    ('POINT (-73.993579999999994 40.736569000000003)'),
-    ('POINT (-73.900388000000007 41.691189000000001)'),
-    ('POINT (-73.989261999999997 40.663339000000001)'),
-    ('POINT (-73.918380999999997 41.090746000000003)'),
-    ('POINT (-73.862252999999995 40.839613)'),
-    ('POINT (-73.806933000000001 40.989787999999997)'),
-    ('POINT (-73.635006000000004 40.744909)'),
-    ('POINT (-73.794276999999994 41.008797000000001)'),
-    ('POINT (-73.759060000000005 41.022123000000001)'),
-    ('POINT (-73.711965000000006 40.968676000000002)'),
-    ('POINT (-74.668248000000006 42.372920000000001)'),
-    ('POINT (-73.992476999999994 40.739109999999997)'),
-    ('POINT (-74.131673000000006 44.326892000000001)'),
-    ('POINT (-73.974738000000002 40.732664)'),
-    ('POINT (-73.812349999999995 40.798867000000001)'),
-    ('POINT (-78.641949999999994 42.991985)'),
-    ('POINT (-73.962226999999999 40.778944000000003)'),
-    ('POINT (-74.374174999999994 43.006495000000001)'),
-    ('POINT (-77.095714000000001 43.041158000000003)'),
-    ('POINT (-73.425764000000001 40.871898000000002)'),
-    ('POINT (-73.466729000000001 44.708036)'),
-    ('POINT (-73.978020999999998 40.686546999999997)'),
-    ('POINT (-73.974082999999993 40.686098000000001)'),
-    ('POINT (-73.971849000000006 40.602485000000001)'),
-    ('POINT (-73.983153999999999 40.690553000000001)'),
-    ('POINT (-77.052417000000005 42.143089000000003)'),
-    ('POINT (-73.776431000000002 40.934483)'),
-    ('POINT (-74.002019000000004 40.730927999999999)'),
-    ('POINT (-73.772469999999998 42.264814000000001)'),
-    ('POINT (-73.772876999999994 41.158641000000003)'),
-    ('POINT (-72.296062000000006 41.002409)'),
-    ('POINT (-74.021124999999998 41.933720000000001)'),
-    ('POINT (-74.058107000000007 41.083153000000003)'),
-    ('POINT (-73.967922999999999 40.801301000000002)'),
-    ('POINT (-72.294278000000006 41.000610999999999)'),
-    ('POINT (-76.499340000000004 42.438741999999998)'),
-    ('POINT (-73.976597999999996 40.786610000000003)'),
-    ('POINT (-73.988552999999996 40.703600000000002)'),
-    ('POINT (-74.004855000000006 40.741959000000001)'),
-    ('POINT (-73.844444999999993 40.925654999999999)'),
-    ('POINT (-74.005101999999994 40.746654999999997)'),
-    ('POINT (-73.937281999999996 42.819218999999997)'),
-    ('POINT (-74.001677000000001 40.736243000000002)'),
-    ('POINT (-73.684112999999996 40.981757000000002)'),
-    ('POINT (-73.919064000000006 40.832836999999998)'),
-    ('POINT (-78.885268999999994 42.944516)'),
-    ('POINT (-72.299519000000004 40.994070999999998)'),
-    ('POINT (-73.833477999999999 40.940247999999997)'),
-    ('POINT (-73.695717000000002 41.783996999999999)'),
-    ('POINT (-73.926891999999995 40.807422000000003)'),
-    ('POINT (-74.085899999999995 41.747892999999998)'),
-    ('POINT (-73.957583 41.417974999999998)');
-    ~~~
-
-3. Run the query below, which gathers the points into a single geometry using [`ST_Union`](st_union.html) that can be operated on by `ST_ConvexHull`, and converts the output to [GeoJSON](spatial-glossary.html#geojson) so that we can view it with [geojson.io](http://geojson.io):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql 
-    WITH
-        the_geoms_table
-            AS (
-                SELECT
-                    st_union(st_geomfromtext(geom_text)) AS the_union
-                FROM
-                    tmp
-            )
-    SELECT
-        st_asgeojson(st_convexhull(the_union))
-    FROM
-        the_geoms_table;
-    ~~~
-
-    ~~~ json
-    {"type":"Polygon","coordinates":[[[-73.937074,40.578499],[-79.326158,42.102457],[-79.052966,43.105055],[-75.64756,44.590586],[-74.987,44.6699],[-73.466729,44.708036],[-72.185677,40.963122],[-73.937074,40.578499]]]}
-    ~~~
-
-4. Paste the JSON emitted in the previous step into [geojson.io](http://geojson.io) and you should see an image like the following, which shows the convex hull surrounding the locations of [most of the independent bookstores in New York State](https://www.bookweb.org/member_directory/search/ABAmember/results/0/0/ny/0):
-
-    <img src="{{ 'images/v20.2/geospatial/st_convexhull.png' | relative_url }}" alt="ST_ConvexHull example" style="border:1px solid #eee;max-width:100%" />
-
-5. Finally, drop the temporary table if you no longer need it:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    DROP TABLE tmp;
-    ~~~
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_coveredby.md b/src/current/v20.2/st_coveredby.md
deleted file mode 100644
index 1f8850a77a2..00000000000
--- a/src/current/v20.2/st_coveredby.md
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: ST_CoveredBy
-summary: ST_CoveredBy(A, B) returns true if no point in shape A lies outside of shape B
-toc: true
-has_prefixed_variant: true
----
-
-Given two shapes _A_ and _B_, the predicate function `ST_CoveredBy(A, B)` returns `true` if no point in _A_ lies outside of shape _B_.  Otherwise, it returns `false`.
-
-In other words, shape _B_ must completely cover every point in _A_.
-
-`ST_CoveredBy` works on the following data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-- [`GEOGRAPHY`](spatial-glossary.html#geography)
-
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% endif %}
-
-{{site.data.alerts.callout_info}}
-This function is the inverse of [`ST_Covers`](st_covers.html).
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because:
-
-- No Point in the smaller Polygon _A_ lies outside of the larger Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_CoveredBy(st_geomfromtext('SRID=4326;POLYGON((-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))'), st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'));
-~~~
-
-~~~
-  st_coveredby
-----------------
-      true
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_coveredby_true.png' | relative_url }}" alt="ST_CoveredBy - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- Many Points in the smaller Polygon _A_ lie outside of the larger Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_CoveredBy(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-84.191605 39.758949, -75.165222 39.952583, -78.878738 42.880230, -84.191605 39.758949))'));
-~~~
-
-~~~
-  st_coveredby
-----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_coveredby_false.png' | relative_url }}" alt="ST_CoveredBy - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_covers.md b/src/current/v20.2/st_covers.md
deleted file mode 100644
index 8f0036c751d..00000000000
--- a/src/current/v20.2/st_covers.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: ST_Covers
-summary: ST_Covers(A, B) returns true if no point in shape B lies outside of shape A
-toc: true
-has_prefixed_variant: true
----
-
-Given two shapes _A_ and _B_, predicate function `ST_Covers(A, B)` returns `true` if no point in _B_ lies outside of shape _A_.  Otherwise, it returns `false`.
-
-In other words, shape _A_ must completely cover every point in _B_.
-
-This behavior is similar to [`ST_Contains`](st_contains.html), except that the criteria for `ST_Contains` are more exacting, and therefore some pairs of shapes will be accepted by this function that would be rejected by `ST_Contains`.
-
-`ST_Covers` works on the following data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-- [`GEOGRAPHY`](spatial-glossary.html#geography)
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% endif %}
-
-{{site.data.alerts.callout_info}}
-This function is the inverse of [`ST_CoveredBy`](st_coveredby.html).
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because:
-
-- No Point in the smaller Polygon _B_ lies outside of the larger Polygon _A_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_Covers(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))'));
-~~~
-
-~~~
-   st_covers
----------------
-     true
-
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_covers_true.png' | relative_url }}" alt="ST_Covers - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- Many Points in the smaller Polygon _B_ lie outside of the larger Polygon _A_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_Covers(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-84.191605 39.758949, -75.165222 39.952583, -78.878738 42.880230, -84.191605 39.758949))'));
-~~~
-
-~~~
-   st_covers
----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_covers_false.png' | relative_url }}" alt="ST_Covers - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-+ [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_disjoint.md b/src/current/v20.2/st_disjoint.md
deleted file mode 100644
index aa105990dbc..00000000000
--- a/src/current/v20.2/st_disjoint.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: ST_Disjoint
-summary: ST_Disjoint(A, B) returns true if no point in shape A lies within shape B.
-toc: true
-has_prefixed_variant: false
----
-
-Given two shapes _A_ and _B_, `ST_Disjoint(A, B)` returns `true` if the shapes do not share any of the same space -- that is, if no point in the set that comprises _A_ is also a member of the set of points that make up _B_.
-
-`ST_Disjoint` works on the following spatial data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% else %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` does not make use of [spatial indexes](spatial-indexes.html).
-{{site.data.alerts.end}}
-{% endif %}
-
-{{site.data.alerts.callout_info}}
-This function is the inverse of [`ST_Intersects`](st_intersects.html).
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because:
-
-- No Point in the set that comprises Polygon _A_ is also a member of the set of points that make up Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_disjoint(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902), (-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))'), st_geomfromtext('SRID=4326;POLYGON((-87.356934 41.595161, -84.512016 39.103119, -86.529167 39.162222, -87.356934 41.595161))'));
-~~~
-
-~~~
-  st_disjoint
----------------
-     true
-
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_disjoint_true.png' | relative_url }}" alt="ST_Disjoint - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- Many Points in the set that comprises Polygon _A_ are also members of the set of points that make up Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_disjoint(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-84.191605 39.758949, -75.165222 39.952583, -78.878738 42.880230, -84.191605 39.758949))'));
-~~~
-
-~~~
-  st_disjoint
----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_disjoint_false.png' | relative_url }}" alt="ST_Disjoint - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_equals.md b/src/current/v20.2/st_equals.md
deleted file mode 100644
index 9e13567c203..00000000000
--- a/src/current/v20.2/st_equals.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: ST_Equals
-summary: ST_Equals(A, B) returns true if every point that makes up shape A is also part of shape B, and vice versa.
-toc: true
-has_prefixed_variant: true
----
-
-Given two shapes _A_ and _B_, `ST_Equals(A, B)` returns `true` if every point in the set of points that make up _A_ is also in _B_, and if every point in the set of points that make up _B_ is also in _A_.  The ordering of the points in _A_ and _B_ may differ, but they must be made up of equivalent sets.
-
-Another way of describing `ST_Equals(A, B)` is that it will return `true` if both `ST_Within(A, B)` and `ST_Within(B, A)` also return `true`.
-
-`ST_Equals` works on the following data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% endif %}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because:
-
-- Every Point in the set of Points that make up Polygon _A_ is also in Polygon _B_, and  every Point in the set of Points that make up Polygon _B_ is also in Polygon _A_
-
-As mentioned above, the ordering of the points in _A_ and _B_ does not matter.  Below, there are two triangles with the same vertices, which are ordered differently.  In the screenshot, one triangle is drawn in yellow, and the other blue.  The blue and yellow strokes of the two separate triangles' boundaries are visible. Because the images are overlaid on each other, the yellow and blue combine to make part of the exterior outline of the image a green color.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_equals(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-95.992775 36.153980, -87.906471 43.038902, -75.704722 36.076944, -95.992775 36.153980))'));
-~~~
-
-~~~
-   st_equals
----------------
-     true
-
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_equals_true.png' | relative_url }}" alt="ST_Equals - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- It's obvious that not every Point that makes up the set of Points in Polygon _A_ is not also in Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_equals(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-84.191605 39.758949, -75.165222 39.952583, -78.878738 42.880230, -84.191605 39.758949))'));
-~~~
-
-~~~
-   st_equals
----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_equals_false.png' | relative_url }}" alt="ST_Equals - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_intersects.md b/src/current/v20.2/st_intersects.md
deleted file mode 100644
index fb4264e2d7c..00000000000
--- a/src/current/v20.2/st_intersects.md
+++ /dev/null
@@ -1,92 +0,0 @@
----
-title: ST_Intersects
-summary: ST_Intersects(A, B) returns true if any point in shape A lies within shape B.
-toc: true
-has_prefixed_variant: true
----
-
-Given two shapes _A_ and _B_, `ST_Intersects(A, B)` returns `true` if the shapes share any of the same space -- that is, if any point in the set that comprises _A_ is also a member of the set of points that make up _B_.
-
-`ST_Intersects` works on the following data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-- [`GEOGRAPHY`](spatial-glossary.html#geography)
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% endif %}
-
-{{site.data.alerts.callout_info}}
-This function is the inverse of [`ST_Disjoint`](st_disjoint.html).
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because:
-
-- The shapes share some of the same space -- that is, there are Points in the set that comprises Polygon _A_ that are also members of Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_intersects(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-84.191605 39.758949, -75.165222 39.952583, -78.878738 42.880230, -84.191605 39.758949))'));
-~~~
-
-~~~
- st_intersects
----------------
-     true
-
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_intersects_true.png' | relative_url }}" alt="ST_Intersects - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- The shapes do not share any of the same space -- that is, there are no Points in the set that comprises Polygon _A_ that are also members of Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_intersects(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-79.995888 40.440624,-74.666728 40.358244, -76.5 42.443333, -79.995888 40.440624))'));
-~~~
-
-~~~
- st_intersects
----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_intersects_false.png' | relative_url }}" alt="ST_Intersects - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_overlaps.md b/src/current/v20.2/st_overlaps.md
deleted file mode 100644
index 9c15d61aefd..00000000000
--- a/src/current/v20.2/st_overlaps.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: ST_Overlaps
-summary: ST_Overlaps(A, B) returns true if the shapes intersect, but neither is contained within the other.
-toc: true
-has_prefixed_variant: true
----
-
-Given two shapes _A_ and _B_, `ST_Overlaps(A, B)` returns `true` if the following criteria are met:
-
-- The shapes share any of the same space -- that is, if any point in the set that comprises _A_ is also a member of the set of points that make up _B_.
-- Neither of the shapes is contained by the other, in the [`ST_Contains`](st_contains.html) sense.
-
-In other words, `ST_Overlaps` returns `true` if the shapes intersect (in the [`ST_Intersects`](st_intersects.html) sense), but neither is contained within the other.
-
-`ST_Overlaps` works on the following spatial data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% endif %}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because:
-
-- There is a Point in the set that comprises Polygon _A_ that is also a member of the set of Points that make up Polygon _B_.
-- Neither of the shapes is contained by the other, in the [`ST_Contains`](st_contains.html) sense.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_overlaps(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;POLYGON((-84.191605 39.758949, -75.165222 39.952583, -78.878738 42.880230, -84.191605 39.758949))'));
-~~~
-
-~~~
-  st_overlaps
----------------
-     true
-
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_overlaps_true.png' | relative_url }}" alt="ST_Overlaps - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- - There is not any Point in the set that comprises Polygon _A_ that is also a member of the set of Points that make up Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_overlaps(st_geomfromtext('SRID=4326;POLYGON((-79.995888 40.440624,-74.666728 40.358244, -76.5 42.443333, -79.995888 40.440624))'), st_geomfromtext('SRID=4326;POLYGON((-79.976111 40.374444, -74.621157 40.323294, -76.609383 39.299236, -79.976111 40.374444))'));
-~~~
-
-~~~
-  st_overlaps
----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_overlaps_false.png' | relative_url }}" alt="ST_Overlaps - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_touches.md b/src/current/v20.2/st_touches.md
deleted file mode 100644
index aa581c65245..00000000000
--- a/src/current/v20.2/st_touches.md
+++ /dev/null
@@ -1,93 +0,0 @@
----
-title: ST_Touches
-summary: ST_Touches(A, B) returns true if A and B have at least one point in common, but their interiors do not intersect.
-toc: true
-has_prefixed_variant: true
----
-
-Given two shapes _A_ and _B_, `ST_Touches(A, B)` returns `true` if both the following are true:
-
-- At least one point in the set of points that comprises _A_ is also a member of the set of points that make up _B_.
-- No points that make up the interior of _A_ are also part of the interior of _B_.
-
-In other words, _A_ and _B_ have a point along their boundaries in common (i.e., they "touch"), but none of their interior points intersect.  This distinction between shapes touching along a boundary vs. intersecting is also made by the [DE-9IM](spatial-glossary.html#de-9IM) standard.
-
-`ST_Touches` works on the following data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% endif %}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because both of the following are true:
-
-- At least one point in the set of Points that comprise Polygon _A_ is a member of the set of points that make up the LineString _B_.
-- No points from the interior of _A_ are also part of the interior of _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_touches(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902), (-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))'), st_geomfromtext('SRID=4326;LINESTRING(-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832)'));
-~~~
-
-~~~
-   st_touches
----------------
-     true
-
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_touches_true.png' | relative_url }}" alt="ST_Touches - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- Some points from the interior of the LineString _B_ are also part of the interior of the Polygon _A_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT st_touches(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'), st_geomfromtext('SRID=4326;LINESTRING(-88.243385 40.116421, -87.906471 43.038902, -95.992775 36.153980, -95.235278 38.971667)'));
-~~~
-
-~~~
-   st_touches
----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_touches_false.png' | relative_url }}" alt="ST_Touches - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_union.md b/src/current/v20.2/st_union.md
deleted file mode 100644
index c3c459c6751..00000000000
--- a/src/current/v20.2/st_union.md
+++ /dev/null
@@ -1,269 +0,0 @@
----
-title: ST_Union
-summary: ST_Union is an aggregate function that combines a set of shapes into a single shape.
-toc: true
----
-
-Given a set of shapes (e.g., from a [selection query](selection-queries.html)), `ST_Union` combines that set of shapes into a single shape. The resulting shape can then be passed to functions that operate on a single shape, such as [`ST_ConvexHull`](st_convexhull.html).
-
-`ST_Union` works on the following data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-
-{{site.data.alerts.callout_info}}
-The non-aggregate version of `ST_Union` is not yet implemented.  For more information, see [cockroach#49064](https://github.com/cockroachdb/cockroach/issues/49064).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Unlike `ST_Collect`, which does not change the shapes it operates on and merely gathers them into a collection, `ST_Union` modifies the shapes it operates on, merging them together.
-{{site.data.alerts.end}}
-
-## Examples
-
-In this example, we will generate a single geometry from many individual points using `ST_Union`.
-
-1. Create a temporary table to hold all the points, which will be in [Well Known Text (WKT)](spatial-glossary.html#wkt) format:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    CREATE TABLE tmp (ID UUID DEFAULT gen_random_uuid(), geom_text STRING);
-    ~~~
-
-2. Insert the points with the following statement:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    INSERT INTO tmp (geom_text) VALUES
-    ('POINT (-73.962090000000003 40.609226)'),
-    ('POINT (-74.007309000000006 40.619892)'),
-    ('POINT (-73.949724000000003 41.498103999999998)'),
-    ('POINT (-72.390808000000007 40.961891999999999)'),
-    ('POINT (-77.937476000000004 43.218451000000002)'),
-    ('POINT (-73.842978000000002 40.944997999999998)'),
-    ('POINT (-73.928291999999999 40.680906999999998)'),
-    ('POINT (-73.914484999999999 40.775554)'),
-    ('POINT (-73.993281999999994 40.722833000000001)'),
-    ('POINT (-73.900373999999999 41.691662000000001)'),
-    ('POINT (-73.787897999999998 42.250467)'),
-    ('POINT (-75.062138000000004 42.454003)'),
-    ('POINT (-73.992576 40.753692000000001)'),
-    ('POINT (-75.647559999999999 44.590586000000002)'),
-    ('POINT (-73.698974000000007 40.832500000000003)'),
-    ('POINT (-73.957140999999993 40.728864000000002)'),
-    ('POINT (-73.954773000000003 40.732667999999997)'),
-    ('POINT (-74.024456000000001 41.521116999999997)'),
-    ('POINT (-73.785302000000001 43.081800000000001)'),
-    ('POINT (-74.860436000000007 43.040708000000002)'),
-    ('POINT (-74.001165999999998 40.687367000000002)'),
-    ('POINT (-78.809790000000007 42.845362000000002)'),
-    ('POINT (-75.061370999999994 41.608192000000003)'),
-    ('POINT (-76.499137000000005 42.440623000000002)'),
-    ('POINT (-73.379208000000006 43.027712000000001)'),
-    ('POINT (-73.684466999999998 41.259498000000001)'),
-    ('POINT (-74.003300999999993 40.706865999999998)'),
-    ('POINT (-76.384369000000007 43.034204000000003)'),
-    ('POINT (-73.983408999999995 40.723255000000002)'),
-    ('POINT (-74.670794000000001 42.371471999999997)'),
-    ('POINT (-73.963970000000003 40.804766999999998)'),
-    ('POINT (-73.989228999999995 40.743865)'),
-    ('POINT (-73.487143000000003 42.587166000000003)'),
-    ('POINT (-78.608046999999999 42.767758999999998)'),
-    ('POINT (-78.824476000000004 42.754263999999999)'),
-    ('POINT (-72.185676999999998 40.963121999999998)'),
-    ('POINT (-78.639556999999996 43.001435000000001)'),
-    ('POINT (-77.428916999999998 43.212463)'),
-    ('POINT (-73.964771999999996 40.770071999999999)'),
-    ('POINT (-73.937073999999996 40.578499000000001)'),
-    ('POINT (-74.076237000000006 40.636749000000002)'),
-    ('POINT (-73.923480999999995 41.091296)'),
-    ('POINT (-78.00206 42.718395000000001)'),
-    ('POINT (-74.992647000000005 43.018610000000002)'),
-    ('POINT (-73.991900000000001 40.683962000000001)'),
-    ('POINT (-74.119761999999994 42.040447)'),
-    ('POINT (-73.955706000000006 40.785203000000003)'),
-    ('POINT (-73.698363000000001 42.709778)'),
-    ('POINT (-75.296575000000004 43.098322000000003)'),
-    ('POINT (-73.804747000000006 42.709560000000003)'),
-    ('POINT (-79.326158000000007 42.102457000000001)'),
-    ('POINT (-73.938518000000002 40.837735000000002)'),
-    ('POINT (-73.976410999999999 40.672561999999999)'),
-    ('POINT (-73.978993000000003 40.745123999999997)'),
-    ('POINT (-77.587306999999996 43.159300999999999)'),
-    ('POINT (-74.001251999999994 40.734977000000001)'),
-    ('POINT (-76.206723999999994 43.102012000000002)'),
-    ('POINT (-78.876722000000001 42.922820999999999)'),
-    ('POINT (-73.495369999999994 44.703318000000003)'),
-    ('POINT (-79.052965999999998 43.105055)'),
-    ('POINT (-73.551120999999995 41.189729)'),
-    ('POINT (-73.760520999999997 40.809649999999998)'),
-    ('POINT (-73.952360999999996 42.077744000000003)'),
-    ('POINT (-76.511525000000006 43.456606000000001)'),
-    ('POINT (-75.036815000000004 42.448793000000002)'),
-    ('POINT (-75.544407000000007 42.826815000000003)'),
-    ('POINT (-73.686974000000006 40.724902)'),
-    ('POINT (-77.582922999999994 43.154963000000002)'),
-    ('POINT (-78.836257000000003 42.960456999999998)'),
-    ('POINT (-73.919056999999995 41.091124999999998)'),
-    ('POINT (-73.998487999999995 40.733795999999998)'),
-    ('POINT (-73.939606999999995 40.815913000000002)'),
-    ('POINT (-74.058107000000007 41.083153000000003)'),
-    ('POINT (-73.991060000000004 40.733919)'),
-    ('POINT (-73.967905000000002 40.758032999999998)'),
-    ('POINT (-73.875281000000001 41.016382999999998)'),
-    ('POINT (-77.134634000000005 42.961303000000001)'),
-    ('POINT (-78.885418999999999 42.906629000000002)'),
-    ('POINT (-73.553145999999998 40.665826000000003)'),
-    ('POINT (-73.834867000000003 42.621578999999997)'),
-    ('POINT (-73.982307000000006 40.752575)'),
-    ('POINT (-77.816855000000004 42.795613000000003)'),
-    ('POINT (-73.962288000000001 40.671320999999999)'),
-    ('POINT (-72.354918999999995 41.083874999999999)'),
-    ('POINT (-73.965331000000006 40.806128999999999)'),
-    ('POINT (-74.080895999999996 41.844256000000001)'),
-    ('POINT (-73.942249000000004 40.812187000000002)'),
-    ('POINT (-73.974255999999997 40.783757999999999)'),
-    ('POINT (-73.990206999999998 40.754969000000003)'),
-    ('POINT (-73.601747000000003 41.562685000000002)'),
-    ('POINT (-74.117880999999997 42.040733000000003)'),
-    ('POINT (-73.979851999999994 40.664327999999998)'),
-    ('POINT (-73.960042999999999 40.657589000000002)'),
-    ('POINT (-74.009314000000003 40.715324000000003)'),
-    ('POINT (-73.903509 40.703226000000001)'),
-    ('POINT (-74.030330000000006 40.624713999999997)'),
-    ('POINT (-73.909406000000004 40.814979000000001)'),
-    ('POINT (-73.903160999999997 40.744929999999997)'),
-    ('POINT (-73.504622999999995 41.952860000000001)'),
-    ('POINT (-73.865554000000003 42.219304000000001)'),
-    ('POINT (-73.981960000000001 40.766441)'),
-    ('POINT (-73.913732999999993 40.698230000000002)'),
-    ('POINT (-73.596703000000005 40.874966000000001)'),
-    ('POINT (-73.974082999999993 40.686098000000001)'),
-    ('POINT (-73.996341999999999 40.725087000000002)'),
-    ('POINT (-73.595579999999998 42.363210000000002)'),
-    ('POINT (-73.952259999999995 40.674118999999997)'),
-    ('POINT (-73.993341000000001 40.730010999999998)'),
-    ('POINT (-73.989086999999998 40.721902)'),
-    ('POINT (-73.955855999999997 40.655028000000001)'),
-    ('POINT (-74.002930000000006 40.731848999999997)'),
-    ('POINT (-76.086753000000002 44.242874)'),
-    ('POINT (-73.839067 42.681877999999998)'),
-    ('POINT (-74.020105000000001 41.935105)'),
-    ('POINT (-73.980250999999996 44.279376999999997)'),
-    ('POINT (-74.085936000000004 41.747742000000002)'),
-    ('POINT (-77.227361999999999 43.063468)'),
-    ('POINT (-74.093547000000001 40.924697999999999)'),
-    ('POINT (-74.986999999999995 44.669899999999998)'),
-    ('POINT (-73.793597000000005 41.135866)'),
-    ('POINT (-78.889482000000001 42.924545000000002)'),
-    ('POINT (-73.914946 41.936036999999999)'),
-    ('POINT (-73.9071 41.721612999999998)'),
-    ('POINT (-73.993579999999994 40.736569000000003)'),
-    ('POINT (-73.900388000000007 41.691189000000001)'),
-    ('POINT (-73.989261999999997 40.663339000000001)'),
-    ('POINT (-73.918380999999997 41.090746000000003)'),
-    ('POINT (-73.862252999999995 40.839613)'),
-    ('POINT (-73.806933000000001 40.989787999999997)'),
-    ('POINT (-73.635006000000004 40.744909)'),
-    ('POINT (-73.794276999999994 41.008797000000001)'),
-    ('POINT (-73.759060000000005 41.022123000000001)'),
-    ('POINT (-73.711965000000006 40.968676000000002)'),
-    ('POINT (-74.668248000000006 42.372920000000001)'),
-    ('POINT (-73.992476999999994 40.739109999999997)'),
-    ('POINT (-74.131673000000006 44.326892000000001)'),
-    ('POINT (-73.974738000000002 40.732664)'),
-    ('POINT (-73.812349999999995 40.798867000000001)'),
-    ('POINT (-78.641949999999994 42.991985)'),
-    ('POINT (-73.962226999999999 40.778944000000003)'),
-    ('POINT (-74.374174999999994 43.006495000000001)'),
-    ('POINT (-77.095714000000001 43.041158000000003)'),
-    ('POINT (-73.425764000000001 40.871898000000002)'),
-    ('POINT (-73.466729000000001 44.708036)'),
-    ('POINT (-73.978020999999998 40.686546999999997)'),
-    ('POINT (-73.974082999999993 40.686098000000001)'),
-    ('POINT (-73.971849000000006 40.602485000000001)'),
-    ('POINT (-73.983153999999999 40.690553000000001)'),
-    ('POINT (-77.052417000000005 42.143089000000003)'),
-    ('POINT (-73.776431000000002 40.934483)'),
-    ('POINT (-74.002019000000004 40.730927999999999)'),
-    ('POINT (-73.772469999999998 42.264814000000001)'),
-    ('POINT (-73.772876999999994 41.158641000000003)'),
-    ('POINT (-72.296062000000006 41.002409)'),
-    ('POINT (-74.021124999999998 41.933720000000001)'),
-    ('POINT (-74.058107000000007 41.083153000000003)'),
-    ('POINT (-73.967922999999999 40.801301000000002)'),
-    ('POINT (-72.294278000000006 41.000610999999999)'),
-    ('POINT (-76.499340000000004 42.438741999999998)'),
-    ('POINT (-73.976597999999996 40.786610000000003)'),
-    ('POINT (-73.988552999999996 40.703600000000002)'),
-    ('POINT (-74.004855000000006 40.741959000000001)'),
-    ('POINT (-73.844444999999993 40.925654999999999)'),
-    ('POINT (-74.005101999999994 40.746654999999997)'),
-    ('POINT (-73.937281999999996 42.819218999999997)'),
-    ('POINT (-74.001677000000001 40.736243000000002)'),
-    ('POINT (-73.684112999999996 40.981757000000002)'),
-    ('POINT (-73.919064000000006 40.832836999999998)'),
-    ('POINT (-78.885268999999994 42.944516)'),
-    ('POINT (-72.299519000000004 40.994070999999998)'),
-    ('POINT (-73.833477999999999 40.940247999999997)'),
-    ('POINT (-73.695717000000002 41.783996999999999)'),
-    ('POINT (-73.926891999999995 40.807422000000003)'),
-    ('POINT (-74.085899999999995 41.747892999999998)'),
-    ('POINT (-73.957583 41.417974999999998)');
-    ~~~
-
-3. Run the query below, which gathers the points into a single geometry using `ST_Union`, and converts the geometry to [GeoJSON](spatial-glossary.html#geojson) so that we can view it with [geojson.io](http://geojson.io):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    WITH
-        the_geoms_table
-            AS (
-                SELECT
-                    st_union(st_geomfromtext(geom_text)) AS the_union
-                FROM
-                    tmp
-            )
-    SELECT
-        st_asgeojson(the_union)
-    FROM
-        the_geoms_table;
-    ~~~
-
-    ~~~ json
-    {"type":"MultiPoint","coordinates":[[-79.326158,42.102457],[-79.052966,43.105055],[-78.889482,42.924545],[-78.885419,42.906629],[-78.885269,42.944516],[-78.876722,42.922821],[-78.836257,42.960457],[-78.824476,42.754264],[-78.80979,42.845362],[-78.64195,42.991985],[-78.639557,43.001435],[-78.608047,42.767759],[-78.00206,42.718395],[-77.937476,43.218451],[-77.816855,42.795613],[-77.587307,43.159301],[-77.582923,43.154963],[-77.428917,43.212463],[-77.227362,43.063468],[-77.134634,42.961303],[-77.095714,43.041158],[-77.052417,42.143089],[-76.511525,43.456606],[-76.49934,42.438742],[-76.499137,42.440623],[-76.384369,43.034204],[-76.206724,43.102012],[-76.086753,44.242874],[-75.64756,44.590586],[-75.544407,42.826815],[-75.296575,43.098322],[-75.062138,42.454003],[-75.061371,41.608192],[-75.036815,42.448793],[-74.992647,43.01861],[-74.987,44.6699],[-74.860436,43.040708],[-74.670794,42.371472],[-74.668248,42.37292],[-74.374175,43.006495],[-74.131673,44.326892],[-74.119762,42.040447],[-74.117881,42.040733],[-74.093547,40.924698],[-74.085936,41.747742],[-74.0859,41.747893],[-74.080896,41.844256],[-74.076237,40.636749],[-74.058107,41.083153],[-74.03033,40.624714],[-74.024456,41.521117],[-74.021125,41.93372],[-74.020105,41.935105],[-74.009314,40.715324],[-74.007309,40.619892],[-74.005102,40.746655],[-74.004855,40.741959],[-74.003301,40.706866],[-74.00293,40.731849],[-74.002019,40.730928],[-74.001677,40.736243],[-74.001252,40.734977],[-74.001166,40.687367],[-73.998488,40.733796],[-73.996342,40.725087],[-73.99358,40.736569],[-73.993341,40.730011],[-73.993282,40.722833],[-73.992576,40.753692],[-73.992477,40.73911],[-73.9919,40.683962],[-73.99106,40.733919],[-73.990207,40.754969],[-73.989262,40.663339],[-73.989229,40.743865],[-73.989087,40.721902],[-73.988553,40.7036],[-73.983409,40.723255],[-73.983154,40.690553],[-73.982307,40.752575],[-73.98196,40.766441],[-73.980251,44.279377],[-73.979852,40.664328],[-73.978993,40.745124],[-73.978021,40.686547],[-73.976598,40.78661],[-73.976411,40.672562],[-73.974738,40.732664],[-73.974256,40.783758],[-73.974083,40.686098],[-73.971849,40.602485],[-73.967923,40.801301],[-73.967905,40.758033],[-73.965331,40.806129],[-73.964772,40.770072],[-73.96397,40.804767],[-73.962288,40.671321],[-73.962227,40.778944],[-73.96209,40.609226],[-73.960043,40.657589],[-73.957583,41.417975],[-73.957141,40.728864],[-73.955856,40.655028],[-73.955706,40.785203],[-73.954773,40.732668],[-73.952361,42.077744],[-73.95226,40.674119],[-73.949724,41.498104],[-73.942249,40.812187],[-73.939607,40.815913],[-73.938518,40.837735],[-73.937282,42.819219],[-73.937074,40.578499],[-73.928292,40.680907],[-73.926892,40.807422],[-73.923481,41.091296],[-73.919064,40.832837],[-73.919057,41.091125],[-73.918381,41.090746],[-73.914946,41.936037],[-73.914485,40.775554],[-73.913733,40.69823],[-73.909406,40.814979],[-73.9071,41.721613],[-73.903509,40.703226],[-73.903161,40.74493],[-73.900388,41.691189],[-73.900374,41.691662],[-73.875281,41.016383],[-73.865554,42.219304],[-73.862253,40.839613],[-73.844445,40.925655],[-73.842978,40.944998],[-73.839067,42.681878],[-73.834867,42.621579],[-73.833478,40.940248],[-73.81235,40.798867],[-73.806933,40.989788],[-73.804747,42.70956],[-73.794277,41.008797],[-73.793597,41.135866],[-73.787898,42.250467],[-73.785302,43.0818],[-73.776431,40.934483],[-73.772877,41.158641],[-73.77247,42.264814],[-73.760521,40.80965],[-73.75906,41.022123],[-73.711965,40.968676],[-73.698974,40.8325],[-73.698363,42.709778],[-73.695717,41.783997],[-73.686974,40.724902],[-73.684467,41.259498],[-73.684113,40.981757],[-73.635006,40.744909],[-73.601747,41.562685],[-73.596703,40.874966],[-73.59558,42.36321],[-73.553146,40.665826],[-73.551121,41.189729],[-73.504623,41.95286],[-73.49537,44.703318],[-73.487143,42.587166],[-73.466729,44.708036],[-73.425764,40.871898],[-73.379208,43.027712],[-72.390808,40.961892],[-72.354919,41.083875],[-72.299519,40.994071],[-72.296062,41.002409],[-72.294278,41.000611],[-72.185677,40.963122]]}
-    ~~~
-
-4. Paste the JSON emitted in the previous step into [geojson.io](http://geojson.io) and you should see an image like the following, which shows the location of [most of the independent bookstores in New York State](https://www.bookweb.org/member_directory/search/ABAmember/results/0/0/ny/0):
-
-    <img src="{{ 'images/v20.2/geospatial/st_union.png' | relative_url }}" alt="ST_Union example" style="border:1px solid #eee;max-width:100%" />
-
-5. Finally, drop the temporary table if you no longer need it:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    DROP TABLE tmp;
-    ~~~
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Within`](st_within.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/st_within.md b/src/current/v20.2/st_within.md
deleted file mode 100644
index 2165524b5d7..00000000000
--- a/src/current/v20.2/st_within.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: ST_Within
-summary: ST_Within(A, B) returns true if no point in shape A lies outside of shape B, and at least one point in the interior of A lies in the interior of B.
-toc: true
-has_prefixed_variant: true
----
-
-Given two shapes _A_ and _B_, the predicate function `ST_Within(A, B)` returns `true` if the following criteria are met:
-
-- No point in _A_ lies outside of _B_.
-- At least one point in the interior of _A_ lies in the interior of _B_.
-
-In other words, the exterior of shape _B_ must not include any point in _A_, and one or more points of _A_'s interior must lie to the interior of _B_.
-
-This behavior is similar to [`ST_CoveredBy`](st_coveredby.html), except that the criteria are more exacting, and therefore some pairs of shapes will be rejected by this function that would be accepted by `ST_CoveredBy`.
-
-`ST_Within` works on the following spatial data types:
-
-- [`GEOMETRY`](spatial-glossary.html#geometry)
-
-{% if page.has_prefixed_variant %}
-{{site.data.alerts.callout_info}}
-`{{page.title}}` will attempt to use any available [spatial index](spatial-indexes.html) to speed up its operation.  Use the prefixed variant `_{{page.title}}` if you do not want any spatial indexes to be used.
-{{site.data.alerts.end}}
-{% endif %}
-
-{{site.data.alerts.callout_info}}
-This function is the inverse of [`ST_Contains`](st_contains.html).
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/misc/geojson_geometry_note.md %}
-
-### True
-
-In this example, `{{page.title}}` returns `true` because:
-
-- No point in Polygon _A_ lies outside of Polygon _B_.
-- At least one point in the interior of Polygon _A_ lies in the interior of Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_Within(st_geomfromtext('SRID=4326;POLYGON((-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))'), st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))'));
-~~~
-
-~~~
-   st_within
----------------
-     true
-
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_within_true.png' | relative_url }}" alt="ST_Within - true" style="border:1px solid #eee;max-width:100%" />
-
-### False
-
-In this example, `{{page.title}}` returns `false` because:
-
-- All points in Polygon _A_ lie outside of Polygon _B_.
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT ST_Within(st_geomfromtext('SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902), (-87.623177 41.881832, -90.199402 38.627003, -82.446732 38.413651, -87.623177 41.881832))'), st_geomfromtext('SRID=4326;POLYGON((-87.356934 41.595161, -84.512016 39.103119, -86.529167 39.162222, -87.356934 41.595161))'));
-~~~
-
-~~~
-   st_within
----------------
-     false
-(1 row)
-~~~
-
-<img src="{{ 'images/v20.2/geospatial/st_within_false.png' | relative_url }}" alt="ST_Within - false" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Working with Spatial Data](spatial-data.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial functions](functions-and-operators.html#spatial-functions)
-- [`ST_Covers`](st_covers.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Contains`](st_contains.html)
-- [`ST_Intersects`](st_intersects.html)
-- [`ST_CoveredBy`](st_coveredby.html)
-- [`ST_Covers`](st_covers.html)
-- [`ST_Disjoint`](st_disjoint.html)
-- [`ST_Equals`](st_equals.html)
-- [`ST_Overlaps`](st_overlaps.html)
-- [`ST_Touches`](st_touches.html)
-- [`ST_ConvexHull`](st_convexhull.html)
-- [`ST_Union`](st_union.html)
-- [Migrate from Shapefiles](migrate-from-shapefiles.html)
-- [Migrate from GeoJSON](migrate-from-geojson.html)
-- [Migrate from GeoPackage](migrate-from-geopackage.html)
-- [Migrate from OpenStreetMap](migrate-from-openstreetmap.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/start-a-local-cluster-in-docker-linux.md b/src/current/v20.2/start-a-local-cluster-in-docker-linux.md
deleted file mode 100644
index 0c376a9c869..00000000000
--- a/src/current/v20.2/start-a-local-cluster-in-docker-linux.md
+++ /dev/null
@@ -1,32 +0,0 @@
----
-title: Start a Cluster in Docker (Insecure)
-summary: Run an insecure multi-node CockroachDB cluster across multiple Docker containers on a single host.
-toc: true
----
-
-<div id="os-tabs" class="clearfix">
-  <a href="start-a-local-cluster-in-docker-mac.html"><button id="mac" data-eventcategory="buttonClick-doc-os" data-eventaction="mac">Mac</button></a>
-  <button id="linux" class="current" data-eventcategory="buttonClick-doc-os" data-eventaction="linux">Linux</button>
-  <a href="start-a-local-cluster-in-docker-windows.html"><button id="windows" data-eventcategory="buttonClick-doc-os" data-eventaction="windows">Windows</button></a>
-</div>
-
-Once you've [installed the official CockroachDB Docker image](install-cockroachdb.html), it's simple to run an insecure multi-node cluster across multiple Docker containers on a single host, using Docker volumes to persist node data.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-## Before you begin
-
-- Make sure you have already [installed the official CockroachDB Docker image](install-cockroachdb.html).
-- For quick SQL testing or app development, consider [running a single-node cluster](cockroach-start-single-node.html) instead.
-- Note that running multiple nodes on a single host is useful for testing CockroachDB, but it's not suitable for production. To run a physically distributed cluster in containers, use an orchestration tool like Kubernetes or Docker Swarm. See [Orchestration](orchestration.html) for more details, and review the [Production Checklist](recommended-production-settings.html).
-
-{% include {{ page.version.version }}/start-in-docker/mac-linux-steps.md %}
-
-## What's next?
-
-- Learn more about [CockroachDB SQL](learn-cockroachdb-sql.html) and the [built-in SQL client](cockroach-sql.html)
-- [Install the client driver](install-client-drivers.html) for your preferred language
-- [Build an app with CockroachDB](example-apps.html)
-- Further explore CockroachDB capabilities like [fault tolerance and automated repair](demo-fault-tolerance-and-recovery.html), [geo-partitioning](demo-low-latency-multi-region-deployment.html), [serializable transactions](demo-serializable.html), and [JSON support](demo-json-support.html)
diff --git a/src/current/v20.2/start-a-local-cluster-in-docker-mac.md b/src/current/v20.2/start-a-local-cluster-in-docker-mac.md
deleted file mode 100644
index 318fb250f67..00000000000
--- a/src/current/v20.2/start-a-local-cluster-in-docker-mac.md
+++ /dev/null
@@ -1,30 +0,0 @@
----
-title: Start a Cluster in Docker (Insecure)
-summary: Run an insecure multi-node CockroachDB cluster across multiple Docker containers on a single host.
-toc: true
----
-
-<div id="os-tabs" class="clearfix">
-  <button id="mac" class="current" data-eventcategory="buttonClick-doc-os" data-eventaction="mac">Mac</button>
-  <a href="start-a-local-cluster-in-docker-linux.html"><button id="linux" data-eventcategory="buttonClick-doc-os" data-eventaction="linux">Linux</button></a>
-  <a href="start-a-local-cluster-in-docker-windows.html"><button id="windows" data-eventcategory="buttonClick-doc-os" data-eventaction="windows">Windows</button></a>
-</div>
-
-Once you've [installed the official CockroachDB Docker image](install-cockroachdb.html), it's simple to run an insecure multi-node cluster across multiple Docker containers on a single host, using Docker volumes to persist node data.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-- Make sure you have already [installed the official CockroachDB Docker image](install-cockroachdb.html).
-- For quick SQL testing or app development, consider [running a single-node cluster](cockroach-start-single-node.html) instead.
-- Note that running multiple nodes on a single host is useful for testing CockroachDB, but it's not suitable for production. To run a physically distributed cluster in containers, use an orchestration tool like Kubernetes or Docker Swarm. See [Orchestration](orchestration.html) for more details, and review the [Production Checklist](recommended-production-settings.html).
-
-{% include {{ page.version.version }}/start-in-docker/mac-linux-steps.md %}
-
-## What's next?
-
-- Learn more about [CockroachDB SQL](learn-cockroachdb-sql.html) and the [built-in SQL client](cockroach-sql.html)
-- [Install the client driver](install-client-drivers.html) for your preferred language
-- [Build an app with CockroachDB](example-apps.html)
-- Further explore CockroachDB capabilities like [fault tolerance and automated repair](demo-fault-tolerance-and-recovery.html), [geo-partitioning](demo-low-latency-multi-region-deployment.html), [serializable transactions](demo-serializable.html), and [JSON support](demo-json-support.html)
diff --git a/src/current/v20.2/start-a-local-cluster-in-docker-windows.md b/src/current/v20.2/start-a-local-cluster-in-docker-windows.md
deleted file mode 100644
index f6a9b32ad80..00000000000
--- a/src/current/v20.2/start-a-local-cluster-in-docker-windows.md
+++ /dev/null
@@ -1,238 +0,0 @@
----
-title: Start a Cluster in Docker (Insecure)
-summary: Run an insecure multi-node CockroachDB cluster across multiple Docker containers on a single host.
-toc: true
----
-
-<div id="os-tabs" class="clearfix">
-  <a href="start-a-local-cluster-in-docker-mac.html"><button id="mac" data-eventcategory="buttonClick-doc-os" data-eventaction="mac">Mac</button></a>
-  <a href="start-a-local-cluster-in-docker-linux.html"><button id="linux" data-eventcategory="buttonClick-doc-os" data-eventaction="linux">Linux</button></a>
-  <button id="windows" class="current" data-eventcategory="buttonClick-doc-os" data-eventaction="windows">Windows</button>
-</div>
-
-Once you've [installed the official CockroachDB Docker image](install-cockroachdb.html), it's simple to run an insecure multi-node cluster across multiple Docker containers on a single host, using Docker volumes to persist node data.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-{% include {{ page.version.version }}/prod-deployment/insecure-flag.md %}
-
-## Before you begin
-
-- Make sure you have already [installed the official CockroachDB Docker image](install-cockroachdb.html).
-- For quick SQL testing or app development, consider [running a single-node cluster](cockroach-start-single-node.html) instead.
-- Note that running multiple nodes on a single host is useful for testing CockroachDB, but it's not suitable for production. To run a physically distributed cluster in containers, use an orchestration tool like Kubernetes or Docker Swarm. See [Orchestration](orchestration.html) for more details, and review the [Production Checklist](recommended-production-settings.html).
-
-## Step 1. Create a bridge network
-
-Since you'll be running multiple Docker containers on a single host, with one CockroachDB node per container, you need to create what Docker refers to as a [bridge network](https://docs.docker.com/engine/userguide/networking/#/a-bridge-network). The bridge network will enable the containers to communicate as a single cluster while keeping them isolated from external networks.
-
-~~~ powershell
-PS C:\Users\username> docker network create -d bridge roachnet
-~~~
-
-We've used `roachnet` as the network name here and in subsequent steps, but feel free to give your network any name you like.
-
-## Step 2. Start the cluster
-
-1. Start the first node:
-
-    {{site.data.alerts.callout_info}}Be sure to replace <code>&#60;username&#62;</code> in the <code>-v</code> flag with your actual username.{{site.data.alerts.end}}
-
-    ~~~ powershell
-    PS C:\Users\username> docker run -d `
-    --name=roach1 `
-    --hostname=roach1 `
-    --net=roachnet `
-    -p 26257:26257 -p 8080:8080  `
-    -v "//c/Users/<username>/cockroach-data/roach1:/cockroach/cockroach-data"  `
-    {{page.release_info.docker_image}}:{{page.release_info.version}} start `
-    --insecure `
-    --join=roach1,roach2,roach3
-    ~~~
-
-2. This command creates a container and starts the first CockroachDB node inside it. Take a moment to understand each part:
-    - `docker run`: The Docker command to start a new container.
-    - `-d`: This flag runs the container in the background so you can continue the next steps in the same shell.
-    - `--name`: The name for the container. This is optional, but a custom name makes it significantly easier to reference the container in other commands, for example, when opening a Bash session in the container or stopping the container.
-    - `--hostname`: The hostname for the container. You will use this to join other containers/nodes to the cluster.
-    - `--net`: The bridge network for the container to join. See step 1 for more details.
-    - `-p 26257:26257 -p 8080:8080`: These flags map the default port for inter-node and client-node communication (`26257`) and the default port for HTTP requests to the DB Console (`8080`) from the container to the host. This enables inter-container communication and makes it possible to call up the DB Console from a browser.
-    - `-v "//c/Users/<username>/cockroach-data/roach1:/cockroach/cockroach-data"`: This flag mounts a host directory as a data volume. This means that data and logs for this node will be stored in `Users/<username>/cockroach-data/roach1` on the host and will persist after the container is stopped or deleted. For more details, see Docker's <a href="https://docs.docker.com/engine/admin/volumes/bind-mounts/">Bind Mounts</a> topic.
-    - `{{page.release_info.docker_image}}:{{page.release_info.version}} start --insecure --join`: The CockroachDB command to [start a node](cockroach-start.html) in the container in insecure mode. The `--join` flag specifies the `hostname` of each node that will initially comprise your cluster. Otherwise, all [`cockroach start`](cockroach-start.html) defaults are accepted. Note that since each node is in a unique container, using identical default ports won’t cause conflicts.
-
-3. Start two more nodes:
-
-    {{site.data.alerts.callout_info}}Again, be sure to replace <code>&#60;username&#62;</code> in the <code>-v</code> flag with your actual username.{{site.data.alerts.end}}
-
-    ~~~ powershell
-    PS C:\Users\username> docker run -d `
-    --name=roach2 `
-    --hostname=roach2 `
-    --net=roachnet `
-    -v "//c/Users/<username>/cockroach-data/roach2:/cockroach/cockroach-data"  `
-    {{page.release_info.docker_image}}:{{page.release_info.version}} start `
-    --insecure `
-    --join=roach1,roach2,roach3
-    ~~~
-
-    ~~~ powershell
-    PS C:\Users\username> docker run -d `
-    --name=roach3 `
-    --hostname=roach3 `
-    --net=roachnet `
-    -v "//c/Users/<username>/cockroach-data/roach3:/cockroach/cockroach-data"  `
-    {{page.release_info.docker_image}}:{{page.release_info.version}} start `
-    --insecure `
-    --join=roach1,roach2,roach3
-    ~~~
-
-4. Perform a one-time initialization of the cluster:
-
-    ~~~ powershell
-    PS C:\Users\username> docker exec -it roach1 ./cockroach init --insecure
-    ~~~
-
-    You'll see the following message:
-
-    ~~~
-    Cluster successfully initialized
-    ~~~
-
-## Step 3. Use the built-in SQL client
-
-Now that your cluster is live, you can use any node as a SQL gateway. To test this out, let's use the `docker exec` command to start the [built-in SQL shell](cockroach-sql.html) in the first container.
-
-1. Start the SQL shell in the first container:
-
-    ~~~ powershell
-    PS C:\Users\username> docker exec -it roach1 ./cockroach sql --insecure
-    ~~~
-
-2. Run some basic [CockroachDB SQL statements](learn-cockroachdb-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE bank;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE bank.accounts (id INT PRIMARY KEY, balance DECIMAL);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO bank.accounts VALUES (1, 1000.50);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.accounts;
-    ~~~
-
-    ~~~
-      id | balance
-    +----+---------+
-       1 | 1000.50
-    (1 row)
-    ~~~
-
-3. Now exit the SQL shell on node 1 and open a new shell on node 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-    ~~~ powershell
-    PS C:\Users\username> docker exec -it roach2 ./cockroach sql --insecure
-    ~~~
-
-4. Run the same `SELECT` query as before:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.accounts;
-    ~~~
-
-    ~~~
-      id | balance
-    +----+---------+
-       1 | 1000.50
-    (1 row)
-    ~~~
-
-    As you can see, node 1 and node 2 behaved identically as SQL gateways.
-
-5. Exit the SQL shell on node 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-## Step 4. Run a sample workload
-
-CockroachDB also comes with a number of [built-in workloads](cockroach-workload.html) for simulating client traffic. Let's run the workload based on CockroachDB's sample vehicle-sharing application, [MovR](movr.html).
-
-1. Load the initial dataset:
-
-    ~~~ powershell
-    PS C:\Users\username> docker exec -it roach1 ./cockroach workload init movr \
-    'postgresql://root@roach1:26257?sslmode=disable'
-    ~~~
-
-2. Run the workload for 5 minutes:
-
-    ~~~ powershell
-    PS C:\Users\username> docker exec -it roach1 ./cockroach workload run movr \
-    --duration=5m \
-    'postgresql://root@roach1:26257?sslmode=disable'
-    ~~~
-
-## Step 5. Access the DB Console
-
-The CockroachDB [DB Console](ui-overview.html) gives you insight into the overall health of your cluster as well as the performance of the client workload.
-
-1. When you started the first container/node, you mapped the node's default HTTP port `8080` to port `8080` on the host, so go to <a href="http://localhost:8080" data-proofer-ignore>http://localhost:8080</a>.
-
-2. On the [**Cluster Overview**](ui-cluster-overview-page.html), notice that three nodes are live, with an identical replica count on each node:
-
-    <img src="{{ 'images/v20.2/ui_cluster_overview_3_nodes.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    This demonstrates CockroachDB's [automated replication](demo-replication-and-rebalancing.html) of data via the Raft consensus protocol.
-
-    {{site.data.alerts.callout_info}}
-    Capacity metrics can be incorrect when running multiple nodes on a single machine. For more details, see this [limitation](known-limitations.html#available-capacity-metric-in-the-db-console).
-    {{site.data.alerts.end}}
-
-3. Click [**Metrics**](ui-overview-dashboard.html) to access a variety of time series dashboards, including graphs of SQL queries and service latency over time:
-
-    <img src="{{ 'images/v20.2/ui_overview_dashboard_3_nodes.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-4. Use the [**Databases**](ui-databases-page.html), [**Statements**](ui-statements-page.html), and [**Jobs**](ui-jobs-page.html) pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively.
-
-## Step 6.  Stop the cluster
-
-Use the `docker stop` and `docker rm` commands to stop and remove the containers (and therefore the cluster):
-
-~~~ powershell
-PS C:\Users\username> docker stop roach1 roach2 roach3
-~~~
-
-~~~ powershell
-PS C:\Users\username> docker rm roach1 roach2 roach3
-~~~
-
-If you do not plan to restart the cluster, you may want to remove the nodes' data stores:
-
-~~~ powershell
-PS C:\Users\username> Remove-Item cockroach-data -recurse
-~~~
-
-## What's next?
-
-- Learn more about [CockroachDB SQL](learn-cockroachdb-sql.html) and the [built-in SQL client](cockroach-sql.html)
-- [Install the client driver](install-client-drivers.html) for your preferred language
-- [Build an app with CockroachDB](example-apps.html)
-- Further explore CockroachDB capabilities like [fault tolerance and automated repair](demo-fault-tolerance-and-recovery.html), [geo-partitioning](demo-low-latency-multi-region-deployment.html), [serializable transactions](demo-serializable.html), and [JSON support](demo-json-support.html)
diff --git a/src/current/v20.2/start-a-local-cluster.md b/src/current/v20.2/start-a-local-cluster.md
deleted file mode 100644
index 25ca1151c53..00000000000
--- a/src/current/v20.2/start-a-local-cluster.md
+++ /dev/null
@@ -1,372 +0,0 @@
----
-title: Start a Local Cluster (Insecure)
-summary: Run an insecure multi-node CockroachDB cluster locally with each node listening on a different port.
-toc: true
-toc_not_nested: true
----
-
-<div class="filters filters-big clearfix">
-    <a href="secure-a-cluster.html"><button class="filter-button">Secure</button></a>
-    <a href="start-a-local-cluster.html"><button class="filter-button current"><strong>Insecure</strong></button></a>
-</div>
-
-Once you've [installed CockroachDB](install-cockroachdb.html), it's simple to run an insecure multi-node cluster locally.
-
-{% include cockroachcloud/use-cockroachcloud-instead.md %}
-
-## Before you begin
-
-- Make sure you have already [installed CockroachDB](install-cockroachdb.html).
-- For quick SQL testing or app development, consider [running a single-node cluster](cockroach-start-single-node.html) instead.
-- Note that running multiple nodes on a single host is useful for testing CockroachDB, but it's not suitable for production. To run a physically distributed cluster, see [Manual Deployment](manual-deployment.html) or [Orchestrated Deployment](orchestration.html), and review the [Production Checklist](recommended-production-settings.html).
-
-## Step 1. Start the cluster
-
-1. Use the [`cockroach start`](cockroach-start.html) command to start the first node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=node1 \
-    --listen-addr=localhost:26257 \
-    --http-addr=localhost:8080 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    You'll see a message like the following:
-
-    ~~~
-    *
-    * WARNING: RUNNING IN INSECURE MODE!
-    *
-    * - Your cluster is open for any client that can access localhost.
-    * - Any user, even root, can log in without providing a password.
-    * - Any user, connecting as root, can read or write any data in your cluster.
-    * - There is no network encryption nor authentication, and thus no confidentiality.
-    *
-    * Check out how to secure your cluster: https://www.cockroachlabs.com/docs/v19.2/secure-a-cluster.html
-    *
-    *
-    * INFO: initial startup completed.
-    * Node will now attempt to join a running cluster, or wait for `cockroach init`.
-    * Client connections will be accepted after this completes successfully.
-    * Check the log file(s) for progress.
-    *
-    ~~~
-
-2. Take a moment to understand the [flags](cockroach-start.html#flags) you used:
-    - The `--insecure` flag makes communication unencrypted.
-    - Since this is a purely local cluster, `--listen-addr=localhost:26257` and `--http-addr=localhost:8080` tell the node to listen only on `localhost`, with port `26257` used for internal and client traffic and port `8080` used for HTTP requests from the DB Console.
-    - The `--store` flag indicates the location where the node's data and logs are stored.
-    - The `--join` flag specifies the addresses and ports of the nodes that will initially comprise your cluster. You'll use this exact `--join` flag when starting other nodes as well.
-
-        {% include {{ page.version.version }}/prod-deployment/join-flag-single-region.md %}
-    - The `--background` flag starts the `cockroach` process in the background so you can continue using the same terminal for other operations.
-
-3. Start two more nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=node2 \
-    --listen-addr=localhost:26258 \
-    --http-addr=localhost:8081 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=node3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    These commands are the same as before but with unique `--store`, `--listen-addr`, and `--http-addr` flags.
-
-4. Use the [`cockroach init`](cockroach-init.html) command to perform a one-time initialization of the cluster, sending the request to any node on the `--join` list:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach init --insecure --host=localhost:26257
-    ~~~
-
-    You'll see the following message:
-
-    ~~~
-    Cluster successfully initialized
-    ~~~
-
-    At this point, each node also prints helpful [startup details](cockroach-start.html#standard-output) to its log. For example, the following command retrieves node 1's startup details:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ grep 'node starting' node1/logs/cockroach.log -A 11
-    ~~~
-
-    The output will look something like this:
-
-    ~~~
-    CockroachDB node starting at {{ now | date: "%Y-%m-%d %H:%M:%S.%6 +0000 UTC" }}
-    build:               CCL {{page.release_info.version}} @ {{page.release_info.build_time}} (go1.12.6)
-    webui:               http://localhost:8080
-    sql:                 postgresql://root@localhost:26257?sslmode=disable
-    RPC client flags:    cockroach <client cmd> --host=localhost:26257 --insecure
-    logs:                /Users/<username>/node1/logs
-    temp dir:            /Users/<username>/node1/cockroach-temp242232154
-    external I/O path:   /Users/<username>/node1/extern
-    store[0]:            path=/Users/<username>/node1
-    status:              initialized new cluster
-    clusterID:           8a681a16-9623-4fc1-a537-77e9255daafd
-    nodeID:              1
-    ~~~
-
-## Step 2. Use the built-in SQL client
-
-Now that your cluster is live, you can use any node as a SQL gateway. To test this out, let's use CockroachDB's built-in SQL client.
-
-1. Run the [cockroach sql](cockroach-sql.html) command against node 1:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=localhost:26257
-    ~~~
-
-2. Run some basic [CockroachDB SQL statements](learn-cockroachdb-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE bank;
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE bank.accounts (id INT PRIMARY KEY, balance DECIMAL);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO bank.accounts VALUES (1, 1000.50);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.accounts;
-    ~~~
-
-    ~~~
-      id | balance
-    +----+---------+
-       1 | 1000.50
-    (1 row)
-    ~~~
-
-3. Now exit the SQL shell on node 1 and open a new shell on node 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure --host=localhost:26258
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    In a real deployment, all nodes would likely use the default port `26257`, and so you wouldn't need to set the port portion of `--host`.
-    {{site.data.alerts.end}}
-
-4. Run the same `SELECT` query as before:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM bank.accounts;
-    ~~~
-
-    ~~~
-      id | balance
-    +----+---------+
-       1 | 1000.50
-    (1 row)
-    ~~~
-
-    As you can see, node 1 and node 2 behaved identically as SQL gateways.
-
-5. Exit the SQL shell on node 2:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > \q
-    ~~~
-
-## Step 3. Run a sample workload
-
-CockroachDB also comes with a number of [built-in workloads](cockroach-workload.html) for simulating client traffic. Let's run the workload based on CockroachDB's sample vehicle-sharing application, [MovR](movr.html).
-
-1. Load the initial dataset:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload init movr \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-    ~~~
-    I190926 16:50:35.663708 1 workload/workloadsql/dataload.go:135  imported users (0s, 50 rows)
-    I190926 16:50:35.682583 1 workload/workloadsql/dataload.go:135  imported vehicles (0s, 15 rows)
-    I190926 16:50:35.769572 1 workload/workloadsql/dataload.go:135  imported rides (0s, 500 rows)
-    I190926 16:50:35.836619 1 workload/workloadsql/dataload.go:135  imported vehicle_location_histories (0s, 1000 rows)
-    I190926 16:50:35.915498 1 workload/workloadsql/dataload.go:135  imported promo_codes (0s, 1000 rows)
-    ~~~
-
-2. Run the workload for 5 minutes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach workload run movr \
-    --duration=5m \
-    'postgresql://root@localhost:26257?sslmode=disable'
-    ~~~
-
-## Step 4. Access the DB Console
-
-The CockroachDB [DB Console](ui-overview.html) gives you insight into the overall health of your cluster as well as the performance of the client workload.
-
-1. Go to <a href="http://localhost:8080" data-proofer-ignore>http://localhost:8080</a>.
-
-2. On the [**Cluster Overview**](ui-cluster-overview-page.html), notice that three nodes are live, with an identical replica count on each node:
-
-    <img src="{{ 'images/v20.2/ui_cluster_overview_3_nodes.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    This demonstrates CockroachDB's [automated replication](demo-replication-and-rebalancing.html) of data via the Raft consensus protocol.
-
-    {{site.data.alerts.callout_info}}
-    Capacity metrics can be incorrect when running multiple nodes on a single machine. For more details, see this [limitation](known-limitations.html#available-capacity-metric-in-the-db-console).
-    {{site.data.alerts.end}}
-
-3. Click [**Metrics**](ui-overview-dashboard.html) to access a variety of time series dashboards, including graphs of SQL queries and service latency over time:
-
-    <img src="{{ 'images/v20.2/ui_overview_dashboard_3_nodes.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-4. Use the [**Databases**](ui-databases-page.html), [**Statements**](ui-statements-page.html), and [**Jobs**](ui-jobs-page.html) pages to view details about your databases and tables, to assess the performance of specific queries, and to monitor the status of long-running operations like schema changes, respectively.
-
-## Step 5. Simulate node failure
-
-1. In a new terminal, run the [`cockroach quit`](cockroach-quit.html) command against a node to simulate a node failure:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26259
-    ~~~
-
-2. Back in the DB Console, despite one node being "suspect", notice the continued SQL traffic:
-
-    <img src="{{ 'images/v20.2/ui_overview_dashboard_1_suspect.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    This demonstrates CockroachDB's use of the Raft consensus protocol to [maintain availability and consistency in the face of failure](demo-fault-tolerance-and-recovery.html); as long as a majority of replicas remain online, the cluster and client traffic continue uninterrupted.
-
-4. Restart node 3:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=node3 \
-    --listen-addr=localhost:26259 \
-    --http-addr=localhost:8082 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-## Step 6. Scale the cluster
-
-Adding capacity is as simple as starting more nodes with `cockroach start`.
-
-1. Start 2 more nodes:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=node4 \
-    --listen-addr=localhost:26260 \
-    --http-addr=localhost:8083 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --insecure \
-    --store=node5 \
-    --listen-addr=localhost:26261 \
-    --http-addr=localhost:8084 \
-    --join=localhost:26257,localhost:26258,localhost:26259 \
-    --background
-    ~~~
-
-    Again, these commands are the same as before but with unique `--store`, `--listen-addr`, and `--http-addr` flags.
-
-2. Back on the **Cluster Overview** in the DB Console, you'll now see 5 nodes listed:
-
-    <img src="{{ 'images/v20.2/ui_cluster_overview_5_nodes.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-    At first, the replica count will be lower for nodes 4 and 5. Very soon, however, you'll see those numbers even out across all nodes, indicating that data is being [automatically rebalanced](demo-replication-and-rebalancing.html) to utilize the additional capacity of the new nodes.
-
-## Step 7. Stop the cluster
-
-1. When you're done with your test cluster, use the [`cockroach quit`](cockroach-quit.html) command to gracefully shut down each node.
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26257
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26258
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26259
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    For the last 2 nodes, the shutdown process will take longer (about a minute each) and will eventually force the nodes to stop. This is because, with only 2 of 5 nodes left, a majority of replicas are not available, and so the cluster is no longer operational.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26260
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure --host=localhost:26261
-    ~~~
-
-2. To restart the cluster at a later time, run the same `cockroach start` commands as earlier from the directory containing the nodes' data stores.  
-
-    If you do not plan to restart the cluster, you may want to remove the nodes' data stores:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm -rf node1 node2 node3 node4 node5
-    ~~~
-
-## What's next?
-
-- [Install the client driver](install-client-drivers.html) for your preferred language
-- Learn more about [CockroachDB SQL](learn-cockroachdb-sql.html) and the [built-in SQL client](cockroach-sql.html)
-- [Build an app with CockroachDB](example-apps.html)
-- Further explore CockroachDB capabilities like [fault tolerance and automated repair](demo-fault-tolerance-and-recovery.html), [geo-partitioning](demo-low-latency-multi-region-deployment.html), [serializable transactions](demo-serializable.html), and [JSON support](demo-json-support.html)
diff --git a/src/current/v20.2/stream-data-out-of-cockroachdb-using-changefeeds.md b/src/current/v20.2/stream-data-out-of-cockroachdb-using-changefeeds.md
deleted file mode 100644
index 420a2340fd7..00000000000
--- a/src/current/v20.2/stream-data-out-of-cockroachdb-using-changefeeds.md
+++ /dev/null
@@ -1,831 +0,0 @@
----
-title: Stream Data Out of CockroachDB Using Changefeeds
-summary: Stream data out of CockroachDB with efficient, distributed, row-level change subscriptions (changefeeds).
-toc: true
----
-
-Change data capture (CDC) provides efficient, distributed, row-level change feeds into a configurable sink for downstream processing such as reporting, caching, or full-text indexing.
-
-## What is change data capture?
-
-While CockroachDB is an excellent system of record, it also needs to coexist with other systems. For example, you might want to keep your data mirrored in full-text indexes, analytics engines, or big data pipelines.
-
-The main feature of CDC is the changefeed, which targets an allowlist of tables, called the "watched rows". There are two implementations of changefeeds:
-
-| [Core changefeeds](#create-a-core-changefeed)   | [Enterprise changefeeds](#configure-a-changefeed-enterprise) |
---------------------------------------------------|-----------------------------------------------------------------|
-| Useful for prototyping or quick testing. | Recommended for production use. |
-| Available in all products. | Available in CockroachDB {{ site.data.products.serverless }} and CockroachDB {{ site.data.products.dedicated }} or with an [Enterprise license](enterprise-licensing.html) in CockroachDB. |
-| Streams indefinitely until underlying SQL connection is closed. | Maintains connection to configured sink. |
-| Create with [`EXPERIMENTAL CHANGEFEED FOR`](changefeed-for.html). | Create with [`CREATE CHANGEFEED`](create-changefeed.html). |
-| Watches one or multiple tables in a comma-separated list. Emits every change to a "watched" row as a record. | Watches one or multiple tables in a comma-separated list. Emits every change to a "watched" row as a record in a <br> configurable format (`JSON` or Avro) to a configurable sink  ([Kafka](https://kafka.apache.org/)). |
-| [`CREATE`](#create-a-changefeed-core) changefeed and cancel by closing the connection. | Manage changefeed with [`CREATE`](#create), [`PAUSE`](#pause), [`RESUME`](#resume), and [`CANCEL`](#cancel), as well as [monitor](#monitor-a-changefeed) and [debug](#debug-a-changefeed). |
-
-
-## Enable rangefeeds
-
-Changefeeds connect to a long-lived request (i.e., a rangefeed), which pushes changes as they happen. This reduces the latency of row changes, as well as reduces transaction restarts on tables being watched by a changefeed for some workloads.
-
-**Rangefeeds must be enabled for a changefeed to work.** To [enable the cluster setting](set-cluster-setting.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET CLUSTER SETTING kv.rangefeed.enabled = true;
-~~~
-
-Any created changefeed will error until this setting is enabled. Note that enabling rangefeeds currently has a small performance cost (about a 5-10% increase in latencies), whether or not the rangefeed is being used in a changefeed.
-
-The `kv.closed_timestamp.target_duration` [cluster setting](cluster-settings.html) can be used with changefeeds. Resolved timestamps will always be behind by at least this setting's duration; however, decreasing the duration leads to more transaction restarts in your cluster, which can affect performance.
-
-## Ordering guarantees
-
-- In most cases, each version of a row will be emitted once. However, some infrequent conditions (e.g., node failures, network partitions) will cause them to be repeated. This gives our changefeeds an **at-least-once delivery guarantee**.
-
-- Once a row has been emitted with some timestamp, no previously unseen versions of that row will be emitted with a lower timestamp. That is, you will never see a _new_ change for that row at an earlier timestamp.
-
-    For example, if you ran the following:
-
-    ~~~ sql
-    > CREATE TABLE foo (id INT PRIMARY KEY DEFAULT unique_rowid(), name STRING);
-    > CREATE CHANGEFEED FOR TABLE foo INTO 'kafka://localhost:9092' WITH UPDATED;
-    > INSERT INTO foo VALUES (1, 'Carl');
-    > UPDATE foo SET name = 'Petee' WHERE id = 1;
-    ~~~
-
-    You'd expect the changefeed to emit:
-
-    ~~~ shell
-    [1]	{"__crdb__": {"updated": <timestamp 1>}, "id": 1, "name": "Carl"}
-    [1]	{"__crdb__": {"updated": <timestamp 2>}, "id": 1, "name": "Petee"}
-    ~~~
-
-    It is also possible that the changefeed emits an out of order duplicate of an earlier value that you already saw:
-
-    ~~~ shell
-    [1]	{"__crdb__": {"updated": <timestamp 1>}, "id": 1, "name": "Carl"}
-    [1]	{"__crdb__": {"updated": <timestamp 2>}, "id": 1, "name": "Petee"}
-    [1]	{"__crdb__": {"updated": <timestamp 1>}, "id": 1, "name": "Carl"}
-    ~~~
-
-    However, you will **never** see an output like the following (i.e., an out of order row that you've never seen before):
-
-    ~~~ shell
-    [1]	{"__crdb__": {"updated": <timestamp 2>}, "id": 1, "name": "Petee"}
-    [1]	{"__crdb__": {"updated": <timestamp 1>}, "id": 1, "name": "Carl"}
-    ~~~
-
-- If a row is modified more than once in the same transaction, only the last change will be emitted.
-
-- Rows are sharded between Kafka partitions by the row’s [primary key](primary-key.html).
-
-- <a name="resolved-def"></a>The `UPDATED` option adds an "updated" timestamp to each emitted row. You can also use the [`RESOLVED` option](create-changefeed.html#resolved-option) to emit "resolved" timestamp messages to each Kafka partition. A "resolved" timestamp is a guarantee that no (previously unseen) rows with a lower update timestamp will be emitted on that partition.
-
-    For example:
-
-    ~~~ shell
-    {"__crdb__": {"updated": "1532377312562986715.0000000000"}, "id": 1, "name": "Petee H"}
-    {"__crdb__": {"updated": "1532377306108205142.0000000000"}, "id": 2, "name": "Carl"}
-    {"__crdb__": {"updated": "1532377358501715562.0000000000"}, "id": 3, "name": "Ernie"}
-    {"__crdb__":{"resolved":"1532379887442299001.0000000000"}}
-    {"__crdb__":{"resolved":"1532379888444290910.0000000000"}}
-    {"__crdb__":{"resolved":"1532379889448662988.0000000000"}}
-    ...
-    {"__crdb__":{"resolved":"1532379922512859361.0000000000"}}
-    {"__crdb__": {"updated": "1532379923319195777.0000000000"}, "id": 4, "name": "Lucky"}
-    ~~~
-
-- With duplicates removed, an individual row is emitted in the same order as the transactions that updated it. However, this is not true for updates to two different rows, even two rows in the same table.
-
-    To compare two different rows for [happens-before](https://en.wikipedia.org/wiki/Happened-before), compare the "updated" timestamp. This works across anything in the same cluster (e.g., tables, nodes, etc.).
-
-    Resolved timestamp notifications on every Kafka partition can be used to provide strong ordering and global consistency guarantees by buffering records in between timestamp closures. Use the "resolved" timestamp to see every row that changed at a certain time.
-
-    The complexity with timestamps is necessary because CockroachDB supports transactions that can affect any part of the cluster, and it is not possible to horizontally divide the transaction log into independent changefeeds. For more information about this, [read our blog post on CDC](https://www.cockroachlabs.com/blog/change-data-capture/).
-
-## Delete messages
-
-Deleting a row will result in a changefeed outputting the primary key of the deleted row and a null value. For example, with default options, deleting the row with primary key `5` will output:
-
-~~~ shell
-[5] {"after": null}
-~~~
-
-In some unusual situations you may receive a delete message for a row without first seeing an insert message. For example, if an attempt is made to delete a row that does not exist, you may or may not get a delete message because the changefeed behavior is undefined to allow for optimizations at the storage layer. Similarly, if there are multiple writes to a row within a single transaction, only the last one will propagate to a changefeed. This means that creating and deleting a row within the same transaction will never result in an insert message, but may result in a delete message.
-
-## Avro schema changes
-
-To ensure that the Avro schemas that CockroachDB publishes will work with the schema compatibility rules used by the Confluent schema registry, CockroachDB emits all fields in Avro as nullable unions. This ensures that Avro and Confluent consider the schemas to be both backward- and forward-compatible, since the Confluent Schema Registry has a different set of rules than Avro for schemas to be backward- and forward-compatible.
-
-Note that the original CockroachDB column definition is also included in the schema as a doc field, so it's still possible to distinguish between a `NOT NULL` CockroachDB column and a `NULL` CockroachDB column.
-
-## Schema changes with column backfill
-
-When schema changes with column backfill (e.g., adding a column with a default, adding a computed column, adding a `NOT NULL` column, dropping a column) are made to watched rows, the changefeed will emit some duplicates during the backfill. When it finishes, CockroachDB outputs all watched rows using the new schema. When using Avro, rows that have been backfilled by a schema change are always re-emitted.
-
-For an example of a schema change with column backfill, start with the changefeed created in the [example below](#create-a-changefeed-connected-to-kafka):
-
-~~~ shell
-[1]	{"id": 1, "name": "Petee H"}
-[2]	{"id": 2, "name": "Carl"}
-[3]	{"id": 3, "name": "Ernie"}
-~~~
-
-Add a column to the watched table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE office_dogs ADD COLUMN likes_treats BOOL DEFAULT TRUE;
-~~~
-
-The changefeed emits duplicate records 1, 2, and 3 before outputting the records using the new schema:
-
-~~~ shell
-[1]	{"id": 1, "name": "Petee H"}
-[2]	{"id": 2, "name": "Carl"}
-[3]	{"id": 3, "name": "Ernie"}
-[1]	{"id": 1, "name": "Petee H"}  # Duplicate
-[2]	{"id": 2, "name": "Carl"}     # Duplicate
-[3]	{"id": 3, "name": "Ernie"}    # Duplicate
-[1]	{"id": 1, "likes_treats": true, "name": "Petee H"}
-[2]	{"id": 2, "likes_treats": true, "name": "Carl"}
-[3]	{"id": 3, "likes_treats": true, "name": "Ernie"}
-~~~
-
-When using the [`schema_change_policy = nobackfill` option](create-changefeed.html#schema-policy), the changefeed will still emit duplicate records for the table that is being altered. In the preceding output, the records marked as `# Duplicate` will still emit with this option, but not the new schema records.
-
-## Create a changefeed (Core)
-
-A core changefeed streams row-level changes to the client indefinitely until the underlying connection is closed or the changefeed is canceled.
-
-To create a core changefeed:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPERIMENTAL CHANGEFEED FOR name;
-~~~
-
-For more information, see [`CHANGEFEED FOR`](changefeed-for.html).
-
-## Configure a changefeed (Enterprise)
-
-An Enterprise changefeed streams row-level changes in a configurable format to a configurable sink (i.e., Kafka or a cloud storage sink). You can [create](#create), [pause](#pause), [resume](#resume), [cancel](#cancel), [monitor](#monitor-a-changefeed), and [debug](#debug-a-changefeed) an Enterprise changefeed.
-
-### Create
-
-To create an Enterprise changefeed:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE CHANGEFEED FOR TABLE table_name, table_name2 INTO '{scheme}://{host}:{port}?{query_parameters}';
-~~~
-
-{% include {{ page.version.version }}/cdc/url-encoding.md %}
-
-For more information, see [`CREATE CHANGEFEED`](create-changefeed.html).
-
-### Pause
-
-To pause an Enterprise changefeed:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOB job_id;
-~~~
-
-For more information, see [`PAUSE JOB`](pause-job.html).
-
-### Resume
-
-To resume a paused Enterprise changefeed:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOB job_id;
-~~~
-
-For more information, see [`RESUME JOB`](resume-job.html).
-
-### Cancel
-
-To cancel an Enterprise changefeed:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL JOB job_id;
-~~~
-
-For more information, see [`CANCEL JOB`](cancel-job.html).
-
-### Configuring all changefeeds
-
-{% include {{ page.version.version }}/cdc/configure-all-changefeed.md %}
-
-## Monitor a changefeed
-
-{{site.data.alerts.callout_info}}
-Monitoring is only available for Enterprise changefeeds.
-{{site.data.alerts.end}}
-
-Changefeed progress is exposed as a high-water timestamp that advances as the changefeed progresses. This is a guarantee that all changes before or at the timestamp have been emitted. You can monitor a changefeed:
-
-- On the [Changefeed Dashboard](ui-cdc-dashboard.html) of the DB Console.
-- On the [Jobs page](ui-jobs-page.html) of the DB Console. Hover over the high-water timestamp to view the [system time](as-of-system-time.html).
-- Using `crdb_internal.jobs`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT * FROM crdb_internal.jobs WHERE job_id = <job_id>;
-    ~~~
-    ~~~
-            job_id       |  job_type  |                              description                               | ... |      high_water_timestamp      | error | coordinator_id
-    +--------------------+------------+------------------------------------------------------------------------+ ... +--------------------------------+-------+----------------+
-      383870400694353921 | CHANGEFEED | CREATE CHANGEFEED FOR TABLE office_dogs INTO 'kafka://localhost:9092' | ... | 1537279405671006870.0000000000 |       |              1
-    (1 row)
-    ~~~
-
-- Setting up an alert on the `changefeed.max_behind_nanos` metric to track when a changefeed's high-water mark timestamp is at risk of falling behind the cluster's [garbage collection window](configure-replication-zones.html#replication-zone-variables). For more information, see [Monitoring and Alerting](monitoring-and-alerting.html#changefeed-is-experiencing-high-latency).
-
-{{site.data.alerts.callout_info}}
-You can use the high-water timestamp to [start a new changefeed where another ended](create-changefeed.html#start-a-new-changefeed-where-another-ended).
-{{site.data.alerts.end}}
-
-## Debug a changefeed
-
-### Using logs
-
-For Enterprise changefeeds, [use log information](debug-and-error-logs.html) to debug connection issues (i.e., `kafka: client has run out of available brokers to talk to (Is your cluster reachable?)`). Debug by looking for lines in the logs with `[kafka-producer]` in them:
-
-~~~
-I190312 18:56:53.535646 585 vendor/github.com/Shopify/sarama/client.go:123  [kafka-producer] Initializing new client
-I190312 18:56:53.535714 585 vendor/github.com/Shopify/sarama/client.go:724  [kafka-producer] client/metadata fetching metadata for all topics from broker localhost:9092
-I190312 18:56:53.536730 569 vendor/github.com/Shopify/sarama/broker.go:148  [kafka-producer] Connected to broker at localhost:9092 (unregistered)
-I190312 18:56:53.537661 585 vendor/github.com/Shopify/sarama/client.go:500  [kafka-producer] client/brokers registered new broker #0 at 172.16.94.87:9092
-I190312 18:56:53.537686 585 vendor/github.com/Shopify/sarama/client.go:170  [kafka-producer] Successfully initialized new client
-~~~
-
-### Using `SHOW JOBS`
-
-For Enterprise changefeeds, you can check the status by using:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * FROM [SHOW JOBS] WHERE job_type='CHANGEFEED';
-~~~
-
-Or:
-
-{% include copy-clipboard.html %}
-~~~ sql
-SELECT * from crdb_internal.jobs WHERE job_type='CHANGEFEED';
-~~~
-
-For more information, see [`SHOW JOBS`](show-jobs.html).
-
-### Using the DB Console
-
- On the [**Custom Chart** debug page](ui-custom-chart-debug-page.html) of the DB Console:
-
-1. To add a chart, click **Add Chart**.
-2. Select `changefeed.error_retries` from the **Metric Name** dropdown menu.
-
-    A graph of changefeed restarts due to retryable errors will display.
-
-## Usage examples
-
-### Create a core changefeed
-
-{% include {{ page.version.version }}/cdc/create-core-changefeed.md %}
-
-### Create a core changefeed using Avro
-
-{% include {{ page.version.version }}/cdc/create-core-changefeed-avro.md %}
-
-### Create a changefeed connected to Kafka
-
-{{site.data.alerts.callout_info}}
-[`CREATE CHANGEFEED`](create-changefeed.html) is an [Enterprise-only](enterprise-licensing.html) feature. For the core version, see [the `CHANGEFEED FOR` example above](#create-a-core-changefeed).
-{{site.data.alerts.end}}
-
-In this example, you'll set up a changefeed for a single-node cluster that is connected to a Kafka sink. The changefeed will watch two tables.
-
-1. If you do not already have one, [request a trial Enterprise license](enterprise-licensing.html).
-
-2. Use the [`cockroach start-single-node`](cockroach-start-single-node.html) command to start a single-node cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start-single-node --insecure --listen-addr=localhost --background
-    ~~~
-
-3. Download and extract the [Confluent Open Source platform](https://www.confluent.io/download/) (which includes Kafka).
-
-4. Move into the extracted `confluent-<version>` directory and start Confluent:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/confluent local services start
-    ~~~
-
-    Only `zookeeper` and `kafka` are needed. To troubleshoot Confluent, see [their docs](https://docs.confluent.io/current/installation/installing_cp.html#zip-and-tar-archives) and the [Quick Start Guide](https://docs.confluent.io/platform/current/quickstart/ce-quickstart.html#ce-quickstart).
-
-5. Create two Kafka topics:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/kafka-topics \
-    --create \
-    --zookeeper localhost:2181 \
-    --replication-factor 1 \
-    --partitions 1 \
-    --topic office_dogs
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/kafka-topics \
-    --create \
-    --zookeeper localhost:2181 \
-    --replication-factor 1 \
-    --partitions 1 \
-    --topic employees
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    You are expected to create any Kafka topics with the necessary number of replications and partitions. [Topics can be created manually](https://kafka.apache.org/documentation/#basic_ops_add_topic) or [Kafka brokers can be configured to automatically create topics](https://kafka.apache.org/documentation/#topicconfigs) with a default partition count and replication factor.
-    {{site.data.alerts.end}}
-
-6. As the `root` user, open the [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-7. Set your organization name and [Enterprise license](enterprise-licensing.html) key that you received via email:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING cluster.organization = '<organization name>';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING enterprise.license = '<secret>';
-    ~~~
-
-8. Enable the `kv.rangefeed.enabled` [cluster setting](cluster-settings.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING kv.rangefeed.enabled = true;
-    ~~~
-
-9. Create a database called `cdc_demo`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE cdc_demo;
-    ~~~
-
-10. Set the database as the default:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET DATABASE = cdc_demo;
-    ~~~
-
-11. Create a table and add data:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE office_dogs (
-         id INT PRIMARY KEY,
-         name STRING);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO office_dogs VALUES
-       (1, 'Petee'),
-       (2, 'Carl');
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > UPDATE office_dogs SET name = 'Petee H' WHERE id = 1;
-    ~~~
-
-12. Create another table and add data:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE employees (
-         dog_id INT REFERENCES office_dogs (id),
-         employee_name STRING);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO employees VALUES
-       (1, 'Lauren'),
-       (2, 'Spencer');
-    ~~~
-
-13. Start the changefeed:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE CHANGEFEED FOR TABLE office_dogs, employees INTO 'kafka://localhost:9092';
-    ~~~
-    ~~~
-
-            job_id       
-    +--------------------+
-      360645287206223873
-    (1 row)
-    ~~~
-
-    This will start up the changefeed in the background and return the `job_id`. The changefeed writes to Kafka.
-
-14. In a new terminal, move into the extracted `confluent-<version>` directory and start watching the Kafka topics:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/kafka-console-consumer \
-    --bootstrap-server=localhost:9092 \
-    --from-beginning \
-    --whitelist 'office_dogs|employees'
-    ~~~
-
-    ~~~ shell
-    {"after": {"id": 1, "name": "Petee H"}}
-    {"after": {"id": 2, "name": "Carl"}}
-    {"after": {"id": 1, "name": "Lauren", "rowid": 528514320239329281}}
-    {"after": {"id": 2, "name": "Spencer", "rowid": 528514320239362049}}
-    ~~~
-
-    The initial scan displays the state of the tables as of when the changefeed started (therefore, the initial value of `"Petee"` is omitted).
-
-    {% include {{ page.version.version }}/cdc/print-key.md %}
-
-15. Back in the SQL client, insert more data:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO office_dogs VALUES (3, 'Ernie');
-    ~~~
-
-16. Back in the terminal where you're watching the Kafka topics, the following output has appeared:
-
-    ~~~ shell
-    {"after": {"id": 3, "name": "Ernie"}}
-    ~~~
-
-17. When you are done, exit the SQL shell (`\q`).
-
-18. To stop `cockroach`, run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure
-    ~~~
-
-19. To stop Kafka, move into the extracted `confluent-<version>` directory and stop Confluent:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/confluent local services stop
-    ~~~
-
-### Create a changefeed connected to Kafka using Avro
-
-{{site.data.alerts.callout_info}}
-[`CREATE CHANGEFEED`](create-changefeed.html) is an [Enterprise-only](enterprise-licensing.html) feature. For the core version, see [the `CHANGEFEED FOR` example above](#create-a-core-changefeed-using-avro).
-{{site.data.alerts.end}}
-
-In this example, you'll set up a changefeed for a single-node cluster that is connected to a Kafka sink and emits [Avro](https://avro.apache.org/docs/1.8.2/spec.html) records. The changefeed will watch two tables.
-
-1. If you do not already have one, [request a trial Enterprise license](enterprise-licensing.html).
-
-2. Use the [`cockroach start-single-node`](cockroach-start-single-node.html) command to start a single-node cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start-single-node --insecure --listen-addr=localhost --background
-    ~~~
-
-3. Download and extract the [Confluent Open Source platform](https://www.confluent.io/download/) (which includes Kafka).
-
-4. Move into the extracted `confluent-<version>` directory and start Confluent:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/confluent local services start
-    ~~~
-
-    Only `zookeeper`, `kafka`, and `schema-registry` are needed. To troubleshoot Confluent, see [their docs](https://docs.confluent.io/current/installation/installing_cp.html#zip-and-tar-archives) and the [Quick Start Guide](https://docs.confluent.io/platform/current/quickstart/ce-quickstart.html#ce-quickstart).
-
-5. Create two Kafka topics:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/kafka-topics \
-    --create \
-    --zookeeper localhost:2181 \
-    --replication-factor 1 \
-    --partitions 1 \
-    --topic office_dogs
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/kafka-topics \
-    --create \
-    --zookeeper localhost:2181 \
-    --replication-factor 1 \
-    --partitions 1 \
-    --topic employees
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    You are expected to create any Kafka topics with the necessary number of replications and partitions. [Topics can be created manually](https://kafka.apache.org/documentation/#basic_ops_add_topic) or [Kafka brokers can be configured to automatically create topics](https://kafka.apache.org/documentation/#topicconfigs) with a default partition count and replication factor.
-    {{site.data.alerts.end}}
-
-6. As the `root` user, open the [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-7. Set your organization name and [Enterprise license](enterprise-licensing.html) key that you received via email:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING cluster.organization = '<organization name>';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING enterprise.license = '<secret>';
-    ~~~
-
-8. Enable the `kv.rangefeed.enabled` [cluster setting](cluster-settings.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING kv.rangefeed.enabled = true;
-    ~~~
-
-9. Create a database called `cdc_demo`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE cdc_demo;
-    ~~~
-
-10. Set the database as the default:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET DATABASE = cdc_demo;
-    ~~~
-
-11. Create a table and add data:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE office_dogs (
-         id INT PRIMARY KEY,
-         name STRING);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO office_dogs VALUES
-       (1, 'Petee'),
-       (2, 'Carl');
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > UPDATE office_dogs SET name = 'Petee H' WHERE id = 1;
-    ~~~
-
-12. Create another table and add data:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE employees (
-         dog_id INT REFERENCES office_dogs_avro (id),
-         employee_name STRING);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO employees VALUES
-       (1, 'Lauren'),
-       (2, 'Spencer');
-    ~~~
-
-13. Start the changefeed:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE CHANGEFEED FOR TABLE office_dogs, employees INTO 'kafka://localhost:9092' WITH format = experimental_avro, confluent_schema_registry = 'http://localhost:8081';
-    ~~~
-
-    ~~~
-            job_id       
-    +--------------------+
-      360645287206223873
-    (1 row)
-    ~~~
-
-    This will start up the changefeed in the background and return the `job_id`. The changefeed writes to Kafka.
-
-14. In a new terminal, move into the extracted `confluent-<version>` directory and start watching the Kafka topics:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/kafka-avro-console-consumer \
-    --bootstrap-server=localhost:9092 \
-    --from-beginning \
-    --whitelist 'office_dogs|employees'
-    ~~~
-
-    ~~~ shell
-    {"after":{"office_dogs":{"id":{"long":1},"name":{"string":"Petee H"}}}}
-    {"after":{"office_dogs":{"id":{"long":2},"name":{"string":"Carl"}}}}
-    {"after":{"employees":{"dog_id":{"long":1},"employee_name":{"string":"Lauren"},"rowid":{"long":528537452042682369}}}}
-    {"after":{"employees":{"dog_id":{"long":2},"employee_name":{"string":"Spencer"},"rowid":{"long":528537452042747905}}}}
-    ~~~
-
-    The initial scan displays the state of the table as of when the changefeed started (therefore, the initial value of `"Petee"` is omitted).
-
-    {% include {{ page.version.version }}/cdc/print-key.md %}
-
-15. Back in the SQL client, insert more data:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO office_dogs VALUES (3, 'Ernie');
-    ~~~
-
-16. Back in the terminal where you're watching the Kafka topics, the following output has appeared:
-
-    ~~~ shell
-    {"after":{"office_dogs":{"id":{"long":3},"name":{"string":"Ernie"}}}}
-    ~~~
-
-17. When you are done, exit the SQL shell (`\q`).
-
-18. To stop `cockroach`, run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure
-    ~~~
-
-19. To stop Kafka, move into the extracted `confluent-<version>` directory and stop Confluent:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ./bin/confluent local services stop
-    ~~~
-
-### Create a changefeed connected to a cloud storage sink
-
-{{site.data.alerts.callout_info}}
-[`CREATE CHANGEFEED`](create-changefeed.html) is an [Enterprise-only](enterprise-licensing.html) feature. For the core version, see [the `CHANGEFEED FOR` example above](#create-a-core-changefeed).
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/misc/experimental-warning.md %}
-
-In this example, you'll set up a changefeed for a single-node cluster that is connected to an AWS S3 sink. The changefeed watches two tables. Note that you can set up changefeeds for any of [these cloud storage providers](create-changefeed.html#cloud-storage-sink).
-
-1. If you do not already have one, [request a trial Enterprise license](enterprise-licensing.html).
-
-2. Use the [`cockroach start-single-node`](cockroach-start-single-node.html) command to start a single-node cluster:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start-single-node --insecure --listen-addr=localhost --background
-    ~~~
-
-3. As the `root` user, open the [built-in SQL client](cockroach-sql.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach sql --insecure
-    ~~~
-
-4. Set your organization name and [Enterprise license](enterprise-licensing.html) key that you received via email:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING cluster.organization = '<organization name>';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING enterprise.license = '<secret>';
-    ~~~
-
-5. Enable the `kv.rangefeed.enabled` [cluster setting](cluster-settings.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING kv.rangefeed.enabled = true;
-    ~~~
-
-6. Create a database called `cdc_demo`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE DATABASE cdc_demo;
-    ~~~
-
-7. Set the database as the default:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET DATABASE = cdc_demo;
-    ~~~
-
-8. Create a table and add data:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE office_dogs (
-         id INT PRIMARY KEY,
-         name STRING);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO office_dogs VALUES
-       (1, 'Petee'),
-       (2, 'Carl');
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > UPDATE office_dogs SET name = 'Petee H' WHERE id = 1;
-    ~~~
-
-9. Create another table and add data:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE TABLE employees (
-         dog_id INT REFERENCES office_dogs (id),
-         employee_name STRING);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > INSERT INTO employees VALUES
-       (1, 'Lauren'),
-       (2, 'Spencer');
-    ~~~
-
-10. Start the changefeed:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE CHANGEFEED FOR TABLE office_dogs, employees INTO 'experimental-s3://example-bucket-name/test?AWS_ACCESS_KEY_ID=enter_key-here&AWS_SECRET_ACCESS_KEY=enter_key_here' with updated, resolved='10s';
-    ~~~
-
-    ~~~
-            job_id       
-    +--------------------+
-      360645287206223873
-    (1 row)
-    ~~~
-
-    This will start up the changefeed in the background and return the `job_id`. The changefeed writes to AWS.
-
-11. Monitor your changefeed on the <a href="http://localhost:8080/#/metrics/changefeeds/cluster" data-proofer-ignore>DB Console</a>. For more information, see [Changefeeds Dashboard](ui-cdc-dashboard.html).
-
-12. When you are done, exit the SQL shell (`\q`).
-
-13. To stop `cockroach`, run:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach quit --insecure
-    ~~~
-
-## Known limitations
-
-{% include {{ page.version.version }}/known-limitations/cdc.md %}
-
-## See also
-
-- [`CREATE CHANGEFEED`](create-changefeed.html)
-- [`CHANGEFEED FOR`](changefeed-for.html)
-- [`PAUSE JOB`](pause-job.html)
-- [`CANCEL JOB`](cancel-job.html)
-- [Other SQL Statements](sql-statements.html)
-- [Changefeed Dashboard](ui-cdc-dashboard.html)
diff --git a/src/current/v20.2/string.md b/src/current/v20.2/string.md
deleted file mode 100644
index e7a9e17c13c..00000000000
--- a/src/current/v20.2/string.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-title: STRING
-summary: The STRING data type stores a string of Unicode characters.
-toc: true
----
-
-The `STRING` [data type](data-types.html) stores a string of Unicode characters.
-
-{{site.data.alerts.callout_info}}
-`STRING` is not a data type supported by PostgreSQL. For PostgreSQL compatibility, CockroachDB supports additional [aliases](#aliases) and [`STRING`-related types](#related-types).
-{{site.data.alerts.end}}
-
-## Aliases
-
-CockroachDB supports the following alias for `STRING`:
-
-- `TEXT`
-
-## Related types
-
-For PostgreSQL compatibility, CockroachDB supports the following `STRING`-related types and their aliases:
-
-- `VARCHAR` (and alias `CHARACTER VARYING`)
-- `CHAR` (and alias `CHARACTER`)
-
-These types are functionality identical to `STRING`.
-
-## Length
-
-To limit the length of a string column, use `STRING(n)`, where `n` is the maximum number of Unicode code points (normally thought of as "characters") allowed. This applies to all related types as well (e.g., to limit the length of a `VARCHAR` type, use `VARCHAR(n)`).
-
-When inserting a `STRING` value or a `STRING`-related-type value:
-
-- If the value is cast with a length limit (e.g., `CAST('hello world' AS STRING(5))`), CockroachDB truncates to the limit. This applies to `STRING(n)` and all related types.
-- If the value exceeds the column's length limit, CockroachDB returns an error. This applies to `STRING(n)` and all related types.
-- For `STRING(n)` and `VARCHAR(n)`/`CHARACTER VARYING(n)` types, if the value is under the column's length limit, CockroachDB does **not** add space padding to the end of the value.
-- <span class="version-tag">New in v20.2:</span> For `CHAR(n)`/`CHARACTER(n)` types, if the value is under the column's length limit, CockroachDB adds space padding from the end of the value to the length limit.
-
-                        Type                      |          Length                  
---------------------------------------------------|------------------------------
-`CHARACTER`, `CHARACTER(n)`, `CHAR`, `CHAR(n)`    | Fixed-length                
-`CHARACTER VARYING(n)`, `VARCHAR(n)`, `STRING(n)` | Variable-length, with a limit  
-`TEXT`, `VARCHAR`, `CHARACTER VARYING`, `STRING`  | Variable-length, with no limit
-
-## Syntax
-
-A value of type `STRING` can be expressed using a variety of formats.
-See [string literals](sql-constants.html#string-literals) for more details.
-
-When printing out a `STRING` value in the [SQL shell](cockroach-sql.html), the shell uses the simple
-SQL string literal format if the value doesn't contain special character,
-or the escaped format otherwise.
-
-### Collations
-
-`STRING` values accept [collations](collate.html), which lets you sort strings according to language- and country-specific rules.
-
-## Size
-
-The size of a `STRING` value is variable, but it's recommended to keep values under 64 kilobytes to ensure performance. Above that threshold, [write amplification](https://en.wikipedia.org/wiki/Write_amplification) and other considerations may cause significant performance degradation.   
-
-## Examples
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE strings (a STRING PRIMARY KEY, b STRING(4), c TEXT);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM strings;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |   indices   | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-------------+-----------+
-  a           | STRING    |    false    | NULL           |                       | {"primary"} |   false
-  b           | STRING(4) |    true     | NULL           |                       | {}          |   false
-  c           | STRING    |    true     | NULL           |                       | {}          |   false
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO strings VALUES ('a1b2c3d4', 'e5f6', 'g7h8i9');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM strings;
-~~~
-
-~~~
-     a     |  b   |   c
-+----------+------+--------+
-  a1b2c3d4 | e5f6 | g7h8i9
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE aliases (a STRING PRIMARY KEY, b VARCHAR, c CHAR);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM aliases;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |   indices   | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-------------+-----------+
-  a           | STRING    |    false    | NULL           |                       | {"primary"} |   false
-  b           | VARCHAR   |    true     | NULL           |                       | {}          |   false
-  c           | CHAR      |    true     | NULL           |                       | {}          |   false
-(3 rows)
-~~~
-
-## Supported casting and conversion
-
-`STRING` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`ARRAY` | Requires supported [`ARRAY`](array.html) string format, e.g., `'{1,2,3}'`.<br>Note that string literals can be implicitly cast to any supported `ARRAY` data type except [`BYTES`](bytes.html), [`ENUM`](enum.html), [`JSONB`](jsonb.html), [`SERIAL`](serial.html), and the [spatial data types](spatial-glossary.html#data-types) `Box2D`, `GEOGRAPHY`, and `GEOMETRY`.
-`BIT` | Requires supported [`BIT`](bit.html) string format, e.g., `'101001'`.
-`BOOL` | Requires supported [`BOOL`](bool.html) string format, e.g., `'true'`.
-`BYTES` | For more details, [see here](bytes.html#supported-conversions).
-`DATE` | Requires supported [`DATE`](date.html) string format, e.g., `'2016-01-25'`.
-`DECIMAL` | Requires supported [`DECIMAL`](decimal.html) string format, e.g., `'1.1'`.
-`FLOAT` | Requires supported [`FLOAT`](float.html) string format, e.g., `'1.1'`.
-`INET` | Requires supported [`INET`](inet.html) string format, e.g, `'192.168.0.1'`.
-`INT` | Requires supported [`INT`](int.html) string format, e.g., `'10'`.
-`INTERVAL` | Requires supported [`INTERVAL`](interval.html) string format, e.g., `'1h2m3s4ms5us6ns'`.
-`TIME` | Requires supported [`TIME`](time.html) string format, e.g., `'01:22:12'` (microsecond precision).
-`TIMESTAMP` | Requires supported [`TIMESTAMP`](timestamp.html) string format, e.g., `'2016-01-25 10:10:10.555555'`.
-`UUID` | Requires supported [`UUID`](uuid.html) string format, e.g., `'63616665-6630-3064-6465-616462656562'`.
-
-### `STRING` vs. `BYTES`
-
-While both `STRING` and `BYTES` can appear to have similar behavior in many situations, one should understand their nuance before casting one into the other.
-
-`STRING` treats all of its data as characters, or more specifically, Unicode code points. `BYTES` treats all of its data as a byte string. This difference in implementation can lead to dramatically different behavior. For example, let's take a complex Unicode character such as ☃ ([the snowman emoji](https://emojipedia.org/snowman/)):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT length('☃'::string);
-~~~
-
-~~~
-  length
-+--------+
-       1
-~~~
-
-~~~ sql
-> SELECT length('☃'::bytes);
-~~~
-~~~
-  length
-+--------+
-       3
-~~~
-
-In this case, [`LENGTH(string)`](functions-and-operators.html#string-and-byte-functions) measures the number of Unicode code points present in the string, whereas [`LENGTH(bytes)`](functions-and-operators.html#string-and-byte-functions) measures the number of bytes required to store that value. Each character (or Unicode code point) can be encoded using multiple bytes, hence the difference in output between the two.
-
-#### Translate literals to `STRING` vs. `BYTES`
-
-A literal entered through a SQL client will be translated into a different value based on the type:
-
-+ `BYTES` give a special meaning to the pair `\x` at the beginning, and translates the rest by substituting pairs of hexadecimal digits to a single byte. For example, `\xff` is equivalent to a single byte with the value of 255. For more information, see [SQL Constants: String literals with character escapes](sql-constants.html#string-literals-with-character-escapes).
-+ `STRING` does not give a special meaning to `\x`, so all characters are treated as distinct Unicode code points. For example, `\xff` is treated as a `STRING` with length 4 (`\`, `x`, `f`, and `f`).
-
-## See also
-
-- [Data Types](data-types.html)
-- [String literal syntax](sql-constants.html#string-literals)
diff --git a/src/current/v20.2/subqueries.md b/src/current/v20.2/subqueries.md
deleted file mode 100644
index edaf2f97a66..00000000000
--- a/src/current/v20.2/subqueries.md
+++ /dev/null
@@ -1,156 +0,0 @@
----
-title: Subqueries
-summary: Subqueries enable the use of the results from a query within another query.
-toc: true
----
-
-SQL subqueries enable reuse of the results from a [selection query](selection-queries.html) within another query.
-
-
-## Overview
-
-CockroachDB supports two kinds of subqueries:
-
-- **Relational** subqueries which appear as operand in [selection queries](selection-queries.html) or [table expressions](table-expressions.html).
-- **Scalar** subqueries which appear as operand in a [scalar expression](scalar-expressions.html).
-
-## Data writes in subqueries
-
-When a subquery contains a data-modifying statement (`INSERT`,
-`DELETE`, etc.), the data modification is always executed to
-completion even if the surrounding query only uses a subset of the
-result rows.
-
-This is true both for subqueries defined using the `(...)` or `[...]`
-notations, and those defined using
-[`WITH`](common-table-expressions.html).
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT *
-   FROM [INSERT INTO t(x) VALUES (1), (2), (3) RETURNING x]
-  LIMIT 1;
-~~~
-
-This query always inserts 3 rows into `t`, even though the surrounding
-query only observes 1 row using [`LIMIT`](limit-offset.html).
-
-## Correlated subqueries
-
-CockroachDB's [cost-based optimizer](cost-based-optimizer.html) supports most [correlated subqueries](https://en.wikipedia.org/wiki/Correlated_subquery).
-
-A subquery is said to be "correlated" when it uses table or column names defined in the surrounding query.
-
-For example, to find every customer with at least one order, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT
-      c.name
-  FROM
-      customers AS c
-  WHERE
-      EXISTS(
-          SELECT * FROM orders AS o WHERE o.customer_id = c.id
-      );
-~~~
-
-The subquery is correlated because it uses `c` defined in the surrounding query.
-
-### `LATERAL` subqueries
-
- CockroachDB supports `LATERAL` subqueries. A `LATERAL` subquery is a correlated subquery that references another query or subquery in its `SELECT` statement, usually in the context of a [`LEFT` join](joins.html#left-outer-joins) or an [`INNER` join](joins.html#inner-joins). Unlike other correlated subqueries, `LATERAL` subqueries iterate through each row in the referenced query for each row in the inner subquery, like a [for loop](https://en.wikipedia.org/wiki/For_loop).
-
-To create a `LATERAL` subquery, use the `LATERAL` keyword directly before the inner subquery's `SELECT` statement.
-
-For example, the following statement performs an `INNER` join of the `users` table and a subquery of the `rides` table that filters on values in the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT name, address FROM users, LATERAL (SELECT * FROM rides WHERE rides.start_address = users.address AND city = 'new york');
-~~~
-
-~~~
-        name       |           address
-+------------------+-----------------------------+
-  Robert Murphy    | 99176 Anderson Mills
-  James Hamilton   | 73488 Sydney Ports Suite 57
-  Judy White       | 18580 Rosario Ville Apt. 61
-  Devin Jordan     | 81127 Angela Ferry Apt. 8
-  Catherine Nelson | 1149 Lee Alley
-  Nicole Mcmahon   | 11540 Patton Extensions
-(6 rows)
-~~~
-
-`LATERAL` subquery joins are especially useful when the join table includes a [computed column](computed-columns.html).
-
-For example, the following query joins a subquery of the `rides` table with a computed column (`adjusted_revenue`), and a subquery of the `users` table that references columns in the `rides` subquery:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT
-   ride_id,
-   vehicle_id,
-   type,
-   adjusted_revenue
-FROM
-   (
-      SELECT
-         id AS ride_id,
-         vehicle_id,
-         revenue - 0.25*revenue AS adjusted_revenue
-      FROM
-         rides
-   )
-   r
-   JOIN
-      LATERAL (
-      SELECT
-         type
-      FROM
-         vehicles
-      WHERE
-         city = 'new york'
-         AND vehicles.id = r.vehicle_id
-         AND r.adjusted_revenue > 65 ) v
-         ON true;
-~~~
-
-~~~
-                ride_id                |              vehicle_id              |    type    | adjusted_revenue
-+--------------------------------------+--------------------------------------+------------+------------------+
-  049ba5e3-53f7-4ec0-8000-000000000009 | 11111111-1111-4100-8000-000000000001 | scooter    |          71.2500
-  0624dd2f-1a9f-4e80-8000-00000000000c | 00000000-0000-4000-8000-000000000000 | skateboard |          70.5000
-  08b43958-1062-4e00-8000-000000000011 | 11111111-1111-4100-8000-000000000001 | scooter    |          70.5000
-  0bc6a7ef-9db2-4d00-8000-000000000017 | 00000000-0000-4000-8000-000000000000 | skateboard |          68.2500
-  0d4fdf3b-645a-4c80-8000-00000000001a | 00000000-0000-4000-8000-000000000000 | skateboard |          67.5000
-  1ba5e353-f7ce-4900-8000-000000000036 | 11111111-1111-4100-8000-000000000001 | scooter    |          70.5000
-(6 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-In a `LATERAL` subquery join, the rows returned by the inner subquery are added to the result of the join with the outer query. Without the `LATERAL` keyword, each subquery is evaluated independently and cannot refer to objects defined in separate queries.
-{{site.data.alerts.end}}
-
-### Limitations
-
-The [cost-based optimizer](cost-based-optimizer.html) supports most correlated subqueries, with the exception of correlated subqueries that generate side effects inside a `CASE` statement.
-
-## Performance best practices
-
-{{site.data.alerts.callout_info}}
-CockroachDB is currently undergoing major changes to evolve and improve the performance of subqueries. The restrictions and workarounds listed in this section will be lifted or made unnecessary over time.
-{{site.data.alerts.end}}
-
-- Scalar subqueries currently disable the distribution of the execution of a query. To ensure maximum performance on queries that process a large number of rows, make the client application compute the subquery results ahead of time and pass these results directly in the surrounding query.
-
-- The results of scalar subqueries are currently loaded entirely into memory when the execution of the surrounding query starts. To prevent execution errors due to memory exhaustion, ensure that subqueries return as few results as possible.
-
-## See also
-
-- [Selection Queries](selection-queries.html)
-- [Scalar Expressions](scalar-expressions.html)
-- [Table Expressions](table-expressions.html)
-- [Performance Best Practices - Overview](performance-best-practices-overview.html)
diff --git a/src/current/v20.2/support-resources.md b/src/current/v20.2/support-resources.md
deleted file mode 100644
index c44f9406bbc..00000000000
--- a/src/current/v20.2/support-resources.md
+++ /dev/null
@@ -1,18 +0,0 @@
----
-title: Support Resources
-summary: There are various ways to reach out for support from Cockroach Labs and our community.
-toc: false
----
-
-For each major release of CockroachDB, Cockroach Labs provides maintenance support for at least 365 days and assistance support for at least an additional 180 days. For more details, see the [Release Support Policy](../releases/release-support-policy.html).
-
-If you're having an issue with CockroachDB, you can reach out for support from Cockroach Labs and our community:
-
-- [Troubleshooting documentation](troubleshooting-overview.html)
-- [CockroachDB Community Forum](https://forum.cockroachlabs.com)
-- [CockroachDB Community Slack](https://cockroachdb.slack.com)
-- [StackOverflow](http://stackoverflow.com/questions/tagged/cockroachdb)
-- [File a GitHub issue](file-an-issue.html)
-- [CockroachDB Support Portal](https://support.cockroachlabs.com)
-
-We also rely on contributions from users like you. If you know how to help users who might be struggling with a problem, we hope you will!
diff --git a/src/current/v20.2/system-catalogs.md b/src/current/v20.2/system-catalogs.md
deleted file mode 100644
index 932ce398405..00000000000
--- a/src/current/v20.2/system-catalogs.md
+++ /dev/null
@@ -1,42 +0,0 @@
----
-title: System Catalogs
-summary: CockroachDB includes several virtual schemas that enable you to interface with CockroachDB.
-toc: true
----
-
-CockroachDB includes a set of system catalogs that provide non-stored data to client applications.
-
-The following system catalogs are available as schemas preloaded to every database:
-
-- [`information_schema`](information-schema.html), a schema provided for compatibility with the SQL standard.
-- [`crdb_internal`](crdb-internal.html), a schema with information about CockroachDB internals.
-- [`pg_catalog`](pg-catalog.html),  a schema provided for compatibility with PostgreSQL.
-- <span class="version-tag">New in v20.2</span>: [`pg_extension`](pg-extension.html), a schema with information about CockroachDB extensions.
-
-{{site.data.alerts.callout_danger}}
-Tables in the system catalogs have varying levels of stability. Not all system catalog tables are meant for programmatic purposes.
-{{site.data.alerts.end}}
-
-To see all of the system catalogs for the [current database](sql-name-resolution.html#current-database), you can use a [`SHOW SCHEMAS`](show-schemas.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-     schema_name     | owner
----------------------+--------
-  crdb_internal      | NULL
-  information_schema | NULL
-  pg_catalog         | NULL
-  pg_extension       | NULL
-  public             | admin
-(5 rows)
-~~~
-
-## See also
-
-- [`SHOW`](show-vars.html)
-- [`SHOW SCHEMAS`](show-schemas.html)
-- [SQL Name Resolution](sql-name-resolution.html)
diff --git a/src/current/v20.2/table-expressions.md b/src/current/v20.2/table-expressions.md
deleted file mode 100644
index 31e5ee72c72..00000000000
--- a/src/current/v20.2/table-expressions.md
+++ /dev/null
@@ -1,409 +0,0 @@
----
-title: Table Expressions
-summary: Table expressions define a data source in selection clauses.
-toc: true
----
-
-Table expressions define a data source in the `FROM` sub-clause of
-[simple `SELECT` clauses](select-clause.html), or as parameter to
-[`TABLE`](selection-queries.html#table-clause).
-
-[SQL Joins](joins.html) are a particular kind of table
-expression.
-
-
-## Synopsis
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/table_ref.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_name` | A [table or view name](#table-or-view-names).
-`table_alias_name` | A name to use in an [aliased table expression](#aliased-table-expressions).
-`name` | One or more aliases for the column names, to use in an [aliased table expression](#aliased-table-expressions).
-`index_name` | Optional syntax to [force index selection](#force-index-selection).
-`func_application` | [Results from a function](#results-from-a-function).
-`row_source_extension_stmt` | [Result rows](#using-the-output-of-other-statements) from a [supported statement](sql-grammar.html#row_source_extension_stmt).
-`select_stmt` | A [selection query](selection-queries.html) to use as [subquery](#subqueries-as-table-expressions).
-`joined_table` | A [join expression](joins.html).
-
-## Table expressions language
-
-The synopsis above really defines a mini-language to construct
-complex table expressions from simpler parts.
-
-Construct | Description | Examples
-----------|-------------|------------
-`table_name [@ scan_parameters]` | [Access a table or view](#access-a-table-or-view). | `accounts`, `accounts@name_idx`
-`function_name ( exprs ... )` | Generate tabular data using a [scalar function](#scalar-function-as-data-source) or [table generator function](#table-generator-functions). | `sin(1.2)`, `generate_series(1,10)`
-`<table expr> [AS] name [( name [, ...] )]` | [Rename a table and optionally columns](#aliased-table-expressions). | `accounts a`, `accounts AS a`, `accounts AS a(id, b)`
-`<table expr> WITH ORDINALITY` | [Enumerate the result rows](#ordinality-annotation). | `accounts WITH ORDINALITY`
-`<table expr> JOIN <table expr> ON ...` | [Join expression](joins.html). | `orders o JOIN customers c ON o.customer_id = c.id`
-`(... subquery ...)` | A [selection query](selection-queries.html) used as [subquery](#subqueries-as-table-expressions). | `(SELECT * FROM customers c)`
-`[... statement ...]` | [Use the result rows](#using-the-output-of-other-statements) of an [explainable statement](sql-grammar.html#preparable_stmt).<br><br>This is a CockroachDB extension. | `[SHOW COLUMNS FROM accounts]`
-
-The following sections provide details on each of these options.
-
-## Table expressions that generate data
-
-The following sections describe primary table expressions that produce
-data.
-
-### Access a table or view
-
-#### Table or view names
-
-Syntax:
-
-~~~
-identifier
-identifier.identifier
-identifier.identifier.identifier
-~~~
-
-A single SQL identifier in a table expression context designates
-the contents of the table, [view](views.html), or sequence with that name
-in the current database, as configured by [`SET DATABASE`](set-vars.html).
-
-If the name is composed of two or more identifiers, [name resolution](sql-name-resolution.html) rules apply.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users; -- uses table `users` in the current database
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM mydb.users; -- uses table `users` in database `mydb`
-~~~
-
-#### Force index selection
-
-{% include {{page.version.version}}/misc/force-index-selection.md %}
-
-{{site.data.alerts.callout_info}}
-You can also force index selection for [`DELETE`](delete.html#force-index-selection-for-deletes) and [`UPDATE`](update.html#force-index-selection-for-updates) statements.
-{{site.data.alerts.end}}
-
-### Access a common table expression
-
-A single identifier in a table expression context can refer to a
-[common table expression](common-table-expressions.html) defined
-earlier.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH a AS (SELECT * FROM users)
-  SELECT * FROM a; -- "a" refers to "WITH a AS .."
-~~~
-
-### Results from a function
-
-A table expression can use the results from a function application as
-a data source.
-
-Syntax:
-
-~~~
-name ( arguments... )
-~~~
-
-The name of a function, followed by an opening parenthesis, followed
-by zero or more [scalar expressions](scalar-expressions.html), followed by
-a closing parenthesis.
-
-The resolution of the function name follows the same rules as the
-resolution of table names. See [Name
-Resolution](sql-name-resolution.html) for more details.
-
-#### Scalar function as data source
-
-When a [function returning a single
-value](scalar-expressions.html#function-calls-and-sql-special-forms) is
-used as a table expression, it is interpreted as tabular data with a
-single column and single row containing the function results.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM sin(3.2)
-~~~
-~~~
-+-----------------------+
-|          sin          |
-+-----------------------+
-| -0.058374143427580086 |
-+-----------------------+
-~~~
-
-{{site.data.alerts.callout_info}}CockroachDB only supports this syntax for compatibility with PostgreSQL. The canonical syntax to evaluate <a href="scalar-expressions.html">scalar functions</a> is as a direct target of <code>SELECT</code>, for example <code>SELECT sin(3.2)</code>.{{site.data.alerts.end}}
-
-
-#### Table generator functions
-
-Some functions directly generate tabular data with multiple rows from
-a single function application. This is also called a "set-returning
-function".
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM generate_series(1, 3);
-~~~
-~~~
-+-----------------+
-| generate_series |
-+-----------------+
-|               1 |
-|               2 |
-|               3 |
-+-----------------+
-~~~
-
-Set-returning functions (SRFs) can now be accessed using `(SRF).x` where `x` is one of the following:
-
-- The name of a column returned from the function
-- `*` to denote all columns.
-
-For example (note that the output of queries against [`information_schema`](information-schema.html) will vary per database):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT (i.keys).* FROM (SELECT information_schema._pg_expandarray(indkey) AS keys FROM pg_index) AS i;
-~~~
-
-~~~
- x | n
----+---
- 1 | 1
- 2 | 1
-(2 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-Currently CockroachDB only supports a small set of generator functions compatible with [the PostgreSQL set-generating functions with the same
-names](https://www.postgresql.org/docs/9.6/static/functions-srf.html).
-{{site.data.alerts.end}}
-
-## Operators that extend a table expression
-
-The following sections describe table expressions that change the
-metadata around tabular data, or add more data, without modifying the
-data of the underlying operand.
-
-### Aliased table expressions
-
-Aliased table expressions rename tables and columns temporarily in
-the context of the current query.
-
-Syntax:
-
-~~~
-<table expr> AS <name>
-<table expr> AS <name>(<colname>, <colname>, ...)
-~~~
-
-In the first form, the table expression is equivalent to its left operand
-with a new name for the entire table, and where columns retain their original name.
-
-In the second form, the columns are also renamed.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT c.x FROM (SELECT COUNT(*) AS x FROM users) AS c;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT c.x FROM (SELECT COUNT(*) FROM users) AS c(x);
-~~~
-
-### Ordinality annotation
-
-Syntax:
-
-~~~
-<table expr> WITH ORDINALITY
-~~~
-
-Designates a data source equivalent to the table expression operand with
-an extra "Ordinality" column that enumerates every row in the data source.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM (VALUES('a'),('b'),('c'));
-~~~
-~~~
-+---------+
-| column1 |
-+---------+
-| a       |
-| b       |
-| c       |
-+---------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM (VALUES ('a'), ('b'), ('c')) WITH ORDINALITY;
-~~~
-~~~
-+---------+------------+
-| column1 | ordinality |
-+---------+------------+
-| a       |          1 |
-| b       |          2 |
-| c       |          3 |
-+---------+------------+
-~~~
-
-{{site.data.alerts.callout_info}}
-`WITH ORDINALITY` necessarily prevents some optimizations of the surrounding query. Use it sparingly if performance is a concern, and always check the output of [`EXPLAIN`](explain.html) in case of doubt.
-{{site.data.alerts.end}}
-
-## `JOIN` expressions
-
-`JOIN` expressions combine the results of two or more table expressions
-based on conditions on the values of particular columns.
-
-See [`JOIN` Expressions](joins.html) for more details.
-
-## Using other queries as table expressions
-
-The following sections describe how to use the results produced by
-another SQL query or statement as a table expression.
-
-### Subqueries as table expressions
-
-Any [selection
-query](selection-queries.html) enclosed
-between parentheses can be used as a table expression, including
-[simple `SELECT` clauses](select-clause.html). This is called a
-"[subquery](subqueries.html)".
-
-Syntax:
-
-~~~
-( ... subquery ... )
-~~~
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT c+2                          FROM (SELECT COUNT(*) AS c FROM users);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT *                            FROM (VALUES(1), (2), (3));
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT firstname || ' ' || lastname FROM (TABLE employees);
-~~~
-
-{{site.data.alerts.callout_info}}
-- See also [Subqueries](subqueries.html) for more details and performance best practices.
-- To use other statements that produce data in a table expression, for example `SHOW`, use the [square bracket notation](#using-the-output-of-other-statements).
-{{site.data.alerts.end}}
-
-<div markdown="1"></div>
-
-### Using the output of other statements
-
-Syntax:
-
-~~~
-SELECT .. FROM [ <stmt> ]
-~~~
-
-A [statement](sql-grammar.html#row_source_extension_stmt) between square brackets in a table expression context designates the output of executing the statement as a row source. The following statements are supported as row sources for table expressions:
-
-- [`DELETE`](delete.html)
-- [`EXPLAIN`](explain.html)
-- [`INSERT`](insert.html)
-- [`SELECT`](select-clause.html)
-- [`SHOW`](sql-statements.html#data-definition-statements)
-- [`UPDATE`](update.html)
-- [`UPSERT`](upsert.html)
-
- `SELECT .. FROM [ <stmt> ]` is equivalent to `WITH table_expr AS ( <stmt> ) SELECT .. FROM table_expr`
-
-{{site.data.alerts.callout_info}}
-This CockroachDB extension syntax complements the [subquery syntax using parentheses](#subqueries-as-table-expressions), which is restricted to [selection queries](selection-queries.html). It was introduced to enable the use of [statements](sql-grammar.html#row_source_extension_stmt) as [subqueries](subqueries.html).
-{{site.data.alerts.end}}
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT "column_name" FROM [SHOW COLUMNS FROM customer];
-~~~
-
-~~~
-+-------------+
-| column_name |
-+-------------+
-| id          |
-| name        |
-| address     |
-+-------------+
-(3 rows)
-~~~
-
-The following statement inserts Albert in the `employee` table and
-immediately creates a matching entry in the `management` table with the
-auto-generated employee ID, without requiring a round trip with the SQL
-client:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO management(manager, reportee)
-    VALUES ((SELECT id FROM employee WHERE name = 'Diana'),
-            (SELECT id FROM [INSERT INTO employee(name) VALUES ('Albert') RETURNING id]));
-~~~
-
-## Composability
-
-Table expressions are used in the [`SELECT`](select-clause.html) and
-[`TABLE`](selection-queries.html#table-clause) variants of [selection
-clauses](selection-queries.html#selection-clauses), and thus can appear everywhere where
-a selection clause is possible. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT ... FROM <table expr>, <table expr>, ...
-> TABLE <table expr>
-> INSERT INTO ... SELECT ... FROM <table expr>, <table expr>, ...
-> INSERT INTO ... TABLE <table expr>
-> CREATE TABLE ... AS SELECT ... FROM <table expr>, <table expr>, ...
-> UPSERT INTO ... SELECT ... FROM <table expr>, <table expr>, ...
-~~~
-
-For more options to compose query results, see [Selection Queries](selection-queries.html).
-
-## See also
-
-- [Constants](sql-constants.html)
-- [Selection Queries](selection-queries.html)
-  - [Selection Clauses](selection-queries.html#selection-clauses)
-- [Explainable Statements](sql-grammar.html#preparable_stmt)
-- [Scalar Expressions](scalar-expressions.html)
-- [Data Types](data-types.html)
-- [Subqueries](subqueries.html)
diff --git a/src/current/v20.2/take-and-restore-encrypted-backups.md b/src/current/v20.2/take-and-restore-encrypted-backups.md
deleted file mode 100644
index c49ceca2040..00000000000
--- a/src/current/v20.2/take-and-restore-encrypted-backups.md
+++ /dev/null
@@ -1,177 +0,0 @@
----
-title: Take and Restore Encrypted Backups
-summary: Learn about the advanced options you can use when you backup and restore a CockroachDB cluster.
-toc: true
----
-
-The ability to [backup a full cluster](backup.html#backup-a-cluster) has been added and the syntax for [incremental backups](backup.html#create-incremental-backups) is simplified. Because of these two changes, [basic backup usage](take-full-and-incremental-backups.html) is now sufficient for most CockroachDB clusters. However, you may want to control your backup and restore options more explicitly.
-
-This doc provides information about how to take and restore encrypted backups in the following ways:
-
-- <span class="version-tag">New in v20.2:</span> [Using AWS Key Management Service (KMS)](#use-aws-key-management-service)
-- [Using a passphrase](#use-a-passphrase)
-
-{{site.data.alerts.callout_info}}
-Encrypted [`BACKUP`](backup.html) is an [Enterprise-only](https://www.cockroachlabs.com/product/cockroachdb/) feature. However, you can take [full backups](take-full-and-incremental-backups.html) without an Enterprise license.
-{{site.data.alerts.end}}
-
-## Use AWS Key Management Service
-
-<span class="version-tag">New in v20.2:</span> You can encrypt full or incremental backups with AWS Key Management Service (KMS) by using the [`kms` option](backup.html#options). Files written by the backup (`BACKUP` manifest and data files) are encrypted using a 256-bit crypto-random generated data key. This data key is encrypted with the provided AWS KMS URI(s) and stored alongside the `BACKUP` data in an `ENCRYPTION_INFO` file, which is used when restoring the backed-up data.
-
-On [`RESTORE`](#restore-from-an-encrypted-backup-with-aws-kms), CockroachDB reads the `ENCRYPTION_INFO` file and attempts to decrypt the encrypted data key using the KMS URI provided in the `RESTORE` statement. Once CockroachDB successfully obtains the unencrypted data key, the `BACKUP` manifest and data files will be decrypted and the restoration will proceed. Similarly, the same KMS URI is needed to decrypt the file to list the contents of the backup when using [`SHOW BACKUP`](show-backup.html#show-an-encrypted-backup).
-
-When used with [incremental backups](backup.html#incremental-backups), the `kms` option is applied to all the [backup file URLs](backup.html#backup-file-urls), which means each incremental must include at least one of the KMS URIs used to take the full backup. It can be any subset of the original URIs, but you cannot include any new KMS URIs. Similarly, when used with [locality-aware backups](take-and-restore-locality-aware-backups.html), the KMS URI provided is applied to files in all localities.
-
-For more information about AWS KMS, see the [documentation](https://aws.amazon.com/kms/).
-
-### Generate a customer master key (CMK)
-
-Before you can use AWS KMS to encrypt a CockroachDB backup, you must first generate a **customer master key (CMK)**. This is the master key generated by AWS KMS and it never leaves the KMS. It contains key-related metadata and key material to encrypt/decrypt other data. The key material can never be exported, deleted, or extracted. CockroachDB expects the CMK to be symmetric (256 bit).
-
-<a name="multi-region"></a> There is also the option to [use multi-region encryption on your data](#take-a-backup-with-multi-region-encryption). At the time of `BACKUP`, you can [provide multiple AWS KMS URIs](#aws-kms-uri-format), each referencing a CMK in a different AWS region. This allows CockroachDB to save multiple versions of the encrypted data key used to encrypt the backup data, one per AWS KMS URI. With these encrypted versions of the data key stored alongside the encrypted backup data, a user can `RESTORE` the encrypted data using any one of the KMS URIs that were supplied during backup. In the case of a single KMS region outage, the data can be decrypted with any of the CMKs from the other regions.
-
-### AWS KMS URI format
-
-The AWS KMS URI must use the following format:
-
-~~~
-aws:///<cmk>?AUTH=<auth_type>&REGION=<region>
-~~~
-
-The AWS URI **requires** the following:
-
- Component                  | Description
-----------------------------+------------------------------------------------------------------------
-`aws:///`                   | The AWS scheme. Note the triple slash (`///`).
-`<cmk>`                     | The key identifiers used to reference the CMK that should be used to encrypt or decrypt. For information about the supported formats, see the [AWS KMS docs](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-id).
-`AUTH=<auth_type>`          | The user-specified credentials.<ul><li>If the `AUTH` parameter is not provided, the AWS connections default to `specified` and the access keys must be provided in the URI parameters (e.g., `AWS_ACCESS_KEY_ID=<key_id>&AWS_SECRET_ACCESS_KEY=<secret_key>`).</li><li>If `AUTH=implicit`, the access keys can be omitted and the [credentials will be loaded from the environment](https://docs.aws.amazon.com/sdk-for-go/api/aws/session/).</li></ul>
-`REGION=<region>`           | The region of the CMK.
-
-See below for [examples](#examples).
-
-### Examples
-
-- [Take an encrypted backup with AWS KMS](#take-an-encrypted-backup-with-aws-kms)
-- [Take a backup with multi-region encryption](#take-a-backup-with-multi-region-encryption)
-- [Restore from an encrypted backup with AWS KMS](#restore-from-an-encrypted-backup-with-aws-kms)
-
-#### Take an encrypted backup with AWS KMS
-
-To take an encrypted backup with AWS KMS, use the `kms` [option](backup.html#options):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO 's3://test/backups/test_kms?AWS_ACCESS_KEY_ID=123456&AWS_SECRET_ACCESS_KEY=123456'
-    WITH kms = 'aws:///<cmk>?AWS_ACCESS_KEY_ID=123456&AWS_SECRET_ACCESS_KEY=123456&REGION=us-east-1';
-~~~
-
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries |  bytes
----------------------+-----------+--------------------+------+---------------+----------
-  594193600274956289 | succeeded |                  1 | 2689 |          1217 | 1420108
-(1 row)
-~~~
-
-#### Take a backup with multi-region encryption
-
-To take a backup with [multi-region encryption](#multi-region), use the `kms` option to specify a comma-separated list of KMS URIs:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO 's3://test/backups/test_explicit_kms_2?AWS_ACCESS_KEY_ID=123456&AWS_SECRET_ACCESS_KEY=123456'
-    WITH KMS=(
-      'aws:///<cmk>?AUTH=implicit&REGION=us-east-1',
-      'aws:///<cmk>?AUTH=implict&REGION=us-west-1'
-    );
-~~~
-
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries | bytes
----------------------+-----------+--------------------+------+---------------+--------
-  594471427115220993 | succeeded |                  1 |   20 |             2 |  1026
-(1 row)
-~~~
-
-#### Restore from an encrypted backup with AWS KMS
-
-To decrypt an [encrypted backup](#take-an-encrypted-backup-with-aws-kms), use the `kms` option and any subset of the KMS URIs that was used to take the backup.
-
-For example, the encrypted backup created in the [first example](#take-an-encrypted-backup-with-aws-kms) can be restored with:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM 's3://test/backups/test_kms?AWS_ACCESS_KEY_ID=123456&AWS_SECRET_ACCESS_KEY=123456'
-    WITH kms = 'aws:///<cmk>?AWS_ACCESS_KEY_ID=123456&AWS_SECRET_ACCESS_KEY=123456&REGION=us-east-1';
-~~~
-
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries |  bytes
----------------------+-----------+--------------------+------+---------------+----------
-  594193600274956291 | succeeded |                  1 | 2689 |          1217 | 1420108
-(1 row)
-~~~
-
-## Use a passphrase
-
-{% include {{ page.version.version }}/backups/encrypted-backup-description.md %}
-
-### Examples
-
-- [Take an encrypted backup using a passphrase](#take-an-encrypted-backup-using-a-passphrase)
-- [Restore from an encrypted backup using a passphrase](#restore-from-an-encrypted-backup-using-a-passphrase)
-
-#### Take an encrypted backup using a passphrase
-
-To take an encrypted backup, use the [`encryption_passphrase` option](backup.html#with-encryption-passphrase):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO \
-'gs://acme-co-backup/test-cluster' \
-WITH encryption_passphrase = 'password123';
-~~~
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries | bytes
----------------------+-----------+--------------------+------+---------------+---------
-  543214409874014209 | succeeded |                  1 | 2597 |          1028 | 467701
-(1 row)
-~~~
-
-To [restore](restore.html), use the same `encryption_passphrase`. See the [example](#restore-from-an-encrypted-backup-using-a-passphrase) below for more details.
-
-#### Restore from an encrypted backup using a passphrase
-
-To decrypt an [encrypted backup](#take-an-encrypted-backup-using-a-passphrase), use the [`encryption_passphrase` option](backup.html#with-encryption-passphrase) option and the same passphrase that was used to create the backup.
-
-For example, the encrypted backup created in the [previous example](#take-an-encrypted-backup-using-a-passphrase) can be restored with:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM \
-'gs://acme-co-backup/test-cluster' \
-WITH encryption_passphrase = 'password123';
-~~~
-~~~
-        job_id       |  status   | fraction_completed | rows | index_entries | bytes
----------------------+-----------+--------------------+------+---------------+---------
-  543217488273801217 | succeeded |                  1 | 2597 |          1028 | 467701
-(1 row)
-~~~
-
-## See also
-
-- [`BACKUP`][backup]
-- [`RESTORE`][restore]
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Take and Restore Locality-aware Backups](take-and-restore-locality-aware-backups.html)
-- [Take Backups with Revision History and Restore from a Point-in-time](take-backups-with-revision-history-and-restore-from-a-point-in-time.html)
-- [`SQL DUMP`](cockroach-dump.html)
-- [`IMPORT`](migration-overview.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference links -->
-
-[backup]:  backup.html
-[restore]: restore.html
diff --git a/src/current/v20.2/take-and-restore-locality-aware-backups.md b/src/current/v20.2/take-and-restore-locality-aware-backups.md
deleted file mode 100644
index 9cd4066b004..00000000000
--- a/src/current/v20.2/take-and-restore-locality-aware-backups.md
+++ /dev/null
@@ -1,229 +0,0 @@
----
-title: Take and Restore Locality-aware Backups
-summary: Learn about the advanced options you can use when you backup and restore a CockroachDB cluster.
-toc: true
----
-
-The ability to [backup a full cluster](backup.html#backup-a-cluster) has been added and the syntax for [incremental backups](backup.html#create-incremental-backups) is simplified. Because of these two changes, [basic backup usage](take-full-and-incremental-backups.html) is now sufficient for most CockroachDB clusters. However, you may want to control your backup and restore options more explicitly.
-
-This doc provides information about how to take and restore locality-aware backups.
-
-{{site.data.alerts.callout_info}}
-Locality-aware [`BACKUP`](backup.html) is an [Enterprise-only](https://www.cockroachlabs.com/product/cockroachdb/) feature. However, you can take [full backups](take-full-and-incremental-backups.html) without an Enterprise license.
-{{site.data.alerts.end}}
-
-You can create locality-aware backups such that each node writes files only to the backup destination that matches the [node locality](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes) configured at [node startup](cockroach-start.html).
-
-This is useful for:
-
-- Reducing cloud storage data transfer costs by keeping data within cloud regions.
-- Helping you comply with data domiciling requirements.
-
-A locality-aware backup is specified by a list of URIs, each of which has a `COCKROACH_LOCALITY` URL parameter whose single value is either `default` or a single locality key-value pair such as `region=us-east`. At least one `COCKROACH_LOCALITY` must be the `default`. Given a list of URIs that together contain the locations of all of the files for a single locality-aware backup, [`RESTORE` can read in that backup](#restore-from-a-locality-aware-backup).
-
-{{site.data.alerts.callout_info}}
-The locality query string parameters must be [URL-encoded](https://en.wikipedia.org/wiki/Percent-encoding).
-{{site.data.alerts.end}}
-
-During locality-aware backups, backup file placement is determined by leaseholder placement, as each node is responsible for backing up the ranges for which it is the leaseholder.  Nodes write files to the backup storage location whose locality matches their own node localities, with a preference for more specific values in the locality hierarchy.  If there is no match, the `default` locality is used.
-
-## Create a locality-aware backup
-
-For example, to create a locality-aware backup where nodes with the locality `region=us-west` write backup files to `s3://us-west-bucket`, and all other nodes write to `s3://us-east-bucket` by default, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO
-	  ('s3://us-east-bucket?COCKROACH_LOCALITY=default', 's3://us-west-bucket?COCKROACH_LOCALITY=region%3Dus-west');
-~~~
-
-can be restored by running:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM ('s3://us-east-bucket', 's3://us-west-bucket');
-~~~
-
-Note that the first URI in the list has to be the URI specified as the `default` URI when the backup was created. If you have moved your backups to a different location since the backup was originally taken, the first URI must be the new location of the files originally written to the `default` location.
-
-## Restore from a locality-aware backup
-
-You can create locality-aware backups such that each node writes files only to the backup destination that matches the [node locality](configure-replication-zones.html#descriptive-attributes-assigned-to-nodes) configured at [node startup](cockroach-start.html).
-
-Given a list of URIs that together contain the locations of all of the files for a single [locality-aware backup](#create-a-locality-aware-backup), [`RESTORE`][restore] can read in that backup. Note that the list of URIs passed to [`RESTORE`][restore] may be different from the URIs originally passed to [`BACKUP`][backup]. This is because it's possible to move the contents of one of the parts of a locality-aware backup (i.e., the files written to that destination) to a different location, or even to consolidate all the files for a locality-aware backup into a single location.
-
-When restoring a [full backup](take-full-and-incremental-backups.html#full-backups), the cluster data is restored first, then the system table data "as is." This means that the restored zone configurations can point to regions that do not have active nodes in the new cluster. For example, if your full backup has the following [zone configurations](configure-zone.html):
-
-~~~ sql
-> ALTER PARTITION europe_west OF INDEX movr.public.rides@primary \
-		CONFIGURE ZONE USING constraints = '[+region=europe-west1]';
-
-> ALTER PARTITION us_east OF INDEX movr.public.rides@primary \
-		CONFIGURE ZONE USING constraints = '[+region=us-east1]';
-
-> ALTER PARTITION us_west OF INDEX movr.public.rides@primary \
-		CONFIGURE ZONE USING constraints = '[+region=us-west1]';
-~~~
-
-And the restored cluster does not have [nodes with the locality](partitioning.html#node-attributes) `region=us-west1`, the restored cluster will still have a zone configuration for `us-west1`. This means that the cluster's data will _not_ be reshuffled to `us-west1` because the region does not exist. The data will be distributed as if the zone configuration does not exist. For the data to be distributed correctly, you can [add node(s)](cockroach-start.html) with the missing region or [remove the zone configuration](configure-zone.html#remove-a-replication-zone).
-
-
-{{site.data.alerts.callout_info}}
-[`RESTORE`][restore] is not truly locality-aware; while restoring from backups, a node may read from a store that does not match its locality. This can happen in the cases that either the [`BACKUP`][backup] or [`RESTORE`][restore] was not full cluster. Note that during a locality-aware restore, some data may be temporarily located on another node before it is eventually relocated to the appropriate node. To avoid this, you can [manually restore zone configurations from a locality-aware backup](#manually-restore-zone-configurations-from-a-locality-aware-backup).
-{{site.data.alerts.end}}
-
-## Create an incremental locality-aware backup
-
-To create an incremental locality-aware backup from a full locality-aware backup, the syntax the same as it is for [regular incremental backups](backup.html#create-incremental-backups). If you backup to a destination already containing a full backup, an incremental backup will be appended to the full backup in a subdirector. For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO
-	  ('s3://us-east-bucket?COCKROACH_LOCALITY=default', 's3://us-west-bucket?COCKROACH_LOCALITY=region%3Dus-west');
-~~~
-
-{{site.data.alerts.callout_info}}
-It is recommend that the same localities be included for every incremental backup in the series of backups; however, only the `default` locality is required. When [restoring from an incremental locality-aware backup](#restore-from-an-incremental-locality-aware-backup), you need to include _every_ locality ever used, even if it was only used once.
-{{site.data.alerts.end}}
-
-And if you want to explicitly control where your incremental backups go, use the `INCREMENTAL FROM` syntax:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO (${uri_1}, ${uri_2}, ...) INCREMENTAL FROM ${full_backup_uri} ...;
-~~~
-
-For example, to create an incremental locality-aware backup from a previous full locality-aware backup where nodes with the locality `region=us-west` write backup files to `s3://us-west-bucket`, and all other nodes write to `s3://us-east-bucket` by default, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO \
-('s3://us-east-bucket/test-cluster-2019-10-08-nightly?COCKROACH_LOCALITY=default', 's3://us-west-bucket/test-cluster-2019-10-08-nightly?COCKROACH_LOCALITY=region%3Dus-west')
-INCREMENTAL FROM 's3://us-east-bucket/test-cluster-2019-10-07-weekly';
-~~~
-
-{{site.data.alerts.callout_info}}
-Note that only the backup URIs you set as the `default` when you created the previous backup(s) are needed in the `INCREMENTAL FROM` clause of your incremental `BACKUP` statement (as shown in the example). This is because the `default` destination for a locality-aware backup contains a manifest file that contains all the metadata required to create additional incremental backups based on it.
-{{site.data.alerts.end}}
-
-## Restore from an incremental locality-aware backup
-
-A locality-aware backup URI can also be used in place of any incremental backup URI in [`RESTORE`][restore].
-
-For example, an incremental locality-aware backup created with
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO
-	  ('s3://us-east-bucket/database-bank-2019-10-08-nightly?COCKROACH_LOCALITY=default', 's3://us-west-bucket/database-bank-2019-10-08-nightly?COCKROACH_LOCALITY=region%3Dus-west')
-  INCREMENTAL FROM
-	  's3://us-east-bucket/database-bank-2019-10-07-weekly';
-~~~
-
-can be restored by running:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM
-  	('s3://us-east-bucket/database-bank-2019-10-07-weekly', 's3://us-west-bucket/database-bank-2019-10-07-weekly'),
-	  ('s3://us-east-bucket/database-bank-2019-10-08-nightly', 's3://us-west-bucket/database-bank-2019-10-08-nightly');
-~~~
-
-{{site.data.alerts.callout_info}}
-When restoring from an incremental locality-aware backup, you need to include _every_ locality ever used, even if it was only used once.
-{{site.data.alerts.end}}
-
-## Create an incremental locality-aware backup from a previous locality-aware backup
-
-To make an incremental locality-aware backup from another locality-aware backup, the syntax is as follows:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO ({uri_1}, {uri_2}, ...) INCREMENTAL FROM {full_backup}, {incr_backup_1}, {incr_backup_2}, ...;
-~~~
-
-For example, let's say you normally run a full backup every Monday, followed by incremental backups on the remaining days of the week.
-
-By default, all nodes send their backups to your `s3://us-east-bucket`, except for nodes in `region=us-west`, which will send their backups to `s3://us-west-bucket`.
-
-If today is Thursday, October 10th, 2019, your `BACKUP` statement will list the following backup URIs:
-
-- The full locality-aware backup URI from Monday, e.g.,
-  - `s3://us-east-bucket/test-cluster-2019-10-07-weekly`
-- The incremental backup URIs from Tuesday and Wednesday, e.g.,
-  - `s3://us-east-bucket/test-cluster-2019-10-08-nightly`
-  - `s3://us-east-bucket/test-cluster-2019-10-09-nightly`
-
-Given the above, to take the incremental locality-aware backup scheduled for today (Thursday), you will run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO
-	  ('s3://us-east-bucket/test-cluster-2019-10-10-nightly?COCKROACH_LOCALITY=default', 's3://us-west-bucket/test-cluster-2019-10-10-nightly?COCKROACH_LOCALITY=region%3Dus-west')
-  INCREMENTAL FROM
-	  's3://us-east-bucket/test-cluster-2019-10-07-weekly',
-	  's3://us-east-bucket/test-cluster-2019-10-08-nightly',
-  	's3://us-east-bucket/test-cluster-2019-10-09-nightly';
-~~~
-
-{{site.data.alerts.callout_info}}
-Note that only the backup URIs you set as the `default` when you created the previous backup(s) are needed in the `INCREMENTAL FROM` clause of your incremental `BACKUP` statement (as shown in the example). This is because the `default` destination for a locality-aware backup contains a manifest file that contains all the metadata required to create additional incremental backups based on it.
-{{site.data.alerts.end}}
-
-## Manually restore zone configurations from a locality-aware backup
-
-During a [locality-aware restore](#restore-from-a-locality-aware-backup), some data may be temporarily located on another node before it is eventually relocated to the appropriate node. To avoid this, you need to manually restore [zone configurations](configure-replication-zones.html) first:
-
-Once the locality-aware restore has started, [pause the restore](pause-job.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> PAUSE JOB 27536791415282;
-~~~
-
-The `system.zones` table stores your cluster's [zone configurations](configure-replication-zones.html), which will prevent the data from rebalancing. To restore them, you must restore the `system.zones` table into a new database because you cannot drop the existing `system.zones` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE system.zones \
-FROM 'azure://acme-co-backup?AZURE_ACCOUNT_KEY=hash&AZURE_ACCOUNT_NAME=acme-co' \
-WITH into_db = 'newdb';
-~~~
-
-After it's restored into a new database, you can write the restored `zones` table data to the cluster's existing `system.zones` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO system.zones SELECT * FROM newdb.zones;
-~~~
-
-Then drop the temporary table you created:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TABLE newdb.zones;
-~~~
-
-Then, [resume the restore](resume-job.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESUME JOB 27536791415282;
-~~~
-
-## See also
-
-- [`BACKUP`][backup]
-- [`RESTORE`][restore]
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Take and Restore Encrypted Backups](take-and-restore-encrypted-backups.html)
-- [Take Backups with Revision History and Restore from a Point-in-time](take-backups-with-revision-history-and-restore-from-a-point-in-time.html)
-- [`SQL DUMP`](cockroach-dump.html)
-- [`IMPORT`](migration-overview.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference links -->
-
-[backup]:  backup.html
-[restore]: restore.html
diff --git a/src/current/v20.2/take-backups-with-revision-history-and-restore-from-a-point-in-time.md b/src/current/v20.2/take-backups-with-revision-history-and-restore-from-a-point-in-time.md
deleted file mode 100644
index 1859768b65d..00000000000
--- a/src/current/v20.2/take-backups-with-revision-history-and-restore-from-a-point-in-time.md
+++ /dev/null
@@ -1,71 +0,0 @@
----
-title: Take Backups with Revision History and Restore from a Point-in-time
-summary: Learn about the advanced options you can use when you backup and restore a CockroachDB cluster.
-toc: true
----
-
-The ability to [backup a full cluster](backup.html#backup-a-cluster) has been added and the syntax for [incremental backups](backup.html#create-incremental-backups) is simplified. Because of these two changes, [basic backup usage](take-full-and-incremental-backups.html) is now sufficient for most CockroachDB clusters. However, you may want to control your backup and restore options more explicitly.
-
-This doc provides information about how to take backups with revision history and restore from a point-in-time.
-
-{{site.data.alerts.callout_info}}
-[`BACKUP`](backup.html) with revision history is an [Enterprise-only](https://www.cockroachlabs.com/product/cockroachdb/) feature. However, you can take [full backups](take-full-and-incremental-backups.html) without an Enterprise license.
-{{site.data.alerts.end}}
-
-You can create full or incremental backups [with revision history](backup.html#with-revision-history):
-
-- Taking full backups with revision history allows you to back up every change made within the garbage collection period leading up to and including the given timestamp.
-- Taking incremental backups with revision history allows you to back up every change made since the last backup and within the garbage collection period leading up to and including the given timestamp. You can take incremental backups with revision history even when your previous full or incremental backups were taken without revision history.
-
-You can configure garbage collection periods using the `ttlseconds` [replication zone setting](configure-replication-zones.html). Taking backups with revision history allows for point-in-time restores within the revision history.
-
-## Create a backup with revision history
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO \
-'gs://acme-co-backup/test-cluster-2017-03-27-weekly' \
-AS OF SYSTEM TIME '-10s' WITH revision_history;
-~~~
-
-## Point-in-time restore
-
-If the full or incremental backup was taken [with revision history](#create-a-backup-with-revision-history), you can restore the data as it existed at an arbitrary point-in-time within the revision history captured by that backup. Use the [`AS OF SYSTEM TIME`](as-of-system-time.html) clause to specify the point-in-time.
-
- Additionally, if you want to restore a specific incremental backup, you can do so by specifying the `end_time` of the backup by using the [`AS OF SYSTEM TIME`](as-of-system-time.html) clause. To find the incremental backup's `end_time`, use [`SHOW BACKUP`](show-backup.html).
-
-If you do not specify a point-in-time, the data will be restored to the backup timestamp; that is, the restore will work as if the data was backed up without revision history.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM 'gs://acme-co-backup/database-bank-2017-03-27-weekly' \
-AS OF SYSTEM TIME '2017-02-26 10:00:00';
-~~~
-
-## Point-in-time restore from incremental backups
-
-Restoring from incremental backups requires previous full and incremental backups. In this example, `-weekly` is the full backup and the two `-nightly` are incremental backups:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM \
-'gs://acme-co-backup/database-bank-2017-03-27-weekly', 'gs://acme-co-backup/database-bank-2017-03-28-nightly', 'gs://acme-co-backup/database-bank-2017-03-29-nightly' \
-AS OF SYSTEM TIME '2017-02-28 10:00:00';
-~~~
-
-## See also
-
-- [`BACKUP`][backup]
-- [`RESTORE`][restore]
-- [Take Full and Incremental Backups](take-full-and-incremental-backups.html)
-- [Take and Restore Encrypted Backups](take-and-restore-encrypted-backups.html)
-- [Take and Restore Locality-aware Backups](take-and-restore-locality-aware-backups.html)
-- [`SQL DUMP`](cockroach-dump.html)
-- [`IMPORT`](migration-overview.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference links -->
-
-[backup]:  backup.html
-[restore]: restore.html
diff --git a/src/current/v20.2/take-full-and-incremental-backups.md b/src/current/v20.2/take-full-and-incremental-backups.md
deleted file mode 100644
index 6409ef21652..00000000000
--- a/src/current/v20.2/take-full-and-incremental-backups.md
+++ /dev/null
@@ -1,165 +0,0 @@
----
-title: Take Full and Incremental Backups
-summary: Learn how to back up and restore a CockroachDB cluster.
-toc: true
----
-
-Because CockroachDB is designed with high fault tolerance, backups are primarily needed for [disaster recovery](disaster-recovery.html) (i.e., if your cluster loses a majority of its nodes). Isolated issues (such as small-scale node outages) do not require any intervention. However, as an operational best practice, **we recommend taking regular backups of your data**.
-
-There are two main types of backups:
-
-- [Full backups](#full-backups)
-- [Incremental backups](#incremental-backups)
-
-## Perform backup and restore
-
-You can use the [`BACKUP`](backup.html) statement to efficiently back up your cluster's schemas and data to popular cloud services such as AWS S3, Google Cloud Storage, or NFS, and the [`RESTORE`](restore.html) statement to efficiently restore schema and data as necessary. For more information, see [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html).
-
-{{site.data.alerts.callout_success}}
-<span class="version-tag">New in v20.2:</span> You can create [schedules for periodic backups](manage-a-backup-schedule.html) in CockroachDB. We recommend using scheduled backups to automate daily backups of your cluster.
-{{site.data.alerts.end}}
-
-### Full backups
-
-<span class="version-tag">New in v20.2:</span> Full backups are now available to both core and Enterprise users.
-
-In most cases, **it's recommended to take full nightly backups of your cluster**. A cluster backup allows you to do the following:
-
-- Restore table(s) from the cluster
-- Restore database(s) from the cluster
-- Restore a full cluster
-
-To do a cluster backup, use the [`BACKUP`](backup.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO '<backup_location>';
-~~~
-
-If it's ever necessary, you can use the [`RESTORE`][restore] statement to restore a table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE TABLE bank.customers FROM '<backup_location>';
-~~~
-
-Or to restore a  database:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE DATABASE bank FROM '<backup_location>';
-~~~
-
-Or to restore your full cluster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM '<backup_location>';
-~~~
-
-{{site.data.alerts.callout_info}}
-A full cluster restore can only be run on a target cluster that has _never_ had user-created databases or tables.
-{{site.data.alerts.end}}
-
-### Incremental backups
-
-If your cluster grows too large for nightly full backups, you can take less frequent full backups (e.g., weekly) with nightly incremental backups. Incremental backups are storage efficient and faster than full backups for larger clusters.
-
-{{site.data.alerts.callout_info}}
-To take incremental backups, you need an [Enterprise license](enterprise-licensing.html).
-{{site.data.alerts.end}}
-
-Periodically run the [`BACKUP`][backup] command to take a full backup of your cluster:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO '<backup_location>';
-~~~
-
-Then, create nightly incremental backups based off of the full backups you've already created. If you backup to a destination already containing a full backup, an incremental backup will be appended to the full backup in a subdirectory:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP TO '<backup_location>';
-~~~
-
-{{site.data.alerts.callout_info}}
-For an example on how to specify the destination of an incremental backup, see [Take Full and Incremental Backups](take-full-and-incremental-backups.html#incremental-backups-with-explicitly-specified-destinations)
-{{site.data.alerts.end}}
-
-If it's ever necessary, you can then use the [`RESTORE`][restore] command to restore your cluster, database(s), and/or table(s). [Restoring from incremental backups](restore.html#restore-from-incremental-backups) requires previous full and incremental backups. To restore from a destination containing the full backup, as well as the automatically appended incremental backups (that are stored as subdirectories, like in the example above):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> RESTORE FROM '<backup_location>';
-~~~
-
-{{site.data.alerts.callout_info}}
-`RESTORE` will re-validate [indexes](indexes.html) when [incremental backups](take-full-and-incremental-backups.html) are created from an older version, but restored from a newer version.
-
-Incremental backups created by v20.2.2 and prior v20.2.x releases or v20.1.4 and prior v20.1.x releases may include incomplete data for indexes that were in the process of being created. Therefore, when incremental backups taken by these versions are restored by v20.2.8+, any indexes created during those incremental backups will be re-validated by `RESTORE`.
-{{site.data.alerts.end}}
-
-### Incremental backups with explicitly specified destinations
-
-To explicitly control where your incremental backups go, use the [`INCREMENTAL FROM`](backup.html#synopsis) syntax:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BACKUP DATABASE bank \
-TO 'gs://acme-co-backup/db/bank/2017-03-29-nightly' \
-AS OF SYSTEM TIME '-10s' \
-INCREMENTAL FROM 'gs://acme-co-backup/database-bank-2017-03-27-weekly', 'gs://acme-co-backup/database-bank-2017-03-28-nightly' WITH revision_history;
-~~~
-
-{{site.data.alerts.callout_info}}
-To take incremental backups, you need an [Enterprise license](enterprise-licensing.html).
-{{site.data.alerts.end}}
-
-### Examples
-
-#### Automated full backups
-
-Both core and Enterprise users can use backup scheduling for full backups of clusters, databases, or tables. To create schedules that only take full backups, included the `FULL BACKUP ALWAYS` clause. For example, to create a schedule for taking full cluster backups:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE SCHEDULE core_schedule_label
-  FOR BACKUP INTO 's3://test/schedule-test-core?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x'
-    RECURRING '@daily'
-    FULL BACKUP ALWAYS
-    WITH SCHEDULE OPTIONS first_run = 'now';
-~~~
-~~~
-     schedule_id     |        name         | status |         first_run         | schedule |                                                                                       backup_stmt
----------------------+---------------------+--------+---------------------------+----------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  588799238330220545 | core_schedule_label | ACTIVE | 2020-09-11 00:00:00+00:00 | @daily   | BACKUP INTO 's3://test/schedule-test-core?AWS_ACCESS_KEY_ID=x&AWS_SECRET_ACCESS_KEY=x' WITH detached
-(1 row)
-~~~
-
-For more examples on how to schedule backups that take full and incremental backups, see [`CREATE SCHEDULE FOR BACKUP`](create-schedule-for-backup.html).
-
-#### Advanced examples
-
-{% include {{ page.version.version }}/backups/advanced-examples-list.md %}
-
-{{site.data.alerts.callout_info}}
-To take incremental backups, backups with revision history, locality-aware backups, and encrypted backups, you need an [Enterprise license](enterprise-licensing.html).
-{{site.data.alerts.end}}
-
-## See also
-
-- [`BACKUP`][backup]
-- [`RESTORE`][restore]
-- [Take and Restore Encrypted Backups](take-and-restore-encrypted-backups.html)
-- [Take and Restore Locality-aware Backups](take-and-restore-locality-aware-backups.html)
-- [Take Backups with Revision History and Restore from a Point-in-time](take-backups-with-revision-history-and-restore-from-a-point-in-time.html)
-- [`SQL DUMP`](cockroach-dump.html)
-- [`IMPORT`](migration-overview.html)
-- [Use the Built-in SQL Client](cockroach-sql.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-
-<!-- Reference links -->
-
-[backup]:  backup.html
-[restore]: restore.html
diff --git a/src/current/v20.2/temporary-tables.md b/src/current/v20.2/temporary-tables.md
deleted file mode 100644
index bb0028e723d..00000000000
--- a/src/current/v20.2/temporary-tables.md
+++ /dev/null
@@ -1,222 +0,0 @@
----
-title: Temporary Tables
-summary: CockroachDB supports session-scoped temporary tables.
-toc: true
----
-
- CockroachDB supports session-scoped temporary tables (also called "temp tables"). Unlike [persistent tables](create-table.html), temp tables can only be accessed from the session in which they were created, and they are dropped at the end of the session.
-
-To create a temp table, add `TEMP`/`TEMPORARY` to a [`CREATE TABLE`](create-table.html) or [`CREATE TABLE AS`](create-table-as.html) statement. For full syntax details, see the [`CREATE TABLE`](create-table.html#synopsis) and [`CREATE TABLE AS`](create-table-as.html#synopsis) pages. For example usage, see [Examples](#examples).
-
-{{site.data.alerts.callout_danger}}
-**This is an experimental feature**. The interface and output are subject to change. For details, see the tracking issue [cockroachdb/cockroach#46260](https://github.com/cockroachdb/cockroach/issues/46260).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-By default, temp tables are disabled in CockroachDB. To enable temp tables, set the `experimental_enable_temp_tables` [session variable](set-vars.html) to `on`.
-{{site.data.alerts.end}}
-
-CockroachDB also supports [temporary views](views.html#temporary-views) and [temporary sequences](create-sequence.html#temporary-sequences).
-
-## Details
-
-- Temp tables are automatically dropped at the end of the session.
-- A temp table can only be accessed from the session in which it was created.
-- Temp tables persist across transactions in the same session.
-- Temp tables can reference persistent tables, but persistent tables cannot reference temp tables.
-- Temp tables cannot be converted to persistent tables.
-- For [PostgreSQL compatibility](https://www.postgresql.org/docs/current/sql-createtable.html), CockroachDB supports the clause `ON COMMIT PRESERVE ROWS` at the end of `CREATE TEMP TABLE` statements. CockroachDB only supports session-scoped temp tables, and does not support the clauses `ON COMMIT DELETE ROWS` and `ON COMMIT DROP`, which are used to define transaction-scoped temp tables in PostgreSQL.
-
-By default, every 30 minutes CockroachDB cleans up all temporary objects that are not tied to an active session. You can change how often the cleanup job runs with the `sql.temp_object_cleaner.cleanup_interval` [cluster setting](cluster-settings.html).
-
-## Temporary schemas
-
-Temp tables are not part of the `public` schema. Instead, when you create the first temp table for a session, CockroachDB generates a single temporary schema (`pg_temp_<id>`) for all of the temp tables, [temporary views](views.html#temporary-views), and [temporary sequences](create-sequence.html#temporary-sequences) in the current session for a database. In a session, you can reference the session's temporary schema as `pg_temp`.
-
-{{site.data.alerts.callout_info}}
-Because the [`SHOW TABLES`](show-tables.html) statement defaults to the `public` schema (which doesn't include temp tables), using `SHOW TABLES` without specifying a schema will not return any temp tables.
-{{site.data.alerts.end}}
-
-## Examples
-
-To use temp tables, you need to set `experimental_enable_temp_tables` to `on`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET experimental_enable_temp_tables=on;
-~~~
-
-### Create a temp table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TEMP TABLE users (
-        id UUID,
-        city STRING,
-        name STRING,
-        address STRING,
-        CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-You can use [`SHOW CREATE`](show-create.html) to view temp tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-  table_name |                create_statement
--------------+-------------------------------------------------
-  users      | CREATE TEMP TABLE users (
-             |     id UUID NOT NULL,
-             |     city STRING NULL,
-             |     name STRING NULL,
-             |     address STRING NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     FAMILY "primary" (id, city, name, address)
-             | )
-(1 row)
-~~~
-
-To show the newly created `pg_temp` schema, use [`SHOW SCHEMAS`](show-schemas.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW SCHEMAS;
-~~~
-
-~~~
-           schema_name
----------------------------------
-  crdb_internal
-  information_schema
-  pg_catalog
-  pg_extension
-  pg_temp_1602087923187609000_1
-  public
-(6 rows)
-~~~
-
-### Create a temp table that references another temp table
-
-To create another temp table that references `users`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TEMP TABLE vehicles (
-        id UUID NOT NULL,
-        city STRING NOT NULL,
-        type STRING,
-        owner_id UUID,
-        creation_time TIMESTAMP,
-        CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-        CONSTRAINT fk_city_ref_users FOREIGN KEY (city, owner_id) REFERENCES users(city, id)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE vehicles;
-~~~
-
-~~~
-  table_name |                                     create_statement
--------------+--------------------------------------------------------------------------------------------
-  vehicles   | CREATE TEMP TABLE vehicles (
-             |     id UUID NOT NULL,
-             |     city STRING NOT NULL,
-             |     type STRING NULL,
-             |     owner_id UUID NULL,
-             |     creation_time TIMESTAMP NULL,
-             |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-             |     CONSTRAINT fk_city_ref_users FOREIGN KEY (city, owner_id) REFERENCES users(city, id),
-             |     INDEX vehicles_auto_index_fk_city_ref_users (city ASC, owner_id ASC),
-             |     FAMILY "primary" (id, city, type, owner_id, creation_time)
-             | )
-(1 row)
-~~~
-
-### Show all temp tables in a session
-
-To show all temp tables in a session's temporary schema, use `SHOW TABLES FROM pg_temp`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM pg_temp;
-~~~
-
-~~~
-           schema_name          | table_name | type  | estimated_row_count
---------------------------------+------------+-------+----------------------
-  pg_temp_1602087923187609000_1 | users      | table |                   0
-  pg_temp_1602087923187609000_1 | vehicles   | table |                   0
-(2 rows)
-~~~
-
-You can also use the full name of the temporary schema in the `SHOW` statement (e.g., `SHOW TABLES FROM pg_temp_1602087923187609000_1`).
-
-### Show temp tables in `information_schema`
-
-Although temp tables are not included in the `public` schema, metadata for temp tables is included in the [`information_schema`](information-schema.html) and `pg_catalog` schemas.
-
-For example, the [`information_schema.tables`](information-schema.html#tables) table includes information about all tables in all schemas in all databases, including temp tables:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.tables WHERE table_schema='pg_temp_1602087923187609000_1';
-~~~
-
-~~~
-   table_catalog |         table_schema          | table_name |   table_type    | is_insertable_into | version
------------------+-------------------------------+------------+-----------------+--------------------+----------
-  defaultdb      | pg_temp_1602087923187609000_1 | users      | LOCAL TEMPORARY | YES                |       2
-  defaultdb      | pg_temp_1602087923187609000_1 | vehicles   | LOCAL TEMPORARY | YES                |       2
-(2 rows)
-~~~
-
-### Cancel a session
-
-If you end the session, all temp tables are lost.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW session_id;
-~~~
-
-~~~
-             session_id
-------------------------------------
-  15fd69f9831c1ed00000000000000001
-(1 row)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CANCEL SESSION '15fd69f9831c1ed00000000000000001';
-~~~
-
-~~~
-ERROR: driver: bad connection
-warning: connection lost!
-opening new connection: all session settings will be lost
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE TABLE users;
-~~~
-
-~~~
-ERROR: relation "users" does not exist
-SQLSTATE: 42P01
-~~~
-
-## See also
-
-- [`CREATE TABLE`](create-table.html)
-- [`CREATE TABLE AS`](create-table-as.html)
-- [`SHOW CREATE TABLE`](show-create.html)
-- [Temporary views](views.html#temporary-views)
-- [Temporary sequences](create-sequence.html#temporary-sequences).
diff --git a/src/current/v20.2/third-party-database-tools.md b/src/current/v20.2/third-party-database-tools.md
deleted file mode 100644
index 71fdbbdfdd8..00000000000
--- a/src/current/v20.2/third-party-database-tools.md
+++ /dev/null
@@ -1,15 +0,0 @@
----
-title: Third-Party Tools Supported by Cockroach Labs
-summary: Learn about third-party software that works with CockroachDB.
-toc: true
----
-
-CockroachDB's support of the PostgreSQL wire protocol makes most PostgreSQL drivers, ORM frameworks, and other types of third-party database tools designed for PostgreSQL compatible with CockroachDB. Cockroach Labs guarantees [official support](#support-levels) for a set of popular PostgreSQL tools, which we list on this page.
-
-{% include {{page.version.version}}/misc/tooling.md %}
-
-## See also
-
-- [Example Apps](example-apps.html)
-- [Install a Postgres Client](install-client-drivers.html)
-- [Third-Party Tools Supported by the Community](community-tooling.html)
diff --git a/src/current/v20.2/time.md b/src/current/v20.2/time.md
deleted file mode 100644
index b70147e3895..00000000000
--- a/src/current/v20.2/time.md
+++ /dev/null
@@ -1,226 +0,0 @@
----
-title: TIME / TIMETZ
-summary: CockroachDB's TIME data type stores a time of day in UTC.
-toc: true
----
-
-The `TIME` [data type](data-types.html) stores the time of day in UTC.
-
- The `TIMETZ` data type stores a time of day with a time zone offset from UTC.
-
-## Variants
-
-`TIME` has two variants:
-
-- `TIME`, which presents all `TIME` values in UTC.
-
-- `TIMETZ`, which converts `TIME` values with a specified time zone offset from UTC.
-
-    Ordering for `TIMETZ` is done in terms of [epoch](https://en.wikipedia.org/wiki/Epoch_(computing)). Time zones with lesser values are ranked higher if times are equal. For example, `'2:00-1' > '2:00+0'` and `'12:00-1' > '1:00+0'`.
-
-    [Like Postgres](https://www.postgresql.org/docs/current/static/datatype-datetime.html), we implement the `TIMETZ` variant for [SQL standards compliance](sql-feature-support.html). We also implement the `TIMETZ` variant for compatibility with ORMs, like [Hibernate](build-a-java-app-with-cockroachdb-hibernate.html).
-
-You can use the [`timezone()`](functions-and-operators.html#date-and-time-functions) and [`AT TIME ZONE`](functions-and-operators.html#special-syntax-forms) functions to convert a `TIMETZ` into a `TIME` at a specified timezone, or to convert a `TIME` into a `TIMETZ` at a specified timezone.
-
-{{site.data.alerts.callout_success}}
-We recommend always using `TIME` instead of `TIMETZ`. Convert UTC values to the appropriate time zone on the client side.
-{{site.data.alerts.end}}
-
-## Aliases
-
-In CockroachDB, the following are aliases:
-
-Alias    | Long Version
----------|-------------
-`TIME`   | `TIME WITHOUT TIME ZONE`
-`TIMETZ` | `TIME WITH TIME ZONE`
-
-## Syntax
-
-### `TIME`
-
-A constant value of type `TIME` can be expressed using an [interpreted literal](sql-constants.html#interpreted-literals), or a string literal [annotated with](scalar-expressions.html#explicitly-typed-expressions) type `TIME` or  [coerced to](scalar-expressions.html#explicit-type-coercions) type `TIME`. When it is unambiguous, a simple unannotated [string literal](sql-constants.html#string-literals) can also be automatically interpreted as type `TIME`.
-
-The string format for `TIME` is `HH:MM:SS.SSSSSS`. For example: `TIME '05:40:00.000001'`. The fractional portion is optional and is rounded to microseconds (i.e., six digits after the decimal) for compatibility with the [PostgreSQL wire protocol](https://www.postgresql.org/docs/current/static/protocol.html).
-
-{{site.data.alerts.callout_info}}
-A date of `0000-01-01` is displayed for all `TIME`/`TIMETZ` values, but is not stored in the database. To print without a date, you can cast the type to a `STRING`.
-
-A time zone offset of `+00:00` is also displayed for all `TIME` and [`TIMESTAMP`](timestamp.html) values, but is not stored in the database.
-{{site.data.alerts.end}}
-
-### `TIMETZ`
-
-To express a `TIMETZ` value with a time zone offset from UTC, you can add an offset to a `TIME` value. For example, `TIMETZ '10:10:10.555555-05:00'` offsets from UTC by -5.
-
-If no time zone is specified for a `TIMETZ` value, the `timezone` [session variable](show-vars.html#supported-variables) is used. For example, if you [set the `timezone`](set-vars.html#set-time-zone) for a session using `SET TIME ZONE -2`, and you define the `TIMETZ` as `TIMETZ '10:10:10.55'`, the value will be displayed with an offset of -2 from UTC.
-
-`TIMETZ` is not affected by session-scoped offsets (unlike [`TIMESTAMPTZ`](timestamp.html)). Time zone offsets only apply to values inserted after the offset has been set, and do not affect existing `TIMETZ` values, or `TIMETZ` values with a time zone offset specified.
-
-## Size
-
-A `TIME` column supports values up to 8 bytes in width, but the total storage size is likely to be larger due to CockroachDB metadata.
-
-A `TIMETZ` column supports values up to 12 bytes in width, but the total storage size is likely to be larger due to CockroachDB metadata.
-
-## Precision
-
- CockroachDB supports precision levels from 0 (seconds) to 6 (microseconds) for `TIME`/`TIMETZ` values. Precision in time values specifies the number of fractional digits retained in the seconds field. For example, specifying a `TIME` value as `TIME(3)` truncates the time precision to milliseconds. By default, `TIME`/`TIMETZ` values have a precision of 6 (microseconds).
-
-You can use an [`ALTER COLUMN ... SET DATA TYPE`](alter-column.html) statement to change the precision level of a `TIME`-typed column. If there is already a non-default precision level specified for the column, the precision level can only be changed to an equal or greater precision level. For an example, see [Create a table with a `TIME`-typed column, with precision](#create-a-table-with-a-time-typed-column-with-precision).
-
-## Examples
-
-### Create a table with a `TIME`-typed column
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE time (time_id INT PRIMARY KEY, time_val TIME);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM time;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
-+-------------+-----------+-------------+----------------+-----------------------+-----------+-----------+
-  time_id     | INT8      |    false    | NULL           |                       | {primary} |   false
-  time_val    | TIME      |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO time VALUES (1, TIME '05:40:00'), (2, TIME '05:41:39');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM time;
-~~~
-
-~~~
-  time_id |         time_val
-+---------+---------------------------+
-        1 | 0000-01-01 05:40:00+00:00
-        2 | 0000-01-01 05:41:39+00:00
-(2 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-The SQL shell displays the date and time zone due to the Go SQL driver it uses. Other client drivers may behave similarly. In such cases, however, the date and time zone are not relevant and are not stored in the database.
-{{site.data.alerts.end}}
-
-Comparing `TIME` values:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT (SELECT time_val FROM time WHERE time_id = 1) < (SELECT time_val FROM time WHERE time_id = 2);
-~~~
-
-~~~
-< (SELECT time_val FROM time WHERE time_id = 2);
-  ?column?
-+----------+
-    true
-(1 row)
-~~~
-
-### Create a table with a `TIME`-typed column, with precision
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE time (time_id INT PRIMARY KEY, time_val TIME(4));
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM time;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  time_id     | INT8      |    false    | NULL           |                       | {primary} |   false
-  time_val    | TIME(4)   |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO time VALUES (1, TIME '05:40:00.123456'), (2, TIME '05:41:39.12345');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM time;
-~~~
-
-~~~
-  time_id |            time_val
-----------+---------------------------------
-        1 | 0000-01-01 05:40:00.1235+00:00
-        2 | 0000-01-01 05:41:39.1235+00:00
-(2 rows)
-~~~
-
-To change the precision level of a column, you can use an [`ALTER COLUMN ... SET DATA TYPE`](alter-column.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE time ALTER COLUMN time_val SET DATA TYPE TIME(5);
-~~~
-
-~~~
-ALTER TABLE
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM time;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  time_id     | INT8      |    false    | NULL           |                       | {primary} |   false
-  time_val    | TIME(5)   |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-If a non-default precision level has already been specified, you cannot change the precision to a lower level.
-{{site.data.alerts.end}}
-
-In this case, the `time_val` column, which is of type `TIME(5)`, cannot be changed to a precision level below `5`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE time ALTER COLUMN time_val SET DATA TYPE TIME(3);
-~~~
-
-~~~
-ERROR: unimplemented: type conversion from TIME(5) to TIME(3) requires overwriting existing values which is not yet implemented
-SQLSTATE: 0A000
-~~~
-
-
-## Supported casting & conversion
-
-`TIME`/`TIMETZ` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`INTERVAL` | Converts to the span of time since midnight (00:00)
-`STRING` | Converts to format `'HH:MM:SS.SSSSSS'` (microsecond precision)
-
-{{site.data.alerts.callout_info}}
-CockroachDB displays `TIME '24:00:00'` and `TIMETZ '24:00:00'` as `0000-01-01 00:00:00`. To display the proper stored value (`24:00:00`), you can [cast the data type to a `STRING`](time.html#supported-casting-conversion).
-{{site.data.alerts.end}}
-
-## See also
-
-- [Data Types](data-types.html)
-- [SQL Feature Support](sql-feature-support.html)
diff --git a/src/current/v20.2/timestamp.md b/src/current/v20.2/timestamp.md
deleted file mode 100644
index a550947745c..00000000000
--- a/src/current/v20.2/timestamp.md
+++ /dev/null
@@ -1,246 +0,0 @@
----
-title: TIMESTAMP / TIMESTAMPTZ
-summary: The TIMESTAMP and TIMESTAMPTZ data types stores a date and time pair in UTC.
-toc: true
----
-
-The `TIMESTAMP` and `TIMESTAMPTZ` [data types](data-types.html) store a date and time pair in UTC.
-
-## Variants
-
-`TIMESTAMP` has two variants:
-
-- `TIMESTAMP` presents all `TIMESTAMP` values in UTC.
-
-- `TIMESTAMPTZ` converts `TIMESTAMP` values from UTC to the client's session time zone (unless another time zone is specified for the value). However, it is conceptually important to note that `TIMESTAMPTZ` **does not** store any time zone data.
-
-    {{site.data.alerts.callout_info}}
-    The default session time zone is UTC, which means that by default `TIMESTAMPTZ` values display in UTC.
-    {{site.data.alerts.end}}
-
-The difference between these two variants is that `TIMESTAMPTZ` uses the client's session [time zone](set-vars.html#set-time-zone), while the other simply does not. This behavior extends to functions like `now()` and `extract()` on `TIMESTAMPTZ` values.
-
-You can use the [`timezone()`](functions-and-operators.html#date-and-time-functions) and [`AT TIME ZONE`](functions-and-operators.html#special-syntax-forms) functions to convert a `TIMESTAMPTZ` into a `TIMESTAMP` at a specified timezone, or to convert a `TIMESTAMP` into a `TIMESTAMPTZ` at a specified timezone.
-
-## Best practices
-
-We recommend always using the `TIMESTAMPTZ` variant because the `TIMESTAMP` variant can sometimes lead to unexpected behaviors when it ignores a session offset. However, we also recommend you avoid [setting a session time zone offset](set-vars.html#set-time-zone) for your database.
-
-## Aliases
-
-In CockroachDB, the following are aliases:
-
-- `TIMESTAMP`, `TIMESTAMP WITHOUT TIME ZONE`
-- `TIMESTAMPTZ`, `TIMESTAMP WITH TIME ZONE`
-
-## Syntax
-
-A constant value of type `TIMESTAMP`/`TIMESTAMPTZ` can be expressed using an
-[interpreted literal](sql-constants.html#interpreted-literals), or a
-string literal
-[annotated with](scalar-expressions.html#explicitly-typed-expressions)
-type `TIMESTAMP`/`TIMESTAMPTZ` or
-[coerced to](scalar-expressions.html#explicit-type-coercions) type
-`TIMESTAMP`/`TIMESTAMPTZ`.
-
-`TIMESTAMP` constants can be expressed using the
-following string literal formats:
-
-Format | Example
--------|--------
-Date only | `TIMESTAMP '2016-01-25'`
-Date and Time | `TIMESTAMP '2016-01-25 10:10:10.555555'`
-ISO 8601 | `TIMESTAMP '2016-01-25T10:10:10.555555'`
-
-To express a `TIMESTAMPTZ` value (with time zone offset from UTC), use
-the following format: `TIMESTAMPTZ '2016-01-25 10:10:10.555555-05:00'`
-
-When it is unambiguous, a simple unannotated [string literal](sql-constants.html#string-literals) can also
-be automatically interpreted as type `TIMESTAMP` or `TIMESTAMPTZ`.
-
-Note that the fractional portion is optional and is rounded to
-microseconds (6 digits after decimal) for compatibility with the
-PostgreSQL wire protocol.
-
-<span class="version-tag">New in v20.2:</span> For PostgreSQL compatibility, CockroachDB bounds `TIMESTAMP` values by the lowest and highest `TIMESTAMP` values supported by PostgreSQL. The minimum allowable `TIMESTAMP` value is `4714-11-24 00:00:00+00 BC`, and the highest allowable `TIMESTAMP` value is `294276-12-31 23:59:59.999999`.
-
-{{site.data.alerts.callout_info}}
-A time zone offset of `+00:00` is displayed for all [`TIME`](time.html) and `TIMESTAMP` values, but is not stored in the database.
-{{site.data.alerts.end}}
-
-## Size
-
-A `TIMESTAMP`/`TIMESTAMPTZ` column supports values up to 12 bytes in width, but the total storage size is likely to be larger due to CockroachDB metadata.
-
-## Precision
-
- CockroachDB supports precision levels from 0 (seconds) to 6 (microseconds) for `TIMESTAMP`/`TIMESTAMPTZ` values. Precision in time values specifies the number of fractional digits retained in the seconds field. For example, specifying a `TIMESTAMPTZ` value as `TIMESTAMPTZ(3)` truncates the time component to milliseconds. By default, `TIMESTAMP`/`TIMESTAMPTZ` values have a precision of 6 (microseconds).
-
-You can use an [`ALTER COLUMN ... SET DATA TYPE`](alter-column.html) statement to change the precision level of a `TIMESTAMP`/`TIMESTAMPTZ`-typed column. If there is already a non-default precision level specified for the column, the precision level can only be changed to an equal or greater precision level. For an example, see [Create a table with a `TIMESTAMP`-typed column, with precision](#create-a-table-with-a-timestamp-typed-column-with-precision).
-
-## Examples
-
-### Create a table with a `TIMESTAMPTZ`-typed column
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE timestamps (a INT PRIMARY KEY, b TIMESTAMPTZ);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM timestamps;
-~~~
-
-~~~
-  column_name |  data_type  | is_nullable | column_default | generation_expression |  indices  | is_hidden
-+-------------+-------------+-------------+----------------+-----------------------+-----------+-----------+
-  a           | INT8        |    false    | NULL           |                       | {primary} |   false
-  b           | TIMESTAMPTZ |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO timestamps VALUES (1, TIMESTAMPTZ '2016-03-26 10:10:10-05:00'), (2, TIMESTAMPTZ '2016-03-26');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM timestamps;
-~~~
-
-~~~
-  a |             b
-+---+---------------------------+
-  1 | 2016-03-26 15:10:10+00:00
-  2 | 2016-03-26 00:00:00+00:00
-(2 rows)
-~~~
-
-### Create a table with a `TIMESTAMP`-typed column, with precision
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE timestamps (a INT PRIMARY KEY, b TIMESTAMP(3));
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM timestamps;
-~~~
-
-~~~
-  column_name |  data_type   | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+--------------+-------------+----------------+-----------------------+-----------+------------
-  a           | INT8         |    false    | NULL           |                       | {primary} |   false
-  b           | TIMESTAMP(3) |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO timestamps VALUES (1, TIMESTAMP '2020-03-25 12:00:00.123456'), (2, TIMESTAMP '2020-03-26 4:00:00.123456');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM timestamps;
-~~~
-
-~~~
-  a |               b
-----+--------------------------------
-  1 | 2020-03-25 12:00:00.123+00:00
-  2 | 2020-03-26 04:00:00.123+00:00
-(2 rows)
-~~~
-
-To change the precision level of a column, you can use an [`ALTER COLUMN ... SET DATA TYPE`](alter-column.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE timestamps ALTER COLUMN b SET DATA TYPE TIMESTAMP(4);
-~~~
-
-~~~
-ALTER TABLE
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM timestamps;
-~~~
-
-~~~
-  column_name |  data_type   | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+--------------+-------------+----------------+-----------------------+-----------+------------
-  a           | INT8         |    false    | NULL           |                       | {primary} |   false
-  b           | TIMESTAMP(4) |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-When changing precision level, `TIMESTAMP` can be changed to `TIMESTAMPTZ`, and `TIMESTAMPTZ` can be changed to `TIMESTAMP`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE timestamps ALTER COLUMN b SET DATA TYPE TIMESTAMPTZ(5);
-~~~
-
-~~~
-ALTER TABLE
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM timestamps;
-~~~
-
-~~~
-  column_name |   data_type    | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+----------------+-------------+----------------+-----------------------+-----------+------------
-  a           | INT8           |    false    | NULL           |                       | {primary} |   false
-  b           | TIMESTAMPTZ(5) |    true     | NULL           |                       | {}        |   false
-(2 rows)
-~~~
-
-{{site.data.alerts.callout_info}}
-If a non-default precision level has already been specified, you cannot change the precision to a lower level.
-{{site.data.alerts.end}}
-
-In this case, the `b` column, which is of type `TIMESTAMPTZ(5)`, cannot be changed to a precision level below `5`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE timestamps ALTER COLUMN b SET DATA TYPE TIMESTAMPTZ(3);
-~~~
-
-~~~
-ERROR: unimplemented: type conversion from TIMESTAMPTZ(5) to TIMESTAMPTZ(3) requires overwriting existing values which is not yet implemented
-SQLSTATE: 0A000
-~~~
-
-## Supported casting and conversion
-
-`TIMESTAMP` values can be [cast](data-types.html#data-type-conversions-and-casts) to any of the following data types:
-
-Type | Details
------|--------
-`DECIMAL` | Converts to number of seconds since the Unix epoch (Jan. 1, 1970).
-`FLOAT` | Converts to number of seconds since the Unix epoch (Jan. 1, 1970).
-`TIME` | Converts to the time portion (HH:MM:SS) of the timestamp.
-`INT` | Converts to number of seconds since the Unix epoch (Jan. 1, 1970).
-`DATE` | --
-`STRING` | <span class="version-tag">New in v20.2:</span> Converts to the date and time portion (YYYY-MM-DD HH:MM:SS) of the timestamp and omits the time zone offset.
-
-### Infinity `TIMESTAMP` casts
-
-CockroachDB currently does not support an `infinity`/`-infinity` representation for `TIMESTAMP` casts. Instead, `infinity::TIMESTAMP` evaluates to `294276-12-31 23:59:59.999999+00:00`, the maximum `TIMESTAMP` value supported, and `-infinity::TIMESTAMP` evaluates to `-4713-11-24 00:00:00+00:00`, the minimum `TIMESTAMP` value supported.
-
-Note that this behavior differs from PostgreSQL, for which `infinity` is higher than any allowable `TIMESTAMP` value (including `294276-12-31 23:59:59.999999+00:00`), and `-infinity` is lower than any allowable `TIMESTAMP` value (including `-4713-11-24 00:00:00+00:00`).
-
-For more details, see [tracking issue](https://github.com/cockroachdb/cockroach/issues/41564).
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/topology-basic-production.md b/src/current/v20.2/topology-basic-production.md
deleted file mode 100644
index 5576ee19f39..00000000000
--- a/src/current/v20.2/topology-basic-production.md
+++ /dev/null
@@ -1,89 +0,0 @@
----
-title: Basic Production Topology
-summary: Guidance for a single-region production deployment.
-toc: true
----
-
-When you're ready to run CockroachDB in production in a single region, it's important to deploy at least 3 CockroachDB nodes to take advantage of CockroachDB's automatic replication, distribution, rebalancing, and resiliency capabilities.  
-
-{{site.data.alerts.callout_success}}
-If you haven't already, [review the full range of topology patterns](topology-patterns.html) to ensure you choose the right one for your use case.
-{{site.data.alerts.end}}
-
-## Prerequisites
-
-{% include {{ page.version.version }}/topology-patterns/fundamentals.md %}
-
-## Configuration
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_basic_production1.png' | relative_url }}" alt="Basic production topology" style="max-width:100%" />
-
-1. Provision hardware as follows:
-    - 1 region with 3 AZs
-    - 3+ VMs evenly distributed across AZs; add more VMs to increase throughput
-    - App and load balancer in same region as VMs for CockroachDB
-        - The load balancer redirects to CockroachDB nodes in the region
-
-2. Start each node on a separate VM, setting the [`--locality`](cockroach-start.html#locality) flag to the node's region and AZ combination. For example, the following command starts a node in the east1 availability zone of the us-east region:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --locality=region=us-east,zone=east1 \
-    --certs-dir=certs \
-    --advertise-addr=<node1 internal address> \
-    --join=<node1 internal address>:26257,<node2 internal address>:26257,<node3 internal address>:26257 \        
-    --cache=.25 \
-    --max-sql-memory=.25 \
-    --background
-    ~~~
-
-With the default 3-way replication factor and `--locality` set as described above, CockroachDB balances each range of table data across AZs, one replica per AZ. System data is replicated 5 times by default and also balanced across AZs, thus increasing the [resiliency of the cluster](configure-replication-zones.html#create-a-replication-zone-for-a-system-range) as a whole.
-
-## Characteristics
-
-### Latency
-
-#### Reads
-
-Since all ranges, including leaseholder replicas, are in a single region, read latency is very low.
-
-For example, in the animation below:
-
-1. The read request reaches the load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the relevant leaseholder.
-4. The leaseholder retrieves the results and returns to the gateway node.
-5. The gateway node returns the results to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_basic_production_reads.png' | relative_url }}" alt="Basic production topology" style="max-width:100%" />
-
-#### Writes
-
-Since all ranges are in a single region, writes achieve consensus without leaving the region and, thus, write latency is very low as well.
-
-For example, in the animation below:
-
-1. The write request reaches the load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder replicas for the relevant table and secondary index.
-4. While each leaseholder appends the write to its Raft log, it notifies its follower replicas.
-5. In each case, 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 leaseholder and the write is committed on the agreeing replicas.
-6. The leaseholders then return acknowledgement of the commit to the gateway node.
-7. The gateway node returns the acknowledgement to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_basic_production_writes.gif' | relative_url }}" alt="Leaseholder preferences topology" style="max-width:100%" />
-
-### Resiliency
-
-Because each range is balanced across AZs, one AZ can fail without interrupting access to any data:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_basic_production_resiliency1.png' | relative_url }}" alt="Basic production topology" style="max-width:100%" />
-
-However, if an additional AZ fails at the same time, the ranges that lose consensus become unavailable for reads and writes:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_basic_production_resiliency2.png' | relative_url }}" alt="Basic production topology" style="max-width:100%" />
-
-## See also
-
-{% include {{ page.version.version }}/topology-patterns/see-also.md %}
diff --git a/src/current/v20.2/topology-development.md b/src/current/v20.2/topology-development.md
deleted file mode 100644
index 607a1e17256..00000000000
--- a/src/current/v20.2/topology-development.md
+++ /dev/null
@@ -1,39 +0,0 @@
----
-title: Development Topology
-summary: Guidance for a single-node cluster for local development.
-toc: true
----
-
-While developing an application against CockroachDB, it's sufficient to deploy a single-node cluster close to your test application, whether that's on a single VM or on your laptop.
-
-{{site.data.alerts.callout_success}}
-If you haven't already, [review the full range of topology patterns](topology-patterns.html) to ensure you choose the right one for your use case.
-{{site.data.alerts.end}}
-
-## Prerequisites
-
-{% include {{ page.version.version }}/topology-patterns/fundamentals.md %}
-
-## Configuration
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_development1.png' | relative_url }}" alt="Development topology" style="max-width:100%" />
-
-For this pattern, you can either [run CockroachDB locally](start-a-local-cluster.html) or [deploy a single-node cluster on a cloud VM](manual-deployment.html).
-
-## Characteristics
-
-### Latency
-
-With the CockroachDB node in the same region as your client, and without the overhead of replication, both read and write latency are very low:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_development_latency.png' | relative_url }}" alt="Development topology" style="max-width:100%" />
-
-### Resiliency
-
-In a single-node cluster, CockroachDB does not replicate data and, therefore, is not resilient to failures. If the machine where the node is running fails, or if the region or availability zone containing the machine fails, the cluster becomes unavailable:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_development2.png' | relative_url }}" alt="Development topology" style="max-width:100%" />
-
-## See also
-
-{% include {{ page.version.version }}/topology-patterns/see-also.md %}
diff --git a/src/current/v20.2/topology-duplicate-indexes.md b/src/current/v20.2/topology-duplicate-indexes.md
deleted file mode 100644
index 0da2b0275a9..00000000000
--- a/src/current/v20.2/topology-duplicate-indexes.md
+++ /dev/null
@@ -1,191 +0,0 @@
----
-title: Duplicate Indexes Topology
-summary: Guidance on using the duplicate indexes topology in a multi-region deployment.
-toc: true
----
-
-In a multi-region deployment, the duplicate indexes pattern is a good choice for tables with the following requirements:
-
-- Read latency must be low, but write latency can be much higher.
-- Reads must be up-to-date for business reasons or because the table is referenced by [foreign keys](foreign-key.html).
-- Rows in the table, and all latency-sensitive queries, **cannot** be tied to specific geographies.
-- Table data must remain available during a region failure.
-
-In general, this pattern is suited well for immutable/reference tables that are rarely or never updated.
-
-{% include_cached youtube.html video_id="xde_Oz-dJxM" %}
-
-{{site.data.alerts.callout_success}}
-**See It In Action** - Read about how a [financial software company](https://www.cockroachlabs.com/guides/banking-guide-to-the-cloud/) is using the Duplicate Indexes topology for low latency reads in their identity access management layer.
-{{site.data.alerts.end}}
-
-## Prerequisites
-
-### Fundamentals
-
-{% include {{ page.version.version }}/topology-patterns/fundamentals.md %}
-
-### Cluster setup
-
-{% include {{ page.version.version }}/topology-patterns/multi-region-cluster-setup.md %}
-
-## Configuration
-
-{{site.data.alerts.callout_info}}
-Pinning secondary indexes requires an [Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/).
-{{site.data.alerts.end}}
-
-### Summary
-
-Using this pattern, you tell CockroachDB to put the leaseholder for the table itself (also called the primary index) in one region, create 2 secondary indexes on the table, and tell CockroachDB to put the leaseholder for each secondary index in one of the other regions. This means that reads will access the local leaseholder (either for the table itself or for one of the secondary indexes). Writes, however, will still leave the region to get consensus for the table and its secondary indexes.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_duplicate_indexes1.png' | relative_url }}" alt="Duplicate Indexes topology" style="max-width:100%" />
-
-### Steps
-
-Assuming you have a [cluster deployed across three regions](#cluster-setup) and a table like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE postal_codes (
-    id INT PRIMARY KEY,
-    code STRING
-);
-~~~
-
-1. If you do not already have one, [request a trial Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/).
-
-2. [Create a replication zone](configure-zone.html) for the table and set a leaseholder preference telling CockroachDB to put the leaseholder for the table in one of the regions, for example `us-west`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE postal_codes
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-west":1}',
-          lease_preferences = '[[+region=us-west]]';
-    ~~~
-
-3. [Create secondary indexes](create-index.html) on the table for each of your other regions, including all of the columns you wish to read either in the key or in the key and a [`STORING`](create-index.html#store-columns) clause:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE INDEX idx_central ON postal_codes (id)
-        STORING (code);
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > CREATE INDEX idx_east ON postal_codes (id)
-        STORING (code);
-    ~~~
-
-4. [Create a replication zone](configure-zone.html) for each secondary index, in each case setting a leaseholder preference telling CockroachDB to put the leaseholder for the index in a distinct region:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX postal_codes@idx_central
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-central":1}',
-          lease_preferences = '[[+region=us-central]]';
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX postal_codes@idx_east
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-east":1}',
-          lease_preferences = '[[+region=us-east]]';
-    ~~~
-
-5. To confirm that replication zones are in effect, you can use the [`SHOW CREATE TABLE`](show-create.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW CREATE TABLE postal_codes;
-    ~~~
-
-    ~~~
-       table_name  |                              create_statement
-    +--------------+----------------------------------------------------------------------------+
-      postal_codes | CREATE TABLE postal_codes (
-                   |     id INT8 NOT NULL,
-                   |     code STRING NULL,
-                   |     CONSTRAINT "primary" PRIMARY KEY (id ASC),
-                   |     INDEX idx_central (id ASC) STORING (code),
-                   |     INDEX idx_east (id ASC) STORING (code),
-                   |     FAMILY "primary" (id, code)
-                   | );
-                   | ALTER TABLE defaultdb.public.postal_codes CONFIGURE ZONE USING
-                   |     num_replicas = 3,
-                   |     constraints = '{+region=us-west: 1}',
-                   |     lease_preferences = '[[+region=us-west]]';
-                   | ALTER INDEX defaultdb.public.postal_codes@idx_central CONFIGURE ZONE USING
-                   |     num_replicas = 3,
-                   |     constraints = '{+region=us-central: 1}',
-                   |     lease_preferences = '[[+region=us-central]]';
-                   | ALTER INDEX defaultdb.public.postal_codes@idx_east CONFIGURE ZONE USING
-                   |     num_replicas = 3,
-                   |     constraints = '{+region=us-east: 1}',
-                   |     lease_preferences = '[[+region=us-east]]'
-    (1 row)
-    ~~~
-
-## Characteristics
-
-### Latency
-
-#### Reads
-
-Reads access the local leaseholder and, therefore, never leave the region. This makes read latency very low.
-
-For example, in the animation below:
-
-1. The read request in `us-central` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the relevant leaseholder. In `us-west`, the leaseholder is for the table itself. In the other regions, the leaseholder is for the relevant index, which the [cost-based optimizer](cost-based-optimizer.html) uses due to the leaseholder preferences.
-4. The leaseholder retrieves the results and returns to the gateway node.
-5. The gateway node returns the results to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_duplicate_indexes_reads.png' | relative_url }}" alt="Pinned secondary indexes topology" style="max-width:100%" />
-
-#### Writes
-
-The replicas for the table and its secondary indexes are spread across all 3 regions, so writes involve multiple network hops across regions to achieve consensus. This increases write latency significantly. It's also important to understand that the replication of extra indexes can reduce throughput and increase storage cost.
-
-For example, in the animation below:
-
-1. The write request in `us-central` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder replicas for the table and its secondary indexes.
-4. While each leaseholder appends the write to its Raft log, it notifies its follower replicas.
-5. In each case, 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 leaseholder and the write is committed on the agreeing replicas.
-6. The leaseholders then return acknowledgement of the commit to the gateway node.
-7. The gateway node returns the acknowledgement to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_duplicate_indexes_writes.gif' | relative_url }}" alt="Duplicate Indexes topology" style="max-width:100%" />
-
-### Resiliency
-
-Because this pattern balances the replicas for the table and its secondary indexes across regions, one entire region can fail without interrupting access to the table:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_duplicate_indexes_resiliency.png' | relative_url }}" alt="Pinned Secondary Indexes topology" style="max-width:100%" />
-
-<!-- However, if an additional machine holding a replica for the table or any of its secondary indexes fails at the same time as the region failure, the range to which the replica belongs becomes unavailable for reads and writes:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_pinned_index_leaseholders3.png' | relative_url }}" alt="Pinned Secondary Indexes topology" style="max-width:100%" /> -->
-
-## Alternatives
-
-- If reads from a table can be historical (4.8 seconds or more in the past), consider the [Follower Reads](topology-follower-reads.html) pattern.
-- If rows in the table, and all latency-sensitive queries, can be tied to specific geographies, consider the [Geo-Partitioned Leaseholders](topology-geo-partitioned-leaseholders.html) pattern. Both patterns avoid extra secondary indexes, which increase data replication and, therefore, higher throughput and less storage.
-
-## Tutorial
-
-For a step-by-step demonstration of how this pattern gets you low-latency reads in a broadly distributed cluster, see the [Low Latency Multi-Region Deployment](demo-low-latency-multi-region-deployment.html) tutorial.
-
-## See also
-
-{% include {{ page.version.version }}/topology-patterns/see-also.md %}
diff --git a/src/current/v20.2/topology-follow-the-workload.md b/src/current/v20.2/topology-follow-the-workload.md
deleted file mode 100644
index 19b175875da..00000000000
--- a/src/current/v20.2/topology-follow-the-workload.md
+++ /dev/null
@@ -1,84 +0,0 @@
----
-title: Follow-the-Workload Topology
-summary: Guidance on using the follow-the-workload topology in a multi-region deployment.
-toc: true
----
-
-In a multi-region deployment, follow-the-workload is the default pattern for tables that use no other pattern. In general, this default pattern is a good choice only for tables with the following requirements:
-
-- The table is active mostly in one region at a time, e.g., following the sun.
-- In the active region, read latency must be low, but write latency can be higher.
-- In non-active regions, both read and write latency can be higher.
-- Table data must remain available during a region failure.
-
-{{site.data.alerts.callout_success}}
-If read performance is your main focus for a table, but you want low-latency reads everywhere instead of just in the most active region, consider the [Duplicate Indexes](topology-duplicate-indexes.html) or [Follower Reads](topology-follower-reads.html) pattern.
-{{site.data.alerts.end}}
-
-## Prerequisites
-
-### Fundamentals
-
-{% include {{ page.version.version }}/topology-patterns/fundamentals.md %}
-
-### Cluster setup
-
-{% include {{ page.version.version }}/topology-patterns/multi-region-cluster-setup.md %}
-
-## Configuration
-
-Aside from [deploying a cluster across three regions](#cluster-setup) properly, with each node started with the [`--locality`](cockroach-start.html#locality) flag specifying its region and AZ combination, this pattern requires no extra configuration. CockroachDB will balance the replicas for a table across the three regions and will assign the range lease to the replica in the region with the greatest demand at any given time (the follow-the-workload feature). This means that read latency in the active region will be low while read latency in other regions will be higher due to having to leave the region to reach the leaseholder. Write latency will be higher as well due to always involving replicas in multiple regions.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follower_reads1.png' | relative_url }}" alt="Follower reads topology" style="max-width:100%" />
-
-{{site.data.alerts.callout_info}}
-This pattern is also used by [system ranges containing important internal data](configure-replication-zones.html#create-a-replication-zone-for-a-system-range).
-{{site.data.alerts.end}}
-
-## Characteristics
-
-### Latency
-
-#### Reads
-
-Reads in the region with the most demand will access the local leaseholder and, therefore, never leave the region. This makes read latency very low in the currently most active region. Reads in other regions, however, will be routed to the leaseholder in a different region and, thus, read latency will be higher.
-
-For example, in the animation below, the most active region is `us-east` and, thus, the table's leaseholder is in that region:
-
-1. The read request in `us-east` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder replica.
-4. The leaseholder retrieves the results and returns to the gateway node.
-5. The gateway node returns the results to the client. In this case, reads in the `us-east` remain in the region and are lower-latency than reads in other regions.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follow_the_workload_reads.png' | relative_url }}" alt="Follow-the-workload topology" style="max-width:100%" />
-
-#### Writes
-
-The replicas for the table are spread across all 3 regions, so writes involve multiple network hops across regions to achieve consensus. This increases write latency significantly.
-
-For example, in the animation below, assuming the most active region is still `us-east`:
-
-1. The write request in `us-east` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder replica.
-4. While the leaseholder appends the write to its Raft log, it notifies its follower replicas.
-5. 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 leaseholder and the write is committed on the agreeing replicas.
-6. The leaseholders then return acknowledgement of the commit to the gateway node.
-7. The gateway node returns the acknowledgement to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follow_the_workload_writes.gif' | relative_url }}" alt="Follow-the-workload topology" style="max-width:100%" />
-
-### Resiliency
-
-Because this pattern balances the replicas for the table across regions, one entire region can fail without interrupting access to the table:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follower_reads_resiliency.png' | relative_url }}" alt="Follow-the-workload topology" style="max-width:100%" />
-
-<!-- However, if an additional machine holding a replica for the table fails at the same time as the region failure, the range to which the replica belongs becomes unavailable for reads and writes:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follower_reads3.png' | relative_url }}" alt="Follow-the-workload topology" style="max-width:100%" /> -->
-
-## See also
-
-{% include {{ page.version.version }}/topology-patterns/see-also.md %}
diff --git a/src/current/v20.2/topology-follower-reads.md b/src/current/v20.2/topology-follower-reads.md
deleted file mode 100644
index acb7b5c0318..00000000000
--- a/src/current/v20.2/topology-follower-reads.md
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: Follower Reads Topology
-summary: Guidance on using the follower reads topology in a multi-region deployment.
-toc: true
----
-
-In a multi-region deployment, the follower reads pattern is a good choice for tables with the following requirements:
-
-- Read latency must be low, but write latency can be higher.
-- Reads can be historical (4.8 seconds or more in the past).
-- Rows in the table, and all latency-sensitive queries, **cannot** be tied to specific geographies (e.g., a reference table).
-- Table data must remain available during a region failure.
-
-{{site.data.alerts.callout_success}}
-This pattern is compatible with all of the other multi-region patterns except [Geo-Partitioned Replicas](topology-geo-partitioned-replicas.html). However, if reads from a table must be exactly up-to-date, use the [Duplicate Indexes](topology-duplicate-indexes.html) or [Geo-Partitioned Leaseholders](topology-geo-partitioned-leaseholders.html) pattern instead. Up-to-date reads are required by tables referenced by [foreign keys](foreign-key.html), for example.
-{{site.data.alerts.end}}
-
-## Prerequisites
-
-### Fundamentals
-
-{% include {{ page.version.version }}/topology-patterns/fundamentals.md %}
-
-### Cluster setup
-
-{% include {{ page.version.version }}/topology-patterns/multi-region-cluster-setup.md %}
-
-## Configuration
-
-{{site.data.alerts.callout_info}}
-Follower reads requires an [Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/).
-{{site.data.alerts.end}}
-
-### Summary
-
-Using this pattern, you configure your application to use the [follower reads](follower-reads.html) feature by adding an `AS OF SYSTEM TIME` clause when reading from the table. This tells CockroachDB to read slightly historical data from the closest replica so as to avoid being routed to the leaseholder, which may be in an entirely different region. Writes, however, will still leave the region to get consensus for the table.
-
-### Steps
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follower_reads1.png' | relative_url }}" alt="Follower reads topology" style="max-width:100%" />
-
-Assuming you have a [cluster deployed across three regions](#cluster-setup) and a table like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE postal_codes (
-    id INT PRIMARY KEY,
-    code STRING
-);
-~~~
-
-Insert some data:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO postal_codes (ID, code) VALUES (1, '10001'), (2, '10002'), (3, '10003'), (4,'60601'), (5,'60602'), (6,'60603'), (7,'90001'), (8,'90002'), (9,'90003');
-~~~
-
-1. If you do not already have one, [request a trial Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/).
-
-2. Configure your app to use `AS OF SYSTEM TIME follower_read_timestamp()` whenever reading from the table:
-
-    {{site.data.alerts.callout_info}}
-    The `follower_read_timestamp()` [function](functions-and-operators.html) returns the [`TIMESTAMP`](timestamp.html) `statement_timestamp() - 4.8s`.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SELECT code FROM postal_codes
-        AS OF SYSTEM TIME follower_read_timestamp()
-                WHERE id = 5;
-    ~~~
-
-    Alternately, instead of modifying individual read queries on the table, you can set the `AS OF SYSTEM TIME` value for all operations in a read-only transaction:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > BEGIN;
-
-    SET TRANSACTION AS OF SYSTEM TIME follower_read_timestamp();
-
-      SELECT code FROM postal_codes
-        WHERE id = 5;
-
-      SELECT code FROM postal_codes
-        WHERE id = 6;
-
-      COMMIT;
-    ~~~
-
-{{site.data.alerts.callout_success}}
-Using the [`SET TRANSACTION`](set-transaction.html#use-the-as-of-system-time-option) statement as shown in the example above will make it easier to use the follower reads feature from [drivers and ORMs](install-client-drivers.html).
-{{site.data.alerts.end}}
-
-## Characteristics
-
-### Latency
-
-#### Reads
-
-Reads retrieve historical data from the closest replica and, therefore, never leave the region. This makes read latency very low but slightly stale.
-
-For example, in the animation below:
-
-1. The read request in `us-central` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the closest replica for the table. In this case, the replica is *not* the leaseholder.
-4. The replica retrieves the results as of 4.8 seconds in the past and returns to the gateway node.
-5. The gateway node returns the results to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follower_reads_reads.png' | relative_url }}" alt="Follower reads topology" style="max-width:100%" />
-
-#### Writes
-
-The replicas for the table are spread across all 3 regions, so writes involve multiple network hops across regions to achieve consensus. This increases write latency significantly.
-
-For example, in the animation below:
-
-1. The write request in `us-central` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder replica for the table in `us-east`.
-4. Once the leaseholder has appended the write to its Raft log, it notifies its follower replicas.
-5. 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 leaseholder and the write is committed on the agreeing replicas.
-6. The leaseholder then returns acknowledgement of the commit to the gateway node.
-7. The gateway node returns the acknowledgement to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follower_reads_writes.gif' | relative_url }}" alt="Follower reads topology" style="max-width:100%" />
-
-### Resiliency
-
-Because this pattern balances the replicas for the table across regions, one entire region can fail without interrupting access to the table:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follower_reads_resiliency.png' | relative_url }}" alt="Follower reads topology" style="max-width:100%" />
-
-<!-- However, if an additional machine holding a replica for the table fails at the same time as the region failure, the range to which the replica belongs becomes unavailable for reads and writes:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_follower_reads3.png' | relative_url }}" alt="Follower reads topology" style="max-width:100%" /> -->
-
-## See also
-
-{% include {{ page.version.version }}/topology-patterns/see-also.md %}
diff --git a/src/current/v20.2/topology-geo-partitioned-leaseholders.md b/src/current/v20.2/topology-geo-partitioned-leaseholders.md
deleted file mode 100644
index 7fa6b52262f..00000000000
--- a/src/current/v20.2/topology-geo-partitioned-leaseholders.md
+++ /dev/null
@@ -1,251 +0,0 @@
----
-title: Geo-Partitioned Leaseholders Topology
-summary: Common cluster topology patterns with setup examples and performance considerations.
-toc: true
----
-
-In a multi-region deployment, the geo-partitioned [leaseholders](architecture/replication-layer.html#leases) topology is a good choice for tables with the following requirements:
-
-- Read latency must be low, but write latency can be higher.
-- Reads must be up-to-date for business reasons or because the table is referenced by [foreign keys](foreign-key.html).
-- Rows in the table, and all latency-sensitive queries, can be tied to specific geographies, e.g., city, state, region.
-- Table data must remain available during a region failure.
-
-{{site.data.alerts.callout_success}}
-**See It In Action** - Read about how a [large telecom provider](https://www.cockroachlabs.com/case-studies/telecom-provider-replaces-amazon-aurora-with-cockroachdb-to-attain-analways-on-customer-experience/) with millions of customers across the United States is using the Geo-Partitioned Leaseholders topology in production for strong resiliency and performance.
-{{site.data.alerts.end}}
-
-## Prerequisites
-
-### Fundamentals
-
-{% include {{ page.version.version }}/topology-patterns/fundamentals.md %}
-
-### Cluster setup
-
-{% include {{ page.version.version }}/topology-patterns/multi-region-cluster-setup.md %}
-
-## Configuration
-
-{{site.data.alerts.callout_info}}
-Geo-partitioning requires an [Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/).
-{{site.data.alerts.end}}
-
-### Summary
-
-Using this pattern, you design your table schema to allow for [partitioning](partitioning.html#table-creation), with a column identifying geography as the first column in the table's compound primary key (e.g., city/id). You tell CockroachDB to partition the table and all of its secondary indexes by that geography column, each partition becoming its own range of 3 replicas. You then tell CockroachDB to put the leaseholder for each partition in the relevant region (e.g., LA partitions in `us-west`, NY partitions in `us-east`). The other replicas of a partition remain balanced across the other regions. This means that reads in each region will access local leaseholders and, therefore, will have low, intra-region latencies. Writes, however, will leave the region to get consensus and, therefore, will have higher, cross-region latencies.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioned_leaseholders1.png' | relative_url }}" alt="Geo-partitioned leaseholders topology" style="max-width:100%" />
-
-### Steps
-
-Assuming you have a [cluster deployed across three regions](#cluster-setup) and a table and secondary index like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-    id UUID NOT NULL DEFAULT gen_random_uuid(),
-    city STRING NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    address STRING NOT NULL,
-    PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX users_last_name_index ON users (city, last_name);
-~~~
-
-1. If you do not already have one, [request a trial Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/).
-
-2. Partition the table by `city`. For example, assuming there are three possible `city` values, `los angeles`, `chicago`, and `new york`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE users PARTITION BY LIST (city) (
-        PARTITION la VALUES IN ('los angeles'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION ny VALUES IN ('new york')
-    );
-    ~~~
-
-    This creates distinct ranges for each partition of the table.
-
-3. Partition the secondary index by `city` as well:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX users_last_name_index PARTITION BY LIST (city) (
-        PARTITION la VALUES IN ('los angeles'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION ny VALUES IN ('new york')
-    );
-    ~~~
-
-    This creates distinct ranges for each partition of the secondary index.
-
-4. For each partition of the table and its secondary index, [create a replication zone](configure-zone.html) that tells CockroachDB to put the partition's leaseholder in the relevant region:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION la OF INDEX users@*
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-west":1}',
-          lease_preferences = '[[+region=us-west]]';
-      ALTER PARTITION chicago OF INDEX users@*
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-central":1}',
-          lease_preferences = '[[+region=us-central]]';
-      ALTER PARTITION ny OF INDEX users@*
-        CONFIGURE ZONE USING
-          num_replicas = 3,
-          constraints = '{"+region=us-east":1}',
-          lease_preferences = '[[+region=us-east]]';
-      ~~~
-
-5. To confirm that partitions are in effect, you can use the [`SHOW CREATE TABLE`](show-create.html) or [`SHOW PARTITIONS`](show-partitions.html) statement:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW CREATE TABLE users;
-    ~~~
-
-    ~~~
-      table_name |                                          create_statement
-    +------------+----------------------------------------------------------------------------------------------------+
-      users      | CREATE TABLE users (
-                 |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-                 |     city STRING NOT NULL,
-                 |     first_name STRING NOT NULL,
-                 |     last_name STRING NOT NULL,
-                 |     address STRING NOT NULL,
-                 |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-                 |     INDEX users_last_name_index (city ASC, last_name ASC) PARTITION BY LIST (city) (
-                 |         PARTITION la VALUES IN (('los angeles')),
-                 |         PARTITION chicago VALUES IN (('chicago')),
-                 |         PARTITION ny VALUES IN (('new york'))
-                 |     ),
-                 |     FAMILY "primary" (id, city, first_name, last_name, address)
-                 | ) PARTITION BY LIST (city) (
-                 |     PARTITION la VALUES IN (('los angeles')),
-                 |     PARTITION chicago VALUES IN (('chicago')),
-                 |     PARTITION ny VALUES IN (('new york'))
-                 | );
-                 | ALTER PARTITION chicago OF INDEX defaultdb.public.users@primary CONFIGURE ZONE USING
-                 |     num_replicas = 3,
-                 |     constraints = '{+region=us-central: 1}',
-                 |     lease_preferences = '[[+region=us-central]]';
-                 | ALTER PARTITION la OF INDEX defaultdb.public.users@primary CONFIGURE ZONE USING
-                 |     num_replicas = 3,
-                 |     constraints = '{+region=us-west: 1}',
-                 |     lease_preferences = '[[+region=us-west]]';
-                 | ALTER PARTITION ny OF INDEX defaultdb.public.users@primary CONFIGURE ZONE USING
-                 |     num_replicas = 3,
-                 |     constraints = '{+region=us-east: 1}',
-                 |     lease_preferences = '[[+region=us-east]]';
-                 | ALTER PARTITION chicago OF INDEX defaultdb.public.users@users_last_name_index CONFIGURE ZONE USING
-                 |     num_replicas = 3,
-                 |     constraints = '{+region=us-central1: 1}',
-                 |     lease_preferences = '[[+region=us-central1]]';
-                 | ALTER PARTITION la OF INDEX defaultdb.public.users@users_last_name_index CONFIGURE ZONE USING
-                 |     num_replicas = 3,
-                 |     constraints = '{+region=us-west: 1}',
-                 |     lease_preferences = '[[+region=us-west]]';
-                 | ALTER PARTITION ny OF INDEX defaultdb.public.users@users_last_name_index CONFIGURE ZONE USING
-                 |     num_replicas = 3,
-                 |     constraints = '{+region=us-east: 1}',
-                 |     lease_preferences = '[[+region=us-east]]'
-    (1 row)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW PARTITIONS FROM TABLE users;
-    ~~~
-
-    ~~~
-      database_name | table_name | partition_name | parent_partition | column_names |         index_name          | partition_value |                  zone_config
-    +---------------+------------+----------------+------------------+--------------+-----------------------------+-----------------+-----------------------------------------------+
-      defaultdb     | users      | la             | NULL             | city         | users@primary               | ('los angeles') | num_replicas = 3,
-                    |            |                |                  |              |                             |                 | constraints = '{+region=us-west1: 1}',
-                    |            |                |                  |              |                             |                 | lease_preferences = '[[+region=us-west1]]'
-      defaultdb     | users      | chicago        | NULL             | city         | users@primary               | ('chicago')     | num_replicas = 3,
-                    |            |                |                  |              |                             |                 | constraints = '{+region=us-central1: 1}',
-                    |            |                |                  |              |                             |                 | lease_preferences = '[[+region=us-central1]]'
-      defaultdb     | users      | ny             | NULL             | city         | users@primary               | ('new york')    | num_replicas = 3,
-                    |            |                |                  |              |                             |                 | constraints = '{+region=us-east1: 1}',
-                    |            |                |                  |              |                             |                 | lease_preferences = '[[+region=us-east1]]'
-      defaultdb     | users      | la             | NULL             | city         | users@users_last_name_index | ('los angeles') | num_replicas = 3,
-                    |            |                |                  |              |                             |                 | constraints = '{+region=us-west1: 1}',
-                    |            |                |                  |              |                             |                 | lease_preferences = '[[+region=us-west1]]'
-      defaultdb     | users      | chicago        | NULL             | city         | users@users_last_name_index | ('chicago')     | num_replicas = 3,
-                    |            |                |                  |              |                             |                 | constraints = '{+region=us-central1: 1}',
-                    |            |                |                  |              |                             |                 | lease_preferences = '[[+region=us-central1]]'
-      defaultdb     | users      | ny             | NULL             | city         | users@users_last_name_index | ('new york')    | num_replicas = 3,
-                    |            |                |                  |              |                             |                 | constraints = '{+region=us-east1: 1}',
-                    |            |                |                  |              |                             |                 | lease_preferences = '[[+region=us-east1]]'
-    (6 rows)
-    ~~~
-
-{{site.data.alerts.callout_success}}
-As you scale and add more cities, you can repeat steps 2 and 3 with the new complete list of cities to re-partition the table and its secondary indexes, and then repeat step 4 to create replication zones for the new partitions.
-{{site.data.alerts.end}}
-
-{% include {{page.version.version}}/sql/crdb-internal-partitions.md %}
-
-## Characteristics
-
-### Latency
-
-#### Reads
-
-Because each partition's leaseholder is constrained to the relevant region (e.g., the `la` partitions' leaseholders are located in the `us-west` region), reads that specify the local region key access the relevant leaseholder locally. This makes read latency very low, with the exception of reads that do not specify a region key or that refer to a partition in another region.
-
-For example, in the animation below:
-
-1. The read request in `us-west` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder for the relevant partition.
-4. The leaseholder retrieves the results and returns to the gateway node.
-5. The gateway node returns the results to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioned_leaseholders_reads.png' | relative_url }}" alt="Geo-partitioned leaseholders topology" style="max-width:100%" />
-
-#### Writes
-
-Just like for reads, because each partition's leaseholder is constrained to the relevant region (e.g., the `la` partitions' leaseholders are located in the `us-west` region), writes that specify the local region key access the relevant leaseholder replicas locally. However, a partition's other replicas are spread across the other regions, so writes involve multiple network hops across regions to achieve consensus. This increases write latency significantly.
-
-For example, in the animation below:
-
-1. The write request in `us-west` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder replicas for the relevant table and secondary index partitions.
-4. While each leaseholder appends the write to its Raft log, it notifies its follower replicas, which are in the other regions.
-5. In each case, 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 leaseholder and the write is committed on the agreeing replicas.
-6. The leaseholders then return acknowledgement of the commit to the gateway node.
-7. The gateway node returns the acknowledgement to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioned_leaseholders_writes.gif' | relative_url }}" alt="Geo-partitioned leaseholders topology" style="max-width:100%" />
-
-### Resiliency
-
-Because this pattern balances the replicas for each partition across regions, one entire region can fail without interrupting access to any partitions. In this case, if any range loses its leaseholder in the region-wide outage, CockroachDB makes one of the range's other replicas the leaseholder:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioned_leaseholders_resiliency1.png' | relative_url }}" alt="Geo-partitioning topology" style="max-width:100%" />
-
-<!-- However, if an additional machine fails at the same time as the region failure, the partitions that lose consensus become unavailable for reads and writes:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioned_leaseholders_resiliency2.png' | relative_url }}" alt="Geo-partitioning topology" style="max-width:100%" /> -->
-
-## Alternatives
-
-- If reads from a table can be historical (4.8 seconds or more in the past), consider the [Follower Reads](topology-follower-reads.html) pattern.
-- If rows in the table, and all latency-sensitive queries, **cannot** be tied to specific geographies, consider the [Duplicate Indexes](topology-duplicate-indexes.html) pattern.
-
-## See also
-
-{% include {{ page.version.version }}/topology-patterns/see-also.md %}
diff --git a/src/current/v20.2/topology-geo-partitioned-replicas.md b/src/current/v20.2/topology-geo-partitioned-replicas.md
deleted file mode 100644
index 0f052107daf..00000000000
--- a/src/current/v20.2/topology-geo-partitioned-replicas.md
+++ /dev/null
@@ -1,224 +0,0 @@
----
-title: Geo-Partitioned Replicas Topology
-summary: Guidance on using the geo-partitioned replicas topology in a multi-region deployment.
-toc: true
----
-
-In a multi-region deployment, the geo-partitioned replicas topology is a good choice for tables with the following requirements:
-
-- Read and write latency must be low.
-- Rows in the table, and all latency-sensitive queries, can be tied to specific geographies, e.g., city, state, region.
-- Regional data must remain available during an AZ failure, but it's OK for regional data to become unavailable during a region-wide failure.
-
-{{site.data.alerts.callout_success}}
-**See It In Action** - Read about how an [electronic lock manufacturer](https://www.cockroachlabs.com/case-studies/european-electronic-lock-manufacturer-modernizes-iam-system-with-managed-cockroachdb/) and [multi-national bank](https://www.cockroachlabs.com/case-studies/top-five-multinational-bank-modernizes-its-european-core-banking-services-migrating-from-oracle-to-cockroachdb/) are using the Geo-Partitioned Replicas topology in production for improved performance and regulatory compliance.
-{{site.data.alerts.end}}
-
-## Prerequisites
-
-### Fundamentals
-
-{% include {{ page.version.version }}/topology-patterns/fundamentals.md %}
-
-### Cluster setup
-
-{% include {{ page.version.version }}/topology-patterns/multi-region-cluster-setup.md %}
-
-## Configuration
-
-{{site.data.alerts.callout_info}}
-Geo-partitioning requires an [Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/).
-{{site.data.alerts.end}}
-
-### Summary
-
-Using this pattern, you design your table schema to allow for [partitioning](partitioning.html#table-creation), with a column identifying geography as the first column in the table's compound primary key (e.g., city/id). You tell CockroachDB to partition the table and all of its secondary indexes by that geography column, each partition becoming its own range of 3 replicas. You then tell CockroachDB to pin each partition (all of its replicas) to the relevant region (e.g., LA partitions in `us-west`, NY partitions in `us-east`). This means that reads and writes in each region will always have access to the relevant replicas and, therefore, will have low, intra-region latencies.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioning1.png' | relative_url }}" alt="Geo-partitioning topology" style="max-width:100%" />
-
-### Steps
-
-Assuming you have a [cluster deployed across three regions](#cluster-setup) and a table and secondary index like the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE users (
-    id UUID NOT NULL DEFAULT gen_random_uuid(),
-    city STRING NOT NULL,
-    first_name STRING NOT NULL,
-    last_name STRING NOT NULL,
-    address STRING NOT NULL,
-    PRIMARY KEY (city ASC, id ASC)
-);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX users_last_name_index ON users (city, last_name);
-~~~
-
-{{site.data.alerts.callout_info}}
-A geo-partitioned table does not require a secondary index. However, if the table does have one or more secondary indexes, each index must be partitioned as well. This means that the indexes must start with the column identifying geography, like the table itself, which impacts the queries they'll be useful for. If you cannot partition all secondary indexes on a table you want to geo-partition, consider the [Geo-Partitioned Leaseholders](topology-geo-partitioned-leaseholders.html) pattern instead.
-{{site.data.alerts.end}}
-
-1. If you do not already have one, [request a trial Enterprise license](https://www.cockroachlabs.com/get-started-cockroachdb/).
-
-2. Partition the table by `city`. For example, assuming there are three possible `city` values, `los angeles`, `chicago`, and `new york`:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER TABLE users PARTITION BY LIST (city) (
-        PARTITION la VALUES IN ('los angeles'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION ny VALUES IN ('new york')
-    );
-    ~~~
-
-    This creates distinct ranges for each partition of the table.
-
-3. Partition the secondary index by `city` as well:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER INDEX users_last_name_index PARTITION BY LIST (city) (
-        PARTITION la VALUES IN ('los angeles'),
-        PARTITION chicago VALUES IN ('chicago'),
-        PARTITION ny VALUES IN ('new york')
-    );
-    ~~~
-
-    This creates distinct ranges for each partition of the secondary index.
-
-4. For each partition of the table and its secondary index, [create a replication zone](configure-zone.html) that constrains the partition's replicas to nodes in the relevant region:
-
-    {{site.data.alerts.callout_success}}
-    The `<table>@*` syntax lets you create zone configurations for all identically named partitions of a table, saving you multiple steps.
-    {{site.data.alerts.end}}
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > ALTER PARTITION la OF INDEX users@*
-        CONFIGURE ZONE USING constraints = '[+region=us-west]';
-      ALTER PARTITION chicago OF INDEX users@*
-        CONFIGURE ZONE USING constraints = '[+region=us-central]';
-      ALTER PARTITION ny OF INDEX users@*
-        CONFIGURE ZONE USING constraints = '[+region=us-east]';
-      ~~~
-
-5. To confirm that partitions are in effect, you can use the [`SHOW CREATE TABLE`](show-create.html) or [`SHOW PARTITIONS`](show-partitions.html) statement:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW CREATE TABLE users;
-    ~~~
-
-    ~~~
-      table_name |                                          create_statement
-    +------------+----------------------------------------------------------------------------------------------------+
-      users      | CREATE TABLE users (
-                 |     id UUID NOT NULL DEFAULT gen_random_uuid(),
-                 |     city STRING NOT NULL,
-                 |     first_name STRING NOT NULL,
-                 |     last_name STRING NOT NULL,
-                 |     address STRING NOT NULL,
-                 |     CONSTRAINT "primary" PRIMARY KEY (city ASC, id ASC),
-                 |     INDEX users_last_name_index (city ASC, last_name ASC) PARTITION BY LIST (city) (
-                 |         PARTITION la VALUES IN (('los angeles')),
-                 |         PARTITION chicago VALUES IN (('chicago')),
-                 |         PARTITION ny VALUES IN (('new york'))
-                 |     ),
-                 |     FAMILY "primary" (id, city, first_name, last_name, address)
-                 | ) PARTITION BY LIST (city) (
-                 |     PARTITION la VALUES IN (('los angeles')),
-                 |     PARTITION chicago VALUES IN (('chicago')),
-                 |     PARTITION ny VALUES IN (('new york'))
-                 | );
-                 | ALTER PARTITION chicago OF INDEX defaultdb.public.users@primary CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-central]';
-                 | ALTER PARTITION la OF INDEX defaultdb.public.users@primary CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-west]';
-                 | ALTER PARTITION ny OF INDEX defaultdb.public.users@primary CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-east]';
-                 | ALTER PARTITION chicago OF INDEX defaultdb.public.users@users_last_name_index CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-central]';
-                 | ALTER PARTITION la OF INDEX defaultdb.public.users@users_last_name_index CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-west]';
-                 | ALTER PARTITION ny OF INDEX defaultdb.public.users@users_last_name_index CONFIGURE ZONE USING
-                 |     constraints = '[+region=us-east]'
-    (1 row)
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SHOW PARTITIONS FROM TABLE users;
-    ~~~
-
-    ~~~
-      database_name | table_name | partition_name | parent_partition | column_names |         index_name          | partition_value |              zone_config
-    +---------------+------------+----------------+------------------+--------------+-----------------------------+-----------------+---------------------------------------+
-      defaultdb     | users      | la             | NULL             | city         | users@primary               | ('los angeles') | constraints = '[+region=us-west]'
-      defaultdb     | users      | chicago        | NULL             | city         | users@primary               | ('chicago')     | constraints = '[+region=us-central]'
-      defaultdb     | users      | ny             | NULL             | city         | users@primary               | ('new york')    | constraints = '[+region=us-east]'
-      defaultdb     | users      | la             | NULL             | city         | users@users_last_name_index | ('los angeles') | constraints = '[+region=us-west]'
-      defaultdb     | users      | chicago        | NULL             | city         | users@users_last_name_index | ('chicago')     | constraints = '[+region=us-central]'
-      defaultdb     | users      | ny             | NULL             | city         | users@users_last_name_index | ('new york')    | constraints = '[+region=us-east]'
-    (6 rows)
-    ~~~
-
-{{site.data.alerts.callout_success}}
-As you scale and add more cities, you can repeat steps 2 and 3 with the new complete list of cities to re-partition the table and its secondary indexes, and then repeat step 4 to create replication zones for the new partitions.
-{{site.data.alerts.end}}
-
-{% include {{page.version.version}}/sql/crdb-internal-partitions.md %}
-
-## Characteristics
-
-### Latency
-
-#### Reads
-
-Because each partition is constrained to the relevant region (e.g., the `la` partitions are located in the `us-west` region), reads that specify the local region key access the relevant leaseholder locally. This makes read latency very low, with the exception of reads that do not specify a region key or that refer to a partition in another region; such reads will be transactionally consistent but will not have local latencies.
-
-For example, in the animation below:
-
-1. The read request in `us-central` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder for the relevant partition.
-4. The leaseholder retrieves the results and returns to the gateway node.
-5. The gateway node returns the results to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioning_reads.png' | relative_url }}" alt="Geo-partitioning topology" style="max-width:100%" />
-
-#### Writes
-
-Just like for reads, because each partition is constrained to the relevant region (e.g., the `la` partitions are located in the `us-west` region), writes that specify the local region key access the relevant replicas without leaving the region. This makes write latency very low, with the exception of writes that do not specify a region key or that refer to a partition in another region; such writes will be transactionally consistent but will not have local latencies.
-
-For example, in the animation below:
-
-1. The write request in `us-central` reaches the regional load balancer.
-2. The load balancer routes the request to a gateway node.
-3. The gateway node routes the request to the leaseholder replicas for the relevant table and secondary index partitions.
-4. While each leaseholder appends the write to its Raft log, it notifies its follower replicas, which are in the same region.
-5. In each case, 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 leaseholder and the write is committed on the agreeing replicas.
-6. The leaseholders then return acknowledgement of the commit to the gateway node.
-7. The gateway node returns the acknowledgement to the client.
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioning_writes.gif' | relative_url }}" alt="Geo-partitioning topology" style="max-width:100%" />
-
-### Resiliency
-
-Because each partition is constrained to the relevant region and balanced across the 3 AZs in the region, one AZ can fail per region without interrupting access to the partitions in that region:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioning_resiliency1.png' | relative_url }}" alt="Geo-partitioning topology" style="max-width:100%" />
-
-However, if an entire region fails, the partitions in that region become unavailable for reads and writes, even if your load balancer can redirect requests to a different region:
-
-<img src="{{ 'images/v20.2/topology-patterns/topology_geo-partitioning_resiliency2.png' | relative_url }}" alt="Geo-partitioning topology" style="max-width:100%" />
-
-## Tutorial
-
-For a step-by-step demonstration of how this pattern gets you low-latency reads and writes in a broadly distributed cluster, see the [Low Latency Multi-Region Deployment](demo-low-latency-multi-region-deployment.html) tutorial.
-
-## See also
-
-{% include {{ page.version.version }}/topology-patterns/see-also.md %}
diff --git a/src/current/v20.2/topology-patterns.md b/src/current/v20.2/topology-patterns.md
deleted file mode 100644
index 2be18b25f33..00000000000
--- a/src/current/v20.2/topology-patterns.md
+++ /dev/null
@@ -1,45 +0,0 @@
----
-title: Topology Patterns
-summary: Recommended topology patterns for running CockroachDB in a cloud environment.
-toc: true
-key: cluster-topology-patterns.html
----
-
-This section provides recommended topology patterns for running CockroachDB in a cloud environment, each with required configurations and latency and resiliency characteristics.
-
-{{site.data.alerts.callout_info}}
-You can observe latency patterns for your cluster on the [Network Latency page](ui-network-latency-page.html) of the DB Console.
-{{site.data.alerts.end}}
-
-## Single-region patterns
-
-When your clients are in a single geographic region, choosing a topology is straightforward.
-
-Pattern | Latency | Resiliency | Configuration
---------|---------|------------|--------------
-[Development](topology-development.html) | <ul><li>Fast reads and writes</li></ul> | <ul><li>None</li></ul> | <ul><li>1 node</li><li>No replication</li></ul>
-[Basic Production](topology-basic-production.html) | <ul><li>Fast reads and writes</li></ul> | <ul><li>1 AZ failure</li></ul> | <ul><li>1 region</li><li>3 AZs</li><li>3+ nodes across AZs</li></ul>
-
-## Multi-region patterns
-
-When your clients are in multiple geographic regions, it is important to deploy your cluster across regions properly and then carefully choose the right topology for each of your tables. Not doing so can result in unexpected latency and resiliency.
-
-{{site.data.alerts.callout_info}}
-Multi-region patterns are almost always table-specific. For example, you might use the [Geo-Partitioning Replicas](topology-geo-partitioned-replicas.html) pattern for frequently updated tables that are geographically specific and the [Duplicate Indexes](topology-duplicate-indexes.html) pattern for reference tables that are not tied to geography and that are read frequently but updated infrequently.
-{{site.data.alerts.end}}
-
-Pattern | Latency | Resiliency | Configuration
---------|---------|------------|--------------
-[Geo-Partitioned Replicas](topology-geo-partitioned-replicas.html) | <ul><li>Fast regional reads and writes</li></ul> | <ul><li>1 AZ failure per partition</li></ul> | <ul><li>Geo-partitioned table</li><li>Partition replicas pinned to regions</li></ul>
-[Geo-Partitioned Leaseholders](topology-geo-partitioned-leaseholders.html) | <ul><li>Fast regional reads</li><li>Slower cross-region writes</li></ul> | <ul><li>1 region failure</li></ul> | <ul><li>Geo-partitioned table</li><li>Partition replicas spread across regions</li><li>Partition leaseholders pinned to regions</li></ul>
-[Duplicate Indexes](topology-duplicate-indexes.html) | <ul><li>Fast regional reads (current)</li><li>Much slower cross-region writes</li></ul> | <ul><li>1 region failure</li></ul> | <ul><li>Multiple identical indexes</li><li>Index replicas spread across regions</li><li>Index leaseholders pinned to regions</li></ul>
-[Follower Reads](topology-follower-reads.html) | <ul><li>Fast regional reads (historical)</li><li>Slower cross-region writes</li></ul> | <ul><li>1 region failure</li></ul> | <ul><li>App configured to use follower reads</li></ul>
-[Follow-the-Workload](topology-follow-the-workload.html) | <ul><li>Fast regional reads (active region)</li><li>Slower cross-region reads (elsewhere)</li><li>Slower cross-region writes</li> | <ul><li>1 region failure</li></ul> | <ul><li>None</li></ul>
-
-## Anti-patterns
-
-The following anti-patterns are ineffective or risky:
-
-- Single-region deployments using 2 AZs, or multi-region deployments using 2 regions. In these cases, the cluster would be unable to survive the loss of a single AZ or a single region, respectively.
-- Broadly distributed multi-region deployments (e.g., `us-west`, `asia`, and `europe`) using only the default [Follow-the-Workload](topology-follow-the-workload.html) pattern. In this case, latency will likely be unacceptably high.
-- [Geo-partitioned tables](topology-geo-partitioned-replicas.html) with non-partitioned secondary indexes. In this case, writes will incur cross-region latency to achieve consensus on the non-partitioned indexes.
diff --git a/src/current/v20.2/transaction-retry-error-reference.md b/src/current/v20.2/transaction-retry-error-reference.md
deleted file mode 100644
index 28d61428b2a..00000000000
--- a/src/current/v20.2/transaction-retry-error-reference.md
+++ /dev/null
@@ -1,283 +0,0 @@
----
-title: Transaction Retry Error Reference
-summary: A list of the transaction retry (serialization) errors emitted by CockroachDB, including likely causes and user actions for mitigation.
-toc: true
----
-
-This page has a list of the transaction retry error codes emitted by CockroachDB.
-
-Transaction retry errors use the `SQLSTATE` error code `40001`, and emit error messages with the string `restart transaction`. The most common transaction retry errors are also known as serialization errors. Serialization errors indicate that a transaction failed because it could not be placed into a [serializable ordering](demo-serializable.html) among all of the currently-executing transactions.
-
-The failure to place a transaction into a serializable ordering usually happens due to a [transaction conflict](architecture/transaction-layer.html#transaction-conflicts) with another concurrent or recent transaction that is trying to write to the same data. When multiple transactions are trying to write to the same data, this state is also known as contention. When serialization errors occur due to contention, the transaction needs to be retried by the client as described in [client-side retry handling](transactions.html#client-side-intervention).
-
-In less common cases, transaction retry errors are not caused by contention, but by the internal state of the CockroachDB cluster. For example, the cluster could be overloaded. In such cases, other actions may need to be taken above and beyond client-side retries.
-
-See below for a complete list of retry error codes. For each error code, we describe:
-
-- Why the error is happening.
-- What to do about it.
-
-This page is meant to provide information about specific transaction retry error codes to make troubleshooting easier. In most cases, the correct actions to take when these errors occur are:
-
-1. Update your app to retry on serialization errors (where `SQLSTATE` is `40001`), as described in [client-side retry handling](transactions.html#client-side-intervention).
-
-2. Design your schema and queries to reduce contention. For more information about how contention occurs and how to avoid it, see [Understanding and avoiding transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). In particular, if you are able to [send all of the statements in your transaction in a single batch](transactions.html#batched-statements), CockroachDB can usually automatically retry the entire transaction for you.
-
-3. Use historical reads with [`SELECT ... AS OF SYSTEM TIME`](as-of-system-time.html).
-
-4. In some cases, [`SELECT FOR UPDATE`](select-for-update.html) can also be used to reduce the occurrence of serialization errors.
-
-5. [High priority transactions](transactions.html#transaction-priorities) are less likely to experience serialization errors than low priority transactions. Adjusting transaction priorities usually does not change how many serialization errors occur, but it can help control which transactions experience them.
-
-{{site.data.alerts.callout_info}}
-Note that your application's retry logic does not need to distinguish between the different types of serialization errors. They are listed here for reference during advanced troubleshooting.
-{{site.data.alerts.end}}
-
-## Overview
-
-CockroachDB always attempts to find a [serializable ordering](demo-serializable.html) among all of the currently-executing transactions.
-
-Whenever possible, CockroachDB will [auto-retry a transaction internally](transactions.html#automatic-retries) without notifying the client. CockroachDB will only send a serialization error to the client when it cannot resolve the error automatically without client-side intervention.
-
-In other words, by the time a serialization error bubbles up to the client, CockroachDB has already tried to handle the error internally, and could not.
-
-The main reason why CockroachDB cannot auto-retry every serialization error without sending an error to the client is that the SQL language is "conversational" by design. The client can send arbitrary statements to the server during a transaction, receive some results, and then decide to issue other arbitrary statements inside the same transaction based on the server's response.
-
-Suppose that the client is [a Java application using JDBC](build-a-java-app-with-cockroachdb.html), or an analyst typing [`BEGIN`](begin-transaction.html) directly to [a SQL shell](cockroach-sql.html). In either case, the client is free to issue a `BEGIN`, wait an arbitrary amount of time, and issue additional statements. Meanwhile, other transactions are being processed by the system, potentially writing to the same data.
-
-This "conversational" design means that there is no way for the server to always retry the arbitrary statements sent so far inside an open transaction. If there are different results for any given statement than there were at an earlier point in the currently open transaction's lifetime (likely due to the operations of other, concurrently-executing transactions), CockroachDB must defer to the client to decide how to handle that situation. This is why we recommend [keeping transactions as small as possible](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-
-## Error reference
-
-- [RETRY_WRITE_TOO_OLD](#retry_write_too_old)
-- [RETRY_SERIALIZABLE](#retry_serializable)
-- [RETRY_ASYNC_WRITE_FAILURE](#retry_async_write_failure)
-- [ReadWithinUncertaintyInterval](#readwithinuncertaintyinterval)
-- [RETRY_COMMIT_DEADLINE_EXCEEDED](#retry_commit_deadline_exceeded)
-- [ABORT_REASON_ABORTED_RECORD_FOUND](#abort_reason_aborted_record_found)
-- [ABORT_REASON_CLIENT_REJECT](#abort_reason_client_reject)
-- [ABORT_REASON_PUSHER_ABORTED](#abort_reason_pusher_aborted)
-- [ABORT_REASON_ABORT_SPAN](#abort_reason_abort_span)
-- [ABORT_REASON_NEW_LEASE_PREVENTS_TXN](#abort_reason_new_lease_prevents_txn)
-- [ABORT_REASON_TIMESTAMP_CACHE_REJECTED](#abort_reason_timestamp_cache_rejected)
-
-### RETRY_WRITE_TOO_OLD
-
-```
-TransactionRetryWithProtoRefreshError: ... RETRY_WRITE_TOO_OLD ...
-```
-
-_Description_:
-
-The `RETRY_WRITE_TOO_OLD` error occurs when a transaction _A_ tries to write to a row _R_, but another transaction _B_ that was supposed to be serialized after _A_ (i.e., had been assigned a higher timestamp), has already written to that row _R_, and has already committed. This is a common error when you have too much contention in your workload.
-
-_Action_:
-
-1. Retry transaction _A_ as described in [client-side retry handling](transactions.html#client-side-intervention).
-2. Design your schema and queries to reduce contention. For more information about how contention occurs and how to avoid it, see [Understanding and avoiding transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). In particular, if you are able to [send all of the statements in your transaction in a single batch](transactions.html#batched-statements), CockroachDB can usually automatically retry the entire transaction for you.
-
-### RETRY_SERIALIZABLE
-
-```
-TransactionRetryWithProtoRefreshError: ... RETRY_SERIALIZABLE ...
-```
-
-_Description_:
-
-The `RETRY_SERIALIZABLE` error occurs in the following cases:
-
-1. When a transaction _A_ has its timestamp moved forward (also known as _A_ being "pushed") as CockroachDB attempts to find a serializable transaction ordering. Specifically, transaction _A_ tried to write a key that transaction _B_ had already read, and _B_ was supposed to be serialized after _A_ (i.e., _B_ had a higher timestamp than _A_). CockroachDB will try to serialize _A_ after _B_ by changing _A_'s timestamp, but it cannot do that when another transaction has subsequently written to some of the keys that _A_ has read and returned to the client. When that happens, the `RETRY_SERIALIZATION` error is signalled. For more information about how timestamp pushes work in our transaction model, see the [architecture docs on the transaction layer's timestamp cache](architecture/transaction-layer.html).
-
-2. When a [high-priority transaction](transactions.html#transaction-priorities) _A_ does a read that runs into a write intent from another lower-priority transaction _B_, and some other transaction _C_ writes to a key that _B_ has already read. Transaction _B_ will get this error when it tries to commit, because _A_ has already read some of the data touched by _B_ and returned results to the client, and _C_ has written data previously read by _B_.
-
-3. When a transaction _A_ is forced to refresh (i.e., change its timestamp) due to hitting the maximum _closed timestamp_ interval (closed timestamps enable [Follower Reads](follower-reads.html#how-follower-reads-work) and [Change Data Capture (CDC)](stream-data-out-of-cockroachdb-using-changefeeds.html)). This can happen when transaction _A_ is a long-running transaction, and there is a write by another transaction to data that _A_ has already read. If this is the cause of the error, the solution is to increase the `kv.closed_timestamp.target_duration` setting to a higher value. Unfortunately, there is no indication from this error code that a too-low closed timestamp setting is the issue. Therefore, you may need to rule out cases 1 and 2 (or experiment with increasing the closed timestamp interval, if that is possible for your application - see the note below).
-
-_Action_:
-
-1. If you encounter case 1 or 2 above, the solution is to:
-   1. Retry transaction _A_ as described in [client-side retry handling](transactions.html#client-side-intervention).
-   2. Design your schema and queries to reduce contention. For more information about how contention occurs and how to avoid it, see [Understanding and avoiding transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). In particular, if you are able to [send all of the statements in your transaction in a single batch](transactions.html#batched-statements), CockroachDB can usually automatically retry the entire transaction for you.
-   3. Use historical reads with [`SELECT ... AS OF SYSTEM TIME`](as-of-system-time.html).
-
-2. If you encounter case 3 above, the solution is to:
-   1. Increase the `kv.closed_timestamp.target_duration` setting to a higher value. As described above, this will impact the freshness of data available via [Follower Reads](follower-reads.html) and [CDC changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html).
-   2. Retry transaction _A_ as described in [client-side retry handling](transactions.html#client-side-intervention).
-   3. Design your schema and queries to reduce contention. For more information about how contention occurs and how to avoid it, see [Understanding and avoiding transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). In particular, if you are able to [send all of the statements in your transaction in a single batch](transactions.html#batched-statements), CockroachDB can usually automatically retry the entire transaction for you.
-   3. Use historical reads with [`SELECT ... AS OF SYSTEM TIME`](as-of-system-time.html).
-
-{{site.data.alerts.callout_info}}
-If you increase the `kv.closed_timestamp.target_duration` setting, it means that you are increasing the amount of time by which the data available in [Follower Reads](follower-reads.html) and [CDC changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html) lags behind the current state of the cluster. In other words, there is a trade-off here: if you absolutely must execute long-running transactions that execute concurrently with other transactions that are writing to the same data, you may have to settle for longer delays on Follower Reads and/or CDC to avoid frequent serialization errors. The anomaly that would be exhibited if these transactions were not retried is called [write skew](https://www.cockroachlabs.com/blog/what-write-skew-looks-like/).
-{{site.data.alerts.end}}
-
-### RETRY_ASYNC_WRITE_FAILURE
-
-```
-TransactionRetryWithProtoRefreshError: ... RETRY_ASYNC_WRITE_FAILURE ...
-```
-
-_Description_:
-
-The `RETRY_ASYNC_WRITE_FAILURE` error occurs when some kind of problem with your cluster's operation occurs at the moment of a previous write in the transaction, causing CockroachDB to fail to replicate one of the transaction's writes. For example, this can happen if you have a networking partition that cuts off access to some nodes in your cluster.
-
-_Action_:
-
-1. Retry the transaction as described in [client-side retry handling](transactions.html#client-side-intervention). This is worth doing because the problem with the cluster is likely to be transient.
-2. Investigate the problems with your cluster.  For cluster troubleshooting information, see [Troubleshoot Cluster Setup](cluster-setup-troubleshooting.html).
-
-### ReadWithinUncertaintyInterval
-
-```
-TransactionRetryWithProtoRefreshError: ReadWithinUncertaintyIntervalError:
-        read at time 1591009232.376925064,0 encountered previous write with future timestamp 1591009232.493830170,0 within uncertainty interval `t <= 1591009232.587671686,0`;
-        observed timestamps: [{1 1591009232.587671686,0} {5 1591009232.376925064,0}]
-```
-
-_Description_:
-
-The `ReadWithinUncertaintyIntervalError` can occur when two transactions which start on different gateway nodes attempt to operate on the same data at close to the same time, and one of the operations is a write. The uncertainty comes from the fact that we cannot tell which one started first - the clocks on the two gateway nodes may not be perfectly in sync.
-
-For example, if the clock on node _A_ is ahead of the clock on node _B_, a transaction started on node _A_ may be able to commit a write with a timestamp that is still in the "future" from the perspective of node _B_. A later transaction that starts on node _B_ should be able to see the earlier write from node _A_, even if _B_'s clock has not caught up to _A_. The "read within uncertainty interval" occurs if we discover this situation in the middle of a transaction, when it is too late for the database to handle it automatically. When node _B_'s transaction retries, it will unambiguously occur after the transaction from node _A_.
-
-{{site.data.alerts.callout_info}}
-This behavior is non-deterministic: it depends on which node is the [leaseholder](architecture/life-of-a-distributed-transaction.html#leaseholder-node) of the underlying data range. It’s generally a sign of contention. Uncertainty errors are always possible with near-realtime reads under contention.
-{{site.data.alerts.end}}
-
-_Action_:
-
-The solution is to do one of the following:
-
-1. Be prepared to retry on uncertainty (and other) errors, as described in [client-side retry handling](transactions.html#client-side-intervention).
-2. Use historical reads with [`SELECT ... AS OF SYSTEM TIME`](as-of-system-time.html).
-3. Design your schema and queries to reduce contention. For more information about how contention occurs and how to avoid it, see [Understanding and avoiding transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). In particular, if you are able to [send all of the statements in your transaction in a single batch](transactions.html#batched-statements), CockroachDB can usually automatically retry the entire transaction for you.
-4. If you [trust your clocks](operational-faqs.html#what-happens-when-node-clocks-are-not-properly-synchronized), you can try lowering the [`--max-offset` option to `cockroach start`](cockroach-start.html#flags), which provides an upper limit on how long a transaction can continue to restart due to uncertainty.
-
-{{site.data.alerts.callout_info}}
-Uncertainty errors are a form of transaction conflict. For more information about transaction conflicts, see [Transaction conflicts](architecture/transaction-layer.html#transaction-conflicts).
-{{site.data.alerts.end}}
-
-### RETRY_COMMIT_DEADLINE_EXCEEDED
-
-```
-TransactionRetryWithProtoRefreshError: TransactionPushError: transaction deadline exceeded ...
-```
-
-_Description_:
-
-The `RETRY_COMMIT_DEADLINE_EXCEEDED` error means that the transaction timed out due to being pushed by other concurrent transactions. This error is most likely to happen to long-running transactions. The conditions that trigger this error are very similar to the conditions that lead to a [`RETRY_SERIALIZABLE`](#retry_serializable) error, except that a transaction that hits this error got pushed for several minutes, but did not hit any of the conditions that trigger a `RETRY_SERIALIZABLE` error. In other words, the conditions that trigger this error are a subset of those that trigger `RETRY_SERIALIZABLE`, and that this transaction ran for too long (several minutes).
-
-{{site.data.alerts.callout_info}}
-Read-only transactions do not get pushed, so they do not run into this error.
-{{site.data.alerts.end}}
-
-This error occurs in the cases described below.
-
-1. When a transaction _A_ has its timestamp moved forward (also known as _A_ being "pushed") as CockroachDB attempts to find a serializable transaction ordering. Specifically, transaction _A_ tried to write a key that transaction _B_ had already read. _B_ was supposed to be serialized after _A_ (i.e., _B_ had a higher timestamp than _A_). CockroachDB will try to serialize _A_ after _B_ by changing _A_'s timestamp.
-
-2. When a [high-priority transaction](transactions.html#transaction-priorities) _A_ does a read that runs into a write intent from another lower-priority transaction _B_. Transaction _B_ may get this error when it tries to commit, because _A_ has already read some of the data touched by _B_ and returned results to the client.
-
-3. When a transaction _A_ is forced to refresh (change its timestamp) due to hitting the maximum _closed timestamp_ interval (closed timestamps enable [Follower Reads](follower-reads.html#how-follower-reads-work) and [Change Data Capture (CDC)](stream-data-out-of-cockroachdb-using-changefeeds.html)). This can happen when transaction _A_ is a long-running transaction, and there is a write by another transaction to data that _A_ has already read.
-
-_Action_:
-
-1. The `RETRY_COMMIT_DEADLINE_EXCEEDED` error is one case where the standard advice to add a retry loop to your application may not be advisable. A transaction that runs for long enough to get pushed beyond its deadline is quite likely to fail again on retry for the same reasons. Therefore, the best thing to do in this case is to shrink the running time of your transactions so they complete more quickly and do not hit the deadline.
-2. If you encounter case 3 above, you can increase the `kv.closed_timestamp.target_duration` setting to a higher value. Unfortunately, there is no indication from this error code that a too-low closed timestamp setting is the issue. Therefore, you may need to rule out cases 1 and 2 (or experiment with increasing the closed timestamp interval, if that is possible for your application - see the note below).
-
-{{site.data.alerts.callout_info}}
-If you increase the `kv.closed_timestamp.target_duration` setting, it means that you are increasing the amount of time by which the data available in [Follower Reads](follower-reads.html) and [CDC changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html) lags behind the current state of the cluster. In other words, there is a trade-off here: if you absolutely must execute long-running transactions that execute concurrently with other transactions that are writing to the same data, you may have to settle for longer delays on Follower Reads and/or CDC to avoid frequent serialization errors. The anomaly that would be exhibited if these transactions were not retried is called [write skew](https://www.cockroachlabs.com/blog/what-write-skew-looks-like/).
-{{site.data.alerts.end}}
-
-### ABORT_REASON_ABORTED_RECORD_FOUND
-
-```
-TransactionRetryWithProtoRefreshError:TransactionAbortedError(ABORT_REASON_ABORTED_RECORD_FOUND) ...
-```
-
-_Description_:
-
-The `ABORT_REASON_ABORTED_RECORD_FOUND` error means that the client application is trying to use a transaction that has been aborted. This happens in one of the following cases:
-
-- Write-write conflict: Another [high-priority transaction](transactions.html#transaction-priorities) _B_ encountered a write intent by our transaction _A_, and tried to push _A_'s timestamp.
-- Cluster overload: _B_ thinks that _A_'s transaction coordinator node is dead, because the coordinator node hasn't heartbeated the transaction record for a few seconds.
-- Deadlock: Some transaction _B_ is trying to acquire conflicting locks in reverse order from transaction _A_.
-
-_Action_:
-
-If you are encountering deadlocks:
-
-- Avoid producing deadlocks in your application by making sure that transactions acquire locks in the same order.
-
-If you are using only default [transaction priorities](transactions.html#transaction-priorities):
-
-- This error means your cluster has problems. You are likely overloading it. Investigate the source of the overload, and do something about it. For more information, see [Node liveness issues](cluster-setup-troubleshooting.html#node-liveness-issues).
-
-If you are using [high- or low-priority transactions](transactions.html#transaction-priorities):
-
-- Update your app to retry on serialization errors (where `SQLSTATE` is `40001`), as described in [client-side retry handling](transactions.html#client-side-intervention).
-- Design your schema and queries to reduce contention. For more information about how contention occurs and how to avoid it, see [Understanding and avoiding transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention). In particular, if you are able to [send all of the statements in your transaction in a single batch](transactions.html#batched-statements), CockroachDB can usually automatically retry the entire transaction for you.
-
-### ABORT_REASON_CLIENT_REJECT
-
-```
-TransactionRetryWithProtoRefreshError:TransactionAbortedError(ABORT_REASON_CLIENT_REJECT) ...
-```
-
-_Description_:
-
-The `ABORT_REASON_CLIENT_REJECT` error is caused by the same conditions as the [`ABORT_REASON_ABORTED_RECORD_FOUND`](#abort_reason_aborted_record_found), and requires the same actions. The errors are fundamentally the same, except that they are discovered at different points in the process.
-
-### ABORT_REASON_PUSHER_ABORTED
-
-```
-TransactionRetryWithProtoRefreshError:TransactionAbortedError(ABORT_REASON_PUSHER_ABORTED) ...
-```
-
-_Description_:
-
-The `ABORT_REASON_PUSHER_ABORTED` error is caused by the same conditions as the [`ABORT_REASON_ABORTED_RECORD_FOUND`](#abort_reason_aborted_record_found), and requires the same actions. The errors are fundamentally the same, except that they are discovered at different points in the process.
-
-### ABORT_REASON_ABORT_SPAN
-
-```
-TransactionRetryWithProtoRefreshError:TransactionAbortedError(ABORT_REASON_ABORT_SPAN) ...
-```
-
-_Description_:
-
-The `ABORT_REASON_ABORT_SPAN` error is caused by the same conditions as the [`ABORT_REASON_ABORTED_RECORD_FOUND`](#abort_reason_aborted_record_found), and requires the same actions. The errors are fundamentally the same, except that they are discovered at different points in the process.
-
-### ABORT_REASON_NEW_LEASE_PREVENTS_TXN
-
-```
-TransactionRetryWithProtoRefreshError:TransactionAbortedError(ABORT_REASON_NEW_LEASE_PREVENTS_TXN) ...
-```
-
-_Description_:
-
-The `ABORT_REASON_NEW_LEASE_PREVENTS_TXN` error occurs because the timestamp cache will not allow transaction _A_ to create a transaction record. A new lease wipes the timestamp cache, so this could mean the [leaseholder](architecture/life-of-a-distributed-transaction.html#leaseholder-node) was moved and the duration of transaction _A_ was unlucky enough to happen across a lease acquisition. In other words, leaseholders got shuffled out from underneath transaction _A_ (due to no fault of the client application or schema design), and now it has to be retried.
-
-_Action_:
-
-Retry transaction _A_ as described in [client-side retry handling](transactions.html#client-side-intervention).
-
-### ABORT_REASON_TIMESTAMP_CACHE_REJECTED
-
-```
-TransactionRetryWithProtoRefreshError:TransactionAbortedError(ABORT_REASON_TIMESTAMP_CACHE_REJECTED) ...
-```
-
-_Description_:
-
-The `ABORT_REASON_TIMESTAMP_CACHE_REJECTED` error occurs when the timestamp cache will not allow transaction _A_ to create a transaction record. This can happen due to a [range merge](architecture/distribution-layer.html#range-merges) happening in the background, or because the timestamp cache is an in-memory cache, and has outgrown its memory limit (about 64 MB).
-
-_Action_:
-
-Retry transaction _A_ as described in [client-side retry handling](transactions.html#client-side-intervention).
-
-## See also
-
-- [Common Errors](common-errors.html)
-- [Transactions](transactions.html)
-- [Client-side retry handling](transactions.html#client-side-intervention)
-- [Understanding and avoiding transaction contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention)
-- [DB Console Transactions Page](ui-transactions-page.html)
-- [Architecture - Transaction Layer](architecture/transaction-layer.html)
diff --git a/src/current/v20.2/transactions.md b/src/current/v20.2/transactions.md
deleted file mode 100644
index 0e66a8e6fb9..00000000000
--- a/src/current/v20.2/transactions.md
+++ /dev/null
@@ -1,277 +0,0 @@
----
-title: Transactions
-summary: CockroachDB supports bundling multiple SQL statements into a single all-or-nothing transaction.
-toc: true
----
-
-CockroachDB supports bundling multiple SQL statements into a single all-or-nothing transaction. Each transaction guarantees [ACID semantics](https://en.wikipedia.org/wiki/ACID) spanning arbitrary tables and rows, even when data is distributed. If a transaction succeeds, all mutations are applied together with virtual simultaneity. If any part of a transaction fails, the entire transaction is aborted, and the database is left unchanged. CockroachDB guarantees that while a transaction is pending, it is isolated from other concurrent transactions with serializable [isolation](#isolation-levels).
-
-{{site.data.alerts.callout_info}}
-For a detailed discussion of CockroachDB transaction semantics, see [How CockroachDB Does Distributed Atomic Transactions](https://www.cockroachlabs.com/blog/how-cockroachdb-distributes-atomic-transactions/) and [Serializable, Lockless, Distributed: Isolation in CockroachDB](https://www.cockroachlabs.com/blog/serializable-lockless-distributed-isolation-cockroachdb/). Note that the explanation of the transaction model described in this blog post is slightly out of date. See the [Transaction Retries](#transaction-retries) section for more details.
-{{site.data.alerts.end}}
-
-## SQL statements
-
-Each of the following SQL statements control transactions in some way.
-
-| Statement                                            | Function                                                                                                                                                                 |
-|------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [`BEGIN`](begin-transaction.html)                    | Initiate a transaction, as well as control its [priority](#transaction-priorities).                                                                                      |
-| [`SET TRANSACTION`](set-transaction.html)            | Control a transaction's [priority](#transaction-priorities).                                                                                                             |
-| [`COMMIT`](commit-transaction.html)                  | Commit a regular transaction, or clear the connection after committing a transaction using the [advanced retry protocol](advanced-client-side-transaction-retries.html). |
-| [`ROLLBACK`](rollback-transaction.html)              | Abort a transaction and roll the database back to its state before the transaction began.                                                                                |
-| [`SHOW`](show-vars.html)                             | Display the current transaction settings.                                                                                                                                |
-| [`SAVEPOINT`](savepoint.html)                        | Used for [nested transactions](#nested-transactions); also used to implement [advanced client-side transaction retries](advanced-client-side-transaction-retries.html).  |
-| [`RELEASE SAVEPOINT`](release-savepoint.html)        | Commit a [nested transaction](#nested-transactions); also used for [retryable transactions](advanced-client-side-transaction-retries.html).                             |
-| [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html) | Roll back a [nested transaction](#nested-transactions); also used to handle [retryable transaction errors](advanced-client-side-transaction-retries.html).              |
-
-{{site.data.alerts.callout_info}}
-Application developers who are using a framework or library that does not have [advanced retry logic](advanced-client-side-transaction-retries.html) built in should implement an application-level retry loop with exponential backoff as shown in [Client-side intervention](#client-side-intervention).
-{{site.data.alerts.end}}
-
-## Syntax
-
-In CockroachDB, a transaction is set up by surrounding SQL statements with the [`BEGIN`](begin-transaction.html) and [`COMMIT`](commit-transaction.html) statements.
-
-To use [advanced client-side transaction retries](advanced-client-side-transaction-retries.html), you should also include the [`SAVEPOINT`](savepoint.html), [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html) and [`RELEASE SAVEPOINT`](release-savepoint.html) statements.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-
-> SAVEPOINT cockroach_restart;
-
-<transaction statements>
-
-> RELEASE SAVEPOINT cockroach_restart;
-
-> COMMIT;
-~~~
-
-At any time before it's committed, you can abort the transaction by executing the [`ROLLBACK`](rollback-transaction.html) statement.
-
-Clients using transactions must also include logic to handle [retries](#transaction-retries).
-
-## Error handling
-
-To handle errors in transactions, you should check for the following types of server-side errors:
-
-Type | Description
------|------------
-**Retry Errors** | Errors with the code `40001` or string `retry transaction`, which indicate that a transaction failed because it could not be placed in a serializable ordering of transactions by CockroachDB. This is often due to contention: conflicts with another concurrent or recent transaction accessing the same data. In such cases, the transaction needs to be retried by the client as described in [client-side intervention](#client-side-intervention).  For a reference listing all of the retry error codes emitted by CockroachDB, see the [Transaction Retry Error Reference](transaction-retry-error-reference.html).
-**Ambiguous Errors** | Errors with the code `40003` which indicate that the state of the transaction is ambiguous, i.e., you cannot assume it either committed or failed. How you handle these errors depends on how you want to resolve the ambiguity. For information about how to handle ambiguous errors, see [here](common-errors.html#result-is-ambiguous).
-**SQL Errors** | All other errors, which indicate that a statement in the transaction failed. For example, violating the `UNIQUE` constraint generates a `23505` error. After encountering these errors, you can either issue a [`COMMIT`](commit-transaction.html) or [`ROLLBACK`](rollback-transaction.html) to abort the transaction and revert the database to its state before the transaction began.<br><br>If you want to attempt the same set of statements again, you must begin a completely new transaction.
-
-## Transaction retries
-
-Transactions may require retries if they experience deadlock or [read/write contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention) with other concurrent transactions which cannot be resolved without allowing potential [serializable anomalies](https://en.wikipedia.org/wiki/Serializability).
-
-{% include {{page.version.version}}/misc/mitigate-contention-note.md %}
-
-There are two cases in which transaction retries occur:
-
-1. [Automatic retries](#automatic-retries), which CockroachDB processes for you.
-2. [Client-side intervention](#client-side-intervention), which your application must handle.
-
-### Automatic retries
-
-CockroachDB automatically retries individual statements (implicit transactions) and transactions sent from the client as a single batch, as long as the size of the results being produced for the client, including protocol overhead, is less than 16KiB by default. Once that buffer overflows, CockroachDB starts streaming results back to the client, at which point automatic retries cannot be performed any more. As long as the results of a single statement or batch of statements are known to stay clear of this limit, the client does not need to worry about transaction retries.
-
-{{site.data.alerts.callout_success}}
-You can change the results buffer size for all new sessions using the `sql.defaults.results_buffer.size` [cluster setting](cluster-settings.html), or for a specific session using the `results_buffer_size` [session variable](set-vars.html). Note, however, that decreasing the buffer size can increase the number of transaction retry errors a client receives, whereas increasing the buffer size can increase the delay until the client receives the first result row.
-{{site.data.alerts.end}}
-
-In future versions of CockroachDB, we plan on providing stronger guarantees for read-only queries that return at most one row, regardless of the size of that row.
-
-#### Individual statements
-
-Individual statements are treated as implicit transactions, and so they fall
-under the rules described above. If the results are small enough, they will be
-automatically retried. In particular, `INSERT/UPDATE/DELETE` statements without
-a `RETURNING` clause are guaranteed to have minuscule result sizes.
-For example, the following statement would be automatically retried by CockroachDB:
-
-~~~ sql
-> DELETE FROM customers WHERE id = 1;
-~~~
-
-#### Batched statements
-
-Transactions can be sent from the client as a single batch. Batching implies that CockroachDB receives multiple statements without being asked to return results in between them; instead, CockroachDB returns results after executing all of the statements, except when the accumulated results overflow the buffer mentioned above, in which case they are returned sooner and automatic retries can no longer be performed.
-
-Batching is generally controlled by your driver or client's behavior. Technically, it can be achieved in two ways, both supporting automatic retries:
-
-1. When the client/driver is using the [PostgreSQL Extended Query protocol](https://www.postgresql.org/docs/10/static/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY), a batch is made up of all queries sent in between two `Sync` messages. Many drivers support such batches through explicit batching constructs. 
-
-2. When the client/driver is using the [PostgreSQL Simple Query protocol](https://www.postgresql.org/docs/10/static/protocol-flow.html#id-1.10.5.7.4), a batch is made up of semicolon-separated strings sent as a unit to CockroachDB. For example, in Go, this code would send a single batch (which would be automatically retried):
-
-    ~~~ go
-    db.Exec(
-      "BEGIN;
-
-      DELETE FROM customers WHERE id = 1;
-
-      DELETE orders WHERE customer = 1;
-
-      COMMIT;"
-    )
-    ~~~
-
-{{site.data.alerts.callout_info}}
-Within a batch of statements, CockroachDB infers that the statements are not
-conditional on the results of previous statements, so it can retry all of them.
-Of course, if the transaction relies on conditional logic (e.g., statement 2 is
-executed only for some results of statement 1), then the transaction cannot be
-all sent to CockroachDB as a single batch. In these common cases, CockroachDB
-cannot retry, say, statement 2 in isolation. Since results for statement 1 have
-already been delivered to the client by the time statement 2 is forcing the
-transaction to retry, the client needs to be involved in retrying the whole
-transaction and so you should write your transactions to use
-[client-side intervention](#client-side-intervention).
-{{site.data.alerts.end}}
-
-### Client-side intervention
-
-Your application should include client-side retry handling when the statements are sent individually, such as:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> BEGIN;
-
-> UPDATE products SET inventory = 0 WHERE sku = '8675309';
-
-> INSERT INTO orders (customer, status) VALUES (1, 'new');
-
-> COMMIT;
-~~~
-
-To indicate that a transaction must be retried, CockroachDB signals an error with the code `40001` and an error message that begins with the string `"retry transaction"`.  For a complete list of transaction retry error codes, see [Transaction retry error reference](transaction-retry-error-reference.html).
-
-To handle these types of errors, you have the following options:
-
-- If your database library or framework provides a method for retryable transactions (it will often be documented as a tool for handling deadlocks), use it.
-- If you're building an application in the following languages, Cockroach Labs has created adapters that include automatic retry handling:
-   - **Go** developers using [GORM](https://github.com/jinzhu/gorm) or [pgx](https://github.com/jackc/pgx) can use the [`github.com/cockroachdb/cockroach-go/crdb`](https://github.com/cockroachdb/cockroach-go/tree/master/crdb) package. For an example, see [Build a Go App with CockroachDB](build-a-go-app-with-cockroachdb.html).
-   - **Python** developers using [SQLAlchemy](https://www.sqlalchemy.org) can use the [`sqlalchemy-cockroachdb` adapter](https://github.com/cockroachdb/sqlalchemy-cockroachdb). For an example, see [Build a Python App with CockroachDB and SQLAlchemy](build-a-python-app-with-cockroachdb-sqlalchemy.html).
-   - **Ruby (ActiveRecord)** developers can use the [`activerecord-cockroachdb-adapter`](https://rubygems.org/gems/activerecord-cockroachdb-adapter). For an example, see [Build a Ruby App with CockroachDB and ActiveRecord](build-a-ruby-app-with-cockroachdb-activerecord.html).
-- If you're building an application with another driver or data access framework that is [supported by CockroachDB](third-party-database-tools.html), we recommend reusing the retry logic in our ["Simple CRUD" Example Apps](example-apps.html). For example, **Java** developers accessing the database with [JDBC](https://jdbc.postgresql.org) can reuse the example code implementing retry logic shown in [Build a Java app with CockroachDB](build-a-java-app-with-cockroachdb.html).
-- If you're building an application with a language and framework for which we do not provide example retry logic, you might need to write your own retry logic. For an example, see the [Client-side intervention example](#client-side-intervention-example).
-- **Advanced users, such as library authors**: See [Advanced Client-Side Transaction Retries](advanced-client-side-transaction-retries.html).
-
-{% include {{page.version.version}}/misc/mitigate-contention-note.md %}
-
-#### Client-side intervention example
-
-{% include {{page.version.version}}/misc/client-side-intervention-example.md %}
-
-## Transaction contention
-
-Transactions in CockroachDB lock data resources that are written during their execution. When a pending write from one transaction conflicts with a write of a concurrent transaction, the concurrent transaction must wait for the earlier transaction to complete before proceeding. When a dependency cycle is detected between transactions, the transaction with the higher priority aborts the dependent transaction to avoid deadlock, which must be [retried](#client-side-intervention).
-
-For more details about transaction contention and best practices for avoiding contention, see [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-
-## Nested transactions
-
-CockroachDB supports the nesting of transactions using [savepoints](savepoint.html).  These nested transactions are also known as sub-transactions.  Nested transactions can be rolled back without discarding the state of the entire surrounding transaction.
-
-This can be useful in applications that abstract database access using an application development framework or [ORM](install-client-drivers.html).  Different components of the application can operate on different sub-transactions without having to know about each others' internal operations, while trusting that the database will maintain isolation between sub-transactions and preserve data integrity.
-
-Just as [`COMMIT`](commit-transaction.html) and [`ROLLBACK`](rollback-transaction.html) are used to commit and discard entire transactions, respectively, [`RELEASE SAVEPOINT`](release-savepoint.html) and [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html#rollback-a-nested-transaction) are used to commit and discard nested transactions.  This relationship is shown in the table below:
-
-| Statement                                                                          | Effect                                                |
-|------------------------------------------------------------------------------------+-------------------------------------------------------|
-| [`COMMIT`](commit-transaction.html)                                                | Commit an entire transaction.                         |
-| [`ROLLBACK`](rollback-transaction.html)                                            | Discard an entire transaction.                        |
-| [`RELEASE SAVEPOINT`](release-savepoint.html)                                      | Commit (really, forget) the named nested transaction. |
-| [`ROLLBACK TO SAVEPOINT`](rollback-transaction.html#rollback-a-nested-transaction) | Discard the changes in the named nested transaction.  |
-
-For more information, including examples showing how to use savepoints to create nested transactions, see [the savepoints documentation](savepoint.html#examples).
-
-## Transaction priorities
-
-Every transaction in CockroachDB is assigned an initial **priority**. By default, the transaction priority is `NORMAL`, but for transactions that should be given higher (or lower) preference in [high-contention scenarios](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention), you can set the priority in the [`BEGIN`](begin-transaction.html) statement:
-
-~~~ sql
-> BEGIN PRIORITY <LOW | NORMAL | HIGH>;
-~~~
-
-You can also set the priority immediately after a transaction is started:
-
-~~~ sql
-> SET TRANSACTION PRIORITY <LOW | NORMAL | HIGH>;
-~~~
-
-<span class="version-tag">New in v20.2:</span> To set the default transaction priority for all transactions in a session, use the `default_transaction_priority` [session variable](set-vars.html). For example:
-
-~~~ sql
-> SET default_transaction_priority = 'high';
-~~~
-
-To see the current priority of a transaction, use [`SHOW TRANSACTION PRIORITY`](show-vars.html) or `SHOW transaction_priority`:
-
-~~~ sql
-> SHOW transaction_priority;
-~~~
-
-~~~
-  transaction_priority
-------------------------
-  high
-~~~
-
-~~~ sql
-> SHOW TRANSACTION PRIORITY;
-~~~
-
-~~~
-  transaction_priority
-------------------------
-  high
-~~~
-
-Note that `transaction_priority` is a read-only [session variable](show-vars.html) that cannot be set directly.
-
-{{site.data.alerts.callout_info}}
-When two transactions contend for the same resources indirectly, they may create a dependency cycle leading to a deadlock situation, where both transactions are waiting on the other to finish. In these cases, CockroachDB allows the transaction with higher priority to abort the other, which must then retry. On retry, the transaction inherits the higher priority. This means that each retry makes a transaction more likely to succeed in the event it again experiences deadlock.
-{{site.data.alerts.end}}
-
-## Isolation levels
-
-CockroachDB executes all transactions at the strongest ANSI transaction isolation level: `SERIALIZABLE`. All other ANSI transaction isolation levels (e.g., `SNAPSHOT`, `READ UNCOMMITTED`, `READ COMMITTED`, and `REPEATABLE READ`) are automatically upgraded to `SERIALIZABLE`. Weaker isolation levels have historically been used to maximize transaction throughput. However, [recent research](http://www.bailis.org/papers/acidrain-sigmod2017.pdf) has demonstrated that the use of weak isolation levels results in substantial vulnerability to concurrency-based attacks.
-
-{{site.data.alerts.callout_info}}
-For a detailed discussion of isolation in CockroachDB transactions, see [Serializable, Lockless, Distributed: Isolation in CockroachDB](https://www.cockroachlabs.com/blog/serializable-lockless-distributed-isolation-cockroachdb/).
-{{site.data.alerts.end}}
-
-#### Serializable isolation
-
-With `SERIALIZABLE` isolation, a transaction behaves as though it has the entire database all to itself for the duration of its execution. This means that no concurrent writers can affect the transaction unless they commit before it starts, and no concurrent readers can be affected by the transaction until it has successfully committed. This is the strongest level of isolation provided by CockroachDB and it's the default.
-
-`SERIALIZABLE` isolation permits no anomalies. To prevent [write skew](https://en.wikipedia.org/wiki/Snapshot_isolation) anomalies, `SERIALIZABLE` isolation may require transaction restarts. For a demonstration of `SERIALIZABLE` preventing write skew, see [Serializable Transactions](demo-serializable.html).
-
-### Comparison to ANSI SQL isolation levels
-
-CockroachDB uses slightly different isolation levels than [ANSI SQL isolation levels](https://en.wikipedia.org/wiki/Isolation_(database_systems)#Isolation_levels).
-
-#### Aliases
-
-`SNAPSHOT`, `READ UNCOMMITTED`, `READ COMMITTED`, and `REPEATABLE READ` are aliases for `SERIALIZABLE`.
-
-#### Comparison
-
-The CockroachDB `SERIALIZABLE` level is stronger than the ANSI SQL `READ UNCOMMITTED`, `READ COMMITTED`, and `REPEATABLE READ` levels and equivalent to the ANSI SQL `SERIALIZABLE` level.
-
-For more information about the relationship between these levels, see [A Critique of ANSI SQL Isolation Levels](https://arxiv.org/ftp/cs/papers/0701/0701157.pdf).
-
-## See also
-
-- [`BEGIN`](begin-transaction.html)
-- [`COMMIT`](commit-transaction.html)
-- [`ROLLBACK`](rollback-transaction.html)
-- [`SAVEPOINT`](savepoint.html)
-- [`RELEASE SAVEPOINT`](release-savepoint.html)
-- [`SHOW`](show-vars.html)
-- [Retryable transaction example code in Java using JDBC](build-a-java-app-with-cockroachdb.html)
-- [DB Console Transactions Page](ui-transactions-page.html)
-- [CockroachDB Architecture: Transaction Layer](architecture/transaction-layer.html)
-- [Transaction retry error reference](transaction-retry-error-reference.html)
diff --git a/src/current/v20.2/troubleshooting-overview.md b/src/current/v20.2/troubleshooting-overview.md
deleted file mode 100644
index 67ad8194a55..00000000000
--- a/src/current/v20.2/troubleshooting-overview.md
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: Troubleshooting Overview
-summary: Initial steps to take if you run in to issues with CockroachDB.
-toc: false
----
-
-If you run into issues with CockroachDB, there are a few initial steps you can always take:
-
-1. Check your [logs](debug-and-error-logs.html) for errors related to your issue.
-    - Logs are generated on a per-node basis, so you must either identify the node where the issue occurred or [collect the logs from all active nodes in your cluster](cockroach-debug-zip.html).
-    - Alternately, you can [stop](cockroach-quit.html) and [restart](cockroach-start.html) problematic nodes with the `--logtostderr` flag to print logs to your terminal through `stderr`, letting you see all cluster activities as it occurs.
-
-2. Check our list of [common errors](common-errors.html) for a solution.  If you are getting transaction retry errors, see [client-side retry handling](transactions.html#client-side-intervention) and the [Transaction Retry Error Reference](transaction-retry-error-reference.html).
-
-3. If the problem doesn't match a common error, try the following pages:
-    - [Troubleshoot Cluster Setup](cluster-setup-troubleshooting.html) helps start your cluster and scale it by adding nodes.
-    - [Troubleshoot Query Behavior](query-behavior-troubleshooting.html) helps with unexpected query results.
-
-4. If you cannot resolve the issue easily yourself, the following tools can help you get unstuck:
-    - [Support Resources](support-resources.html) identifies ways you can get help with troubleshooting.
-    - [File an Issue](file-an-issue.html) provides details about filing issues that you're unable to resolve.
diff --git a/src/current/v20.2/truncate.md b/src/current/v20.2/truncate.md
deleted file mode 100644
index 0ca1a1e3db7..00000000000
--- a/src/current/v20.2/truncate.md
+++ /dev/null
@@ -1,160 +0,0 @@
----
-title: TRUNCATE
-summary: The TRUNCATE statement deletes all rows from specified tables.
-toc: true
----
-
-The `TRUNCATE` [statement](sql-statements.html) removes all rows from a table. At a high level, it works by dropping the table and recreating a new table with the same name.
-
-{% include {{{ page.version.version }}/misc/schema-change-stmt-note.md %}
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/truncate.html %}
-</div>
-
-## Required privileges
-
-The user must have the `DROP` [privilege](authorization.html#assign-privileges) on the table.
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table to truncate.
-`CASCADE` | Truncate all tables with [Foreign Key](foreign-key.html) dependencies on the table being truncated.<br><br>`CASCADE` does not list dependent tables it truncates, so should be used cautiously.
-`RESTRICT`    | _(Default)_ Do not truncate the table if any other tables have [Foreign Key](foreign-key.html) dependencies on it.
-
-## Limitations
-
-`TRUNCATE` is a schema change, and as such is not transactional. For more information about how schema changes work, see [Online Schema Changes](online-schema-changes.html).
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-### Truncate a table (no foreign key dependencies)
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1;
-~~~
-
-~~~
-+----+------+
-| id | name |
-+----+------+
-|  1 | foo  |
-|  2 | bar  |
-+----+------+
-(2 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> TRUNCATE t1;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM t1;
-~~~
-
-~~~
-+----+------+
-| id | name |
-+----+------+
-+----+------+
-(0 rows)
-~~~
-
-### Truncate a table and dependent tables
-
-In these examples, the `orders` table has a [Foreign Key](foreign-key.html) relationship to the `customers` table. Therefore, it's only possible to truncate the `customers` table while simultaneously truncating the dependent `orders` table, either using `CASCADE` or explicitly.
-
-#### Truncate dependent tables using `CASCADE`
-
-{{site.data.alerts.callout_danger}}<code>CASCADE</code> truncates <em>all</em> dependent tables without listing them, which can lead to inadvertent and difficult-to-recover losses. To avoid potential harm, we recommend truncating tables explicitly in most cases. See <a href="#truncate-dependent-tables-explicitly">Truncate Dependent Tables Explicitly</a> for more details.{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> TRUNCATE customers;
-~~~
-
-~~~
-pq: "customers" is referenced by foreign key from table "orders"
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> TRUNCATE customers CASCADE;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers;
-~~~
-
-~~~
-+----+-------+
-| id | email |
-+----+-------+
-+----+-------+
-(0 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders;
-~~~
-
-~~~
-+----+----------+------------+
-| id | customer | orderTotal |
-+----+----------+------------+
-+----+----------+------------+
-(0 rows)
-~~~
-
-#### Truncate dependent tables explicitly
-
-{% include copy-clipboard.html %}
-~~~ sql
-> TRUNCATE customers, orders;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM customers;
-~~~
-
-~~~
-+----+-------+
-| id | email |
-+----+-------+
-+----+-------+
-(0 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM orders;
-~~~
-
-~~~
-+----+----------+------------+
-| id | customer | orderTotal |
-+----+----------+------------+
-+----+----------+------------+
-(0 rows)
-~~~
-
-## See also
-
-- [`DELETE`](delete.html)
-- [`SHOW JOBS`](show-jobs.html)
-- [Foreign Key constraint](foreign-key.html)
-- [Online Schema Changes](online-schema-changes.html)
diff --git a/src/current/v20.2/ui-cdc-dashboard.md b/src/current/v20.2/ui-cdc-dashboard.md
deleted file mode 100644
index 080e341012e..00000000000
--- a/src/current/v20.2/ui-cdc-dashboard.md
+++ /dev/null
@@ -1,74 +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 DB Console lets you monitor the [changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html) created across your cluster. To view this dashboard, [access the DB Console](ui-overview.html#db-console-access), click **Metrics** on the left-hand navigation bar, and then select **Dashboard** > **Changefeeds**.
-
-{% include {{ page.version.version }}/ui/ui-metrics-navigation.md %}
-
-The **Changefeeds** dashboard displays the following time series graphs:
-
-## Max Changefeed Latency
-
-This graph shows the maximum latency for resolved timestamps of any running changefeed.
-
-<img src="{{ 'images/v20.2/ui_max_changefeed.png' | relative_url }}" alt="DB Console Max Changefeed Latency graph" style="border:1px solid #eee;max-width:100%" />
-
-{{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](stream-data-out-of-cockroachdb-using-changefeeds.html#ordering-guarantees).
-{{site.data.alerts.end}}
-
-## Sink Byte Traffic
-
-This graph shows the number of bytes emitted by CockroachDB into the sink for changefeeds.
-
-<img src="{{ 'images/v20.2/ui_sink_byte_traffic.png' | relative_url }}" alt="DB Console Sink Byte Traffic graph" style="border:1px solid #eee;max-width:100%" />
-
-Metric | Description
---------|----
-**Emitted Bytes** | The number of bytes emitted by CockroachDB into the sink for changefeeds.
-
-## Sink Counts
-
-This graph shows:
-
-- The number of messages that CockroachDB sent to the sink.
-- The number of flushes that the sink performed for changefeeds.
-
-<img src="{{ 'images/v20.2/ui_sink_counts.png' | relative_url }}" alt="DB Console Sink Counts graph" style="border:1px solid #eee;max-width:100%" />
-
-Metric | Description
---------|----
-**Messages** | The number of messages that CockroachDB sent to the sink for changefeeds.
-**Flushes** | The the number of flushes that the sink performed for changefeeds.
-
-## Sink Timings
-
-This graph shows:
-
-- The time in milliseconds per second required by CockroachDB to send messages to the sink.
-- The time CockroachDB spent waiting for the sink to flush the messages for changefeeds.
-
-<img src="{{ 'images/v20.2/ui_sink_timings.png' | relative_url }}" alt="DB Console Sink Timings graph" style="border:1px solid #eee;max-width:100%" />
-
-Metric | Description
---------|----
-**Message Emit Time** | The time in milliseconds per second required by CockroachDB to send messages to the sink for changefeeds.
-**Flush Time** | The time in milliseconds per second that CockroachDB spent waiting for the sink to flush the messages for changefeeds.
-
-## Changefeed Restarts
-
-This graph displays the number of times changefeeds restarted due to retryable errors.
-
-<img src="{{ 'images/v20.2/ui_changefeed_restarts.png' | relative_url }}" alt="DB Console Changefeed Restarts graph" style="border:1px solid #eee;max-width:100%" />
-
-{% include {{ page.version.version }}/ui/ui-summary-events.md %}
-
-## See also
-
-- [Stream Data Out of CockroachDB Using Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.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/v20.2/ui-cluster-overview-page.md b/src/current/v20.2/ui-cluster-overview-page.md
deleted file mode 100644
index 120d5b28238..00000000000
--- a/src/current/v20.2/ui-cluster-overview-page.md
+++ /dev/null
@@ -1,147 +0,0 @@
----
-title: Cluster Overview Page
-summary: The Cluster Overview page of the DB Console displays key metrics about your cluster and individual nodes.
-toc: true
----
-
-The **Cluster Overview** page of the DB Console displays key metrics about your cluster and individual nodes. These include:
-
-- Liveness status
-- Replication status
-- Uptime
-- Hardware usage
-
-If you have an [Enterprise license](enterprise-licensing.html), you can enable the [Node Map](#node-map-enterprise) view for a visual representation of your cluster's geographic layout.
-
-{{site.data.alerts.callout_success}}
-Enter your email in the banner at the top to receive updates on CockroachDB [releases](../releases/).
-{{site.data.alerts.end}}
-
-## Cluster Overview panel
-
-Use the **Cluster Overview** panel to quickly assess the capacity and health of your cluster.
-
-<img src="{{ 'images/v20.2/ui-cluster-overview-panel.png' | relative_url }}" alt="DB Console cluster overview" style="border:1px solid #eee;max-width:100%" />
-
-Metric | Description
---------|----
-Capacity Usage | <ul><li>Used: The total disk space in use by CockroachDB data across all nodes. This excludes the disk space used by the Cockroach binary, operating system, and other system files.</li><li>Usable: The total disk space usable by CockroachDB data across all nodes. This cannot exceed the store size, if one has been set using [`--store`](cockroach-start.html#store).</li></ul>See [Capacity metrics](#capacity-metrics) for details on how these values are calculated.
-Node Status | <ul><li>The number of `LIVE` nodes in the cluster.</li><li>The number of `SUSPECT` nodes in the cluster. A node is considered suspect if its [liveness status is unavailable](cluster-setup-troubleshooting.html#node-liveness-issues) or the node is in the process of [decommissioning](#decommissioned-nodes).</li><li>The number of `DEAD` nodes in the cluster.</li>
-Replication Status | <ul><li>The total number of [ranges](architecture/overview.html#glossary) in the cluster.</li><li>The number of [under-replicated ranges](ui-replication-dashboard.html#review-of-cockroachdb-terminology) in the cluster. A non-zero number indicates an unstable cluster.</li><li>The number of [unavailable ranges](ui-replication-dashboard.html#review-of-cockroachdb-terminology) in the cluster. A non-zero number indicates an unstable cluster.</li>
-
-### Capacity metrics
-
-The [Cluster Overview](#cluster-overview-panel), [Node List](#node-list), and [Node Map](#node-map-enterprise) display **Capacity Usage** by the CockroachDB [store](architecture/storage-layer.html) (the directory on each node where CockroachDB reads and writes its data) as a percentage of the disk space that is **usable** on the cluster, locality, or node.
-
-Usable disk space is constrained by the following:
-
-- The maximum store size, which may be specified using the [`--store`](cockroach-start.html#store) flag when starting nodes. If no store size has been explicitly set, the actual disk capacity is used as the limit. This value is displayed on the Capacity graph in the [Storage dashboard](ui-storage-dashboard.html#capacity).
-- Any disk space occupied by non-CockroachDB data. This may include the operating system and other system files, as well as the Cockroach binary itself.
-
-The DB Console thus calculates **usable** disk space as the sum of empty disk space, up to the value of the maximum store size, and disk space that is already being **used** by CockroachDB data.
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-{{site.data.alerts.end}}
-
-## Node List
-
-The **Node List** groups nodes by locality. The lowest-level locality tier is used to organize the Node List. Hover over a locality to see all localities for the group of nodes.
-
-{{site.data.alerts.callout_success}}
-We recommend [defining `--locality` flags when starting nodes](cockroach-start.html#locality). CockroachDB uses locality to distribute replicas and mitigate [network latency](ui-network-latency-page.html). Locality is also a prerequisite for enabling the [Node Map](#node-map-enterprise).
-{{site.data.alerts.end}}
-
-### Node status
-
-Each locality and node is displayed with its current operational status.
-
-Locality Status | Description
--------|------------
-`LIVE` | All nodes in the locality are live.
-`WARNING` | Locality has 1 or more `SUSPECT`, `DECOMMISSIONING`, or `DEAD` nodes (red indicates a dead node).
-
-Node Status | Description
--------|------------
-`LIVE` | Node is online and updating its liveness record.
-`SUSPECT` | Node has an [unavailable liveness status](cluster-setup-troubleshooting.html#node-liveness-issues).
-`DECOMMISSIONING` | Node is in the [process of decommissioning](remove-nodes.html#how-it-works).
-`DECOMMISSIONED` | Node has completed decommissioning, has been stopped, and has not [updated its liveness record](cluster-setup-troubleshooting.html#node-liveness-issues) for 5 minutes.
-`DEAD` | Node has not [updated its liveness record](cluster-setup-troubleshooting.html#node-liveness-issues) for 5 minutes.
-
-{{site.data.alerts.callout_info}}
-Nodes are considered dead once they have not [updated their liveness record](cluster-setup-troubleshooting.html#node-liveness-issues) for a certain amount of time (5 minutes by default). At this point, the [automated repair process](cockroach-quit.html#how-it-works) starts, wherein CockroachDB rebalances replicas from dead nodes to live nodes, using the unaffected replicas as sources.
-{{site.data.alerts.end}}
-
-### Node details
-
-The following details are also shown.
-
-<img src="{{ 'images/v20.2/ui-node-list.png' | relative_url }}" alt="DB Console node list" style="border:1px solid #eee;max-width:100%" />
-
-Column | Description
--------|------------
-Node Count | Number of nodes in the locality.
-Nodes | Nodes are grouped by locality and displayed with their address and node ID (the ID is the number that is prepended by `n`). Click the address to view node statistics. Hover over a row and click **Logs** to see the node's log.
-Uptime | Amount of time the node has been running.
-Replicas | Number of replicas on the node or in the locality.
-Capacity Usage | Percentage of usable disk space occupied by CockroachDB data on the node or in the locality. See [Capacity metrics](#capacity-metrics).
-Memory Usage | Memory used by CockroachDB as a percentage of the total memory on the node or in the locality.
-CPUs | Number of vCPUs on the machine.
-Version | Build tag of the CockroachDB version installed on the node.
-
-### Decommissioned Nodes
-
-Nodes that have been [decommissioned](remove-nodes.html#how-it-works) will be listed in the table of **Recently Decommissioned Nodes**, indicating that they are removed from the cluster. You can see the full history of decommissioned nodes by clicking "View all decommissioned nodes".
-
-<img src="{{ 'images/v20.2/ui-decommissioned-nodes.png' | relative_url }}" alt="DB Console node list" style="border:1px solid #eee;max-width:100%" />
-
-{{site.data.alerts.callout_info}}
-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.
-{{site.data.alerts.end}}
-
-## Node Map (Enterprise)
-
-The **Node Map** is an [enterprise](enterprise-licensing.html) feature that visualizes the geographical configuration of your cluster. It requires that [`--locality` flags have been defined](cockroach-start.html#locality) for your nodes.
-
-For guidance on enabling and configuring the node map, see [Enable the Node Map](enable-node-map.html).
-
-<img src="{{ 'images/v20.2/ui-node-map.png' | relative_url }}" alt="DB Console Summary Panel" style="border:1px solid #eee;max-width:90%" />
-
-The Node Map uses the longitude and latitude of each locality to position the components on the map. The map is populated with [**locality components**](#locality-component) and [**node components**](#node-component).
-
-### Locality component
-
-A locality component represents capacity, CPU, and QPS metrics for a given locality.
-
-The map shows the components for the highest-level locality tier (e.g., region). You can click on the **Node Count** of a locality component to view any lower-level localities (e.g., availability zone).
-
-For details on how **Capacity Usage** is calculated, see [Capacity metrics](#capacity-metrics).
-
-<img src="{{ 'images/v20.2/ui-region-component.png' | relative_url }}" alt="DB Console Summary Panel" style="border:1px solid #eee;max-width:90%" />
-
-{{site.data.alerts.callout_info}}
-On multi-core systems, the displayed CPU usage can be greater than 100%. Full utilization of 1 core is considered as 100% CPU usage. If you have _n_ cores, then CPU usage can range from 0% (indicating an idle system) to (_n_ * 100)% (indicating full utilization).
-{{site.data.alerts.end}}
-
-### Node component
-
-A node component represents capacity, CPU, and QPS metrics for a given node.
-
-Node components are accessed by clicking on the **Node Count** of the lowest-level [locality component](#locality-component).
-
-For details on how **Capacity Usage** is calculated, see [Capacity metrics](#capacity-metrics).
-
-<img src="{{ 'images/v20.2/ui-node-components.png' | relative_url }}" alt="DB Console Summary Panel" style="border:1px solid #eee;max-width:90%" />
-
-{{site.data.alerts.callout_info}}
-On multi-core systems, the displayed CPU usage can be greater than 100%. Full utilization of 1 core is considered as 100% CPU usage. If you have _n_ cores, then CPU usage can range from 0% (indicating an idle system) to (_n_ * 100)% (indicating full utilization).
-{{site.data.alerts.end}}
-
-## See also
-
-- [Production Checklist](recommended-production-settings.html)
-- [Locality](cockroach-start.html#locality)
-- [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/v20.2/ui-custom-chart-debug-page.md b/src/current/v20.2/ui-custom-chart-debug-page.md
deleted file mode 100644
index bf7adf50408..00000000000
--- a/src/current/v20.2/ui-custom-chart-debug-page.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: Custom Chart Debug Page
-summary: The Custom Chart debug page can be used to create one or multiple custom charts showing any combination of over 200 available metrics.
-toc: true
----
-
-The **Custom Chart** debug page in the DB Console 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 DB Console](ui-overview.html), and either:
-
-- Open <a href="http://localhost:8080/#/debug/chart" data-proofer-ignore>http://localhost:8080/#/debug/chart</a> 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
-
-<img src="{{ 'images/v20.2/ui-custom-chart-debug-00.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-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}}/ui-custom-chart-debug-page-00.html %}
-
-## Examples
-
-### Query user and system CPU usage
-
-<img src="{{ 'images/v20.2/ui-custom-chart-debug-01.png' | relative_url }}" alt="DB Console" style="border:1px solid #eee;max-width:100%" />
-
-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 [DB Console](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/v20.2/ui-databases-page.md b/src/current/v20.2/ui-databases-page.md
deleted file mode 100644
index 4391b3f8cf7..00000000000
--- a/src/current/v20.2/ui-databases-page.md
+++ /dev/null
@@ -1,62 +0,0 @@
----
-title: Databases Page
-summary: The Databases page provides details about databases configured, the tables in each database, and the grants assigned to each user.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-On a secure cluster, this area of the DB Console can only be accessed by an `admin` user. See [DB Console access](ui-overview.html#db-console-access).
-{{site.data.alerts.end}}
-
-The **Databases** page of the DB Console provides details of the following:
-
-- The databases configured.
-- The tables in each database.
-- The grants assigned to each user.
-
-To view this page, [access the DB Console](ui-overview.html#db-console-access) and click **Databases** in the left-hand navigation.
-
-## Tables view
-
-The **Tables** view shows details of the system table as well as the tables in your databases.
-
-To view [table details](#table-details), click on a table name.
-
-<img src="{{ 'images/v20.2/ui_database_tables_view.png' | relative_url }}" alt="DB Console Database Tables View" style="border:1px solid #eee;max-width:100%" />
-
-The following are displayed for each table:
-
-Parameter | Description
---------|----
-Table Name | The name of the table.
-Size | Approximate disk size of all replicas of this table on the cluster.
-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.
-
-### Table details
-
-Click any table name in [Tables](#tables-view) view to display details for that table.
-
-<img src="{{ 'images/v20.2/ui_database_tables_details.png' | relative_url }}" alt="DB Console Database Tables View" style="border:1px solid #eee;max-width:100%" />
-
-- **Overview** displays the SQL statements used to [create and define the table](create-table.html), as well as [partitioning](partitioning.html) info and [zone configurations](configure-replication-zones.html). In addition, the following metrics are displayed:
-	- **Size** is the approximate disk size of all replicas of this table on the cluster.
-	- **Ranges** is the number of [ranges](architecture/overview.html#terms) in this table.
-	- **Replicas** is the number of [replicas](architecture/replication-layer.html) of this table on the cluster.
-- **Grants** displays the [grants](#grants-view) associated with the table.
-
-## Grants view
-
-The **Grants** view shows the [privileges](authorization.html#assign-privileges) granted to users for each database.
-
-For more details about grants and privileges, see [`GRANT <privileges>`](grant.html).
-
-<img src="{{ 'images/v20.2/ui_database_grants_view.png' | relative_url }}" alt="DB Console Database Grants View" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [Statements page](ui-statements-page.html)
-- [Assign privileges](authorization.html#assign-privileges)
-- [`GRANT <privileges>`](grant.html)
-- [Raw status endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v20.2/ui-debug-pages.md b/src/current/v20.2/ui-debug-pages.md
deleted file mode 100644
index 9cef6bbf220..00000000000
--- a/src/current/v20.2/ui-debug-pages.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Advanced Debug Page
-summary: The Advanced Debug page provides links to advanced monitoring and troubleshooting reports and cluster configuration details.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-Most of the functionality on this page can only be accessed by an `admin` user. See [DB Console security](ui-overview.html#db-console-security).
-{{site.data.alerts.end}}
-
-The **Advanced Debug** page of the DB Console provides links to advanced monitoring and troubleshooting reports and cluster configuration details. To view this page, [access the DB Console](ui-overview.html#db-console-access) and click **Advanced Debug** in the left-hand navigation.
-
-{{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 DB Console 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](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](ui-overview.html#db-console-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](ui-overview.html#db-console-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](ui-overview.html#db-console-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/).
-
-## Raw Status Endpoints (JSON)
-
-Depending on your [access level](ui-overview.html#db-console-access), the endpoints listed here provide access to:
-
-- [Log files](debug-and-error-logs.html#write-to-file)
-- Secondary log files (e.g., storage engine logs, [execution logs](query-behavior-troubleshooting.html#cluster-wide-execution-logs), [slow query logs](query-behavior-troubleshooting.html#using-the-slow-query-log), [authentication logs](query-behavior-troubleshooting.html#authentication-logs))
-- Node status
-- Hot ranges
-- Node-specific metrics
-- Session data
-- Cluster-wide range data
-- Allocator runs
-
-## 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/v20.2/ui-hardware-dashboard.md b/src/current/v20.2/ui-hardware-dashboard.md
deleted file mode 100644
index c09e3c79443..00000000000
--- a/src/current/v20.2/ui-hardware-dashboard.md
+++ /dev/null
@@ -1,128 +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 the hardware utilization of your cluster. This includes CPU usage, disk throughput, network traffic, storage capacity, and memory.
-
-To view this dashboard, [access the DB Console](ui-overview.html#db-console-access), click **Metrics** in the left-hand navigation, and select **Dashboard** > **Hardware**.
-
-{% include {{ page.version.version }}/ui/ui-metrics-navigation.md %}
-
-The **Hardware** dashboard displays the following time series graphs:
-
-## CPU Percent
-
-<img src="{{ 'images/v20.2/ui_cpu_percent.png' | relative_url }}" alt="DB Console CPU Percent graph" style="border:1px solid #eee;max-width:100%" />
-
-{{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
-
-<img src="{{ 'images/v20.2/ui_memory_usage_new.png' | relative_url }}" alt="DB Console Memory Usage graph" style="border:1px solid #eee;max-width:100%" />
-
-{{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
-
-<img src="{{ 'images/v20.2/ui_disk_read_bytes.png' | relative_url }}" alt="DB Console Disk Read Bytes graph" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_disk_write_bytes.png' | relative_url }}" alt="DB Console Disk Write Bytes graph" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_disk_read_ops.png' | relative_url }}" alt="DB Console Disk Read Ops graph" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_disk_write_ops.png' | relative_url }}" alt="DB Console Disk Write Ops graph" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_disk_iops.png' | relative_url }}" alt="DB Console Disk IOPS in Progress graph" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_available_disk_capacity.png' | relative_url }}" alt="DB Console Disk Capacity graph" style="border:1px solid #eee;max-width:100%" />
-
-Metric | Description
---------|--------
-**Available Disk Capacity** | Free disk space available to CockroachDB data on each node.
-
-### Capacity metrics
-
-The **available** disk capacity equals the amount of empty disk space, up to the value of the maximum store size. The store size is determined as follows:
-
-- If a store size was specified using the [`--store`](cockroach-start.html#store) flag when starting nodes, this value is used as the limit for CockroachDB data.
-- If no store size has been explicitly set, the actual disk capacity is used as the limit for CockroachDB data.
-
-The disk usage of the Cockroach binary, operating system, and other system files is not shown on the **Available Disk Capacity** graph.
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-{{site.data.alerts.end}}
-
-## Network Bytes Received
-
-<img src="{{ 'images/v20.2/ui_network_bytes_received.png' | relative_url }}" alt="DB Console Network Bytes Received graph" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_network_bytes_sent.png' | relative_url }}" alt="DB Console Network Bytes Sent graph" style="border:1px solid #eee;max-width:100%" />
-
-- 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/v20.2/ui-jobs-page.md b/src/current/v20.2/ui-jobs-page.md
deleted file mode 100644
index fea88436935..00000000000
--- a/src/current/v20.2/ui-jobs-page.md
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Jobs Page
-summary: The Jobs page of the DB Console provides details about long-running tasks performed by your cluster.
-toc: true
----
-
-The **Jobs** page of the DB Console provides details about long-running tasks performed by your cluster. These can include:
-
-{% include {{ page.version.version }}/sql/schema-changes.md %}.
-- [`IMPORT`](import.html).
-- Enterprise [`BACKUP`](backup.html) and [`RESTORE`](restore.html).
-- [User-created table statistics](create-statistics.html) created for use by the [cost-based optimizer](cost-based-optimizer.html).
-- [Automatic table statistics](cost-based-optimizer.html#table-statistics).
-- [Changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html).
-
-{{site.data.alerts.callout_success}}
-All users can see their own jobs, and `admin` users can view all jobs performed across all nodes in the cluster.
-{{site.data.alerts.end}}
-
-To view these details, [access the DB Console](ui-overview.html#db-console-access) and click **Jobs** in the left-hand navigation.
-
-## Filter jobs
-
-Use the **Status** menu to filter jobs by [job status](#job-status).
-
-Use the **Type** menu to filter jobs by type.
-
-You can toggle between showing the latest 50 jobs or all jobs on the cluster.
-
-{{site.data.alerts.callout_info}}
-Jobs are deleted every 14 days. This interval can be changed via the `jobs.retention_time` [cluster setting](cluster-settings.html).
-
-The Jobs list is designed for you to manage pending work. It is not intended to display the canonical record of all jobs that have run. If you need a historical record of all jobs you have run, you should log this information externally.
-{{site.data.alerts.end}}
-
-## Jobs list
-
-Use the **Jobs** list to see your recently created and completed jobs.
-
-- For changefeeds, the table displays a [high-water timestamp that advances as the changefeed progresses](stream-data-out-of-cockroachdb-using-changefeeds.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).
-
-- [Automatic table statistics](cost-based-optimizer.html#table-statistics) jobs are not displayed even when the **Type** menu is set to **All**. To view these jobs, set **Type** to **Automatic-Statistics Creation** as described [above](#filter-jobs).
-
-- To view [job details](#job-details), click on the job description.
-
-<img src="{{ 'images/v20.2/ui_jobs_page_new.png' | relative_url }}" alt="DB Console Jobs Page" style="border:1px solid #eee;max-width:100%" />
-
-Parameter | Description
-----------|------------
-Description | SQL statement that created the job.
-Job ID | Unique job ID. This value is used to [pause](pause-job.html), [resume](resume-job.html), or [cancel](cancel-job.html) jobs.
-Users | User that created the job.
-Creation Time | Date and time the job was created.
-Status | Current [job status](#job-status) or completion progress.
-
-### Job status
-
-Status | Description
--------|------------
-`PENDING` | Job is created but has not started running.
-`PAUSED` | Job is [paused](pause-job.html).
-`FAILED` | Job failed to complete.
-`SUCCEEDED` | Job successfully completed.
-`CANCELED` | Job was [cancelled](cancel-job.html).
-
-A job that is currently running will be displayed with its percent completion and time remaining, rather than the `RUNNING` status.
-
-## Job details
-
-Click any description on the [jobs list](#jobs-list) to see the full SQL statement that created the job.
-
-The job ID, creation time, users, and status are also shown.
-
-<img src="{{ 'images/v20.2/ui_jobs_page_details.png' | relative_url }}" alt="DB Console Jobs Page" style="border:1px solid #eee;max-width:100%" />
-
-## See also
-
-- [`SHOW JOBS`](show-jobs.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/v20.2/ui-network-latency-page.md b/src/current/v20.2/ui-network-latency-page.md
deleted file mode 100644
index 8c5fa16adc5..00000000000
--- a/src/current/v20.2/ui-network-latency-page.md
+++ /dev/null
@@ -1,58 +0,0 @@
----
-title: Network Latency Page
-summary: The Network Latency page displays round-trip latencies between all nodes in your cluster.
-toc: true
----
-
-The **Network Latency** page displays round-trip latencies between all nodes in your cluster. Latency is the time required to transmit a packet across a network, and is highly dependent on your network topology. Use this page to determine whether your latency is appropriate for your [topology pattern](topology-patterns.html), or to identify nodes with unexpected latencies.
-
-To view this page, [access the DB Console](ui-overview.html#db-console-access) and click **Network Latency** in the left-hand navigation.
-
-## Sort and filter network latency
-
-Use the **Sort By** menu to arrange the latency matrix by [locality](cockroach-start.html#locality) (e.g., cloud, region, availability zone, datacenter).
-
-Use the **Filter** menu to select specific nodes or localities to view.
-
-Select **Collapse Nodes** to display the mean latencies of each locality, depending on how the matrix is sorted. This is a way to quickly assess cross-regional or cross-cloud latency.
-
-## Understanding the Network Latency matrix
-
-Each cell in the matrix displays the round-trip latency in milliseconds between two nodes in your cluster. Round-trip latency includes the return time of a packet. Latencies are color-coded by their standard deviation from the mean latency on the network: green for lower values, and blue for higher.
-
-<img src="{{ 'images/v20.2/ui_network_latency_matrix.png' | relative_url }}" alt="DB Console Network Latency matrix" style="border:1px solid #eee;max-width:100%" />
-
-Rows represent origin nodes, and columns represent destination nodes. Hover over a cell to see round-trip latency and locality metadata for origin and destination nodes.
-
-On a [typical multi-region cluster](demo-low-latency-multi-region-deployment.html#step-4-access-the-db-console), you can expect much lower latencies between nodes in the same region/availability zone. Nodes in different regions/availability zones, meanwhile, will experience higher latencies that reflect their geographical distribution.
-
-For instance, the cluster shown above has nodes in `us-west1`, `us-east1`, and `europe-west2`. Latencies are highest between nodes in `us-west1` and `europe-west2`, which span the greatest distance. This is especially clear when sorting by region or availability zone and collapsing nodes:
-
-<img src="{{ 'images/v20.2/ui_network_latency_collapsed_nodes.png' | relative_url }}" alt="DB Console Network Latency collapsed nodes" style="border:1px solid #eee;max-width:100%" />
-
-### No connections
-
-Nodes that have lost a connection are displayed in a separate color. This can help you locate a network partition in your cluster.
-
-{{site.data.alerts.callout_info}}
-A network partition prevents nodes from communicating with each other in one or both directions. This can be due to a configuration problem with the network, such as when allowlisted IP addresses or hostnames change after a node is torn down and rebuilt. In a symmetric partition, node communication is broken in both directions. In an asymmetric partition, node communication works in one direction but not the other.
-
-The effect of a network partition depends on which nodes are partitioned, where the ranges are located, and to a large extent, whether [localities](cockroach-start.html#locality) are defined. If localities are not defined, a partition that cuts off at least (n-1)/2 nodes will cause data unavailability.
-{{site.data.alerts.end}}
-
-Click the **NO CONNECTIONS** link to see lost connections between nodes or [localities](cockroach-start.html#locality), if any are defined.
-
-## Topology fundamentals
-
-{% include {{ page.version.version }}/topology-patterns/fundamentals.md %}
-
-{{site.data.alerts.callout_info}}
-Network latency limits the performance of individual operations. You can use the [Statements](ui-statements-page.html) page to see the latencies of SQL statements on gateway nodes.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Topology Patterns](topology-patterns.html)
-- [CockroachDB Performance](performance.html#latency)
-- [Performance Tuning](performance-tuning.html)
-- [Low Latency Reads and Writes in a Multi-Region Cluster](demo-low-latency-multi-region-deployment.html)
diff --git a/src/current/v20.2/ui-overview-dashboard.md b/src/current/v20.2/ui-overview-dashboard.md
deleted file mode 100644
index df16fef7a20..00000000000
--- a/src/current/v20.2/ui-overview-dashboard.md
+++ /dev/null
@@ -1,84 +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 DB Console](ui-overview.html#db-console-access) and click **Metrics** on the left-hand navigation bar. The **Overview** dashboard is displayed by default.
-
-{% include {{ page.version.version }}/ui/ui-metrics-navigation.md %}
-
-{{site.data.alerts.callout_info}}
-All timestamps in the DB Console are shown in Coordinated Universal Time (UTC).
-{{site.data.alerts.end}}
-
-The **Overview** dashboard displays the following time series graphs:
-
-## SQL Queries
-
-<img src="{{ 'images/v20.2/ui_sql_queries.png' | relative_url }}" alt="DB Console SQL Queries graph" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_service_latency_99_percentile.png' | relative_url }}" alt="DB Console Service Latency graph" style="border:1px solid #eee;max-width:100%" />
-
-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
-
-<img src="{{ 'images/v20.2/ui_replicas_per_node.png' | relative_url }}" alt="DB Console Replicas per node graph" style="border:1px solid #eee;max-width:100%" />
-
-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 DB Console 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
-
-<img src="{{ 'images/v20.2/ui_capacity.png' | relative_url }}" alt="DB Console Capacity graph" style="border:1px solid #eee;max-width:100%" />
-
-You can monitor the **Capacity** graph to determine when additional storage is needed (e.g., by [scaling your cluster](cockroach-start.html)).
-
-Metric | Description
---------|--------
-**Capacity** | The maximum store size. This value may be set per node using [`--store`](cockroach-start.html#store). If a store size has not been set, this metric displays the actual disk capacity. See [Capacity metrics](#capacity-metrics).
-**Available** | The free disk space available to CockroachDB data.
-**Used** | The disk space in use by CockroachDB data. This excludes the Cockroach binary, operating system, and other system files.
-
-### Capacity metrics
-
-The **Capacity** graph displays disk usage by CockroachDB data in relation to the maximum [store](architecture/storage-layer.html) size, which is determined as follows:
-
-- If a store size was specified using the [`--store`](cockroach-start.html#store) flag when starting nodes, this value is used as the limit for CockroachDB data.
-- If no store size has been explicitly set, the actual disk capacity is used as the limit for CockroachDB data.
-
-The **available** capacity thus equals the amount of empty disk space, up to the value of the maximum store size. The **used** capacity refers only to disk space occupied by CockroachDB data, which resides in the store directory on each node.
-
-The disk usage of the Cockroach binary, operating system, and other system files is not shown on the **Capacity** graph.
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/ui/ui-summary-events.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/v20.2/ui-overview.md b/src/current/v20.2/ui-overview.md
deleted file mode 100644
index 6687eed175a..00000000000
--- a/src/current/v20.2/ui-overview.md
+++ /dev/null
@@ -1,74 +0,0 @@
----
-title: DB Console Overview
-summary: Use the DB Console to monitor and optimize cluster performance.
-toc: true
-key: explore-the-admin-ui.html
----
-
-The DB Console provides details about your cluster and database configuration, and helps you optimize cluster performance.
-
-## DB Console areas
-
-Area | Description
---------|----
-[Cluster Overview](ui-cluster-overview-page.html) | Essential metrics about the cluster and nodes, including liveness status, replication status, uptime, and hardware usage.
-[Node Map](enable-node-map.html) | Geographical configuration of your cluster and metrics at the locality and node levels, visualized on a map.
-[Overview Dashboard](ui-overview-dashboard.html) | Metrics about SQL performance, replication, and storage.
-[Hardware Dashboard](ui-hardware-dashboard.html) | Metrics about CPU usage, disk throughput, network traffic, storage capacity, and memory.
-[Runtime Dashboard](ui-runtime-dashboard.html) | Metrics about node count, CPU time, and memory usage.
-[SQL Dashboard](ui-sql-dashboard.html) | Metrics about SQL connections, byte traffic, queries, transactions, and service latency.
-[Storage Dashboard](ui-storage-dashboard.html) | Metrics about storage capacity and file descriptors.
-[Replication Dashboard](ui-replication-dashboard.html) | Metrics about how data is replicated across the cluster, e.g., range status, replicas per store, and replica quiescence.
-[Changefeeds Dashboard](ui-cdc-dashboard.html) | Metrics about the [changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html) created across your cluster.
-[Databases](ui-databases-page.html) | Details about the system and user databases in the cluster.
-[Sessions](ui-sessions-page.html) | <span class="version-tag">New in v20.2:</span> Details about open sessions in the cluster.
-[Statements](ui-statements-page.html) | Frequently executed and high latency [SQL statements](sql-statements.html), with the option to collect statement diagnostics.
-[Transactions](ui-transactions-page.html) | <span class="version-tag">New in v20.2:</span> Details about transactions running on the cluster.
-[Network Latency](ui-network-latency-page.html) | Latencies and lost connections between all nodes in your cluster.
-[Jobs](ui-jobs-page.html) | Details of jobs running in the cluster.
-[Advanced Debug](ui-debug-pages.html) | 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.
-
-## DB Console access
-
-The DB Console is accessible from every node at `http://<host>:<http-port>`, or `http://<host>:8080` by default.
-
-- If you included the [`--http-addr`](cockroach-start.html#networking) flag when starting nodes, use the IP address/hostname and port specified by that flag.
-- If you didn't include the [`--http-addr`](cockroach-start.html#networking) flag when starting nodes, use the IP address/hostname specified by the [`--listen-addr`](cockroach-start.html#networking) flag and port `8080`.
-- If you are running a [secure cluster](#db-console-security), use `https` instead of `http`. You will also need to [create a user with a password](create-user.html#create-a-user-with-a-password) to log in.
-
-{{site.data.alerts.callout_success}}
-For guidance on accessing the DB Console in the context of cluster deployment, see [Start a Local Cluster](start-a-local-cluster.html) and [Manual Deployment](manual-deployment.html).
-{{site.data.alerts.end}}
-
-### DB Console security
-
-On insecure clusters, all areas of the DB Console are accessible to all users.
-
-On secure clusters, for each user who should have access to the DB Console, you must [create a user with a password](create-user.html#create-a-user-with-a-password) and optionally [grant the user membership to the `admin` role](grant-roles.html).
-
-{{site.data.alerts.callout_info}}
-The default `root` user is a member of the `admin` role. Use the following command to [grant users membership to the `admin` role](grant-roles.html):
-
-<code style="white-space:pre-wrap">GRANT admin TO \<sql_user\>;</code>
-{{site.data.alerts.end}}
-
-For security reasons, non-admin users access only the data over which they have privileges (e.g., their tables, jobs, and list of sessions), and data that does not require privileges (e.g., cluster health, node status, metrics).
-
-The following areas of the DB Console can only be accessed by [`admin` users](authorization.html#admin-role). These areas display information from privileged HTTP endpoints that operate with `admin` privilege.
-
-Secure area | Privileged information
------|-----
-[Node Map](enable-node-map.html) | Database and table names
-[Databases](ui-databases-page.html) | Stored table data
-[Statements](ui-statements-page.html) | SQL statements
-[Advanced Debug](ui-debug-pages.html) (some reports) | Stored table data, operational details, internal IP addresses, names, credentials, application data (depending on report)
-
-{{site.data.alerts.callout_info}}
-By default, the DB Console shares anonymous usage details with Cockroach Labs. For information about the details shared and how to opt-out of reporting, see [Diagnostics Reporting](diagnostics-reporting.html).
-{{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/v20.2/ui-replication-dashboard.md b/src/current/v20.2/ui-replication-dashboard.md
deleted file mode 100644
index 3cc2bb978a8..00000000000
--- a/src/current/v20.2/ui-replication-dashboard.md
+++ /dev/null
@@ -1,113 +0,0 @@
----
-title: Replication Dashboard
-summary: The Replication dashboard lets you monitor the replication metrics for your cluster.
-toc: true
----
-
-The **Replication** dashboard in the DB Console enables you to monitor the replication metrics for your cluster.
-
-To view this dashboard, [access the DB Console](ui-overview.html#db-console-access), click **Metrics** in the left-hand navigation, and select **Dashboard** > **Replication**.
-
-## Review of CockroachDB terminology
-
-- **Range**: CockroachDB stores all user data and almost all system data in a giant sorted map of key-value pairs. This keyspace is divided into "ranges", contiguous chunks of the keyspace, so that every key can always be found in a single range.
-- **Range Replica:** CockroachDB replicates each range (3 times by default) and stores each replica on a different node.
-- **Range Lease:** For each range, one of the replicas holds the "range lease". This replica, referred to as the "leaseholder", is the one that receives and coordinates all read and write requests for the range.
-- **Under-replicated Ranges:** <a name="under-replicated-ranges"></a> When a cluster is first initialized, the few default starting ranges will only have a single replica, but as soon as other nodes are available, they will replicate to them until they've reached their desired replication factor, the default being 3. If a range does not have enough replicas, the range is said to be "under-replicated".
-- **Unavailable Ranges:** <a name="unavailable-ranges"></a> If a majority of a range's replicas are on nodes that are unavailable, then the entire range is unavailable and will be unable to process queries.
-
-For more details, see [Scalable SQL Made Easy: How CockroachDB Automates Operations](https://www.cockroachlabs.com/blog/automated-rebalance-and-repair/)
-
-{% include {{ page.version.version }}/ui/ui-metrics-navigation.md %}
-
-The **Replication** dashboard displays the following time series graphs:
-
-## Ranges
-
-<img src="{{ 'images/v20.2/ui_ranges.png' | relative_url }}" alt="DB Console Replicas per Store" style="border:1px solid #eee;max-width:100%" />
-
-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.
-
-## Logical Bytes per Store
-
-<img src="{{ 'images/v20.2/ui_logical_bytes_per_store.png' | relative_url }}" alt="DB Console Replicas per Store" style="border:1px solid #eee;max-width:100%" />
-
-Metric | Description
---------|--------
-**Logical Bytes per Store** | Number of logical bytes stored in [key-value pairs](architecture/distribution-layer.html#table-data) on each node. This includes historical and deleted data.
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/ui/logical-bytes.md %}
-{{site.data.alerts.end}}
-
-## Replicas Per Store
-
-<img src="{{ 'images/v20.2/ui_replicas_per_store.png' | relative_url }}" alt="DB Console Replicas per Store" style="border:1px solid #eee;max-width:100%" />
-
-- 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 DB Console, as described in [Fault tolerance and recovery](demo-fault-tolerance-and-recovery.html).
-
-## Replica Quiescence
-
-<img src="{{ 'images/v20.2/ui_replica_quiescence.png' | relative_url }}" alt="DB Console Replica Quiescence" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_replica_snapshots.png' | relative_url }}" alt="DB Console Replica Snapshots" style="border:1px solid #eee;max-width:100%" />
-
-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) | 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
-- 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.
-
-{% include {{ page.version.version }}/ui/ui-summary-events.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/v20.2/ui-runtime-dashboard.md b/src/current/v20.2/ui-runtime-dashboard.md
deleted file mode 100644
index 4847aee764f..00000000000
--- a/src/current/v20.2/ui-runtime-dashboard.md
+++ /dev/null
@@ -1,79 +0,0 @@
----
-title: Runtime Dashboard
-summary: The Runtime dashboard lets you monitor runtime metrics for you cluster, such as node count, memory usage, and CPU time.
-toc: true
----
-
-The **Runtime** dashboard in the DB Console lets you monitor runtime metrics for you cluster, such as node count, memory usage, and CPU time. To view this dashboard, [access the DB Console](ui-overview.html#db-console-access), click **Metrics** on the left-hand navigation bar, and then select **Dashboard** > **Runtime**.
-
-{% include {{ page.version.version }}/ui/ui-metrics-navigation.md %}
-
-The **Runtime** dashboard displays the following time series graphs:
-
-## Live Node Count
-
-<img src="{{ 'images/v20.2/ui_node_count.png' | relative_url }}" alt="DB Console Node Count" style="border:1px solid #eee;max-width:100%" />
-
-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](#summary-panel).
-
-## Memory Usage
-
-<img src="{{ 'images/v20.2/ui_memory_usage.png' | relative_url }}" alt="DB Console Memory Usage" style="border:1px solid #eee;max-width:100%" />
-
-- 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, <a href="https://forum.cockroachlabs.com/">contact us</a>.{{site.data.alerts.end}}
-
-## CPU Time
-
-<img src="{{ 'images/v20.2/ui_cpu_time.png' | relative_url }}" alt="DB Console CPU Time" style="border:1px solid #eee;max-width:100%" />
-
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_clock_offset.png' | relative_url }}" alt="DB Console Clock Offset" style="border:1px solid #eee;max-width:100%" />
-
-- 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.
-
-{% include {{ page.version.version }}/ui/ui-summary-events.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/v20.2/ui-sessions-page.md b/src/current/v20.2/ui-sessions-page.md
deleted file mode 100644
index 7c6886f9df7..00000000000
--- a/src/current/v20.2/ui-sessions-page.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: Sessions Page
-summary: The Sessions page provides details of all open sessions in the cluster.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-On a secure cluster, this area of the DB Console can only be accessed by a SQL user with the [`VIEWACTIVITY`](authorization.html#create-and-manage-users) role option. Note that non-`admin` users will see only their own sessions, while `admin` users see sessions for all users.
-{{site.data.alerts.end}}
-
-<span class="version-tag">New in v20.2:</span> The **Sessions** page of the DB Console provides details of all open sessions in the cluster.
-
-To view this page, [access the DB Console](ui-overview.html#db-console-access) and click **Sessions** in the left-hand navigation.
-
-## Sessions list
-
-Use the **Sessions** list to see the open sessions in the cluster. This includes active and idle sessions.
-
-{{site.data.alerts.callout_info}}
-A session is *active* if it has an open transaction (including implicit transactions, which are individual SQL statements), and *idle* if it has no open transaction. Active sessions consume hardware resources.
-{{site.data.alerts.end}}
-
-- If a session is active, the most recent SQL statement is displayed in the **Statement** column.
-- If a session is idle, **Transaction Duration**, **Statement Duration**, and **Statement** will display `N/A`.
-- To view [details of a session](#session-details), click the **Session Duration**.
-
-{{site.data.alerts.callout_info}}
-An active session can have an open transaction that is not currently running SQL. In this case, the **Statement** and **Statement Duration** columns will display `N/A` and **Transaction Duration** will display a value. Transactions that are held open can cause [contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention).
-{{site.data.alerts.end}}
-
-<img src="{{ 'images/v20.2/ui-sessions-page.png' | relative_url }}" alt="DB Console Database Tables View" style="border:1px solid #eee;max-width:100%" />
-
-The following are displayed for each active session:
-
-Parameter | Description
---------- | -----------
-Session Age | Amount of time the session has been open.
-Txn Duration | Amount of time the transaction has been active, if there is an open transaction.
-Statement Age | Amount of time the SQL statement has been active, if there is an active statement.
-Memory Usage | Amount of memory currently allocated to this session / maximum amount of memory this session has ever been allocated.
-Statement | Active SQL statement. If more than one statement is active, the most recent statement is shown.
-Actions | Options to terminate the active query and/or terminate the session. These require the [`CANCELQUERY` role option](authorization.html#create-and-manage-users).<br><br>**Terminate Statement:** Ends the SQL statement. The session running this statement will receive an error.<br><br>**Terminate Session:** Ends the session. The client that holds this session will receive a "connection terminated" event.
-
-{{site.data.alerts.callout_success}}
-Sort by **Txn Duration** to display all active sessions at the top.
-{{site.data.alerts.end}}
-
-## Session details
-
-Click the **Session Age** of any session to display details and possible actions for that session.
-
-<img src="{{ 'images/v20.2/ui-sessions-details-page.png' | relative_url }}" alt="DB Console Database Tables View" style="border:1px solid #eee;max-width:100%" />
-
-- **Session** shows the ID of the connected session.
-	- **Session Start Time** shows the timestamp at which the session started.
-	- **Gateway Node** shows the node ID and IP address/port of the [gateway](architecture/life-of-a-distributed-transaction.html#gateway) node handling the client connection.
-	- **Client Address** shows the IP address/port of the client that opened the session.
-	- **Memory Usage** shows the amount of memory currently allocated to this session / maximum amount of memory this session has ever allocated.
-	- The **Terminate Session** button ends the session. The client that holds this session will receive a "connection terminated" event.
-	- The **Terminate Statement** button ends the SQL statement. The session running this statement will receive an error.
-- **Transaction** will display the following information for an open transaction.
-	- **Transaction Start Time** shows the timestamp at which the transaction started.
-	- **Number of Statements Executed** shows the total number of SQL statements executed by the transaction.
-	- **Number of Retries** shows the total number of [retries](transactions.html#transaction-retries) for the transaction.
-	- **Number of Automatic Retries** shows the total number of [automatic retries](transactions.html#automatic-retries) run by CockroachDB for the transaction.
-	- **Priority** shows the [priority](transactions.html#transaction-priorities) for the transaction.
-	- **Read Only?** shows whether the transaction is read-only.
-	- **AS OF SYSTEM TIME?** shows whether the transaction uses [`AS OF SYSTEM TIME`](performance-best-practices-overview.html#use-as-of-system-time-to-decrease-conflicts-with-long-running-queries) to return historical data.
-	- **Memory Usage** shows the amount of memory currently allocated to this transaction / maximum amount of memory this transaction has ever allocated.
-- **Statement** will display the following information for an active statement.
-	- The SQL statement is shown.
-	- **Execution Start Time** shows the timestamp at which the statement was run.
-	- **Distributed Execution?** shows whether the statement uses [Distributed SQL (DistSQL)](architecture/sql-layer.html#distsql) optimization.
-	- **View Statement Details** opens the [Statement Details](ui-statements-page.html#statement-details-page) page for the statement.
-
-## See also
-
-- [`SHOW SESSIONS`](show-sessions.html)
-- [Statements page](ui-statements-page.html)
-- [SQL Statements](sql-statements.html)
-- [Transactions](transactions.html)
-- [Transaction Error Retry Reference](transaction-retry-error-reference.html)
-- [Production Checklist](recommended-production-settings.html#hardware)
diff --git a/src/current/v20.2/ui-sql-dashboard.md b/src/current/v20.2/ui-sql-dashboard.md
deleted file mode 100644
index 57cd348d4a2..00000000000
--- a/src/current/v20.2/ui-sql-dashboard.md
+++ /dev/null
@@ -1,89 +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 DB Console lets you monitor the performance of your SQL queries. To view this dashboard, [access the DB Console](ui-overview.html#db-console-access), click **Metrics** on the left-hand navigation bar, and then select **Dashboard** > **SQL**.
-
-{% include {{ page.version.version }}/ui/ui-metrics-navigation.md %}
-
-The **SQL** dashboard displays the following time series graphs:
-
-## SQL Connections
-
-<img src="{{ 'images/v20.2/ui_sql_connections.png' | relative_url }}" alt="DB Console SQL Connections" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_sql_byte_traffic.png' | relative_url }}" alt="DB Console SQL Byte Traffic" style="border:1px solid #eee;max-width:100%" />
-
-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
-
-<img src="{{ 'images/v20.2/ui_sql_queries.png' | relative_url }}" alt="DB Console SQL Queries" style="border:1px solid #eee;max-width:100%" />
-
-- 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.
-
-## SQL Query Errors
-
-<img src="{{ 'images/v20.2/ui_sql_query_errors.png' | relative_url }}" alt="DB Console SQL Query Errors" style="border:1px solid #eee;max-width:100%" />
-
-- 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
-
-<img src="{{ 'images/v20.2/ui_service_latency_99_percentile.png' | relative_url }}" alt="DB Console Service Latency" style="border:1px solid #eee;max-width:100%" />
-
-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 displays the 99th [percentile](https://en.wikipedia.org/wiki/Percentile#The_normal_distribution_and_percentiles) of service latency for the selected node.
-
-- In the cluster view, the graph displays the 99th [percentile](https://en.wikipedia.org/wiki/Percentile#The_normal_distribution_and_percentiles) of service latency for each node in the cluster.
-
-## Transactions
-
-<img src="{{ 'images/v20.2/ui_transactions.png' | relative_url }}" alt="DB Console Transactions" style="border:1px solid #eee;max-width:100%" />
-
-- 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.
-
-<img src="{{ 'images/v20.2/ui_transaction_latency.png' | relative_url }}" alt="DB Console Transaction Latencies" style="border:1px solid #eee;max-width:100%" />
-
-## 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.
-
-{% include {{ page.version.version }}/ui/ui-summary-events.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/v20.2/ui-statements-page.md b/src/current/v20.2/ui-statements-page.md
deleted file mode 100644
index b61c2c843c2..00000000000
--- a/src/current/v20.2/ui-statements-page.md
+++ /dev/null
@@ -1,190 +0,0 @@
----
-title: Statements Page
-summary: The Statements page helps you identify frequently executed or high latency SQL statements, view statement details, and download statement diagnostics.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-On a secure cluster, this area of the DB Console can only be accessed by an `admin` user. See [DB Console access](ui-overview.html#db-console-access).
-{{site.data.alerts.end}}
-
-The **Statements** page helps you:
-
-- Identify frequently executed or high latency [SQL statements](sql-statements.html).
-- View SQL statement [details](#statement-details-page).
-- Download SQL statement [diagnostics](#diagnostics) for troubleshooting.
-
-To view this page, [access the DB Console](ui-overview.html#db-console-access) and click **Statements** in the left-hand navigation.
-
-## Search and filter by application
-
-By default, this page shows SQL statements from all applications running on the cluster, and hides internal CockroachDB queries.
-
-To filter the statements by [`application_name`](connection-parameters.html#additional-connection-parameters), use the **App** menu. If you haven't set `application_name` in the client connection string, it appears as `unset`.
-
-CockroachDB's internal queries are only displayed under the `(internal)` app. Queries from the SQL shell are displayed under the `$ cockroach sql` app.
-
-You can also search for statements using the search bar.
-
-## Understand the Statements page
-
-Use this page to identify SQL statements that you may want to [troubleshoot](query-behavior-troubleshooting.html). This might include statements that are experiencing high latencies, multiple [retries](transactions.html#transaction-retries), or execution failures. You can optionally create and retrieve [diagnostics](#diagnostics) for these statements.
-
-{{site.data.alerts.callout_success}}
-If you haven't yet executed any queries in the cluster as a user, this page will initially be blank.
-{{site.data.alerts.end}}
-
-<img src="{{ 'images/v20.2/ui-statements-page.png' | relative_url }}" alt="DB Console Statements Page" style="border:1px solid #eee;max-width:100%" />
-
-Parameter | Description
------|------------
-Statement | SQL statement [fingerprint](#sql-statement-fingerprints).<br><br>To view additional details of a SQL statement fingerprint, click this to open the [**Statement Details** page](#statement-details-page).
-Txn Type | Type of transaction (implicit or explicit). Explicit transactions refer to statements that are wrapped by [`BEGIN`](begin-transaction.html) and [`COMMIT`](commit-transaction.html) statements by the client. Explicit transactions employ [transactional pipelining](architecture/transaction-layer.html#transaction-pipelining) and therefore report latencies that do not account for replication.<br><br>For statements not in explicit transactions, CockroachDB wraps each statement in individual implicit transactions.
-Retries | Cumulative number of [retries](transactions.html#transaction-retries) of statements with this fingerprint within the last hour or specified [time interval](#time-interval).
-Execution Count | Cumulative number of executions of statements with this fingerprint within the last hour or specified [time interval](#time-interval). <br><br>The bar indicates the ratio of runtime success (gray) to [retries](transactions.html#transaction-retries) (red) for the SQL statement fingerprint.
-Rows Affected | Average number of rows returned while executing statements with this fingerprint within the last hour or specified [time interval](#time-interval). <br><br>The gray bar indicates the mean number of rows returned. The blue bar indicates one standard deviation from the mean.
-Latency | Average service latency of statements with this fingerprint within the last hour or specified [time interval](#time-interval). Service latency is the time taken to execute a query once it is received by the cluster. It does not include the time taken to send the query to the cluster or return the result to the client. <br><br>The gray bar indicates the mean latency. The blue bar indicates one standard deviation from the mean.
-Diagnostics |  Option to activate [diagnostics](#diagnostics) for this fingerprint. If activated, this displays the status of diagnostics collection (`WAITING FOR QUERY`, `READY`, OR `ERROR`). When `READY`, the most recent diagnostics bundle can be downloaded here. Access the full history of diagnostics for the fingerprint in the [**Statement Details**](#statement-details-page) page.
-
-### Time interval
-
-By default, the Statements page displays all SQL statements executed within a one-hour time interval. The display is cleared at the end of each interval. You can change the interval with the [`diagnostics.reporting.interval`](cluster-settings.html#settings) cluster setting.
-
-### SQL statement fingerprints
-
-The Statements page displays SQL statement *fingerprints*.
-
-A statement fingerprint represents one or more SQL statements by replacing literal values (e.g., numbers and strings) with underscores (`_`). This can help you quickly identify frequently executed SQL statements and their latencies.
-
-For multiple SQL statements to be represented by a fingerprint, they must be identical aside from their literal values:
-
-- <code style="white-space:pre-wrap">INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)</code>
-- <code style="white-space:pre-wrap">INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (192, 891, 20)</code>
-- <code style="white-space:pre-wrap">INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (784, 452, 78)</code>
-
-The above SQL statements have the fingerprint:
-
-<code style="white-space:pre-wrap">INSERT INTO new_order(product_id, customer_id, no_w_id) VALUES (_, _, _)</code>
-
-The following statements cannot be represented by the same fingerprint:
-
-- <code style="white-space:pre-wrap">INSERT INTO orders(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)</code>
-- <code style="white-space:pre-wrap">INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES (380, 11, 11098)</code>
-- <code style="white-space:pre-wrap">INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, 11, 11098)</code>
-- <code style="white-space:pre-wrap">INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, $2, 11098)</code>
-- <code style="white-space:pre-wrap">INSERT INTO new_order(product_id, customer_id, transaction_id) VALUES ($1, $2, $3)</code>
-
-It is possible to see the same fingerprint listed multiple times in the following scenarios:
-
-- Statements with this fingerprint were executed by more than one [`application_name`](show-vars.html#supported-variables).
-- Statements with this fingerprint were executed both successfully and unsuccessfully.
-
-## Statement Details page
-
-Click on a SQL statement fingerprint to open **Statement Details**. For each statement fingerprint, the details include:
-
-- [Overview](#overview)
-- [Diagnostics](#diagnostics)
-- [Logical plan](#logical-plan)
-- [Statistics](#execution-stats)
-
-<img src="{{ 'images/v20.2/ui_statements_details_page.png' | relative_url }}" alt="DB Console Statements Page" style="border:1px solid #eee;max-width:100%" />
-
-### Overview
-
-The **Overview** section displays the SQL statement fingerprint and essential statistics on the right-hand side of the page:
-
-- **Total Time** is the cumulative time taken to execute statements with this fingerprint within the [specified time interval](#time-interval).
-- **Mean Service Latency** is the average service latency of statements with this fingerprint within the [specified time interval](#time-interval).
-- **App** displays the name specified by the [`application_name`](show-vars.html#supported-variables) session setting.
-- **Transaction Type** displays the type of transaction (implicit or explicit).
-- **Distributed execution?** indicates whether the execution was distributed.
-- **Vectorized execution?** indicates whether the execution used the [vectorized execution engine](vectorized-execution.html).
-- **Used cost-based optimizer?** indicates whether the execution used the [cost-based optimizer](cost-based-optimizer.html).
-- **Failed?** indicates whether the execution was successful.
-
-**Execution Count** displays execution statistics for the SQL statement fingerprint.
-
-- **First Attempts** is the cumulative number of first attempts at executing statements with this fingerprint within the [specified time interval](#time-interval).
-- **Retries** is the cumulative number of [retries](transactions.html#transaction-retries) of statements with this fingerprint within the [specified time interval](#time-interval).
-- **Max Retries** is the highest number of retries of a single statement with this fingerprint within the [specified time interval](#time-interval). For example, if three statements with the same fingerprint had to be retried 0, 1, and 5 times, then the Max Retries value for the fingerprint is 5.
-- **Total** is the total number of executions of statements with this fingerprint. It is calculated as the sum of first attempts and retries.
-
-**Rows Affected** displays statistics on rows returned for the SQL statement fingerprint.
-
-- **Mean Rows** is the average number of rows returned while executing statements with this fingerprint within the [specified time interval](#time-interval).
-- **Standard Deviation** is the value of one standard deviation of the mean.
-
-### Diagnostics
-
-The **Diagnostics** section of the Statement Details page allows you to activate and view diagnostics for the SQL statement fingerprint.
-
-When you activate diagnostics for a fingerprint, CockroachDB waits for the next SQL query that matches this fingerprint to be run on any node. On the next match, information about the SQL statement is written to a diagnostics bundle that you can download. This bundle consists of [statement traces](show-trace.html) in various formats (including a JSON file that can be [imported to Jaeger](query-behavior-troubleshooting.html#visualize-statement-traces-in-jaeger)), a physical query plan, execution statistics, and other information about the query. The bundle contents are identical to those produced by [`EXPLAIN ANALYZE (DEBUG)`](explain-analyze.html#debug-option).
-
-{{site.data.alerts.callout_success}}
-Diagnostics will be collected a maximum of *N* times for a given activated fingerprint where *N* is the number of nodes in your cluster.
-{{site.data.alerts.end}}
-
-{% include {{ page.version.version }}/sql/statement-bundle-warning.md %}
-
-<img src="{{ 'images/v20.2/ui_statements_diagnostics.png' | relative_url }}" alt="DB Console Statements Page" style="border:1px solid #eee;max-width:100%" />
-
-- Click the **Activate** button to begin collecting diagnostics for the fingerprint. This will open the list of **Statement diagnostics** with a status next to each activated diagnostic.
-	- `WAITING FOR QUERY` indicates that a SQL statement matching the fingerprint has not yet been recorded.
-	- `ERROR` indicates that the attempt at diagnostics collection failed.
-	- `READY` indicates that the diagnostics have run and can be downloaded. A download link will appear beside the status.
-- For any row with a `READY` status, click **Bundle (.zip)** to retrieve the diagnostics.
-
-The information collected in the bundle can be used to diagnose problematic SQL statements, such as [slow queries](query-behavior-troubleshooting.html#query-is-always-slow). We recommend that you share the diagnostics bundle with our [support team](support-resources.html), which can help you interpret the results. You can also import `trace-jaeger.json` into Jaeger to [visualize the statement traces](query-behavior-troubleshooting.html#visualize-statement-traces-in-jaeger).
-
-Click **All statement diagnostics** to view a complete history of your collected diagnostics, each of which can be downloaded. Although fingerprints are periodically cleared from the Statements page, all diagnostics bundles are preserved. If you need to access diagnostics that were collected for a fingerprint not present in the past [interval](#time-interval), you can find the bundle here.
-
-### Logical Plan
-
-The **Logical Plan** section displays CockroachDB's query plan for an [explainable statement](sql-grammar.html#preparable_stmt). You can use this information to optimize the query. For more information about logical plans, see [`EXPLAIN`](explain.html).
-
-<img src="{{ 'images/v20.2/ui_statements_logical_plan.png' | relative_url }}" alt="DB Console Statements Page" style="border:1px solid #eee;max-width:100%" />
-
-By default, the logical plan for each fingerprint is sampled every 5 minutes. You can change the interval with the [`sql.metrics.statement_details.plan_collection.period`](cluster-settings.html#settings) cluster setting. 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';
-~~~
-
-### Execution Stats
-
-**Execution Latency by Phase** displays the service latency of statements matching this fingerprint, broken down by [phase](architecture/sql-layer.html#sql-parser-planner-executor) (parse, plan, run, overhead), as well as the overall service latency. The gray bar indicates the mean latency. The blue bar indicates one standard deviation from the mean.
-
-{{site.data.alerts.callout_success}}
-"Overhead" comprises the statements that remain after subtracting parse, plan, and run latencies from the overall latency. These might include fetching table descriptors that were not cached, or other background tasks required to execute the query.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Service latency can be affected by network latency, which is displayed for your cluster on the [Network Latency](ui-network-latency-page.html) page.
-{{site.data.alerts.end}}
-
-**Other Execution Statistics** displays the following statistics.
-
-Parameter | Description
-----------|------------
-Rows Read | The number of rows read by the statement. The gray bar indicates the mean number of rows read. The blue bar indicates one standard deviation from the mean.
-Disk Bytes Read | The size of the data read by the statement. The gray bar indicates the mean number of bytes read. The blue bar indicates one standard deviation from the mean.
-
-The **Statistics by Node** table provides a breakdown of the number of statements of the selected fingerprint per gateway node. You can use this table to determine whether, for example, you are executing queries on a node that is far from the data you are requesting (see [Optimize Query Performance](make-queries-fast.html#cluster-topology)).
-
-Parameter | Description
------|------------
-Node | ID of the gateway node.
-Retries | Cumulative number of [retries](transactions.html#transaction-retries) of statements with this fingerprint within the last hour or specified [time interval](#time-interval).
-Execution Count | Cumulative number of executions of statements with this fingerprint within the last hour or specified [time interval](#time-interval).
-Rows Affected | Average number of rows returned while executing statements with this fingerprint within the last hour or specified [time interval](#time-interval). <br><br>The gray bar indicates the mean number of rows returned. The blue bar indicates one standard deviation from the mean.
-Latency | Average service latency of statements with this fingerprint within the last hour or specified [time interval](#time-interval). Service latency is the time taken to execute a query once it is received by the cluster. It does not include the time taken to return the result to the client. <br><br>The gray bar indicates the mean latency. The blue bar indicates one standard deviation from the mean.
-
-## See also
-
-- [Troubleshoot Query Behavior](query-behavior-troubleshooting.html)
-- [Transaction retries](transactions.html#transaction-retries)
-- [Optimize Query Performance](make-queries-fast.html)
-- [Support Resources](support-resources.html)
-- [Raw Status Endpoints](monitoring-and-alerting.html#raw-status-endpoints)
diff --git a/src/current/v20.2/ui-storage-dashboard.md b/src/current/v20.2/ui-storage-dashboard.md
deleted file mode 100644
index 088ee68a876..00000000000
--- a/src/current/v20.2/ui-storage-dashboard.md
+++ /dev/null
@@ -1,95 +0,0 @@
----
-title: Storage Dashboard
-summary: The Storage dashboard lets you monitor the storage utilization of your cluster.
-toc: true
----
-
-The **Storage** dashboard lets you monitor the storage utilization of your cluster.
-
-To view this dashboard, [access the DB Console](ui-overview.html#db-console-access), click **Metrics** in the left-hand navigation, and select **Dashboard** > **Storage**.
-
-{% include {{ page.version.version }}/ui/ui-metrics-navigation.md %}
-
-The **Storage** dashboard displays the following time series graphs:
-
-## Capacity
-
-You can monitor the **Capacity** graph to determine when additional storage is needed (e.g., by [scaling your cluster](cockroach-start.html)).
-
-<img src="{{ 'images/v20.2/ui_capacity.png' | relative_url }}" alt="DB Console Capacity graph" style="border:1px solid #eee;max-width:100%" />
-
-Metric | Description
---------|--------
-**Capacity** | The maximum store size. This value may be set per node using [`--store`](cockroach-start.html#store). If a store size has not been set, this metric displays the actual disk capacity. See [Capacity metrics](#capacity-metrics).
-**Available** | The free disk space available to CockroachDB data.
-**Used** | The disk space in use by CockroachDB data. This excludes the Cockroach binary, operating system, and other system files.
-
-### Capacity metrics
-
-The **Capacity** graph displays disk usage by CockroachDB data in relation to the maximum [store](architecture/storage-layer.html) size, which is determined as follows:
-
-- If a store size was specified using the [`--store`](cockroach-start.html#store) flag when starting nodes, this value is used as the limit for CockroachDB data.
-- If no store size has been explicitly set, the actual disk capacity is used as the limit for CockroachDB data.
-
-The **available** capacity thus equals the amount of empty disk space, up to the value of the maximum store size. The **used** capacity refers only to disk space occupied by CockroachDB data, which resides in the store directory on each node.
-
-The disk usage of the Cockroach binary, operating system, and other system files is not shown on the **Capacity** graph.
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/misc/available-capacity-metric.md %}
-{{site.data.alerts.end}}
-
-## Live Bytes
-
-The **Live Bytes** graph displays the amount of data that can be read by applications and CockroachDB.
-
-<img src="{{ 'images/v20.2/ui_live_bytes.png' | relative_url }}" alt="DB Console Replicas per Store" style="border:1px solid #eee;max-width:100%" />
-
-Metric | Description
---------|--------
-**Live** | Number of logical bytes stored in live [key-value pairs](architecture/distribution-layer.html#table-data). Live data excludes historical and deleted data.
-**System** | Number of physical bytes stored in [system key-value pairs](architecture/distribution-layer.html#meta-ranges). This includes historical and deleted data that has not been [garbage collected](architecture/storage-layer.html#garbage-collection).
-
-{{site.data.alerts.callout_info}}
-{% include {{ page.version.version }}/ui/logical-bytes.md %}
-{{site.data.alerts.end}}
-
-## File Descriptors
-
-<img src="{{ 'images/v20.2/ui_file_descriptors.png' | relative_url }}" alt="DB Console File Descriptors" style="border:1px solid #eee;max-width:100%" />
-
-- 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 DB Console 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:
-
-- Log Commit Latency: 99th Percentile
-- Log Commit Latency: 50th Percentile
-- Command Commit Latency: 99th Percentile
-- Command Commit Latency: 50th Percentile
-- 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.
-
-{% include {{ page.version.version }}/ui/ui-summary-events.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/v20.2/ui-transactions-page.md b/src/current/v20.2/ui-transactions-page.md
deleted file mode 100644
index 7eaa4ccb03c..00000000000
--- a/src/current/v20.2/ui-transactions-page.md
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: Transactions Page
-summary: The Transactions page helps you identify frequently retried or high latency transactions and view transaction details.
-toc: true
----
-
-{{site.data.alerts.callout_info}}
-On a secure cluster, this area of the DB Console can only be accessed by an `admin` user. See [DB Console access](ui-overview.html#db-console-access).
-{{site.data.alerts.end}}
-
-<span class="version-tag">New in v20.2:</span> The **Transactions** page helps you:
-
-- Identify frequently retried or high latency transactions.
-- View transaction [details](#transaction-details-page).
-
-{{site.data.alerts.callout_success}}
-In contrast with the [**Statements** page](ui-statements-page.html), which displays [SQL statement fingerprints](ui-statements-page.html#sql-statement-fingerprints), the **Transactions** page displays SQL statement fingerprints grouped by [transaction](transactions.html).
-{{site.data.alerts.end}}
-
-To view this page, [access the DB Console](ui-overview.html#db-console-access) and click **Transactions** in the left-hand navigation.
-
-## Search and filter by application
-
-By default, this page shows transactions from all applications running on the cluster, and hides internal CockroachDB transactions.
-
-To filter the transactions by [`application_name`](connection-parameters.html#additional-connection-parameters), use the **App** pulldown in the **Filters** menu. If you haven't set `application_name` in the client connection string, it appears as `unset`.
-
-- CockroachDB's internal transactions are only displayed under the `$ internal` app.
-- Transactions from the SQL shell are displayed under the `$ cockroach sql` app.
-
-You can also search for transactions using the search bar.
-
-## Filter by transaction latency
-
-You can filter transactions in which a SQL statement fingerprint exceeds a specified latency value. Use the pulldown in the **Filters** menu.
-
-## Understand the Transactions page
-
-Use this page to identify transactions that you may want to [troubleshoot](query-behavior-troubleshooting.html), such as transactions that are experiencing high latencies, multiple [retries](transactions.html#transaction-retries), or execution failures.
-
-{{site.data.alerts.callout_success}}
-If you haven't yet run any transactions in the cluster as a user, this page will display a blank table.
-{{site.data.alerts.end}}
-
-<img src="{{ 'images/v20.2/ui-transactions-page.png' | relative_url }}" alt="DB Console Statements Page" style="border:1px solid #eee;max-width:100%" />
-
-Parameter | Description
------|------------
-Transactions | Transaction.<br><br>To view the transaction fingerprint and details, click this to open the [**Transaction Details** page](#transaction-details-page).
-Statements | Number of SQL statements in the transaction.
-Retries | Cumulative number of [retries](transactions.html#transaction-retries) of this transaction within the last hour or specified [time interval](ui-statements-page.html#time-interval).
-Execution Count | Cumulative number of executions of this transaction within the last hour or specified [time interval](#time-interval). <br><br>The bar indicates the ratio of runtime success (gray) to [retries](transactions.html#transaction-retries) (red) for the transaction.
-Rows Affected | Average number of rows returned while executing this transaction within the last hour or specified [time interval](#time-interval). <br><br>The gray bar indicates the mean number of rows returned. The blue bar indicates one standard deviation from the mean.
-Latency | Average service latency of this transaction within the last hour or specified [time interval](#time-interval). This includes the total time the transaction remains open, which can exceed the latency of the SQL statements in the transaction. To view the SQL statement latency for this transaction, see the [**Transaction Details** page](#transaction-details-page). <br><br>The gray bar indicates the mean latency. The blue bar indicates one standard deviation from the mean.
-
-{{site.data.alerts.callout_info}}
-Significant transactions on your database are likely to have a high execution count or number of rows affected.
-{{site.data.alerts.end}}
-
-### Time interval
-
-By default, the Transactions page displays all transactions executed within a one-hour time interval. The display is cleared at the end of each interval. You can change the interval with the [`diagnostics.reporting.interval`](cluster-settings.html#settings) cluster setting.
-
-## Transaction Details page
-
-Click on a transaction fingerprint to open **Transaction Details**.
-
-The *transaction fingerprint* is displayed as a list of the individual [SQL statement fingerprints](ui-statements-page.html#sql-statement-fingerprints) in the transaction:
-
-<img src="{{ 'images/v20.2/ui-transactions-details-page.png' | relative_url }}" alt="DB Console Statements Page" style="border:1px solid #eee;max-width:100%" />
-
-The following details are also displayed for the SQL statements in the transaction:
-
-Parameter | Description
------|------------
-Statement | SQL statement [fingerprint](ui-statements-page.html#sql-statement-fingerprints).<br><br>To view additional details of a SQL statement fingerprint, click this to open the [**Statement Details** page](ui-statements-page.html#statement-details-page).
-Txn Type | Type of transaction (implicit or explicit). Explicit transactions refer to statements that are wrapped by [`BEGIN`](begin-transaction.html) and [`COMMIT`](commit-transaction.html) statements by the client. Explicit transactions employ [transactional pipelining](architecture/transaction-layer.html#transaction-pipelining) and therefore report latencies that do not account for replication.<br><br>For statements not in explicit transactions, CockroachDB wraps each statement in individual implicit transactions.
-Retries | Cumulative number of [retries](transactions.html#transaction-retries) of statements with this fingerprint within the last hour or specified [time interval](ui-statements-page.html#time-interval).
-Execution Count | Cumulative number of executions of statements with this fingerprint within the last hour or specified [time interval](ui-statements-page.html#time-interval). <br><br>The bar indicates the ratio of runtime success (gray) to [retries](transactions.html#transaction-retries) (red) for the SQL statement fingerprint.
-Rows Affected | Average number of rows returned while executing statements with this fingerprint within the last hour or specified [time interval](ui-statements-page.html#time-interval). <br><br>The gray bar indicates the mean number of rows returned. The blue bar indicates one standard deviation from the mean.
-Latency | Average service latency of statements with this fingerprint within the last hour or specified [time interval](ui-statements-page.html#time-interval). This includes the time taken to execute a query once it is received by the cluster. It does not include the time taken to send the query to the cluster or return the result to the client. <br><br>The gray bar indicates the mean latency. The blue bar indicates one standard deviation from the mean.
-
-## See also
-
-- [Transactions](transactions.html)
-- [Transaction Layer](architecture/transaction-layer.html)
-- [Run Multi-Statement Transactions](run-multi-statement-transactions.html)
-- [Transaction latency graphs](ui-sql-dashboard.html#transactions)
-- [Transaction retries](transactions.html#transaction-retries)
-- [DB Console Statements Page](ui-statements-page.html)
diff --git a/src/current/v20.2/unique.md b/src/current/v20.2/unique.md
deleted file mode 100644
index 8261b4ce8bf..00000000000
--- a/src/current/v20.2/unique.md
+++ /dev/null
@@ -1,142 +0,0 @@
----
-title: Unique Constraint
-summary: The UNIQUE constraint specifies that each non-NULL value in the constrained column must be unique.
-toc: true
----
-
-The `UNIQUE` [constraint](constraints.html) specifies that each non-`NULL` value in the constrained column must be unique.
-
-
-## Details
-
-- You can insert `NULL` values into columns with the `UNIQUE` constraint because `NULL` is the absence of a value, so it is never equal to other `NULL` values and not considered a duplicate value. This means that it's possible to insert rows that appear to be duplicates if one of the values is `NULL`.
-
-    If you need to strictly enforce uniqueness, use the [`NOT NULL` constraint](not-null.html) in addition to the `UNIQUE` constraint. You can also achieve the same behavior through the table's [Primary Key](primary-key.html).
-
-- Columns with the `UNIQUE` constraint automatically have an [index](indexes.html) created with the name `<table name>_<columns>_key`. To avoid having two identical indexes, you should not create indexes that exactly match the `UNIQUE` constraint's columns and order.
-
-    The `UNIQUE` constraint depends on the automatically created index, so dropping the index also drops the `UNIQUE` constraint.
-
-- When using the `UNIQUE` constraint on multiple columns, the collective values of the columns must be unique. This *does not* mean that each value in each column must be unique, as if you had applied the `UNIQUE` constraint to each column individually.
-
-- You can define the `UNIQUE` constraint when [creating a table](#syntax), or you can add it to existing tables through [`ADD CONSTRAINT`](add-constraint.html#add-the-unique-constraint).
-
-## Syntax
-
-`UNIQUE` constraints can be defined at the [table level](#table-level). However, if you only want the constraint to apply to a single column, it can be applied at the [column level](#column-level).
-
-### Column level
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/unique_column_level.html %}
-</div>
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table you're creating.
-`column_name` | The name of the constrained column.
-`column_type` | The constrained column's [data type](data-types.html).
-`column_constraints` | Any other column-level [constraints](constraints.html) you want to apply to this column.
-`column_def` | Definitions for any other columns in the table.
-`table_constraints` | Any table-level [constraints](constraints.html) you want to apply.
-
-**Example**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE warehouses (
-    warehouse_id    INT        PRIMARY KEY NOT NULL,
-    warehouse_name  STRING(35) UNIQUE,
-    location_id     INT
-  );
-~~~
-
-### Table level
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/unique_table_level.html %}
-</div>
-
-Parameter | Description
-----------|------------
-`table_name` | The name of the table you're creating.
-`column_def` | Definitions for any other columns in the table.
-`name` | The name you want to use for the constraint, which must be unique to its table and follow these [identifier rules](keywords-and-identifiers.html#identifiers).
-`column_name` | The name of the column you want to constrain.
-`table_constraints` | Any other table-level [constraints](constraints.html) you want to apply.
-
-**Example**
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE logon (
-    login_id  INT PRIMARY KEY,
-    customer_id   INT,
-    logon_date    TIMESTAMP,
-    UNIQUE (customer_id, logon_date)
-  );
-~~~
-
-## Usage example
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE IF NOT EXISTS logon (
-    login_id INT PRIMARY KEY,
-    customer_id   INT NOT NULL,
-    sales_id INT,
-    UNIQUE (customer_id, sales_id)
-  );
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO logon (login_id, customer_id, sales_id) VALUES (1, 2, 1);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO logon (login_id, customer_id, sales_id) VALUES (2, 2, 1);
-~~~
-
-~~~
-duplicate key value (customer_id,sales_id)=(2,1) violates unique constraint "logon_customer_id_sales_id_key"
-~~~
-
-As mentioned in the [details](#details) above, it is possible when using the `UNIQUE` constraint alone to insert *NULL* values in a way that causes rows to appear to have rows with duplicate values.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO logon (login_id, customer_id, sales_id) VALUES (3, 2, NULL);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO logon (login_id, customer_id, sales_id) VALUES (4, 2, NULL);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT customer_id, sales_id FROM logon;
-~~~
-
-~~~
-+-------------+----------+
-| customer_id | sales_id |
-+-------------+----------+
-|           2 |        1 |
-|           2 | NULL     |
-|           2 | NULL     |
-+-------------+----------+
-~~~
-
-## See also
-
-- [Constraints](constraints.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`CHECK` constraint](check.html)
-- [`DEFAULT` value constraint](default-value.html)
-- [Foreign key constraint](foreign-key.html)
-- [`NOT NULL` constraint](not-null.html)
-- [`PRIMARY` key constraint](primary-key.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
diff --git a/src/current/v20.2/unsplit-at.md b/src/current/v20.2/unsplit-at.md
deleted file mode 100644
index e2afc40e99b..00000000000
--- a/src/current/v20.2/unsplit-at.md
+++ /dev/null
@@ -1,190 +0,0 @@
----
-title: UNSPLIT AT
-summary: The UNSPLIT AT statement removes a range split enforcement at a specified row in the table or index.
-toc: true
----
-
-The `UNSPLIT AT` [statement](sql-statements.html) removes a [split enforcement](split-at.html) on a [range split](architecture/distribution-layer.html#range-splits), at a specified row in a table or index.
-
-Removing a split enforcement from a table or index ("unsplitting") allows CockroachDB to merge ranges as needed, to help improve your cluster's performance. For more information, see [Range Merges](architecture/distribution-layer.html#range-merges).
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/unsplit_table_at.html %}
-</div>
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/unsplit_index_at.html %}
-</div>
-
-## Required privileges
-
-The user must have the `INSERT` [privilege](authorization.html#assign-privileges) on the table or index.
-
-## Parameters
-
- Parameter | Description
------------|-------------
- `table_name` | The name of the table that you want to unsplit.
- `table_name @ index_name`<br>`standalone_index_name` | The name of the index that you want to unsplit.
- `select_stmt` | A [selection query](selection-queries.html) that produces one or more rows at which to unsplit a table or index.
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements-nodes.md %}
-
-### Unsplit a table
-
-The `crdb_internal.ranges` table contains information about ranges in your CockroachDB cluster. At this point, just one range contains the data in the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT range_id, start_pretty, end_pretty, split_enforced_until FROM crdb_internal.ranges WHERE table_name='users';
-~~~
-~~~
-  range_id | start_pretty | end_pretty | split_enforced_until
-+----------+--------------+------------+----------------------+
-        21 | /Table/53    | /Table/54  | NULL
-(1 row)
-~~~
-
-Now [split](split-at.html) the `users` table ranges based on primary key values:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users SPLIT AT VALUES ('chicago'), ('new york'), ('seattle');
-~~~
-~~~
-              key              |         pretty         |       split_enforced_until
-+------------------------------+------------------------+----------------------------------+
-  \275\211\022chicago\000\001  | /Table/53/1/"chicago"  | 2262-04-11 23:47:16.854776+00:00
-  \275\211\022new york\000\001 | /Table/53/1/"new york" | 2262-04-11 23:47:16.854776+00:00
-  \275\211\022seattle\000\001  | /Table/53/1/"seattle"  | 2262-04-11 23:47:16.854776+00:00
-(3 rows)
-~~~
-
-You can see the additional ranges in the `crdb_internal.ranges` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT range_id, start_pretty, end_pretty, split_enforced_until FROM crdb_internal.ranges WHERE table_name='users';
-~~~
-~~~
-  range_id |      start_pretty      |       end_pretty       |       split_enforced_until
-+----------+------------------------+------------------------+----------------------------------+
-        21 | /Table/53              | /Table/53/1/"chicago"  | NULL
-        27 | /Table/53/1/"chicago"  | /Table/53/1/"new york" | 2262-04-11 23:47:16.854776+00:00
-        28 | /Table/53/1/"new york" | /Table/53/1/"seattle"  | 2262-04-11 23:47:16.854776+00:00
-        29 | /Table/53/1/"seattle"  | /Table/54              | 2262-04-11 23:47:16.854776+00:00
-(4 rows)
-~~~
-
-Now unsplit the table to remove the split enforcements:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE users UNSPLIT AT VALUES ('chicago'), ('new york'), ('seattle');
-~~~
-~~~
-              key              |         pretty
-+------------------------------+------------------------+
-  \275\211\022chicago\000\001  | /Table/53/1/"chicago"
-  \275\211\022new york\000\001 | /Table/53/1/"new york"
-  \275\211\022seattle\000\001  | /Table/53/1/"seattle"
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT range_id, start_pretty, end_pretty, split_enforced_until FROM crdb_internal.ranges WHERE table_name='users';
-~~~
-~~~
-  range_id |      start_pretty      |       end_pretty       | split_enforced_until
-+----------+------------------------+------------------------+----------------------+
-        21 | /Table/53              | /Table/53/1/"chicago"  | NULL
-        27 | /Table/53/1/"chicago"  | /Table/53/1/"new york" | NULL
-        28 | /Table/53/1/"new york" | /Table/53/1/"seattle"  | NULL
-        29 | /Table/53/1/"seattle"  | /Table/54              | NULL
-(4 rows)
-~~~
-
-The `users` table is still split into ranges at `'chicago'`, `'new york'`, and `'seattle'`, but the `split_enforced_until` column is now `NULL` for all ranges in the table. The split is no longer enforced, and CockroachDB can [merge the data](architecture/distribution-layer.html#range-merges) in the table as needed.
-
-### Unsplit an index
-
-Add a new secondary [index](indexes.html) to the `rides` table, on the `revenue` column, and then [split](split-at.html) the table ranges by secondary index values:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX revenue_idx ON rides(revenue);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX rides@revenue_idx SPLIT AT VALUES (25.00), (50.00), (75.00);
-~~~
-~~~
-         key        |      pretty      |       split_enforced_until
-+-------------------+------------------+----------------------------------+
-  \277\214*2\000    | /Table/55/4/25   | 2262-04-11 23:47:16.854776+00:00
-  \277\214*d\000    | /Table/55/4/5E+1 | 2262-04-11 23:47:16.854776+00:00
-  \277\214*\226\000 | /Table/55/4/75   | 2262-04-11 23:47:16.854776+00:00
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT range_id, start_pretty, end_pretty, split_enforced_until FROM crdb_internal.ranges WHERE table_name='rides';
-~~~
-~~~
-  range_id |   start_pretty   |    end_pretty    |       split_enforced_until
-+----------+------------------+------------------+----------------------------------+
-        23 | /Table/55        | /Table/55/4      | NULL
-        32 | /Table/55/4      | /Table/55/4/25   | 2019-09-10 21:27:35.056275+00:00
-        33 | /Table/55/4/25   | /Table/55/4/5E+1 | 2262-04-11 23:47:16.854776+00:00
-        34 | /Table/55/4/5E+1 | /Table/55/4/75   | 2262-04-11 23:47:16.854776+00:00
-        35 | /Table/55/4/75   | /Table/56        | 2262-04-11 23:47:16.854776+00:00
-(5 rows)
-~~~
-
-Now unsplit the index to remove the split enforcements:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER INDEX rides@revenue_idx UNSPLIT AT VALUES (25.00), (50.00), (75.00);
-~~~
-~~~
-         key        |      pretty
-+-------------------+------------------+
-  \277\214*2\000    | /Table/55/4/25
-  \277\214*d\000    | /Table/55/4/5E+1
-  \277\214*\226\000 | /Table/55/4/75
-(3 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT range_id, start_pretty, end_pretty, split_enforced_until FROM crdb_internal.ranges WHERE table_name='rides';
-~~~
-~~~
-  range_id |   start_pretty   |    end_pretty    |       split_enforced_until
-+----------+------------------+------------------+----------------------------------+
-        23 | /Table/55        | /Table/55/4      | NULL
-        32 | /Table/55/4      | /Table/55/4/25   | 2019-09-10 21:27:35.056275+00:00
-        33 | /Table/55/4/25   | /Table/55/4/5E+1 | NULL
-        34 | /Table/55/4/5E+1 | /Table/55/4/75   | NULL
-        35 | /Table/55/4/75   | /Table/56        | NULL
-(5 rows)
-~~~
-
-The table is still split into ranges at `25.00`, `50.00`, and `75.00`, but the `split_enforced_until` column is now `NULL` for all ranges in the table. The split is no longer enforced, and CockroachDB can [merge the data](architecture/distribution-layer.html#range-merges) in the table as needed.
-
-## See also
-
-- [`SPLIT AT`](split-at.html)
-- [Selection Queries](selection-queries.html)
-- [Distribution Layer](architecture/distribution-layer.html)
-- [Range Merges](architecture/distribution-layer.html#range-merges)
-- [Replication Layer](architecture/replication-layer.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/update-data.md b/src/current/v20.2/update-data.md
deleted file mode 100644
index 2e31afadee9..00000000000
--- a/src/current/v20.2/update-data.md
+++ /dev/null
@@ -1,435 +0,0 @@
----
-title: Update Data
-summary: How to update the data in CockroachDB from various programming languages
-toc: true
----
-
-This page has instructions for updating existing rows of data in CockroachDB, using the following [SQL statements](sql-statements.html):
-
-- [`UPDATE`](#use-update), which updates existing rows in a table.
-- [`UPSERT`](#use-upsert), which inserts new rows in a table, updating existing rows that conflict on a primary key.
-- [`INSERT ... ON CONFLICT ... DO UPDATE`](#use-insert-on-conflict), which inserts new rows in a table, updating existing rows in the event of a conflict on specified, `UNIQUE`-constrained columns.
-
-## Before you begin
-
-Before reading this page, do the following:
-
-- [Install CockroachDB](install-cockroachdb.html).
-- [Start a local cluster](secure-a-cluster.html), or [create a CockroachDB {{ site.data.products.cloud }} cluster](../cockroachcloud/create-your-cluster.html).
-- [Install a Postgres client](install-client-drivers.html).
-- [Connect to the database](connect-to-the-database.html).
-- [Create a database schema](schema-design-overview.html).
-- [Insert data](insert-data.html) that you now want to update.
-
-    In the examples on this page, we use sample [`movr`](movr.html) data imported with the [`cockroach workload` command](cockroach-workload.html).
-
-## Use `UPDATE`
-
-To update existing rows in a table, use an [`UPDATE` statement](update.html) with a `WHERE` clause that filters on the columns that identify the rows that you want to update.
-
-{{site.data.alerts.callout_info}}
-To update a large number of rows (i.e., tens of thousands of rows or more), we recommend iteratively updating subsets of the rows that you want to update, until all of the rows have been updated. You can write a script to do this, or you can write a loop into your application.
-
-For guidance and an example, see [Bulk-update Data](bulk-update-data.html).
-{{site.data.alerts.end}}
-
-### `UPDATE` SQL syntax
-
-In SQL, `UPDATE` statements generally take the following form:
-
-~~~
-UPDATE {table} SET {update_column} = {update_value} WHERE {filter_column} = {filter_value}
-~~~
-
-Where:
-
-- `{table}` is the table to update.
-- `{update_column}` is the column to update.
-- `{update_value}` is the new value of the column in the matching row.
-- `{filter_column}` is the column to filter on.
-- `{filter_value}` is the matching value for the filter.
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `UPDATE` statement, including additional examples, see the [`UPDATE` syntax page](update.html).
-{{site.data.alerts.end}}
-
-### `UPDATE` best practices
-
-Here are some best practices to follow when updating rows:
-
-- Always specify a `WHERE` clause in `UPDATE` queries. If no `WHERE` clause is specified, CockroachDB will update all of the rows in the specified table.
-- To update a large number of rows (i.e., tens of thousands of rows or more), use a [batch-update loop](bulk-update-data.html).
-- When executing `UPDATE` statements from an application, make sure that you wrap the SQL-executing functions in [a retry loop that handles transaction errors](error-handling-and-troubleshooting.html#transaction-retry-errors) that can occur under contention.
-
-### `UPDATE` example
-
-Suppose you want to change the status of all of the vehicles owned by a particular MovR user. To update all rows in the `vehicles` table with the `owner_id` equal to `bd70a3d7-0a3d-4000-8000-000000000025`:
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go (lib/pq)</button>
-  <button class="filter-button" data-scope="java">Java (JDBC)</button>
-  <button class="filter-button" data-scope="python">Python (psycopg2)</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ sql
-UPDATE vehicle SET status = 'unavailable' WHERE owner_id = 'bd70a3d7-0a3d-4000-8000-000000000025';
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-// 'db' is an open database connection
-
-ownerID := "bd70a3d7-0a3d-4000-8000-000000000025"
-
-if _, err := db.Exec("UPDATE vehicle SET status = 'unavailable' WHERE owner_id = $1", ownerID); err != nil {
-  return err
-}
-return nil
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-// ds is an org.postgresql.ds.PGSimpleDataSource
-
-String ownerId = "bd70a3d7-0a3d-4000-8000-000000000025";
-
-try (Connection connection = ds.getConnection()) {
-    PreparedStatement p = connection.prepareStatement("UPDATE vehicles SET status = 'unavailable' WHERE owner_id = ?");
-    p.setString(1, ownerId);
-    p.executeUpdate();
-
-} catch (SQLException e) {
-    System.out.printf("sql state = [%s]\ncause = [%s]\nmessage = [%s]\n", e.getSQLState(), e.getCause(),
-            e.getMessage());
-}
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-# conn is a psycopg2 connection
-
-ownerID = 'bd70a3d7-0a3d-4000-8000-000000000025'
-
-with conn.cursor() as cur:
-    cur.execute(
-        "UPDATE vehicles SET status = 'unavailable' WHERE owner_id = %s", (ownerID,))
-~~~
-
-</section>
-
-## Use `UPSERT`
-
-To insert new rows into a table, and update rows that conflict with the primary key value(s) of the new rows, use an [`UPSERT` statement](upsert.html).
-
-### `UPSERT` SQL syntax
-
-In SQL, `UPSERT` statements take the following form:
-
-~~~
-UPSERT INTO {table} ({upsert_columns}) VALUES ({upsert_values});
-~~~
-
-Where:
-
-- `{table}` is the table to update.
-- `{upsert_columns}` is a comma-separated list of the columns to which you want to insert values.
-- `{upsert_values}` is a comma-separated list of values that you want to insert.
-
-{{site.data.alerts.callout_success}}
-For detailed reference documentation on the `UPSERT` statement, including additional examples, see the [`UPSERT` syntax page](upsert.html).
-{{site.data.alerts.end}}
-
-### `UPSERT` best practices
-
-Here are some best practices to follow when using `UPSERT`:
-
-- Limit the number of `UPSERT` statements that you execute. It's more efficient to insert multiple rows with a single statement than to execute multiple `UPSERT` statements that each insert a single row.
-- When executing `UPSERT` statements from an application, make sure that you wrap the SQL-executing functions in [a retry loop that handles transaction errors](error-handling-and-troubleshooting.html#transaction-retry-errors) that can occur under contention.
-
-### `UPSERT` example
-
-Suppose you want to add some promo codes to the MovR platform, and overwrite any existing promos with the same code. To insert new rows into the `promo_codes` table, and update any rows that have the same primary key `code` value:
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go (lib/pq)</button>
-  <button class="filter-button" data-scope="java">Java (JDBC)</button>
-  <button class="filter-button" data-scope="python">Python (psycopg2)</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ sql
-UPSERT INTO promo_codes (code, description, rules)
-  VALUES ('0_explain_theory_something','Fifteen percent off.', '{"type": "percent_discount", "value": "15%"}'),
-    ('100_address_garden_certain','Twenty percent off.','{"type": "percent_discount", "value": "20%"}'),
-    ('1000_do_write_words','Twenty-five percent off.','{"type": "percent_discount", "value": "25%"}');
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-// 'db' is an open database connection
-
-codeOne := "0_explain_theory_something"
-descriptionOne := "Fifteen percent off."
-rulesOne := `{"type": "percent_discount", "value\": "15%"}`
-codeTwo := "100_address_garden_certain"
-descriptionTwo := "Twenty percent off."
-rulesTwo := `{"type": "percent_discount", "value": "20%"}`
-codeThree := "1000_do_write_words"
-descriptionThree := "Twenty-five percent off."
-rulesThree := `{"type": "percent_discount", "value": "25%"}`
-
-if _, err := db.Exec("UPSERT INTO promo_codes (code, description, rules) "+
-  "values ($1, $2, $3), ($4, $5, $6), ($7, $8, $9)",
-  codeOne, descriptionOne, rulesOne, codeTwo, descriptionTwo,
-  rulesTwo, codeThree, descriptionThree, rulesThree); err != nil {
-  return err
-}
-return nil
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-// ds is an org.postgresql.ds.PGSimpleDataSource
-
-String codeOne = "0_explain_theory_something";
-String descriptionOne = "Fifteen percent off.";
-String rulesOne = "{\"type\": \"percent_discount\", \"value\": \"15%\"}";
-String codeTwo = "100_address_garden_certain";
-String descriptionTwo = "Twenty percent off.";
-String rulesTwo = "{\"type\": \"percent_discount\", \"value\": \"20%\"}";
-String codeThree = "1000_do_write_words";
-String descriptionThree = "Twenty-five percent off.";
-String rulesThree = "{\"type\": \"percent_discount\", \"value\": \"25%\"}";
-
-try (Connection connection = ds.getConnection()) {
-    PreparedStatement p = connection.prepareStatement("UPSERT INTO promo_codes (code, description, rules) values (?, ?, ?), (?, ?, ?), (?, ?, ?)");
-    p.setString(1, codeOne);
-    p.setString(2, descriptionOne);
-    p.setString(3, rulesOne);
-    p.setString(4, codeTwo);
-    p.setString(5, descriptionTwo);
-    p.setString(6, rulesTwo);
-    p.setString(7, codeThree);
-    p.setString(8, descriptionThree);
-    p.setString(9, rulesThree);
-    p.executeUpdate();
-
-
-} catch (SQLException e) {
-    System.out.printf("sql state = [%s]\ncause = [%s]\nmessage = [%s]\n", e.getSQLState(), e.getCause(),
-            e.getMessage());
-}
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-# conn is a psycopg2 connection
-
-codeOne = '0_explain_theory_something'
-descriptionOne = 'Fifteen percent off.'
-rulesOne = '{"type": "percent_discount", "value": "15%"}'
-codeTwo = '100_address_garden_certain'
-descriptionTwo = 'Twenty percent off.'
-rulesTwo = '{"type": "percent_discount", "value": "20%"}'
-codeThree = '1000_do_write_words'
-descriptionThree = 'Twenty-five percent off.'
-rulesThree = '{"type": "percent_discount", "value": "25%"}'
-
-with conn.cursor() as cur:
-    cur.execute("UPSERT INTO promo_codes (code, description, rules) values (%s,%s,%s), (%s,%s,%s), (%s,%s,%s)",
-                (codeOne, descriptionOne, rulesOne, codeTwo, descriptionTwo, rulesTwo, codeThree, descriptionThree, rulesThree))
-~~~
-
-</section>
-
-## Use `INSERT ON CONFLICT`
-
-To insert new rows into a table, and to update rows with `UNIQUE`-constrained values that conflict with any values of the new rows, use an `INSERT ... ON CONFLICT ... DO UPDATE` statement.
-
-`INSERT ... ON CONFLICT ... DO UPDATE` is semantically identical to `UPSERT`, when the conflicting values are in the primary key and the action to take on conflict is to update the conflicting rows with the new rows. `INSERT ... ON CONFLICT` is more flexible than `UPSERT`, and can be used to consider uniqueness for columns not in the primary key. With `INSERT ... ON CONFLICT`, you can also control how to update rows in the event of a conflict. This contrasts with the behavior of an `UPSERT` statement, which just overwrites conflicting rows with new rows.
-
-{{site.data.alerts.callout_info}}
- Note that if you are inserting to/updating all columns of a table, and the table has no secondary indexes, `UPSERT` will be faster than the equivalent `INSERT ON CONFLICT` statement, as it will write without first reading.
-{{site.data.alerts.end}}
-
-### `INSERT ON CONFLICT` SQL syntax
-
-In SQL, `INSERT ... ON CONFLICT ... DO UPDATE` statements take the following form:
-
-~~~
-INSERT INTO {table} ({insert_columns}) VALUES ({insert_values})
-  ON CONFLICT ({conflict_columns}) DO UPDATE SET {update_column} = {update value};
-~~~
-
-Where:
-
-- `{table}` is the table to update.
-- `{insert_columns}` is a comma-separated list of the columns to which you want to insert values.
-- `{insert_values}` is a comma-separated list of values that you want to insert.
-- `{conflict_columns}` is a comma-separated list of the columns to evaluate for a conflict.
-- `{update_column}` is the column to update, on conflict.
-- `{update_values}` is the value to assign the update column.
-
-Note that the statement contains an `UPDATE` clause, which is semantically identical to an `UPDATE` statement.
-
-### `INSERT ON CONFLICT` best practices
-
-Here are some best practices to follow when using `INSERT ... ON CONFLICT ... DO UPDATE`:
-
-- Limit the number of `INSERT` statements that you execute. It's more efficient to insert multiple rows with a single statement than to execute multiple `INSERT` statements that each insert a single row.
-- When executing `INSERT` statements from an application, make sure that you wrap the SQL-executing functions in [a retry loop that handles transaction errors](error-handling-and-troubleshooting.html#transaction-retry-errors) that can occur under contention.
-- Follow the [performance best practices listed on the `INSERT`](insert.html#performance-best-practices) page.
-
-### `INSERT ON CONFLICT` example
-
-Suppose you want to record a particular user's promo code usage count. The `user_promo_codes` table keeps track of user promo usage. If no usage counter exists, you want to insert a new row, and if one does exist, you want to increment the `usage_count` column by 1.
-
-<div class="filters clearfix">
-  <button class="filter-button" data-scope="sql">SQL</button>
-  <button class="filter-button" data-scope="go">Go (lib/pq)</button>
-  <button class="filter-button" data-scope="java">Java (JDBC)</button>
-  <button class="filter-button" data-scope="python">Python (psycopg2)</button>
-</div>
-
-<section class="filter-content" markdown="1" data-scope="sql">
-
-{% include copy-clipboard.html %}
-~~~ sql
-INSERT INTO user_promo_codes (city, user_id, code, "timestamp", usage_count)
-    VALUES ('new york', '147ae147-ae14-4b00-8000-000000000004', 'promo_code', now(), 1)
-    ON CONFLICT (city, user_id, code)
-    DO UPDATE SET usage_count = user_promo_codes.usage_count;
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-
-{% include copy-clipboard.html %}
-~~~ go
-// 'db' is an open database connection
-
-city := "new york"
-userId := "147ae147-ae14-4b00-8000-000000000004"
-code := "promo_code"
-ts := "now()"
-usageCount := 1
-
-if _, err := db.Exec("INSERT INTO user_promo_codes "+
-  "VALUES ($1, $2, $3, $4, $5) ON CONFLICT (city, user_id, code) "+
-  "DO UPDATE SET usage_count = user_promo_codes.usage_count + 1",
-  city, userId, code, ts, usageCount); err != nil {
-  return err
-}
-return nil
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="java">
-
-{% include copy-clipboard.html %}
-~~~ java
-// ds is an org.postgresql.ds.PGSimpleDataSource
-
-String city = "new york";
-String userId = "147ae147-ae14-4b00-8000-000000000004";
-String code = "promo_code";
-String ts = "now()";
-int usageCount = 1;
-
-try (Connection connection = ds.getConnection()) {
-    PreparedStatement p = connection.prepareStatement("INSERT INTO user_promo_codes VALUES (?, ?, ?, ?, ?) ON CONFLICT (city, user_id, code) DO UPDATE SET usage_count = user_promo_codes.usage_count+1");
-    p.setString(1, city);
-    p.setString(2, userId);
-    p.setString(3, code);
-    p.setString(4, ts);
-    p.setInt(5, usageCount);
-    p.executeUpdate();
-
-} catch (SQLException e) {
-    System.out.printf("sql state = [%s]\ncause = [%s]\nmessage = [%s]\n", e.getSQLState(), e.getCause(),
-            e.getMessage());
-}
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-
-{% include copy-clipboard.html %}
-~~~ python
-# conn is a psycopg2 connection
-
-city = 'new york'
-userId = '147ae147-ae14-4b00-8000-000000000004'
-code = 'promo_code'
-ts = 'now()'
-usageCount = 1
-
-with conn.cursor() as cur:
-    cur.execute("INSERT INTO user_promo_codes VALUES (%s, %s, %s, %s, %s) ON CONFLICT (city, user_id, code)"
-                "DO UPDATE SET usage_count = user_promo_codes.usage_count+1", (city, userId, code, ts, usageCount))
-~~~
-
-</section>
-
-## See also
-
-Reference information related to this task:
-
-- [`UPDATE`](update.html)
-- [Bulk-update Data](bulk-update-data.html)
-- [`UPSERT`](update.html)
-- [`INSERT ... ON CONFLICT`](insert.html#on-conflict-clause)
-- [Understanding and Avoiding Transaction Contention](performance-best-practices-overview.html#understanding-and-avoiding-transaction-contention)
-
-Other common tasks:
-
-- [Connect to the Database](connect-to-the-database.html)
-- [Insert Data](insert-data.html)
-- [Query Data](query-data.html)
-- [Delete Data](delete-data.html)
-- [Bulk-update Data](bulk-update-data.html)
-- [Run Multi-Statement Transactions](run-multi-statement-transactions.html)
-- [Error Handling and Troubleshooting][error_handling]
-- [Optimize Query Performance](make-queries-fast.html)
-- [Hello World Example apps](example-apps.html)
-
-<!-- Reference Links -->
-
-[error_handling]: error-handling-and-troubleshooting.html
-[manual]: manual-deployment.html
-[orchestrated]: orchestration.html
-[selection]: selection-queries.html
diff --git a/src/current/v20.2/update.md b/src/current/v20.2/update.md
deleted file mode 100644
index 1a899af2646..00000000000
--- a/src/current/v20.2/update.md
+++ /dev/null
@@ -1,606 +0,0 @@
----
-title: UPDATE
-summary: The UPDATE statement updates one or more rows in a table.
-toc: true
----
-
-The `UPDATE` [statement](sql-statements.html) updates rows in a table.
-
-{{site.data.alerts.callout_danger}}
-If you update a row that contains a column referenced by a [foreign key constraint](foreign-key.html) and has an [`ON UPDATE` action](foreign-key.html#foreign-key-actions), all of the dependent rows will also be updated.
-{{site.data.alerts.end}}
-
-
-## Required privileges
-
-The user must have the `SELECT` and `UPDATE` [privileges](authorization.html#assign-privileges) on the table.
-
-## Synopsis
-
-<div class="horizontal-scroll">
-{% include {{ page.version.version }}/sql/diagrams/update.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`common_table_expr` | See [Common Table Expressions](common-table-expressions.html).
-`table_name` | The name of the table that contains the rows you want to update.
-`AS table_alias_name` | An alias for the table name. When an alias is provided, it completely hides the actual table name.
-`column_name` | The name of the column whose values you want to update.
-`a_expr` | The new value you want to use, the [aggregate function](functions-and-operators.html#aggregate-functions) you want to perform, or the [scalar expression](scalar-expressions.html) you want to use.<br><br>To fill columns with their [default values](default-value.html), use `DEFAULT VALUES` in place of `a_expr`. To fill a specific column with its default value, leave the value out of the `a_expr` or use `DEFAULT` at the appropriate position.
-`FROM table_ref` | Specify a table to reference, but not update, in `UPDATE` expressions, or in `RETURNING` and `WHERE` clauses. For more details, see [Reference other tables in an update](#reference-other-tables-in-an-update).
-`select_stmt` | A [selection query](selection-queries.html). Each value must match the [data type](data-types.html) of its column on the left side of `=`.
-`WHERE a_expr`| `a_expr` must be a [scalar expression](scalar-expressions.html) that returns Boolean values using columns (e.g., `<column> = <value>`). Update rows that return `TRUE`.<br><br/>**Without a `WHERE` clause in your statement, `UPDATE` updates all rows in the table.**
-`sort_clause` | An `ORDER BY` clause. See [Ordering Query Results](order-by.html) and [Ordering of rows in DML statements](order-by.html#ordering-rows-in-dml-statements) for more details.
-`limit_clause` | A `LIMIT` clause. See [Limiting Query Results](limit-offset.html) for more details.
-`RETURNING target_list` | Return values based on rows updated, where `target_list` can be specific column names from the table, `*` for all columns, or computations using [scalar expressions](scalar-expressions.html). <br><br>To return nothing in the response, not even the number of rows updated, use `RETURNING NOTHING`.
-`ONLY ... *` | <span class="version-tag">New in v20.2:</span> Supported for compatibility with PostgreSQL table inheritance syntax. This clause is a no-op, as CockroachDB does not currently support table inheritance.
-
-## Force index selection for updates
-
-By using the explicit index annotation (also known as "index hinting"), you can override [CockroachDB's index selection](https://www.cockroachlabs.com/blog/index-selection-cockroachdb-2/) and use a specific [index](indexes.html) for updating rows of a named table.
-
-{{site.data.alerts.callout_info}}
-Index selection can impact [performance](performance-best-practices-overview.html), but does not change the result of a query.
-{{site.data.alerts.end}}
-
-The syntax to force an update for a specific index is:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE table@my_idx SET ...
-~~~
-
-This is equivalent to the longer expression:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE table@{FORCE_INDEX=my_idx} SET ...
-~~~
-
-To view how the index hint modifies the query plan that CockroachDB follows for updating rows, use an [`EXPLAIN (OPT)`](explain.html#opt-option) statement. To see all indexes available on a table, use [`SHOW INDEXES`](show-index.html).
-
-For examples, see [Update with index hints](#update-with-index-hints).
-
-## Reference other tables in an update
-
-To reference values from a table other than the table being updated, add a `FROM` clause that specifies one or more tables in the cluster. Values from tables specified in a `FROM` clause can be used in `UPDATE` expressions, and in `RETURNING` and `WHERE` clauses.
-
-When executing an `UPDATE` query with a `FROM` clause, CockroachDB [joins](joins.html) the target table (i.e., the table being updated) to the tables referenced in the `FROM` clause. The output of this join should have the same number of rows as the rows being updated in the target table, as CockroachDB uses a single row from the join output to update a given row in the target table. If the join produces more rows than the rows being updated in the target table, there is no way to predict which row from the join output will be used to update a row in the target table.
-
-For an example, see [Update using values from a different table](#update-using-values-from-a-different-table).
-
-## Bulk-update data
-
-To update a large number of rows (i.e., tens of thousands of rows or more), we recommend iteratively updating subsets of the rows that you want to update, until all of the rows have been updated. You can write a script to do this, or you can write a loop into your application.
-
-For guidance and an example, see [Bulk-update Data](bulk-update-data.html).
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements.md %}
-
-### Update a single column in a single row
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users LIMIT 10;
-~~~
-
-~~~
-                   id                  |   city    |        name        |            address             | credit_card
-+--------------------------------------+-----------+--------------------+--------------------------------+-------------+
-  c28f5c28-f5c2-4000-8000-000000000026 | amsterdam | Maria Weber        | 14729 Karen Radial             | 5844236997
-  c7ae147a-e147-4000-8000-000000000027 | amsterdam | Tina Miller        | 97521 Mark Extensions          | 8880478663
-  cccccccc-cccc-4000-8000-000000000028 | amsterdam | Taylor Cunningham  | 89214 Jennifer Well            | 5130593761
-  d1eb851e-b851-4800-8000-000000000029 | amsterdam | Kimberly Alexander | 48474 Alfred Hollow            | 4059628542
-  19999999-9999-4a00-8000-000000000005 | boston    | Nicole Mcmahon     | 11540 Patton Extensions        | 0303726947
-  1eb851eb-851e-4800-8000-000000000006 | boston    | Brian Campbell     | 92025 Yang Village             | 9016427332
-  23d70a3d-70a3-4800-8000-000000000007 | boston    | Carl Mcguire       | 60124 Palmer Mews Apt. 49      | 4566257702
-  28f5c28f-5c28-4600-8000-000000000008 | boston    | Jennifer Sanders   | 19121 Padilla Brooks Apt. 12   | 1350968125
-  80000000-0000-4000-8000-000000000019 | chicago   | Matthew Clay       | 49220 Lisa Junctions           | 9132291015
-  851eb851-eb85-4000-8000-00000000001a | chicago   | Samantha Coffey    | 6423 Jessica Underpass Apt. 87 | 9437219051
-(10 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE users SET address = '201 E Randolph St' WHERE id = '851eb851-eb85-4000-8000-00000000001a';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users LIMIT 10;
-~~~
-
-~~~
-                   id                  |   city    |        name        |           address            | credit_card
-+--------------------------------------+-----------+--------------------+------------------------------+-------------+
-  c28f5c28-f5c2-4000-8000-000000000026 | amsterdam | Maria Weber        | 14729 Karen Radial           | 5844236997
-  c7ae147a-e147-4000-8000-000000000027 | amsterdam | Tina Miller        | 97521 Mark Extensions        | 8880478663
-  cccccccc-cccc-4000-8000-000000000028 | amsterdam | Taylor Cunningham  | 89214 Jennifer Well          | 5130593761
-  d1eb851e-b851-4800-8000-000000000029 | amsterdam | Kimberly Alexander | 48474 Alfred Hollow          | 4059628542
-  19999999-9999-4a00-8000-000000000005 | boston    | Nicole Mcmahon     | 11540 Patton Extensions      | 0303726947
-  1eb851eb-851e-4800-8000-000000000006 | boston    | Brian Campbell     | 92025 Yang Village           | 9016427332
-  23d70a3d-70a3-4800-8000-000000000007 | boston    | Carl Mcguire       | 60124 Palmer Mews Apt. 49    | 4566257702
-  28f5c28f-5c28-4600-8000-000000000008 | boston    | Jennifer Sanders   | 19121 Padilla Brooks Apt. 12 | 1350968125
-  80000000-0000-4000-8000-000000000019 | chicago   | Matthew Clay       | 49220 Lisa Junctions         | 9132291015
-  851eb851-eb85-4000-8000-00000000001a | chicago   | Samantha Coffey    | 201 E Randolph St            | 9437219051
-(10 rows)
-~~~
-
-### Update multiple columns in a single row
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE rides SET (end_address, revenue) = ('201 E Randolph St', 25.00) WHERE id = '851eb851-eb85-4000-8000-000000000104';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM rides WHERE rider_id = '851eb851-eb85-4000-8000-00000000001a';
-~~~
-
-~~~
-                   id                  |  city   | vehicle_city |               rider_id               |              vehicle_id              |         start_address         |         end_address         |        start_time         |         end_time          | revenue
-+--------------------------------------+---------+--------------+--------------------------------------+--------------------------------------+-------------------------------+-----------------------------+---------------------------+---------------------------+---------+
-  849ba5e3-53f7-4000-8000-000000000103 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 77630 Steven Road Suite 60    | 74140 Andrew Spur           | 2018-12-30 03:04:05+00:00 | 2018-12-31 08:04:05+00:00 |   20.00
-  851eb851-eb85-4000-8000-000000000104 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 76707 Timothy Square          | 201 E Randolph St           | 2018-12-15 03:04:05+00:00 | 2018-12-17 07:04:05+00:00 |   25.00
-  86a7ef9d-b22d-4000-8000-000000000107 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 28532 Kevin Villages Suite 90 | 27493 Ortega Radial Apt. 60 | 2018-12-08 03:04:05+00:00 | 2018-12-09 03:04:05+00:00 |   36.00
-  92f1a9fb-e76c-4800-8000-00000000011f | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 56955 Edward Walks            | 53193 Jerry Village         | 2019-01-01 03:04:05+00:00 | 2019-01-01 15:04:05+00:00 |   35.00
-  94fdf3b6-45a1-4800-8000-000000000123 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 63820 Robinson Fields         | 89245 Eric Orchard          | 2018-12-14 03:04:05+00:00 | 2018-12-16 10:04:05+00:00 |   80.00
-(5 rows)
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE rides SET end_address = '10000 W OHare Ave', revenue = 60.00 WHERE id = '94fdf3b6-45a1-4800-8000-000000000123';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM rides WHERE rider_id = '851eb851-eb85-4000-8000-00000000001a';
-~~~
-
-~~~
-                   id                  |  city   | vehicle_city |               rider_id               |              vehicle_id              |         start_address         |         end_address         |        start_time         |         end_time          | revenue
-+--------------------------------------+---------+--------------+--------------------------------------+--------------------------------------+-------------------------------+-----------------------------+---------------------------+---------------------------+---------+
-  849ba5e3-53f7-4000-8000-000000000103 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 77630 Steven Road Suite 60    | 74140 Andrew Spur           | 2018-12-30 03:04:05+00:00 | 2018-12-31 08:04:05+00:00 |   20.00
-  851eb851-eb85-4000-8000-000000000104 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 76707 Timothy Square          | 201 E Randolph St           | 2018-12-15 03:04:05+00:00 | 2018-12-17 07:04:05+00:00 |   25.00
-  86a7ef9d-b22d-4000-8000-000000000107 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 28532 Kevin Villages Suite 90 | 27493 Ortega Radial Apt. 60 | 2018-12-08 03:04:05+00:00 | 2018-12-09 03:04:05+00:00 |   36.00
-  92f1a9fb-e76c-4800-8000-00000000011f | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 56955 Edward Walks            | 53193 Jerry Village         | 2019-01-01 03:04:05+00:00 | 2019-01-01 15:04:05+00:00 |   35.00
-  94fdf3b6-45a1-4800-8000-000000000123 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 63820 Robinson Fields         | 10000 W OHare Ave           | 2018-12-14 03:04:05+00:00 | 2018-12-16 10:04:05+00:00 |   60.00
-(5 rows)
-~~~
-
-### Update using `SELECT` statement
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE rides SET (revenue, start_address) =
-    (SELECT revenue, end_address FROM rides WHERE id = '94fdf3b6-45a1-4800-8000-000000000123')
-     WHERE id = '851eb851-eb85-4000-8000-000000000104';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM rides WHERE rider_id = '851eb851-eb85-4000-8000-00000000001a';
-~~~
-
-~~~
-                   id                  |  city   | vehicle_city |               rider_id               |              vehicle_id              |         start_address         |         end_address         |        start_time         |         end_time          | revenue
-+--------------------------------------+---------+--------------+--------------------------------------+--------------------------------------+-------------------------------+-----------------------------+---------------------------+---------------------------+---------+
-  849ba5e3-53f7-4000-8000-000000000103 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 77630 Steven Road Suite 60    | 74140 Andrew Spur           | 2018-12-30 03:04:05+00:00 | 2018-12-31 08:04:05+00:00 |   20.00
-  851eb851-eb85-4000-8000-000000000104 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 10000 W OHare Ave             | 201 E Randolph St           | 2018-12-15 03:04:05+00:00 | 2018-12-17 07:04:05+00:00 |   60.00
-  86a7ef9d-b22d-4000-8000-000000000107 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 28532 Kevin Villages Suite 90 | 27493 Ortega Radial Apt. 60 | 2018-12-08 03:04:05+00:00 | 2018-12-09 03:04:05+00:00 |   36.00
-  92f1a9fb-e76c-4800-8000-00000000011f | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 56955 Edward Walks            | 53193 Jerry Village         | 2019-01-01 03:04:05+00:00 | 2019-01-01 15:04:05+00:00 |   35.00
-  94fdf3b6-45a1-4800-8000-000000000123 | chicago | chicago      | 851eb851-eb85-4000-8000-00000000001a | 88888888-8888-4800-8000-000000000008 | 63820 Robinson Fields         | 10000 W OHare Ave           | 2018-12-14 03:04:05+00:00 | 2018-12-16 10:04:05+00:00 |   60.00
-(5 rows)
-~~~
-
-### Update with default values
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE users SET address = DEFAULT WHERE id = '19999999-9999-4a00-8000-000000000005';
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM users LIMIT 5;
-~~~
-
-~~~
-                   id                  |   city    |        name        |        address        | credit_card
-+--------------------------------------+-----------+--------------------+-----------------------+-------------+
-  c28f5c28-f5c2-4000-8000-000000000026 | amsterdam | Maria Weber        | 14729 Karen Radial    | 5844236997
-  c7ae147a-e147-4000-8000-000000000027 | amsterdam | Tina Miller        | 97521 Mark Extensions | 8880478663
-  cccccccc-cccc-4000-8000-000000000028 | amsterdam | Taylor Cunningham  | 89214 Jennifer Well   | 5130593761
-  d1eb851e-b851-4800-8000-000000000029 | amsterdam | Kimberly Alexander | 48474 Alfred Hollow   | 4059628542
-  19999999-9999-4a00-8000-000000000005 | boston    | Nicole Mcmahon     | NULL                  | 0303726947
-(5 rows)
-~~~
-
-### Update using values from a different table
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE rides SET revenue = NULL FROM vehicles WHERE rides.rider_id=vehicles.owner_id AND rides.vehicle_id=vehicles.id;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM rides WHERE revenue IS NULL LIMIT 5;
-~~~
-
-~~~
-                   id                  |   city    | vehicle_city |               rider_id               |              vehicle_id              |         start_address          |         end_address         |        start_time         |         end_time          | revenue
----------------------------------------+-----------+--------------+--------------------------------------+--------------------------------------+--------------------------------+-----------------------------+---------------------------+---------------------------+----------
-  ab020c49-ba5e-4800-8000-00000000014e | amsterdam | amsterdam    | c28f5c28-f5c2-4000-8000-000000000026 | aaaaaaaa-aaaa-4800-8000-00000000000a | 1905 Christopher Locks Apt. 77 | 66037 Belinda Plaza Apt. 93 | 2018-12-13 03:04:05+00:00 | 2018-12-14 08:04:05+00:00 | NULL
-  ac083126-e978-4800-8000-000000000150 | amsterdam | amsterdam    | c28f5c28-f5c2-4000-8000-000000000026 | aaaaaaaa-aaaa-4800-8000-00000000000a | 50217 Victoria Fields Apt. 44  | 56217 Wilson Spring         | 2018-12-07 03:04:05+00:00 | 2018-12-07 10:04:05+00:00 | NULL
-  af9db22d-0e56-4800-8000-000000000157 | amsterdam | amsterdam    | c28f5c28-f5c2-4000-8000-000000000026 | aaaaaaaa-aaaa-4800-8000-00000000000a | 20937 Gibson River             | 50480 Steven Row            | 2018-12-23 03:04:05+00:00 | 2018-12-25 11:04:05+00:00 | NULL
-  b22d0e56-0418-4000-8000-00000000015c | amsterdam | amsterdam    | bd70a3d7-0a3d-4000-8000-000000000025 | bbbbbbbb-bbbb-4800-8000-00000000000b | 36054 Ward Crescent Suite 35   | 7745 John Run               | 2018-12-09 03:04:05+00:00 | 2018-12-10 18:04:05+00:00 | NULL
-  b53f7ced-9168-4000-8000-000000000162 | amsterdam | amsterdam    | bd70a3d7-0a3d-4000-8000-000000000025 | bbbbbbbb-bbbb-4800-8000-00000000000b | 86091 Mcdonald Motorway        | 1652 Robert Ford            | 2018-12-05 03:04:05+00:00 | 2018-12-05 06:04:05+00:00 | NULL
-(5 rows)
-~~~
-
-### Update all rows
-
-{{site.data.alerts.callout_danger}}
-If you do not use the `WHERE` clause to specify the rows to be updated, the values for all rows will be updated.
-{{site.data.alerts.end}}
-{{site.data.alerts.callout_info}}
-If the [`sql_safe_updates`](cockroach-sql.html#allow-potentially-unsafe-sql-statements) session variable is set to `true`, the client will prevent the update. `sql_safe_updates` is set to `true` by default.
-{{site.data.alerts.end}}
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE rides SET revenue = 7.00;
-~~~
-
-~~~
-pq: rejected: UPDATE without WHERE clause (sql_safe_updates = true)
-~~~
-
-You can use a [`SET`](set-vars.html) statement to set session variables.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET sql_safe_updates = false;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE rides SET revenue = 7.00;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM rides LIMIT 5;
-~~~
-
-~~~
-                   id                  |   city    | vehicle_city |               rider_id               |              vehicle_id              |         start_address          |            end_address            |        start_time         |         end_time          | revenue
-+--------------------------------------+-----------+--------------+--------------------------------------+--------------------------------------+--------------------------------+-----------------------------------+---------------------------+---------------------------+---------+
-  c0000000-0000-4000-8000-000000000177 | amsterdam | amsterdam    | c28f5c28-f5c2-4000-8000-000000000026 | cccccccc-cccc-4000-8000-00000000000c | 65738 Williams Summit          | 72424 Thomas Field Suite 82       | 2018-12-31 03:04:05+00:00 | 2019-01-01 03:04:05+00:00 |    7.00
-  c083126e-978d-4000-8000-000000000178 | amsterdam | amsterdam    | cccccccc-cccc-4000-8000-000000000028 | cccccccc-cccc-4000-8000-00000000000c | 53613 Johnson Terrace          | 12667 Monica Hollow               | 2018-12-16 03:04:05+00:00 | 2018-12-17 15:04:05+00:00 |    7.00
-  c10624dd-2f1a-4000-8000-000000000179 | amsterdam | amsterdam    | c7ae147a-e147-4000-8000-000000000027 | cccccccc-cccc-4000-8000-00000000000c | 61921 Brittany Orchard Apt. 85 | 81157 Stephanie Court Suite 96    | 2018-12-30 03:04:05+00:00 | 2019-01-01 07:04:05+00:00 |    7.00
-  c189374b-c6a7-4000-8000-00000000017a | amsterdam | amsterdam    | cccccccc-cccc-4000-8000-000000000028 | cccccccc-cccc-4000-8000-00000000000c | 75456 Gray View                | 69175 Christopher Shoals Suite 47 | 2018-12-23 03:04:05+00:00 | 2018-12-23 03:04:05+00:00 |    7.00
-  c20c49ba-5e35-4000-8000-00000000017b | amsterdam | amsterdam    | cccccccc-cccc-4000-8000-000000000028 | cccccccc-cccc-4000-8000-00000000000c | 38892 Joseph Summit Suite 86   | 89582 Melissa Streets             | 2018-12-27 03:04:05+00:00 | 2018-12-28 18:04:05+00:00 |    7.00
-(5 rows)
-~~~
-
-### Update and return values
-
-In this example, the `RETURNING` clause returns the `id` value of the row updated. The language-specific versions assume that you have installed the relevant [client drivers](install-client-drivers.html).
-
-{{site.data.alerts.callout_success}}This use of <code>RETURNING</code> mirrors the behavior of MySQL's <code>last_insert_id()</code> function.{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}When a driver provides a <code>query()</code> method for statements that return results and an <code>exec()</code> method for statements that do not (e.g., Go), it's likely necessary to use the <code>query()</code> method for <code>UPDATE</code> statements with <code>RETURNING</code>.{{site.data.alerts.end}}
-
-<section class="filters clearfix">
-    <button class="filter-button" data-scope="shell">Shell</button>
-    <button class="filter-button" data-scope="python">Python</button>
-    <button class="filter-button" data-scope="ruby">Ruby</button>
-    <button class="filter-button" data-scope="go">Go</button>
-    <button class="filter-button" data-scope="js">Node.js</button>
-</section>
-
-<section class="filter-content" markdown="1" data-scope="shell">
-<p></p>
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE vehicles SET status = 'available' WHERE city = 'new york' RETURNING id;
-~~~
-
-~~~
-                   id
-+--------------------------------------+
-  00000000-0000-4000-8000-000000000000
-  11111111-1111-4100-8000-000000000001
-(2 rows)
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="python">
-<p></p>
-
-{% include copy-clipboard.html %}
-~~~ python
-# Import the driver.
-import psycopg2
-
-# Connect to the "bank" database.
-conn = psycopg2.connect(
-    database='movr',
-    user='root',
-    host='localhost',
-    port=26257
-)
-
-# Make each statement commit immediately.
-conn.set_session(autocommit=True)
-
-# Open a cursor to perform database operations.
-cur = conn.cursor()
-
-# Update a row in the "vehicles" table
-# and return the "id" value.
-cur.execute(
-    "UPDATE vehicles SET status = 'available' WHERE city = 'new york' RETURNING id;"
-)
-
-# Print out the returned value.
-rows = cur.fetchall()
-print('IDs:')
-for row in rows:
-    print([str(cell) for cell in row])
-
-# Close the database connection.
-cur.close()
-conn.close()
-~~~
-
-The printed value would look like:
-
-~~~
-IDs:
-['00000000-0000-4000-8000-000000000000']
-['11111111-1111-4100-8000-000000000001']
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="ruby">
-<p></p>
-
-{% include copy-clipboard.html %}
-~~~ ruby
-# Import the driver.
-require 'pg'
-
-# Connect to the "bank" database.
-conn = PG.connect(
-    user: 'root',
-    dbname: 'movr',
-    host: 'localhost',
-    port: 26257
-)
-
-# Update a row in the "vehicles" table
-# and return the "id" value.
-conn.exec(
-    "UPDATE vehicles SET status = 'available' WHERE city = 'new york' RETURNING id;"
-) do |res|
-
-# Print out the returned value.
-puts "IDs:"
-    res.each do |row|
-        puts row
-    end
-end
-
-# Close communication with the database.
-conn.close()
-~~~
-
-The printed value would look like:
-
-~~~
-IDs:
-{"id"=>"00000000-0000-4000-8000-000000000000"}
-{"id"=>"11111111-1111-4100-8000-000000000001"}
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="go">
-<p></p>
-
-{% include copy-clipboard.html %}
-~~~ go
-package main
-
-import (
-	"database/sql"
-	"fmt"
-	"log"
-
-	_ "github.com/lib/pq"
-)
-
-func main() {
-	//Connect to the "bank" database.
-	db, err := sql.Open(
-		"postgres",
-		"postgresql://root@localhost:26257/movr?sslmode=disable",
-	)
-	if err != nil {
-		log.Fatal("error connecting to the database: ", err)
-	}
-
-	// Update a row in the "vehicles" table
-	// and return the "id" value.
-	rows, err := db.Query(
-		"UPDATE vehicles SET status = 'available' WHERE city = 'new york' RETURNING id;",
-	)
-	if err != nil {
-		log.Fatal(err)
-	}
-
-	// Print out the returned value.
-	defer rows.Close()
-	fmt.Println("IDs:")
-	for rows.Next() {
-		var id string
-		if err := rows.Scan(&id); err != nil {
-			log.Fatal(err)
-		}
-		fmt.Printf("%s\n", id)
-	}
-}
-~~~
-
-The printed value would look like:
-
-~~~
-IDs:
-00000000-0000-4000-8000-000000000000
-11111111-1111-4100-8000-000000000001
-~~~
-
-</section>
-
-<section class="filter-content" markdown="1" data-scope="js">
-<p></p>
-
-{% include copy-clipboard.html %}
-~~~ js
-var async = require('async')
-var pg = require('pg')
-
-// Config to connect to the "movr" database.
-var config = {
-    user: 'root',
-    host: 'localhost',
-    database: 'movr',
-    port: 26257
-  }
-
-// Create pool
-var pool = new pg.Pool(config)
-
-pool.connect(function (err, client, done) {
-
-    // Close communication with the database and exit.
-    var finish = function () {
-        done()
-        process.exit()
-    }
-
-    if (err) {
-        console.error('could not connect to cockroachdb', err);
-        finish()
-    }
-    async.waterfall([function (next) {
-        client.query(
-            `UPDATE vehicles SET status = 'available' WHERE city = 'new york' RETURNING id;`,
-          next
-        )
-      }
-    ],
-    function (err, results) {
-      if (err) {
-        console.error('error updating and selecting from users', err);
-        finish()
-      }
-      // Print out the returned value.
-      console.log('IDs:')
-      results.rows.forEach(function (row) {
-        console.log(row)
-      })
-
-      finish()
-    })
-  })
-~~~
-
-The printed value would like:
-
-~~~
-IDs:
-{ id: '00000000-0000-4000-8000-000000000000' }
-{ id: '11111111-1111-4100-8000-000000000001' }
-~~~
-
-</section>
-
-### Update with index hints
-
-Suppose that you create a multi-column index on the `users` table with the `name` and `city` columns.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE INDEX ON users (name, city);
-~~~
-
-Now suppose you want to update a couple rows in the table, based on their contents. You can use the [`EXPLAIN (OPT)`](explain.html#opt-option) command to see how the [cost-based optimizer](cost-based-optimizer.html) decides to perform the `UPDATE` statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (opt) UPDATE users SET name='Patricia Smith (there are two)' WHERE name='Patricia Smith';
-~~~
-
-~~~
-                                        text
-------------------------------------------------------------------------------------
-  update users
-   └── project
-        ├── index-join users
-        │    └── scan users@users_name_city_idx
-        │         └── constraint: /10/9/8: [/'Patricia Smith' - /'Patricia Smith']
-        └── projections
-             └── 'Patricia Smith (there are two)'
-(7 rows)
-~~~
-
-The output of the `EXPLAIN` statement shows that the optimizer scans the newly-created `users_name_city_idx` index when performing the update. This makes sense, as you are performing an update based on the `name` column.
-
-Although `users_name_city_idx` is likely the most efficient index for the table scan, you may want to assess the performance difference between scanning on `users_name_city_idx` and scanning on the primary index. You can provide an index hint (i.e., force the index selection) to use the primary key of the `users` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> EXPLAIN (opt) UPDATE users@primary SET name='Patricia Smith (there are two)' WHERE name='Patricia Smith';
-~~~
-
-~~~
-                       text
----------------------------------------------------
-  update users
-   └── project
-        ├── select
-        │    ├── scan users
-        │    │    └── flags: force-index=primary
-        │    └── filters
-        │         └── name = 'Patricia Smith'
-        └── projections
-             └── 'Patricia Smith (there are two)'
-(9 rows)
-~~~
-
-## See also
-
-- [`DELETE`](delete.html)
-- [`INSERT`](insert.html)
-- [`UPSERT`](upsert.html)
-- [`TRUNCATE`](truncate.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`DROP TABLE`](drop-table.html)
-- [`DROP DATABASE`](drop-database.html)
-- [Other SQL Statements](sql-statements.html)
-- [Limiting Query Results](limit-offset.html)
-- [Ordering of rows in DML statements](order-by.html#ordering-rows-in-dml-statements)
diff --git a/src/current/v20.2/upgrade-cockroach-version.md b/src/current/v20.2/upgrade-cockroach-version.md
deleted file mode 100644
index 7f42935cf8d..00000000000
--- a/src/current/v20.2/upgrade-cockroach-version.md
+++ /dev/null
@@ -1,272 +0,0 @@
----
-title: Upgrade to CockroachDB v20.2
-summary: Learn how to upgrade your CockroachDB cluster to a new version.
-toc: true
----
-
-Because of CockroachDB's [multi-active availability](multi-active-availability.html) design, you can perform a "rolling upgrade" of your CockroachDB cluster. This means that you can upgrade nodes one at a time without interrupting the cluster's overall health and operations.
-
-## Step 1. Verify that you can upgrade
-
-Run [`cockroach sql`](cockroach-sql.html) against any node in the cluster to open the SQL shell. Then check your current cluster version:
-
-{% include_cached copy-clipboard.html %}
-~~~ sql
-> SHOW CLUSTER SETTING version;
-~~~
-
-To upgrade to a new version, you must first be on a [production release](../releases/) of the previous version. The release does not need to be the **latest** production release of the previous version, but it must be a production release rather than a testing release (alpha/beta).
-
-Therefore, if you are upgrading from v19.2 to v20.2, or from a testing release (alpha/beta) of v20.1 to v20.2:
-
-1. First [upgrade to a production release of v20.1](../v20.1/upgrade-cockroach-version.html). Be sure to complete all the steps.
-
-1. Then return to this page and perform a second rolling upgrade to v20.2.
-
-If you are upgrading from any production release of v20.1, or from any earlier v20.2 release, you do not have to go through intermediate releases; continue to step 2.
-
-## Step 2. Prepare to upgrade
-
-Before starting the upgrade, complete the following steps.
-
-### Check load balancing
-
-Make sure your cluster is behind a [load balancer](recommended-production-settings.html#load-balancing), or your clients are configured to talk to multiple nodes. If your application communicates with a single node, stopping that node to upgrade its CockroachDB binary will cause your application to fail.
-
-### Check cluster health
-
-Verify the overall health of your cluster using the [DB Console](ui-overview.html). On the **Overview**:
-
-  - Under **Node Status**, make sure all nodes that should be live are listed as such. If any nodes are unexpectedly listed as suspect or dead, identify why the nodes are offline and either restart them or [decommission](remove-nodes.html) them before beginning your upgrade. If there are dead and non-decommissioned nodes in your cluster, it will not be possible to finalize the upgrade (either automatically or manually).
-
-  - Under **Replication Status**, make sure there are 0 under-replicated and unavailable ranges. Otherwise, performing a rolling upgrade increases the risk that ranges will lose a majority of their replicas and cause cluster unavailability. Therefore, it's important to identify and resolve the cause of range under-replication and/or unavailability before beginning your upgrade.
-
-  - In the **Node List**:
-      - Make sure all nodes are on the same version. If any nodes are behind, upgrade them to the cluster's current version first, and then start this process over.
-      - Make sure capacity and memory usage are reasonable for each node. Nodes must be able to tolerate some increase in case the new version uses more resources for your workload. Also go to **Metrics > Dashboard: Hardware** and make sure CPU percent is reasonable across the cluster. If there's not enough headroom on any of these metrics, consider [adding nodes](cockroach-start.html) to your cluster before beginning your upgrade.
-
-### Review breaking changes
-
-Review the [backward-incompatible changes in v20.2](../releases/v20.2.html#v20-2-0-backward-incompatible-changes) and [deprecated features](../releases/v20.2.html#v20-2-0-deprecations). If any affect your application, make the necessary changes.
-
-## Step 3. Decide how the upgrade will be finalized
-
-{{site.data.alerts.callout_info}}
-This step is relevant only when upgrading from v20.1.x to v20.2. For upgrades within the v20.2.x series, skip this step.
-{{site.data.alerts.end}}
-
-By default, after all nodes are running the new version, the upgrade process will be **auto-finalized**. This will enable certain [features and performance improvements introduced in v20.2](#features-that-require-upgrade-finalization). However, it will no longer be possible to perform a downgrade to v20.1. In the event of a catastrophic failure or corruption, the only option will be to start a new cluster using the old binary and then restore from one of the backups created prior to performing the upgrade. For this reason, **we recommend disabling auto-finalization** so you can monitor the stability and performance of the upgraded cluster before finalizing the upgrade, but note that you will need to follow all of the subsequent directions, including the manual finalization in [step 5](#step-5-finish-the-upgrade):
-
-1. [Upgrade to v20.1](../v20.1/upgrade-cockroach-version.html), if you haven't already.
-
-1. Start the [`cockroach sql`](cockroach-sql.html) shell against any node in the cluster.
-
-1. Set the `cluster.preserve_downgrade_option` [cluster setting](cluster-settings.html):
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > SET CLUSTER SETTING cluster.preserve_downgrade_option = '20.1';
-    ~~~
-
-    It is only possible to set this setting to the current cluster version.
-
-### Features that require upgrade finalization
-
-When upgrading from v20.1 to v20.2, certain features and performance improvements will be enabled only after finalizing the upgrade, including but not limited to:
-
-- **Spatial features:** After finalization, it will be possible to use [spatial indexes](spatial-indexes.html), and [spatial functions](functions-and-operators.html#spatial-functions), as well as the ability to migrate spatial data from various formats such as [Shapefiles](migrate-from-shapefiles.html), [GeoJSON](migrate-from-geojson.html), [GeoPackages](migrate-from-geopackage.html), and [OpenStreetMap](migrate-from-openstreetmap.html).
-
-- **`ENUM` data types:** After finalization, it will be possible to create and manage [user-defined `ENUM` data types](enum.html) consisting of sets of enumerated, static values.
-
-- **Altering column data types:** After finalization, it will be possible to [alter column data types](alter-column.html#altering-column-types) where column data must be rewritten.
-
-- **User-defined schemas:** After finalization, it will be possible to [create user-defined logical schemas](create-schema.html), as well [alter user-defined schemas](alter-schema.html), [drop user-defined schemas](drop-schema.html), [set the schema for a database object](set-schema.html), and [convert databases to user-defined schemas](convert-to-schema.html). For details on migrating a cluster that does not use user-defined schemas in its naming hierarchy, see [Migrating namespaces from previous versions of CockroachDB](sql-name-resolution.html#migrating-namespaces-from-previous-versions-of-cockroachdb).
-
-- **Foreign key index requirement:** After finalization, it will no longer be required to have an index on the referencing columns of a [`FOREIGN KEY`](foreign-key.html) constraint.
-
-- **Minimum password length:** After finalization, it will be possible to use the `server.user_login.min_password_length` [cluster setting](cluster-settings.html) to set a minimum length for passwords.
-
-- **Materialized views:** After finalization, it will be possible to create [materialized views](views.html#materialized-views), or views that store their selection query results on-disk.
-
-- **`CREATELOGIN` privilege:** After finalization, the `CREATELOGIN` privilege will be required to define or change authentication principals or their credentials.
-
-## Step 4. Perform the rolling upgrade
-
-For each node in your cluster, complete the following steps. Be sure to upgrade only one node at a time, and wait at least one minute after a node rejoins the cluster to upgrade the next node. Simultaneously upgrading more than one node increases the risk that ranges will lose a majority of their replicas and cause cluster unavailability.
-
-{{site.data.alerts.callout_success}}
-We recommend creating scripts to perform these steps instead of performing them manually. Also, if you are running CockroachDB on Kubernetes, see our documentation on [single-cluster](orchestrate-cockroachdb-with-kubernetes.html#upgrade-the-cluster) and/or [multi-cluster](orchestrate-cockroachdb-with-kubernetes-multi-cluster.html#upgrade-the-cluster) orchestrated deployments for upgrade guidance instead.
-{{site.data.alerts.end}}
-
-1. Drain and stop the node using one of the following methods:
-
-    {% include {{ page.version.version }}/prod-deployment/node-shutdown.md %}
-
-    Verify that the process has stopped:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ ps aux | grep cockroach
-    ~~~
-
-    Alternately, you can check the node's logs for the message `server drained and shutdown completed`.
-
-1. Download and install the CockroachDB binary you want to use:
-
-    <div class="filters clearfix">
-      <button style="width: 15%" class="filter-button" data-scope="mac">Mac</button>
-      <button style="width: 15%" class="filter-button" data-scope="linux">Linux</button>
-    </div>
-    <p></p>
-
-    <div class="filter-content" markdown="1" data-scope="mac">
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{page.release_info.version}}.darwin-10.9-amd64.tgz|tar -xzf -
-    ~~~
-    </div>
-
-    <div class="filter-content" markdown="1" data-scope="linux">
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ curl https://binaries.cockroachdb.com/cockroach-{{page.release_info.version}}.linux-amd64.tgz|tar -xzf -
-    ~~~
-    </div>
-
-1. If you use `cockroach` in your `$PATH`, rename the outdated `cockroach` binary, and then move the new one into its place:
-
-    <div class="filters clearfix">
-      <button style="width: 15%" class="filter-button" data-scope="mac">Mac</button>
-      <button style="width: 15%" class="filter-button" data-scope="linux">Linux</button>
-    </div>
-    <p></p>
-
-    <div class="filter-content" markdown="1" data-scope="mac">
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    i="$(which cockroach)"; mv "$i" "$i"_old
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{page.release_info.version}}.darwin-10.9-amd64/cockroach /usr/local/bin/cockroach
-    ~~~
-    </div>
-
-    <div class="filter-content" markdown="1" data-scope="linux">
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    i="$(which cockroach)"; mv "$i" "$i"_old
-    ~~~
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cp -i cockroach-{{page.release_info.version}}.linux-amd64/cockroach /usr/local/bin/cockroach
-    ~~~
-    </div>
-
-1. Start the node to have it rejoin the cluster.
-
-    {{site.data.alerts.callout_danger}}
-    For maximum availability, do not wait more than a few minutes before restarting the node with the new binary. See [this open issue](https://github.com/cockroachdb/cockroach/issues/37906) for context.
-    {{site.data.alerts.end}}
-
-    Without a process manager like `systemd`, re-run the [`cockroach start`](cockroach-start.html) command that you used to start the node initially, for example:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ cockroach start \
-    --certs-dir=certs \
-    --advertise-addr=<node address> \
-    --join=<node1 address>,<node2 address>,<node3 address>
-    ~~~
-
-    If you are using `systemd` as the process manager, run this command to start the node:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ systemctl start <systemd config filename>
-    ~~~
-
-1. Verify the node has rejoined the cluster through its output to [`stdout`](cockroach-start.html#standard-output) or through the [DB Console](ui-cluster-overview-page.html#node-status).
-
-1. If you use `cockroach` in your `$PATH`, you can remove the old binary:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    $ rm /usr/local/bin/cockroach_old
-    ~~~
-
-    If you leave versioned binaries on your servers, you do not need to do anything.
-
-1. After the node has rejoined the cluster, ensure that the node is ready to accept a SQL connection.
-
-    Unless there are tens of thousands of ranges on the node, it's usually sufficient to wait one minute. To be certain that the node is ready, run the following command:
-
-    {% include copy-clipboard.html %}
-    ~~~ shell
-    cockroach sql -e 'select 1'
-    ~~~
-
-    The command will automatically wait to complete until the node is ready.
-
-1. Repeat these steps for the next node.
-
-## Step 5. Finish the upgrade
-
-{{site.data.alerts.callout_info}}
-This step is relevant only when upgrading from v20.1.x to v20.2. For upgrades within the v20.2.x series, skip this step.
-{{site.data.alerts.end}}
-
-If you disabled auto-finalization in [step 3](#step-3-decide-how-the-upgrade-will-be-finalized), monitor the stability and performance of your cluster for as long as you require to feel comfortable with the upgrade (generally at least a day). If during this time you decide to roll back the upgrade, repeat the rolling restart procedure with the old binary.
-
-Once you are satisfied with the new version:
-
-1. Start the [`cockroach sql`](cockroach-sql.html) shell against any node in the cluster.
-
-1. Re-enable auto-finalization:
-
-    {% include copy-clipboard.html %}
-    ~~~ sql
-    > RESET CLUSTER SETTING cluster.preserve_downgrade_option;
-    ~~~
-
-    {{site.data.alerts.callout_info}}
-    This statement can take up to a minute to complete, depending on the amount of data in the cluster, as it kicks off various internal maintenance and migration tasks. During this time, the cluster will experience a small amount of additional load.
-    {{site.data.alerts.end}}
-
-1. Check the cluster version to confirm that the finalize step has completed:
-
-    {% include_cached copy-clipboard.html %}
-    ~~~ sql
-    > SHOW CLUSTER SETTING version;
-    ~~~
-
-{{site.data.alerts.callout_danger}}
-If you intend to continue upgrading to **v21.1 or later**, you must ensure that any previously decommissioned nodes are fully decommissioned. Otherwise, they will block the upgrade. For instructions, see [Check decommissioned nodes](#check-decommissioned-nodes).
-{{site.data.alerts.end}}
-
-### Check decommissioned nodes
-
-Check the `membership` field in the [output of `cockroach node status --decommission`](cockroach-node.html). Nodes with `decommissioned` membership are fully decommissioned, while nodes with `decommissioning` membership have not completed the process. If there are `decommissioning` nodes in your cluster, this will block the upgrade.
-
-**Before upgrading from v20.2 to v21.1**, you must manually change the status of any `decommissioning` nodes to `decommissioned`. To do this, [run `cockroach node decommission`](remove-nodes.html#step-2-start-the-decommissioning-process-on-the-nodes) on these nodes and confirm that they update to `decommissioned`.
-
-In case a decommissioning process is hung, [recommission](remove-nodes.html#recommission-nodes) and then [decommission those nodes](remove-nodes.html#remove-multiple-nodes) again, and confirm that they update to `decommissioned`.
-
-## Troubleshooting
-
-After the upgrade has finalized (whether manually or automatically), it is no longer possible to downgrade to the previous release. If you are experiencing problems, we therefore recommend that you:
-
-1. Run the [`cockroach debug zip`](cockroach-debug-zip.html) command against any node in the cluster to capture your cluster's state.
-
-2. [Reach out for support](support-resources.html) from Cockroach Labs, sharing your debug zip.
-
-In the event of catastrophic failure or corruption, the only option will be to start a new cluster using the old binary and then restore from one of the backups created prior to performing the upgrade.
-
-## See also
-
-- [View Node Details](cockroach-node.html)
-- [Collect Debug Information](cockroach-debug-zip.html)
-- [View Version Details](cockroach-version.html)
-- [Release notes for our latest version](../releases/{{page.version.version}}.html)
diff --git a/src/current/v20.2/upsert.md b/src/current/v20.2/upsert.md
deleted file mode 100644
index 479bdfcc492..00000000000
--- a/src/current/v20.2/upsert.md
+++ /dev/null
@@ -1,287 +0,0 @@
----
-title: UPSERT
-summary: The UPSERT statement inserts rows when values do not violate uniqueness constraints, and it updates rows when values do violate uniqueness constraints.
-toc: true
----
-
-The `UPSERT` [statement](sql-statements.html) is semantically equivalent to [`INSERT ON CONFLICT`](insert.html#on-conflict-clause), but the two may have slightly different [performance characteristics](#considerations). It inserts rows in cases where specified values do not violate uniqueness constraints, and it updates rows in cases where values do violate uniqueness constraints.
-
-## Considerations
-
-- `UPSERT` considers uniqueness only for [Primary Key](primary-key.html) columns. `INSERT ON CONFLICT` is more flexible and can be used to consider uniqueness for other columns. For more details, see [How `UPSERT` transforms into `INSERT ON CONFLICT`](#how-upsert-transforms-into-insert-on-conflict) below.
-
-- When inserting/updating all columns of a table, and the table has no secondary indexes, `UPSERT` will be faster than the equivalent `INSERT ON CONFLICT` statement, as it will write without first reading. This may be particularly useful if you are using a simple SQL table of two columns to [simulate direct KV access](sql-faqs.html#can-i-use-cockroachdb-as-a-key-value-store).
-
-- A single [multi-row `UPSERT`](#upsert-multiple-rows) statement is faster than multiple single-row `UPSERT` statements. Whenever possible, use multi-row `UPSERT` instead of multiple single-row `UPSERT` statements.
-
-- If the input data contains duplicates, see [Import data containing duplicate rows using `DISTINCT ON`](#import-data-containing-duplicate-rows-using-distinct-on) below.
-
-## Required privileges
-
-The user must have the `INSERT`, `SELECT` and `UPDATE` [privileges](authorization.html#assign-privileges) on the table.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/upsert.html %}
-</div>
-
-## Parameters
-
-Parameter | Description
-----------|------------
-`common_table_expr` | See [Common Table Expressions](common-table-expressions.html).
-`table_name` | The name of the table.
-`AS table_alias_name` | An alias for the table name. When an alias is provided, it completely hides the actual table name.
-`column_name` | The name of a column to populate during the insert.
-`select_stmt` | A [selection query](selection-queries.html). Each value must match the [data type](data-types.html) of its column. Also, if column names are listed after `INTO`, values must be in corresponding order; otherwise, they must follow the declared order of the columns in the table.
-`DEFAULT VALUES` | To fill all columns with their [default values](default-value.html), use `DEFAULT VALUES` in place of `select_stmt`. To fill a specific column with its default value, leave the value out of the `select_stmt` or use `DEFAULT` at the appropriate position.
-`RETURNING target_list` | Return values based on rows inserted, where `target_list` can be specific column names from the table, `*` for all columns, or computations using [scalar expressions](scalar-expressions.html).<br><br>Within a [transaction](transactions.html), use `RETURNING NOTHING` to return nothing in the response, not even the number of rows affected.
-
-## How `UPSERT` transforms into `INSERT ON CONFLICT`
-
-`UPSERT` considers uniqueness only for [primary key](primary-key.html) columns. For example, assuming that columns `a` and `b` are the primary key, the following `UPSERT` and `INSERT ON CONFLICT` statements are equivalent:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPSERT INTO t (a, b, c) VALUES (1, 2, 3);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO t (a, b, c)
-    VALUES (1, 2, 3)
-    ON CONFLICT (a, b)
-    DO UPDATE SET c = excluded.c;
-~~~
-
-`INSERT ON CONFLICT` is more flexible and can be used to consider uniqueness for columns not in the primary key. For more details, see the [Upsert that Fails (Conflict on Non-Primary Key)](#upsert-that-fails-conflict-on-non-primary-key) example below.
-
-## Examples
-
-### Upsert a row (no conflict)
-
-In this example, the `id` column is the primary key. Because the inserted `id` value does not conflict with the `id` value of any existing row, the `UPSERT` statement inserts a new row into the table.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-+----+----------+
-| id | balance  |
-+----+----------+
-|  1 |  10000.5 |
-|  2 | 20000.75 |
-+----+----------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPSERT INTO accounts (id, balance) VALUES (3, 6325.20);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-+----+----------+
-| id | balance  |
-+----+----------+
-|  1 |  10000.5 |
-|  2 | 20000.75 |
-|  3 |   6325.2 |
-+----+----------+
-~~~
-
-### Upsert multiple rows
-
-In this example, the `UPSERT` statement inserts multiple rows into the table.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-+----+----------+
-| id | balance  |
-+----+----------+
-|  1 |  10000.5 |
-|  2 | 20000.75 |
-|  3 |   6325.2 |
-+----+----------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPSERT INTO accounts (id, balance) VALUES (4, 1970.4), (5, 2532.9), (6, 4473.0);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-+----+----------+
-| id | balance  |
-+----+----------+
-|  1 |  10000.5 |
-|  2 | 20000.75 |
-|  3 |   6325.2 |
-|  4 |   1970.4 |
-|  5 |   2532.9 |
-|  6 |   4473.0 |
-+----+----------+
-~~~
-
-### Upsert that updates a row (conflict on primary key)
-
-In this example, the `id` column is the primary key. Because the inserted `id` value is not unique, the `UPSERT` statement updates the row with the new `balance`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-+----+----------+
-| id | balance  |
-+----+----------+
-|  1 |  10000.5 |
-|  2 | 20000.75 |
-|  3 |   6325.2 |
-|  4 |   1970.4 |
-|  5 |   2532.9 |
-|  6 |   4473.0 |
-+----+----------+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPSERT INTO accounts (id, balance) VALUES (3, 7500.83);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-+----+----------+
-| id | balance  |
-+----+----------+
-|  1 |  10000.5 |
-|  2 | 20000.75 |
-|  3 |  7500.83 |
-|  4 |   1970.4 |
-|  5 |   2532.9 |
-|  6 |   4473.0 |
-+----+----------+
-~~~
-
-### Upsert that fails (conflict on non-primary key)
-
-`UPSERT` will not update rows when the uniquness conflict is on columns not in the primary key. In this example, the `a` column is the primary key, but the `b` column also has the [`UNIQUE` constraint](unique.html). Because the inserted `b` value is not unique, the `UPSERT` fails.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM unique_test;
-~~~
-
-~~~
-+---+---+
-| a | b |
-+---+---+
-| 1 | 1 |
-| 2 | 2 |
-| 3 | 3 |
-+---+---+
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPSERT INTO unique_test VALUES (4, 1);
-~~~
-
-~~~
-pq: duplicate key value (b)=(1) violates unique constraint "unique_test_b_key"
-~~~
-
-In such a case, you would need to use the [`INSERT ON CONFLICT`](insert.html) statement to specify the `b` column as the column with the `UNIQUE` constraint.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO unique_test VALUES (4, 1) ON CONFLICT (b) DO UPDATE SET a = excluded.a;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM unique_test;
-~~~
-
-~~~
-+---+---+
-| a | b |
-+---+---+
-| 2 | 2 |
-| 3 | 3 |
-| 4 | 1 |
-+---+---+
-~~~
-
-### Import data containing duplicate rows using `DISTINCT ON`
-
-If the input data to insert/update contains duplicate rows, you must
-use [`DISTINCT ON`](select-clause.html#eliminate-duplicate-rows) to
-ensure there is only one row for each value of the primary key.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH
-    -- the following data contains duplicates on the conflict column "id":
-    inputrows AS (VALUES (8, 130), (8, 140))
-
-  UPSERT INTO accounts (id, balance)
-    (SELECT DISTINCT ON(id) id, balance FROM inputrows); -- de-duplicate the input rows
-~~~
-
-The `DISTINCT ON` clause does not guarantee which of the duplicates is
-considered. To force the selection of a particular duplicate, use an
-`ORDER BY` clause:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> WITH
-    -- the following data contains duplicates on the conflict column "id":
-    inputrows AS (VALUES (8, 130), (8, 140))
-
-  UPSERT INTO accounts (id, balance)
-    (SELECT DISTINCT ON(id) id, balance
-	 FROM inputrows
-     ORDER BY balance); -- pick the lowest balance as value to update in each account
-~~~
-
-{{site.data.alerts.callout_info}}
-Using `DISTINCT ON` incurs a performance cost to search and eliminate duplicates.
-For best performance, avoid using it when the input is known to not contain duplicates.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Ordering of rows in DML statements](order-by.html#ordering-rows-in-dml-statements)
-- [Selection Queries](selection-queries.html)
-- [`DELETE`](delete.html)
-- [`INSERT`](insert.html)
-- [`UPDATE`](update.html)
-- [`TRUNCATE`](truncate.html)
-- [`ALTER TABLE`](alter-table.html)
-- [`DROP TABLE`](drop-table.html)
-- [`DROP DATABASE`](drop-database.html)
-- [Other SQL Statements](sql-statements.html)
diff --git a/src/current/v20.2/use-a-local-file-server-for-bulk-operations.md b/src/current/v20.2/use-a-local-file-server-for-bulk-operations.md
deleted file mode 100644
index 98089aab223..00000000000
--- a/src/current/v20.2/use-a-local-file-server-for-bulk-operations.md
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: Use a Local File Server for Bulk Operations
-summary: Learn how to create a simple file server for use with bulk operations within CockroachDB
-toc: true
----
-
-If you need a location to store files for the [`IMPORT`](import.html) process or [CockroachDB backups](backup.html), but do not have access to (or cannot use) [cloud storage providers](use-cloud-storage-for-bulk-operations.html), you can run a local file server. You can then use this file server by leveraging support for our [HTTP Export Storage API](#http-export-storage-api).
-
-This is especially useful for:
-
-- Implementing a compatibility layer in front of custom or proprietary storage providers for which CockroachDB does not yet have built-in support
-- Using on-premises storage
-
-## HTTP export storage API
-
-CockroachDB tasks that require reading or writing external files (such as [`IMPORT`](import.html) and [`BACKUP`](backup.html)) can use the HTTP Export Storage API by prefacing the address with `http`, e.g., `http://fileserver/mnt/cockroach-exports`.
-
-This API uses the `GET`, `PUT` and `DELETE` methods. This behaves like you would expect typical HTTP requests to work. After a `PUT` request to some path, a subsequent `GET` request should return the content sent in the `PUT` request body, at least until a `DELETE` request is received for that path.
-
-## Examples
-
-You can use any file server software that supports `GET`, `PUT` and `DELETE` methods, but we've included code samples for common ones:
-
-- [Using PHP with `IMPORT`](#using-php-with-import)
-- [Using Python with `IMPORT`](#using-python-with-import)
-- [Using Ruby with `IMPORT`](#using-ruby-with-import)
-- [Using nginx as a file server](#using-nginx-as-a-file-server)
-
-{{site.data.alerts.callout_info}}We do not recommend using any machines running <code>cockroach</code> as file servers. Using machines that are running cockroach as file servers could negatively impact performance if I/O operations exceed capacity.{{site.data.alerts.end}}
-
-### Using PHP with `IMPORT`
-
-The PHP language has an HTTP server built in.  You can serve local files using the commands below.  For more information about how to import these locally served files, see the documentation for the [`IMPORT`][import] statement.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cd /path/to/data
-$ php -S 127.0.0.1:3000 # files available at e.g., 'http://localhost:3000/data.sql'
-~~~
-
-### Using Python with `IMPORT`
-
-The Python language has an HTTP server included in the standard library.  You can serve local files using the commands below.  For more information about how to import these locally served files, see the documentation for the [`IMPORT`][import] statement.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cd /path/to/data
-$ python -m SimpleHTTPServer 3000 # files available at e.g., 'http://localhost:3000/data.sql'
-~~~
-
-If you use Python 3, try:
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cd /path/to/data
-$ python -m http.server 3000
-~~~
-
-### Using Ruby with `IMPORT`
-
-The Ruby language has an HTTP server included in the standard library.  You can serve local files using the commands below.  For more information about how to import these locally served files, see the documentation for the [`IMPORT`][import] statement.
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cd /path/to/data
-$ ruby -run -ehttpd . -p3000 # files available at e.g., 'http://localhost:3000/data.sql'
-~~~
-
-### Using nginx as a file server
-
-1. Install `nginx` with the `webdav` module (often included in `-full` or similarly named packages in various distributions).
-
-2. In the `nginx.conf` file, add a `dav_methods PUT DELETE` directive. For example:
-
-    {% include copy-clipboard.html %}
-    ~~~ nginx
-    events {
-        worker_connections  1024;
-    }
-    http {
-      server {
-        listen 20150;
-        location / {
-          dav_methods  PUT DELETE;
-          root /mnt/cockroach-exports;
-          sendfile           on;
-          sendfile_max_chunk 1m;
-        }
-      }
-    }
-    ~~~
-
-## See also
-
-- [`IMPORT`][import]
-- [`BACKUP`](backup.html) (*Enterprise only*)
-- [`RESTORE`](restore.html) (*Enterprise only*)
-
-<!-- Reference Links -->
-
-[import]: import.html
diff --git a/src/current/v20.2/use-cloud-storage-for-bulk-operations.md b/src/current/v20.2/use-cloud-storage-for-bulk-operations.md
deleted file mode 100644
index 858c6c65f49..00000000000
--- a/src/current/v20.2/use-cloud-storage-for-bulk-operations.md
+++ /dev/null
@@ -1,159 +0,0 @@
----
-title: Use Cloud Storage for Bulk Operations
-summary: CockroachDB constructs a secure API call to the cloud storage specified in a URL passed to bulk operation statements.
-toc: true
----
-
-CockroachDB uses the URL provided in a [`BACKUP`](backup.html), [`RESTORE`](restore.html), [`IMPORT`](import.html), or [`EXPORT`](export.html) statement to construct a secure API call to the service you specify. The URL structure depends on the type of file storage you are using.
-
-{{site.data.alerts.callout_success}}
-We strongly recommend using cloud/remote storage (Amazon S3, Google Cloud Platform, etc.).
-{{site.data.alerts.end}}
-
-URLs for the files you want to import must use the format shown below. For examples, see [Example file URLs](#example-file-urls).
-
-~~~
-[scheme]://[host]/[path]?[parameters]
-~~~
-
-Location                                                    | Scheme      | Host                                             | Parameters                                                                 |
-|-------------------------------------------------------------+-------------+--------------------------------------------------+----------------------------------------------------------------------------
-Amazon                                                      | `s3`        | Bucket name                                      | `AUTH` (optional; can be `implicit` or `specified`), `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN` <br><br>For more information, see [Authentication - Amazon S3](#amazon-s3).
-Azure                                                       | `azure`     | N/A (see [Example file URLs](#example-file-urls)) | `AZURE_ACCOUNT_KEY`, `AZURE_ACCOUNT_NAME`
-Google Cloud           | `gs`        | Bucket name                                      | `AUTH` (optional; can be `default`, `implicit`, or `specified`), `CREDENTIALS` <br><br>For more information, see [Authentication - Google Cloud Storage](#google-cloud-storage).
-HTTP&nbsp;[<sup>1</sup>](#considerations)                   | `http`      | Remote host                                      | N/A <br><br>For more information, see [Authentication - HTTP](#http).
-NFS/Local&nbsp;[<sup>2</sup>](#considerations)              | `nodelocal` | `nodeID` or `self` (see [Example file URLs](#example-file-urls)) | N/A
-S3-compatible services | `s3`        | Bucket name                                      | `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`, `AWS_REGION`&nbsp;[<sup>3</sup>](#considerations) (optional), `AWS_ENDPOINT` <br><br>For more information, see [Authentication - S3-compatible services](#s3-compatible-services).
-
-{{site.data.alerts.callout_success}}
-The location parameters often contain special characters that need to be URI-encoded. Use Javascript's [encodeURIComponent](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent) function or Go language's [url.QueryEscape](https://golang.org/pkg/net/url/#QueryEscape) function to URI-encode the parameters. Other languages provide similar functions to URI-encode special characters.
-{{site.data.alerts.end}}
-
-<a name="considerations"></a>
-
-- <sup>1</sup> The file system backup location on the NFS drive is relative to the path specified by the [`--external-io-dir`](cockroach-start.html#flags-external-io-dir) flag set while [starting the node](cockroach-start.html). If the flag is set to `disabled`, then imports from local directories and NFS drives are disabled.
-
-- <sup>2</sup>   Using a `nodeID` is required and the data files will be in the `extern` directory of the specified node. In most cases (including single-node clusters), using `nodelocal://1/<path>` is sufficient. Use `self` if you do not want to specify a `nodeID`, and the individual data files will be in the `extern` directories of arbitrary nodes; however, to work correctly, each node must have the [`--external-io-dir`](cockroach-start.html#flags-external-io-dir) flag point to the same NFS mount or other network-backed, shared storage.
-
-- <sup>3</sup> The `AWS_REGION` parameter is optional since it is not a required parameter for most S3-compatible services. Specify the parameter only if your S3-compatible service requires it.
-
-## Example file URLs
-
-Example URLs for [`BACKUP`](backup.html), [`RESTORE`](restore.html), [`EXPORT`](export.html), or [changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html) given a bucket or container name of `acme-co` and an `employees` subdirectory:
-
-Location     | Example
--------------+----------------------------------------------------------------------------------
-Amazon S3    | `s3://acme-co/employees?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456`
-Azure        | `azure://acme-co/employees?AZURE_ACCOUNT_NAME=acme-co&AZURE_ACCOUNT_KEY=url-encoded-123`
-Google Cloud | `gs://acme-co/employees?AUTH=specified&CREDENTIALS=encoded-123`
-NFS/Local    | `nodelocal://1/path/employees`, `nodelocal://self/nfsmount/backups/employees`&nbsp;[<sup>2</sup>](#considerations)
-
-{{site.data.alerts.callout_info}}
-URLs for [changefeeds](stream-data-out-of-cockroachdb-using-changefeeds.html) should be prepended with `experimental-`.
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Currently, cloud storage sinks (for changefeeds) only work with `JSON` and emits newline-delimited `JSON` files.
-{{site.data.alerts.end}}
-
-Example URLs for [`IMPORT`](import.html) given a bucket or container name of `acme-co` and a filename of `employees`:
-
-Location     | Example
--------------+----------------------------------------------------------------------------------
-Amazon S3    | `s3://acme-co/employees.sql?AWS_ACCESS_KEY_ID=123&AWS_SECRET_ACCESS_KEY=456`
-Azure        | `azure://employees.sql?AZURE_ACCOUNT_KEY=123&AZURE_ACCOUNT_NAME=acme-co`
-Google Cloud | `gs://acme-co/employees.sql`
-HTTP         | `http://localhost:8080/employees.sql`
-NFS/Local    | `nodelocal://1/path/employees`, `nodelocal://self/nfsmount/backups/employees`&nbsp;[<sup>2</sup>](#considerations)
-
-{{site.data.alerts.callout_info}}
-HTTP storage can only be used for [`IMPORT`](import.html).
-{{site.data.alerts.end}}
-
-## Encryption
-
-[Transport Layer Security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security) is used for encryption in transit when transmitting data to or from Amazon S3, Google Cloud Storage, and Azure.
-
-For encryption at rest, if your cloud provider offers transparent data encryption, you can use that to ensure that your backups are not stored on disk in cleartext.
-
-* [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)
-* [Azure Storage](https://docs.microsoft.com/en-us/azure/storage/common/storage-service-encryption#about-azure-storage-encryption)
-* [Google Cloud Storage](https://cloud.google.com/storage/docs/encryption)
-
-CockroachDB also provides client-side encryption of backup data, for more information, see [Take and Restore Encrypted Backups](take-and-restore-encrypted-backups.html).
-
-## Authentication
-
-Authentication behavior differs by cloud provider:
-
-### Amazon S3
-
-  - If the `AUTH` parameter is not provided, AWS connections default to `specified` and the access keys must be provided in the URI parameters.
-
-    As an example:
-
-    ~~~sql
-    BACKUP DATABASE <database> INTO 's3://{bucket name}/{path in bucket}/?AWS_ACCESS_KEY_ID={access key ID}&AWS_SECRET_ACCESS_KEY={secret access key}';
-    ~~~
-
-  -  If the `AUTH` parameter is `implicit`, the access keys can be omitted and [the credentials will be loaded from the environment](https://docs.aws.amazon.com/sdk-for-go/api/aws/session/), i.e. the machines running the backup.
-
-    ~~~sql
-    BACKUP DATABASE <database> INTO 's3://{bucket name}/{path}?AUTH=implicit';
-    ~~~
-
-    You [can associate an EC2 instance with an IAM role](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html) to provide implicit access to S3 storage within the IAM role's policy. In the following command, the `instance example` EC2 instance is [associated](https://docs.aws.amazon.com/cli/latest/reference/ec2/associate-iam-instance-profile.html) with the `example profile` instance profile, giving the EC2 instance implicit access to any `example profile` S3 buckets.
-
-    ~~~shell
-    aws ec2 associate-iam-instance-profile --iam-instance-profile Name={example profile} --region={us-east-2} --instance-id {instance example}
-    ~~~
-
-### Google Cloud Storage
-
-If the `AUTH` parameter is set to:
-
-  - `default`: GCS connections only use the key provided in the `cloudstorage.gs.default.key` [cluster setting](cluster-settings.html), and will error if not present.
-  - `specified`: Pass the JSON object for authentication to the `CREDENTIALS` parameter. The JSON key object needs to be base64-encoded (using the standard encoding in [RFC 4648](https://tools.ietf.org/html/rfc4648)).
-
-    To access the storage bucket with specified credentials, it's necessary to [create a service account](https://cloud.google.com/iam/docs/creating-managing-service-accounts) and add the service account address to the permissions on the specific storage bucket. [The JSON object for authentication](https://cloud.google.com/iam/docs/creating-managing-service-account-keys#iam-service-account-keys-create-console) can be downloaded, encoded, and then passed to the `CREDENTIALS` parameter.
-
-    ~~~sql
-    BACKUP DATABASE <database> INTO 'gs://{bucket name}/{path}?AUTH=specified&CREDENTIALS={encoded key}';
-    ~~~
-
-  - `implicit`: The instance can use [environment data](https://cloud.google.com/docs/authentication/production#providing_credentials_to_your_application) from the service account to access resources. This will provide implicit access to the storage bucket.
-
-    ~~~sql
-    BACKUP DATABASE <database> INTO 'gs://{bucket name}/{path}?AUTH=implicit';
-    ~~~
-
-  - If `AUTH` is not provided, use the key provided in the `cloudstorage.gs.default.key` [cluster setting](cluster-settings.html). Otherwise, use environment data.
-
-    {% include {{ page.version.version }}/backups/gcs-default-deprec.md %}
-
-### Azure Storage
-
-To access Azure storage containers, it is sometimes necessary to [url encode](https://en.wikipedia.org/wiki/Percent-encoding) the account key since it is base64-encoded and may contain `+`, `/`, `=` characters. For example:
-
-~~~sql
-BACKUP DATABASE <database> INTO 'azure://{container name}/{path}?AZURE_ACCOUNT_NAME={account name}&AZURE_ACCOUNT_KEY={url-encoded key}';
-~~~
-
-### HTTP
-
-If your environment requires an HTTP or HTTPS proxy server for outgoing connections, you can set the standard `HTTP_PROXY` and `HTTPS_PROXY` [environment variables](cockroach-commands.html#environment-variables) when starting CockroachDB. You can create your own HTTP server with [NGINX](use-a-local-file-server-for-bulk-operations.html). A custom root CA can be appended to the system's default CAs by setting the `cloudstorage.http.custom_ca` [cluster setting](cluster-settings.html), which will be used when verifying certificates from HTTPS URLs.
-
-If you cannot run a full proxy, you can disable external HTTP(S) access (as well as custom HTTP(S) endpoints) when importing by using the [`--external-io-disable-http` flag](cockroach-start.html#flags-external-io-disable-http).
-
-### S3-compatible services
-
-A custom root CA can be appended to the system's default CAs by setting the `cloudstorage.http.custom_ca` [cluster setting](cluster-settings.html), which will be used when verifying certificates from an S3-compatible service.
-
-## See also
-
-- [`BACKUP`](backup.html)
-- [`RESTORE`](restore.html)
-- [`IMPORT`](import.html)
-- [`EXPORT`](export.html)
-- [`CREATE CHANGEFEED`](create-changefeed.html)
-- [Cluster Settings](cluster-settings.html)
diff --git a/src/current/v20.2/use-userfile-for-bulk-operations.md b/src/current/v20.2/use-userfile-for-bulk-operations.md
deleted file mode 100644
index d6774c4a5a9..00000000000
--- a/src/current/v20.2/use-userfile-for-bulk-operations.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: Use Userfile for Bulk Operations
-summary: The IMPORT statement imports various types of data into CockroachDB.with user-scoped storage.
-toc: true
----
-
-<span class="version-tag">New in v20.2:</span> To put files on your CockroachDB cluster without external servers, use `userfile`, a per-user bulk file storage. To interact with `userfile`, use the following [commands](cockroach-commands.html):
-
-- [`cockroach userfile upload`](#upload-a-file)
-- [`cockroach userfile list`](#list-files)
-- [`cockroach userfile delete`](#delete-files)
-
-Once a userfile is uploaded, you can run [`IMPORT`](#import-from-userfile).
-
-## Upload a file
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile upload /Users/maxroach/Desktop/test-data.csv /test-data.csv --certs-dir=certs
-~~~
-
-~~~
-successfully uploaded to userfile://defaultdb.public.userfiles_root/test-data.csv
-~~~
-
-For more information, see [`cockroach userfile upload`](cockroach-userfile-upload.html).
-
-## List files
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile list '*.csv' --certs-dir=certs
-~~~
-
-~~~
-userfile://defaultdb.public.userfiles_root/test-data-2.csv
-userfile://defaultdb.public.userfiles_root/test-data.csv
-~~~
-
-For more information, see [`cockroach userfile list`](cockroach-userfile-list.html).
-
-## Delete files
-
-{% include copy-clipboard.html %}
-~~~ shell
-$ cockroach userfile delete test-data.csv --certs-dir=certs
-~~~
-
-~~~
-deleted userfile://defaultdb.public.userfiles_root/test-data.csv
-~~~
-
-For more information, see [`cockroach userfile delete`](cockroach-userfile-delete.html).
-
-## Import from `userfile`
-
-{% include copy-clipboard.html %}
-~~~ sql
-> IMPORT TABLE customers (
-		id INT,
-		dob DATE,
-		first_name STRING,
-    last_name STRING,
-    joined DATE
-)
-CSV DATA (
-    'userfile:///test-data.csv'
-);
-~~~
-
-{{site.data.alerts.callout_info}}
-`userfile:///` (note the three slashes) references the default path (`userfile://defaultdb.public.userfiles_$user/`).
-{{site.data.alerts.end}}
-
-~~~
-        job_id       |  status   | fraction_completed |  rows  | index_entries |  bytes
----------------------+-----------+--------------------+--------+---------------+-----------
-  599865027685613569 | succeeded |                  1 | 300024 |             0 | 13389972
-(1 row)
-~~~
-
-For more import options, see [`IMPORT`](import.html) or [`IMPORT INTO`](import-into.html).
-
-## See also
-
-- [`cockroach userfile upload`](cockroach-userfile-upload.html)
-- [`cockroach userfile list`](cockroach-userfile-list.html)
-- [`cockroach userfile delete`](cockroach-userfile-delete.html)
-- [Other Cockroach Commands](cockroach-commands.html)
-- [`IMPORT`](import.html)
-- [`IMPORT INTO`](import-into.html)
diff --git a/src/current/v20.2/uuid.md b/src/current/v20.2/uuid.md
deleted file mode 100644
index 9aa6d5536ad..00000000000
--- a/src/current/v20.2/uuid.md
+++ /dev/null
@@ -1,137 +0,0 @@
----
-title: UUID
-summary: The UUID data type stores 128-bit Universal Unique Identifiers.
-toc: true
----
-
-The `UUID` (Universally Unique Identifier) [data type](data-types.html) stores a 128-bit value that is [unique across both space and time](https://www.ietf.org/rfc/rfc4122.txt).
-
-{{site.data.alerts.callout_success}}
-To auto-generate unique row identifiers, use [`UUID`](uuid.html) with the `gen_random_uuid()` function as the default value. See the [example](#create-a-table-with-auto-generated-unique-row-ids) below for more details.
-{{site.data.alerts.end}}
-
-## Syntax
-
-You can express `UUID` values using the following formats:
-
-Format | Description
--------|-------------
-Standard [RFC4122](http://www.ietf.org/rfc/rfc4122.txt) format | Hyphen-separated groups of 8, 4, 4, 4, and 12 hexadecimal digits.<br><br>Example: `acde070d-8c4c-4f0d-9d8a-162843c10333`
-`BYTES` | `UUID` value specified as a [`BYTES`](bytes.html) value.<br><br>Example: `b'kafef00ddeadbeed'`
-Uniform Resource Name | A [Uniform Resource Name (URN)](https://www.ietf.org/rfc/rfc2141.txt) specified as "urn:uuid:" followed by the [RFC4122](http://www.ietf.org/rfc/rfc4122.txt) format.<br><br>Example: `urn:uuid:63616665-6630-3064-6465-616462656564`
-Alternate RFC4122 formats | The [RFC4122](http://www.ietf.org/rfc/rfc4122.txt) format, surrounded by braces, expressed with upper-case digits, or with hyphens omitted.<br><br>Examples: `{acde070d-8c4c-4f0d-9d8a-162843c10333}`, `ACDE070D-8C4C-4f0D-9d8A-162843c10333`, `acde070d8c4c4f0d9d8a162843c10333`
-
-CockroachDB displays all `UUID` values in the standard [RFC4122](http://www.ietf.org/rfc/rfc4122.txt) format.
-
-## Size
-
-A `UUID` value is 128 bits in width, but the total storage size is likely to be larger due to CockroachDB metadata.
-
-## Examples
-
-### Create a table with manually-entered `UUID` values
-
-#### Create a table with `UUID` in standard [RFC4122](http://www.ietf.org/rfc/rfc4122.txt)-specified format
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TABLE v (token uuid);
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO v VALUES ('63616665-6630-3064-6465-616462656562');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM v;
-~~~
-
-~~~
-                 token
-----------------------------------------
-  63616665-6630-3064-6465-616462656562
-(1 row)
-~~~
-
-#### Create a table with `UUID` in `BYTE` format
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO v VALUES (b'kafef00ddeadbeed');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM v;
-~~~
-
-~~~
-                 token
-----------------------------------------
-  63616665-6630-3064-6465-616462656562
-  6b616665-6630-3064-6465-616462656564
-(2 rows)
-~~~
-
-#### Create a table with `UUID` used as URN
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO v VALUES ('urn:uuid:63616665-6630-3064-6465-616462656564');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM v;
-~~~
-
-~~~
-                 token
-----------------------------------------
-  63616665-6630-3064-6465-616462656562
-  6b616665-6630-3064-6465-616462656564
-  63616665-6630-3064-6465-616462656564
-(3 rows)
-~~~
-
-#### Express UUIDs in alternate formats
-
-{% include copy-clipboard.html %}
-~~~ sql
-> INSERT INTO v VALUES ('{acde070d-8c4c-4f0d-9d8a-162843c10333}'), ('ACDE070D-8C4C-4f0D-9d8A-162843c10333'), ('acde070d8c4c4f0d9d8a162843c10333');
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM v;
-~~~
-
-~~~
-                 token
-----------------------------------------
-  63616665-6630-3064-6465-616462656562
-  6b616665-6630-3064-6465-616462656564
-  63616665-6630-3064-6465-616462656564
-  acde070d-8c4c-4f0d-9d8a-162843c10333
-  acde070d-8c4c-4f0d-9d8a-162843c10333
-  acde070d-8c4c-4f0d-9d8a-162843c10333
-(6 rows)
-~~~
-
-### Create a table with auto-generated unique row IDs
-
-{% include {{ page.version.version }}/faq/auto-generate-unique-ids.html %}
-
-## Supported casting and conversion
-
-`UUID` values can be [cast](data-types.html#data-type-conversions-and-casts) to the following data type:
-
-Type | Details
------|--------
-`BYTES` | Requires supported [`BYTES`](bytes.html) string format, e.g., `b'\141\061\142\062\143\063'`.
-
-## See also
-
-[Data Types](data-types.html)
diff --git a/src/current/v20.2/validate-constraint.md b/src/current/v20.2/validate-constraint.md
deleted file mode 100644
index 9cf769acdb8..00000000000
--- a/src/current/v20.2/validate-constraint.md
+++ /dev/null
@@ -1,60 +0,0 @@
----
-title: VALIDATE CONSTRAINT
-summary: Use the ADD COLUMN statement to add columns to tables.
-toc: true
----
-
-The `VALIDATE CONSTRAINT` [statement](sql-statements.html) is part of `ALTER TABLE` and checks whether values in a column match a [constraint](constraints.html) on the column. This statement is especially useful after applying a constraint to an existing column via [`ADD CONSTRAINT`](add-constraint.html). In this case, `VALIDATE CONSTRAINT` can be used to find values already in the column that do not match the constraint.
-
-{% include {{ page.version.version }}/sql/combine-alter-table-commands.md %}
-
-## Required privileges
-
-The user must have the `CREATE` [privilege](authorization.html#assign-privileges) on the table.
-
-## Synopsis
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/validate_constraint.html %}
-</div>
-
-## Parameters
-
- Parameter         | Description                                                                 
--------------------+-----------------------------------------------------------------------------
- `table_name`      | The name of the table in which the constraint you'd like to validate lives.
- `constraint_name` | The name of the constraint on `table_name` you'd like to validate.          
-
-## Viewing schema changes
-
-{% include {{ page.version.version }}/misc/schema-change-view-job.md %}
-
-## Examples
-
-In [`ADD CONSTRAINT`](add-constraint.html), we [added a foreign key constraint](add-constraint.html#add-the-foreign-key-constraint-with-cascade) like so:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE orders ADD CONSTRAINT customer_fk FOREIGN KEY (customer_id) REFERENCES customers (id) ON DELETE CASCADE;
-~~~
-
-In order to ensure that the data added to the `orders` table prior to the creation of the `customer_fk` constraint conforms to that constraint, run the following:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE orders VALIDATE CONSTRAINT customer_fk;
-~~~
-
-{{site.data.alerts.callout_info}}
-If present in a [`CREATE TABLE`](create-table.html) statement, the table is considered validated because an empty table trivially meets its constraints.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Constraints](constraints.html)
-- [`ADD CONSTRAINT`](add-constraint.html)
-- [`SHOW CONSTRAINTS`](show-constraints.html)
-- [`RENAME CONSTRAINT`](rename-constraint.html)
-- [`DROP CONSTRAINT`](drop-constraint.html)
-- [`CREATE TABLE`](create-table.html)
-- [`SHOW JOBS`](show-jobs.html)
diff --git a/src/current/v20.2/vectorized-execution.md b/src/current/v20.2/vectorized-execution.md
deleted file mode 100644
index fecf4601c7a..00000000000
--- a/src/current/v20.2/vectorized-execution.md
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: Vectorized Query Execution
-summary: The CockroachDB vectorized SQL query execution engine processes query plans using a column-oriented model to improve performance.
-toc: true
----
-
-CockroachDB supports [column-oriented](https://en.wikipedia.org/wiki/Column-oriented_DBMS#Column-oriented_systems) ("vectorized") query execution on all [CockroachDB data types](data-types.html).
-
-Many SQL databases execute [query plans](https://en.wikipedia.org/wiki/Query_plan) one row of table data at a time. Row-oriented execution models can offer good performance for [online transaction processing (OLTP)](https://en.wikipedia.org/wiki/Online_transaction_processing) queries, but suboptimal performance for [online analytical processing (OLAP)](https://en.wikipedia.org/wiki/Online_analytical_processing) queries. The CockroachDB vectorized execution engine dramatically improves performance over [row-oriented execution](https://en.wikipedia.org/wiki/Column-oriented_DBMS#Row-oriented_systems) by processing each component of a query plan on type-specific batches of column data.
-
-## Configuring vectorized execution
-
- <span class="version-tag">New in v20.2:</span> By default, vectorized execution is enabled in CockroachDB.
-
-You can configure vectorized execution with the `vectorize` [session variable](set-vars.html). The following options are supported:
-
-Option    | Description
-----------|------------
-`on`   | Turns on vectorized execution for all queries on rows over the [`vectorize_row_count_threshold`](#setting-the-row-threshold-for-vectorized-execution) (1000 rows, by default).<br><br>**Default:** `vectorize=on`
-`201auto` | Follows the [vectorized execution behavior of CockroachDB v20.1](../v20.1/vectorized-execution.html), instructing CockroachDB to use the vectorized execution engine on queries that use a constant amount of memory, on [data types supported by the vectorized engine in CockroachDB v20.1](../v20.1/data-types.html).
-`off`  | Turns off vectorized execution for all queries.
-
-For information about setting session variables, see [`SET` &lt;session variable&gt;](set-vars.html).
-
-{{site.data.alerts.callout_success}}
-To see if CockroachDB will use the vectorized execution engine for a query, run a simple [`EXPLAIN`](explain.html) statement on the query. If `vectorize` is `true`, the query will be executed with the vectorized engine. If it is `false`, the row-oriented execution engine is used instead.
-{{site.data.alerts.end}}
-
-### Setting the row threshold for vectorized execution
-
-The efficiency of vectorized execution increases with the number of rows processed. If you are querying a table with a small number of rows, it is more efficient to use row-oriented execution.
-
-By default, vectorized execution is enabled for queries on tables of 1000 rows or more. If the number of rows in a table falls below 1000, CockroachDB uses the row-oriented execution engine instead.
-
-For performance tuning, you can change the minimum number of rows required to use the vectorized engine to execute a query plan in the current session with the `vectorize_row_count_threshold` [session variable](set-vars.html).
-
-## How vectorized execution works
-
-When you issue a query, the gateway node (i.e., the node from which you issue the query) [parses the query and creates a physical plan](architecture/sql-layer.html#sql-parser-planner-executor) for execution on each node that receives the plan. If vectorized execution is enabled, the physical plan is sent to each node to be executed by the vectorized execution engine.
-
-{{site.data.alerts.callout_success}}
-To see a detailed view of the vectorized execution plan for a query, run the [`EXPLAIN(VEC)`](explain.html#vec-option) statement on the query.
-{{site.data.alerts.end}}
-
-For information about vectorized execution in the context of the CockroachDB architecture, see [Query Execution](architecture/sql-layer.html#query-execution).
-
-For detailed examples of vectorized query execution for hash and merge joins, see the blog posts [40x faster hash joiner with vectorized execution](https://www.cockroachlabs.com/blog/vectorized-hash-joiner/) and [Vectorizing the merge joiner in CockroachDB](https://www.cockroachlabs.com/blog/vectorizing-the-merge-joiner-in-cockroachdb/).
-
-## Disk-spilling operations
-
-The following operations require [memory buffering](https://en.wikipedia.org/wiki/Data_buffer) during execution:
-
-- Global [sorts](order-by.html)
-- [Unordered aggregations](order-by.html)
-- [Hash joins](joins.html#hash-joins)
-- [Merge joins](joins.html#merge-joins) on non-unique columns. Merge joins on columns that are guaranteed to have one row per value, also known as "key columns", can execute entirely in-memory.
-- [Window functions](window-functions.html). Note that [support for window functions is limited in the vectorized execution engine](#window-functions).
-
-If there is not enough memory allocated for an operation, CockroachDB will spill the intermediate execution results to disk if the operation supports disk spilling. By default, the memory limit allocated per operator is 64MiB. You can change this limit with the `sql.distsql.temp_storage.workmem` [cluster setting](cluster-settings.html).
-
-You can also configure a node's total budget for in-memory query processing at node startup with the [`--max-sql-memory` flag](cockroach-start.html#general). If the queries running on the node exceed the memory budget, the node spills intermediate execution results to disk, if possible. The [`--max-disk-temp-storage` flag](cockroach-start.html#general) sets the maximum on-disk storage capacity. If the maximum on-disk storage capacity is reached, the query will return an error during execution.
-
-## Known limitations
-
-### Unordered aggregation operations
-
-{% include {{ page.version.version }}/known-limitations/unordered-operations.md %}
-
-### Unsupported queries
-
-The vectorized engine does not support queries containing:
-
-- A join filtered with an [`ON` expression](joins.html#supported-join-conditions). See [tracking issue](https://github.com/cockroachdb/cockroach/issues/38018).
-
-### Window functions
-
-Support for certain [window functions](window-functions.html) is limited in the vectorized execution engine. If a query includes an unsupported window function, the window function will be handled by the row-oriented execution engine. If the same query includes other, supported operations, those operations will be handled by the vectorized execution engine. See [tracking issue](https://github.com/cockroachdb/cockroach/issues/37040).
-
-### Spatial features
-
-The vectorized engine does not support [working with spatial data](spatial-data.html). Queries with [geospatial functions](functions-and-operators.html#spatial-functions) or [spatial data](spatial-data.html) will revert to the row-oriented execution engine.
-
-## See also
-
-- [SQL Layer](architecture/sql-layer.html)
-- [`SET` &lt;session variable&gt;](set-vars.html)
-- [`SHOW` &lt;session variable&gt;](show-vars.html)
diff --git a/src/current/v20.2/views.md b/src/current/v20.2/views.md
deleted file mode 100644
index a08a529bdab..00000000000
--- a/src/current/v20.2/views.md
+++ /dev/null
@@ -1,621 +0,0 @@
----
-title: Views
-summary: Learn about CockroachDB's dematerialized and materialized views.
-toc: true
----
-
-A view is a stored and named [selection query](selection-queries.html). By default, CockroachDB's views are **dematerialized**: they do not store the results of the underlying queries. Instead, the underlying query is executed anew every time the view is used.
-
-<span class="version-tag">New in v20.2:</span> CockroachDB also supports [**materialized views**](#materialized-views). Materialized views are views that store their selection query results.
-
-{{site.data.alerts.callout_info}}
-<span class="version-tag">New in v20.2:</span> By default, views created in a database cannot reference objects in a different database. To enable cross-database references for views, set the `sql.cross_db_views.enabled` [cluster setting](cluster-settings.html) to `true`.
-{{site.data.alerts.end}}
-
-## Why use views?
-
-There are various reasons to use views, including:
-
-- [Hide query complexity](#hide-query-complexity)
-- [Limit access to underlying data](#limit-access-to-underlying-data)
-
-### Hide query complexity
-
-When you have a complex query that, for example, joins several tables, or performs complex calculations, you can store the query as a view and then select from the view as you would from a standard table.
-
-#### Example
-
-Let's say you're using our [sample `startrek` database](cockroach-gen.html#generate-example-data), which contains two tables, `episodes` and `quotes`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> USE startrek;
-~~~
-
-There's a foreign key constraint between the `episodes.id` column and the `quotes.episode` column. To count the number of famous quotes per season, you could run the following join:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT episodes.season, count(*)
-  FROM quotes
-  JOIN episodes
-  ON quotes.episode = episodes.id
-  GROUP BY episodes.season;
-~~~
-
-~~~
-  season | count
----------+--------
-       1 |    78
-       2 |    76
-       3 |    46
-(3 rows)
-~~~
-
-Alternatively, to make it much easier to run this complex query, you could create a view:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE VIEW quotes_per_season (season, quotes)
-  AS SELECT episodes.season, count(*)
-  FROM quotes
-  JOIN episodes
-  ON quotes.episode = episodes.id
-  GROUP BY episodes.season
-  ORDER BY episodes.season;
-~~~
-
-Then, executing the query is as easy as `SELECT`ing from the view:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM quotes_per_season;
-~~~
-
-~~~
-  season | quotes
----------+---------
-       1 |     78
-       2 |     76
-       3 |     46
-(3 rows)
-~~~
-
-### Limit access to underlying data
-
-When you do not want to grant a user access to all the data in one or more standard tables, you can create a view that contains only the columns and/or rows that the user should have access to and then grant the user permissions on the view.
-
-#### Example
-
-Let's say you have a `bank` database containing an `accounts` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> USE bank;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-  id |   type   | balance |      email
------+----------+---------+------------------
-   1 | checking |    1000 | max@roach.com
-   2 | savings  |   10000 | max@roach.com
-   3 | checking |   15000 | betsy@roach.com
-   4 | checking |    5000 | lilly@roach.com
-   5 | savings  |   50000 | ben@roach.com
-(5 rows)
-~~~
-
-You want a particular user, `bob`, to be able to see the types of accounts each user has without seeing the balance in each account, so you create a view to expose just the `type` and `email` columns:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE VIEW user_accounts
-  AS SELECT type, email
-  FROM accounts;
-~~~
-
-You then make sure `bob` does not have privileges on the underlying `accounts` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW GRANTS ON accounts;
-~~~
-
-~~~
-  database_name | schema_name | table_name | grantee | privilege_type
-----------------+-------------+------------+---------+-----------------
-  bank          | public      | accounts   | admin   | ALL
-  bank          | public      | accounts   | root    | ALL
-(2 rows)
-~~~
-
-Finally, you grant `bob` privileges on the `user_accounts` view:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> GRANT SELECT ON user_accounts TO bob;
-~~~
-
-Now, `bob` will get a permissions error when trying to access the underlying `accounts` table but will be allowed to query the `user_accounts` view:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM accounts;
-~~~
-
-~~~
-pq: user bob does not have SELECT privilege on table accounts
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM user_accounts;
-~~~
-
-~~~
-    type   |      email
------------+------------------
-  checking | max@roach.com
-  savings  | max@roach.com
-  checking | betsy@roach.com
-  checking | lilly@roach.com
-  savings  | ben@roach.com
-(5 rows)
-~~~
-
-## How views work
-
-### Creating views
-
-To create a view, use the [`CREATE VIEW`](create-view.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE VIEW quotes_per_season (season, quotes)
-  AS SELECT episodes.season, count(*)
-  FROM quotes
-  JOIN episodes
-  ON quotes.episode = episodes.id
-  GROUP BY episodes.season
-  ORDER BY episodes.season;
-~~~
-
-{{site.data.alerts.callout_info}}
-Any [selection query](selection-queries.html) is valid as operand to `CREATE VIEW`, not just [simple `SELECT` clauses](select-clause.html).
-{{site.data.alerts.end}}
-
-### Listing views
-
-Once created, views are listed alongside regular tables in the database:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES FROM startrek;
-~~~
-
-~~~
-  schema_name |    table_name     | type  | estimated_row_count
---------------+-------------------+-------+----------------------
-  public      | episodes          | table |                  79
-  public      | quotes            | table |                 200
-  public      | quotes_per_season | view  |                   0
-(3 rows)
-~~~
-
-To list just views, you can query the `views` table in the [Information Schema](information-schema.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM information_schema.views;
-~~~
-
-~~~
-  table_catalog | table_schema |    table_name     |                                                                               view_definition                                                                                | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
-----------------+--------------+-------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+--------------+--------------+--------------------+----------------------+----------------------+-----------------------------
-  startrek      | public       | quotes_per_season | SELECT episodes.season, count(*) FROM startrek.public.quotes JOIN startrek.public.episodes ON quotes.episode = episodes.id GROUP BY episodes.season ORDER BY episodes.season | NULL         | NO           | NO                 | NO                   | NO                   | NO
-(1 row)
-~~~
-
-### Querying views
-
-To query a view, target it with a [table expression](table-expressions.html#table-or-view-names), for example using a [`SELECT` clause](select-clause.html), just as you would with a stored table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM quotes_per_season;
-~~~
-
-~~~
-  season | quotes
----------+---------
-       1 |     78
-       2 |     76
-       3 |     46
-(3 rows)
-~~~
-
-`SELECT`ing a view executes the view's stored `SELECT` statement, which returns the relevant data from the underlying table(s). To inspect the `SELECT` statement executed by the view, use the [`SHOW CREATE`](show-create.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW CREATE quotes_per_season;
-~~~
-
-~~~
-     table_name     |                                                                                                           create_statement
---------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  quotes_per_season | CREATE VIEW public.quotes_per_season (season, quotes) AS SELECT episodes.season, count(*) FROM startrek.public.quotes JOIN startrek.public.episodes ON quotes.episode = episodes.id GROUP BY episodes.season ORDER BY episodes.season
-(1 row)
-~~~
-
-You can also inspect the `SELECT` statement executed by a view by querying the `views` table in the [Information Schema](information-schema.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT view_definition FROM information_schema.views WHERE table_name = 'quotes_per_season';
-~~~
-
-~~~
-                                                                                view_definition
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-  SELECT episodes.season, count(*) FROM startrek.public.quotes JOIN startrek.public.episodes ON quotes.episode = episodes.id GROUP BY episodes.season ORDER BY episodes.season
-(1 row)
-~~~
-
-### View dependencies
-
-A view depends on the objects targeted by its underlying query. Attempting to [rename an object](rename-table.html) referenced in a view's stored query therefore results in an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE quotes RENAME TO sayings;
-~~~
-
-~~~
-ERROR: cannot rename relation "startrek.public.quotes" because view "quotes_per_season" depends on it
-SQLSTATE: 2BP01
-HINT: you can drop quotes_per_season instead.
-~~~
-
-Likewise, attempting to [drop an object](drop-table.html) referenced in a view's stored query results in an error:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TABLE quotes;
-~~~
-
-~~~
-ERROR: cannot drop relation "quotes" because view "quotes_per_season" depends on it
-SQLSTATE: 2BP01
-HINT: you can drop quotes_per_season instead.
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE episodes DROP COLUMN season;
-~~~
-
-~~~
-ERROR: cannot drop column "season" because view "quotes_per_season" depends on it
-SQLSTATE: 2BP01
-HINT: you can drop quotes_per_season instead.
-~~~
-
-<span class="version-tag">New in v20.2:</span> You can [drop](drop-column.html) or [rename columns](rename-column.html) from a table on which a view is dependent, as long as the view does not depend on that column of the table. For example, because there is no view that depends on the `num` column of the `episodes` table, you can rename it to `number`:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE startrek.episodes RENAME COLUMN num TO number;
-~~~
-
-Similarly, because no view depends on the `title` column of the `episodes` table, you can drop it. Note that to drop a column with data in it, you must first set `sql_safe_updates = false`.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SET sql_safe_updates = false;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER TABLE startrek.episodes DROP COLUMN title;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW COLUMNS FROM startrek.episodes;
-~~~
-
-~~~
-  column_name | data_type | is_nullable | column_default | generation_expression |  indices  | is_hidden
---------------+-----------+-------------+----------------+-----------------------+-----------+------------
-  id          | INT8      |    false    | NULL           |                       | {primary} |   false
-  season      | INT8      |    true     | NULL           |                       | {}        |   false
-  number      | INT8      |    true     | NULL           |                       | {}        |   false
-  stardate    | DECIMAL   |    true     | NULL           |                       | {}        |   false
-(4 rows)
-~~~
-
-When [dropping a table](drop-table.html) or [dropping a view](drop-view.html), you can use the `CASCADE` keyword to drop all dependent objects as well:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP TABLE quotes CASCADE;
-~~~
-
-~~~
-DROP TABLE
-~~~
-
-{{site.data.alerts.callout_danger}}
-`CASCADE` drops **all** dependent objects without listing them, which can lead to inadvertent and difficult-to-recover losses. To avoid potential harm, we recommend dropping objects individually in most cases.
-{{site.data.alerts.end}}
-
-### Renaming views
-
-To rename a view, use the [`ALTER VIEW`](alter-view.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER VIEW quotes_per_season RENAME TO quotes_count;
-~~~
-
-~~~
-RENAME VIEW
-~~~
-
-It is not possible to change the stored query executed by the view. Instead, you must drop the existing view and create a new view.
-
-### Replacing views
-
-<span class="version-tag">New in v20.2:</span> To replace a view, use [`CREATE OR REPLACE VIEW`](create-view.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE OR REPLACE VIEW quotes_count (season, quotes, stardate)
-  AS SELECT episodes.season, count(*), episodes.stardate
-  FROM quotes
-  JOIN episodes
-  ON quotes.episode = episodes.id
-  GROUP BY episodes.season, episodes.stardate;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM quotes_count LIMIT 10;
-~~~
-
-~~~
-  season | quotes | stardate
----------+--------+-----------
-       1 |      5 |   1709.2
-       1 |      7 |   2821.5
-       1 |      2 |   3113.2
-       1 |      6 |     3134
-       1 |      3 |   2715.1
-       1 |      7 |   3012.4
-       1 |      2 |   3196.1
-       2 |      4 |   3468.1
-       2 |      1 |   3541.9
-       2 |      5 |   4211.4
-(10 rows)
-~~~
-
-### Removing views
-
-To remove a view, use the [`DROP VIEW`](drop-view.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP VIEW quotes_count;
-~~~
-
-~~~
-DROP VIEW
-~~~
-
-## Materialized views
-
-<span class="version-tag">New in v20.2:</span> CockroachDB supports [materialized views](https://en.wikipedia.org/wiki/Materialized_view). Materialized views are views that store the results of their underlying queries.
-
-When you [select](selection-queries.html) from a materialized view, the stored query data that is returned might be out-of-date. This contrasts with a standard (i.e., "dematerialized") view, which runs its underlying query every time it is used, returning the latest results. In order to get the latest results from a materialized view, you must [refresh the view](refresh.html), and then select from it.
-
-Because materialized views store query results, they offer better performance than standard views, at the expense of the additional storage required to store query results and the guarantee that the results are up-to-date.
-
-### Usage
-
-Materialized views and standard views share similar syntax for [creating](create-view.html), [showing](show-tables.html), [renaming](alter-view.html), and [dropping](drop-view.html).
-
-To create a materialized view, use a [`CREATE MATERIALIZED VIEW`](create-view.html) statement.
-
-For example, suppose that you have the [sample `bank` database](cockroach-workload.html#bank-workload) loaded to a CockroachDB cluster, and populated with some workload values:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE MATERIALIZED VIEW overdrawn_accounts
-  AS SELECT id, balance
-  FROM bank
-  WHERE balance < 0;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM overdrawn_accounts;
-~~~
-
-~~~
-  id  | balance
-------+----------
-    1 |  -17643
-    3 |   -5928
-   13 |   -3700
-...
-(402 rows)
-~~~
-
-To show existing materialized views, use a [`SHOW TABLES`](show-tables.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SHOW TABLES;
-~~~
-
-~~~
-  schema_name |     table_name     |       type        | estimated_row_count
---------------+--------------------+-------------------+----------------------
-  public      | bank               | table             |                1000
-  public      | overdrawn_accounts | materialized view |                   0
-(2 rows)
-~~~
-
-Now suppose you update the `balance` values of the `bank` table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> UPDATE bank SET balance = 0 WHERE balance < 0;
-~~~
-
-~~~
-UPDATE 402
-~~~
-
-The changes can be seen in the table with a simple `SELECT` statement against the table:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT id, balance
-FROM bank
-WHERE balance < 0;
-~~~
-
-~~~
-  id | balance
------+----------
-(0 rows)
-~~~
-
-Recall that materialized views do not automatically update their stored results. Selecting from `overdrawn_accounts` returns stored results, which are outdated:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM overdrawn_accounts;
-~~~
-
-~~~
-  id  | balance
-------+----------
-    1 |  -17643
-    3 |   -5928
-   13 |   -3700
-...
-(402 rows)
-~~~
-
-To update the materialized view's results, use a [`REFRESH`](refresh.html) statement:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> REFRESH MATERIALIZED VIEW overdrawn_accounts;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM overdrawn_accounts;
-~~~
-
-~~~
-  id | balance
------+----------
-(0 rows)
-~~~
-
-To rename the materialized view, use [`ALTER MATERIALIZED VIEW`](alter-view.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> ALTER MATERIALIZED VIEW overdrawn_accounts RENAME TO forgiven_accounts;
-~~~
-
-~~~
-RENAME VIEW
-~~~
-
-To remove the materialized view, use [`DROP MATERIALIZED VIEW`](drop-view.html):
-
-{% include copy-clipboard.html %}
-~~~ sql
-> DROP MATERIALIZED VIEW forgiven_accounts;
-~~~
-
-~~~
-DROP VIEW
-~~~
-
-## Temporary views
-
-CockroachDB supports session-scoped temporary views. Unlike persistent views, temporary views can only be accessed from the session in which they were created, and they are dropped at the end of the session. You can create temporary views on both persistent tables and [temporary tables](temporary-tables.html).
-
-{{site.data.alerts.callout_danger}}
-**This is an experimental feature**. The interface and output are subject to change. For details, see the tracking issue [cockroachdb/cockroach#46260](https://github.com/cockroachdb/cockroach/issues/46260).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-Temporary tables must be enabled in order to use temporary views. By default, temporary tables are disabled in CockroachDB. To enable temporary tables, set the `experimental_enable_temp_tables` [session variable](set-vars.html) to `on`.
-{{site.data.alerts.end}}
-
-### Details
-
-- Temporary views are automatically dropped at the end of the session.
-- A temporary view can only be accessed from the session in which it was created.
-- Temporary views persist across transactions in the same session.
-- Temporary views cannot be converted to persistent views.
-- Temporary views can be created on both persistent tables and [temporary tables](temporary-tables.html).
-- When you create a view on a temporary table, the view automatically becomes temporary.
-
-{{site.data.alerts.callout_info}}
-Like [temporary tables](temporary-tables.html), temporary views are not in the `public` schema. Instead, when you create the first temporary table, view, or sequence for a session, CockroachDB generates a single temporary schema (`pg_temp_<id>`) for all of the temporary objects in the current session for a database.
-{{site.data.alerts.end}}
-
-### Usage
-
-To create a temporary view, add [`TEMP`/`TEMPORARY`](sql-grammar.html#opt_temp) to a [`CREATE VIEW`](create-view.html) statement.
-
-For example:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> CREATE TEMP VIEW temp_view (season, quotes)
-  AS SELECT episodes.season, count(*)
-  FROM quotes
-  JOIN episodes
-  ON quotes.episode = episodes.id
-  GROUP BY episodes.season;
-~~~
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM temp_view;
-~~~
-
-~~~
-  season | quotes
----------+---------
-       1 |     78
-       2 |     76
-       3 |     46
-(3 rows)
-~~~
-
-## See also
-
-- [Selection Queries](selection-queries.html)
-- [Simple `SELECT` Clauses](select-clause.html)
-- [`CREATE VIEW`](create-view.html)
-- [`SHOW CREATE`](show-create.html)
-- [`GRANT`](grant.html)
-- [`ALTER VIEW`](alter-view.html)
-- [`DROP VIEW`](drop-view.html)
diff --git a/src/current/v20.2/well-known-binary.md b/src/current/v20.2/well-known-binary.md
deleted file mode 100644
index 3da5b5a6e43..00000000000
--- a/src/current/v20.2/well-known-binary.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: Well Known Binary
-summary: The Well Known Binary format provides a representation of a geometric shape that is efficient for machine processing and storage.
-toc: true
----
-
-The Well Known Binary format (hereafter _WKB_) provides a non-textual, binary representation of a geometric shape. It is used to:
-
-- Allow shapes to be transferred between CockroachDB and a [SQL client](cockroach-sql.html) or [application](build-a-java-app-with-cockroachdb.html).
-- Provide a portable binary format that can be read across different platforms.
-
-WKB is obtained by serializing a shape as a sequence of numbers. For more detailed information about the structure of the WKB format, see the diagrams showing WKB integer codes in the [OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture](https://portal.opengeospatial.org/files/?artifact_id=25355).
-
-<a name="ewkb"></a>
-
-The Extended Well Known Binary (_EWKB_) format is the same as WKB, with an [SRID](spatial-glossary.html#srid) representation prepended to the data structure.
-
-## See also
-
-- [Spatial features](spatial-features.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture](https://portal.opengeospatial.org/files/?artifact_id=25355)
-- [Well known text](well-known-text.html)
-- [GeoJSON](geojson.html)
-- [SRID 4326 - longitude and latitude](srid-4326.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/well-known-text.md b/src/current/v20.2/well-known-text.md
deleted file mode 100644
index cf46b141f03..00000000000
--- a/src/current/v20.2/well-known-text.md
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: Well Known Text
-summary: The Well Known Text format provides a text representation of a geometric shape.
-toc: true
----
-
-The Well Known Text format (hereafter _WKT_) provides a text representation of a geometric shape.  It can be used to:
-
-- Build instances of various shapes (e.g., using `ST_MakePolygon` on a Linestring).
-- Convert existing shapes to a text representation for ease of reading.
-
-Each shape in WKT has a _tag_ which says what it is, usually followed by a list of coordinates.  For example, here are some common tags:
-
-- `POINT(...)`
-- `LINESTRING(...)`
-- `POLYGON((...))`
-
-WKT is technically case insensitive, but is sometimes displayed using "CamelCase" for easier reading.  For example, one can represent a MultiPolygon as either of:
-
-- `MULTIPOLYGON(...)`
-- `MultiPolygon(...)`
-
-When a shape is made up of homogeneous subcomponents, such as a polygon made up of various points, the subcomponents do not need to have their own tags. For example:
-
-`LINESTRING(-88.243385 40.116421, -87.906471 43.038902, -95.992775 36.153980)`
-
-<a name="ewkt"></a>
-
-Shapes expressed in WKT can have an [SRID](spatial-glossary.html) prepended to the shape and followed by a semicolon, in the form `SRID=123;TAG(...)`.  The format is known as Extended Well Known Text (_EWKT_); it is the same as WKT, with an [SRID](spatial-glossary.html#srid) representation prepended to the data structure.
-
-For example, below is a polygon representing a geometry that uses [SRID 4326](srid-4326.html), which is used to represent latitude and longitude coordinates on the Earth as defined in the [WGS84](spatial-glossary.html#wgs84) standard:
-
-`SRID=4326;POLYGON((-87.906471 43.038902, -95.992775 36.153980, -75.704722 36.076944, -87.906471 43.038902))`
-
-{{site.data.alerts.callout_info}}
-For more detailed information about the Well Known Text format, see [the OGC specification for WKT](http://docs.opengeospatial.org/is/18-010r7/18-010r7.html).
-{{site.data.alerts.end}}
-
-{{site.data.alerts.callout_info}}
-CockroachDB only supports 2-dimensional geometries.
-{{site.data.alerts.end}}
-
-## See also
-
-- [Spatial features](spatial-features.html)
-- [Spatial indexes](spatial-indexes.html)
-- [Spatial and GIS Glossary of Terms](spatial-glossary.html)
-- [Geographic information — Well-known text representation of coordinate reference systems](http://www.opengis.net/doc/is/wkt-crs/2.0.6)
-- [OpenGIS Implementation Specification for Geographic information - Simple feature access - Part 1: Common architecture](https://portal.opengeospatial.org/files/?artifact_id=25355)
-- [Well known binary](well-known-binary.html)
-- [GeoJSON](geojson.html)
-- [SRID 4326 - longitude and latitude](srid-4326.html)
-- [Introducing Distributed Spatial Data in Free, Open Source CockroachDB](https://www.cockroachlabs.com/blog/spatial-data/) (blog post)
diff --git a/src/current/v20.2/window-functions.md b/src/current/v20.2/window-functions.md
deleted file mode 100644
index 641f2f40ed3..00000000000
--- a/src/current/v20.2/window-functions.md
+++ /dev/null
@@ -1,388 +0,0 @@
----
-title: Window Functions
-summary: A window function performs a calculation across a set of table rows that are somehow related to the current row.
-toc: true
----
-
-CockroachDB supports the application of a function over a subset of the rows returned by a [selection query][selection-query]. Such a function is known as a _window function_, and it allows you to compute values by operating on more than one row at a time. The subset of rows a window function operates on is known as a _window frame_.
-
-For a complete list of supported window functions, see [Functions and Operators](functions-and-operators.html#window-functions).
-
-{{site.data.alerts.callout_success}}
-All [aggregate functions][aggregate-functions] can also be used as [window functions][window-functions]. For more information, see the [Examples](#examples) below.
-{{site.data.alerts.end}}
-
-## Window definitions
-
-Window frames are defined in [`OVER` clauses](sql-grammar.html#over_clause) or [`WINDOW` clauses](sql-grammar.html#window_clause).
-
-### Syntax
-
-<div class="filters clearfix">
-  <button style="width: 15%" class="filter-button" data-scope="basic">Basic</button>
-  <button style="width: 15%" class="filter-button" data-scope="expanded">Expanded</button>
-</div>
-
-<br><br>
-
-<div class="filter-content" markdown="1" data-scope="basic">
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/window_definition.html %}
-</div>
-
-### Parameters
-
-Parameter | Description
-----------|-------------
-`window_name` | The name of the new window frame.
-`opt_existing_window_name` | An optional name of an existing window frame, defined in a different window definition.
-`opt_partition_clause`  | An optional `PARTITION BY` clause.
-`opt_sort_clause` | An optional `ORDER BY` clause. See [Ordering Query Results](order-by.html) for details.
-`opt_frame_clause`  | An optional frame clause, which contains a frame boundary and/or an `EXCLUDE` clause.
-
-</div>
-
-<div class="filter-content" markdown="1" data-scope="expanded">
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/window_definition.html %}
-</div>
-
-**opt_frame_clause ::=**
-
-<div>
-{% include {{ page.version.version }}/sql/diagrams/opt_frame_clause.html %}
-</div>
-
-### Parameters
-
-Parameter | Description
-----------|-------------
-`window_name` | The name of the new window frame.
-`opt_existing_window_name` | An optional name of an existing window frame, defined in a different window definition.
-`opt_partition_clause`  | An optional `PARTITION BY` clause.
-`opt_sort_clause` | An optional `ORDER BY` clause. See [Ordering Query Results](order-by.html) for details.
-`frame_bound` | An optional frame boundary.<br>Valid start boundaries include `UNBOUNDED PRECEDING`, `<offset> PRECEDING`, and `CURRENT ROW`.<br>Valid end boundaries include `UNBOUNDED FOLLOWING`, `<offset> FOLLOWING`, and `CURRENT ROW`.
-`opt_frame_exclusion` | An optional frame `EXCLUDE` clause.<br>Valid exclusions include `CURRENT ROW`, `GROUP`, `TIES`, and `NO OTHERS`.
-
-</div>
-
-## How window functions work
-
-At a high level, window functions work by:
-
-1. Creating a "virtual table" using a [selection query][selection-query].
-2. Splitting that table into window frames with [window definitions](#window-definitions). You can define window frames in an [`OVER` clause](sql-grammar.html#over_clause), directly after the window function, or in a [`WINDOW` clause](sql-grammar.html#window_clause), as a part of the selection query.
-3. Applying the window function to each of the window frames.
-
-For example, consider a query where the window frames are defined for each window function call:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT DISTINCT(city),
-             SUM(revenue) OVER () AS total_revenue,
-             SUM(revenue) OVER (PARTITION BY city) AS city_revenue
-            FROM rides
-        ORDER BY city_revenue DESC;
-~~~
-
-Its operation can be described as follows (numbered steps listed here correspond to the numbers in the diagram below):
-
-1. The outer `SELECT DISTINCT(city) ... FROM rides` creates a "virtual table" on which the window functions will operate.
-2. The window function `SUM(revenue) OVER ()` operates on a window frame containing all rows of the query output.
-3. The window function `SUM(revenue) OVER (PARTITION BY city)` operates on several window frames in turn; each frame contains the `revenue` columns for a different city [partition](partitioning.html) (Amsterdam, Boston, L.A., etc.).
-
-<img src="{{ 'images/v20.2/window-functions.png' | relative_url }}" alt="Window function diagram" style="border:1px solid #eee;max-width:100%" />
-
-### Caveats
-
-The most important part of working with window functions is understanding what data will be in the frame that the window function will be operating on. By default, the window frame includes all of the rows of the partition. If you order the partition, the default frame includes all rows from the first row in the partition to the current row. In other words, adding an `ORDER BY` clause when you create the window frame (e.g., `PARTITION BY x ORDER by y`) has the following effects:
-
-- It makes the rows inside the window frame ordered.
-- It changes what rows the function is called on - no longer all of the rows in the window frame, but a subset between the "first" row and the current row.
-
-Another way of saying this is that you can run a window function on either:
-
-- All rows in the window frame created by the  `PARTITION BY` clause, e.g., `SELECT f(x) OVER () FROM z`.
-- A subset of the rows in the window frame if the frame is created with `SELECT f(x) OVER (PARTITION BY x ORDER BY y) FROM z`.
-
-Because of this, you should be aware of the behavior of any [aggregate function][aggregate-functions] you use as a [window function][window-functions]. If you are not seeing results you expect from a window function, this behavior may explain why. You may need to specify the frame boundaries explicitly in [the window definition](#window-definitions).
-
-{{site.data.alerts.callout_success}}
-If you are running separate window functions over the same window frame, you can define the window frame once in a `WINDOW` clause, and then refer to the window by its name when you call the window function. For an example, see [Customers taking the most rides and generating the most revenue](#customers-taking-the-most-rides-and-generating-the-most-revenue).
-{{site.data.alerts.end}}
-
-## Examples
-
-{% include {{page.version.version}}/sql/movr-statements-geo-partitioned-replicas.md %}
-
-### Customers taking the most rides
-
-To see which customers have taken the most rides, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM
-    (SELECT distinct(name) as "name",
-            COUNT(*) OVER (PARTITION BY name) AS "number of rides"
-     FROM users JOIN rides ON users.id = rides.rider_id)
-  ORDER BY "number of rides" DESC LIMIT 10;
-~~~
-
-~~~
-        name       | number of rides
-+------------------+-----------------+
-  Michael Brown    |              19
-  Richard Bullock  |              17
-  Judy White       |              15
-  Patricia Herrera |              15
-  Tony Ortiz       |              15
-  Maria Weber      |              15
-  Cindy Medina     |              14
-  Samantha Coffey  |              13
-  Nicole Mcmahon   |              13
-  Amy Cobb         |              13
-(10 rows)
-~~~
-
-### Customers generating the most revenue
-
-To see which customers have generated the most revenue, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT DISTINCT name,
-    SUM(revenue) OVER (PARTITION BY name) AS "total rider revenue"
-    FROM users JOIN rides ON users.id = rides.rider_id
-    ORDER BY "total rider revenue" DESC
-    LIMIT 10;
-~~~
-
-~~~
-        name       | total rider revenue
-+------------------+---------------------+
-  Richard Bullock  |              952.00
-  Patricia Herrera |              948.00
-  Maria Weber      |              903.00
-  Michael Brown    |              858.00
-  Judy White       |              818.00
-  Tyler Dalton     |              786.00
-  Samantha Coffey  |              758.00
-  Cindy Medina     |              740.00
-  Tony Ortiz       |              724.00
-  Nicole Mcmahon   |              696.00
-(10 rows)
-~~~
-
-### Add row numbers to query output
-
-To add row numbers to the output, kick the previous query down into a subquery and run the `row_number()` window function.
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT row_number() OVER (), *
-  FROM (
-		  SELECT DISTINCT
-		         name,
-		         sum(revenue) OVER (
-					PARTITION BY name
-		         ) AS "total rider revenue"
-		    FROM users JOIN rides ON users.id = rides.rider_id
-		ORDER BY "total rider revenue" DESC
-		   LIMIT 10
-       );
-~~~
-
-~~~
-  row_number |       name       | total rider revenue
-+------------+------------------+---------------------+
-           1 | Richard Bullock  |              952.00
-           2 | Patricia Herrera |              948.00
-           3 | Maria Weber      |              903.00
-           4 | Michael Brown    |              858.00
-           5 | Judy White       |              818.00
-           6 | Tyler Dalton     |              786.00
-           7 | Samantha Coffey  |              758.00
-           8 | Cindy Medina     |              740.00
-           9 | Tony Ortiz       |              724.00
-          10 | Nicole Mcmahon   |              696.00
-(10 rows)
-~~~
-
-### Customers taking the most rides and generating the most revenue
-
-To see which customers have taken the most rides while generating the most revenue, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM (
-    SELECT DISTINCT name,
-      COUNT(*)     OVER w AS "number of rides",
-      (SUM(revenue) OVER w)::DECIMAL(100,2) AS "total rider revenue"
-      FROM users JOIN rides ON users.ID = rides.rider_id
-      WINDOW w AS (PARTITION BY name)
-    )
-  ORDER BY "number of rides" DESC,
-           "total rider revenue" DESC
-  LIMIT 10;
-~~~
-
-~~~
-        name       | number of rides | total rider revenue
-+------------------+-----------------+---------------------+
-  Michael Brown    |              19 |              858.00
-  Richard Bullock  |              17 |              952.00
-  Patricia Herrera |              15 |              948.00
-  Maria Weber      |              15 |              903.00
-  Judy White       |              15 |              818.00
-  Tony Ortiz       |              15 |              724.00
-  Cindy Medina     |              14 |              740.00
-  Tyler Dalton     |              13 |              786.00
-  Samantha Coffey  |              13 |              758.00
-  Nicole Mcmahon   |              13 |              696.00
-(10 rows)
-~~~
-
-Note that in the query above, a `WINDOW` clause defines the window frame, and the `OVER` clauses reuse the window frame.
-
-### Customers with the highest average revenue per ride
-
-To see which customers have the highest average revenue per ride, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT DISTINCT name,
-    COUNT(*)     OVER w AS "number of rides",
-    AVG(revenue) OVER w AS "average revenue per ride"
-    FROM users JOIN rides ON users.ID = rides.rider_id
-    WINDOW w AS (PARTITION BY name)
-    ORDER BY "average revenue per ride" DESC, "number of rides" ASC
-    LIMIT 10;
-~~~
-
-~~~
-         name         | number of rides | average revenue per ride
-+---------------------+-----------------+--------------------------+
-  Daniel Hernandez MD |               7 |    69.714285714285714286
-  Pamela Morse        |               5 |                    68.40
-  Mark Adams          |               7 |    66.571428571428571429
-  Sarah Wang DDS      |               8 |                   63.375
-  Patricia Herrera    |              15 |                    63.20
-  Taylor Cunningham   |              10 |                    62.60
-  Tyler Dalton        |              13 |    60.461538461538461538
-  Maria Weber         |              15 |                    60.20
-  James Hamilton      |               8 |                    60.00
-  Deborah Carson      |              10 |                    59.70
-(10 rows)
-~~~
-
-### Customers with the highest average revenue per ride, given ten or more rides
-
-To see which customers have the highest average revenue per ride, given that they have taken at least 10 rides, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT * FROM (
-    SELECT DISTINCT name,
-      COUNT(*)     OVER w AS "number of rides",
-      (AVG(revenue) OVER w)::DECIMAL(100,2) AS "average revenue per ride"
-      FROM users JOIN rides ON users.ID = rides.rider_id
-      WINDOW w AS (PARTITION BY name)
-  )
-  WHERE "number of rides" >= 10
-  ORDER BY "average revenue per ride" DESC
-  LIMIT 10;
-~~~
-
-~~~
-        name        | number of rides | average revenue per ride
-+-------------------+-----------------+--------------------------+
-  Patricia Herrera  |              15 |                    63.20
-  Taylor Cunningham |              10 |                    62.60
-  Tyler Dalton      |              13 |                    60.46
-  Maria Weber       |              15 |                    60.20
-  Deborah Carson    |              10 |                    59.70
-  Carl Russell      |              11 |                    58.36
-  Samantha Coffey   |              13 |                    58.31
-  Matthew Clay      |              11 |                    56.09
-  Richard Bullock   |              17 |                    56.00
-  Ryan Hickman      |              10 |                    55.70
-(10 rows)
-~~~
-
-### Total number of riders, and total revenue
-
-To find out the total number of riders and total revenue generated thus far by the app, run:
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT
-    COUNT("id") AS "total # of riders",
-    SUM("total rider revenue") AS "total revenue" FROM (
-      SELECT DISTINCT users.id,
-             SUM(revenue) OVER (PARTITION BY users.id) AS "total rider revenue"
-        FROM users JOIN rides ON users.id = rides.rider_id
-        ORDER BY "total rider revenue" DESC);
-~~~
-
-~~~
-  total # of riders | total revenue
-+-------------------+---------------+
-                 50 |      25628.00
-(1 row)
-~~~
-
-### How many vehicles of each type
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT DISTINCT type, COUNT(*) OVER (PARTITION BY type) AS cnt FROM vehicles ORDER BY cnt DESC;
-~~~
-
-~~~
-     type    | cnt
-+------------+-----+
-  scooter    |   7
-  skateboard |   6
-  bike       |   2
-(3 rows)
-~~~
-
-### How much revenue per city
-
-{% include copy-clipboard.html %}
-~~~ sql
-> SELECT DISTINCT(city), SUM(revenue) OVER (PARTITION BY city) AS city_revenue FROM rides ORDER BY city_revenue DESC;
-~~~
-
-~~~
-      city      | city_revenue
-+---------------+--------------+
-  boston        |      3019.00
-  amsterdam     |      2966.00
-  new york      |      2923.00
-  san francisco |      2857.00
-  paris         |      2849.00
-  washington dc |      2797.00
-  seattle       |      2792.00
-  los angeles   |      2772.00
-  rome          |      2653.00
-(9 rows)
-~~~
-
-## See also
-
-- [Simple `SELECT` clause][simple-select]
-- [Selection Queries][selection-query]
-- [Aggregate functions][aggregate-functions]
-- [Window Functions][window-functions]
-- [CockroachDB 2.0 Demo][demo]
-
-<!-- Links -->
-
-[aggregate-functions]: functions-and-operators.html#aggregate-functions
-[demo]: https://www.youtube.com/watch?v=v2QK5VgLx6E
-[simple-select]: select-clause.html
-[selection-query]: selection-queries.html
-[window-functions]: functions-and-operators.html#window-functions
diff --git a/src/current/v21.1/backup.md b/src/current/v21.1/backup.md
index bc646c3e483..6ddc3b08b84 100644
--- a/src/current/v21.1/backup.md
+++ b/src/current/v21.1/backup.md
@@ -24,7 +24,7 @@ You can also back up:
 Because CockroachDB is designed with high fault tolerance, these backups are designed primarily for disaster recovery (i.e., if your cluster loses a majority of its nodes) through [`RESTORE`](restore.html). Isolated issues (such as small-scale node outages) do not require any intervention.
 
 {{site.data.alerts.callout_info}}
-The [`BACKUP ... TO`](../v20.2/backup.html) and [`RESTORE ... FROM`](../v20.2/restore.html) syntax is **deprecated** as of v22.1 and will be removed in a future release.
+The `BACKUP ... TO` and `RESTORE ... FROM` syntax is **deprecated** as of v22.1 and will be removed in a future release.
 
 We recommend using the `BACKUP ... INTO {collectionURI}` syntax, which creates or adds to a [backup collection](take-full-and-incremental-backups.html#backup-collections) in your storage location. For restoring backups, we recommend using `RESTORE FROM {backup} IN {collectionURI}` with `{backup}` being [`LATEST`](restore.html#restore-the-most-recent-backup) or a specific [subdirectory](restore.html#subdir-param).
 
@@ -152,7 +152,7 @@ Per our guidance in the [Performance](#performance) section, we recommend starti
 {% include {{ page.version.version }}/backups/bulk-auth-options.md %}
 
 {{site.data.alerts.callout_info}}
-{% include_cached new-in.html version="v21.1" %} The syntax `BACKUP ... INTO` adds a backup to a collection within the backup destination. The path to the backup is created using a date-based naming scheme. Versions of CockroachDB prior to v21.1 used the syntax `BACKUP ... TO` to backup directly to a specific operator-chosen destination, rather than picking a date-based path. The `BACKUP ... TO` syntax will be **deprecated** in future releases. For more information on this soon-to-be deprecated syntax, [see the docs for v20.2](../v20.2/backup.html) or earlier.
+{% include_cached new-in.html version="v21.1" %} The syntax `BACKUP ... INTO` adds a backup to a collection within the backup destination. The path to the backup is created using a date-based naming scheme. Versions of CockroachDB prior to v21.1 used the syntax `BACKUP ... TO` to backup directly to a specific operator-chosen destination, rather than picking a date-based path. The `BACKUP ... TO` syntax will be **deprecated** in future releases. For more information on this soon-to-be deprecated syntax, see the docs for v20.2 or earlier.
 {{site.data.alerts.end}}
 
 ### Backup a cluster
diff --git a/src/current/v21.1/kubernetes-performance.md b/src/current/v21.1/kubernetes-performance.md
index a4e08f6ae46..d9f8e88cda2 100644
--- a/src/current/v21.1/kubernetes-performance.md
+++ b/src/current/v21.1/kubernetes-performance.md
@@ -438,9 +438,9 @@ To set up a CockroachDB `DaemonSet`:
     $ kubectl create -f cockroachdb-daemonset-secure.yaml
     ~~~
 
-5. [Manually check and approve each node's certificates](../v20.2/orchestrate-cockroachdb-with-kubernetes.html#step-2-start-cockroachdb), as described in the tutorial on using the `StatefulSet` feature.
+5. Manually check and approve each node's certificates, as described in the tutorial on using the `StatefulSet` feature.
 
-6. [Use the `cluster-init-secure.yaml` file to initialize the cluster](../v20.2/orchestrate-cockroachdb-with-kubernetes.html#step-2-start-cockroachdb), as described in the tutorial on using the `StatefulSet` feature.
+6. Use the `cluster-init-secure.yaml` file to initialize the cluster, as described in the tutorial on using the `StatefulSet` feature.
 
     For the initialization step to work, you will need to change the address on the `--host=cockroachdb-0.cockroach` line from `cockroachdb-0.cockroach` to the address of one of your nodes.
 
diff --git a/src/current/v21.1/migrate-to-multiregion-sql.md b/src/current/v21.1/migrate-to-multiregion-sql.md
index 99a01f751aa..0ed551a3fde 100644
--- a/src/current/v21.1/migrate-to-multiregion-sql.md
+++ b/src/current/v21.1/migrate-to-multiregion-sql.md
@@ -58,7 +58,7 @@ As part of this migration, data may move temporarily out of the geography where
 
 ### Step 1. Remove the old replication zone configurations
 
-Depending on which [legacy multi-region topology pattern](../v20.2/topology-patterns.html#multi-region-patterns) you are migrating from, the procedure will vary. For instructions showing how to remove the existing zone configuration for each pattern, see below.
+Depending on which legacy multi-region topology pattern you were using, the procedure will vary. For instructions showing how to remove the existing zone configuration for each pattern, see below.
 
 - [Duplicate indexes](#duplicate-indexes)
 - [Geo-partitioned leaseholders](#geo-partitioned-leaseholders)
diff --git a/src/current/v21.1/operate-cockroachdb-kubernetes.md b/src/current/v21.1/operate-cockroachdb-kubernetes.md
index d09161c4fbf..70cd213cfe1 100644
--- a/src/current/v21.1/operate-cockroachdb-kubernetes.md
+++ b/src/current/v21.1/operate-cockroachdb-kubernetes.md
@@ -1163,7 +1163,7 @@ The upgrade process on Kubernetes is a [staged update](https://kubernetes.io/doc
 
     Therefore, in order to upgrade to v21.1, you must be on a production release of v20.2.
 
-    1. If you are upgrading to v21.1 from a production release earlier than v20.2, or from a testing release (alpha/beta), first [upgrade to a production release of v20.2](../v20.2/orchestrate-cockroachdb-with-kubernetes.html#upgrade-the-cluster). Be sure to complete all the steps.
+    1. If you are upgrading to v21.1 from a production release earlier than v20.2, or from a testing release (alpha/beta), first upgrade to a production release of v20.2. Be sure to complete all the steps.
 
     1. Then return to this page and perform a second upgrade to v21.1.
 
diff --git a/src/current/v21.1/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md b/src/current/v21.1/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md
index db1ea530163..952956b01f1 100644
--- a/src/current/v21.1/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md
+++ b/src/current/v21.1/orchestrate-cockroachdb-with-kubernetes-multi-cluster.md
@@ -1050,7 +1050,7 @@ The upgrade process on Kubernetes is a [staged update](https://kubernetes.io/doc
 
     Therefore, in order to upgrade to v21.1, you must be on a production release of v20.2.
 
-    1. If you are upgrading to v21.1 from a production release earlier than v20.2, or from a testing release (alpha/beta), first [upgrade to a production release of v20.2](../v20.2/orchestrate-cockroachdb-with-kubernetes-multi-cluster.html#upgrade-the-cluster). Be sure to complete all the steps.
+    1. If you are upgrading to v21.1 from a production release earlier than v20.2, or from a testing release (alpha/beta), first upgrade to a production release of v20.2. Be sure to complete all the steps.
 
     1. Then return to this page and perform a second upgrade to v21.1.
 
diff --git a/src/current/v21.1/restore.md b/src/current/v21.1/restore.md
index f7b49996964..bf30618df0d 100644
--- a/src/current/v21.1/restore.md
+++ b/src/current/v21.1/restore.md
@@ -15,7 +15,7 @@ You can restore:
 - [Tables](#tables)
 
 {{site.data.alerts.callout_info}}
-The [`BACKUP ... TO`](../v20.2/backup.html) and [`RESTORE ... FROM`](../v20.2/restore.html) syntax is **deprecated** as of v22.1 and will be removed in a future release.
+The `BACKUP ... TO` and `RESTORE ... FROM` syntax is **deprecated** as of v22.1 and will be removed in a future release.
 
 We recommend using the `BACKUP ... INTO {collection}` syntax, which creates or adds to a [backup collection](take-full-and-incremental-backups.html#backup-collections) in your storage location. For restoring backups, we recommend using `RESTORE FROM {backup} IN {collection}` with `{backup}` being [`LATEST`](#restore-the-most-recent-backup) or a specific [subdirectory](#subdir-param).
 
diff --git a/src/current/v21.1/upgrade-cockroach-version.md b/src/current/v21.1/upgrade-cockroach-version.md
index 09e8be78415..9bbe34c4984 100644
--- a/src/current/v21.1/upgrade-cockroach-version.md
+++ b/src/current/v21.1/upgrade-cockroach-version.md
@@ -109,7 +109,7 @@ Two changes that are particularly important to note:
     - If your cluster currently uses RocksDB as the storage engine, before you upgrade to v21.1, restart each of your nodes, removing `--storage-engine=rocksdb` from the `cockroach start` command. You can follow the same rolling process described in [step 4](#step-4-perform-the-rolling-upgrade) below, but do not change the binary; just remove the `--storage-engine=rocksdb` flag and restart.
 
 - [Interleaving data](interleave-in-parent.html) was deprecated in v20.2, disabled by default in v21.1, and removed from CockroachDB in v21.2. For migration steps, see the [interleave deprecation](interleave-in-parent.html#deprecation) notice.
-    - If your cluster includes interleaved data and you perform backups, first make sure you are running [v20.2.10+](../v20.2/upgrade-cockroach-version.html); then update your `BACKUP` commands to use the [`INCLUDE_DEPRECATED_INTERLEAVES` option](backup.html#include-deprecated-interleaves); and only then return to this page and upgrade to v21.1. Note that the `INCLUDE_DEPRECATED_INTERLEAVES` option is a no-op in v20.2.10, but this sequence is the only way to prevent backups including interleaved data from failing on v21.1.
+    - If your cluster includes interleaved data and you perform backups, first make sure you are running v20.2.10+; then update your `BACKUP` commands to use the [`INCLUDE_DEPRECATED_INTERLEAVES` option](backup.html#include-deprecated-interleaves); and only then return to this page and upgrade to v21.1. Note that the `INCLUDE_DEPRECATED_INTERLEAVES` option is a no-op in v20.2.10, but this sequence is the only way to prevent backups including interleaved data from failing on v21.1.
 
 ## Step 3. Decide how the upgrade will be finalized
 
@@ -119,7 +119,7 @@ This step is relevant only when upgrading from v20.2.x to v21.1. For upgrades wi
 
 By default, after all nodes are running the new version, the upgrade process will be **auto-finalized**. This will enable certain [features and performance improvements introduced in v21.1](#features-that-require-upgrade-finalization). However, it will no longer be possible to perform a downgrade to v20.2. In the event of a catastrophic failure or corruption, the only option will be to start a new cluster using the old binary and then restore from one of the backups created prior to performing the upgrade. For this reason, **we recommend disabling auto-finalization** so you can monitor the stability and performance of the upgraded cluster before finalizing the upgrade, but note that you will need to follow all of the subsequent directions, including the manual finalization in [step 5](#step-5-finish-the-upgrade):
 
-1. [Upgrade to v20.2](../v20.2/upgrade-cockroach-version.html), if you haven't already.
+1. Upgrade to v20.2, if you haven't already.
 
 1. Start the [`cockroach sql`](cockroach-sql.html) shell against any node in the cluster.
 
diff --git a/src/current/v21.2/backup.md b/src/current/v21.2/backup.md
index 9baf3ecdcc2..06ef65393ef 100644
--- a/src/current/v21.2/backup.md
+++ b/src/current/v21.2/backup.md
@@ -25,7 +25,7 @@ You can also backup:
 Because CockroachDB is designed with high fault tolerance, these backups are designed primarily for disaster recovery (i.e., if your cluster loses a majority of its nodes) through [`RESTORE`](restore.html). Isolated issues (such as small-scale node outages) do not require any intervention.
 
 {{site.data.alerts.callout_info}}
-The [`BACKUP ... TO`](../v20.2/backup.html) and [`RESTORE ... FROM`](../v20.2/restore.html) syntax is **deprecated** as of v22.1 and will be removed in a future release.
+The `BACKUP ... TO` and `RESTORE ... FROM` syntax is **deprecated** as of v22.1 and will be removed in a future release.
 
 We recommend using the `BACKUP ... INTO {collectionURI}` syntax, which creates or adds to a [backup collection](take-full-and-incremental-backups.html#backup-collections) in your storage location. For restoring backups, we recommend using `RESTORE FROM {backup} IN {collectionURI}` with `{backup}` being [`LATEST`](restore.html#restore-the-most-recent-backup) or a specific [subdirectory](restore.html#subdir-param).
 
@@ -156,7 +156,7 @@ Per our guidance in the [Performance](#performance) section, we recommend starti
 {% include {{ page.version.version }}/backups/bulk-auth-options.md %}
 
 {{site.data.alerts.callout_info}}
-The [`BACKUP ... TO`](../v20.2/backup.html) and [`RESTORE ... FROM`](../v20.2/restore.html) syntax is **deprecated** as of v22.1 and will be removed in a future release.
+The `BACKUP ... TO` and `RESTORE ... FROM` syntax is **deprecated** as of v22.1 and will be removed in a future release.
 
 We recommend using the `BACKUP ... INTO {collectionURI}` syntax, which creates or adds to a [backup collection](take-full-and-incremental-backups.html#backup-collections) in your storage location. For restoring backups, we recommend using `RESTORE FROM {backup} IN {collectionURI}` with `{backup}` being [`LATEST`](restore.html#restore-the-most-recent-backup) or a specific [subdirectory](restore.html#subdir-param).
 
diff --git a/src/current/v21.2/migrate-to-multiregion-sql.md b/src/current/v21.2/migrate-to-multiregion-sql.md
index b68d0a37e6d..976f297a10c 100644
--- a/src/current/v21.2/migrate-to-multiregion-sql.md
+++ b/src/current/v21.2/migrate-to-multiregion-sql.md
@@ -61,7 +61,7 @@ As part of this migration, data may move temporarily out of the geography where
 
 ### Step 1. Remove the old replication zone configurations
 
-Depending on which [legacy multi-region topology pattern](../v20.2/topology-patterns.html#multi-region-patterns) you are migrating from, the procedure will vary. For instructions showing how to remove the existing zone configuration for each pattern, see below.
+Depending on which legacy multi-region topology pattern you were using, the procedure will vary. For instructions showing how to remove the existing zone configuration for each pattern, see below.
 
 - [Duplicate indexes](#duplicate-indexes)
 - [Geo-partitioned leaseholders](#geo-partitioned-leaseholders)
diff --git a/src/current/v21.2/restore.md b/src/current/v21.2/restore.md
index 12fc8d6716e..72d27e679a6 100644
--- a/src/current/v21.2/restore.md
+++ b/src/current/v21.2/restore.md
@@ -18,7 +18,7 @@ You can restore:
 For details on restoring across versions of CockroachDB, see [Restoring Backups Across Versions](restoring-backups-across-versions.html).
 
 {{site.data.alerts.callout_info}}
-The [`BACKUP ... TO`](../v20.2/backup.html) and [`RESTORE ... FROM`](../v20.2/restore.html) syntax is **deprecated** as of v22.1 and will be removed in a future release.
+The `BACKUP ... TO` and `RESTORE ... FROM` syntax is **deprecated** as of v22.1 and will be removed in a future release.
 
 We recommend using the `BACKUP ... INTO {collection}` syntax, which creates or adds to a [backup collection](take-full-and-incremental-backups.html#backup-collections) in your storage location. For restoring backups, we recommend using `RESTORE FROM {backup} IN {collection}` with `{backup}` being [`LATEST`](#restore-the-most-recent-backup) or a specific [subdirectory](#subdir-param).
 
diff --git a/src/current/v21.2/take-full-and-incremental-backups.md b/src/current/v21.2/take-full-and-incremental-backups.md
index 45849cfbd4b..49d18ad0725 100644
--- a/src/current/v21.2/take-full-and-incremental-backups.md
+++ b/src/current/v21.2/take-full-and-incremental-backups.md
@@ -15,7 +15,7 @@ There are two main types of backups:
 You can use the [`BACKUP`](backup.html) statement to efficiently back up your cluster's schemas and data to popular cloud services such as AWS S3, Google Cloud Storage, or NFS, and the [`RESTORE`](restore.html) statement to efficiently restore schema and data as necessary. For more information, see [Use Cloud Storage for Bulk Operations](use-cloud-storage-for-bulk-operations.html).
 
 {{site.data.alerts.callout_info}}
-The [`BACKUP ... TO`](../v20.2/backup.html) and [`RESTORE ... FROM`](../v20.2/restore.html) syntax is **deprecated** as of v22.1 and will be removed in a future release.
+The `BACKUP ... TO` and `RESTORE ... FROM` syntax is **deprecated** as of v22.1 and will be removed in a future release.
 
 We recommend using the `BACKUP ... INTO {collection}` syntax, which creates or adds to a [backup collection](take-full-and-incremental-backups.html#backup-collections) in your storage location. For restoring backups, we recommend using `RESTORE FROM {backup} IN {collection}` with `{backup}` being [`LATEST`](restore.html#restore-the-most-recent-backup) or a specific [subdirectory](restore.html#subdir-param).
 
diff --git a/src/current/v22.1/migrate-to-multiregion-sql.md b/src/current/v22.1/migrate-to-multiregion-sql.md
index f7b5ea5fe06..02be153f9f5 100644
--- a/src/current/v22.1/migrate-to-multiregion-sql.md
+++ b/src/current/v22.1/migrate-to-multiregion-sql.md
@@ -61,7 +61,7 @@ As part of this migration, data may move temporarily out of the geography where
 
 ### Step 1. Remove the old replication zone configurations
 
-Depending on which [legacy multi-region topology pattern](../v20.2/topology-patterns.html#multi-region-patterns) you are migrating from, the procedure will vary. For instructions showing how to remove the existing zone configuration for each pattern, see below.
+Depending on which legacy multi-region topology pattern you were using, the procedure will vary. For instructions showing how to remove the existing zone configuration for each pattern, see below.
 
 - [Duplicate indexes](#duplicate-indexes)
 - [Geo-partitioned leaseholders](#geo-partitioned-leaseholders)