broken links

Author: levkk

docs/architecture/comparison.md

@@ -28,7 +28,7 @@ PgDog aims to be the de facto PostgreSQL proxy and pooler. Below is a feature co
 | [Manual routing](../features/sharding/manual-routing.md) | Only using comments (regex), doesn't work with prepared statements | :material-check-circle-outline: |
 | [Automatic routing](../features/sharding/query-routing.md) | No | :material-check-circle-outline: |
 | [Primary key generation](../features/sharding/schema_management/primary_keys.md) | No | :material-check-circle-outline: |
-| [Cross-shard queries](../features/sharding/cross-shard.md) | No | Partial support |
-| [COPY](../features/sharding/copy.md) | No | :material-check-circle-outline: |
+| [Cross-shard queries](../features/sharding/cross-shard-queries/index.md) | No | Partial support |
+| [COPY](../features/sharding/cross-shard-queries/copy.md) | No | :material-check-circle-outline: |
 | [Postgres-compatible sharding functions](../features/sharding/sharding-functions.md) | No | Same functions as declarative partitioning |
 | Two-Phase Commit  | No | :material-check-circle-outline: |

docs/features/sharding/2pc.md

@@ -104,4 +104,4 @@ Two-phase commit is used for writes only. Read transactions are finished using n
 ## Read more
 
 - [Omnisharded tables](omnishards.md)
-- [Cross-shard queries](cross-shard.md)
+- [Cross-shard queries](cross-shard-queries/index.md)

docs/features/sharding/cross-shard-queries/copy.md

@@ -22,7 +22,7 @@ PgDog supports sharding data sent via `COPY`, using any one of the following for
 | Text | PostgreSQL version of CSV, with `<tab>` (`\t`) as the delimiter. | `hello\tworld\t1\t2\t3` |
 | Binary | PostgreSQL-specific format that encodes data using the format used to store it on disk. | |
 
-Each row is extracted from the data stream, inspected for the sharding key, and sent to a data node. The sharding key should be specified in the [configuration](../../configuration/pgdog.toml/sharded_tables.md) and provided in the command statement, for example:
+Each row is extracted from the data stream, inspected for the sharding key, and sent to a data node. The sharding key should be specified in the [configuration](../../../configuration/pgdog.toml/sharded_tables.md) and provided in the command statement, for example:
 
 ```postgresql
 COPY users (id, email) FROM STDIN;
@@ -38,5 +38,5 @@ The cost of parsing and sharding the CSV stream in PgDog is negligibly small.
 
 ## Read more
 
-- [Two-phase commit](2pc.md)
-- [Omnisharded tables](omnishards.md)
+- [Two-phase commit](../2pc.md)
+- [Omnisharded tables](../omnishards.md)

docs/features/sharding/cross-shard-queries/ddl.md

@@ -8,7 +8,7 @@ icon: material/table-cog
 
 ## Atomicity
 
-DDL statements should be atomic across all shards. This is to protect against a single shard failure to create a table or index, which could result in an inconsistent schema. PgDog can use [two-phase commit](2pc.md) to ensure this is the case, however that means that all DDL statements must be executed inside a transaction, for example:
+DDL statements should be atomic across all shards. This is to protect against a single shard failure to create a table or index, which could result in an inconsistent schema. PgDog can use [two-phase commit](../2pc.md) to ensure this is the case, however that means that all DDL statements must be executed inside a transaction, for example:
 
 ```postgresql
 BEGIN;
@@ -22,7 +22,7 @@ COMMIT;
 
 ## Idempotency
 
