How to use clustering keys in Hologres - Hologres: Central de Documentação do Alibaba Cloud

Este tópico descreve como usar uma clustering key no Hologres para ordenar dados e acelerar consultas.

Introdução

O Hologres ordena os dados nos arquivos com base em uma clustering key. Esse recurso acelera consultas de intervalo e filtros nas colunas indexadas. Especifique a clustering key ao criar uma tabela com a seguinte sintaxe:

-- Syntax supported by Hologres V2.1 and later
CREATE TABLE <table_name> (...) WITH (clustering_key = '[<columnName>[,...]]');
-- Syntax supported by all versions
BEGIN;
CREATE TABLE <table_name> (...);
CALL set_table_property('<table_name>', 'clustering_key', '[<columnName>{:asc} [,...]]');
COMMIT;

Parâmetros:

Parâmetro	Descrição
table_name	Nome da tabela na qual você deseja especificar uma clustering key.
columnName	Nome da coluna que você deseja definir como clustering key.

Recomendações de uso

A clustering key é ideal para consultas pontuais e de intervalo. Ela melhora significativamente o desempenho de operações de filtro, como consultas com WHERE a = 1 ou WHERE a > 1 AND a < 5. Para obter o melhor desempenho em consultas pontuais, defina tanto uma clustering key quanto um índice bitmap nas mesmas colunas.
A clustering key segue o princípio de correspondência mais à esquerda. Por isso, recomendamos incluir no máximo duas colunas na chave para garantir sua aplicabilidade a uma ampla variedade de consultas. A ordem das colunas é importante: as colunas listadas primeiro têm prioridade de ordenação maior do que as listadas posteriormente.
Ao especificar um campo de Clustering Key, adicione :asc após o nome do campo para definir a ordem de classificação do índice. A ordem padrão é asc (crescente). Versões do Hologres anteriores à V2.1 não suportam a definição da ordem de classificação como decrescente (desc). Nessas versões, se a ordem fosse definida como decrescente, a Clustering Key não seria utilizada, resultando em baixo desempenho de consulta. A partir da V2.1, é possível definir a Clustering Key como desc após ativar um parâmetro GUC específico. No entanto, esse recurso é suportado apenas para campos de tipos de dados como Text, Char, Varchar, Bytea e Int. A definição da Clustering Key como desc ainda não é suportada para campos de outros tipos de dados.
```
set hg_experimental_optimizer_enable_variable_length_desc_ck_filter = on;
```
Em tabelas orientadas a linhas, a clustering key assume a chave primária como valor padrão. Em versões anteriores ao Hologres V0.9, nenhuma clustering key era definida por padrão. Se você definir uma clustering key diferente da chave primária, o Hologres criará duas cópias ordenadas dos dados: uma para a chave primária e outra para a clustering key, causando redundância de dados.

Limites

Para modificar uma clustering key, crie uma nova tabela e importe os dados.
As colunas especificadas em uma clustering key devem ser NOT NULL. As versões do Hologres da V1.3.20 à V1.3.27 suportavam colunas anuláveis em uma clustering key, mas esse suporte foi removido a partir da V1.3.28. Uma clustering key anulável pode afetar a integridade dos dados. Caso seu cenário exija uma clustering key anulável, ative-a executando o comando abaixo antes da instrução SQL:
```
set hg_experimental_enable_nullable_clustering_key = true;
```
Colunas com os seguintes tipos de dados não podem ser usadas em uma clustering key: Float, Float4, Float8, Double, Decimal(Numeric), Json, Jsonb, Bit, Varbit, Money, Time With Time Zone ou outros tipos de dados complexos.
Nas versões do Hologres anteriores à V2.1, não é possível definir a ordem de classificação de um índice como decrescente (desc). Se a ordem for definida como decrescente, a clustering key não será utilizada, resultando em baixo desempenho de consulta. A partir da V2.1, ative o seguinte GUC para definir a clustering key como desc. Contudo, esse recurso é suportado apenas para campos de tipos de dados como Text, Char, Varchar, Bytea e Int. Não é possível definir a clustering key como desc para campos de outros tipos de dados.
```
set hg_experimental_optimizer_enable_variable_length_desc_ck_filter = on;
```
Para tabelas orientadas a colunas, nenhuma clustering key é definida por padrão. Especifique explicitamente uma com base no seu caso de uso.

No Hologres, é possível definir apenas uma clustering key por tabela. Isso significa que, ao criar uma tabela, execute o comando call apenas uma vez, e não múltiplas vezes. Exemplo:

