Wawancara PostgreSQL: Bagaimana Cara Kerja MVCC dan VACUUM Bersama-sama?

Prompt dan Konteks yang Berlaku

Tabel orders pada PostgreSQL 18 memiliki 500 juta baris aktif dan pembaruan yang terus-menerus. Tim mengamati empat fakta:

• n_dead_tup terus meningkat;
• autovacuum worker muncul secara berkala;
• pg_relation_size('orders') tidak turun setelah vacuuming biasa;
• satu sesi aplikasi telah berstatus idle in transaction selama enam jam dan mengekspos backend_xmin yang lama.

Jelaskan rangkaian lengkap mulai dari visibilitas MVCC hingga pembersihan fisik. Diagnosis insiden tersebut, pilih urutan pemulihan yang aman, dan sebutkan bukti yang diperlukan sebelum menyatakan masalah telah teratasi. Angka-angka tersebut adalah input latihan, bukan batas ambang operasional universal.

Hal ini berlaku untuk wawancara backend, database, platform, dan SRE di mana kandidat harus menghubungkan semantik konkurensi dengan perilaku penyimpanan di lingkungan produksi. SQL hanyalah bahasa untuk inspeksi.

Apa yang Sedang Dievaluasi oleh Pewawancara

Ujian pertama adalah apakah kandidat memahami bahwa UPDATE adalah pembuatan versi. PostgreSQL menyimpan metadata tuple seperti transaction ID yang melakukan penyisipan (xmin) dan transaction ID yang menghapus atau menggantikan (xmax). Sebuah snapshot menggabungkan batasan transaksi dan status commit untuk menentukan versi mana yang terlihat. Aturannya jauh lebih presisi daripada sekadar "pilih baris dengan xmin terbesar."

Ujian kedua adalah apakah kandidat dapat menghubungkan visibilitas dengan pembersihan (cleanup). Versi lama tidak dapat dihapus selama snapshot yang aktif masih membutuhkannya. Transaksi terbuka yang lama, prepared transaction, atau replication slot dapat menahan cleanup horizon. Autovacuum dapat berjalan dengan sukses tetapi tetap melaporkan tuple yang mati (dead) tetapi belum dapat dihapus (removable).

Ujian ketiga adalah akurasi operasional. VACUUM biasa secara normal membuat ruang mati dapat digunakan kembali di dalam relasi; ini biasanya tidak menyusutkan ukuran file relasi. VACUUM FULL menulis ulang relasi, membutuhkan ruang disk sementara tambahan, dan mengambil kunci ACCESS EXCLUSIVE. Ini adalah operasi pemeliharaan luar biasa, bukan respons pertama terhadap perkiraan dead tuple yang meningkat.

