Estos parámetros controlan el comportamiento del vaciado (vacuuming). Para obtener más información sobre el propósito y las responsabilidades del vacuum, consulta la Section 24.1.
Estos ajustes controlan el comportamiento de la funcionalidad de autovacuum. Consulta la Section 24.1.6 para obtener más información. Ten en cuenta que muchos de estos ajustes se pueden sobrescribir para cada tabla individualmente; consulta la Parámetros de almacenamiento.
autovacuum (boolean)
#
Controla si el servidor debe ejecutar el
demonio lanzador de autovacuum (autovacuum launcher). Está activado por defecto; sin embargo,
también debe estar habilitado track_counts para
que funcione el autovacuum.
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor; sin embargo, el autovacuum se puede
desactivar para tablas individuales cambiando los parámetros de almacenamiento de la tabla.
Ten en cuenta que incluso cuando este parámetro está desactivado, el sistema lanzará procesos de autovacuum si es necesario para evitar la rotación (wraparound) de IDs de transacción. Consulta la Section 24.1.5 para obtener más información.
autovacuum_worker_slots (integer)
#Especifica el número de slots de backend a reservar para los procesos autovacuum worker. El valor predeterminado suele ser de 16 slots, pero podría ser menor si la configuración del núcleo (kernel) no lo soporta (según se determine durante initdb). Este parámetro solo se puede establecer al iniciar el servidor.
Al cambiar este valor, considera también ajustar autovacuum_max_workers.
autovacuum_max_workers (integer)
#
Especifica el número máximo de procesos de autovacuum (distintos del
lanzador de autovacuum) que pueden ejecutarse al mismo tiempo. El valor predeterminado
es 3. Este parámetro solo se puede establecer en el
archivo postgresql.conf o en la línea de comandos del servidor.
Ten en cuenta que un valor para este parámetro que sea mayor que autovacuum_worker_slots no tendrá ningún efecto, ya que los trabajadores de autovacuum se toman del grupo de slots establecido por esa configuración.
autovacuum_naptime (integer)
#
Especifica el retraso mínimo entre ejecuciones de autovacuum en cualquier
base de datos dada. En cada ronda, el demonio examina la
base de datos y emite comandos VACUUM y ANALYZE
según sea necesario para las tablas en esa base de datos.
Si este valor se especifica sin unidades, se toma como segundos.
El valor predeterminado es un minuto (1min).
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor.
autovacuum_vacuum_threshold (integer)
#
Especifica el número mínimo de tuplas actualizadas o eliminadas necesarias
para activar un VACUUM en cualquier tabla.
El valor predeterminado es 50 tuplas.
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor;
pero la configuración se puede sobrescribir para tablas individuales cambiando
los parámetros de almacenamiento de la tabla.
autovacuum_vacuum_insert_threshold (integer)
#
Especifica el número de tuplas insertadas necesarias para activar un
VACUUM en cualquier tabla.
El valor predeterminado es 1000 tuplas. Si se especifica -1, autovacuum no
activará una operación de VACUUM en ninguna tabla basándose en
el número de inserciones.
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor;
pero la configuración se puede sobrescribir para tablas individuales cambiando
los parámetros de almacenamiento de la tabla.
autovacuum_analyze_threshold (integer)
#
Especifica el número mínimo de tuplas insertadas, actualizadas o eliminadas
necesarias para activar un ANALYZE en cualquier tabla.
El valor predeterminado es 50 tuplas.
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor;
pero la configuración se puede sobrescribir para tablas individuales cambiando
los parámetros de almacenamiento de la tabla.
autovacuum_vacuum_scale_factor (floating point)
#
Especifica una fracción del tamaño de la tabla a añadir a
autovacuum_vacuum_threshold
al decidir si se activa un VACUUM.
El valor predeterminado es 0.2 (20% del tamaño de la tabla).
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor;
pero la configuración se puede sobrescribir para tablas individuales cambiando
los parámetros de almacenamiento de la tabla.
autovacuum_vacuum_insert_scale_factor (floating point)
#
Especifica una fracción de las páginas no congeladas en la tabla a añadir a
autovacuum_vacuum_insert_threshold al decidir si
se activa un VACUUM. El valor predeterminado es
0.2 (20% de las páginas no congeladas en la tabla). Este
parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor; pero la configuración se puede sobrescribir
para tablas individuales cambiando los parámetros de almacenamiento de la tabla.
autovacuum_analyze_scale_factor (floating point)
#
Especifica una fracción del tamaño de la tabla a añadir a
autovacuum_analyze_threshold
al decidir si se activa un ANALYZE.
El valor predeterminado es 0.1 (10% del tamaño de la tabla).
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor;
pero la configuración se puede sobrescribir para tablas individuales cambiando
los parámetros de almacenamiento de la tabla.
autovacuum_vacuum_max_threshold (integer)
#
Especifica el número máximo de tuplas actualizadas o eliminadas necesarias para
activar un VACUUM en cualquier tabla, es decir, un límite en el
valor calculado con
autovacuum_vacuum_threshold y
autovacuum_vacuum_scale_factor. El valor predeterminado es
100,000,000 tuplas. Si se especifica -1, autovacuum no aplicará un número
máximo de tuplas actualizadas o eliminadas que activará una operación
de VACUUM. Este parámetro solo se puede establecer
en el archivo postgresql.conf o en la línea de comandos
del servidor; pero la configuración se puede sobrescribir para tablas individuales
cambiando los parámetros de almacenamiento.
autovacuum_freeze_max_age (integer)
#
Especifica la edad máxima (en transacciones) que el campo
pg_class.relfrozenxid de una tabla
puede alcanzar antes de que se fuerce una operación VACUUM
para evitar la rotación (wraparound) de IDs de transacción en la tabla.
Ten en cuenta que el sistema lanzará procesos de autovacuum para
evitar la rotación incluso cuando el autovacuum esté desactivado por lo demás.
El vaciado también permite la eliminación de archivos antiguos del
subdirectorio pg_xact, razón por la cual el valor
predeterminado es de un nivel relativamente bajo de 200 millones de transacciones.
Este parámetro solo se puede establecer al iniciar el servidor, pero la configuración
se puede reducir para tablas individuales cambiando los parámetros de almacenamiento
de la tabla.
Para obtener más información, consulta la Section 24.1.5.
autovacuum_multixact_freeze_max_age (integer)
#
Especifica la edad máxima (en multixacts) que el campo
pg_class.relminmxid de una tabla
puede alcanzar antes de que se fuerce una operación VACUUM para
evitar la rotación (wraparound) de IDs de multixact en la tabla.
Ten en cuenta que el sistema lanzará procesos de autovacuum para
evitar la rotación incluso cuando el autovacuum esté desactivado por lo demás.
El vaciado de multixacts también permite la eliminación de archivos antiguos de los
subdirectorios pg_multixact/members y pg_multixact/offsets,
razón por la cual el valor predeterminado es de un nivel relativamente bajo de
400 millones de multixacts.
Este parámetro solo se puede establecer al iniciar el servidor, pero la configuración se
puede reducir para tablas individuales cambiando los parámetros de almacenamiento de la tabla.
Para obtener más información, consulta la Section 24.1.5.1.
autovacuum_vacuum_cost_delay (floating point)
#
Especifica el valor del retraso por coste que se utilizará en las operaciones
automáticas de VACUUM. Si se especifica -1, se utilizará el valor
habitual de vacuum_cost_delay.
Si este valor se especifica sin unidades, se toma como milisegundos.
El valor predeterminado es de 2 milisegundos.
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor;
pero la configuración se puede sobrescribir para tablas individuales cambiando
los parámetros de almacenamiento de la tabla.
autovacuum_vacuum_cost_limit (integer)
#
Especifica el valor del límite de coste que se utilizará en las operaciones
automáticas de VACUUM. Si se especifica -1
(que es el valor predeterminado), se utilizará el valor habitual de
vacuum_cost_limit. Ten en cuenta que
el valor se distribuye proporcionalmente entre los trabajadores de autovacuum en ejecución,
si hay más de uno, de modo que la suma de los límites de cada trabajador no
supere el valor de esta variable.
Este parámetro solo se puede establecer en el archivo postgresql.conf
o en la línea de comandos del servidor;
pero la configuración se puede sobrescribir para tablas individuales cambiando
los parámetros de almacenamiento de la tabla.
Durante la ejecución de los comandos VACUUM
y ANALYZE, el sistema mantiene un
contador interno que realiza el seguimiento del coste estimado de las
diversas operaciones de E/S que se realizan. Cuando el coste acumulado
alcanza un límite (especificado por
vacuum_cost_limit), el proceso que realiza
la operación se suspenderá durante un corto período de tiempo, según lo especificado por
vacuum_cost_delay. Luego, restablecerá el
contador y continuará con la ejecución.
El propósito de esta funcionalidad es permitir a los administradores reducir
el impacto de E/S de estos comandos en la actividad concurrente de la base de datos.
Hay muchas situaciones en las que no es
importante que los comandos de mantenimiento como
VACUUM y ANALYZE terminen
rápidamente; sin embargo, por lo general es muy importante que estos
comandos no interfieran significativamente con la capacidad del
sistema para realizar otras operaciones de base de datos. El retraso de vacuum
basado en coste proporciona una forma para que los administradores logren esto.
Esta funcionalidad está desactivada por defecto para los comandos
VACUUM emitidos manualmente. Para habilitarla, establece la
variable vacuum_cost_delay en un valor diferente de cero.
vacuum_cost_delay (floating point)
#
La cantidad de tiempo que el proceso dormirá cuando se haya superado
el límite de coste. Si este valor se especifica sin unidades, se toma
como milisegundos. El valor predeterminado es
0, lo que desactiva la funcionalidad de retraso de vacuum
basado en coste. Los valores positivos habilitan el vaciado basado en coste.
Al utilizar el vaciado basado en coste, los valores adecuados para
vacuum_cost_delay suelen ser bastante pequeños, tal vez
menos de 1 milisegundo. Aunque vacuum_cost_delay
se puede establecer en valores de fracciones de milisegundo, es posible que tales
retrasos no se midan con precisión en plataformas más antiguas. En tales plataformas,
para aumentar el consumo de recursos limitado de VACUUM
por encima de lo que obtienes con 1ms, tendrás que cambiar los otros parámetros de coste
de vacuum. No obstante, debes mantener vacuum_cost_delay
tan pequeño como tu plataforma pueda medir de forma consistente; los retrasos grandes no son útiles.
vacuum_cost_page_hit (integer)
#
El coste estimado para vaciar un búfer que se encuentra en el búfer
caché compartido. Representa el coste de bloquear el pool de búferes,
buscar en la tabla hash compartida y escanear el contenido de la página.
El valor predeterminado es 1.
vacuum_cost_page_miss (integer)
#
El coste estimado para vaciar un búfer que tiene que ser leído desde el
disco. Esto representa el esfuerzo de bloquear el pool de búferes,
buscar en la tabla hash compartida, leer el bloque deseado desde
el disco y escanear su contenido. El valor predeterminado es
2.
vacuum_cost_page_dirty (integer)
#
El coste estimado que se cobra cuando vacuum modifica un bloque que
antes estaba limpio. Representa la E/S adicional requerida para
volver a volcar (flush) el bloque sucio al disco. El valor predeterminado es
20.
vacuum_cost_limit (integer)
#
Este es el coste acumulado que hará que el proceso de vaciado
se duerma durante vacuum_cost_delay. El
valor predeterminado es 200.
Existen ciertas operaciones que retienen bloqueos críticos y, por lo tanto,
deberían completarse lo más rápido posible. Los retrasos de vacuum basados
en coste no ocurren durante tales operaciones. Por lo tanto, es
posible que el coste acumulado sea muy superior al límite especificado.
Para evitar retrasos inútilmente largos en tales casos, el retraso real
se calcula como vacuum_cost_delay *
accumulated_balance /
vacuum_cost_limit con un máximo de
vacuum_cost_delay * 4.
vacuum_truncate (boolean)
#
Habilita o deshabilita que vacuum intente truncar las páginas vacías al
final de la tabla. El valor predeterminado es true.
Si es true, VACUUM y el autovacuum
realizan el truncamiento y el espacio en disco de las páginas truncadas se
devuelve al sistema operativo. Ten en cuenta que el truncamiento requiere
un bloqueo ACCESS EXCLUSIVE en la tabla. El
parámetro TRUNCATE de
VACUUM, si se
especifica, sobrescribe el valor de este parámetro. La configuración también
se puede sobrescribir para tablas individuales cambiando los parámetros de almacenamiento
de la tabla.
Para mantener la corrección incluso después de que los IDs de transacción roten (wrap around),
PostgreSQL marca las filas que son lo suficientemente
antiguas como congeladas (frozen). Estas filas son visibles para todos;
otras transacciones no necesitan examinar su XID de inserción para
determinar la visibilidad. VACUUM es responsable de
marcar las filas como congeladas. Los siguientes ajustes controlan el comportamiento de
congelación de VACUUM y deben ajustarse en función del
ritmo de consumo de XID del sistema y los patrones de acceso a los datos de las cargas
de trabajo dominantes. Consulta la Section 24.1.5 para obtener más
información sobre la rotación de IDs de transacción y cómo ajustar estos parámetros.
vacuum_freeze_table_age (integer)
#
VACUUM realiza un escaneo agresivo si el campo
pg_class.relfrozenxid de la tabla ha alcanzado
la edad especificada por este ajuste. Un escaneo agresivo se diferencia de
un VACUUM regular en que visita cada página que pueda
contener XIDs o MXIDs no congelados, no solo aquellas que puedan contener tuplas
muertas. El valor predeterminado es 150 millones de transacciones. Aunque los usuarios pueden
establecer este valor en cualquier rango desde cero hasta dos mil millones, VACUUM
limitará silenciosamente el valor efectivo al 95% de
autovacuum_freeze_max_age, de modo que un
VACUUM manual periódico tenga la oportunidad de ejecutarse antes de que se
lance un autovacuum de prevención de rotación para la tabla. Para obtener más
información, consulta la
Section 24.1.5.
vacuum_freeze_min_age (integer)
#
Especifica la edad límite (en transacciones) que
VACUUM debe utilizar para decidir si
debe congelar filas en páginas que tienen un XID más antiguo.
El valor predeterminado es 50 millones de transacciones. Aunque los
usuarios pueden establecer este valor en cualquier rango desde cero hasta mil millones,
VACUUM limitará silenciosamente el valor efectivo a la mitad
del valor de autovacuum_freeze_max_age, para
que no haya un tiempo irrazonablemente corto entre autovacuums forzados.
Para obtener más información, consulta la Section 24.1.5.
vacuum_failsafe_age (integer)
#
Especifica la edad máxima (en transacciones) que el campo
pg_class.relfrozenxid de una tabla
puede alcanzar antes de que VACUUM tome
medidas extraordinarias para evitar un fallo por rotación de IDs de transacción
en todo el sistema. Esta es la estrategia de último recurso de VACUUM.
El sistema a prueba de fallos (failsafe) suele activarse cuando un autovacuum para evitar
la rotación de IDs de transacción ya ha estado ejecutándose durante algún tiempo,
aunque es posible que se active durante cualquier VACUUM.
Cuando se activa el sistema a prueba de fallos, cualquier retraso basado en coste que esté
en vigor ya no se aplicará, se omitirán otras tareas de mantenimiento no esenciales
(como el vaciado de índices) y se desactivará cualquier
Buffer Access Strategy
en uso, lo que permitirá que VACUUM tenga la libertad
de utilizar todos los shared buffers.
El valor predeterminado es 1.6 mil millones de transacciones. Aunque los usuarios pueden
establecer este valor en cualquier rango desde cero hasta 2.1 mil millones,
VACUUM ajustará silenciosamente el valor efectivo
a no menos del 105% de autovacuum_freeze_max_age.
vacuum_multixact_freeze_table_age (integer)
#
VACUUM realiza un escaneo agresivo si el campo de la tabla
pg_class.relminmxid field has reached
the age specified by this setting. An aggressive scan differs from
un VACUUM regular en que visita cada página que pueda
contener XIDs o MXIDs no congelados, no solo aquellas que puedan contener tuplas
muertas. El valor predeterminado es 150 millones de multixacts.
Aunque los usuarios pueden establecer este valor en cualquier rango desde cero hasta dos mil millones,
VACUUM limitará silenciosamente el valor efectivo al 95% de
autovacuum_multixact_freeze_max_age, de modo que un
VACUUM manual periódico tenga la oportunidad de ejecutarse antes de que se
lance un autovacuum de prevención de rotación para la tabla.
Para obtener más información, consulta la Section 24.1.5.1.
vacuum_multixact_freeze_min_age (integer)
#
Especifica la edad límite (en multixacts) que VACUUM
debe utilizar para decidir si debe congelar páginas con
un ID de multixact más antiguo. El valor predeterminado es 5 millones de multixacts.
Aunque los usuarios pueden establecer este valor en cualquier rango desde cero hasta mil millones,
VACUUM limitará silenciosamente el valor efectivo a la mitad
del valor de autovacuum_multixact_freeze_max_age,
para que no haya un tiempo irrazonablemente corto entre autovacuums forzados.
Para obtener más información, consulta la Section 24.1.5.1.
vacuum_multixact_failsafe_age (integer)
#
Especifica la edad máxima (en multixacts) que el campo
pg_class.relminmxid de una tabla
puede alcanzar antes de que VACUUM tome
medidas extraordinarias para evitar un fallo por rotación de IDs de multixact
en todo el sistema. Esta es la estrategia de último recurso de VACUUM.
El sistema a prueba de fallos (failsafe) suele activarse cuando un autovacuum para evitar
la rotación de IDs de transacción ya ha estado ejecutándose durante algún tiempo,
aunque es posible que se active durante cualquier VACUUM.
Cuando se activa el sistema a prueba de fallos, cualquier retraso basado en coste que esté en vigor ya no se aplicará y se omitirán las tareas de mantenimiento no esenciales (como el vaciado de índices).
El valor predeterminado es 1.6 mil millones de multixacts. Aunque los usuarios pueden establecer
este valor en cualquier rango desde cero hasta 2.1 mil millones,
VACUUM ajustará silenciosamente el valor efectivo
a no menos del 105% de autovacuum_multixact_freeze_max_age.
vacuum_max_eager_freeze_failure_rate (floating point)
#
Especifica el número máximo de páginas (como una fracción del total de páginas de la
relación) que VACUUM puede escanear y
fallar en establecer como enteramente congeladas (all-frozen) en el visibility map
antes de desactivar el escaneo ansioso (eager scanning). Un valor de 0
desactiva el escaneo ansioso por completo. El valor predeterminado es
0.03 (3%).
Ten en cuenta que cuando el escaneo ansioso está habilitado, solo los fallos de congelación cuentan para el límite, no la congelación exitosa. Las congelaciones exitosas de páginas están limitadas internamente al 20% de las páginas visibles pero no congeladas en la relación. Limitar las congelaciones exitosas ayuda a amortizar el coste general en múltiples vaciados normales y limita el inconveniente potencial de congelaciones ansiosas desperdiciadas en páginas que se modifican nuevamente antes del próximo vaciado agresivo.
Este parámetro solo se puede establecer en el
archivo postgresql.conf o en la línea de comandos
del servidor; pero la configuración se puede sobrescribir para tablas individuales
cambiando el
parámetro de almacenamiento correspondiente de la tabla.
Para obtener más información sobre cómo ajustar el comportamiento de congelación de vacuum,
consulta la Section 24.1.5.