# Veritabanı & sorgu

> Bir veri modeli kararı gerçek veri hacmi altında ne ödetir?

- Durum: Sürüyor
- Kayıt sayısı: 3
- Kaynak: https://www.muhammetsafak.com.tr/research/program/veritabani/
- Dil: tr-TR
- Yazar: Muhammet Şafak

---
Index stratejisi, sorgu planı ve bağlantı yönetiminin gerçek veri hacmi altında ödettiği bedel; şema ve migration kararları dâhil.

## Bulgu defteri

### Partial index on beş dakikada üç yüz beş kat şişti — ve autovacuum bir kez bile gelmedi

- Soru: Sürekli churn altındaki bir kuyruk tablosunda partial index'in küçüklüğü kalıcı mı, ve varsayılan autovacuum ayarları ona yetişiyor mu?
- Bulgu: Canlı küme beş bin satırda sabit dururken partial index 0,125 MB'dan 38,2 MB'a çıktı — üç yüz beş kat. Küçüklüğü canlı satır sayısından geliyor, şişme hızı iş hacminden, ve ikisi arasında hiçbir bağ yok. Composite index oransal olarak daha az şişti (%42) ama mutlak olarak daha çok (+126 MB) ve şişerken belleğe sığmayı bıraktı: gecikmesi 0,52 ms'den 61 saniyeye çıktı, kuyruğu 126 bine tırmandı. On beş dakikada 1,75 milyon ölü satır birikti ve autovacuum **bir kez bile koşmadı** — varsayılan eşik tablonun tamamına göre ölçekleniyor (50 + 0,2 × 10 milyon ≈ 2 milyon), churn ise küçük canlı kümede oluyor.
- https://www.muhammetsafak.com.tr/research/kuyruk-tablosunda-bloat-ve-autovacuum/
- Markdown: https://www.muhammetsafak.com.tr/research/kuyruk-tablosunda-bloat-ve-autovacuum.md

### Partial index kuyruk tablosunu kırk bir kat küçültüyor — planner onu seçtiği sürece

- Soru: Milyonlarca ölü satır biriken bir Postgres kuyruk tablosunda partial index ne kazandırıyor, ve planner onu ne zaman seçmiyor?
- Bulgu: 10 milyon ölü satırda partial index saniyede 11.537 iş çıkarıyor, index'siz tablo 7. Composite index'le hız farkı küçük (%6,9) ama boyut farkı değil: 7,6 MB'a karşı 310,4 MB, ve partial tabloyla birlikte büyümüyor çünkü yalnız 5.000 canlı satırı indeksliyor. Asıl bulgu bunların hiçbiri: planner hazırlanmış bir deyimde generic plana geçtiği anda partial index tamamen devre dışı kalıyor — 11.752 tps 7'ye, 0,68 ms 1,1 saniyeye düşüyor. Bin altı yüz otuz beş kat. Aynı koşulda composite index etkilenmiyor.
- https://www.muhammetsafak.com.tr/research/partial-index-kuyruk-tablosu/
- Markdown: https://www.muhammetsafak.com.tr/research/partial-index-kuyruk-tablosu.md

### Postgres partial index'i generic plana çevirmedi: kırk çalıştırma, kırk custom plan

- Soru: Hazırlanmış bir deyimde Postgres partial index'li sorguyu kendiliğinden generic plana çeviriyor mu — yoksa bin altı yüz otuz beş katlık uçuruma ancak elle mi düşülüyor?
- Bulgu: Postgres geçişi reddediyor. Partial index'te kırk çalıştırmanın kırkı da custom plan — sayaç 40/0. Reddetmesinin sebebi tam olarak felaketin kendisi: generic plan partial index'i kullanamaz, bu yüzden tahmini maliyeti yüksek çıkar ve planner onu seçmez. Composite index ise ders kitabındaki gibi altıncı çalıştırmada geçiyor (5/35) ve hiçbir şey kaybetmiyor. Yani bin altı yüz otuz beş katlık uçurum gerçek ama çitli: ona düşmek için `plan_cache_mode = force_generic_plan` yazmak gerekiyor.
- https://www.muhammetsafak.com.tr/research/planner-generic-plana-ne-zaman-geciyor/
- Markdown: https://www.muhammetsafak.com.tr/research/planner-generic-plana-ne-zaman-geciyor.md