Terakhir, kandidat harus memisahkan empat sinyal: perkiraan jumlah tuple, ruang yang dapat diambil kembali, ukuran relasi, dan performa yang terlihat oleh pengguna. Hal-hal ini saling terkait tetapi tidak dapat saling menggantikan. n_dead_tup yang menurun tidak membuktikan bahwa file sistem operasi telah menyusut, dan ukuran file yang tidak berubah tidak membuktikan bahwa vacuum gagal.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Tingkat isolasi (isolation levels) mana yang digunakan? Di bawah Read Committed, setiap pernyataan biasanya mendapatkan snapshot baru; Repeatable Read dan Serializable mempertahankan snapshot tingkat transaksi. Transaksi yang idle dapat mempertahankan snapshot horizon-nya meskipun tidak melakukan pekerjaan apa pun.
• Apakah backend_xmin yang lama merupakan pemblokir global? Bangun korelasi alih-alih berasumsi. Prepared transaction, logical atau physical replication slot, dan sesi lain mungkin mengekspos horizon yang lebih lama.
• Apakah statistik cukup segar untuk memandu penanganan insiden? n_dead_tup dan n_live_tup adalah perkiraan. Baca metrik ini bersamaan dengan waktu vacuum terakhir, progres, log, ukuran relasi, dan perilaku beban kerja.
• Apakah penggunaan kembali disk atau penyusutan file segera yang menjadi tujuan? Pembersihan rutin menargetkan penggunaan kembali dalam kondisi stabil (steady-state reuse). Mengembalikan ruang dalam jumlah besar ke sistem operasi memerlukan penulisan ulang atau rencana online-rebuild yang sesuai.
• Bisakah aplikasi menghentikan transaksi enam jam tersebut dengan aman? Identifikasi pemilik dan operasi bisnisnya terlebih dahulu. Membatalkan atau mematikannya akan membatalkan pekerjaan yang sedang terbuka (rollback) dan dapat memengaruhi alur pengguna.
• Apa yang berubah pada beban kerja? Tingkat pembaruan, kolom yang diindeks, lebar baris, pengaturan autovacuum, saturasi worker, dan masa pakai transaksi semuanya memengaruhi perputaran versi (version churn) dan kapasitas pembersihan.
• Berapa banyak dampak penguncian dan I/O yang diizinkan? Rencana pemulihan harus menjaga latensi, replikasi, ruang sisa disk (headroom), dan ketersediaan, bukan hanya menyelesaikan pemeliharaan secepat mungkin.

Kerangka Jawaban 30 Detik

"MVCC pada PostgreSQL memungkinkan setiap pernyataan membaca snapshot yang konsisten sementara pembaruan membuat versi tuple baru. Versi lama tetap ada sampai tidak ada snapshot aktif yang dapat melihatnya. Di sini, transaksi terbuka selama enam jam dapat menahan backend_xmin, sehingga autovacuum dapat memindai tabel tetapi tidak dapat menghapus versi yang masih berpotensi terlihat.

Saya pertama-tama akan mengonfirmasi horizon tertua di seluruh sesi, prepared transaction, dan replication slot; mengorelasikannya dengan statistik tabel, progres vacuum, log, dan ukuran; lalu menghentikan pemblokir yang terverifikasi melalui aplikasi pemiliknya. Saya akan menjalankan atau membiarkan vacuum biasa mengejar ketertinggalan di bawah batas I/O yang terukur dan memverifikasi bahwa estimasi dead tuple serta perilaku penggunaan kembali stabil. VACUUM biasa membuat ruang dapat digunakan kembali dan biasanya tidak menyusutkan file. VACUUM FULL menulis ulang dan mengunci tabel secara eksklusif, sehingga memerlukan keputusan pemeliharaan terpisah. Terakhir, saya akan membatasi masa pakai transaksi, menyesuaikan pengaturan tabel yang sering diperbarui (hot tables) per relasi, memantau usia XID, dan mempertahankan pembekuan sehingga XID lama tidak pernah melintasi wraparound horizon."

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Lacak Satu Pembaruan Melalui MVCC

Misalkan transaksi 100 menyisipkan versi pesanan. Header tuple-nya mencatat insertion XID di xmin. Kemudian, transaksi 220 memperbarui pesanan tersebut. PostgreSQL membuat tuple penerus dan menandai versi lama sebagai telah digantikan menggunakan metadata transaksi termasuk xmax; ini tidak menimpa byte lama secara langsung di tempat seperti yang mungkin disarankan oleh model logis.

Pembaca memeriksa snapshot dan status commit transaksinya untuk memutuskan versi mana yang terlihat. Secara sederhana, pembaca menolak versi yang disisipkan oleh transaksi yang belum di-commit atau berada di masa depan snapshot, dan mungkin mempertahankan versi yang transaksi penghapusnya belum terlihat. Aturan visibilitas nyata juga menangani transaksi saat ini, transaksi yang dibatalkan (aborted), ID perintah, dan hint bit, sehingga membandingkan nilai numerik xmin dan xmax saja bukanlah implementasi yang benar.