Sintaxe suportada pelo Hologres V2.1 e posteriores:

-- Correct usage
CREATE TABLE tbl (
    a int NOT NULL,
    b text NOT NULL
)
WITH (
    clustering_key = 'a,b'
);
-- Incorrect usage
CREATE TABLE tbl (
    a int NOT NULL,
    b text NOT NULL
)
WITH (
    clustering_key = 'a',
    clustering_key = 'b'
);

Sintaxe suportada por todas as versões:

-- Correct usage
BEGIN;
CREATE TABLE tbl (a int NOT NULL, b text NOT NULL);
CALL set_table_property('tbl', 'clustering_key', 'a,b');
COMMIT;
-- Incorrect usage
BEGIN;
CREATE TABLE tbl (a int NOT NULL, b text NOT NULL);
CALL set_table_property('tbl', 'clustering_key', 'a');
CALL set_table_property('tbl', 'clustering_key', 'b');
COMMIT;

Funcionamento

Uma clustering key ordena fisicamente os dados nos arquivos. Por padrão, a ordenação é crescente (asc). As seções a seguir explicam os conceitos de layout lógico e físico de uma clustering key.

Layout lógico

Consultas que utilizam uma clustering key seguem o princípio de correspondência mais à esquerda. Se as condições de filtro de uma consulta não corresponderem ao prefixo das colunas da clustering key, a chave não conseguirá acelerar a consulta. O exemplo a seguir ilustra o layout lógico de uma clustering key no Hologres.
Suponha que você tenha uma tabela com as colunas Name, Date e Class.
- Se você definir a clustering key como (Date), os dados da tabela serão ordenados pela coluna Date.
- Se você definir a clustering key como (Class, Date), os dados serão ordenados primeiro pela coluna Class e, em seguida, pela coluna Date dentro de cada classe.
A escolha das colunas da clustering key determina o layout final de ordenação dos dados.
Layout de armazenamento físico

O layout de armazenamento físico de uma clustering key agrupa dados relacionados.

Esses princípios de layout têm as seguintes implicações:

A clustering key é adequada para filtros de intervalo. Consultas com condições como WHERE date = '1/1' ou WHERE a > '1/1' AND a < '1/5' são significativamente aceleradas.
As consultas seguem o princípio de correspondência mais à esquerda. Por exemplo, se uma clustering key for definida nas colunas (a,b,c), a consulta poderá ser acelerada se filtrar por (a,b,c) ou (a,b). Se a consulta filtrar por (a,c), apenas a condição em a poderá usar a clustering key. Caso a consulta filtre por (b,c), ela não poderá usar a clustering key.

No exemplo a seguir, as colunas uid,class,date formam a clustering key.

Sintaxe suportada pelo Hologres V2.1 e posteriores:

CREATE TABLE clustering_test (
    uid int NOT NULL,
    name text NOT NULL,
    class text NOT NULL,
    date text NOT NULL,
    PRIMARY KEY (uid)
)
WITH (
    clustering_key = 'uid,class,date'
);
INSERT INTO clustering_test VALUES
(1,'Alice','1','2022-10-19'),
(2,'Bob','3','2022-10-19'),
(3,'Sam','2','2022-10-20'),
(4,'Joe','2','2022-10-20'),
(5,'Sue','2','2022-10-18'),
(6,'Ben','3','2022-10-17'),
(7,'Tom','3','2022-10-20');

Sintaxe suportada por todas as versões:

BEGIN;
CREATE TABLE clustering_test (
  uid int NOT NULL,
  name text NOT NULL,
  class text NOT NULL,
  date text NOT NULL,
  PRIMARY KEY (uid)
);
CALL set_table_property('clustering_test', 'clustering_key', 'uid,class,date');
COMMIT;
INSERT INTO clustering_test VALUES
(1,'Alice','1','2022-10-19'),
(2,'Bob','3','2022-10-19'),
(3,'Sam','2','2022-10-20'),
(4,'Joe','2','2022-10-20'),
(5,'Sue','2','2022-10-18'),
(6,'Ben','3','2022-10-17'),
(7,'Tom','3','2022-10-20');

Consultar apenas a coluna uid utiliza a clustering key.

SELECT * FROM clustering_test WHERE uid > '3';

Ao inspecionar o plano de execução com a instrução EXPLAIN, observa-se um operador Cluster Filter. Isso indica que o otimizador usou a clustering key para acelerar a consulta.

explain SELECT * FROM clustering_test WHERE uid > '3';
QUERY PLAN
Gather  (cost=0.00..1.10 rows=4 width=24)
  ->  Exchange (Gather Exchange)  (cost=0.00..1.10 rows=4 width=24)
    ->  Decode  (cost=0.00..1.10 rows=4 width=24)
      ->  Index Scan using holo_index:[1] on clustering_test  (cost=0.00..1.00 rows=4 width=24)
            Cluster Filter: (uid > 3)
Optimizer: HQO version 1.3.0

Consultar as colunas uid,class utiliza a clustering key.

SELECT * FROM clustering_test WHERE uid = '3' AND class >'1' ;

O plano de execução mostra um operador Cluster Filter, indicando que o otimizador usou a clustering key para acelerar a consulta.

explain SELECT * FROM clustering_test WHERE uid = '3' AND class >'1' ;
QUERY PLAN
Exchange (Gather Exchange)  (cost=0.00..1.10 rows=1 width=24)
->  Decode  (cost=0.00..1.10 rows=1 width=24)
    ->  Index Scan using holo_index:[1] on clustering_test  (cost=0.00..1.00 rows=1 width=24)
          Cluster Filter: ((uid = 3) AND (class > '1'::text))
          Shard Selector(Eagerly):
            ->: l0 [3]
Optimizer: HQO version 1.3.0

Consultar as colunas uid,class,date utiliza a clustering key.
```
SELECT * FROM clustering_test WHERE uid = '3' AND class ='2' AND date > '2022-10-17';
```
Ao inspecionar o plano de execução, é possível ver um operador Cluster Filter, o que indica que a clustering key foi utilizada e a consulta foi acelerada. O resultado do plano de execução mostra que um Index Scan using holo_index:[1] on clustering_test é usado e a condição do Cluster Filter é ((uid = 3) AND (class = '2'::text) AND (date > '2022-10-17'::text)). Isso confirma que a clustering key foi usada corretamente.

Consultar as colunas uid,date não segue o princípio de correspondência mais à esquerda. Portanto, apenas uid pode utilizar a Clustering Key, enquanto date é processado usando um filtro comum.

SELECT * FROM clustering_test WHERE uid = '3'  AND date > '2022-10-17';

Ao visualizar o plano de execução (EXPLAIN SQL), nota-se que, no plano mostrado abaixo, apenas a coluna uid possui o operador Cluster Filter.

explain SELECT * FROM clustering_test WHERE uid = '3'  AND date > '2022-10-17';
QUERY PLAN
Exchange (Gather Exchange)  (cost=0.00..1.10 rows=1 width=24)
  -> Decode  (cost=0.00..1.10 rows=1 width=24)
    -> Index Scan using holo_index:[1] on clustering_test  (cost=0.00..1.00 rows=1 width=24)
          Filter: (date > '2022-10-17'::text)
          Cluster Filter: (uid = 3)
        Shard Selector(Eagerly):
          ->: I0 [3]
Optimizer: HQO version 1.3.0

Consultar apenas as colunas class,date não segue o princípio de correspondência mais à esquerda. A consulta não consegue aproveitar a clustering key.
```
SELECT * FROM clustering_test WHERE class ='2' AND date > '2022-10-17';
```
A ausência do operador Cluster Filter no plano de execução (obtido via EXPLAIN SQL) indica que a Clustering Key não foi usada. Após executar EXPLAIN, o plano de consulta mostra um Index Scan onde a coluna date usa um Filter e a coluna class usa um Bitmap Filter, nenhum dos quais é acelerado pela Clustering Key.

Exemplos

Exemplo 1: Cenários em que uma consulta pode utilizar uma clustering key.

Sintaxe suportada pelo Hologres V2.1 e posteriores:

CREATE TABLE table1 (
    col1 int NOT NULL,
    col2 text NOT NULL,
    col3 text NOT NULL,
    col4 text NOT NULL
)
WITH (
    clustering_key = 'col1,col2'
);
-- For the table created above, the following queries can be accelerated.
-- This query can be accelerated.
select * from table1 where col1='abc';
-- This query can be accelerated.
select * from table1 where col1>'xxx' and col1<'abc';
-- This query can be accelerated.
select * from table1 where col1 in ('abc','def');
-- This query can be accelerated.
select * from table1 where col1='abc' and col2='def'; 
-- This query cannot be accelerated.
select col1,col4 from table1 where col2='def';

Sintaxe suportada por todas as versões:

