È richiesto un REINDEX dopo CLUSTER?

Sto pensando di utilizzare CLUSTER per riordinare una tabella in base a un indice. Comprendo che questa ricreazione dei dati della tabella rende tutti gli indici esistenti gonfiati o inutili. Ho visto alcune indicazioni che è richiesto un REINDEX dopo un CLUSTER. Ho trovato altri riferimenti che indicano che CLUSTER esegue un REINDEX. La Documentazione ufficiale non dice nulla sul fatto che REINDEX sia parte di CLUSTER o sia richiesto (sebbene suggerisca di eseguire ANALYZE dopo CLUSTER)

Qualcuno può definitivamente (cioè con una sorta di riferimento a documenti ufficiali) dire se è richiesto o meno un REINDEX dopo un CLUSTER?

Non è necessario reindicizzare, perché CLUSTERlo fa efficacemente per te.

Più specificamente, CLUSTERblocca la tabella di origine, quindi crea una nuova copia ordinata in base all'indice di destinazione. Crea indici sulla nuova copia, quindi sostituisce la vecchia tabella e gli indici con quelli nuovi.

Si noti che ciò vale anche VACUUM FULLper 9.0+.

Se hai assistito a discussioni che suggeriscono che gli CLUSTERindici di gonfiore potrebbero essere le persone che stanno assumendo che CLUSTERfunzionano come pre-9.0 VACUUM FULL. Potresti anche vedere e leggere male le discussioni che menzionano il gonfiamento dell'indice causato dalla vecchia VACUUM FULLimplementazione e suggeriscono CLUSTERcome alternativa .

Ciò è implicito nella documentazione :

viene creata una copia temporanea della tabella che contiene i dati della tabella nell'ordine dell'indice. Vengono create anche copie temporanee di ciascun indice sulla tabella . Pertanto, è necessario spazio libero su disco almeno uguale alla somma delle dimensioni della tabella e delle dimensioni dell'indice

Ciò che non dice, ma dovrebbe, è che quelle copie temporanee sostituiscono la tabella originale . (Grassetto mio).

Sono con a_horse_with_no_name su questo: non è necessario ricreare gli indici. Oltre a ciò la CLUSTERdocumentazione non lo menziona, possiamo anche consultare ulteriormente la REINDEXpagina:

Esistono diversi scenari in cui utilizzare REINDEX:

• Un indice è stato danneggiato e non contiene più dati validi. Anche se in teoria ciò non dovrebbe mai accadere, in pratica gli indici possono essere danneggiati a causa di bug del software o guasti hardware. REINDEX fornisce un metodo di recupero.

• Un indice è diventato "gonfio", ovvero contiene molte pagine vuote o quasi vuote. Ciò può verificarsi con gli indici B-tree in PostgreSQL con determinati schemi di accesso non comuni. REINDEX fornisce un modo per ridurre il consumo di spazio dell'indice scrivendo una nuova versione dell'indice senza le pagine morte. Vedere la Sezione 23.2 per ulteriori informazioni.

• Hai modificato un parametro di archiviazione (come fillfactor) per un indice e desideri assicurarti che la modifica abbia avuto pieno effetto.

• Una compilazione di indice con l'opzione CONCURRENTLY non è riuscita, lasciando un indice "non valido". Tali indici sono inutili ma può essere conveniente usare REINDEX per ricostruirli. Si noti che REINDEX non eseguirà una build simultanea. Per creare l'indice senza interferire con la produzione, è necessario eliminare l'indice ed emettere nuovamente il comando CREATE INDEX CONCURRENTLY.

Chiaramente, CLUSTERnon rientra in nessuno di questi casi.

E c'è una piccola frase nei CLUSTERdocumenti:

[durante il clustering] Vengono create anche copie temporanee di ciascun indice sulla tabella.

Ciò suggerisce che, proprio come la tabella stessa, anche gli indici vengono riordinati durante il processo, rendendo in tal modo inutile la reindicizzazione.

È stato trovato un riferimento nella sezione Ripristino dello spazio su disco .

Se si dispone di una tabella di questo tipo e è necessario recuperare lo spazio su disco in eccesso che occupa, è necessario utilizzare VACUUM FULL, o in alternativa CLUSTER o una delle varianti di riscrittura delle tabelle di ALTER TABLE. Questi comandi riscrivono un'intera nuova copia della tabella e creano nuovi indici per essa.

Analizzando tutte le risposte, secondo me il modo giusto per farlo è reindicizzare PRIMA del cluster. Poiché la documentazione non dice se il cluster fa o meno un reindex e solo una copia dell'indice, ordinata o meno, penso che un indice indicizzato si tradurrà in una tabella cluster migliore. Successivamente un'analisi finirà il lavoro. Un vuoto pieno prima di tutto sembra essere inutile, a meno che il cluster e / o il reindex non liberino le tuple morte