Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris. # Mengoptimalkan kinerja kueri di Aurora PostgreSQL Mengoptimalkan kinerja kueri sangat penting karena membantu database berjalan lebih cepat dan lebih efisien saat menggunakan lebih sedikit sumber daya, yang menghasilkan pengalaman pengguna yang lebih baik dan biaya operasi yang lebih rendah. Amazon Aurora PostgreSQL menyediakan beberapa fitur untuk membantu mengoptimalkan kinerja kueri untuk beban kerja PostgreSQL. **Topics** + [Meningkatkan performa kueri untuk Aurora PostgreSQL dengan Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md) + [Mengoptimalkan subkueri berkorelasi di Aurora PostgreSQL](apg-correlated-subquery.md) + [Meningkatkan kinerja kueri menggunakan gabungan adaptif](user-apg-adaptive-join.md) + [Menggunakan cache paket bersama](apg-shared-plan-cache.md) # Meningkatkan performa kueri untuk Aurora PostgreSQL dengan Aurora Optimized Reads Anda dapat mencapai pemrosesan kueri yang lebih cepat untuk Aurora PostgreSQL dengan Aurora Optimized Reads. Instans DB Aurora PostgreSQL yang menggunakan Aurora Optimized Reads memberikan latensi kueri hingga 8x lebih baik dan penghematan biaya hingga 30% untuk aplikasi dengan set data besar, yang melebihi kapasitas memori instans DB. **Topics** + [Gambaran umum Aurora Optimized Reads di PostgreSQL](#AuroraPostgreSQL.optimized.reads.overview) + [Menggunakan Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.using) + [Kasus penggunaan untuk Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.usecases) + [Memantau instans DB yang menggunakan Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.monitoring) + [Praktik terbaik untuk Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.bestpractices) ## Gambaran umum Aurora Optimized Reads di PostgreSQL Bacaan yang Dioptimalkan Aurora tersedia secara default saat Anda membuat cluster DB yang menggunakan instans R6gd, R8gd, dan R6id berbasis Intel berbasis Graviton dengan penyimpanan memori express () non-volatile. NVMe Fitur ini tersedia dari versi PostgreSQL berikut: + 14.12 dan versi yang lebih tinggi, 15.7 dan versi yang lebih tinggi, 16.3 dan versi yang lebih tinggi, 17.4 dan versi yang lebih tinggi untuk instans R8gd + 14.9 dan versi yang lebih tinggi, 15.4 dan versi yang lebih tinggi, 16.1 dan semua versi yang lebih tinggi untuk instans R6gd dan R6id Aurora Optimized Reads mendukung dua kemampuan: cache berjenjang dan objek sementara. **Cache berjenjang yang didukung Optimized Reads** - Menggunakan cache berjenjang, Anda dapat memperluas kapasitas caching instans DB hingga 5x memori instans. Kemampuan ini secara otomatis mempertahankan cache untuk menyimpan data terbaru yang konsisten secara transaksional, sehingga membebaskan aplikasi dari overhead dalam mengelola keterkinian data dalam solusi caching berbasis hasil set eksternal. Kemampuan ini menawarkan latensi hingga 8x lebih baik untuk kueri yang sebelumnya mengambil data dari penyimpanan Aurora. Di Aurora, nilai untuk `shared_buffers` dalam kelompok parameter default biasanya diatur ke sekitar 75% dari memori yang tersedia. Namun, untuk jenis instans r8gd, r6gd, dan r6id, Aurora mengurangi `shared_buffers` ruang sebesar 4,5% untuk meng-host metadata untuk cache Bacaan yang Dioptimalkan. **Objek sementara yang diaktifkan Bacaan yang dioptimalkan** - Menggunakan objek sementara, Anda dapat mencapai pemrosesan kueri yang lebih cepat dengan menempatkan file sementara yang dihasilkan oleh PostgreSQL di penyimpanan lokal. NVMe Kemampuan ini mengurangi lalu lintas ke Elastic Block Storage (EBS) melalui jaringan. Ini menawarkan latensi dan throughput hingga 2x lebih baik untuk kueri lanjutan yang mengurutkan, menggabungkan, atau menggabungkan volume data besar yang tidak sesuai dengan kapasitas memori yang tersedia pada instans DB. Pada cluster Aurora I/O-Optimized, Optimized Reads menggunakan cache berjenjang dan objek sementara pada penyimpanan. NVMe Dengan kemampuan cache berjenjang yang didukung Optimized Reads, Aurora mengalokasikan 2x memori instans untuk objek sementara, sekitar 10% penyimpanan untuk operasi internal, dan penyimpanan yang tersisa sebagai cache berjenjang. Pada klaster Standar Aurora, Optimized Reads hanya menggunakan objek sementara. Cluster Aurora I/O-Optimized memungkinkan Anda mengubah ukuran ruang yang dialokasikan untuk objek sementara yang diaktifkan Bacaan yang Dioptimalkan menggunakan parameter dinamis pada tingkat instans. `aurora_temp_space_size` Fitur pengubahan ukuran ini tersedia dari versi PostgreSQL berikut: + 16.8 dan semua versi yang lebih tinggi + 15.12 dan versi 15 yang lebih tinggi + 14.17 dan versi 14 yang lebih tinggi Dengan parameter ini, Anda dapat mengubah ukuran kapasitas dari 2x hingga 6x memori instans tanpa memerlukan restart mesin database. Saat Anda memperluas ruang objek sementara, perubahan akan segera berlaku, terlepas dari beban kerja bersamaan. Namun, ketika Anda mengurangi ruang, penyesuaian selesai hanya setelah ada cukup ruang yang tidak terpakai di objek sementara untuk mengakomodasi permintaan ukuran baru. Setelah Anda mengubah ukuran objek sementara yang diaktifkan Bacaan yang Dioptimalkan, cache berjenjang secara otomatis menyesuaikan untuk menggunakan ruang yang tersedia. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html) **catatan** Peralihan antara cluster yang dioptimalkan oleh iOS dan standar pada kelas instans DB NVMe berbasis menyebabkan restart mesin database langsung. Di Aurora PostgreSQL, gunakan `temp_tablespaces` parameter untuk mengkonfigurasi ruang tabel tempat objek sementara disimpan. Untuk memeriksa apakah objek sementara dikonfigurasi, gunakan perintah berikut: ``` postgres=> show temp_tablespaces; temp_tablespaces --------------------- aurora_temp_tablespace (1 row) ``` `aurora_temp_tablespace`Ini adalah tablespace yang dikonfigurasi oleh Aurora yang menunjuk ke penyimpanan lokal NVMe . Anda tidak dapat mengubah parameter ini atau beralih kembali ke penyimpanan Amazon EBS. Untuk memeriksa apakah cache baca yang dioptimalkan diaktifkan, gunakan perintah berikut: ``` postgres=> show shared_preload_libraries; shared_preload_libraries -------------------------------------------------------- rdsutils,pg_stat_statements,aurora_optimized_reads_cache ``` ## Menggunakan Aurora Optimized Reads Saat Anda menyediakan instans Aurora PostgreSQL DB dengan salah satu instans DB NVMe berbasis, instans DB secara otomatis menggunakan Aurora Optimized Reads. Untuk mengaktifkan Aurora Optimized Reads, lakukan salah satu hal berikut ini: + Buat cluster DB PostgreSQL Aurora menggunakan salah satu kelas instance DB berbasis. NVMe Untuk informasi selengkapnya, lihat [Membuat klaster DB Amazon Aurora](Aurora.CreateInstance.md). + Ubah cluster Aurora PostgreSQL DB yang ada untuk menggunakan salah satu kelas instance DB berbasis. NVMe Untuk informasi selengkapnya, lihat [Memodifikasi klaster DB Amazon Aurora](Aurora.Modifying.md). Bacaan yang Dioptimalkan Aurora tersedia di semua Wilayah AWS tempat di mana satu atau lebih kelas instans DB dengan penyimpanan NVMe SSD lokal didukung. Untuk informasi selengkapnya, lihat [Kelas instans Amazon Aurora DB](Concepts.DBInstanceClass.md). Untuk beralih kembali ke instance Aurora pembacaan yang tidak dioptimalkan, ubah kelas instans DB dari instance Aurora Anda ke kelas instance serupa NVMe tanpa penyimpanan sementara untuk beban kerja database Anda. Misalnya, jika kelas instans DB saat ini adalah db.r6gd.4xlarge, pilih db.r6g.4xlarge untuk beralih kembali. Untuk informasi selengkapnya, lihat [Memodifikasi instans Aurora DB](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html). ## Kasus penggunaan untuk Aurora Optimized Reads **Cache berjenjang yang didukung Optimized Reads** Berikut ini adalah beberapa kasus penggunaan yang dapat memperoleh manfaat dari Optimized Reads dengan cache berjenjang: + Aplikasi skala internet seperti pemrosesan pembayaran, penagihan, e-commerce dengan kinerja SLAs yang ketat. + Dasbor pelaporan waktu nyata yang menjalankan ratusan kueri titik untuk metrics/data dikumpulkan. + Aplikasi AI generatif dengan ekstensi pgvector untuk mencari neighbor yang tepat atau terdekat dalam jutaan penyematan vektor. **Objek sementara yang didukung Optimized Reads** Berikut ini adalah beberapa kasus penggunaan yang dapat memperoleh manfaat dari Optimized Reads dengan objek sementara: + Kueri analitis yang mencakup Ekspresi Tabel Umum (CTEs), tabel turunan, dan operasi pengelompokan. + Replika baca yang menangani kueri yang tidak dioptimalkan untuk aplikasi. + Kueri pelaporan sesuai permintaan atau dinamis dengan operasi kompleks seperti GROUP BY dan ORDER BY yang tidak selalu dapat menggunakan indeks yang sesuai. + `CREATE INDEX`atau `REINDEX` operasi untuk menyortir. + Beban kerja lain yang menggunakan tabel sementara internal. ## Memantau instans DB yang menggunakan Aurora Optimized Reads Anda dapat memantau kueri yang menggunakan cache berjenjang yang didukung Optimized Reads dengan perintah EXPLAIN seperti yang ditunjukkan pada contoh berikut: ``` Postgres=> EXPLAIN (ANALYZE, BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000 QUERY PLAN -------------------------------------------------------------------------------------- Index Scan using sbtest15_pkey on sbtest15 (cost=0.57..8.59 rows=1 width=121) (actual time=0.287..0.288 rows=1 loops=1) Index Cond: (id = 100000000) Buffers: shared hit=3 read=2 aurora_orcache_hit=2 I/O Timings: shared/local read=0.264 Planning: Buffers: shared hit=33 read=6 aurora_orcache_hit=6 I/O Timings: shared/local read=0.607 Planning Time: 0.929 ms Execution Time: 0.303 ms (9 rows) Time: 2.028 ms ``` **catatan** `aurora_orcache_hit`dan `aurora_storage_read` bidang di `Buffers` bagian rencana penjelasan hanya ditampilkan ketika Pembacaan yang Dioptimalkan diaktifkan dan nilainya lebih besar dari nol. Bidang baca adalah total `aurora_storage_read` bidang `aurora_orcache_hit` dan. Anda dapat memantau instans DB yang menggunakan Bacaan yang Dioptimalkan Aurora menggunakan metrik berikut CloudWatch: + `AuroraOptimizedReadsCacheHitRatio` + `FreeEphemeralStorage` + `ReadIOPSEphemeralStorage` + `ReadLatencyEphemeralStorage` + `ReadThroughputEphemeralStorage` + `WriteIOPSEphemeralStorage` + `WriteLatencyEphemeralStorage` + `WriteThroughputEphemeralStorage` Metrik ini menyediakan data tentang penyimpanan instans, IOPS, dan throughput yang tersedia. Untuk informasi selengkapnya tentang metrik ini, lihat [Metrik tingkat instans untuk Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). Anda juga dapat menggunakan `pg_proctab` ekstensi untuk memantau NVMe penyimpanan. ``` postgres=>select * from pg_diskusage(); major | minor | devname | reads_completed | reads_merged | sectors_read | readtime | writes_completed | writes_merged | sectors_written | writetime | current_io | iotime | totaliotime ------+-------+---------------------+-----------------+--------------+--------------+----------+------------------+---------------+-----------------+-----------+------------+---------+------------- | | rdstemp | 23264 | 0 | 191450 | 11670 | 1750892 | 0 | 24540576 | 819350 | 0 | 3847580 | 831020 | | rdsephemeralstorage | 23271 | 0 | 193098 | 2620 | 114961 | 0 | 13845120 | 130770 | 0 | 215010 | 133410 (2 rows) ``` ## Praktik terbaik untuk Aurora Optimized Reads Gunakan praktik terbaik berikut untuk Aurora Optimized Reads: + Pantau ruang penyimpanan yang tersedia di penyimpanan instans dengan CloudWatch metrik`FreeEphemeralStorage`. Jika penyimpanan instance mencapai batasnya karena beban kerja pada instans DB, atur konkurensi dan kueri yang banyak menggunakan objek sementara atau memodifikasinya untuk menggunakan kelas instans DB yang lebih besar. + Pantau CloudWatch metrik untuk hit rate cache Optimized Reads. Operasi seperti VACUUM akan memodifikasi sejumlah besar blok dengan sangat cepat. Hal ini dapat menyebabkan penurunan sementara dalam rasio hit. Ekstensi `pg_prewarm` dapat digunakan untuk memuat data ke dalam cache buffer yang memungkinkan Aurora secara proaktif menulis beberapa blok tersebut ke cache Optimized Reads. + Anda dapat mengaktifkan manajemen cache klaster (CCM) untuk melakukan "warm up" cache buffer dan cache berjenjang pada pembaca tingkat 0, yang akan digunakan sebagai target failover. Ketika CCM diaktifkan, cache buffer dipindai secara berkala untuk menulis halaman yang memenuhi syarat untuk pengosongan dalam cache berjenjang. Untuk informasi selengkapnya tentang CCM, lihat [Pemulihan cepat setelah failover dengan manajemen cache klaster untuk Aurora PostgreSQL](AuroraPostgreSQL.cluster-cache-mgmt.md). # Mengoptimalkan subkueri berkorelasi di Aurora PostgreSQL Sebuah kolom tabel referensi subquery berkorelasi dari kueri luar. Ini dievaluasi sekali untuk setiap baris yang dikembalikan oleh kueri luar. Dalam contoh berikut, subquery referensi kolom dari tabel ot. Tabel ini tidak termasuk dalam klausa FROM subquery, tetapi direferensikan dalam klausa FROM kueri luar. Jika tabel ot memiliki 1 juta baris, subquery perlu dievaluasi 1 juta kali. ``` SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); ``` **catatan** Transformasi subquery dan cache subquery tersedia di Aurora PostgreSQL dimulai dengan versi 16.8, sedangkan Babelfish untuk Aurora PostgreSQL mendukung fitur ini dari 4.2.0. Dimulai dengan Babelfish untuk Aurora PostgreSQL versi 4.6.0 dan 5.2.0, parameter berikut mengontrol fitur-fitur ini: babelfishpg\$1tsql.apg\$1enable\$1correlated\$1scalar\$1transform babelfishpg\$1tsql.apg\$1enable\$1subquery\$1cache Secara default, kedua parameter dihidupkan. ## Meningkatkan kinerja kueri PostgreSQL Aurora menggunakan transformasi subquery Aurora PostgreSQL dapat mempercepat subquery yang berkorelasi dengan mengubahnya menjadi gabungan luar yang setara. Optimalisasi ini berlaku untuk dua jenis subkueri berkorelasi berikut: + Subquery yang mengembalikan nilai agregat tunggal dan muncul dalam daftar SELECT. ``` SELECT ot.a, ot.b, (SELECT AVG(it.b) FROM it WHERE it.a = ot.a) FROM ot; ``` + Subquery yang mengembalikan nilai agregat tunggal dan muncul dalam klausa WHERE. ``` SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); ``` ### Mengaktifkan transformasi dalam subquery Untuk mengaktifkan transformasi subkueri yang berkorelasi menjadi gabungan luar yang setara, atur parameternya ke. `apg_enable_correlated_scalar_transform` `ON` Nilai default dari parameter ini adalah`OFF`. Anda dapat memodifikasi kelompok parameter cluster atau instance untuk mengatur parameter. Untuk mempelajari selengkapnya, lihat [](USER_WorkingWithParamGroups.md). Atau, Anda dapat mengonfigurasi pengaturan hanya untuk sesi saat ini dengan perintah berikut: ``` SET apg_enable_correlated_scalar_transform TO ON; ``` ### Memverifikasi transformasi Gunakan perintah EXPLORE untuk memverifikasi apakah subquery yang berkorelasi telah diubah menjadi gabungan luar dalam rencana kueri. Ketika transformasi diaktifkan, bagian subquery berkorelasi yang berlaku akan diubah menjadi gabungan luar. Contoh: ``` postgres=> CREATE TABLE ot (a INT, b INT); CREATE TABLE postgres=> CREATE TABLE it (a INT, b INT); CREATE TABLE postgres=> SET apg_enable_correlated_scalar_transform TO ON; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); QUERY PLAN -------------------------------------------------------------- Hash Join Hash Cond: (ot.a = apg_scalar_subquery.scalar_output) Join Filter: ((ot.b)::numeric < apg_scalar_subquery.avg) -> Seq Scan on ot -> Hash -> Subquery Scan on apg_scalar_subquery -> HashAggregate Group Key: it.a -> Seq Scan on it ``` Kueri yang sama tidak diubah ketika parameter GUC diputar`OFF`. Rencana tidak akan memiliki gabungan luar tetapi subplan sebagai gantinya. ``` postgres=> SET apg_enable_correlated_scalar_transform TO OFF; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT AVG(it.b) FROM it WHERE it.a = ot.a); QUERY PLAN ---------------------------------------- Seq Scan on ot Filter: ((b)::numeric < (SubPlan 1)) SubPlan 1 -> Aggregate -> Seq Scan on it Filter: (a = ot.a) ``` ### Batasan + Subquery harus dalam daftar SELECT atau dalam salah satu kondisi dalam klausa where. Jika tidak, itu tidak akan diubah. + Subquery harus mengembalikan fungsi agregat. Fungsi agregat yang ditentukan pengguna tidak didukung untuk transformasi. + Subquery yang ekspresi pengembaliannya bukan fungsi agregat sederhana tidak akan diubah. + Kondisi berkorelasi dalam klausa WHERE subquery harus menjadi referensi kolom sederhana. Jika tidak, itu tidak akan diubah. + Kondisi berkorelasi dalam subquery di mana klausa harus berupa predikat kesetaraan biasa. + Subquery tidak dapat berisi klausa HAVING atau GROUP BY. + Klausa where dalam subquery mungkin berisi satu atau lebih predikat yang dikombinasikan dengan AND. **catatan** Dampak kinerja transformasi bervariasi tergantung pada skema, data, dan beban kerja Anda. Eksekusi subquery yang berkorelasi dengan transformasi dapat secara signifikan meningkatkan kinerja karena jumlah baris yang dihasilkan oleh kueri luar meningkat. Kami sangat menyarankan Anda menguji fitur ini di lingkungan non-produksi dengan skema, data, dan beban kerja Anda yang sebenarnya sebelum mengaktifkannya di lingkungan produksi. ## Menggunakan cache subquery untuk meningkatkan kinerja kueri PostgreSQL Aurora Aurora PostgreSQL mendukung cache subquery untuk menyimpan hasil subquery berkorelasi. Fitur ini melewatkan eksekusi subquery berkorelasi berulang saat hasil subquery sudah ada di cache. ### Memahami cache subquery Node Memoize PostgreSQL adalah bagian penting dari cache subquery. Node Memoize mempertahankan tabel hash di cache lokal untuk memetakan dari nilai parameter input ke baris hasil kueri. Batas memori untuk tabel hash adalah produk dari work\$1mem dan hash\$1mem\$1multiplier. Untuk mempelajari lebih lanjut, lihat [Konsumsi Sumber Daya](https://www.postgresql.org/docs/16/runtime-config-resource.html). Selama eksekusi kueri, cache subquery menggunakan Cache Hit Rate (CHR) untuk memperkirakan apakah cache meningkatkan kinerja kueri dan untuk memutuskan pada runtime kueri apakah akan terus menggunakan cache. CHR adalah rasio jumlah klik cache dengan jumlah total permintaan. Misalnya, jika subquery yang berkorelasi perlu dieksekusi 100 kali, dan 70 dari hasil eksekusi tersebut dapat diambil dari cache, CHR adalah 0,7. Untuk setiap jumlah cache apg\$1subquery\$1cache\$1check\$1interval yang hilang, manfaat cache subquery dievaluasi dengan memeriksa apakah CHR lebih besar dari apg\$1subquery\$1cache\$1hit\$1rate\$1threshold. Jika tidak, cache akan dihapus dari memori, dan eksekusi kueri akan kembali ke eksekusi ulang subquery asli yang tidak di-cache. ### Parameter yang mengontrol perilaku cache subquery Tabel berikut mencantumkan parameter yang mengontrol perilaku cache subquery. | Parameter | Deskripsi | Default | Diizinkan | | --- | --- | --- | --- | | apg\$1enable\$1subquery\$1cache | Mengaktifkan penggunaan cache untuk subquery skalar berkorelasi. | MATI | ON, OFF | | apg\$1subquery\$1cache\$1check\$1interval | Menetapkan frekuensi, dalam jumlah kesalahan cache, untuk mengevaluasi tingkat hit cache subquery. | 500 | 0–2147483647 | | apg\$1subquery\$1cache\$1hit\$1rate\$1threshold | Menetapkan ambang batas untuk hit rate cache subquery. | 0,3 | 0,0—1,0 | **catatan** Nilai yang lebih besar `apg_subquery_cache_check_interval` dapat meningkatkan akurasi estimasi manfaat cache berbasis ChR, tetapi akan meningkatkan overhead cache, karena CHR tidak akan dievaluasi hingga tabel cache memiliki baris. `apg_subquery_cache_check_interval` Nilai `apg_subquery_cache_hit_rate_threshold` bias yang lebih besar untuk meninggalkan cache subquery dan kembali ke eksekusi ulang subquery asli yang tidak di-cache. Anda dapat memodifikasi kelompok parameter cluster atau instance untuk mengatur parameter. Untuk mempelajari selengkapnya, lihat [](USER_WorkingWithParamGroups.md). Atau, Anda dapat mengonfigurasi pengaturan hanya untuk sesi saat ini dengan perintah berikut: ``` SET apg_enable_subquery_cache TO ON; ``` ### Mengaktifkan cache subquery di Aurora PostgreSQL Ketika cache subquery diaktifkan, Aurora PostgreSQL menerapkan cache untuk menyimpan hasil subquery. Rencana kueri kemudian akan memiliki node Memoize di bawah SubPlan. Misalnya, urutan perintah berikut menunjukkan perkiraan rencana eksekusi kueri dari subquery berkorelasi sederhana tanpa cache subquery. ``` postgres=> SET apg_enable_subquery_cache TO OFF; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ------------------------------------ Seq Scan on ot Filter: (b < (SubPlan 1)) SubPlan 1 -> Seq Scan on it Filter: (a = ot.a) ``` Setelah dihidupkan`apg_enable_subquery_cache`, rencana kueri akan berisi node Memoize di bawah SubPlan node, yang menunjukkan bahwa subquery berencana untuk menggunakan cache. ``` postgres=> SET apg_enable_subquery_cache TO ON; SET postgres=> EXPLAIN (COSTS FALSE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ------------------------------------ Seq Scan on ot Filter: (b < (SubPlan 1)) SubPlan 1 -> Memoize Cache Key: ot.a Cache Mode: binary -> Seq Scan on it Filter: (a = ot.a) ``` Rencana eksekusi kueri yang sebenarnya berisi rincian lebih lanjut dari cache subquery, termasuk klik cache dan kesalahan cache. Output berikut menunjukkan rencana eksekusi query aktual dari contoh query di atas setelah memasukkan beberapa nilai ke tabel. ``` postgres=> EXPLAIN (COSTS FALSE, TIMING FALSE, ANALYZE TRUE) SELECT ot.a, ot.b FROM ot WHERE ot.b < (SELECT it.b FROM it WHERE it.a = ot.a); QUERY PLAN ----------------------------------------------------------------------------- Seq Scan on ot (actual rows=2 loops=1) Filter: (b < (SubPlan 1)) Rows Removed by Filter: 8 SubPlan 1 -> Memoize (actual rows=0 loops=10) Cache Key: ot.a Cache Mode: binary Hits: 4 Misses: 6 Evictions: 0 Overflows: 0 Memory Usage: 1kB -> Seq Scan on it (actual rows=0 loops=6) Filter: (a = ot.a) Rows Removed by Filter: 4 ``` Total nomor hit cache adalah 4, dan total nomor cache miss adalah 6. Jika jumlah total hit dan misses kurang dari jumlah loop di node Memoize, itu berarti evaluasi CHR tidak lulus dan cache dibersihkan dan ditinggalkan di beberapa titik. Eksekusi subquery kemudian kembali ke eksekusi ulang asli yang tidak di-cache. ### Batasan Cache subquery tidak mendukung pola tertentu dari subquery yang berkorelasi. Jenis kueri tersebut akan dijalankan tanpa cache, bahkan jika cache subquery diaktifkan: + IN/EXISTS/ANY/ALLsubquery berkorelasi + Subquery berkorelasi yang berisi fungsi nondeterministik. + Subkueri berkorelasi yang mereferensikan kolom tabel luar dengan tipe data yang tidak mendukung operasi hashing atau kesetaraan. # Meningkatkan kinerja kueri menggunakan gabungan adaptif ## Ikhtisar Adaptive join adalah fitur pratinjau di Aurora PostgreSQL 17.4 yang membantu meningkatkan kinerja kueri. Fitur ini dinonaktifkan secara default, tetapi Anda dapat mengaktifkannya menggunakan parameter Global User Configuration (GUC). Karena ini adalah fitur pratinjau, nilai parameter default mungkin berubah. Saat diaktifkan, gabungan adaptif membantu mengoptimalkan kinerja kueri dengan beralih secara dinamis dari gabungan loop bersarang ke gabungan hash saat runtime. Peralihan ini terjadi ketika pengoptimal PostgreSQL salah memilih sambungan loop bersarang karena perkiraan kardinalitas yang tidak akurat. ## Mengkonfigurasi gabungan adaptif Anda dapat mengontrol gabungan adaptif menggunakan tiga parameter GUC ini: **Parameter konfigurasi gabungan adaptif** | Parameter GUC | Deskripsi | Opsi default dan konfigurasi | | --- | --- | --- | | apg\$1adaptive\$1join\$1crossover\$1multiplier | Pengganda ini bekerja dengan titik crossover baris untuk menentukan kapan harus beralih dari loop bersarang ke gabungan hash. Titik crossover baris adalah di mana pengoptimal SQL memperkirakan bahwa loop bersarang dan operasi gabungan hash memiliki biaya yang sama. Nilai multiplier yang lebih tinggi mengurangi kemungkinan pengalihan gabungan adaptif ke gabungan hash. | Mengontrol apakah Adaptive Join diaktifkan [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) | | apg\$1adaptive\$1join\$1cost\$1threshold | Parameter ini menetapkan ambang biaya kueri minimum. Gabungan adaptif secara otomatis menonaktifkan dirinya sendiri untuk kueri di bawah ambang batas ini. Ini mencegah overhead kinerja dalam kueri sederhana di mana biaya perencanaan gabungan adaptif dapat melebihi manfaat beralih dari loop bersarang ke gabungan hash. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) | | apg\$1enable\$1parameterized\$1adaptive\$1join | Parameter ini memperluas fungsionalitas gabungan adaptif ke gabungan loop bersarang berparameter saat diaktifkan. Secara default, gabungan adaptif hanya berfungsi dengan gabungan loop bersarang tanpa parameter, karena ini lebih mungkin mendapat manfaat dari beralih ke gabungan hash. Gabungan loop bersarang berparameter biasanya berkinerja lebih baik, membuat peralihan ke bergabung dengan hash menjadi kurang penting. | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/AmazonRDS/latest/AuroraUserGuide/user-apg-adaptive-join.html) `apg_adaptive_join_crossover_multiplier`Harus diaktifkan terlebih dahulu | # Menggunakan cache paket bersama ## Ikhtisar Aurora PostgreSQL menggunakan process-per-user model di mana setiap koneksi klien membuat proses backend khusus. Setiap proses backend mempertahankan cache rencana lokalnya sendiri untuk pernyataan yang disiapkan. Karena cache ini tidak dapat dibagi antar proses, aplikasi yang menggunakan banyak pernyataan yang disiapkan dapat membuat cache duplikat di berbagai proses backend, yang mengarah pada peningkatan penggunaan memori. Aurora PostgreSQL versi 17.6 dan yang lebih baru dan 16.10 dan kemudian memperkenalkan fungsionalitas cache paket bersama. Saat Anda mengaktifkan fitur ini, proses backend dapat berbagi paket generik, yang mengurangi penggunaan memori dan meningkatkan kinerja dengan menghilangkan pembuatan paket duplikat. Cache paket bersama menggunakan komponen berikut sebagai kunci cache-nya: + String kueri (termasuk komentar) + Parameter GUC terkait perencana (termasuk) `search_path` + ID Pengguna + ID Database Instans memulai ulang ulang cache bersama. ## Parameter Tabel berikut menjelaskan parameter yang mengontrol fitur cache paket bersama: | Parameter | Deskripsi | Default | Diizinkan | | --- | --- | --- | --- | | apg\$1shared\$1plan\$1cache.enable | Mengaktifkan atau menonaktifkan cache paket bersama | 0 (MATI) | 0, 1 | | apg\$1shared\$1plan\$1cache.max | Jumlah maksimum entri cache | 200—1000 (tergantung ukuran instance) | 100—50000 | | apg\$1shared\$1plan\$1cache.min\$1size\$1per\$1entry | Ukuran paket minimum untuk disimpan dalam cache bersama. Paket yang lebih kecil menggunakan cache lokal untuk mengoptimalkan kinerja OLTP. | 16 KB | 0—32768 (KB) | | apg\$1shared\$1plan\$1cache.max\$1size\$1per\$1entry | Ukuran paket maksimum untuk cache bersama. Paket yang lebih besar hanya menyimpan informasi biaya. | 256 KB—4 MB (tergantung ukuran instance) | 0—32768 (KB) | | apg\$1shared\$1plan\$1cache.idle\$1generic\$1plan\$1release\$1timeout | Waktu setelah sesi idle merilis rencana generik lokal. Nilai yang lebih rendah menghemat memori; nilai yang lebih tinggi mungkin meningkatkan kinerja. | 10 detik | 0—2147483647 (ms) | **catatan** Anda dapat memodifikasi semua parameter tanpa memulai ulang. ## Memantau tampilan dan fungsi + `apg_shared_plan_cache()`— Menampilkan informasi entri cache terperinci (hits, validitas, stempel waktu) + `apg_shared_plan_cache_stat()`— Menampilkan statistik tingkat instance (penggusuran, pembatalan) + `apg_shared_plan_cache_reset()`— Menghapus semua entri di `apg_shared_plan_cache()` dan `apg_shared_plan_cache_stat()` + `apg_shared_plan_cache_remove(cache_key)`— Menghapus entri dari `apg_shared_plan_cache()` tempat entri cocok `cache_key` ## Batasan + Hanya berfungsi dengan pernyataan yang disiapkan dan tidak menyimpan PL/pgSQL pernyataan cache + Tidak menyimpan kueri yang berisi tabel sementara atau tabel katalog + Tidak menyimpan kueri yang bergantung pada RLS (Keamanan Tingkat Baris) + Setiap replika mempertahankan cache-nya sendiri (tidak ada berbagi lintas replika)