Cara menggunakan kunci clustering di Hologres - Hologres

Topik ini menjelaskan cara menggunakan clustering key di Hologres untuk mengurutkan data dan mempercepat kueri.

Pendahuluan

Hologres mengurutkan data dalam file berdasarkan clustering key. Hal ini dapat mempercepat kueri rentang (range) dan filter pada kolom yang diindeks. Anda harus menentukan clustering key saat membuat tabel dengan sintaks berikut.

-- Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru
CREATE TABLE <table_name> (...) WITH (clustering_key = '[<columnName>[,...]]');
-- Sintaks yang didukung oleh semua versi
BEGIN;
CREATE TABLE <table_name> (...);
CALL set_table_property('<table_name>', 'clustering_key', '[<columnName>{:asc} [,...]]');
COMMIT;

Parameter:

Parameter	Deskripsi
table_name	Nama tabel tempat Anda ingin menentukan clustering key.
columnName	Nama kolom yang ingin Anda tentukan sebagai clustering key.

Rekomendasi penggunaan

Clustering key ideal untuk kueri titik (point) dan rentang (range). Fitur ini secara signifikan meningkatkan performa operasi filter, seperti kueri dengan WHERE a = 1 atau WHERE a > 1 AND a < 5. Untuk performa kueri titik yang optimal, Anda dapat menetapkan clustering key dan bitmap index pada kolom yang sama.
Clustering key mengikuti prinsip pencocokan paling kiri (leftmost matching principle). Oleh karena itu, kami merekomendasikan agar Anda tidak menyertakan lebih dari dua kolom dalam clustering key untuk memastikan clustering key tersebut berlaku pada berbagai jenis kueri. Urutan kolom sangat penting: kolom yang disebutkan lebih awal memiliki prioritas pengurutan lebih tinggi daripada kolom yang disebutkan kemudian.
Saat menentukan field Clustering Key, Anda dapat menambahkan :asc setelah nama field untuk menentukan urutan pengurutan indeks. Urutan pengurutan default adalah asc (ascending). Versi Hologres sebelum V2.1 tidak mendukung pengaturan urutan pengurutan ke descending (desc). Pada versi tersebut, jika urutan pengurutan diatur ke descending, Clustering Key tidak akan terpakai, sehingga mengakibatkan performa kueri yang buruk. Mulai dari V2.1, Anda dapat mengatur Clustering Key ke desc setelah mengaktifkan parameter GUC tertentu. Namun, fitur ini hanya didukung untuk field dengan tipe data seperti Text, Char, Varchar, Bytea, dan Int. Pengaturan Clustering Key ke desc belum didukung untuk field dengan tipe data lainnya.
```
set hg_experimental_optimizer_enable_variable_length_desc_ck_filter = on;
```
Untuk tabel berorientasi baris (row-oriented table), clustering key secara default adalah primary key. Pada versi Hologres sebelum V0.9, tidak ada clustering key yang ditetapkan secara default. Jika Anda menentukan clustering key yang berbeda dari primary key, Hologres akan membuat dua salinan data yang diurutkan—satu untuk primary key dan satu lagi untuk clustering key. Hal ini menyebabkan redundansi data.

Batasan

Untuk memodifikasi clustering key, Anda harus membuat tabel baru dan mengimpor data.
Kolom yang ditentukan dalam clustering key harus bersifat NOT NULL. Versi Hologres dari V1.3.20 hingga V1.3.27 mendukung kolom nullable dalam clustering key, tetapi dukungan ini dihentikan mulai dari V1.3.28. Clustering key yang nullable dapat memengaruhi kebenaran data. Jika bisnis Anda memerlukan clustering key yang nullable, Anda dapat mengaktifkannya dengan menjalankan perintah berikut sebelum pernyataan SQL Anda.
```
set hg_experimental_enable_nullable_clustering_key = true;
```
Kolom dengan tipe data berikut tidak dapat digunakan dalam clustering key: Float, Float4, Float8, Double, Decimal(Numeric), Json, Jsonb, Bit, Varbit, Money, dan Time With Time Zone, atau tipe data kompleks lainnya.
Pada versi Hologres sebelum V2.1, Anda tidak dapat mengatur urutan pengurutan indeks ke descending (desc). Jika urutan pengurutan diatur ke descending, clustering key tidak akan terpakai, sehingga mengakibatkan performa kueri yang buruk. Mulai dari V2.1, Anda dapat mengaktifkan GUC berikut untuk mengatur clustering key ke desc. Namun, fitur ini hanya didukung untuk field dengan tipe data seperti Text, Char, Varchar, Bytea, dan Int. Anda tidak dapat mengatur clustering key ke desc untuk field dengan tipe data lainnya.
```
set hg_experimental_optimizer_enable_variable_length_desc_ck_filter = on;
```
Untuk tabel berorientasi kolom (column-oriented table), tidak ada clustering key yang ditentukan secara default. Anda harus secara eksplisit menentukannya sesuai kasus penggunaan Anda.

