Apakah VACUUM ANALYZE reguler masih direkomendasikan di bawah 9.1?

Saya menggunakan PostgreSQL 9.1 di Ubuntu. Apakah dijadwalkan VACUUM ANALYZEmasih direkomendasikan, atau apakah autovacuum cukup untuk memenuhi semua kebutuhan?

Jika jawabannya "tergantung", maka:

• Saya memiliki database largish (ukuran pembuangan terkompresi 30 GiB, direktori data 200 GiB)
• Saya melakukan ETL ke dalam database, mengimpor hampir 3 juta baris per minggu
• Tabel dengan perubahan paling sering semuanya diwarisi dari tabel master, tanpa data di tabel master (data dipartisi berdasarkan minggu)
• Saya membuat rollup per jam, dan dari sana, laporan harian, mingguan dan bulanan

Saya bertanya karena jadwal VACUUM ANALYZEtersebut memengaruhi pelaporan saya. Ini berjalan selama lebih dari 5 jam, dan saya harus membunuhnya dua kali minggu ini, karena itu berdampak pada impor basis data biasa. check_postgrestidak melaporkan mengasapi signifikan pada database, jadi itu tidak benar-benar masalah.

Dari dokumen, autovacuum juga harus mengurus pembungkus ID transaksi. Pertanyaannya tetap: apakah saya masih membutuhkan VACUUM ANALYZE?

VACUUM hanya diperlukan pada baris yang diperbarui atau dihapus dalam tabel non-sementara. Jelas Anda melakukan banyak INSERT tetapi tidak jelas dari deskripsi bahwa Anda juga melakukan banyak PEMBARUAN atau HAPUS.

Operasi ini dapat dilacak dengan pg_stat_all_tablestampilan, khususnya kolom n_tup_upddan n_tup_del. Juga, bahkan lebih tepatnya, ada n_dead_tupkolom yang memberitahu, per tabel, berapa banyak baris yang perlu disedot. (lihat Memantau statistik dalam dokumen untuk fungsi dan pandangan terkait pengumpulan statistik).

Strategi yang memungkinkan dalam kasus Anda adalah untuk menekan VACUUM yang dijadwalkan, mengawasi pandangan ini dan memeriksa tabel mana yang n_dead_tupnaik secara signifikan. Kemudian terapkan VACUUM agresif untuk tabel ini saja. Ini akan menjadi kemenangan jika ada tabel besar yang barisnya tidak pernah dihapus atau diperbarui dan VACUUM agresif benar-benar diperlukan hanya pada tabel yang lebih kecil.

Tetapi tetap menjalankan ANALYZE untuk optimizer untuk selalu memiliki statistik baru.

Saya tidak melihat apa pun dalam pertanyaan Anda yang autovacuumtidak akan diurus. Ini sangat tergantung pada pola kegiatan menulis Anda . Anda menyebutkan 3 juta baris baru per minggu, tetapi INSERT(atau COPY) biasanya tidak membuat tabel dan indeks menggembung. ( autovacuumhanya perlu mengurus statistik kolom , peta visibilitas dan beberapa pekerjaan kecil). UPDATEdan DELETEmerupakan penyebab dominan penggelembungan tabel dan indeks, terutama saat menargetkan baris acak. Saya tidak melihat semua itu dalam pertanyaan Anda.

autovacuumtelah berjalan jauh dan melakukan pekerjaan dengan baik di Postgres 9.1 atau lebih baru. Saya akan melihat autovacuumpengaturannya . Jika menyedot debu cenderung mengganggu beban kerja Anda, lihat juga "Penundaan Pengosongan Berbasis Biaya" . Penghisap debu secara manual harus menjadi pengecualian yang jarang.

Jika Anda memiliki banyak UPDATEs acak , Anda mungkin ingin mengatur FILLFACTORke sesuatu yang lebih rendah dari 100, untuk memungkinkan pembaruan HOT segera dan mengurangi kebutuhan VACUUM. Lebih lanjut tentang pembaruan HOT:

• Data yang berlebihan dalam laporan pembaruan

Perhatikan juga, bahwa tabel sementara membutuhkan manual VACUUM& ANALYZE. Saya mengutip manual padaCREATE TABLE :

The autovacuum daemon tidak bisa akses dan karena itu tidak dapat vakum atau menganalisis tabel sementara. Untuk alasan ini, operasi vakum dan analisis yang tepat harus dilakukan melalui perintah SQL sesi. Misalnya, jika tabel sementara akan digunakan dalam kueri kompleks, sebaiknya jalankan ANALYZEdi tabel sementara setelah diisi.

Meskipun saya setuju bahwa menggunakan fitur otomatis lebih baik daripada menjalankannya dengan basis data yang luas, dalam kebanyakan kasus per penyetelan tabel diperlukan.

Saya tidak terlalu setuju dengan pilihan desain postgres untuk menyatukan vakum dan menganalisis, saya telah melihat beberapa contoh di mana database yang melakukan banyak penyisipan / pembaruan tetapi sedikit penghapusan tidak pernah dilakukan analisis dan mulai berkinerja buruk.

Solusinya adalah masuk ke tabel yang sering digunakan dan tunduk pada pertanyaan besar dan mengatur pengaturan analisis otomatis untuk tabel tersebut ke sesuatu ke tempat di mana mereka akan dianalisis sekali atau setiap hari.

Anda dapat membuka pengaturan per tabel di gui pada tab vakum otomatis dan Anda akan melihat analisis pengaturan di sana yang dapat Anda atur secara independen dari ruang hampa udara.

Pengaturan berakhir di tabel reloptions dan dapat dilihat dengan kueri

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

dan nilai sampel dari analisis agresif mungkin

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Untuk melihat kapan terakhir kali tabel Anda mendapat kueri yang dianalisis secara otomatis

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;