From d5c8ba40bbcc609a93f2fde702504549f7d47b41 Mon Sep 17 00:00:00 2001 From: Robert Hodges Date: Wed, 4 Sep 2024 08:22:15 -0700 Subject: [PATCH] Update joins-tricks.md Fixed syntax. --- .../en/altinity-kb-queries-and-syntax/joins/joins-tricks.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/en/altinity-kb-queries-and-syntax/joins/joins-tricks.md b/content/en/altinity-kb-queries-and-syntax/joins/joins-tricks.md index fcf907ba81..4f12dd1808 100644 --- a/content/en/altinity-kb-queries-and-syntax/joins/joins-tricks.md +++ b/content/en/altinity-kb-queries-and-syntax/joins/joins-tricks.md @@ -1,6 +1,6 @@ --- -title: "JOINs optimization tricks" -linkTitle: "JOINs optimization tricks" +title: "JOIN optimization tricks" +linkTitle: "JOIN optimization tricks" description: > JOINs --- @@ -214,7 +214,7 @@ Probably, but it does mean that we need to get rid of JOIN. Despite that all DBMS support ~ similar feature set, feature performance on different database are different: -Small example, for PostgreSQL, is recommended to replace big IN clauses with JOINs, because IN clauses have bad performance in it. +Small example, for PostgreSQL, is recommended to replace big IN clauses with JOINs, because IN clauses have bad performance. But for ClickHouse it's the opposite!, IN works faster than JOIN, because it only checks key existence in HashSet and doesn't need to extract any data from the right table in IN. Let's test that: