PostgreSQL Tablo ve İndeks Şişkinliği

Problem neden önemlidir?

MVCC güncellemeleri ve uygun olmayan doluluk davranışı tablo ile indekslerin gereksiz büyümesine katkıda bulunabilir. Büyük bir nesne otomatik olarak şişkin değildir; veri gerçekten büyümüş olabilir.

Nasıl teşhis edilir?

Tablo, indeks ve toplam ilişki boyutlarını satır ve değişim eğilimleriyle karşılaştırın. Boyut fonksiyonları alan kullanımını gösterir, yeniden kullanılabilir boş alanı kesin olarak sınıflandırmaz.

Sorgu en büyük tablo ve materyalize görünümlerin ayrılmış boyutlarını listeler. Sonuç tek başına şişkinlik yüzdesi veya kurtarılabilir alan hesabı değildir.

SELECT c.oid::regclass AS relation,
       pg_relation_size(c.oid) AS table_bytes,
       pg_indexes_size(c.oid) AS index_bytes,
       pg_total_relation_size(c.oid) AS total_bytes
FROM pg_class AS c
JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE c.relkind IN ('r', 'm')
  AND n.nspname NOT IN ('pg_catalog', 'information_schema')
ORDER BY total_bytes DESC
LIMIT 25;

Güvenli çözüm yaklaşımı

Önce büyümenin gerçek veri, ölü sürümler veya indeks tasarımından kaynaklandığını doğrulayın. Yeniden yapılandırma gerekiyorsa kilit, disk ve WAL etkisini ayrı bir bakım planında değerlendirin.

Sürekli monitoring neden gerekir?

moon, nesne boyutu eğilimlerini düşük ek yükle sürekli görünür tutmaya yardımcı olur. Slack, PagerDuty veya webhook uyarıları olağandışı büyümeyi erken paylaşabilir.