Di Hologres, Anda hanya dapat menetapkan satu clustering key untuk setiap tabel. Artinya, saat membuat tabel, Anda hanya dapat menjalankan perintah call satu kali, bukan beberapa kali. Contohnya:

Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

-- Penggunaan yang benar
CREATE TABLE tbl (
    a int NOT NULL,
    b text NOT NULL
)
WITH (
    clustering_key = 'a,b'
);
-- Penggunaan yang salah
CREATE TABLE tbl (
    a int NOT NULL,
    b text NOT NULL
)
WITH (
    clustering_key = 'a',
    clustering_key = 'b'
);

Sintaks yang didukung oleh semua versi:

-- Penggunaan yang benar
BEGIN;
CREATE TABLE tbl (a int NOT NULL, b text NOT NULL);
CALL set_table_property('tbl', 'clustering_key', 'a,b');
COMMIT;
-- Penggunaan yang salah
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;

Cara kerja

Clustering key mengurutkan data secara fisik dalam file. Secara default, data diurutkan dalam urutan ascending (asc). Bagian berikut menjelaskan konsep tata letak logis dan fisik untuk clustering key.

Tata letak logis

Kueri yang menggunakan clustering key mengikuti prinsip pencocokan paling kiri. Jika kondisi filter kueri tidak sesuai dengan awalan (prefix) kolom clustering key, clustering key tidak dapat mempercepat kueri tersebut. Contoh berikut mengilustrasikan tata letak logis clustering key di Hologres.
Asumsikan Anda memiliki tabel dengan kolom Name, Date, dan Class.
- Jika Anda menetapkan clustering key ke (Date), data dalam tabel diurutkan berdasarkan kolom Date.
- Jika Anda menetapkan clustering key ke (Class, Date), data diurutkan terlebih dahulu berdasarkan kolom Class, lalu berdasarkan kolom Date dalam setiap class.
Pilihan kolom clustering key menentukan tata letak akhir data yang diurutkan.
Tata letak penyimpanan fisik

Tata letak penyimpanan fisik clustering key mengelompokkan data yang terkait secara bersamaan.

Prinsip tata letak ini memiliki implikasi berikut:

Clustering key sangat cocok untuk filter rentang. Misalnya, kueri dengan kondisi seperti WHERE date = '1/1' atau WHERE a > '1/1' AND a < '1/5' dipercepat secara signifikan.
Kueri mengikuti prinsip pencocokan paling kiri. Misalnya, jika clustering key didefinisikan pada kolom (a,b,c), kueri dapat dipercepat jika melakukan filter pada (a,b,c) atau (a,b). Jika kueri melakukan filter pada (a,c), hanya kondisi pada a yang dapat menggunakan clustering key. Jika kueri melakukan filter pada (b,c), clustering key tidak dapat digunakan sama sekali.

Pada contoh berikut, kolom uid,class,date membentuk clustering key.

Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

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');

Sintaks yang didukung oleh semua versi:

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');

Kueri hanya pada kolom uid memanfaatkan clustering key.

SELECT * FROM clustering_test WHERE uid > '3';

Dengan memeriksa rencana eksekusi menggunakan pernyataan EXPLAIN, Anda akan melihat operator Cluster Filter. Ini menunjukkan bahwa pengoptimal (optimizer) menggunakan clustering key untuk mempercepat kueri.

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

Kueri pada kolom uid,class memanfaatkan clustering key.

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