begin;
create table table1 (
  col1 int not null,
  col2 text not null,
  col3 text not null,
  col4 text not null
);
call set_table_property('table1', 'clustering_key', 'col1,col2');
commit;
-- For the table created above, the following queries can be accelerated.
-- This query can be accelerated.
select * from table1 where col1='abc';
-- This query can be accelerated.
select * from table1 where col1>'xxx' and col1<'abc';
-- This query can be accelerated.
select * from table1 where col1 in ('abc','def');
-- This query can be accelerated.
select * from table1 where col1='abc' and col2='def';
-- This query cannot be accelerated.
select col1,col4 from table1 where col2='def';

Exemplo 2: A Clustering Key está definida como asc/desc.

Sintaxe suportada pelo Hologres V2.1 e posteriores:

CREATE TABLE tbl (
    a int NOT NULL,
    b text NOT NULL
)
WITH (
    clustering_key = 'a:desc,b:asc'
);

Sintaxe suportada por todas as versões:

BEGIN;
CREATE TABLE tbl (
  a int NOT NULL, 
  b text NOT NULL
);
CALL set_table_property('tbl', 'clustering_key', 'a:desc,b:asc');
COMMIT;

Ajustes avançados

Diferentemente da clustering key em bancos de dados tradicionais como MySQL ou SQL Server, a ordenação no Hologres ocorre apenas nos arquivos, e não em toda a tabela. Portanto, realizar uma operação ORDER BY na Clustering Key ainda gera custo de desempenho.

A partir da V1.3, o Hologres introduziu otimizações significativas de desempenho para casos de uso de clustering key. Essas otimizações proporcionam melhor desempenho nos dois cenários a seguir. Se sua instância do Hologres estiver em uma versão anterior à 1,3, consulte Solução de problemas: Erros de preparação de upgrade ou entre em contato conosco para obter suporte seguindo as instruções em Como obter suporte online?.

Usar ORDER BY em clustering keys

No Hologres, os dados dentro de um arquivo são ordenados de acordo com as clustering keys definidas. Em versões anteriores à V1.3, o otimizador não conseguia usar a propriedade de ordenação das clustering keys para gerar um plano de execução ideal. Além disso, a ordem dos dados não podia ser garantida após passar por um nó de shuffle devido à mesclagem de múltiplas vias. Isso frequentemente resultava em maior carga computacional e tempos de consulta mais longos. O Hologres V1.3 otimiza esse processo. Agora, o otimizador pode gerar um plano de execução que utiliza a propriedade de ordenação das clustering keys e preserva a ordem dos dados entre os shuffles, melhorando o desempenho da consulta. No entanto, observe os seguintes pontos:

Se uma consulta não filtrar pelas clustering keys de uma tabela, ela usará SeqScan por padrão em vez de IndexScan. Apenas o IndexScan utiliza a propriedade de ordenação das clustering keys.
O otimizador nem sempre escolhe um plano de execução que depende da ordem de classificação da clustering key, pois essa abordagem tem algum custo. Por exemplo, dados ordenados nos arquivos ainda podem exigir ordenação adicional na memória.

Exemplo:

Sintaxe suportada pelo Hologres V2.1 e posteriores:

DROP TABLE IF EXISTS test_use_sort_info_of_clustering_keys;
CREATE TABLE test_use_sort_info_of_clustering_keys (
    a int NOT NULL,
    b int NOT NULL,
    c text
)
WITH (
    distribution_key = 'a',
    clustering_key = 'a,b'
);
INSERT INTO test_use_sort_info_of_clustering_keys SELECT i%500, i%100, i::text FROM generate_series(1, 1000) as s(i);
ANALYZE test_use_sort_info_of_clustering_keys;

Sintaxe suportada por todas as versões:

DROP TABLE if exists test_use_sort_info_of_clustering_keys;
BEGIN;
CREATE TABLE test_use_sort_info_of_clustering_keys
(
          a int NOT NULL,
          b int NOT NULL,
          c text
);
CALL set_table_property('test_use_sort_info_of_clustering_keys', 'distribution_key', 'a');
CALL set_table_property('test_use_sort_info_of_clustering_keys', 'clustering_key', 'a,b');
COMMIT;
INSERT INTO test_use_sort_info_of_clustering_keys SELECT i%500, i%100, i::text FROM generate_series(1, 1000) as s(i);
ANALYZE test_use_sort_info_of_clustering_keys;

Instrução de consulta:

explain select * from test_use_sort_info_of_clustering_keys where a > 100  order by a, b;

