Merge pull request #3661 from ClickHouse/fix_settings_generation

gingerwizard · web-flow · commit 878067f225bc · 2025-04-13T14:27:43.000+01:00
Fix broken anchors
diff --git a/docs/best-practices/choosing_a_primary_key.md b/docs/best-practices/choosing_a_primary_key.md
@@ -13,7 +13,7 @@ import primary_key from '@site/static/images/bestpractices/primary_key.gif';
 
 > We interchangeably use the term "ordering key" to refer to the "primary key" on this page. Strictly, [these differ in ClickHouse](/engines/table-engines/mergetree-family/mergetree#choosing-a-primary-key-that-differs-from-the-sorting-key), but for the purposes of this document, readers can use them interchangeably, with the ordering key referring to the columns specified in the table `ORDER BY`.
 
-Note that a ClickHouse primary key works [very differently](/migrations/postgresql/designing-schemas#how-are-clickhouse-primary-keys-different) to those familiar with similar terms in OLTP databases such as Postgres.
+Note that a ClickHouse primary key works [very differently](/migrations/postgresql/data-modeling-techniques#primary-ordering-keys-in-clickhouse) to those familiar with similar terms in OLTP databases such as Postgres.
 
 Choosing an effective primary key in ClickHouse is crucial for query performance and storage efficiency. ClickHouse organizes data into parts, each containing its own sparse primary index. This index significantly speeds up queries by reducing the volume of data scanned. Additionally, because the primary key determines the physical order of data on disk, it directly impacts compression efficiency. Optimally ordered data compresses more effectively, which further enhances performance by reducing I/O.
 
diff --git a/docs/data-modeling/projections.md b/docs/data-modeling/projections.md
@@ -94,7 +94,7 @@ We'll also look at how the projection can be used to speed up queries which filt
 on columns which are not in the primary key of a table.
 
 For this example, we'll be using the New York Taxi Data
-dataset available at [sql.clickhouse.com](sql.clickhouse.com) which is ordered 
+dataset available at [sql.clickhouse.com](https://sql.clickhouse.com/) which is ordered 
 by `pickup_datetime`.
 
 Let's write a simple query to find all the trip IDs for which passengers 
diff --git a/docs/integrations/data-ingestion/clickpipes/aws-privatelink.md b/docs/integrations/data-ingestion/clickpipes/aws-privatelink.md
@@ -87,7 +87,7 @@ See AWS guide for [managing permissions](https://docs.aws.amazon.com/vpc/latest/
 
 :::info
 [Cross-region access](https://docs.aws.amazon.com/vpc/latest/privatelink/privatelink-share-your-services.html#endpoint-service-cross-region)
-can be configured for ClickPipes. Add [your ClickPipe region](#supported-aws-regions-aws-privatelink-regions) to the allowed regions in your VPC endpoint service.
+can be configured for ClickPipes. Add [your ClickPipe region](#aws-privatelink-endpoint-types) to the allowed regions in your VPC endpoint service.
 :::
 
 ## Creating a ClickPipe with reverse private endpoint {#creating-clickpipe}
diff --git a/docs/integrations/data-ingestion/clickpipes/postgres/index.md b/docs/integrations/data-ingestion/clickpipes/postgres/index.md
@@ -145,6 +145,6 @@ You can configure the Advanced settings if needed. A brief description of each s
 
 ## What's next? {#whats-next}
 
-Once you've moved data from Postgres to ClickHouse, the next obvious question is how to query and model your data in ClickHouse to make the most of it. Please refer to the [migration guide](/migrations/postgres/overview) to a step by step approaches on how to migrate from PostgreSQL to ClickHouse. Alongside the migration guide, make sure to check the pages about [Deduplication strategies (using CDC)](/integrations/clickpipes/postgres/deduplication) and [Ordering Keys](/integrations/clickpipes/postgres/ordering_keys) to understand how to handle duplicates and customize ordering keys when using CDC. 
+Once you've moved data from Postgres to ClickHouse, the next obvious question is how to query and model your data in ClickHouse to make the most of it. Please refer to the [migration guide](/migrations/postgresql/overview) to a step by step approaches on how to migrate from PostgreSQL to ClickHouse. Alongside the migration guide, make sure to check the pages about [Deduplication strategies (using CDC)](/integrations/clickpipes/postgres/deduplication) and [Ordering Keys](/integrations/clickpipes/postgres/ordering_keys) to understand how to handle duplicates and customize ordering keys when using CDC. 
 
 Finally, please refer to the ["ClickPipes for Postgres FAQ"](/integrations/clickpipes/postgres/faq) page for more information about common issues and how to resolve them.
diff --git a/docs/integrations/data-ingestion/clickpipes/postgres/ordering_keys.md b/docs/integrations/data-ingestion/clickpipes/postgres/ordering_keys.md
@@ -7,7 +7,7 @@ title: 'Ordering keys'
 
 Ordering Keys (a.k.a. sorting keys) define how data is sorted on disk and indexed for a table in ClickHouse. When replicating from Postgres, ClickPipes sets the Postgres primary key of a table as the ordering key for the corresponding table in ClickHouse. In most cases, the Postgres primary key serves as a sufficient ordering key, as ClickHouse is already optimized for fast scans, and custom ordering keys are often not required.
 
-As describe in the [migration guide](/migrations/postgres/data-modeling-techniques), for larger use cases you should include additional columns beyond the Postgres primary key in the ClickHouse ordering key to optimize queries. 
+As describe in the [migration guide](/migrations/postgresql/data-modeling-techniques), for larger use cases you should include additional columns beyond the Postgres primary key in the ClickHouse ordering key to optimize queries. 
 
 By default with CDC, choosing an ordering key different from the Postgres primary key can cause data deduplication issues in ClickHouse. This happens because the ordering key in ClickHouse serves a dual role: it controls data indexing and sorting while acting as the deduplication key. The easiest way to address this issue is by defining refreshable materialized views.
 
diff --git a/docs/migrations/postgres/dataset.md b/docs/migrations/postgres/dataset.md
@@ -119,7 +119,7 @@ DESCRIBE TABLE postgresql('<host>:<port>', 'postgres', 'posts', '<username>', '<
 SETTINGS describe_compact_output = 1
 ```
 
-For an overview of data type mapping between PostgreSQL and ClickHouse, refer to the [appendix documentation](/migrations/postgres/appendix#data-type-mappings).
+For an overview of data type mapping between PostgreSQL and ClickHouse, refer to the [appendix documentation](/migrations/postgresql/appendix#data-type-mappings).
 
 The steps for optimizing the types for this schema are identical to if the data has been loaded from other sources e.g. Parquet on S3. Applying the process described in this [alternate guide using Parquet](/data-modeling/schema-design) results in the following schema:
 
diff --git a/docs/migrations/postgres/index.md b/docs/migrations/postgres/index.md
@@ -9,10 +9,9 @@ description: 'Landing page for the PostgreSQL migrations section'
 | Page                                                                                                                 | Description                                                                                                                                                             |
 |----------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | [Overview](./overview.md)                                                                                        | Introduction page for this section                                                                                                                                      |
-| [Connecting to PostgreSQL](../../integrations/data-ingestion/dbms/postgresql/connecting-to-postgresql.md)            | This page covers the following options for integrating PostgreSQL with ClickHouse: ClickPipes, PeerDB, PostgreSQL table engine, MaterializedPostgreSQL database engine. |
-| [Comparing PostgreSQL and ClickHouse](../../integrations/data-ingestion/dbms/postgresql/postgres-vs-clickhouse.md)   | Explores Postgres vs ClickHouse - Equivalent and different concepts.                                                                                                    |
-| [Loading data from PostgreSQL to ClickHouse](./dataset.md)                                                           | Part 1 of a guide on migrating from PostgreSQL to ClickHouse.                                                                                                           |
-| [Rewrite PostgreSQL Queries](./rewriting-queries.md)        | Part 2 of a guide on migrating from PostgreSQL to ClickHouse.                                                                                                           |
-| [Data modeling techniques](./data-modeling-techniques.md)                                                            | Part 3 of a guide on migrating from PostgreSQL to ClickHouse.                                                                                                           |
-| [Appendix](./appendix.md)            | Additional information about differences between PostgreSQL and ClickHouse                                                                                                              |
+| [Connecting to PostgreSQL](/integrations/postgresql/connecting-to-postgresql)            | This page covers the following options for integrating PostgreSQL with ClickHouse: ClickPipes, PeerDB, PostgreSQL table engine, MaterializedPostgreSQL database engine. |
+| [Migrating data](/migrations/postgresql/dataset)   | Part 1 of a guide on migrating from PostgreSQL to ClickHouse. Using a practical example, it demonstrates how to efficiently carry out the migration with a real-time replication (CDC) approach. Many of the concepts covered are also applicable to manual bulk data transfers from PostgreSQL to ClickHouse.                                                                                        |
+|[Rewriting PostgreSQL Queries](/migrations/postgresql/rewriting-queries)|Part 2 of a guide on migrating from PostgreSQL to ClickHouse. Using a practical example, it demonstrates how to efficiently carry out the migration with a real-time replication (CDC) approach. Many of the concepts covered are also applicable to manual bulk data transfers from PostgreSQL to ClickHouse.|
+|[Data modeling techniques](/migrations/postgresql/data-modeling-techniques)|Part 3 of a guide on migrating from PostgreSQL to ClickHouse. Using a practical example, it demonstrates how to model data in ClickHouse if migrating from PostgreSQL.|
+|[Appendix](/migrations/postgresql/appendix)|Additional information relevant to migrating from PostgreSQL|
 
diff --git a/docs/migrations/postgres/overview.md b/docs/migrations/postgres/overview.md
@@ -13,7 +13,7 @@ OLTP, or online transactional processing databases, are designed to manage trans
 
 OLAP, or online analytical processing databases, are designed to meet those needs — to manage analytical workloads. The primary objective of these databases is to ensure that engineers can efficiently query and aggregate over vast datasets. Real-time OLAP systems like ClickHouse allow this analysis to happen as data is ingested in real time.
 
-See [here](/migrations/postgres/appendix#postgres-vs-clickhouse-equivalent-and-different-concepts) for a more in-depth comparison of ClickHouse and PostgreSQL.
+See [here](/migrations/postgresql/appendix#postgres-vs-clickhouse-equivalent-and-different-concepts) for a more in-depth comparison of ClickHouse and PostgreSQL.
 
 To see the potential performance differences between ClickHouse and Postgres on analytical queries, see [Rewriting PostgreSQL Queries in ClickHouse](/migrations/postgresql/rewriting-queries).
 