Rencana eksekusi menunjukkan operator Cluster Filter, yang menunjukkan bahwa pengoptimal menggunakan clustering key untuk mempercepat kueri.

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

Kueri pada kolom uid,class,date memanfaatkan clustering key.
```
SELECT * FROM clustering_test WHERE uid = '3' AND class ='2' AND date > '2022-10-17';
```
Dengan memeriksa rencana eksekusi, Anda dapat melihat operator Cluster Filter, yang menunjukkan bahwa clustering key dimanfaatkan dan kueri dipercepat. Hasil rencana eksekusi menunjukkan bahwa Index Scan using holo_index:[1] on clustering_test digunakan dan kondisi Cluster Filter adalah ((uid = 3) AND (class = '2'::text) AND (date > '2022-10-17'::text)). Hal ini mengonfirmasi bahwa clustering key digunakan dengan benar.

Kueri pada kolom uid,date tidak mengikuti prinsip pencocokan paling kiri. Oleh karena itu, hanya uid yang dapat memanfaatkan Clustering Key, sedangkan date diproses menggunakan filter biasa.

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

Dengan melihat rencana eksekusi (EXPLAIN SQL), Anda dapat melihat bahwa dalam rencana berikut, hanya kolom uid yang memiliki operator 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

Kueri hanya pada kolom class,date tidak mengikuti prinsip pencocokan paling kiri. Kueri ini tidak dapat memanfaatkan clustering key.
```
SELECT * FROM clustering_test WHERE class ='2' AND date > '2022-10-17';
```
Tidak adanya operator Cluster Filter dalam rencana eksekusi (dari EXPLAIN SQL) menunjukkan bahwa Clustering Key tidak digunakan. Setelah menjalankan EXPLAIN, rencana kueri menunjukkan Index Scan di mana kolom date menggunakan Filter dan kolom class menggunakan Bitmap Filter, yang keduanya tidak dipercepat oleh Clustering Key.

Contoh

Contoh 1: Skenario di mana kueri dapat memanfaatkan clustering key.

Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

CREATE TABLE table1 (
    col1 int NOT NULL,
    col2 text NOT NULL,
    col3 text NOT NULL,
    col4 text NOT NULL
)
WITH (
    clustering_key = 'col1,col2'
);
-- Untuk tabel yang dibuat di atas, kueri berikut dapat dipercepat.
-- Kueri ini dapat dipercepat.
select * from table1 where col1='abc';
-- Kueri ini dapat dipercepat.
select * from table1 where col1>'xxx' and col1<'abc';
-- Kueri ini dapat dipercepat.
select * from table1 where col1 in ('abc','def');
-- Kueri ini dapat dipercepat.
select * from table1 where col1='abc' and col2='def'; 
-- Kueri ini tidak dapat dipercepat.
select col1,col4 from table1 where col2='def';

Sintaks yang didukung oleh semua versi:

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;
-- Untuk tabel yang dibuat di atas, kueri berikut dapat dipercepat.
-- Kueri ini dapat dipercepat.
select * from table1 where col1='abc';
-- Kueri ini dapat dipercepat.
select * from table1 where col1>'xxx' and col1<'abc';
-- Kueri ini dapat dipercepat.
select * from table1 where col1 in ('abc','def');
-- Kueri ini dapat dipercepat.
select * from table1 where col1='abc' and col2='def';
-- Kueri ini tidak dapat dipercepat.
select col1,col4 from table1 where col2='def';

Contoh 2: Clustering Key diatur ke asc/desc.

Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

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

Sintaks yang didukung oleh semua versi:

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

Tuning lanjutan

Berbeda dengan clustering key di database tradisional seperti MySQL atau SQL Server, pengurutan di Hologres hanya dilakukan dalam file, bukan di seluruh tabel. Oleh karena itu, menjalankan operasi ORDER BY pada Clustering Key tetap memiliki biaya performa.

Mulai dari V1.3, Hologres memperkenalkan optimasi performa signifikan untuk kasus penggunaan clustering key. Optimasi ini memberikan performa lebih baik dalam dua skenario berikut. Jika instans Hologres Anda menggunakan versi sebelum 1.3, lihat Pemecahan Masalah: Error persiapan upgrade atau hubungi kami untuk dukungan dengan mengikuti petunjuk di Cara mendapatkan dukungan online?.