Comparação de planos de execução

O código a seguir mostra o plano de execução em uma versão anterior à V1.3, como a V1.1. Visualize o plano executando a instrução EXPLAIN.

 Sort  (cost=0.00..0.00 rows=797 width=11)
   ->  Gather  (cost=0.00..2.48 rows=797 width=11)
         Sort Key: a, b
         ->  Sort  (cost=0.00..2.44 rows=797 width=11)
               Sort Key: a, b
               ->  Exchange (Gather Exchange)  (cost=0.00..1.11 rows=797 width=11)
                     ->  Decode  (cost=0.00..1.11 rows=797 width=11)
                           ->  Index Scan using holo_index:[1] on test_use_sort_info_of_clustering_keys  (cost=0.00..1.00 rows=797 width=11)
                                 Cluster Filter: (a > 100)

O código a seguir mostra o plano de execução no Hologres V1.3.

 Gather  (cost=0.00..1.15 rows=797 width=11)
   Merge Key: a, b
   ->  Exchange (Gather Exchange)  (cost=0.00..1.11 rows=797 width=11)
         Merge Key: a, b
         ->  Decode  (cost=0.00..1.11 rows=797 width=11)
               ->  Index Scan using holo_index:[1] on test_use_sort_info_of_clustering_keys  (cost=0.00..1.01 rows=797 width=11)
                     Order by: a, b
                     Cluster Filter: (a > 100)

O plano de execução da V1.3 é mais eficiente. Ele usa a propriedade de ordenação da clustering key para mesclar diretamente a saída. Isso cria uma execução em pipeline e evita operações lentas de ordenação ao trabalhar com grandes conjuntos de dados. Conforme mostrado na comparação, o plano da V1.3 substitui o operador Sort por um Merge Key, indicando um processo baseado em mesclagem mais eficiente.

Usar JOIN em clustering keys (Beta)

O Hologres V1.3 introduziu o operador Merge Join, que permite ao otimizador aproveitar a natureza ordenada das clustering keys, reduzir a carga computacional e melhorar o desempenho. No entanto, observe os seguintes pontos:

Este recurso está em beta e desativado por padrão. Para usá-lo, ative o seguinte parâmetro antes de executar sua consulta:
```
-- Enable merge join
set hg_experimental_enable_sort_merge_join=on;
```
Se uma consulta não filtrar pelas clustering keys de uma tabela, ela usará SeqScan por padrão em vez de IndexScan. Apenas o IndexScan utiliza a propriedade de ordenação das clustering keys.
O otimizador nem sempre gera um plano de execução baseado na ordem de classificação das clustering keys, pois usar essa propriedade tem alguns custos. Por exemplo, dados ordenados nos arquivos ainda podem exigir ordenação adicional na memória.

Exemplo:

Sintaxe suportada pelo Hologres V2.1 e posteriores:

DROP TABLE IF EXISTS test_use_sort_info_of_clustering_keys1;
CREATE TABLE test_use_sort_info_of_clustering_keys1 (
    a int,
    b int,
    c text
)
WITH (
    distribution_key = 'a',
    clustering_key = 'a,b'
);
INSERT INTO test_use_sort_info_of_clustering_keys1 SELECT i % 500, i % 100, i::text FROM generate_series(1, 10000) AS s(i);
ANALYZE test_use_sort_info_of_clustering_keys1;
DROP TABLE IF EXISTS test_use_sort_info_of_clustering_keys2;
CREATE TABLE test_use_sort_info_of_clustering_keys2 (
    a int,
    b int,
    c text
)
WITH (
    distribution_key = 'a',
    clustering_key = 'a,b'
);
INSERT INTO test_use_sort_info_of_clustering_keys2 SELECT i % 600, i % 200, i::text FROM generate_series(1, 10000) AS s(i);
ANALYZE test_use_sort_info_of_clustering_keys2;

Sintaxe suportada por todas as versões:

drop table if exists test_use_sort_info_of_clustering_keys1;
begin;
create table test_use_sort_info_of_clustering_keys1
(
  a int,
  b int,
  c text
);
call set_table_property('test_use_sort_info_of_clustering_keys1', 'distribution_key', 'a');
call set_table_property('test_use_sort_info_of_clustering_keys1', 'clustering_key', 'a,b');
commit;
insert into test_use_sort_info_of_clustering_keys1 select i%500, i%100, i::text from generate_series(1, 10000) as s(i);
analyze test_use_sort_info_of_clustering_keys1;
drop table if exists test_use_sort_info_of_clustering_keys2;
begin;
create table test_use_sort_info_of_clustering_keys2
(
  a int,
  b int,
  c text
);
call set_table_property('test_use_sort_info_of_clustering_keys2', 'distribution_key', 'a');
call set_table_property('test_use_sort_info_of_clustering_keys2', 'clustering_key', 'a,b');
commit;
insert into test_use_sort_info_of_clustering_keys2 select i%600, i%200, i::text from generate_series(1, 10000) as s(i);
analyze test_use_sort_info_of_clustering_keys2;

