Ejemplo de Postgresql REINDEX

REINDEX – reconstruir índices

Sinopsis

REINDEX [(option[,...])]  INDEX [ CONCURRENTLY ] name

whereoption can be one of:

    VERBOSE

Descripción

REINDEX reconstruye un índice utilizando los datos almacenados en la tabla del índice, reemplazando la copia anterior del índice. Hay varios escenarios en los que usar 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 convertido “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. Consulte la Sección 24.2 para obtener más información.

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

• Si una compilación de índice falla con el CONCURRENTLY opción, este índice se deja como “inválido“. Tales índices son inútiles pero pueden ser convenientes de usar REINDEX para reconstruirlos. Tenga en cuenta que solo REINDEX INDEX puede realizar una compilación simultánea en un índice no válido.

Parámetros

INDEX

Vuelva a crear el índice especificado.

TABLE

Vuelva a crear todos los índices de la tabla especificada. Si la mesa tiene un secundario “BRINDIS“ tabla, que también se vuelve a indexar.

SCHEMA

Vuelva a crear todos los índices del esquema especificado. Si una tabla de este esquema tiene una secundaria “BRINDIS“ tabla, que también se vuelve a indexar. También se procesan los índices de los catálogos de sistemas compartidos. Esta forma de REINDEX no se puede ejecutar dentro de un bloque de transacciones.

DATABASE

Recrear todos los índices dentro de la base de datos actual. También se procesan los índices de los catálogos de sistemas compartidos. Esta forma de REINDEX no se puede ejecutar dentro de un bloque de transacciones.

SYSTEM

Vuelva a crear todos los índices en los catálogos del sistema dentro de la base de datos actual. Se incluyen índices en catálogos de sistemas compartidos. Los índices de las tablas de usuario no se procesan. Esta forma de REINDEX no se puede ejecutar dentro de un bloque de transacciones.

name

El nombre del índice, la tabla o la base de datos específicos que se van a volver a indexar. Los nombres de índices y tablas pueden estar calificados por esquema. Ahora, REINDEX DATABASE y REINDEX SYSTEM solo puede reindexar la base de datos actual, por lo que su parámetro debe coincidir con el nombre de la base de datos actual.

CONCURRENTLY

Cuando se usa esta opción, PostgreSQL reconstruirá el índice sin tomar ningún bloqueo que evite inserciones, actualizaciones o eliminaciones simultáneas en la tabla; mientras que una reconstrucción de índice estándar bloquea las escrituras (pero no las lecturas) en la tabla hasta que se hace. Hay varias advertencias que debe tener en cuenta al utilizar esta opción; consulte Reconstrucción de índices simultáneamente a continuación.

Para tablas temporales, REINDEX es siempre no concurrente, ya que ninguna otra sesión puede acceder a ellos, y la reindexación no concurrente es más barata.

VERBOSE

Imprime un informe de progreso a medida que se vuelve a indexar cada índice.

Notas

Si sospecha la corrupción de un índice en una tabla de usuario, simplemente puede reconstruir ese índice, o todos los índices en la tabla, usando REINDEX INDEX o REINDEX TABLE.

Las cosas son más difíciles si necesita recuperarse de la corrupción de un índice en una tabla del sistema. En este caso, es importante que el sistema no haya utilizado ninguno de los índices sospechosos. (De hecho, en este tipo de escenario, es posible que los procesos del servidor se bloqueen inmediatamente al inicio, debido a la dependencia de los índices dañados). Para recuperarse de manera segura, el servidor debe iniciarse con el -P opción, que le impide utilizar índices para las búsquedas del catálogo del sistema.

Una forma de hacer esto es apagar el servidor e iniciar un servidor PostgreSQL de un solo usuario con el -P opción incluida en su línea de comando. Luego, REINDEX DATABASE, REINDEX SYSTEM, REINDEX TABLE, o REINDEX INDEX se puede emitir, dependiendo de cuánto desee reconstruir. En caso de duda, utilice REINDEX SYSTEM para seleccionar la reconstrucción de todos los índices del sistema en la base de datos. Luego salga de la sesión del servidor de usuario único y reinicie el servidor normal. Consulte la página de referencia de postgres para obtener más información sobre cómo interactuar con la interfaz del servidor de usuario único.

