chore: update hypertable landing page

_partials/_timescaledb-gucs.md

@@ -80,4 +80,4 @@
 | `skip_scan_run_cost_multiplier` | `REAL` | `1.0` | Default is 1.0 i.e. regularly estimated SkipScan run cost, 0.0 will make SkipScan to have run cost = 0<br />min: `0.0`, max: `1.0` |
 | `telemetry_level` | `ENUM` | `TELEMETRY_DEFAULT` | Level used to determine which telemetry to send |
 
-Version: [2.21.0](https://github.com/timescale/timescaledb/releases/tag/2.21.0)
+Version: [2.21.0](https://github.com/timescale/timescaledb/releases/tag/2.21.0)

migrate/pg-dump-and-restore.md

@@ -138,4 +138,3 @@ And that is it, you have migrated your data from a $MST_LONG instance to a $SERV
 [data-compression]: /use-timescale/:currentVersion:/hypercore/
 [data-retention]: /use-timescale/:currentVersion:/data-retention/about-data-retention/
 [live migration]: /migrate/:currentVersion:/live-migration
-[space-partitioning]: /use-timescale/:currentVersion:/hypertables/about-hypertables#space-partitioning

self-hosted/distributed-hypertables/about-distributed-hypertables.md

@@ -271,5 +271,4 @@ of $TIMESCALE_DB might remove some of these limitations.
 [multi-node-ha]: /self-hosted/:currentVersion:/multinode-timescaledb/multinode-ha/
 [multi-node]: /self-hosted/:currentVersion:/multinode-timescaledb/
 [random-func]: <https://www.postgresql.org/docs/current/functions-math.html#FUNCTIONS-MATH-RANDOM-TABLE>
-[space-partitioning]: /use-timescale/:currentVersion:/hypertables/about-hypertables#space-partitioning
 [volatility]: <https://www.postgresql.org/docs/current/xfunc-volatility.html>

use-timescale/hypertables/index.md

@@ -15,74 +15,100 @@ import ChunkInterval from "versionContent/_partials/_chunk-interval.mdx";
 ![Hypertable structure](https://assets.timescale.com/docs/images/hypertable-structure.png)
 
 
-## Hypertable partitioning
+## Partition by time
 
 Each $HYPERTABLE is partitioned into child $HYPERTABLEs called chunks. Each chunk is assigned
-a range of time, and only contains data from that range. If the $HYPERTABLE is
-also partitioned by space, each chunk is also assigned a subset of the space
-values.
+a range of time, and only contains data from that range.
 
-When $TIMESCALE_DB creates a chunk, the creation time is stored in the catalog metadata. This chunk creation 
-time is not the same as the partition ranges for the data contained in the chunk. Certain
-functionality can use this chunk creation time metadata in cases where it makes sense.
 
-<Highlight type="note">
+### Time partitioning
 
-Inheritance is not supported for $HYPERTABLEs and may lead to unexpected behavior.
-
-</Highlight>
-
-Each $HYPERTABLE chunk holds data for a specific time range only. When you
-insert data from a time range that doesn't yet have a chunk, $TIMESCALE_DB
-automatically creates a chunk to store it.
-
-By default, each chunk covers 7 days. You can change this to better suit your
-needs. For example, if you set `chunk_interval` to 1 day, each chunk stores
-data from the same day. Data from different days is stored in different chunks.
+By default, each $HYPERTABLE chunk holds data for 7 days. You can change this to better suit your
+needs. For example, if you set `chunk_interval` to 1 day, each chunk stores data for a single day.
 
 The following figure shows the difference in structure between a relational table and a hypertable:
 
 ![Compare a relational table to a hypertable](https://assets.timescale.com/docs/images/getting-started/hypertables-chunks.webp)
 
-$TIMESCALE_DB divides time into potential chunk ranges, based on the
-`chunk_interval`. If data exists for a potential chunk range, that chunk is
-created.
+$TIMESCALE_DB divides time into potential chunk ranges, based on the `chunk_interval`. Each $HYPERTABLE chunk holds 
+data for a specific time range only. When you insert data from a time range that doesn't yet have a chunk, $TIMESCALE_DB
+automatically creates a chunk to store it.
 
 In practice, this means that the start time of your earliest chunk does not
 necessarily equal the earliest timestamp in your $HYPERTABLE. Instead, there
 might be a time gap between the start time and the earliest timestamp. This
 doesn't affect your usual interactions with your $HYPERTABLE, but might affect
 the number of chunks you see when inspecting it.
 
+## Partition by dimension
+
+Partitioning on time is the most common use case for $HYPERTABLE, but it may not be enough for your needs. For example,
+you may need to scan for the latest readings that match a certain condition without locking a critical $HYPERTABLE.
+Best practice to optimize ingest and query performance is to add a partitioning dimension on a non-time column such as
+location or device UUID, and specify a number of partitions.
+
+You add a partitioning dimension at the same time as you create the hypertable, when the table is empty. The good news 
+is that although you select the number of partitions at creation time, as your data grows you can change the number of 
+partitions later and improve query performance. Changing the number of partitions only affects chunks created after the 
+change, not existing chunks. To set the number of partitions for a partitioning dimension, call `set_number_partitions`. 
+For example:
+
+<Procedure>
+
+1. **Create the $HYPERTABLE with 1 day interval chunk interval**
+
+   ```sql
+   CREATE TABLE conditions(
+      "time"      timestamptz not null,
+      device_id   integer,
+      temperature float
+   )
+   WITH(
+      timescaledb.hypertable,
+      timescaledb.partition_column='time',
+      timescaledb.chunk_interval='1 day'
+   );
+   ```
+
+1. **Add a hash partition on a non-time column**
+
+   ```sql
+   select * from add_dimension('conditions', by_hash('device_id', 3));
+   ``` 
+   Now use your $HYPERTABLE as usual, but you can also ingest and query efficiently by the `device_id` column.
+
+1. **Change the number of partitions as you data grows**
+
+   ```sql
+   select set_number_partitions('conditions', 5, 'device_id');
+   ```
+
+</Procedure>
+
 ## Best practices for scaling and partitioning
 
 Best practices for maintaining a high performance when scaling include:
 
-- Limit the number of $HYPERTABLEs in your $SERVICE_SHORT; having tens of thousands of $HYPERTABLEs is not recommended. 
-- Choose a strategic chunk size. 
+- Limit the number of $HYPERTABLEs in your $SERVICE_SHORT; having tens of thousands of $HYPERTABLEs is not recommended.
+- Choose a strategic chunk size.
 
 Chunk size affects insert and query performance. You want a chunk small enough
 to fit into memory so you can insert and query recent data without
 reading from disk. However, having too many small and sparsely filled chunks can
-affect query planning time and compression. The more chunks in the system, the slower that process becomes, even more so 
-when all those chunks are part of a single hypertable. 
+affect query planning time and compression. The more chunks in the system, the slower that process becomes, even more so
+when all those chunks are part of a single hypertable.
 
 <ChunkInterval />
 
 For a detailed analysis of how to optimize your chunk sizes, see the
 [blog post on chunk time intervals][blog-chunk-time]. To learn how
-to view and set your chunk time intervals, see how to 
+to view and set your chunk time intervals, see how to
 [Optimize $HYPERTABLE chunk intervals][change-chunk-intervals].
 
 ## $HYPERTABLE_CAP indexes
 
-By default, indexes are automatically created when you create a $HYPERTABLE.
-
-The default indexes are:
-
-*   On all $HYPERTABLEs, an index on time, descending
-*   On $HYPERTABLEs with space partitions, an index on the space parameter and
-    time
+By default, indexes are automatically created when you create a $HYPERTABLE. The default index is on time, descending.
+You can prevent index creation by setting the `create_default_indexes` option to `false`.
 
 $HYPERTABLE_CAPs have some restrictions on unique constraints and indexes. If you
 want a unique index on a $HYPERTABLE, it must include all the partitioning
@@ -107,5 +133,4 @@ This section shows you:
 [hypertables-and-unique-indexes]: /use-timescale/:currentVersion:/hypertables/hypertables-and-unique-indexes/
 [pg-analyze]: https://www.postgresql.org/docs/current/sql-analyze.html
 [chunks_detailed_size]: /api/:currentVersion:/hypertable/chunks_detailed_size
-
 [troubleshooting]: /use-timescale/:currentVersion:/hypertables/troubleshooting/