From dec2f5ce48d2e7124201a187b5f3319e7b93f6fa Mon Sep 17 00:00:00 2001 From: atovpeko Date: Tue, 21 Jan 2025 11:12:48 +0200 Subject: [PATCH 1/2] update --- use-timescale/schema-management/about-indexing.md | 8 +++++--- use-timescale/schema-management/indexing.md | 3 +-- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/use-timescale/schema-management/about-indexing.md b/use-timescale/schema-management/about-indexing.md index 92aa6e817a..ed213c37ae 100644 --- a/use-timescale/schema-management/about-indexing.md +++ b/use-timescale/schema-management/about-indexing.md @@ -11,8 +11,10 @@ Because looking up data can take a long time, especially if you have a lot of data in your hypertable, you can use an index to speed up read operations from non-compressed chunks (which use their [own columnar indexes][about-compression]). -You can create an index on any combination of columns, as long as you include -the `time` column, for time-series data. Which column you choose to create your +You can create an index on any combination of columns. To define an index as a `UNIQUE` or `PRIMARY KEY` index, it must include +the time column and the partitioning column, if you are using one. + +Which column you choose to create your index on depends on what kind of data you have stored. When you create a hypertable, set the datatype for the `time` column as `timestamptz` and not `timestamp`. @@ -97,7 +99,7 @@ different queries. Here are some examples: SELECT * FROM devices WHERE store_id = x ``` -This queries the portion of the list with a specific store_id. The index is +This queries the portion of the list with a specific `store_id`. The index is effective for this query, but could be a bit bloated; an index on just `store_id` would probably be more efficient. diff --git a/use-timescale/schema-management/indexing.md b/use-timescale/schema-management/indexing.md index a767647d06..0b3497680c 100644 --- a/use-timescale/schema-management/indexing.md +++ b/use-timescale/schema-management/indexing.md @@ -8,8 +8,7 @@ keywords: [hypertables, indexes] # Indexing data You can use an index on your database to speed up read operations. You can -create an index on any combination of columns, as long as you include the `time` -column, for time-series data. Timescale supports all table objects supported +create an index on any combination of columns. Timescale supports all table objects supported within PostgreSQL, including data types, indexes, and triggers. You can create an index using the `CREATE INDEX` command. For example, to create From acb76f00004f991830387621f04397c978f20baf Mon Sep 17 00:00:00 2001 From: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> Date: Thu, 30 Jan 2025 12:45:00 +0200 Subject: [PATCH 2/2] Update use-timescale/schema-management/about-indexing.md Co-authored-by: Mats Kindahl Signed-off-by: Anastasiia Tovpeko <114177030+atovpeko@users.noreply.github.com> --- use-timescale/schema-management/about-indexing.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/use-timescale/schema-management/about-indexing.md b/use-timescale/schema-management/about-indexing.md index ed213c37ae..c2b9eccb27 100644 --- a/use-timescale/schema-management/about-indexing.md +++ b/use-timescale/schema-management/about-indexing.md @@ -11,8 +11,7 @@ Because looking up data can take a long time, especially if you have a lot of data in your hypertable, you can use an index to speed up read operations from non-compressed chunks (which use their [own columnar indexes][about-compression]). -You can create an index on any combination of columns. To define an index as a `UNIQUE` or `PRIMARY KEY` index, it must include -the time column and the partitioning column, if you are using one. +You can create an index on any combination of columns. To define an index as a `UNIQUE` or `PRIMARY KEY` index, it must include the partitioning column (this is usually the time column). Which column you choose to create your index on depends on what kind of data you have stored.