DOC-2711: Implicitly partitioned tables can use HSIs (cockroachdb#14457)

v22.1/hash-sharded-indexes.md

@@ -42,7 +42,7 @@ We recommend doing thorough performance testing of your workload with different
 You can create hash-sharded indexes with implicit partitioning under the following scenarios:
 
 - The table is partitioned implicitly with [`REGIONAL BY ROW`](multiregion-overview.html#regional-by-row-tables), and the `crdb_region` column is not part of the columns in the hash-sharded index.
-- The table is partitioned implicitly with `PARTITION ALL BY`, and the partition columns are not part of the columns in the hash-sharded index.
+- The table is partitioned implicitly with `PARTITION ALL BY`, and the partition columns are not part of the columns in the hash-sharded index. Note that `PARTITION ALL BY` is in preview.
 
 However, if an index of a table, whether it be a primary key or secondary index, is explicitly partitioned with `PARTITION BY`, then that index cannot be hash-sharded. Partitioning columns cannot be placed explicitly as key columns of a hash-sharded index as well, including `REGIONAL BY ROW` table's `crdb_region` column.
 

v22.1/multiregion-overview.md

@@ -185,6 +185,8 @@ This behavior also applies to [GIN indexes](inverted-indexes.html).
 
 For an example that uses unique indexes but applies to all indexes on `REGIONAL BY ROW` tables, see [Add a unique index to a `REGIONAL BY ROW` table](add-constraint.html#add-a-unique-index-to-a-regional-by-row-table).
 
+Regional by row tables can take advantage of [hash-sharded indexes](hash-sharded-indexes.html) provided the `crdb_region` column is not part of the columns in the hash-sharded index.
+
 ## Schema changes in multi-region clusters
 
 {% include {{ page.version.version }}/performance/lease-preference-system-database.md %}