Model ini mengurangi konflik kunci baca/tulis: pembaca biasa tidak memblokir penulis, dan penulis tidak memblokir pembaca biasa. Ini tidak berarti bahwa sesama penulis tidak pernah saling memblokir. Dua transaksi yang memperbarui baris logis yang sama masih dapat menunggu atau berkonflik, dan tingkat isolasi yang lebih tinggi dapat membatalkan transaksi untuk mempertahankan jaminannya.

Langkah 2: Menurunkan Batas Pembersihan (Cleanup Horizon)

Setelah transaksi 220 melakukan commit, tuple lama menjadi usang untuk snapshot baru. Tuple tersebut tidak dapat langsung dihapus jika snapshot yang dimulai lebih awal masih dapat melihatnya. Vacuum memilih batas potong berdasarkan horizon relevan tertua. Versi yang lebih baru dari batas keamanan tersebut mungkin berstatus "baru saja mati" (recently dead): secara logis usang untuk pekerjaan saat ini tetapi belum aman untuk dihapus.

Sesi idle in transaction selama enam jam berbahaya karena klien meninggalkan transaksi terbuka. backend_xmin-nya dapat mempertahankan snapshot lama meskipun server sedang menunggu perintah klien berikutnya. Investigasi yang sama harus mencakup:

• pg_prepared_xacts, karena prepared transaction dapat menahan XID lama;
• pg_replication_slots, karena xmin atau catalog_xmin dapat menahan baris atau katalog yang diperlukan;
• baris pg_stat_activity lain dengan backend_xid atau backend_xmin lama;
• umpan balik replika dan konfigurasi logical decoding, karena persyaratan replikasi dapat memengaruhi pembersihan.

Oleh karena itu, rantai kausalitasnya adalah: horizon berumur panjang → versi lama tetap berpotensi terlihat → vacuum tidak dapat mengambilnya kembali → beban kerja heap dan indeks menumpuk → efisiensi cache dan biaya pemindaian dapat memburuk. Rantai tersebut harus dibuktikan dengan timestamp dan horizon yang selaras, bukan sekadar disimpulkan dari satu nama sesi yang idle.

Langkah 3: Diagnosis dengan Estimasi, Progres, dan Ukuran Secara Terpisah

Mulailah dengan snapshot read-only dari aktivitas dan statistik relasi:

SELECT pid,
       usename,
       application_name,
       state,
       xact_start,
       age(backend_xid) AS xid_age,
       age(backend_xmin) AS xmin_age,
       wait_event_type,
       wait_event,
       left(query, 120) AS query_sample
FROM pg_stat_activity
WHERE backend_xid IS NOT NULL OR backend_xmin IS NOT NULL
ORDER BY GREATEST(
  COALESCE(age(backend_xid), 0),
  COALESCE(age(backend_xmin), 0)
) DESC;

SELECT relid::regclass AS relation,
       n_live_tup,
       n_dead_tup,
       n_tup_upd,
       n_tup_hot_upd,
       last_vacuum,
       last_autovacuum,
       vacuum_count,
       autovacuum_count
FROM pg_stat_user_tables
WHERE relid = 'orders'::regclass;

SELECT pg_size_pretty(pg_relation_size('orders')) AS heap_size,
       pg_size_pretty(pg_indexes_size('orders')) AS index_size,
       pg_size_pretty(pg_total_relation_size('orders')) AS total_size;

n_dead_tup adalah sebuah estimasi, bukan pengukuran bloat yang tepat. last_autovacuum membuktikan bahwa seorang worker telah selesai, bukan berarti ia telah menghapus setiap versi yang usang. Relasi yang besar bisa tetap sehat jika halaman yang dibebaskan digunakan kembali dengan laju yang sama dengan kedatangan versi baru. Sebaliknya, ukuran relasi yang stabil dapat menyembunyikan peningkatan latensi atau perputaran indeks (index churn).

Saat vacuum aktif, periksa pg_stat_progress_vacuum untuk fase dan blok heap yang dipindai. Gunakan log autovacuum atau output VACUUM (VERBOSE) untuk mengetahui berapa banyak tuple yang dihapus, berapa banyak yang tetap tidak dapat dihapus, dan apakah pembekuan mengalami kemajuan. Periksa pg_stat_all_tables, riwayat ukuran relasi, latensi kueri, tekanan buffer dan I/O, laju WAL, lag replikasi, dan ruang sisa disk pada garis waktu yang sama.

Langkah 4: Pemulihan dengan Urutan Paling Aman

Pertama, identifikasi pemilik dan tujuan dari transaksi tertua. Jika transaksi tersebut ditinggalkan (abandoned), tutup melalui aplikasi atau pemilik koneksi. Jika itu adalah pekerjaan bisnis yang aktif, putuskan apakah rollback dapat diterima sebelum melakukan pembatalan. PostgreSQL mengekspos pg_cancel_backend dan pg_terminate_backend, tetapi akses ke suatu fungsi bukanlah otorisasi untuk mengganggu produksi.

Selanjutnya, selesaikan prepared transaction yang lebih lama atau replication slot yang usang melalui sistem pemiliknya. Menghapus slot aktif dapat mengharuskan pembuatan ulang replika atau hilangnya posisi decoding yang diharapkan, jadi ini adalah keputusan pemulihan yang eksplisit.

Setelah horizon maju, biarkan autovacuum mengejar ketertinggalan atau jalankan VACUUM (VERBOSE, ANALYZE) orders biasa yang terarah selama jendela waktu yang terukur. Pantau latensi, I/O, WAL, lag replikasi, progres vacuum, dan sisa ruang disk. Jangan meluncurkan beberapa pekerjaan pemeliharaan yang saling bersaing hanya karena pekerjaan pertama memakan waktu lama.

Kemudian verifikasi hasilnya:

• backend_xmin atau horizon slot tertua yang relevan telah maju;
• vacuum melaporkan bahwa versi mati yang sebelumnya tertahan sekarang dapat dihapus dan telah dihapus;
• n_dead_tup trennya menurun setelah pembaruan statistik;
• pembaruan baru menggunakan kembali ruang yang tersedia dan pertumbuhan relasi kembali ke kondisi stabil yang diharapkan;
• latensi permintaan, biaya pemindaian indeks, WAL, dan lag replika tetap berada dalam batas yang disepakati;
• age(relfrozenxid) dan usia XID database memiliki batas aman yang memadai.

Hanya setelah bukti ini ada, tim boleh mengevaluasi pemadatan fisik (physical compaction). VACUUM FULL orders membuat salinan padat yang baru, membutuhkan disk ekstra selama penulisan ulang, dan menahan kunci ACCESS EXCLUSIVE. Tabel dengan 500 juta baris mungkin memerlukan strategi online rebuild atau penggantian partisi yang terencana sebagai gantinya. Pilihan yang tepat bergantung pada downtime, sisa disk kosong, replikasi, foreign keys, konvergensi penulisan, dan rollback—bukan sekadar keinginan untuk memperkecil satu metrik ukuran.

Langkah 5: Menjelaskan Autovacuum Tanpa Hal Gaib

Autovacuum bereaksi terhadap statistik kumulatif. Untuk pembaruan dan penghapusan, PostgreSQL 18 menggunakan pemicu dalam bentuk:

vacuum threshold = min(
  autovacuum_vacuum_max_threshold,
  autovacuum_vacuum_threshold
    + autovacuum_vacuum_scale_factor * pg_class.reltuples
)

Pembersihan yang dipicu oleh penyisipan memiliki ambang batas terpisah berdasarkan tuple yang disisipkan dan fraksi halaman yang belum dibekukan. Pembersihan anti-wraparound juga dipaksakan oleh usia XID bahkan ketika autovacuum biasa telah dinonaktifkan untuk suatu tabel.

Pada relasi yang sangat besar dan sering diperbarui, faktor skala global dapat menunggu terlalu banyak perubahan atau menciptakan pekerjaan yang mendadak tinggi (bursty). Sesuaikan parameter penyimpanan tabel berdasarkan produksi versi dan kapasitas vacuum yang terukur. Periksa juga ketersediaan worker dan cost delay: pemicu yang tepat tidak menjamin bahwa worker langsung memulai atau selesai lebih cepat daripada laju beban kerja membuat sampah data.

Pencegahan juga harus dilakukan di jalur penulisan (write path). Buat transaksi tetap pendek dan hindari panggilan jaringan atau waktu tunggu pengguna di dalamnya. Terapkan idle_in_transaction_session_timeout secara selektif ke peran aplikasi yang sesuai, karena connection pool dan pekerjaan yang memang memakan waktu lama membutuhkan penanganan yang kompatibel. Perbarui hanya kolom yang diperlukan. Jika tidak ada kolom terindeks yang berubah dan tuple baru muat di halaman heap yang sama, pembaruan HOT dapat menghindari entri indeks baru; fillfactor dapat meningkatkan peluang tersebut dengan konsekuensi membiarkan lebih banyak ruang halaman tidak terpakai pada awalnya.

Langkah 6: Hubungkan Pembekuan dengan XID Wraparound

ID transaksi normal berukuran 32-bit dan dibandingkan dalam ruang sirkular. XID normal memiliki sekitar dua miliar ID yang dianggap lebih tua dan dua miliar yang dianggap lebih baru. Jika sebuah tuple mempertahankan XID penyisipan biasa tanpa batas waktu, pada akhirnya nilai yang sangat lama dapat tampak berada di masa depan.

Vacuum mencegah hal ini dengan membekukan versi tuple ter-commit yang sudah cukup lama. PostgreSQL modern merepresentasikan pembekuan dengan status tuple sambil mempertahankan xmin asli untuk visibilitas forensik; versi yang dibekukan diperlakukan lebih tua dari setiap transaksi normal. Penanda frozen-XID tabel dan database mencatat seberapa jauh proses ini telah berjalan.

Ini adalah persyaratan kebenaran data (correctness), bukan sekadar pembersihan bloat opsional. Pantau age(pg_class.relfrozenxid) dan age(pg_database.datfrozenxid), selidiki vacuum anti-wraparound, dan pertahankan kapasitas yang cukup agar proses tersebut dapat selesai. Menaikkan batas pembekuan hanya menunda pekerjaan dan mempersempit jendela keselamatan; ini tidak menghilangkan batasan sirkular XID.

Contoh Jawaban Kuat

"Saya akan memodelkan insiden ini sebagai perbandingan produksi versi melawan pembersihan yang aman. PostgreSQL MVCC memberikan snapshot kepada setiap pernyataan atau transaksi. Sebuah pembaruan membuat tuple penerus dan menandai versi lama melalui metadata transaksi. Pembaca mengevaluasi xmin, xmax, status commit, dan snapshot-nya untuk memilih versi yang terlihat. Ini memungkinkan pembacaan dan penulisan biasa berjalan tanpa konflik kunci baca, sementara sesama penulis pada baris yang sama masih dapat diblokir atau dibatalkan.

Versi lama tidak dapat dihapus sampai tidak ada snapshot relevan yang dapat melihatnya. Saya akan memeriksa semua sesi untuk mencari backend_xid dan backend_xmin yang lama, kemudian prepared transaction dan replication slot. Transaksi idle selama enam jam adalah tersangka kuat karena transaksi terbuka dapat mempertahankan snapshot horizon-nya, tetapi saya akan membuktikan bahwa itu adalah pemblokir tertua sebelum menghentikannya.

Saya akan mengorelasikan horizon tersebut dengan pg_stat_user_tables, pg_stat_progress_vacuum, log autovacuum, ukuran heap dan indeks, pertumbuhan relasi, latensi, I/O, WAL, dan lag replikasi. n_dead_tup adalah perkiraan, dan timestamp autovacuum hanya membuktikan bahwa proses pernah berjalan. Jika pemilik mengonfirmasi transaksi tersebut ditinggalkan, saya akan menutupnya, menyelesaikan horizon yang lebih lama, dan membiarkan vacuum biasa yang terarah mengejar ketertinggalan di bawah beban terukur.

VACUUM biasa menghapus versi yang aman untuk dihapus dan membuat ruangnya dapat digunakan kembali. Ini biasanya mempertahankan file relasi pada ukuran yang sama. VACUUM FULL menulis ulang relasi, membutuhkan disk sementara, dan mengunci tabel secara eksklusif, jadi saya hanya akan mempertimbangkannya di bawah keputusan pemadatan terencana dengan downtime atau strategi online-rebuild.

Untuk pencegahan, saya akan membatasi masa pakai transaksi, menyetel idle-transaction timeout yang sesuai dengan peran, memantau horizon tertua dan usia XID, menyesuaikan autovacuum per tabel yang sering diakses berdasarkan churn yang terukur, dan mendorong pembaruan HOT jika skema dan beban kerja memungkinkan. Vacuum juga membekukan versi ter-commit yang cukup lama sehingga XID mereka selalu diperlakukan sebagai masa lalu, mencegah wraparound. Keberhasilan berarti batas pemblokir telah maju, tuple yang dapat dihapus telah dibersihkan, penggunaan kembali ruang menstabilkan pertumbuhan, SLO layanan tetap sehat, dan usia frozen-XID mempertahankan batas keamanan yang cukup."

Kesalahan Umum dan Perbaikan

• Mengatakan UPDATE memodifikasi satu baris di tempat → PostgreSQL biasanya membuat versi tuple heap baru → lacak pendahulu dan penerus melalui metadata MVCC.
• Mereduksi visibilitas menjadi xmin < current_xid saja → status commit, batas snapshot, transaksi aktif, xmax, dan aturan perintah sangat penting → jelaskan keputusan snapshot tanpa membuat jalan pintas numerik yang keliru.
• Mengklaim pembaca dan penulis tidak pernah memblokir → MVCC menghilangkan konflik kunci baca/tulis biasa, sedangkan penulis pada baris yang sama dan kunci eksplisit tetap berkonflik → nyatakan jaminan yang lebih presisi.
• Mengasumsikan autovacuum yang selesai telah menghapus setiap dead tuple → horizon lama dapat menyebabkan versi tidak dapat dihapus → periksa tuple yang tertahan, horizon pemblokir, log, dan progres.
• Memperlakukan n_dead_tup sebagai byte bloat yang tepat → itu adalah perkiraan jumlah baris → ukur heap, indeks, pertumbuhan, penggunaan kembali, dan performa secara terpisah.
• Menyebut ukuran file yang tidak berubah sebagai kegagalan vacuum → vacuum biasa biasanya menyimpan ruang yang dibebaskan di dalam relasi untuk digunakan kembali → nilai penggunaan kembali kondisi stabil sebelum menuntut pemadatan.
• Menjalankan VACUUM FULL secara langsung → penulisan ulang membutuhkan disk ekstra dan kunci eksklusif → hapus pemblokir dan kejar ketertinggalan dengan vacuum biasa sebelum membuat rencana pemadatan.
• Hanya menyesuaikan faktor skala global → tabel yang sering diakses dan kapasitas worker berbeda-beda → gunakan pengaturan per-tabel yang didukung oleh bukti laju versi, waktu penyelesaian, dan SLO.
• Mematikan PID tertua tanpa pemeriksaan kepemilikan → transaksinya akan di-rollback dan alur klien mungkin gagal → konfirmasikan tujuan, dampak, dan jalur pemulihan terlebih dahulu.
• Memperlakukan pembekuan sebagai optimasi penyimpanan → pembekuan melindungi kebenaran data pada perbandingan sirkular XID → pantau usia frozen-XID dan pekerjaan anti-wraparound sebagai kontrol keamanan.

Pertanyaan Lanjutan

Pertanyaan Lanjutan 1: Mengapa Ukuran Tabel Bisa Tetap Sama Setelah VACUUM Berhasil?

Vacuum biasa menandai ruang dead tuple dapat digunakan kembali di dalam relasi yang sama. Vacuum dapat mengembalikan halaman yang benar-benar kosong di akhir fisik file dalam kondisi terbatas, tetapi perilaku standarnya adalah penggunaan kembali secara internal. Menyusutkan ruang kosong sembarang memerlukan penulisan ulang atau reorganisasi relasi. Oleh karena itu, ukuran yang stabil disertai latensi yang stabil dan penggunaan kembali yang berkelanjutan menandakan kondisi yang sehat.

Pertanyaan Lanjutan 2: Mengapa Autovacuum Berjalan tetapi Meninggalkan Banyak Versi Mati?

Versi tersebut mungkin masih terlihat oleh snapshot lama, tertahan oleh prepared transaction atau replication horizon, atau dihasilkan lebih cepat daripada kapasitas worker untuk membersihkannya. Worker juga mungkin tertunda atau terganggu oleh beban kerja dan penguncian. Gunakan log verbose, progres, horizon tertua, saturasi worker, dan laju produksi versi untuk membedakan kasus-kasus ini.

Pertanyaan Lanjutan 3: Apa Perbedaan Antara VACUUM dan ANALYZE?

Vacuum mengambil kembali ruang yang dapat digunakan kembali, memelihara indeks dan visibility map, serta membekukan metadata transaksi lama. Analyze mengambil sampel data untuk memperbarui statistik perencana kueri (planner). VACUUM (ANALYZE) melakukan keduanya, tetapi satu tidak menggantikan yang lain: statistik yang akurat tidak menghapus dead tuple, dan ruang yang diambil kembali tidak menjamin model distribusi data yang akurat.

Pertanyaan Lanjutan 4: Bagaimana Pembaruan HOT Mengurangi Tekanan Vacuum?

Ketika pembaruan tidak mengubah kolom yang diindeks dan penerusnya muat di halaman heap yang sama, PostgreSQL dapat menghindari penambahan entri indeks baru. Versi perantara dalam rantai HOT juga dapat dipangkas selama akses halaman normal. HOT tidak menghilangkan kebutuhan MVCC atau vacuum, tetapi mengurangi perputaran indeks dan beban kerja pembersihan. Pantau n_tup_hot_upd terhadap total pembaruan dan uji setiap perubahan fillfactor terhadap biaya ruang dan cache.

Pertanyaan Lanjutan 5: Bisakah Anda Menonaktifkan Autovacuum dan Menjalankan Cron Job Setiap Malam?

Itu berisiko untuk beban kerja yang dinamis dan tidak menonaktifkan pemeliharaan anti-wraparound. Lonjakan aktivitas di siang hari dapat membuat lebih banyak versi usang daripada yang dapat dibersihkan oleh jendela pemeliharaan malam hari, sementara tabel statis pada akhirnya tetap memerlukan pembekuan. Tetap aktifkan autovacuum, sesuaikan dari perputaran tabel yang diamati, dan lengkapi dengan pemeliharaan terkontrol hanya jika beban kerja membenarkan pilihan tersebut.

Pertanyaan Lanjutan 6: Pengaman (Guardrail) Apa yang Membantu Mengatasi Transaksi Idle?

idle_in_transaction_session_timeout dapat menghentikan sesi yang menunggu terlalu lama di dalam transaksi terbuka. Terapkan pada peran yang kompatibel dan uji perilaku connection pool, mekanisme retry, serta pekerjaan yang sah. Perbaiki juga batas aplikasi: mulai transaksi sesaat sebelum pekerjaan database, commit atau rollback segera, dan jangan pernah menunggu input pengguna atau layanan jarak jauh saat membiarkannya tetap terbuka.