Alternativamente, se puede iniciar una sesión regular del servidor con -P incluido en sus opciones de línea de comando. El método para hacer esto varía entre los clientes, pero en todos los clientes basados ​​en libpq, es posible configurar el PGOPTIONS variable de entorno a -P antes de iniciar el cliente. Tenga en cuenta que si bien este método no requiere bloquear a otros clientes, podría ser conveniente evitar que otros usuarios se conecten a la base de datos dañada hasta que se hayan completado las reparaciones.

REINDEX es similar a colocar y volver a crear el índice en el sentido de que el contenido del índice se reconstruye desde cero. Sin embargo, las consideraciones de bloqueo son bastante diferentes. REINDEX bloquea las escrituras pero no las lecturas de la tabla principal del índice. También tiene un bloqueo exclusivo en el índice específico que se está procesando, lo que bloqueará las lecturas que intenten usar ese índice. A diferencia de, DROP INDEX momentáneamente toma un bloqueo exclusivo en la tabla principal, bloqueando tanto las escrituras como las lecturas. El posterior CREATE INDEX bloquea las escrituras pero no las lecturas; dado que el índice no está allí, ninguna lectura intentará usarlo, lo que significa que no habrá bloqueo, pero las lecturas podrían verse obligadas a costosos escaneos secuenciales.

Volver a indexar un solo índice o tabla requiere ser el propietario de ese índice o tabla. Volver a indexar un esquema o base de datos requiere ser el propietario de ese esquema o base de datos. Tenga en cuenta específicamente que, por lo tanto, es posible que los no superusuarios reconstruyan índices de tablas propiedad de otros usuarios. Sin embargo, como excepción especial, cuando REINDEX DATABASE, REINDEX SCHEMA o REINDEX SYSTEM es emitido por un usuario que no es un superusuario, los índices de los catálogos compartidos se omitirán a menos que el usuario sea el propietario del catálogo (lo que normalmente no será el caso). Por supuesto, los superusuarios siempre pueden volver a indexar cualquier cosa.

No se admite la reindexación de tablas particionadas o índices particionados. En su lugar, cada partición individual se puede volver a indexar por separado.

Reconstruir índices simultáneamente

La reconstrucción de un índice puede interferir con el funcionamiento normal de una base de datos. Normalmente, PostgreSQL bloquea la tabla cuyo índice se reconstruye contra escrituras y realiza toda la construcción del índice con un solo escaneo de la tabla. Otras transacciones aún pueden leer la tabla, pero si intentan insertar, actualizar o eliminar filas en la tabla, se bloquearán hasta que finalice la reconstrucción del índice. Esto podría tener un efecto severo si el sistema es una base de datos de producción en vivo. Las tablas muy grandes pueden tardar muchas horas en indexarse, e incluso para tablas más pequeñas, una reconstrucción de índice puede bloquear a los escritores durante períodos que son inaceptablemente largos para un sistema de producción.

PostgreSQL admite la reconstrucción de índices con un bloqueo mínimo de escrituras. Este método se invoca especificando el CONCURRENTLY opción de REINDEX. Cuando se usa esta opción, PostgreSQL debe realizar dos escaneos de la tabla para cada índice que necesita ser reconstruido y esperar la terminación de todas las transacciones existentes que potencialmente podrían usar el índice. Este método requiere más trabajo total que una reconstrucción de índice estándar y tarda mucho más en completarse, ya que necesita esperar transacciones sin terminar que podrían modificar el índice. Sin embargo, dado que permite que continúen las operaciones normales mientras se reconstruye el índice, este método es útil para reconstruir índices en un entorno de producción. Por supuesto, la carga adicional de CPU, memoria y E / S impuesta por la reconstrucción del índice puede ralentizar otras operaciones.

Los siguientes pasos ocurren en una reindexación simultánea. Cada paso se ejecuta en una transacción separada. Si hay varios índices para reconstruir, cada paso recorre todos los índices antes de pasar al siguiente paso.

1. Se agrega una nueva definición de índice transitorio al catálogo pg_index. Esta definición se utilizará para reemplazar el índice anterior. A SHARE UPDATE EXCLUSIVE El bloqueo a nivel de sesión se aplica a los índices que se vuelven a indexar, así como a sus tablas asociadas, para evitar cualquier modificación del esquema durante el procesamiento.

