¿Se requiere un REINDEX después del CLUSTER?

12

Estoy considerando usar CLUSTER para reordenar una tabla por un índice. Entiendo que esta recreación de los datos de la tabla hace que todos los índices existentes se hinchen o sean inútiles. He visto algunas indicaciones de que se requiere un REINDEX después de un CLUSTER. He encontrado otras referencias que indican que CLUSTER hace un REINDEX. La documentación oficial no dice nada acerca de que REINDEX sea parte de CLUSTER o sea obligatorio (aunque sí sugiere ejecutar ANALYZE después del CLUSTER)

¿Puede alguien definitivamente (es decir, con algún tipo de referencia a documentos oficiales) decir si se requiere o no un REINDEX después de un CLUSTER?

postgresql ÁRBOL
fuente
2
No creo que sea necesario. clusterreubica las filas, por lo que tendrá que actualizar la información del índice de todos modos.
a_horse_with_no_name
Sí, pero la teoría en la mitad de las discusiones que he encontrado es que eso hace que el índice se hinche.
ÁRBOL

Respuestas:

12

No necesita reindexar, porque CLUSTERefectivamente lo hace por usted.

Más específicamente, CLUSTERbloquea la tabla de origen y luego crea una nueva copia ordenada de acuerdo con el índice de destino. Crea índices en la nueva copia y luego reemplaza la tabla antigua e indexa con las nuevas.

Tenga en cuenta que esto también es cierto VACUUM FULLen 9.0+.

Si ha estado viendo una discusión que sugiere que los CLUSTERíndices de hinchazón podrían ser personas que suponen que CLUSTERfunciona como pre-9.0 VACUUM FULL. También podría estar viendo y leyendo mal las discusiones que mencionan la hinchazón del índice causada por la VACUUM FULLimplementación anterior y sugiriendo CLUSTERcomo alternativa .

Esto está implícito en la documentación :

Se crea una copia temporal de la tabla que contiene los datos de la tabla en el orden del índice. También se crean copias temporales de cada índice en la tabla . Por lo tanto, necesita espacio libre en el disco al menos igual a la suma del tamaño de la tabla y los tamaños de índice

Lo que no dice, pero debería, es que esas copias temporales reemplacen la tabla original . (Negrita mía).

Craig Ringer
fuente
1
¿Tiene alguna referencia de que CLUSTER reemplaza los índices?
ÁRBOL
1
@ ÁRBOL añadido. Los documentos no le dicen explícitamente que la tabla temporal y los índices luego reemplazan los originales, pero verá que ese es el caso si realmente mira el directorio de datos antes / después de un CLUSTER o si examina el código fuente.
Craig Ringer el
He probado esto y, al menos en mi escenario de prueba, se redujo el tamaño del archivo de índice. Pero este es solo un escenario, y podría haber muchas variables que afectan el comportamiento (número de índices, tamaño total en el disco, etc.), por lo que no puedo confiar en una prueba simple.
ÁRBOL
1
@TREE Para una certeza absoluta en la comprensión del comportamiento en todas las circunstancias posibles, deberá leer el código fuente. Todo lo que puedo decir es que no estoy al tanto de ninguna situación en la que CLUSTERno se reescriban los índices, y el examen de los archivos reales base/mostrará claramente nuevos relfilenodecorreos electrónicos. Parece que te preocupan los problemas que aún no tienes.
Craig Ringer el
8

Estoy con a_horse_with_no_name en esto: no necesita volver a crear los índices. Además de que la CLUSTERdocumentación no lo menciona, también podemos consultar la REINDEXpágina:

Hay varios escenarios en los que utilizar REINDEX:

  • Un índice se ha dañado y ya no contiene datos válidos. Aunque en teoría esto nunca debería suceder, en la práctica los índices pueden corromperse debido a errores de software o fallas de hardware. REINDEX proporciona un método de recuperación.

  • Un índice se ha "hinchado", es decir, contiene muchas páginas vacías o casi vacías. Esto puede ocurrir con índices de árbol B en PostgreSQL bajo ciertos patrones de acceso poco comunes. REINDEX proporciona una forma de reducir el consumo de espacio del índice escribiendo una nueva versión del índice sin las páginas muertas. Vea la Sección 23.2 para más información.

  • Ha alterado un parámetro de almacenamiento (como el factor de relleno) para un índice y desea asegurarse de que el cambio haya tenido pleno efecto.

  • Una construcción de índice con la opción CONCURRENTEMENTE falló, dejando un índice "inválido". Dichos índices son inútiles, pero puede ser conveniente usar REINDEX para reconstruirlos. Tenga en cuenta que REINDEX no realizará una compilación concurrente. Para construir el índice sin interferir con la producción, debe soltar el índice y volver a emitir el comando CREATE INDEX CONCURRENTLY.

Claramente, CLUSTERno cae en ninguno de estos casos.

Y hay una pequeña oración en los CLUSTERdocumentos:

[durante la agrupación] También se crean copias temporales de cada índice de la tabla.

Esto sugiere que, al igual que la tabla en sí, los índices también se reordenan durante el proceso, lo que hace que la reindexación sea inútil.

dezso
fuente
La sugerencia ciertamente está ahí, y las pruebas parecen confirmarlo. Me sentiría mejor confiando en este comportamiento si los documentos realmente dijeran que los índices fueron recreados (permanentemente).
ÁRBOL
2
Veo cosas para un parche de documentación aquí. El manual debería ser más explícito sobre la recreación de índices.
Erwin Brandstetter
Mi sospecha en este punto es que los desarrolladores no quieren documentar oficialmente este comportamiento porque no quieren estar vinculados permanentemente a esta implementación.
ÁRBOL
@TREE hay muchos cambios de características entre versiones y los documentos cambian (en su mayoría) en consecuencia. Presumiblemente, las especificaciones también cambian :), por lo que no veo ningún empate en ninguna parte.
dezso
@dezso True, pero serán reacios a eliminar la funcionalidad documentada. Dada la calidad de la documentación en general, todavía asumo que la omisión de este comportamiento es intencional.
ÁRBOL
5

Encontró una referencia, en la sección Recuperando espacio en disco .

Si tiene una tabla de este tipo y necesita recuperar el espacio en disco que ocupa, deberá usar VACUUM FULL, o alternativamente CLUSTER o una de las variantes de reescritura de tablas de ALTER TABLE. Estos comandos reescriben una copia completamente nueva de la tabla y crean nuevos índices para ella.

ÁRBOL
fuente
-3

Analizando todas las respuestas, en mi opinión, la forma correcta de hacerlo es reindexar ANTES del clúster. Como la documentación no dice si el clúster hace o no una reindexación, y solo una copia del índice, ordenada o no, creo que un índice indexado dará como resultado una mejor tabla agrupada. Después de eso, un análisis finalizará el trabajo. Un vacío lleno antes de todo parece ser inútil, a menos que el clúster y / o la reindexación no liberen tuplas muertas

Aislan Luiz Wendling
fuente
Como se menciono en la respuesta aceptada, la documentación no decir que los índices se reconstruirán, pero no en la página sobre el comando cluster.
ÁRBOL
Y ambos, CLUSTERy VACUUM FULLproduce una nueva tabla física, simplemente no puede haber ningún muerto después de ella. El espacio utilizado por la copia anterior se liberará al final de la operación.
dezso
En efecto. Recrea la tabla y todos los índices. Pero tengo una duda sobre el índice que utiliza el Cluster para reordenar la tabla. Se reindexará primero o se usará para reordenar la tabla como está. ¿Y después de eso se recrea el índice? Porque un índice problemático podría generar algunos problemas ...
Aislan Luiz Wendling