From 9a425a66762343578ca1e8436d711fb168bfebbe Mon Sep 17 00:00:00 2001 From: "mintlify[bot]" <109931778+mintlify[bot]@users.noreply.github.com> Date: Thu, 4 Jun 2026 08:32:05 +0000 Subject: [PATCH] docs: fix typo non-existence to non-existent in postgres migration guide --- .../postgres/migration-guide/migration-guide-part3.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/core/get-started/setup/migration-guides/postgres/migration-guide/migration-guide-part3.mdx b/core/get-started/setup/migration-guides/postgres/migration-guide/migration-guide-part3.mdx index dfe8d02c..b0ac8627 100644 --- a/core/get-started/setup/migration-guides/postgres/migration-guide/migration-guide-part3.mdx +++ b/core/get-started/setup/migration-guides/postgres/migration-guide/migration-guide-part3.mdx @@ -110,7 +110,7 @@ Ok. 0 rows in set. Elapsed: 0.103 sec. ``` -- **Query optimization** - While partitions can assist with query performance, this depends heavily on the access patterns. If queries target only a few partitions (ideally one), performance can potentially improve. This is only typically useful if the partitioning key isn't in the primary key and you're filtering by it. However, queries that need to cover many partitions may perform worse than if no partitioning is used (as there may possibly be more parts as a result of partitioning). The benefit of targeting a single partition will be even less pronounced to non-existence if the partitioning key is already an early entry in the primary key. Partitioning can also be used to [optimize GROUP BY queries](/core/reference/engines/table-engines/mergetree-family/custom-partitioning-key#group-by-optimisation-using-partition-key) if values in each partition are unique. However, in general, you should ensure the primary key is optimized and only consider partitioning as a query optimization technique in exceptional cases where access patterns access a specific predictable subset of the day, e.g., partitioning by day, with most queries in the last day. +- **Query optimization** - While partitions can assist with query performance, this depends heavily on the access patterns. If queries target only a few partitions (ideally one), performance can potentially improve. This is only typically useful if the partitioning key isn't in the primary key and you're filtering by it. However, queries that need to cover many partitions may perform worse than if no partitioning is used (as there may possibly be more parts as a result of partitioning). The benefit of targeting a single partition will be even less pronounced to non-existent if the partitioning key is already an early entry in the primary key. Partitioning can also be used to [optimize GROUP BY queries](/core/reference/engines/table-engines/mergetree-family/custom-partitioning-key#group-by-optimisation-using-partition-key) if values in each partition are unique. However, in general, you should ensure the primary key is optimized and only consider partitioning as a query optimization technique in exceptional cases where access patterns access a specific predictable subset of the day, e.g., partitioning by day, with most queries in the last day. ### Recommendations for partitions {#recommendations-for-partitions}