-Some statements, like `CREATE INDEX CONCURRENTLY`, cannot run inside transactions. To make sure these are safely executed, you have two options: use [manual routing](manual-routing.md) and execute it on each shard individually, or write idempotent schema migrations, for example:
+Some statements, like `CREATE INDEX CONCURRENTLY`, cannot run inside transactions. To make sure these are safely executed, you have two options: use [manual routing](../manual-routing.md) and execute it on each shard individually, or write idempotent schema migrations, for example:
 
 ```postgresql
 DROP INDEX IF EXISTS user_id_idx;

docs/features/sharding/index.md

@@ -19,9 +19,9 @@ PgDog is a query router. It can extract sharding hints directly from the SQL usi
 | Query router feature | Description |
 |-|-|
 | [**Direct-to-shard queries**](query-routing.md) | Automatic sharding key detection which sends the query to one shard only. |
-| [**Cross-shard queries**](cross-shard.md) | Queries that don't have a sharding key are sent to all shards with results collected and transformed, as if they came from one database. |
+| [**Cross-shard queries**](cross-shard-queries/index.md) | Queries that don't have a sharding key are sent to all shards with results collected and transformed, as if they came from one database. |
 | [**Manual routing**](manual-routing.md) | Provide the sharding key in a query comment, or separately with a `SET` PostgreSQL command. |
-| [**Sharded COPY**](copy.md) | Data sent via `COPY` commands is automatically split between all shards, using the configured [sharding function](sharding-functions.md). |
+| [**Sharded COPY**](cross-shard-queries/copy.md) | Data sent via `COPY` commands is automatically split between all shards, using the configured [sharding function](sharding-functions.md). |
 
 ## Managing data
 

docs/features/sharding/manual-routing.md

@@ -140,5 +140,5 @@ You can read more about this in [our blog](https://pgdog.dev/blog/sharding-a-rea
 
 ## Read more
 
-- [Cross-shard queries](cross-shard.md)
+- [Cross-shard queries](cross-shard-queries/index.md)
 - [Sharding functions](sharding-functions.md)

docs/features/sharding/query-routing.md

@@ -40,15 +40,15 @@ The `SELECT` query can express complex filtering logic and not all of it is curr
 | Column equals to a value | `payments.user_id = $1` |
 | Column matches against a list | `payments.user_id IN ($1, $2, $3)`
 
-All other variations will be ignored and the query will be sent to [all shards](cross-shard.md).
+All other variations will be ignored and the query will be sent to [all shards](cross-shard-queries/index.md).
 
 !!! note "Query router improvements"
     This is an area of constant improvement. Check back here for updates or [create an issue](https://github.com/pgdogdev/pgdog/issues/new) to request
     support for a particular filter you're using.
 
 If the query has multiple sharding key filters, all of them will be extracted and converged to a set of unique shard numbers.
 
-For example, when filtering by a list of values, e.g., `WHERE user_id IN ($1, $2, $3)`, if all of them map to a single shard, the query will be sent to that shard only. If they map to two or more shards, it will be sent to all corresponding shards [concurrently](cross-shard.md).
+For example, when filtering by a list of values, e.g., `WHERE user_id IN ($1, $2, $3)`, if all of them map to a single shard, the query will be sent to that shard only. If they map to two or more shards, it will be sent to all corresponding shards [concurrently](cross-shard-queries/index.md).
 
 ## INSERT
 
@@ -77,7 +77,7 @@ VALUES ($1, $2), ($3, $4) -- More than one tuple.
 
 Both `UPDATE` and `DELETE` queries work identically to [`SELECT`](#select) queries. The query router looks inside the `WHERE` clause for sharding keys, and routes the query to the corresponding shard.
 
-If no `WHERE` clause is present, or it's filtering on a column not used for sharding, the query is sent to all shards [concurrently](cross-shard.md), for example:
+If no `WHERE` clause is present, or it's filtering on a column not used for sharding, the query is sent to all shards [concurrently](cross-shard-queries/index.md), for example:
 
 ```postgresql
 UPDATE users SET banned = true;
@@ -144,5 +144,5 @@ The latter will match queries referring to the `users.id` column only. Together
 
 ## Read more
 
-- [Cross-shard queries](cross-shard.md)
+- [Cross-shard queries](cross-shard-queries/index.md)
 - [Manual routing](manual-routing.md)