Instrução de consulta:

explain select * from test_use_sort_info_of_clustering_keys1 a join test_use_sort_info_of_clustering_keys2 b on a.a = b.a and a.b=b.b where a.a > 100 and b.a < 300;

Comparação de planos de execução

O código a seguir mostra o plano de execução em uma versão anterior à V1.3, como a V1.1.

 Gather  (cost=0.00..3.09 rows=4762 width=24)
   ->  Hash Join  (cost=0.00..2.67 rows=4762 width=24)
         Hash Cond: ((test_use_sort_info_of_clustering_keys1.a = test_use_sort_info_of_clustering_keys2.a) AND (test_use_sort_info_of_clustering_keys1.b = test_use_sort_info_of_clustering_keys2.b))
         ->  Exchange (Gather Exchange)  (cost=0.00..1.14 rows=3993 width=12)
               ->  Decode  (cost=0.00..1.14 rows=3993 width=12)
                     ->  Index Scan using holo_index:[1] on test_use_sort_info_of_clustering_keys1  (cost=0.00..1.01 rows=3993 width=12)
                           Cluster Filter: ((a > 100) AND (a < 300))
         ->  Hash  (cost=1.13..1.13 rows=3386 width=12)
               ->  Exchange (Gather Exchange)  (cost=0.00..1.13 rows=3386 width=12)
                     ->  Decode  (cost=0.00..1.13 rows=3386 width=12)
                           ->  Index Scan using holo_index:[1] on test_use_sort_info_of_clustering_keys2  (cost=0.00..1.01 rows=3386 width=12)
                                 Cluster Filter: ((a > 100) AND (a < 300))

O código a seguir mostra o plano de execução no Hologres V1.3.

  Gather  (cost=0.00..2.88 rows=4762 width=24)
   ->  Merge Join  (cost=0.00..2.46 rows=4762 width=24)
         Merge Cond: ((test_use_sort_info_of_clustering_keys2.a = test_use_sort_info_of_clustering_keys1.a) AND (test_use_sort_info_of_clustering_keys2.b = test_use_sort_info_of_clustering_keys1.b))
         ->  Exchange (Gather Exchange)  (cost=0.00..1.14 rows=3386 width=12)
               Merge Key: test_use_sort_info_of_clustering_keys2.a, test_use_sort_info_of_clustering_keys2.b
               ->  Decode  (cost=0.00..1.14 rows=3386 width=12)
                     ->  Index Scan using holo_index:[1] on test_use_sort_info_of_clustering_keys2  (cost=0.00..1.01 rows=3386 width=12)
                           Order by: test_use_sort_info_of_clustering_keys2.a, test_use_sort_info_of_clustering_keys2.b
                           Cluster Filter: ((a > 100) AND (a < 300))
         ->  Exchange (Gather Exchange)  (cost=0.00..1.14 rows=3993 width=12)
               Merge Key: test_use_sort_info_of_clustering_keys1.a, test_use_sort_info_of_clustering_keys1.b
               ->  Decode  (cost=0.00..1.14 rows=3993 width=12)
                     ->  Index Scan using holo_index:[1] on test_use_sort_info_of_clustering_keys1  (cost=0.00..1.01 rows=3993 width=12)
                           Order by: test_use_sort_info_of_clustering_keys1.a, test_use_sort_info_of_clustering_keys1.b
                           Cluster Filter: ((a > 100) AND (a < 300))

O plano da V1.3 usa um Merge Join aproveitando a natureza ordenada da clustering key. Ele realiza uma mesclagem ordenada dentro de cada shard antes da junção, criando um pipeline eficiente. Essa abordagem evita possíveis erros de falta de memória (OOM) que podem ocorrer com um Hash Join quando um dos lados da junção é muito grande para caber na memória.

Documentação relacionada

Para obter mais informações sobre instruções de Linguagem de Definição de Dados (DDL) para tabelas internas do Hologres, consulte os seguintes tópicos: