fix: broken links. (timescale#3123)

* fix: broken links.

* fix: broken links.

Author: billy-the-fish

_partials/_migrate_dual_write_step1.md

@@ -9,4 +9,4 @@ ensure that enough disk is pre-provisioned on your Timescale instance.
 
 <OpenSupportRequest />
 
-[create-service]: /use-timescale/:currentVersion:/services/create-a-service/
+[create-service]: /getting-started/:currentVersion:/services/

about/release-notes/changes-in-timescaledb-2.md

@@ -422,7 +422,7 @@ statistics related to all jobs.
 
 #### Removed
 
-*   [`timescaledb_information.continuous_aggregate_stats`](https://legacy-docs.timescale.com/v1.7/api#timescaledb_information-continuous_aggregate_stats): Removed in favor of the `job_stats` view mentioned above.
+*   `timescaledb_information.continuous_aggregate_stats`: Removed in favor of the `job_stats` view mentioned above.
 
 ### Updating existing continuous aggregates
 
@@ -465,9 +465,9 @@ policies are now available in the main jobs view.
 
 #### Removed
 
-*   [`add_drop_chunks_policy`](https://legacy-docs.timescale.com/v1.7/api#add_drop_chunks_policy): removed in favor of the
+*   `add_drop_chunks_policy`: removed in favor of the
 explicit functions above.
-*   [`timescaledb_information.drop_chunks_policies`](https://legacy-docs.timescale.com/v1.7/api#timescaledb_information-drop_chunks_policies):
+*   `timescaledb_information.drop_chunks_policies`:
  view has been removed in favor of the more general jobs view.
 
 ### Compression
@@ -487,11 +487,11 @@ compression policies are now available in the main jobs view.
 
 #### Removed
 
-*   [`add_compress_chunk_policy`](https://legacy-docs.timescale.com/v1.7/api#add_compress_chunks_policy): Removed in favor of the
+*   `add_compress_chunk_policy`: Removed in favor of the
 explicit functions above.
-*   [`timescaledb_information.compressed_hypertable_stats`](https://legacy-docs.timescale.com/v1.7/api#timescaledb_information-compressed_hypertable_stats):
+*   `timescaledb_information.compressed_hypertable_stats`:
 Removed in favor of the new `hypertable_compression_stats(hypertable)` function linked above
-*   [`timescaledb_information.compressed_chunk_stats`](https://legacy-docs.timescale.com/v1.7/api#timescaledb_information-compressed_chunk_stats):
+*   `timescaledb_information.compressed_chunk_stats`:
 Removed in favor of the new `chunk_compression_stats(hypertable)` function linked above.
 
 ## Managing policies and other jobs
@@ -517,10 +517,10 @@ features has been removed. All features are available either under the community
 open-source Apache-2 License. [This blog post](https://blog.timescale.com/blog/building-open-source-business-in-cloud-era-v2/)
 explains the changes. The following changes were made to license API:
 
-*   [`timescaledb_information.license`](https://legacy-docs.timescale.com/v1.7/api#timescaledb_information-license):  This view
+*   `timescaledb_information.license`:  This view
 has been removed, as it primarily provided information on the enterprise license key's expiration date, which is no
 longer applicable. The current license used by the extension can instead be viewed in the GUC below.
-*   `timescaledb.license`: This GUC value (which replaces the former [`timescaledb.license_key`](https://legacy-docs.timescale.com/v1.7/api#timescaledb_license-key) GUC)
+*   `timescaledb.license`: This GUC value (which replaces the former `timescaledb.license_key` GUC)
 can take the value `timescale` or `apache`. It can be set only at startup (in the postgresql.conf configuration file
 or on the server command line), and allows limiting access to certain features
 by license. For example, setting the

about/release-notes/index.md

@@ -74,10 +74,10 @@ New compression settings take effect on any new chunks that are compressed after
 Following the deprecation announcement for Multi-node in TimescaleDB 2.13,
 Multi-node is no longer supported starting with TimescaleDB 2.14.
 
-TimescaleDB 2.13 is the last version that includes multi-node support. Learn more about it [here](docs/MultiNodeDeprecation.md).
+TimescaleDB 2.13 is the last version that includes multi-node support. Learn more about it [here][multi-node-deprecation].
 
 If you want to migrate from multi-node TimescaleDB to single-node TimescaleDB, read the
-[migration documentation](https://docs.timescale.com/migrate/latest/multi-node-to-timescale-service/).
+[migration documentation][multi-node-to-timescale-service].
 
 #### Deprecation notice: recompress_chunk procedure
 TimescaleDB 2.14 is the last version that will include the recompress_chunk procedure. Its
@@ -174,10 +174,10 @@ available opportunity.
 #### Deprecation notice: Multi-node support
 TimescaleDB 2.13 is the last version that will include multi-node support. Multi-node
 support in 2.13 is available for PostgreSQL 13, 14 and 15. Learn more about it
-[here](https://github.com/timescale/timescaledb/blob/main/docs/MultiNodeDeprecation.md).
+[here][multi-node-deprecation].
 
 If you want to migrate from multi-node TimescaleDB to single-node TimescaleDB read the
-[migration documentation](https://docs.timescale.com/migrate/latest/multi-node-to-timescale-service/).
+[migration documentation][multi-node-to-timescale-service].
 
 #### PostgreSQL 13 deprecation announcement
 We will continue supporting PostgreSQL 13 until April 2024. Sooner to that time, we will announce the specific version of TimescaleDB in which PostgreSQL 13 support will not be included going forward.
@@ -692,3 +692,5 @@ For release notes for older TimescaleDB versions, see the
 [pg-upgrade]: /self-hosted/:currentVersion:/upgrades/upgrade-pg/
 [migrate-caggs]: /use-timescale/:currentVersion:/continuous-aggregates/migrate/
 [join-caggs]: /use-timescale/:currentVersion:/continuous-aggregates/create-a-continuous-aggregate/#create-a-continuous-aggregate-with-a-join
+[multi-node-to-timescale-service]:/migrate/:currentVersion:/playbooks/multi-node-to-timescale-service/
+[multi-node-deprecation]: https://github.com/timescale/timescaledb/blob/main/docs/MultiNodeDeprecation.md

ai/index.md

@@ -56,7 +56,7 @@ Under the hood, embeddings are represented as a vector (a list of numbers) that
 
 Timescale Vector works with the most popular embedding models that have output vectors of 2,000 dimensions or less. Here are some popular choices for text embeddings for use with Timescale Vector:
 
-- [OpenAI embedding models](https://platform.openai.com/docs/guides/embeddings): text-embedding-ada-002 is OpenAI's recommended embedding generation model.
+- [OpenAI embedding models](https://platform.openai.com/docs/guides/embeddings/): text-embedding-ada-002 is OpenAI's recommended embedding generation model.
 - [Sentence transformers](https://huggingface.co/sentence-transformers): Several popular open source models for embedding generation from text.
 - [Cohere representation models](https://docs.cohere.com/docs/models#representation): Cohere offers many models that can be used to generate embeddings from text in English or multiple languages.
 
@@ -69,4 +69,4 @@ And here are some popular choices for image embeddings:
 - [VGG](https://pytorch.org/vision/stable/models/vgg.html)
 - [Vision Transformer (ViT)](https://github.com/lukemelas/PyTorch-Pretrained-ViT)
 
-[vector-search-indexing]: /ai/:currentVersion:/concepts/#vector-search-indexing-approximate-nearest-neighbor-search
+[vector-search-indexing]: /ai/:currentVersion:/key-vector-database-concepts-for-understanding-pgvector/#vector-search-indexing-approximate-nearest-neighbor-search

ai/key-vector-database-concepts-for-understanding-pgvector.md

@@ -26,7 +26,7 @@ CREATE TABLE IF NOT EXISTS document_embedding  (
 
 This table contains a primary key, a foreign key to the document table, some metadata, the text being embedded (in the `contents` column), and the embedded vector.
 
-This may seem like a bit of a weird design: why aren't the embeddings simply a separate column in the document table? The answer has to do with context length limits of embedding models and of LLMs. When embedding data, there is a limit to the length of content you can embed (for example, OpenAI's ada-002 has a limit of [8191 tokens]((https://platform.openai.com/docs/guides/embeddings/second-generation-models))), and so, if you are embedding a long piece of text, you have to break it up into smaller chunks and embed each chunk individually. Therefore, when thinking about this at the database layer, there is usually a one-to-many relationship between the thing being embedded and the embeddings which is represented by a foreign key from the embedding to the thing.
+This may seem like a bit of a weird design: why aren't the embeddings simply a separate column in the document table? The answer has to do with context length limits of embedding models and of LLMs. When embedding data, there is a limit to the length of content you can embed (for example, OpenAI's ada-002 has a limit of [8191 tokens](https://platform.openai.com/docs/guides/embeddings/embedding-models) ), and so, if you are embedding a long piece of text, you have to break it up into smaller chunks and embed each chunk individually. Therefore, when thinking about this at the database layer, there is usually a one-to-many relationship between the thing being embedded and the embeddings which is represented by a foreign key from the embedding to the thing.
 
 Of course, if you do not want to store the original data in the database and you are just storing only the embeddings, that's totally fine too. Just omit the foreign key from the table. Another popular alternative is to put the foreign key into the metadata JSONB.
 

ai/sql-interface-for-pgvector-and-timescale-vector.md

@@ -322,5 +322,5 @@ ORDER BY embedding <=> $1
 LIMIT 10
 ```
 
-[distance-functions]: /ai/:currentVersion:/concepts/#vector-distance-types
-[vector-search-indexing]: /ai/:currentVersion:/concepts/#vector-search-indexing-approximate-nearest-neighbor-search
+[distance-functions]: /ai/:currentVersion:/key-vector-database-concepts-for-understanding-pgvector/#vector-distance-types
+[vector-search-indexing]: /ai/:currentVersion:/key-vector-database-concepts-for-understanding-pgvector/#vector-search-indexing-approximate-nearest-neighbor-search

api/add_policies.md

@@ -81,5 +81,5 @@ SELECT timescaledb_experimental.add_policies(
 );
 ```
 <!-- vale Vale.Terms = NO -->
-[add_continuous_aggregate_policy]: /api/:currentVersion/continuous-aggregates/add_continuous_aggregate_policy/
+[add_continuous_aggregate_policy]: /api/:currentVersion:/continuous-aggregates/add_continuous_aggregate_policy/
 <!-- vale Vale.Terms = YES -->

migrate/pg-dump-and-restore/pg-dump-restore-from-postgres.md

@@ -44,7 +44,7 @@ Before you begin, ensure that you have:
 - Checked that the version of PostgreSQL in your target database is greater
   than or equal to that of the source database.
 
-[Created a database service in Timescale]: /use-timescale/:currentVersion:/services/create-a-service/
+[Created a database service in Timescale]: /getting-started/:currentVersion:/services/
 [list of compatible extensions]: /use-timescale/:currentVersion:/extensions/
 
 ## Dump the source database

migrate/pg-dump-and-restore/pg-dump-restore-from-timescaledb.md

@@ -44,7 +44,7 @@ Before you begin, ensure that you have:
   same). For more information, see the [upgrade instructions] for self-hosted
   TimescaleDB.
 
-[Created a database service in Timescale]: /use-timescale/:currentVersion:/services/create-a-service/
+[Created a database service in Timescale]: /getting-started/:currentVersion:/services/
 [list of compatible extensions]: /use-timescale/:currentVersion:/extensions/
 [upgrade instructions]: /self-hosted/:currentVersion:/upgrades/about-upgrades/
 

migrate/playbooks/multi-node-to-timescale-service.md

@@ -47,7 +47,7 @@ Before you begin, ensure that you have:
   same). For more information, see the [upgrade instructions] for self-hosted
   TimescaleDB.
 
-[Created a database service in Timescale]: /use-timescale/:currentVersion:/services/create-a-service/
+[Created a database service in Timescale]: /getting-started/:currentVersion:/services/
 [list of compatible extensions]: /use-timescale/:currentVersion:/extensions/
 [upgrade instructions]: /self-hosted/:currentVersion:/upgrades/about-upgrades/