VACUUM'u yalnızca INSERT alan bir tabloda çalıştırmaya değer mi?

2015 yılında yeniden icat konuşmasında, AWS vakumun sadece güncellemelerden veya sildikten sonra değil, aynı zamanda insertlerden sonra da çalıştırılması gerektiğini belirtti. İşte konuşmanın ilgili kısmı:

http://www.youtube.com/watch?v=tZXp19q8RFo&t=16m2s

Sözde, sadece kesici uçlar alsalar bile bloklar üzerinde yapılması gereken bir temizleme vardır ve bu temizleme, bir blok ilk seçildiğinde (okumaları yavaşlatma) veya vakum sırasında yapılabilir. Bu doğru mu ve eğer öyleyse, tam olarak ne tür bir temizlik yapılmalıdır?

tl; dr: Veriler işlendikten sonra okuyan ilk işlem ipucu bitleri ayarlar. Bu, sayfayı kirletecek ve yazma etkinliği oluşturacaktır. Başka bir şey yapar VACUUM(ancak diğer komutlar değil), sayfayı uygunsa tümüyle görünür olarak işaretler. VACUUMsonunda tuples dondurmak için masaya vurmak zorunda kalacak.

Bir kesici uçtan sonra yapılması gereken iş gerçekten temizlik değildir, en azından VACUUMnormalde diğer çalışma anlamında değildir . Ayrıntılara girmeden önce, bu cevabın mevcut (yayınlanmamış) 9.6 koduna dayandığını ve görünürlük üzerinde bir etkisi olsa bile akış çoğaltmasının etkilerini görmezden geldiğimi unutmayın.

MVCC nedeniyle, Postgres, bir grubun bir sorgu için görünür olup olmayacağını her değerlendirdiğinde, grubu oluşturan işlemin (xmin gizli alanına kaydedilen) diğer bazı kriterlerle birlikte yapılıp yapılmadığını dikkate almalıdır. Bu kontrol pahalıdır, bu nedenle bir işlemin o anda açık olan tüm işlemlerde görülebildiği anda, demet başlığında bunu belirten bir "ipucu biti" ayarlanır. Bu bitin ayarı sayfaya yönlendirilir, yani diske yazılması gerekir. Verileri okumak için bir sonraki komut SELECTaniden çok fazla yazma trafiği yaratan bir komutsa, bu çok kafa karıştırıcı olabilir . Ekleme işleminin tamamlanmasından VACUUMsonra a çalıştırılması bundan kaçınacaktır. Bir diğer önemli ayrım iseVACUUMHER ZAMAN bir sayfada tuples ipucu verir (sayfada temizleme kilidine sahip olduğu sürece), ancak diğer birçok komut yalnızca ekleme işlemi komut başlamadan önce yapılırsa ipucu verir .

Tüm bu ipucu bitlerini yazmanın önemli bir noktası, VACUUMkısaltılabilir (ve otomatik vakumun varsayılan olarak kısılmış olmasıdır). Diğer komutlar kısıtlanmaz ve olabildiğince çabuk kirli veriler oluşturur.

VACUUMsayfaları tümüyle görünür olarak işaretlemenin tek yöntemidir; bu, bazı işlemler için önemli bir performans özelliğidir (özellikle yalnızca dizin taramaları). Büyük bir insert yaparsanız, yeni eklenen tuples'den başka bir şey olmayan birçok sayfa olması muhtemeldir. VACUUMbu sayfaları potansiyel olarak tümüyle görünür olarak işaretleyebilir, ancak yalnızca VACUUMbaşlatıldığında en eski çalışan işlem verileri ekleyen işlemden daha yeni olduğunda işaretleyebilir .

MVCC nasıl çalıştığını Çünkü 2 milyar işlemler önce ~ daha sokulmuş tuples gerekir "olarak işaretlenecektir dondurulmuş ". Varsayılan olarak autovacuum her 200M işleminde devreye girer. Toplu bir eklemeden sonra vacuum_freeze_min_age 0 olarak ayarlanmış bir manuel vakumun çalıştırılması, bunun etkisini azaltmaya yardımcı olabilir. Daha agresif bir şekilde, VACUUM FREEZEyerleştirdikten sonra masada çalışabilirsiniz . Bu, bir sonraki dondurma taraması gerçekleştiğinde "saati sıfırlar".

Belirli ayrıntıları öğrenmek istiyorsanız, içeriye HEAPTUPLE_LIVEdoğru arama yaptıktan sonra duruma bir göz atın . Kendisine de bakın ve karşılaştırın .HeapTupleSatisfiesVacuum()lazy_scan_heap()HeapTupleSatisfiesVacuum()HeapTupleSatisfiesMVCC()

İlginç olabilecek iki sunumum daha var. İlk video http://www.pgcon.org/2015/schedule/events/829.en.html adresinden , ikincisi ise (biraz daha iyi olduğunu düşünüyorum) https://www.youtube adresinden edinilebilir . com / watch? v = L8nErzxPJjQ