Merge branch 'main' into search_for_kb

Author: Blargian

docs/en/cloud/reference/cloud-compatibility.md

@@ -127,9 +127,10 @@ The table below summarizes our efforts to expand some of the capabilities descri
 |SQL user-defined functions (UDFs)                                        | **Added in GA**                         |
 |MySQL and PostgreSQL engine                                              | **Added in GA**                         |
 |MySQL interface                                                          | **Added in GA**                         |
-|Postgres interfaces                                                      | Coming soon                                       |
-|Engines for SQLite, ODBC, Redis, HDFS, and Hive                          | Coming soon                                       |
-|Protobuf, Cap'n'Proto formats                                            | Coming soon                                       |
+|Redis                                                                    | Coming soon                             |
+|Postgres interfaces                                                      | Evaluating demand                       |
+|Engines for SQLite, ODBC, HDFS, and Hive                                 | Evaluating demand                       |
+|Protobuf, Cap'n'Proto formats                                            | Evaluating demand                       |
 |Kafka Table Engine                                                       | Not recommended; see alternatives above |
 |JDBC Table Engine                                                        | Not recommended                         |
 |EmbeddedRocksDB Engine                                                   | Evaluating demand                       |

docs/en/data-modeling/schema-design.md

@@ -139,7 +139,7 @@ The largest initial improvement in compression and query performance can be obta
 
 - **Use strict types** - Our initial schema used Strings for many columns which are clearly numerics. Usage of the correct types will ensure the expected semantics when filtering and aggregating. The same applies to date types, which have been correctly provided in the Parquet files.
 - **Avoid Nullable Columns** - By default the above columns have been assumed to be Null. The Nullable type allows queries to determine the difference between an empty and Null value. This creates a separate column of UInt8 type. This additional column has to be processed every time a user works with a nullable column. This leads to additional storage space used and almost always negatively affects query performance. Only use Nullable if there is a difference between the default empty value for a type and Null. For example, a value of 0 for empty values in the `ViewCount` column will likely be sufficient for most queries and not impact results. If empty values should be treated differently, they can often also be excluded from queries with a filter.
-Use the minimal precision for numeric types - ClickHouse has a number of numeric types designed for different numeric ranges and precision. Always aim to minimize the number of bits used to represent a column. As well as integers of different size e.g. Int16, ClickHouse offers unsigned variants whose minimum value is 0. These can allow fewer bits to be used for a column e.g. UInt16 has a maximum value of 65535, twice that of an Int16. Prefer these types over large unsigned variants if possible.
+Use the minimal precision for numeric types - ClickHouse has a number of numeric types designed for different numeric ranges and precision. Always aim to minimize the number of bits used to represent a column. As well as integers of different size e.g. Int16, ClickHouse offers unsigned variants whose minimum value is 0. These can allow fewer bits to be used for a column e.g. UInt16 has a maximum value of 65535, twice that of an Int16. Prefer these types over larger signed variants if possible.
 - **Minimal precision for date types** - ClickHouse supports a number of date and datetime types. Date and Date32 can be used for storing pure dates, with the latter supporting a larger date range at the expense of more bits. DateTime and DateTime64 provide support for date times. DateTime is limited to second granularity and uses 32 bits. DateTime64, as the name suggests, uses 64 bits but provides support up to nanosecond granularity. As ever, choose the more coarse version acceptable for queries, minimizing the number of bits needed.
 - **Use LowCardinality** - Numbers, strings, Date or DateTime columns with a low number of unique values can potentially be encoded using the LowCardinality type. This dictionary encodes values, reducing the size on disk. Consider this for columns with less than 10k unique values. 
 FixedString for special cases - Strings which have a fixed length can be encoded with the FixedString type e.g. language and currency codes.  This is efficient when data has the length of precisely N bytes. In all other cases, it is likely to reduce efficiency and LowCardinality is preferred.

docs/en/whats-new/roadmap.md

@@ -8,10 +8,11 @@ sidebar_position: 50
 
 The current roadmap is published for open discussion:
 
-- [2024](https://github.com/ClickHouse/ClickHouse/issues/58392)
+- [2025](https://github.com/ClickHouse/ClickHouse/issues/74046)
 
 ## Previous Roadmaps
 
+- [2024](https://github.com/ClickHouse/ClickHouse/issues/58392)
 - [2023](https://github.com/ClickHouse/ClickHouse/issues/44767)
 - [2022](https://github.com/ClickHouse/ClickHouse/issues/44767)
 - [2021](https://github.com/ClickHouse/ClickHouse/issues/17623)

src/css/custom.scss

@@ -1184,3 +1184,14 @@ input:-ms-input-placeholder { /* IE 10-11 */
 input::-ms-input-placeholder { /* Microsoft Edge */
   color: var(--docsearch-muted-color);;
 }
+
+[data-theme='light'] .details_r1OI {
+  --ifm-alert-background-color: #F6F7FA;
+  --ifm-alert-foreground-color: var(--ifm-alert-foreground-color);
+  border: 1px solid #E6E7E9;
+
+  .details_lb9f > summary::before {
+    border-color: transparent transparent transparent
+    #437EEF;
+  }
+}