L'ANALISI SOTTOVUOTO regolare è ancora raccomandata al punto 9.1?

Sto usando PostgreSQL 9.1 su Ubuntu. Le programmazioni sono VACUUM ANALYZEancora consigliate o l'autovacuum è sufficiente per soddisfare tutte le esigenze?

Se la risposta è "dipende", quindi:

• Ho un database di grandi dimensioni (dimensione del dump compresso di 30 GiB, directory dei dati di 200 GiB)
• Faccio ETL nel database, importando quasi 3 milioni di righe alla settimana
• Le tabelle con le modifiche più frequenti sono tutte ereditate da una tabella principale, senza dati nella tabella principale (i dati vengono partizionati per settimana)
• Creo rollup orari e da lì rapporti giornalieri, settimanali e mensili

Lo sto chiedendo perché la pianificazione ha un VACUUM ANALYZEimpatto sui miei rapporti. Funziona per più di 5 ore e ho dovuto ucciderlo due volte questa settimana, perché stava influenzando le normali importazioni di database. check_postgresnon segnala alcun gonfiamento significativo nel database, quindi non è davvero un problema.

In base ai documenti, anche Autovacuum dovrebbe occuparsi della conclusione dell'ID transazione. La domanda rimane: ho ancora bisogno di un VACUUM ANALYZE?

VACUUM è necessario solo su righe aggiornate o eliminate in tabelle non temporanee. Ovviamente stai facendo molti INSERTI, ma dalla descrizione non è ovvio che stai anche facendo molti AGGIORNAMENTI o DELETTE.

Queste operazioni possono essere monitorate con la pg_stat_all_tablesvista, in particolare le colonne n_tup_upde n_tup_del. Inoltre, ancor più al punto, c'è una n_dead_tupcolonna che dice, per tabella, quante righe devono essere aspirate. (consultare Monitoraggio delle statistiche nel documento per funzioni e viste relative alla raccolta delle statistiche).

Una possibile strategia nel tuo caso sarebbe quella di sopprimere il VUOTO programmato, tenendo d'occhio questo punto di vista e controllando quali tabelle n_dead_tupstanno aumentando in modo significativo. Quindi applicare il VUOTO aggressivo solo a queste tabelle. Questa sarà una vittoria se ci sono tabelle di grandi dimensioni le cui righe non vengono mai cancellate né aggiornate e il VACUUM aggressivo è davvero necessario solo su tabelle più piccole.

Ma continua a utilizzare ANALYZE affinché l'ottimizzatore abbia sempre nuove statistiche.

Non vedo nulla nella tua domanda che autovacuumnon se ne occuperebbe. Dipende in gran parte dal modello delle tue attività di scrittura . Citi 3 milioni di nuove righe alla settimana, ma INSERT(o COPY) in genere non creano un gonfiamento di tabella e indice. ( autovacuumdeve solo occuparsi delle statistiche delle colonne , della mappa di visibilità e di alcuni lavori minori). UPDATEe DELETEsono la causa dominante del gonfiamento di tabelle e indici, specialmente quando si prendono di mira righe casuali. Non vedo nulla di tutto ciò nella tua domanda.

autovacuumha fatto molta strada e sta facendo un ottimo lavoro in Postgres 9.1 o versioni successive. Vorrei dare un'occhiata alle autovacuumimpostazioni . Se l'aspirazione tende a interferire con il carico di lavoro, consultare anche "Ritardo vuoto basato sui costi" . L'aspirazione manuale dovrebbe essere la rara eccezione.

Se hai molti messaggi casuali UPDATE, potresti voler impostare FILLFACTORqualcosa su un valore inferiore a 100, per consentire subito aggiornamenti HOT e ridurre la necessità di VACUUM. Altre informazioni sugli aggiornamenti HOT:

• Dati ridondanti nelle dichiarazioni di aggiornamento

Si noti inoltre che le tabelle temporanee richiedono manuale VACUUMe ANALYZE. Cito il manuale suCREATE TABLE :

Il demone autovacuum non può accedere e quindi non può aspirare o analizzare tabelle temporanee. Per questo motivo, le operazioni di analisi e vuoto appropriate devono essere eseguite tramite i comandi SQL della sessione. Ad esempio, se una tabella temporanea verrà utilizzata in query complesse, è consigliabile eseguirla ANALYZEsulla tabella temporanea dopo che è stata popolata.

Anche se concordo sul fatto che utilizzare le funzioni automatiche sia la soluzione migliore anziché eseguirlo a livello di database, nella maggior parte dei casi è necessario eseguire l'ottimizzazione per tabella.

Non sono del tutto d'accordo con la scelta del design di postgres per legare vuoto e analisi, ho visto diversi casi in cui i database che eseguono molti inserimenti / aggiornamenti ma poca eliminazione non vengono mai analizzati e iniziano a funzionare male.

La soluzione è quella di andare nelle tabelle che vengono utilizzate pesantemente e sono soggette a query di grandi dimensioni e impostare le impostazioni di analisi automatica per quelle tabelle su qualcosa in cui vengono analizzate una volta o ogni due giorni.

Puoi accedere alle impostazioni per tabella nella GUI nella scheda del vuoto automatico e vedrai lì analizzare le impostazioni che puoi impostare indipendentemente dal vuoto.

Le impostazioni finiscono nella tabella reloptions e possono essere visualizzate con la query

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

e potrebbe esserci un valore campione di un'analisi aggressiva

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

Per vedere l'ultima volta che le tue tabelle hanno ottenuto una query analizzata automaticamente

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;