2. Se realiza una primera pasada para construir el índice para cada nuevo índice. Una vez que se construye el índice, su bandera pg_index.indisready se cambia a “cierto“ para que esté listo para inserciones, haciéndolo visible para otras sesiones una vez que finalice la transacción que realizó la compilación. Este paso se realiza en una transacción separada para cada índice.

3. Luego, se realiza una segunda pasada para agregar tuplas que se agregaron mientras se ejecutaba la primera pasada. Este paso también se realiza en una transacción separada para cada índice.

4. Todas las restricciones que hacen referencia al índice se cambian para hacer referencia a la nueva definición de índice y se cambian los nombres de los índices. En este punto, pg_index.indisvalid se cambia a “cierto“ para el nuevo índice y para “falso“ para el antiguo, y se realiza una invalidación de caché que hace que todas las sesiones que hacían referencia al índice antiguo se invalidaran.

5. Los viejos índices tienen pg_index.indisready cambiado a “falso“ para evitar nuevas inserciones de tuplas, después de esperar a que se completen las consultas en ejecución que podrían hacer referencia al índice anterior.

6. Se eliminan los índices antiguos. los SHARE UPDATE EXCLUSIVE se liberan los bloqueos de sesión para los índices y la tabla.

Si surge un problema al reconstruir los índices, como una infracción de unicidad en un índice único, el REINDEX El comando fallará, pero dejará un “inválido“ nuevo índice además del preexistente. Este índice se ignorará para fines de consulta porque podría estar incompleto; sin embargo, seguirá consumiendo la sobrecarga de actualización. El psql d El comando informará un índice como INVALID:

postgres=# d tabTable"public.tab"Column|Type| Modifiers
--------+---------+-----------
 col    |integer|
Indexes:
    "idx"btree(col)"idx_ccnew"btree(col) INVALID

Si el índice marcado INVALID tiene el sufijo ccnew, luego corresponde al índice transitorio creado durante la operación concurrente, y el método de recuperación recomendado es eliminarlo usando DROP INDEX, luego intente REINDEX CONCURRENTLY de nuevo. Si, en cambio, el índice no válido tiene un sufijo ccold, corresponde al índice original que no se pudo eliminar; el método de recuperación recomendado es simplemente eliminar dicho índice, ya que la reconstrucción adecuada ha sido exitoso.

Las compilaciones de índices regulares permiten que otras compilaciones de índices regulares en la misma tabla ocurran simultáneamente, pero solo una compilación de índices simultánea puede ocurrir en una tabla a la vez. En ambos casos, mientras tanto, no se permiten otros tipos de modificación de esquema en la tabla. Otra diferencia es que un REINDEX TABLE o REINDEX INDEX El comando se puede ejecutar dentro de un bloque de transacciones, pero REINDEX CONCURRENTLY no poder.

Como cualquier transacción de larga duración, REINDEX en una mesa puede afectar qué tuplas se pueden eliminar por concurrente VACUUM en cualquier otra mesa.

REINDEX SYSTEM no soporta CONCURRENTLY ya que los catálogos del sistema no se pueden volver a indexar al mismo tiempo.

Además, los índices para las restricciones de exclusión no se pueden volver a indexar al mismo tiempo. Si dicho índice se nombra directamente en este comando, se genera un error. Si una tabla o base de datos con índices de restricción de exclusión se vuelve a indexar al mismo tiempo, esos índices se omitirán. (Es posible volver a indexar dichos índices sin la CONCURRENTLY opción.)

Ejemplos de

Reconstruir un solo índice:

REINDEX INDEX my_index;

Reconstruir todos los índices de la mesa. my_table:

REINDEX TABLE my_table;

Reconstruya todos los índices en una base de datos en particular, sin confiar en que los índices del sistema ya sean válidos:

$ export PGOPTIONS="-P"
$ psql broken_db
...
broken_db=> REINDEX DATABASE broken_db;
broken_db=> q

Reconstruir índices para una tabla, sin bloquear las operaciones de lectura y escritura en las relaciones involucradas mientras la reindexación está en progreso:

REINDEX TABLE CONCURRENTLY my_broken_table;

Compatibilidad

No hay REINDEX comando en el estándar SQL.

Ver también

CREAR ÍNDICE, SOLTAR ÍNDICE, reindexdb