docs/features/sharding/resharding/hash.md

@@ -39,7 +39,7 @@ Required (*) and optional parameters for this command are as follows:
 
 The first thing PgDog will do when data sync is started is create a replication slot on each primary database in the source cluster. This will prevent Postgres from removing the WAL, while we copy data for each table to the destination.
 
-Next, each table will be copied, in parallel, to the destination database, using [sharded COPY](../copy.md). Once that's done, table changes are synchronized, in real-time, with logical replication from the replication slot created earlier.
+Next, each table will be copied, in parallel, to the destination database, using [sharded COPY](../cross-shard-queries/copy.md). Once that's done, table changes are synchronized, in real-time, with logical replication from the replication slot created earlier.
 
 The whole process happens entirely online, and doesn't require database reboots or pausing writes to the source database.
 
@@ -95,7 +95,7 @@ PgDog will distribute the table copy load evenly between all replicas in the con
 
 #### Binary `COPY`
 
-PgDog uses the binary `COPY` format to send and receive data, which has been shown to be consistently faster than text, because it avoids the (de)serialization overhead of sending tuples in text form. PgDog decodes tuples in-flight and splits them evenly between destination shards, using the [sharded COPY](../copy.md) implementation.
+PgDog uses the binary `COPY` format to send and receive data, which has been shown to be consistently faster than text, because it avoids the (de)serialization overhead of sending tuples in text form. PgDog decodes tuples in-flight and splits them evenly between destination shards, using the [sharded COPY](../cross-shard-queries/copy.md) implementation.
 
 !!! note "Binary compatibility"
     While the data format used by PostgreSQL databases hasn't changed in decades, binary `COPY` sends rows exactly as they are stored on disk.

docs/features/sharding/sharding-functions.md

@@ -23,7 +23,7 @@ The sharding functions are configurable in [`pgdog.toml`](../../configuration/pg
     Since sharding is configured for each table or column name, this allows storing tables
     with different sharding functions in the same database.
 
-    While this works for some [cross-shard](cross-shard.md) queries, joins between tables using a different sharding function are not possible for [direct-to-shard](query-routing.md) queries.
+    While this works for some [cross-shard](cross-shard-queries/index.md) queries, joins between tables using a different sharding function are not possible for [direct-to-shard](query-routing.md) queries.
 
 
 ## Hash
@@ -81,7 +81,7 @@ values = [1, 2, 3]
 shard = 0
 ```
 
-This example will route all queries with `user_id` equal to one, two, or three to shard zero. Unlike [hash](#hash) sharding, a value <-> shard mapping is required for _all_ values of the sharding key. If a value is used that doesn't have a mapping, the query will be sent to [all shards](cross-shard.md).
+This example will route all queries with `user_id` equal to one, two, or three to shard zero. Unlike [hash](#hash) sharding, a value <-> shard mapping is required for _all_ values of the sharding key. If a value is used that doesn't have a mapping, the query will be sent to [all shards](cross-shard-queries/index.md).
 
 !!! note "Required configuration"
     The `[[sharded_tables]]` configuration entry is still required for list and range sharding. It specifies the data type of the column, which tells PgDog how to parse its value at runtime.
@@ -242,5 +242,5 @@ If a safe rewrite plan cannot be determined, PgDog will abort the transaction an
 
 ## Read more
 
-- [COPY command](copy.md)
+- [COPY command](cross-shard-queries/copy.md)
 - [Two-phase commit](2pc.md)

docs/features/sharding/supported-queries.md

@@ -71,7 +71,7 @@ Currently, PgDog only supports `INSERT` statements with one tuple in the `VALUES
 
 ### `COPY`
 
-`COPY` statements are automatically sharded between all shards. See [COPY](copy.md) for more details.
+`COPY` statements are automatically sharded between all shards. See [COPY](cross-shard-queries/copy.md) for more details.
 
 ## DDL