¿Cancelar un proceso (AUTO) VACUUM en PostgreSQL hace que todo el trabajo realizado sea inútil?

En algunas ocasiones, y después de hacer una masiva update, inserto deletedesde una mesa, comencé VACUUM FULL ANALYZEa asegurarme de que el DB no se hinchara demasiado. Hacerlo en una base de datos de producción me ha permitido descubrir que no era una buena idea, porque podía bloquear la tabla durante un largo período de tiempo. Entonces, cancelé el proceso, quizás intenté simplemente VACUUM(no completo) o dejé AUTOVACUUMhacer más tarde lo que sea que pueda hacer.

La pregunta es: si detengo un VACIO o un AUTOVACO "a mitad de camino", ¿se pierde todo el procesamiento?

Por ejemplo, si VACUUMya encontré 1 M de filas muertas y lo detengo, ¿se pierde toda esta información? ¿VACUUM funciona de una manera totalmente transaccional ("todo o nada", como una muy buena cantidad de procesos PostgreSQL)?

Si VACUUM se puede interrumpir de forma segura sin perder todo el trabajo, ¿hay alguna forma de hacer que el vacuumtrabajo sea incremental? [Trabaje durante 100 ms, pare, espere 10 ms para permitir que no se bloquee el resto del mundo ... y así sucesivamente]. Sé que puede hacer parte de esto ajustando los parámetros de vacío automático, pero estoy pensando en la línea de poder controlar esto mediante programación, para poder hacerlo en ciertos momentos / bajo ciertas condiciones.

NOTA: Detener / cancelar / eliminar el proceso significa en este contexto:

Si usa pgAdmin, presione el botón "Cancelar consulta".
Si trabaja mediante programación, llame a pg_cancel_backend ().

Supongo que ambos son equivalentes. No he usado ningún comando de matar a nivel de shell / sistema.

— joanolo
fuente

El trabajo realizado por un VACUUM FULL interrumpido se perderá por completo, ya que simplemente volverá a usar la versión anterior de la tabla y tirará la versión en progreso de la tabla.

El trabajo realizado por un VACÍO regular (no COMPLETO) podría no perderse por completo. Limpia los índices en lotes, y no será necesario volver a limpiar los lotes que se hayan limpiado completamente. Aún deberán ser inspeccionados nuevamente, pero la próxima vez se encontrarán limpios. Por lo tanto, puede guardar algunos IO de escritura que no será necesario repetir.

— jjanes
fuente

Me encantaría tener más detalles sobre esto, particularmente en autovacuum. Tengo servidores ocupados con muchas bases de datos y, a veces, las aspiradoras automáticas pueden llevar mucho tiempo. Cuando eso sucede, crear un nuevo índice, por ejemplo, es imposible porque el vacío automático tiene un bloqueo. Sería ideal en algunos casos matar el autovacío y aplicar el índice y luego, con suerte, cuando el autovacío se ejecute nuevamente, no tendrá que funcionar durante casi el mismo tiempo. ¿Alguna forma de ver detalles de lo que ha hecho / está haciendo Autovacuum en una tabla e índices?

— Kurt Koller el

9.6 incorporó una vista para monitorear el progreso del vacío: postgresql.org/docs/current/static/progress-reporting.html . No he jugado con eso yo mismo, así que no sé qué tan bien funcionará para usted. El vacío automático debería ceder el paso a la cerradura automáticamente, a menos que se haga para envolver. La configuración predeterminada para el vacío automático está muy acelerada, por lo que es posible que no se ejecute más rápido la próxima vez solo porque se está acelerando a la misma velocidad. Establezco rutinariamente vacuum_cost_page_hity vacuum_cost_page_missa cero.

— jjanes