Il tavolo occupato non viene aspirato

Stiamo usando Postgres 9.2 su Windows per archiviare i dati di serie a bassa frequenza: stiamo inserendo circa 2000 righe al secondo ogni secondo 24 ore, 7 giorni alla settimana senza tempi di inattività. C'è un oggetto DELETEche gira sul tavolo ogni 10 minuti circa per mantenere la lunghezza del tavolo per un numero fisso di giorni. Questo finisce per essere un 900 milioni di file abbastanza stabili. (Per chi fosse interessato, SELECT, INSERT, DELETEsono tutti performante).

Di conseguenza DELETE, pur eliminando le righe non si libera spazio su disco. Per questo dobbiamo VACUUMcorrere.

Ho fatto una query pg_stat_user_tablese VACUUMsembra che non sia mai stato eseguito.

Quello che ho capito da vari documenti ( http://www.postgresql.org/docs/9.2/static/routine-vacuuming.html ):

sembriamo avere il vuoto automatico attivo, ed è in esecuzione su altri tavoli.
il vuoto automatico non funziona FULLe non dovrebbe richiedere un blocco esclusivo sul tavolo.

Qualcuno ha qualche idea sul perché l'auto-vuoto non è in esecuzione? È solo perché il tavolo è continuamente occupato?

E vale la pena correre VACUUMdopo ogni DELETEin questo caso (che passa ogni 10 minuti)?

Modificare:

Eseguire una query utilizzando l'SQL dal collegamento SO di seguito:

-[ RECORD 2 ]---+---------------------------
schemaname      | stats
relname         | statistic_values_by_sec
last_vacuum     |
last_autovacuum |
n_tup           |    932,315,264
dead_tup        |    940,727,818
av_threshold    |    186,463,103
expect_av       | *

e output grezzo:

-[ RECORD 3 ]-----+---------------------------
relid             | 501908
schemaname        | stats
relname           | statistic_values_by_sec
seq_scan          | 12
seq_tup_read      | 4526762064
idx_scan          | 29643
idx_tup_fetch     | 2544206912
n_tup_ins         | 1573896877
n_tup_upd         | 0
n_tup_del         | 941176496
n_tup_hot_upd     | 0
n_live_tup        | 688858417
n_dead_tup        | 940727818
last_vacuum       |
last_autovacuum   |
last_analyze      |
last_autoanalyze  | 2014-08-09 01:36:21.703+01
vacuum_count      | 0
autovacuum_count  | 0
analyze_count     | 0
autoanalyze_count | 69

postgresql vacuum

— Barry
fonte

Vedi Aggressive Autovacuum su PostgreSQL . Inoltre sarebbe interessante avere select * from pg_stat_user_tablesper questa tabella (usare \xin psql per un output ben formattato)

— Daniel Vérité

Tale collegamento è utile e forse risponde alla domanda: la tabella è troppo occupata per il funzionamento del vuoto automatico. @ DanielVérité Ho aggiornato la domanda con l'output che hai chiesto.

— Barry,

Sono molte tuple morte! Se possibile, prendere in considerazione la possibilità di partizionare la tabella in base al timestamp e di eliminare le vecchie partizioni invece di eliminarle. Il principale avvertimento è che l'indice univoco tra le partizioni non è supportato.

— Daniel Vérité,

Il file di registro contiene messaggi sull'autovacuum su questa tabella che viene annullato?

— jjanes,

@jjanes No: non c'era alcuna indicazione nei registri che l'autovacuum fosse mai iniziato.

— Barry,

Vorrei esaminare il partizionamento . Se partizionato di giorno, potresti semplicemente rilasciare l'intera partizione una volta che diventa troppo vecchia. Potrebbe anche non essere più necessario aspirare.

Inoltre, le prestazioni complessive potrebbero aumentare, poiché non stai inserendo il punto in cui stai eliminando. Dovresti solo scrivere il codice per creare nuove partizioni ed eliminare quelle vecchie.

Questo è esattamente a cosa serve il partizionamento.

— SQB
fonte