Sadece 'pending' satırları taranan bir kuyruk tablosunda partial index kullanmalı mıyım?
`WHERE status='pending'` partial index'ine `ORDER BY` kolonunu da katın, `FOR UPDATE SKIP LOCKED` ile eşleyin ve `'pending'`'i sorguya literal geçin.
Etiket
PostgreSQL veritabanı: index stratejileri, sorgu planlayıcı, vacuum ve performans.
Bu etikette 11 cevaplanmış soru var.
`WHERE status='pending'` partial index'ine `ORDER BY` kolonunu da katın, `FOR UPDATE SKIP LOCKED` ile eşleyin ve `'pending'`'i sorguya literal geçin.
Production'da EXPLAIN (ANALYZE, BUFFERS) çekip tabloyu ANALYZE edin ve n_dead_tup'a bakın; sessions için autovacuum'u sıkılaştırıp partial index ekleyin.
Periyodik base backup alıp WAL'ı sürekli S3'e arşivleyin, recovery_target_time ile hatalı ifadenin saniyeler öncesine dönün ve restore'u prova edin.
20M satırda bloklayan `ALTER TABLE` yerine expand/contract yürütün: kolonları nullable ekleyin, dual-write edin, throttled batch'lerle backfill edin.
Günde 100M satır düz bir tabloda patlar: hypertable ile zamana göre parçalayın, ortalamaları continuous aggregate'e alın, eski chunk'ları sıkıştırın.
İlişkisel çekirdeği (ürün, fiyat, sipariş) PostgreSQL'de tutup değişken nitelikleri GIN index'li tek bir `JSONB` kolonuna koyun; raporlama bölmeye karşı.
`created_at` üzerinde aylık RANGE declarative partitioning kurun, geçmişi batch'lerle backfill edip isimleri tek transaction'da takaslayın.
Kilitleri tek bir global sırada, artan PK gibi, alın; transaction'ı kısa ve dar tutun, hedefli `FOR UPDATE` kullanın, kalanı backoff ile retry edin.
Failover'ı elle yazmayın: Patroni + etcd ile terfiyi quorum'a bağlayın, çoğunluktan kopan eski primary fencing ile kendini replica'ya düşürsün.
Web filosunda Transaction modunu seçin; bedeli protokol seviyesi prepared statement'lardır, onları kapatın ya da PgBouncer 1.21+ desteğini açın.