Gunakan ORDER BY pada clustering key

Di Hologres, data dalam file diurutkan sesuai dengan clustering key yang ditentukan. Pada versi sebelum V1.3, pengoptimal tidak dapat menggunakan properti terurut clustering key untuk menghasilkan rencana eksekusi optimal. Selain itu, urutan data tidak dapat dijamin setelah melewati node shuffle karena penggabungan multi-arah (multi-way merging). Hal ini sering menyebabkan beban komputasi lebih tinggi dan waktu kueri lebih lama. Hologres V1.3 mengoptimalkan proses ini. Pengoptimal kini dapat menghasilkan rencana eksekusi yang memanfaatkan properti terurut clustering key dan mempertahankan urutan data di seluruh shuffle, sehingga meningkatkan performa kueri. Namun, perhatikan poin berikut:

Jika kueri tidak melakukan filter pada clustering key tabel, secara default akan menggunakan SeqScan alih-alih IndexScan. Hanya IndexScan yang memanfaatkan properti terurut clustering key.
Pengoptimal tidak selalu memilih rencana eksekusi yang bergantung pada urutan pengurutan clustering key, karena pendekatan ini memiliki overhead tertentu. Misalnya, data yang diurutkan dalam file mungkin tetap memerlukan pengurutan tambahan di memori.

Contoh:

Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

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;

Sintaks yang didukung oleh semua versi:

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;

Pernyataan kueri:

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

Perbandingan rencana eksekusi

Kode berikut menunjukkan rencana eksekusi pada versi sebelum V1.3, seperti V1.1. Anda dapat melihat rencana tersebut dengan menjalankan pernyataan 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)

Kode berikut menunjukkan rencana eksekusi pada 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)

Rencana eksekusi untuk V1.3 lebih efisien. Rencana ini memanfaatkan properti terurut clustering key untuk langsung menggabungkan output. Hal ini menciptakan eksekusi berpipa (pipelined) dan mencegah operasi pengurutan lambat saat bekerja dengan dataset besar. Seperti yang ditunjukkan dalam perbandingan, rencana V1.3 mengganti operator Sort dengan Merge Key, yang menunjukkan proses penggabungan berbasis merge yang lebih efisien.

Gunakan JOIN pada clustering key (Beta)

Hologres V1.3 memperkenalkan operator Merge Join, yang memungkinkan pengoptimal memanfaatkan sifat terurut clustering key, mengurangi beban komputasi, dan meningkatkan performa. Namun, perhatikan poin berikut:

Fitur ini masih dalam tahap beta dan dinonaktifkan secara default. Untuk menggunakannya, Anda harus mengaktifkan parameter berikut sebelum menjalankan kueri Anda.
```
-- Aktifkan merge join
set hg_experimental_enable_sort_merge_join=on;
```
Jika kueri tidak melakukan filter pada clustering key tabel, secara default akan menggunakan SeqScan alih-alih IndexScan. Hanya IndexScan yang memanfaatkan properti terurut clustering key.
Pengoptimal tidak selalu menghasilkan rencana eksekusi berdasarkan urutan terurut clustering key karena penggunaan properti ini memiliki biaya tertentu. Misalnya, data yang diurutkan dalam file mungkin tetap memerlukan pengurutan tambahan di memori.

Contoh:

Sintaks yang didukung oleh Hologres V2.1 dan versi lebih baru:

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;

Sintaks yang didukung oleh semua versi:

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;

Pernyataan kueri:

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;

Perbandingan rencana eksekusi

Kode berikut menunjukkan rencana eksekusi pada versi sebelum V1.3, seperti 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))

Kode berikut menunjukkan rencana eksekusi pada 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))

Rencana V1.3 menggunakan Merge Join dengan memanfaatkan sifat terurut clustering key. Rencana ini melakukan sort-merge dalam setiap shard sebelum join, menciptakan pipeline yang efisien. Pendekatan ini menghindari potensi error kehabisan memori (OOM) yang dapat terjadi dengan Hash Join ketika salah satu sisi join terlalu besar untuk muat di memori.

Dokumentasi terkait

Untuk informasi lebih lanjut tentang pernyataan Data Definition Language (DDL) untuk tabel internal Hologres, lihat topik berikut: