Karena PostgreSQL MVCC, UPDATE secara efektif mirip dengan DELETE ditambah INSERT . Dengan pengecualian dari nilai yang dipanggang - lihat:
- Apakah Postgres menulis ulang seluruh baris saat pembaruan?
(Dan perbedaan kecil untuk tupel heap only - DELETE + INSERT memulai rantai PANAS baru - tetapi itu tidak ada hubungannya dengan kasus yang dihadapi.)
Tepatnya, baris "dihapus" tidak terlihat oleh transaksi apa pun yang dimulai setelah penghapusan dilakukan, dan kemudian dikosongkan. Oleh karena itu, di sisi database, termasuk manipulasi indeks, efeknya tidak ada perbedaan antara dua pernyataan. (Pengecualian berlaku, teruskan membaca.) Ini sedikit meningkatkan lalu lintas jaringan (bergantung pada data Anda) dan perlu sedikit penguraian.
Saya mempelajari pembaruan PANAS lagi setelah input @araqnid dan menjalankan beberapa tes. Pembaruan pada kolom yang tidak benar-benar mengubah nilai tidak ada bedanya apa pun sejauh menyangkut pembaruan PANAS. Jawaban saya berlaku. Lihat detailnya di bawah.
Ini juga berlaku untuk atribut yang dipanggang, karena atribut tersebut juga tidak disentuh kecuali nilainya benar-benar berubah .
Namun , jika Anda menggunakan pemicu per kolom (diperkenalkan dengan hal 9.0), ini mungkin memiliki efek samping yang tidak diinginkan!
Saya mengutip manual tentang pemicu:
... perintah seperti
UPDATE ... SET x = x ...akan memicu pemicu pada kolomx, meskipun nilai kolom tidak berubah .
Penekanan saya yang berani.
Lapisan abstraksi adalah untuk kenyamanan. Mereka berguna untuk pengembang yang buta huruf SQL atau jika aplikasi harus portabel di antara RDBMS yang berbeda. Pada sisi negatifnya, mereka dapat membantai kinerja dan memperkenalkan titik kegagalan tambahan. Saya menghindarinya sedapat mungkin.
Pembaruan PANAS (Tuple khusus tumpukan)
Tuples Heap-Only diperkenalkan dengan Postgres 8.3, dengan peningkatan penting di 8.3.4 dan 8.4.9.
Catatan rilis untuk Postgres 8.3:
UPDATEs danDELETEs meninggalkan tupel mati, seperti halnyaINSERTyang gagal s.Sebelumnya hanyaVACUUMbisa merebut kembali ruang yang diambil oleh tupel mati. WithHOT dead tuple space dapat diambil kembali secara otomatis pada saatINSERTatauUPDATEjika tidak ada perubahan yang dilakukan pada kolom yang diindeks . Ini memungkinkan kinerja yang lebih konsisten. Selain itu, HOT menghindari penambahan entri indeks duplikat.
Penekanan milikku. Dan "tidak ada perubahan" mencakup kasus di mana kolom diperbarui dengan nilai yang sama seperti yang sudah ada. Saya benar-benar menguji , karena saya tidak yakin.
Pada akhirnya, README.HOT ekstensif dalam kode sumber menegaskannya.
Kolom panggang juga tidak menghalangi pembaruan PANAS. Tuple yang diperbarui PANAS hanya menautkan ke tupel yang sama dan tidak berubah di garpu roti panggang dari relasi. Pembaruan PANAS bahkan berfungsi dengan nilai yang dipanggang dalam daftar target (sebenarnya diubah atau tidak). Jika nilai yang dipanggang diubah, itu memerlukan penulisan ke garpu relasi roti panggang, tentu saja. Saya juga menguji semua itu.
Jangan mengambil kata-kata saya untuk itu, lihat sendiri. Postgres menyediakan beberapa fungsi untuk memeriksa statistik. Jalankan UPDATE . Anda dengan dan tanpa semua kolom dan periksa apakah ada perbedaan.
-- Number of rows HOT-updated in table:
SELECT pg_stat_get_tuples_hot_updated('table_name'::regclass::oid)
-- Number of rows HOT-updated in table, in the current transaction:
SELECT pg_stat_get_xact_tuples_hot_updated('table_name'::regclass::oid)
Atau gunakan pgAdmin. Pilih tabel Anda dan periksa tab "Statistik" di jendela utama.
Ketahuilah bahwa pembaruan PANAS hanya mungkin bila ada ruang untuk versi Tuple baru pada halaman yang sama dari garpu relasi utama. Salah satu cara sederhana untuk memaksakan kondisi itu adalah dengan menguji dengan meja kecil yang hanya menampung beberapa baris. Ukuran halaman biasanya 8k, jadi harus ada ruang kosong di halaman.
