Merge pull request #3928 from ClickHouse/elastic_migration

elastic migration docs

Author: gingerwizard

docs/best-practices/minimize_optimize_joins.md

@@ -26,7 +26,7 @@ For a full guide on denormalizing data in ClickHouse see [here](/data-modeling/d
 
 ## When JOINs are required {#when-joins-are-required}
 
-When JOINs are required, ensure you’re using **at least version 24.12 and preferably the latest version**, as JOIN performance continues to improve with each new release. As of ClickHouse 24.12, the query planner now automatically places the smaller table on the right side of the join for optimal performance - a task that previously had to be done manually. Even more enhancements are coming soon, including more aggressive filter pushdown and automatic re-ordering of multiple joins.
+When JOINs are required, ensure you're using **at least version 24.12 and preferably the latest version**, as JOIN performance continues to improve with each new release. As of ClickHouse 24.12, the query planner now automatically places the smaller table on the right side of the join for optimal performance - a task that previously had to be done manually. Even more enhancements are coming soon, including more aggressive filter pushdown and automatic re-ordering of multiple joins.
 
 Follow these best practices to improve JOIN performance:
 

docs/cloud/changelogs/changelog-25_1-25_4.md

@@ -274,7 +274,7 @@ sidebar_label: 'v25.4'
 * Don't fail silently if user executing `SYSTEM DROP REPLICA` doesn't have enough permissions. [#75377](https://github.com/ClickHouse/ClickHouse/pull/75377) ([Bharat Nallan](https://github.com/bharatnc)).
 * Add a ProfileEvent about the number of times any of system logs has failed to flush. [#75466](https://github.com/ClickHouse/ClickHouse/pull/75466) ([Alexey Milovidov](https://github.com/alexey-milovidov)).
 * Add check and logging for decrypting and decompressing. [#75471](https://github.com/ClickHouse/ClickHouse/pull/75471) ([Vitaly Baranov](https://github.com/vitlibar)).
-* Added support for the micro sign (U+00B5) in the `parseTimeDelta` function. Now both the micro sign (U+00B5) and the Greek letter mu (U+03BC) are recognized as valid representations for microseconds, aligning ClickHouse's behavior with Go’s implementation ([see time.go](https://github.com/golang/go/blob/ad7b46ee4ac1cee5095d64b01e8cf7fcda8bee5e/src/time/time.go#L983C19-L983C20) and [time/format.go](https://github.com/golang/go/blob/ad7b46ee4ac1cee5095d64b01e8cf7fcda8bee5e/src/time/format.go#L1608-L1609)). [#75472](https://github.com/ClickHouse/ClickHouse/pull/75472) ([Vitaly Orlov](https://github.com/orloffv)).
+* Added support for the micro sign (U+00B5) in the `parseTimeDelta` function. Now both the micro sign (U+00B5) and the Greek letter mu (U+03BC) are recognized as valid representations for microseconds, aligning ClickHouse's behavior with Go's implementation ([see time.go](https://github.com/golang/go/blob/ad7b46ee4ac1cee5095d64b01e8cf7fcda8bee5e/src/time/time.go#L983C19-L983C20) and [time/format.go](https://github.com/golang/go/blob/ad7b46ee4ac1cee5095d64b01e8cf7fcda8bee5e/src/time/format.go#L1608-L1609)). [#75472](https://github.com/ClickHouse/ClickHouse/pull/75472) ([Vitaly Orlov](https://github.com/orloffv)).
 * Replace server setting (`send_settings_to_client`) with client setting (`apply_settings_from_server`) that controls whether client-side code (e.g. parsing INSERT data and formatting query output) should use settings from server's `users.xml` and user profile. Otherwise only settings from client command line, session, and the query are used. Note that this only applies to native client (not e.g. HTTP), and doesn't apply to most of query processing (which happens on the server). [#75478](https://github.com/ClickHouse/ClickHouse/pull/75478) ([Michael Kolupaev](https://github.com/al13n321)).
 * Keeper improvement: disable digest calculation when committing to in-memory storage for better performance. It can be enabled with `keeper_server.digest_enabled_on_commit` config. Digest is still calculated when preprocessing requests. [#75490](https://github.com/ClickHouse/ClickHouse/pull/75490) ([Antonio Andelic](https://github.com/antonio2368)).
 * Push down filter expression from JOIN ON when possible. [#75536](https://github.com/ClickHouse/ClickHouse/pull/75536) ([Vladimir Cherkasov](https://github.com/vdimir)).
@@ -621,7 +621,7 @@ sidebar_label: 'v25.4'
 * The universal installation script will propose installation even on macOS. [#74339](https://github.com/ClickHouse/ClickHouse/pull/74339) ([Alexey Milovidov](https://github.com/alexey-milovidov)).
 * Fix build when kerberos is not enabled. [#74771](https://github.com/ClickHouse/ClickHouse/pull/74771) ([flynn](https://github.com/ucasfl)).
 * Update to embedded LLVM 19. [#75148](https://github.com/ClickHouse/ClickHouse/pull/75148) ([Konstantin Bogdanov](https://github.com/thevar1able)).
-* *Potentially breaking*: Improvement to set even more restrictive defaults. The current defaults are already secure. The user has to specify an option to publish ports explicitly. But when the `default` user doesn’t have a password set by `CLICKHOUSE_PASSWORD` and/or a username changed by `CLICKHOUSE_USER` environment variables, it should be available only from the local system as an additional level of protection. [#75259](https://github.com/ClickHouse/ClickHouse/pull/75259) ([Mikhail f. Shiryaev](https://github.com/Felixoid)).
+* *Potentially breaking*: Improvement to set even more restrictive defaults. The current defaults are already secure. The user has to specify an option to publish ports explicitly. But when the `default` user doesn't have a password set by `CLICKHOUSE_PASSWORD` and/or a username changed by `CLICKHOUSE_USER` environment variables, it should be available only from the local system as an additional level of protection. [#75259](https://github.com/ClickHouse/ClickHouse/pull/75259) ([Mikhail f. Shiryaev](https://github.com/Felixoid)).
 * Integration tests have a 1-hour timeout for single batch of parallel tests running. When this timeout is reached `pytest` is killed without some logs. Internal pytest timeout is set to 55 minutes to print results from a session and not trigger external timeout signal. Closes [#75532](https://github.com/ClickHouse/ClickHouse/issues/75532). [#75533](https://github.com/ClickHouse/ClickHouse/pull/75533) ([Ilya Yatsishin](https://github.com/qoega)).
 * Make all clickhouse-server related actions a function, and execute them only when launching the default binary in `entrypoint.sh`. A long-postponed improvement was suggested in [#50724](https://github.com/ClickHouse/ClickHouse/issues/50724). Added switch `--users` to `clickhouse-extract-from-config` to get values from the `users.xml`. [#75643](https://github.com/ClickHouse/ClickHouse/pull/75643) ([Mikhail f. Shiryaev](https://github.com/Felixoid)).
 * For stress tests if server did not exit while we collected stacktraces via gdb additional wait time is added to make `Possible deadlock on shutdown (see gdb.log)` detection less noisy. It will only add delay for cases when test did not finish successfully. [#75668](https://github.com/ClickHouse/ClickHouse/pull/75668) ([Ilya Yatsishin](https://github.com/qoega)).

docs/cloud/manage/billing.md

@@ -417,7 +417,7 @@ This dimension covers the compute units provisioned per service just for Postgre
 ClickPipes. Compute is shared across all Postgres pipes within a service. **It
 is provisioned when the first Postgres pipe is created and deallocated when no
 Postgres CDC pipes remain**. The amount of compute provisioned depends on your
-organization’s tier:
+organization's tier:
 
 | Tier                         | Cost                                          |
 |------------------------------|-----------------------------------------------|
@@ -426,7 +426,7 @@ organization’s tier:
 
 #### Example {#example}
 
-Let’s say your service is in Scale tier and has the following setup:
+Let's say your service is in Scale tier and has the following setup:
 
 - 2 Postgres ClickPipes running continuous replication
 - Each pipe ingests 500 GB of data changes (CDC) per month
@@ -540,7 +540,7 @@ Postgres CDC ClickPipes pricing begins appearing on monthly bills starting
 **September 1st, 2025**, for all customers—both existing and new. Until then, 
 usage is free. Customers have a **3-month window** starting from **May 29**
 (the GA announcement date) to review and optimize their usage if needed, although
-we expect most won’t need to make any changes.
+we expect most won't need to make any changes.
 
 </details>
 
@@ -550,7 +550,7 @@ we expect most won’t need to make any changes.
 
 No data ingestion charges apply while a pipe is paused, since no data is moved. 
 However, compute charges still apply—either 0.5 or 1 compute unit—based on your 
-organization’s tier. This is a fixed service-level cost and applies across all 
+organization's tier. This is a fixed service-level cost and applies across all 
 pipes within that service.
 
 </details>

docs/cloud/reference/changelog.md

@@ -33,7 +33,7 @@ In addition to this ClickHouse Cloud changelog, please see the [Cloud Compatibil
 
 ## May 30, 2025 {#may-30-2025}
 
-- We’re excited to announce general availability of **ClickPipes for Postgres CDC**
+- We're excited to announce general availability of **ClickPipes for Postgres CDC**
   in ClickHouse Cloud. With just a few clicks, you can now replicate your Postgres
   databases and unlock blazing-fast, real-time analytics. The connector delivers 
   faster data synchronization, latency as low as a few seconds, automatic schema changes,
@@ -64,7 +64,7 @@ In addition to this ClickHouse Cloud changelog, please see the [Cloud Compatibil
   * Memory & CPU: Graphs for `CGroupMemoryTotal` (Allocated Memory), `CGroupMaxCPU` (allocated CPU),
     `MemoryResident` (memory used), and `ProfileEvent_OSCPUVirtualTimeMicroseconds` (CPU used)
   * Data Transfer: Graphs showing data ingress and egress from ClickHouse Cloud. Learn more [here](/cloud/manage/network-data-transfer).
-- We’re excited to announce the launch of our new ClickHouse Cloud Prometheus/Grafana mix-in, 
+- We're excited to announce the launch of our new ClickHouse Cloud Prometheus/Grafana mix-in, 
   built to simplify monitoring for your ClickHouse Cloud services.
   This mix-in uses our Prometheus-compatible API endpoint to seamlessly integrate
   ClickHouse metrics into your existing Prometheus and Grafana setup. It includes

docs/data-modeling/projections.md

@@ -326,7 +326,7 @@ paid prices is streaming 2.17 million rows. When we directly used a second table
 optimized for this query, only 81.92 thousand rows were streamed from disk.
 
 The reason for the difference is that currently, the `optimize_read_in_order` 
-optimization mentioned above isn’t supported for projections.
+optimization mentioned above isn't supported for projections.
 
 We inspect the `system.query_log` table to see that ClickHouse 
 automatically used the two projections for the two queries above (see the 

docs/guides/best-practices/index.md

@@ -15,10 +15,10 @@ which covers the main concepts required to improve performance.
 |---------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | [Query Optimization Guide](/optimize/query-optimization)                        | A good place to start for query optimization, this simple guide describes common scenarios of how to use different performance and optimization techniques to improve query performance.                                                                                                                                                                                |
 | [Primary Indexes Advanced Guide](/guides/best-practices/sparse-primary-indexes) | A deep dive into ClickHouse indexing including how it differs from other DB systems, how ClickHouse builds and uses a table's spare primary index and what some of the best practices are for indexing in ClickHouse.                                                                                                                                                   |
-| [Query Parallelism](/optimize/query-parallelism)                                | Explains how ClickHouse parallelizes query execution using processing lanes and the max_threads setting. Covers how data is distributed across lanes, how max_threads is applied, when it isn’t fully used, and how to inspect execution with tools like EXPLAIN and trace logs.                                                                                        |
+| [Query Parallelism](/optimize/query-parallelism)                                | Explains how ClickHouse parallelizes query execution using processing lanes and the max_threads setting. Covers how data is distributed across lanes, how max_threads is applied, when it isn't fully used, and how to inspect execution with tools like EXPLAIN and trace logs.                                                                                        |
 | [Partitioning Key](/optimize/partitioning-key)                                  | Delves into ClickHouse partition key optimization. Explains how choosing the right partition key can significantly improve query performance by allowing ClickHouse to quickly locate relevant data segments. Covers best practices for selecting efficient partition keys and potential pitfalls to avoid.                                                             |
 | [Data Skipping Indexes](/optimize/skipping-indexes)                             | Explains data skipping indexes as a way to optimize performance.                                                                                                                                                                                                                                                                                                        |
-| [PREWHERE Optimization](/optimize/prewhere)                                     | Explains how PREWHERE reduces I/O by avoiding reading unnecessary column data. Shows how it’s applied automatically, how the filtering order is chosen, and how to monitor it using EXPLAIN and logs.                                                                                                                                                                   |
+| [PREWHERE Optimization](/optimize/prewhere)                                     | Explains how PREWHERE reduces I/O by avoiding reading unnecessary column data. Shows how it's applied automatically, how the filtering order is chosen, and how to monitor it using EXPLAIN and logs.                                                                                                                                                                   |
 | [Bulk Inserts](/optimize/bulk-inserts)                                          | Explains the benefits of using bulk inserts in ClickHouse.                                                                                                                                                                                                                                                                                                              |
 | [Asynchronous Inserts](/optimize/asynchronous-inserts)                          | Focuses on ClickHouse's asynchronous inserts feature. It likely explains how asynchronous inserts work (batching data on the server for efficient insertion) and their benefits (improved performance by offloading insert processing). It might also cover enabling asynchronous inserts and considerations for using them effectively in your ClickHouse environment. |
 | [Avoid Mutations](/optimize/avoid-mutations)                                    | Discusses the importance of avoiding mutations (updates and deletes) in ClickHouse. It recommends using append-only inserts for optimal performance and suggests alternative approaches for handling data changes.                                                                                                                                                      |