Si dovrebbe sempre ANALIZZARE IL VUOTO prima di reindicizzare in PostgreSQL 8.4?

Ogni giorno al mattino presto un lavoro pgAgent aggiorna il contenuto della tabella A dalla tabella B sul mio database PostgreSQL 8.4. La tabella A contiene circa 140k record su 91 colonne e ha due indici: uno come parte del PRIMARY KEY e l'altro un indice GIST su una colonna geometrica POINT PostGIS.

Per rendere il processo un po 'più veloce, il lavoro rilascia l'indice sulla colonna della geometria, prima di eliminare i record nella tabella A e inserire i record dalla tabella B, quindi l'indice viene ricreato. Tutto ciò fatto, il demone autovacuum si mette in funzione quando ne ha voglia (dopo circa dieci minuti dal confronto tra le statistiche del lavoro e le statistiche della tabella per il tempo di completamento del lavoro e il tempo di esecuzione di autovacuum).

Dopo aver verificato il tavolo questa mattina dopo che tutto ciò è accaduto, le statistiche del tavolo mi hanno detto che la dimensione del tavolo era 272 MB, la dimensione del tavolo TOAST era 8192 byte e la dimensione dell'indice era 23 MB. Sembrava abbastanza grande, quindi ho emesso un comando REINDEX sul tavolo e la dimensione dell'indice è scesa a 9832 KB.

Le mie domande sono queste:

Perché apparentemente REINDEX riduce così tanto le dimensioni degli indici quando gli indici (o almeno l'indice della colonna della geometria) sono stati ricostruiti da zero? Devo accertarmi che la tabella sia stata aspirata / analizzata prima che gli indici vengano creati? La caduta dell'indice sulla chiave primaria non è un fattore in questo? Cosa mi sto perdendo?

Se l'istruzione CREATE INDEX rileva che un'altra sessione contiene un'istantanea attiva che potrebbe essere ancora interessata ai record eliminati, include i record eliminati nel nuovo indice.

Allo stesso modo, se un REINDEX rileva che un'altra sessione contiene un'istantanea attiva che potrebbe essere ancora interessata ai record eliminati, allora include tali record eliminati nel nuovo indice.

Se un VACUUM rileva che un'altra sessione contiene un'istantanea attiva che potrebbe essere ancora interessata ai record eliminati, mantiene tali record nella tabella. E quindi REINDEX o CREATE INDEX devono anche trasportarli nel nuovo indice, finché esiste ancora un'istantanea.

Una volta lì o più snapshot che potrebbero vedere le righe eliminate, VACUUM potrebbe rimuoverle dalla tabella. Ma un CREATE INDEX o REINDEX potrebbero anche non trasferirli nel nuovo indice, indipendentemente dal fatto che VACUUM sia riuscito a rimuoverli dall'abilità o meno.

Quindi, nel tuo scenario, il ruolo del VUOTO tra CREATE INDEX iniziale e REINDEX è probabilmente solo quello di occupare tempo, durante il quale la tua transazione di lunga durata si spera scompaia da sola e rilasci l'istantanea interferente.

Avendo provato diversi ordini di fare le cose sembra che eseguire un VUOTO prima di un'istruzione REINDEX sia l'unico modo per ottenere la riduzione delle dimensioni, forse perché lo spazio non aspirato si aggiunge all'indice (indicizzazione dei record cancellati?). Forzare una riscrittura della tabella usando

ALTER TABLE blah ALTER COLUMN whiffle SET DATA TYPE whiffle_type;

fa lo stesso tipo di cose, in quanto cancella lo spazio in disuso.

Dover VACUUM nel mezzo del processo interrompe un po 'il flusso poiché è necessario emettere un comando VACUUM al di fuori di una transazione.