PostgreSQL VACUUM sürecini yalnızca disk temizleme işlemi olarak görmek, onun sistem performansına etkisinin önemli bir bölümünü gözden kaçırmak demektir. postgresql vacuum dead tuple mekanizması, MVCC mimarisiyle doğrudan bağlantılıdır ve yanlış yapılandırıldığında tablo şişmesi (table bloat), indeks şişmesi ve sorgu yavaşlaması zinciri başlar. Dead tuple'lar şu senaryolarda oluşur: bir satır güncellendiğinde eski sürüm işaretlenir ve silindiğinde de benzer şekilde xmax atanır. Bu sürümler disk üzerinde kalır; VACUUM onları kaldırana kadar yer kaplamaya devam eder. postgresql vacuum dead tuple temizleme süreci üç şeyi gerçekleştirir: 1. Artık görünür olmayan tuple'ların işaretlenmesi ve FSM (Free Space Map) güncellenmesi. 2. Görünürlük haritasının (visibility map) güncellenmesi, Index Only Scan için kritik. 3. Transaction ID wrap-around önleme amacıyla frozen tuple üretimi. Autovacuum parametreleri yanlış yapılandırıldığında sorunlar birikir. Kritik parametreler: ``` autovacuum_vacuum_threshold = 50 -- minimum dead tuple sayısı autovacuum_vacuum_scale_factor = 0.2 -- tablo boyutunun %20'si autovacuum_vacuum_cost_delay = 2ms -- I/O throttle autovacuum_vacuum_cost_limit = 200 -- her turda harcanabilecek cost ``` Büyük tablolarda `scale_factor = 0.2` çok geç tetiklemeye yol açar. Örneğin 10 milyon satırlık bir tabloda VACUUM ancak 2 milyon dead tuple biriktiğinde başlar. Yüksek yazma hızında bu süre zarfında ciddi bloat oluşabilir. Çözüm: büyük tablolarda `autovacuum_vacuum_scale_factor` sıfıra yaklaştırılır, `autovacuum_vacuum_threshold` mutlak sayıyla belirlenir: ```sql ALTER TABLE buyuk_tablo SET ( autovacuum_vacuum_scale_factor = 0.01, autovacuum_vacuum_threshold = 1000 ); ``` Transaction ID (XID) wrap-around, VACUUM'un en kritik görevi olan postgresql vacuum dead tuple dışındaki işlevidir. 32-bit XID alanı yaklaşık 2 milyar işlemden sonra dolaşır. VACUUM FREEZE bu durumu önler: eski tuple'lar `FrozenTransactionId` ile işaretlenerek XID bağımlılığından kurtarılır. `autovacuum_freeze_max_age` (varsayılan 200 milyon) bu güvenlik sınırıdır. Manuel VACUUM kullanım senaryoları: - Büyük toplu silme/güncelleme sonrasında `VACUUM ANALYZE tablo;` - Bloat ölçümü için `pgstattuple` eklentisi: `SELECT * FROM pgstattuple('tablo');` - Agresif temizleme için `VACUUM (VERBOSE, ANALYZE) tablo;` VACUUM FULL tablo kilidini alır (ACCESS EXCLUSIVE) ve tüm veriyi yeniden yazar, üretim ortamında planlı bakım penceresi dışında kullanılmamalıdır. Bunun yerine `pg_repack` eklentisi, kilit süresi minimumda tutularak tablo yeniden inşasını sağlar.