Menyesuaikan Konstanta Biaya Perencana Kueri
Pelajari cara konstanta biaya perencana seperti random_page_cost dan effective_cache_size memengaruhi pilihan rencana, serta cara menyesuaikannya dengan perangkat keras dan data Anda.
Menyesuaikan Konstanta Biaya Perencana Kueri adalah pelajaran PostgreSQL Performance & Query Optimization gratis di CoddyKit. Ini adalah pelajaran 4 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar PostgreSQL Performance & Query Optimization, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus PostgreSQL Performance & Query Optimization mencakup 4 pelajaran total.
Bagian dari pelajaran ini belum diterjemahkan dan ditampilkan dalam bahasa Inggris.
The Planner Needs Hints About Hardware
The planner estimates the cost of each plan using constants that model your hardware. If those constants do not match reality, it may pick a sequential scan when an index scan would be far faster, or vice versa.
seq_page_cost vs random_page_cost
Two key constants:
seq_page_cost(default 1.0): cost to read a page sequentiallyrandom_page_cost(default 4.0): cost to read a page at random
The 4:1 ratio assumes spinning disks where random reads are slow.
Tuning for SSDs
On SSDs random reads are nearly as cheap as sequential ones. Lowering random_page_cost makes the planner favor index scans appropriately.
SET random_page_cost = 1.1;effective_cache_size
This tells the planner how much memory the OS and PostgreSQL together are likely to use for caching data. It does not allocate memory — it only influences cost estimates for index scans.
SET effective_cache_size = '12GB';Why effective_cache_size Matters
A large value tells the planner that repeated index lookups will likely hit cache, making index scans look cheaper and more attractive for large tables. Set it to roughly 50-75% of total RAM.
CPU Cost Constants
Finer constants weigh CPU work:
cpu_tuple_cost: per-row processingcpu_index_tuple_cost: per index entrycpu_operator_cost: per operator/function call
These are rarely changed but matter for CPU-heavy expressions.
Testing a Change at Session Level
Test constants with SET in your session before making them permanent. Compare plans with EXPLAIN.
SET random_page_cost = 1.1;
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;Making It Permanent
Once satisfied, set the value cluster-wide and reload, or edit postgresql.conf.
ALTER SYSTEM SET random_page_cost = 1.1;
SELECT pg_reload_conf();Beware of Over-Tuning
Do not chase a single slow query by skewing constants globally — you may break thousands of other plans. Fix the root cause (missing index, stale stats) first; adjust constants only for genuine hardware mismatches.
Per-Tablespace Tuning
If some data sits on SSD and some on HDD, you can set random_page_cost per tablespace so the planner reasons about each storage medium correctly.
ALTER TABLESPACE fast_ssd
SET (random_page_cost = 1.1);Verifying the Effect
After changing a constant, confirm the planner actually switched plans. Run EXPLAIN before and after and look for a Seq Scan turning into an Index Scan (or vice versa).
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;
SET random_page_cost = 1.1;
EXPLAIN SELECT * FROM orders WHERE customer_id = 42;Quick Check
Test your planner-tuning knowledge.
Recap
You learned planner cost tuning:
- Cost constants model your hardware for the planner
- Lower
random_page_coston SSDs to favor index scans - Set
effective_cache_sizeto ~50-75% of RAM - Test with
SETand EXPLAIN beforeALTER SYSTEM - Fix indexes/stats before skewing constants globally
Belajar SQL dengan tutor AI — gratis
Tulis dan jalankan kode asli di browser kamu, dapatkan bantuan instan dari tutor AI 24/7, dan lanjutkan di mana kamu tinggalkan di web atau aplikasi.
- Kursus
- 22
- Pelajaran
- 88
Pertanyaan yang Sering Diajukan
Apakah pelajaran “Menyesuaikan Konstanta Biaya Perencana Kueri” gratis?
Ya — teks lengkap “Menyesuaikan Konstanta Biaya Perencana Kueri” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus PostgreSQL Performance & Query Optimization, upgrade ke CoddyKit PRO. Kursus PostgreSQL Performance & Query Optimization mencakup 4 pelajaran total.
Apa yang akan aku pelajari di “Menyesuaikan Konstanta Biaya Perencana Kueri”?
Pelajari cara konstanta biaya perencana seperti random_page_cost dan effective_cache_size memengaruhi pilihan rencana, serta cara menyesuaikannya dengan perangkat keras dan data Anda. Kamu berlatih PostgreSQL Performance & Query Optimization dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.
Apakah aku perlu pengalaman untuk memulai PostgreSQL Performance & Query Optimization?
Tidak diperlukan pengalaman sebelumnya. PostgreSQL Performance & Query Optimization di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 4 dari 4.
Berapa lama pelajaran “Menyesuaikan Konstanta Biaya Perencana Kueri” memakan waktu?
Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.
Bisakah aku menulis dan menjalankan kode dalam pelajaran PostgreSQL Performance & Query Optimization ini?
Ya. Setiap pelajaran PostgreSQL Performance & Query Optimization menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.
Semua pelajaran dalam kursus ini
- Parameter Utama postgresql.conf
- Penyetelan Memori (shared_buffers, work_mem)
- Penyetelan I/O Disk dan Checkpoint
- Menyesuaikan Konstanta Biaya Perencana Kueri