¿Todavía se recomienda el ANÁLISIS DE VACÍO regular en 9.1?

Estoy usando PostgreSQL 9.1 en Ubuntu. ¿ VACUUM ANALYZETodavía se recomiendan los horarios programados , o es suficiente el vacío automático para satisfacer todas las necesidades?

Si la respuesta es "depende", entonces:

• Tengo una gran base de datos (tamaño de volcado comprimido de 30 GiB, directorio de datos de 200 GiB)
• Hago ETL en la base de datos, importando cerca de 3 millones de filas por semana
• Todas las tablas con los cambios más frecuentes se heredan de una tabla maestra, sin datos en la tabla maestra (los datos se dividen por semana)
• Creo paquetes acumulativos por hora y, a partir de ahí, informes diarios, semanales y mensuales.

Lo pregunto porque lo programado VACUUM ANALYZEestá afectando mis informes. Funciona durante más de 5 horas, y tuve que matarlo dos veces esta semana, porque estaba afectando las importaciones regulares de bases de datos. check_postgresno informa ninguna hinchazón significativa en la base de datos, por lo que no es realmente un problema.

Desde los documentos, autovacuum también debe ocuparse de la identificación de la transacción. La pregunta es: ¿todavía necesito un VACUUM ANALYZE?

VACUUM solo se necesita en filas actualizadas o eliminadas en tablas no temporales. Obviamente, está haciendo muchos INSERTOS, pero no es obvio por la descripción que también está haciendo un montón de ACTUALIZACIONES o DELETES.

Estas operaciones se pueden rastrear con la pg_stat_all_tablesvista, específicamente las columnas n_tup_updy n_tup_del. Además, aún más al punto, hay una n_dead_tupcolumna que indica, por tabla, cuántas filas deben aspirarse. (Ver Estadísticas de monitoreo en el documento para funciones y vistas relacionadas con la recopilación de estadísticas).

Una posible estrategia en su caso sería suprimir el VACÍO programado, vigilando esta vista y comprobando en qué tablas n_dead_tupestá subiendo significativamente. Luego aplique el VACÍO agresivo solo a estas tablas. Esto será una victoria si hay tablas grandes cuyas filas nunca se eliminan ni actualizan y el agresivo VACÍO es realmente necesario solo en tablas más pequeñas.

Pero siga ejecutando ANALYZE para que el optimizador siempre tenga estadísticas frescas.

No veo nada en su pregunta que autovacuumno pueda solucionar. Depende en gran medida del patrón de sus actividades de escritura . Usted menciona 3 millones de filas nuevas por semana, pero INSERT(o COPY) generalmente no crea hinchazón de tablas e índices. ( autovacuumsolo tiene que ocuparse de las estadísticas de columna , el mapa de visibilidad y algunos trabajos menores). UPDATEy DELETEson la causa dominante de la hinchazón de tablas e índices, especialmente cuando se dirigen a filas aleatorias. No veo nada de eso en tu pregunta.

autovacuumha recorrido un largo camino y está haciendo un gran trabajo en Postgres 9.1 o posterior. Echaría un vistazo a la autovacuumconfiguración . Si pasar la aspiradora tiende a interferir con su carga de trabajo, eche un vistazo al "Retardo de vacío basado en costos" . La aspiración manual debería ser la rara excepción.

Si tiene muchos correos UPDATEelectrónicos aleatorios , es posible que desee establecer FILLFACTORun valor inferior a 100, para permitir actualizaciones CALIENTES de inmediato y reducir la necesidad de hacerlo VACUUM. Más sobre actualizaciones CALIENTES:

• Datos redundantes en declaraciones de actualización

Tenga en cuenta también que las tablas temporales necesitan manual VACUUMy ANALYZE. Cito el manual sobreCREATE TABLE :

El demonio de vacío automático no puede acceder y, por lo tanto, no puede aspirar o analizar tablas temporales. Por esta razón, las operaciones apropiadas de vacío y análisis deben realizarse a través de comandos SQL de sesión. Por ejemplo, si una tabla temporal se va a utilizar en consultas complejas, es aconsejable ejecutarla ANALYZEen la tabla temporal después de que se complete.

Si bien estoy de acuerdo en que usar las funciones automáticas es mejor en lugar de ejecutarlo en toda la base de datos, en la mayoría de los casos es necesario realizar ajustes por tabla.

No estoy del todo de acuerdo con la elección del diseño de postgres para unir el vacío y el análisis, he visto varias instancias en las que las bases de datos que hacen mucha inserción / actualización pero poca eliminación nunca se analizan y comienzan a funcionar mal.

La solución es ir a las tablas que se usan mucho y están sujetas a grandes consultas y establecer la configuración de análisis automático para esas tablas en algo donde se analizan una vez o cada dos días.

Puede acceder a la configuración por tabla en la interfaz gráfica de usuario en la pestaña de vacío automático y verá analizar la configuración allí que puede establecer independientemente del vacío.

La configuración termina en la tabla de reubicaciones y se puede ver con la consulta

SELECT c.relname, c.reloptions FROM pg_class c where reloptions is not null

y un valor de muestra allí de un análisis agresivo podría ser

{autovacuum_enabled=true,autovacuum_analyze_threshold=10,autovacuum_analyze_scale_factor=.01}

Para ver cuándo fue la última vez que sus tablas obtuvieron una consulta analizada automáticamente

select 
    relname, 
    n_dead_tup, 
    n_tup_ins, 
    n_tup_upd, 
    n_tup_del, 
    last_autoanalyze, 
    autoanalyze_count 
from pg_stat_user_tables 
where last_autoanalyze is not null 
order by last_autoanalyze desc;