Diferencia PostgreSQL entre VACUUM FULL y CLUSTER


13

Tengo una tabla con 200 GB de tamaño ocupada por datos y 180 GB de tamaño por los 6 índices. Tiene un 30% de hinchazón, por lo que quiero recuperar el espacio no deseado que ocupa. Se agrupa en el job_id_idíndice x.

Entonces, para recuperar el espacio, ¿debo usar el clustercomando o el vacuum fullcomando?

  1. ¿Cuál es la diferencia entre estos dos comandos?

  2. ¿El vacuum fullorden por alguna columna es igual al clustercomando?

  3. ¿Se recrea el índice en ambos comandos?

  4. En mi caso, ¿cuál será más rápido?

La versión de la base de datos PostgreSQL es 9.1


1
Sí, los índices serán recreados. Lo que es más rápido depende de algunas cosas, me imagino. Pero una cosa es segura: no hay nada como 'ordenar por vacío una columna'.
dezso

1
Permítanme mencionar también que VACUUM no puede ejecutarse dentro de una transacción que, en muchos casos, hace de CLUSTER una mejor alternativa (y a veces la única alternativa) que produce resultados similares.
2015

Respuestas:


8

Para comprobar qué CLUSTERhace, tomé una tabla mía de un experimento anterior que básicamente contenía los primeros 10 millones de enteros positivos. Ya eliminé algunas filas y también hay otra columna, pero estas solo afectan el tamaño real de la tabla, por lo que no es tan interesante.

Primero, después de correr VACUUM FULLsobre la mesa fka, tomé su tamaño:

\dt+ fka
                    List of relations
 Schema | Name | Type  |  Owner   |  Size  | Description 
--------+------+-------+----------+--------+-------------
 public | fka  | table | test     | 338 MB | 

Luego, veamos el orden físico de los datos desde el comienzo de la tabla:

SELECT *, ctid FROM fka ORDER BY ctid LIMIT 5;

 id  | col1 |  ctid   
-----+------+---------
   2 | 2    | (0,1)
   3 | 3    | (0,2)
   4 | 4    | (0,3)
   5 | 5    | (0,4)
   6 | 6    | (0,5)

Ahora eliminemos algunas filas:

DELETE FROM fka WHERE id % 10 = 5;
--DELETE 1000000

Después de esto, el tamaño de la tabla informada no cambió. Entonces, veamos ahora qué CLUSTERhace:

CLUSTER fka USING fka_pkey;

SELECT *, ctid FROM fka ORDER BY ctid LIMIT 5;

 id  | col1 |  ctid   
-----+------+---------
   2 | 2    | (0,1)
   3 | 3    | (0,2)
   4 | 4    | (0,3)
   6 | 6    | (0,4)
   7 | 7    | (0,5)

Después de la operación, el tamaño de la tabla cambió de 338 a 296 MB. En la ctidcolumna, que describe el lugar físico de la tupla en la página, también ve que no hay ningún espacio donde id = 5solía estar la coincidencia de filas .

A medida que se reordenaron las tuplas, los índices deberían haberse recreado para que apuntaran a los lugares correctos.

Entonces, la diferencia parece ser que VACUUM FULLno ordena las filas. Hasta donde yo sé, hay alguna diferencia en el mecanismo que usan los dos comandos, pero desde un punto de vista práctico, esta parece ser la principal (¿única?) Diferencia.


No estaba seguro de qué es la ctidcolumna. Resulta que es una columna del sistema que describe la ubicación física de la fila dentro de su tabla. postgresql.org/docs/current/ddl-system-columns.html
Gajus

8

VACUUM FULLreescribe todo el contenido de la tabla en un nuevo archivo de disco sin espacio adicional, permitiendo que el espacio no utilizado sea devuelto al sistema operativo. Este método también requiere espacio en disco adicional, ya que escribe una nueva copia de la tabla y no libera la copia anterior hasta que se completa la operación. Por lo general, esto solo debe usarse cuando se necesita reclamar una cantidad significativa de espacio desde dentro de la tabla.

http://www.postgresql.org/docs/9.1/static/sql-vacuum.html

CLUSTERindica a PostgreSQL que agrupe la tabla especificada por table_name en función del índice especificado por index_name. El índice ya debe haber sido definido en table_name. Cuando una tabla se agrupa, se reordena físicamente en función de la información del índice y se adquiere un bloqueo ACCESS EXCLUSIVE en ella.

http://www.postgresql.org/docs/9.1/static/sql-cluster.html

también interesante: is-a-reindex-required-after-cluster

Pero tal vez todo lo que necesita es un simple REINDEXque reconstruya un índice utilizando los datos almacenados en la tabla del índice, reemplazando la copia anterior del índice.

http://www.postgresql.org/docs/9.1/static/sql-reindex.html


1
Woah! ¡Un buen consejo sobre el REINDEX también! VACUUM y CLUSTER han reducido algunas tablas (tratando de comparar los tiempos y los impactos para hacerlo en vivo) y ahora mis objetos más grandes son en realidad índices.
Mike
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.