En primer lugar sería recomendable, para todos los usuarios que quieran proseguir con la lectura de este pequeño manual, que echaran previamente un vistazo a Configuración básica, donde el webmaster introduce muchos de los conceptos que cualquiera que pretenda administrar esta base de datos necesitará conocer, y expone una visión global de los ficheros implicados en esta, en ocasiones, ardua tarea.

Esta entrada pretende ir un paso más allá en determinados parámetros del archivo de configuración de PostgreSQL, postgresql.conf, con la sana intención de que el lector entienda qué significan y las implicaciones que puede conllevar su modificación. Así pues pongámonos manos a la obra, ofreciendo los entresijos de gran parte de las opciones de dicho archivo en su versión 9.0.

Conexiones y autenticación

En esta sección es posible configurar las opciones de acceso desde un punto de vista de los servicios levantados por el motor, además es importante subrayar que, en su configuración inicial, PostgreSQL sólo puede ser accedido desde socket unix, sin puertos TCP/IP abiertos.

authentication_timeout

Define el tiempo que un cliente tiene para completar la autenticación antes de que se desconecte automáticamente, de forma predeterminada son 60 segundos. Un valor adecuado sería entre 15 y 30 segundos, de esa forma nos evitaríamos usuarios que establecen conexiones sin autenticarse y que ocupan conexiones que no podrán ser usadas por otros.

listen_addresses

Establece las direcciones desde las que se escucharán conexiones a PostgreSQL. Por defecto es *, lo que implica que permitirá peticiones desde cualquier IP, aunque puede indicar direcciones específicas si desea filtrar esto. Sin embargo, es importante recalcar que este parámetro no sirve para posibilitar la conexión, únicamente para indicar desde dónde se permite la petición.

max_connections

Indica el número de conexiones simultáneas permitidas, su valor por defecto es 100. El aumento de este número incrementará el consumo de recursos del sistema, en particular, la cantidad de memoria compartida.

port

Puerto por el que PostgreSQL acepta conexiones. Por defecto es el 5432.

superuser_reserved_connections

Establece el máximo número de conexiones que están reservadas para superusuarios, de forma predeterminada son 3. Es posible que desee aumentar la cantidad para asegurar que a un superusuario nunca se le impida la conexión a la base de datos, a pesar de que múltiples usuarios normales estén utilizándola.

Uso de recursos

En esta sección se puede especificar la cantidad de recursos que PostgreSQL está autorizado a consumir. También en éste apartado se tratarán los parámetros que controlan el background writer, proceso que se encarga de actualizar los cambios llevados a cabo, de forma que, la información sobre los registros nuevos o modificados de shared_buffers, sean actualizados de manera casi inmediata.

La importancia de éste proceso radica en que, si bien, el parámetro checkpoint_segments provoca la actualización “real” en base de datos, durante el intervalo en el que éste tiene lugar, el background writer puede haber actualizado la misma información varias veces, lo que hará que sea el “último cambio” el que se almacene realmente en base datos.

bgwriter_delay

Establece el intervalo de tiempo, en milisegundos, en el que se lanzará el background writer. Su valor por defecto es de 200 ms.

bgwriter_lru_maxpages

En cada ejecución del background writer, cuántos buffers serán actualizados (en Linux teclee: show block_size; para conocer el tamaño en bytes de cada uno). Su valor por defecto es de 100 y, poniendo 0 deshabilitaríamos el background writer, salvo cuando estemos ante un pto. de chequeo (ver checkpoint_segments).

maintenance_work_mem

Usada en operaciones del tipo: VACUUM, ANALYZE, CREATE INDEX, ALTER TABLE, ADD FOREIGN KEY. Su valor dependerá mucho del tamaño de nuestras bases de datos aunque, una buena regla en un servidor dedicado, es utilizar alrededor de 50 MB por GB de memoria RAM.

max_prepared_transactions

Establece el número máximo de transacciones preparadas, es decir, aquellas que se gestionan a dos fases (2 phase commit). En la primera se guardan en disco y en la segunda se almacenan realmente en base de datos. Su ventaja es que sobreviven a una caída del servidor una vez superada la primera fase, no obstante, será necesario llevar a cabo la segunda de forma manual si esto ocurre. Su valor por defecto es 0, lo que implica que dicha opción está deshabilitada, si por el contrario, la emplea, es probable que desee tener tantas como max_connections, de modo que cada sesión pueda llegar a tener una operación preparada en espera.
Aumentar este valor implica alrededor de 600 bytes de memoria por incremento, además de lo ya comentado en el parámetro max_locks_per_transaction.

shared_buffers

Este es un parámetro muy importante, que establece y define el tamaño del buffer de memoria que PostgreSQL reservará, como zona de trabajo, en el momento del arranque para procesar las consultas. Por defecto son 32 MB y, si bien la disminución de éste permite ahorrar recursos del sistema en un sistema con poca carga, su aumento se puede mejorar el rendimiento en un sistema de producción muy utilizado. En un servidor dedicado podemos empezar con un 25% del total de nuestra memoria (nunca más del 33%).
Estos buffers (en Linux teclee: show block_size; para conocer el tamaño en bytes de cada uno) se ubican dentro de los denominados segmentos de memoria compartida y es importante saber que la cantidad que pretendamos asignar, nunca podrá exceder al tamaño máximo que tengan los segmentos de memoria. En caso contrario, PostgreSQL se negará a arrancar avisando con un error que no puede reservar el espacio solicitado.

temp_buffers

Hace referencia a la cantidad de memoria utilizada por cada sesión de base de datos para acceder a tablas temporales. El valor por defecto es de 8 MB y, si no emplea dicho tipo de tablas en exceso, no es necesario aumentar éste valor.

vacuum_cost_delay

Tiempo, en milisegundos, que el proceso de VACUUM debe dormir, cuando se ha alcanzado el límite de operaciones fijado por vacuum_cost_limit. Su valor por defecto es 0, lo que provoca que dicho proceso nunca duerma, no obstante, en caso de querer emplear la funcionalidad aportada por este parámetro, lo recomendable en grandes servidores es mantener valores que no superen los 10ms.

vacuum_cost_limit

Durante la ejecución del VACUUM, el sistema mantiene un contador interno, que establece el coste de llevar a cabo cada una de las operaciones del citado comando. El valor de este parámetro establece el número de éstas operaciones que provocarán que el VACUUM duerma el tiempo establecido por vacuum_cost_delay.

work_mem

Usada en operaciones que contengan ORDER BY, DISTINCT, JOINS,... indica la cantidad de memoria que puede utilizar PostgreSQL antes de crear archivos temporales para el procesamiento de los resultados intermedios. El valor por defecto es de 1 MB, si posee tablas muy grandes y mucha memoria, el aumento de este valor puede mejorar el rendimiento. En un servidor dedicado podemos usar un 2-4% del total de nuestra memoria si tenemos pocas sesiones que consuman realmente muchos recursos.

WAL (Write Ahead Log)

PostgreSQL utiliza los denominados ficheros WAL (Write Ahead Log / REDO) para guardar toda la información sobre las transacciones y cambios realizados en la base de datos, así como para garantizar la integridad de los mismos. También emplea estos archivos para reparar automáticamente posibles inconsistencias en la base de datos después de una caída súbita del servidor.

Estos ficheros tienen un nombre único, un tamaño por defecto de 16 MB y se generan en el subdirectorio /pg_xlog que se encuentra en el directorio de datos usado por PostgreSQL.

checkpoint_completion_target

Fue concebido para distribuir uniformemente la ejecución del pto. de chequeo actual (ver checkpoint_segments) durante el período de espera del siguiente. Su valor por defecto es del 0.5, es decir se llevará a cabo el 50% de las operaciones pendientes del pto. de chequeo actual antes de pasar al siguiente. Aumentar el mismo (hasta un máximo de 0.9) puede sobrecargar las operaciones de E/S debido a que el volcado de operaciones pendientes a la base de datos sería mayor.

checkpoint_segments

Este parámetro es muy importante cuando se dan con frecuencia numerosas operaciones de escritura (INSERT, UPDATE, DELETE), esto se debe a que PostgreSQL escribe las nuevas transacciones a la base de datos en archivos llamados segmentos del WAL. Teniendo en cuenta que el valor por defecto de dicho parámetro es 3, implica que cada 48 MB (16 * 3), se lleva a cabo un pto. de chequeo, de manera que los datos del WAL se vuelcan realmente a la base de datos, lo que puede llegar a provocar algunos cuellos de botella.
No obstante, un aumento excesivo del mismo implica una recuperación más lenta ante un fallo en cualquiera de las transacciones, por esta razón, para sistemas de escritura masiva, valores desde 32 (punto de chequeo cada 512 MB) a 256 (cada 128 GB) son los más populares.

checkpoint_timeout

Si bien el parámetro checkpoint_segments servía para indicar la cantidad de memoria del WAL que provoca un pto. de chequeo, éste parámetro lo establece en cuanto al tiempo. Su valor por defecto son 5 minutos.

fsync

Con esta opción a on, PostgreSQL llama a fsync() para asegurarse de que los datos son grabados a disco físicamente después de cada COMMIT por transacción. Esto puede hacer que el rendimiento sea algo menor sin embargo, garantiza que el clúster de base de datos se pueda recuperar a un estado coherente, después de un fallo en el sistema operativo o un accidente de hardware.

synchronous_commit

Especifica si después de que una transacción realice un COMMIT, espera a guardar los registros WAL en disco antes de dar por válidas las operaciones (ver checkpoint_segments). El valor por defecto y, el más seguro, es on.

wal_buffers

Cantidad de la memoria compartida utilizada como buffer para los datos del WAL. El valor por defecto es de 64 kB, aunque tendrá que ajustarlo, para contener la cantidad de información generada para el WAL en una transacción típica, ya que los datos se escriben en el disco en cada confirmación de la transacción. En un entorno de producción una buena aproximación podría ser entre 1 y 16 MB.

wal_sync_method

Método empleado para actualizar las operaciones pendientes a los ficheros de segmentos WAL, aunque si la opción fsync está desactivada, lo que haya especificado aquí no tendrá efecto. Las valores aceptados son:

• open_datasync escribe en los archivos WAL con open() y la opción O_DSYNC.
• fdatasync invoca a fdatasync() tras cada COMMIT.
• fsync invoca a fsync() tras cada COMMIT.
• fsync_writethrough invoca a fsync() tras cada COMMIT, asegurando que la función realmente escribirá sus datos en disco (existen plataformas en donde aun con la opción fsync, no se puede asegurar que los datos realmente se escribieron en disco).
• open_sync escribe en los archivos WAL con open() y la opción O_SYNC.

No todas las opciones están disponibles en todas las plataformas. La instalación de PostgreSQL detectará automáticamente cuál es el valor que se ajusta mejor, salvo en Linux, en donde se establecerá fdatasync.

Ajuste de consultas (Query Tuning)

El planificador de consultas es el módulo de un motor de base de datos que decide como realizar físicamente la operación. PostgreSQL permite la modificación del comportamiento por defecto del planificador, impidiendo que realice ciertas operaciones como: búsqueda por índices, ordenamiento, etc.

constraint_exclusion

Establece si el planificador de consultas utilizará las restricciones de la/s tabla/s incluidas como CHECK. Si está a on, se examinarán las restricciones de todas las tablas, a off, ninguna. Su valor por defecto es partition, lo que implica que únicamente se examinarán cuando se trate de una tabla en la que se haya empleado la herencia.

effective_cache_size

Parámetro usado por el query planner de nuestro motor de bases de datos para optimizar la lectura de datos y mantener en caché las consultas. Un valor alto favorecerá el uso de índices, mientras que uno bajo, las lecturas secuenciales. Se debería configurar en base a la memoria que quede tras establecer el valor de: shared_buffers, sistema operativo y otras aplicaciones, además tenga en cuenta el número esperado de consultas simultáneas en diferentes tablas, ya que tendrá que compartir el espacio disponible. En un servidor dedicado podemos empezar con un 50% del total de nuestra memoria (siendo el máximo aconsejable un 66% del total).

geqo

PostgreSQL incorpora dentro de su analizador de consultas que incluyen JOINs, un algoritmo genético para su optimización, o Generic Query Optimization, para el cual existen opciones que permiten ajustar su comportamiento. Los algoritmos genéticos son una optimización heurística que opera de forma no-determinística, el set de soluciones posibles para el problema se denomina población, mientras que el grado de adaptación de un individuo se llama ajuste.
Las coordenadas del individuo dentro del espacio de soluciones se representa por cromosomas y un gen es una subsección de un cromosoma, el cual codifica el valor de un único parámetro dentro de la optimización. Para obtener la solución se simula la recombinación y mutación de los individuos, realizándose la selección natural en base a aquel individuo que presenta en promedio un mayor grado de adaptación que sus ancestros. El valor por defecto de esta opción es on.

geqo_threshold

Establece el número de elementos del FROM de una consulta que provocarán el uso del optimizador genético (ver geqo). Su valor por defecto es 12 ya que, para consultas más simples es preferible emplear el optimizador por defecto. Sin embargo, para aquellas con demasiados elementos puede ser mejor “perder el tiempo” estudiando todas las opciones posibles mediante éste optimizador quedándose, posteriormente, con la mejor de ellas.

seq_page_cost

Especifica el coste de leer una única página de base de datos en disco de forma secuencial, cuando la información se encuentra contigua en él. Se trata de una estimación y su valor por defecto es 1.0.

random_page_cost

Determina la forma en que el query planner considera los accesos no secuenciales a disco, es decir, cuando las filas involucradas en la orden SQL, se espera que se encuentren repartidas por todo el disco de forma aleatoria. Un valor bajo favorecerá el uso de índices mientras que uno alto, las lecturas secuenciales. Su valor por defecto es 4.0 y, aunque puede ser conveniente reducirlo un poco (a 3.0 por ejemplo), debe recordarse que el uso de índices tiene un costo y nunca será más rápido que el acceso secuencial.

Registro de errores y log

PostgreSQL permite configurar de forma exhaustiva el cómo, cuándo y dónde logear lo que sucede.

client_min_messages

Controla los niveles de mensajes (cantidad de información) que se envía al cliente. Los valores aceptados son: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG, LOG, NOTICE, WARNING, ERROR, FATAL y PANIC. Cada nivel incluye todos los que le siguen y cuanto más a la izquierda esté, menos información se envía. El valor predeterminado es NOTICE.

• DEBUG[5..1] información detallada para los desarrolladores.
• INFO proporciona información implícitamente solicitada por el usuario, por ejemplo, al ejecutar VACUUM VERBOSE.
• NOTICE información que puede ayudar a los usuarios, por ejemplo, cuando se trunca el nombre de un identificador por ser demasiado largo.
• WARNING avisos al usuario, por ejemplo, en caso de hacer un COMMIT fuera de una transacción.
• ERROR informa de un error que ha causado que aborte un comando.
• LOG información interesante para los administradores, por ejemplo, la actividad de los puntos de chequeo.
• FATAL errores que han producido que aborte la sesión.
• PANIC errores que han producido que aborten todas las sesiones del servidor.

log_destination

Indica la salida a la que irán dirigidos los mensajes de log. Por defecto, stderr.

log_directory

Cuando logging_collector está habilitado, este parámetro determina el directorio en el que los archivos de logs se crearán. Se puede especificar como una ruta absoluta o relativa al directorio de datos del clúster.

log_error_verbosity

Gestiona el nivel de detalle que se incluye en cada mensaje añadido al log del servidor. Los valores aceptados son: TERSE, DEFAULT y VERBOSE, cuanto más a la izquierda esté, más información se envía.

log_filename

Cuando logging_collector está habilitado, este parámetro
define los nombres de los archivos de logs creados. El valor se trata como un patrón strftime, por lo que se las variables de tiempo deberán escaparse empleando % (%Y = año, %m = mes, %d = día, etc.).

log_line_prefix

Cadena en formato printf, cuya información equivalente se incluye al comienzo de cada nueva línea del archivo de log. Cada valor ha de escaparse mediante el carácter %, y aquellos que no se reconozcan serán ignorados. Algunos de éstos parámetros sólo estarán disponibles cuando exista una sesión, por lo que no se incluirá su información asociada cuando se loguee información de procesos del sistema.

log_lock_waits

Cuando ocurre un deadlock en el sistema, éste siempre se registra. Sin embargo, poniendo a on este parámetro cada vez que el detector de deadlocks se ponga en marcha (ver deadlock_timeout), y determine que no existe tal, se logeará información acerca de por qué se está esperando. Esto puede ser útil para entender, qué procesos esperan en exceso para poder bloquear y, con ello, terminar su labor.

log_min_duration_statement

Provoca que, todas aquellas instrucciones que hayan durado más tiempo, en milisegundos, que el especificado en dicho parámetro sean logueadas. El valor por defecto es -1, lo que conlleva que nada sea registrado, todo lo contrario ocurrirá si lo cambiamos a 0. Puede llegar a ser útil para identificar aquellas sentencias SQL, que consumen recursos del sistema durante demasiado tiempo.

log_min_error_statement

Controla qué sentencias SQL que hayan generado un error se almacenarán en el log del servidor. Los valores aceptados son: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL y PANIC. Cada nivel incluye todos los que le siguen y cuanto más a la izquierda esté, menos información se envía. El valor predeterminado es ERROR, lo que hará que todas las sentencias SQL que causen un error, un mensaje de log, un fallo grave o detengan todas las sesiones en el servidor, se logueen. Si quisiera desactivar el log puede establecer esta opción en PANIC, lo que hará que prácticamente nada se registre (ver client_min_messages).

log_min_messages

Establece los niveles de mensajes (cantidad de información) que se envía al log del servidor. Los valores aceptados son: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG1, INFO, NOTICE, WARNING, ERROR, LOG, FATAL y PANIC. Cada nivel incluye todos los que le siguen y cuanto más a la izquierda esté, menos información se envía. El valor predeterminado es WARNING (ver client_min_messages).

log_rotation_age

Cuando logging_collector está habilitado, determina el tiempo de vida máximo en minutos de un archivo de log individual, después de éste tiempo un nuevo fichero será creado. Establecer a 0 para deshabilitar la creación basada en el tiempo de los archivos de logs nuevos.

log_rotation_size

Cuando logging_collector está habilitado, determina el tamaño máximo en KB de un archivo de log individual, después de alcanzar este volumen un nuevo fichero será creado. Establecer a 0 para deshabilitar la creación basada en el tamaño de los archivos de logs nuevos.

log_statement

Controla qué sentencias SQL se loguearán. Los valores aceptados son: none, ddl, mod y all, cada nivel incluye a los precedentes.

• ddl registra todas las sentencias de definición de datos como: CREATE, ALTER y DROP
• mod registra las incluidas en ddl y además las modificaciones de datos como: INSERT, UPDATE, DELETE, TRUNCATE y COPY FROM. También PREPARE, EXECUTE y EXPLAIN ANALYZE si incluye algunas de las citadas.
• all las registra todas.

log_truncate_on_rotation

Cuando logging_collector está habilitado, hará que PostgreSQL sobrescriba, en lugar de añadir al final del mismo, cualquier archivo de log existente con el mismo nombre que aquel en el que deba agregar la información. Sin embargo, el truncamiento se producirá sólo cuando un nuevo fichero se abra debido a la rotación en función del tiempo, no durante el inicio del servidor o por una rotación basada en el tamaño.
Por ejemplo, si quisiéramos mantener un log con lo que ha pasado los últimos 7 días, teniendo un archivo diario: log_server.Mon, log_server.Tue, etc. deberemos establecer la siguiente configuración:

logging_collector on
log_rotation_age 1440
log_truncate_on_rotation on
log_filename log_server.%a


logging_collector

Será necesario habilitarlo si queremos capturar los mensajes enviados por PostgreSQL y redirigirlos, por ejemplo, a un archivo de logs. El colector de registro está diseñado para no perder mensajes, esto significa que en caso de una carga muy alta, los procesos del servidor pueden ser bloqueados debido a que, al tratar de enviar mensajes de registro adicionales, el colector se ha quedado atrás.

Estadísticas de ejecución

Las siguientes opciones permiten configurar que estadísticas son recolectadas de forma constante por PostgreSQL. Éstas tienen la función de ayudar a los administradores del sistema, a tener una idea más detallada sobre lo que está sucediendo en el servidor.

Cuando la recolección de estadísticas está habilitada, la información que genera se puede ver a través de la familia de vistas pg_stat y pg_statio.

track_activities

Habilita la recopilación de información del comando que se está ejecutando actualmente. Esta opción está activada por defecto.

track_activity_query_size

Indica el número de bytes reservados para mostrar, en la vista pg_stat_activity, la query que se está ejecutando. Su valor por defecto es de 1024 bytes.

track_counts

Habilita la recolección de estadísticas sobre la actividad de la base de datos. Esta opción está activada por defecto, para que demonios como el autovacuum puedan trabajar correctamente.

track_functions

Establece el comportamiento a la hora de registrar la invocación de funciones y su tiempo de ejecución. El valor por defecto es none, lo que implica que no se guarda ninguna información al respecto. Otros valores aceptados son: pl, se almacena para los procedimientos almacenados y all que, además, añade las funciones SQL y las hechas en C.

stats_temp_directory

Almacena el directorio en donde se almacenarán temporalmente las estadísticas, antes de guardarlas en base de datos. Su valor por defecto es: pg_stat_tmp.

Parámetros del autovacuum

A partir de la versión 8.1 de PostgreSQL, existe un subproceso separado denominado autovacuum, encargado de revisar periódicamente la tablas con modificaciones considerables, información ésta que suministra el recolector de estadísticas, que lo ayudan a llevar a cabo las tareas: VACUUM y ANALYZE.

El demonio en realidad se compone de múltiples procesos que están, a su vez, englobados dentro de cada uno de los trabajadores del autovacuum (autovacuum_max_workers). Dicho demonio se encarga de distribuir las tareas a lo largo del tiempo, intentando poner en marcha a un trabajador en cada base de datos, cada autovacuum_naptime segundos, así pues, si tenemos N bases de datos, un trabajador se pondrá en marcha en el servidor cada autovacuum_naptime / N segundos. El número máximo de trabajadores simultáneos se establece con la opción autovacuum_max_workers, de modo que, si hubiese más bases de datos que trabajadores y, en un momento dado, le tocase a la siguiente base de datos ejecutar el autovacuum, pero ha alcanzado el número máximo de trabajadores, dicha base de datos se encolaría a la espera de que uno de los trabajadores fuese liberado.

Es importante tener en cuenta que, si existen tablas de gran tamaño y cuya actividad (INSERT, UPDATE, DELETE) es bastante alta, puede llegar a absorber en exceso a los trabajadores del autovacuum. También ha de saber que el número de trabajadores no cuenta para el cómputo de max_connections y superuser_reserved_connections.
autovacuum: controla si el servidor debe lanzar el demonio autovacuum. Su valor por defecto es on, aunque para un correcto funcionamiento del mismo ha de estar habilitada la opción track_counts.

autovacuum_analyze_scale_factor

Especifica la fracción del tamaño de la tabla que ha de añadirse a autovacuum_analyze_threshold, para determinar si se lanza el ANALYZE. De manera que, dicho comando se ejecutará si el número de filas obsoletas de una tabla supera:

autovacuum_analyze_threshold+(autovacuum_analyze_scale_factor*total filas)

Su valor por defecto es de 0.1, lo que implica que será necesario modificar al menos el 10% de una tabla para ejecutar el ANALYZE, sin embargo en entornos de producción y, sobre todo, cuando existen tablas con muchas filas, es conveniente reducir éste valor.

autovacuum_analyze_threshold

Establece el número mínimo de filas insertadas, actualizadas o borradas de una tabla, que provocarán la ejecución del ANALYZE. Su valor por defecto es de 50.

autovacuum_freeze_max_age

PostgreSQL introduce el concepto de marca de tiempo para las transacciones o XID (Identificador de transacción), el problema radica en que se trata de un campo limitado a 32 bits, es decir, cuando se han dado en el servidor 232 transacciones el contador se reinicia. Esto podría, potencialmente, provocar pérdida de información debido a que, datos introducidos con un intervalo temporal muy distante, compartiesen el mismo XID y si, por ejemplo, realizásemos un ROLLBACK de la última transacción, borraríamos también los cambios de aquella con igual XID, pero efectuada X meses o años antes.
Por esta razón, el contenido de este parámetro es el único que provocará la ejecución de un VACUUM, a pesar de haber desactivado el autovacuum. Su valor por defecto es de 200 000 000, lo que indica que, cada 200 millones de transacciones en el servidor se ejecutará un VACUUM, para evitar el problema ya comentado.

autovacuum_max_workers

Establece el número máximo de procesos autovacuum (al margen del propio demonio que los lanza), que pueden ejecutarse a la vez. El valor por defecto es 3.

autovacuum_naptime

Indica el tiempo mínimo que transcurre entre cada autovacuum, para una determinada base de datos. En cada ronda, el demonio examina la base de datos y determina si es preciso ejecutar el VACUUM y el ANALYZE en sus tablas. La demora se establece en segundos y su valor por defecto es de 1 minuto.

autovacuum_vacuum_cost_delay

Tiempo, en milisegundos, que el proceso de VACUUM automático debe dormir entre ejecuciones. Su valor por defecto es 20ms aunque, si se emplea -1, se utilizará el establecido por el parámetro vacuum_cost_delay.

autovacuum_vacuum_cost_limit

Límite en el número de operaciones que pueden llevar a cabo los trabajadores del autovacuum. Su valor por defecto es -1, lo que implica que se empleará vacuum_cost_limit para establecer este parámetro. Tenga presente que dicho valor de distribuirá proporcionalmente entre los trabajadores que estén ejecutándose actualmente, es decir, si hemos indicado 180 y tenemos 3 trabajadores, el límite de cada uno será de 60.

autovacuum_vacuum_scale_factor

Especifica la fracción del tamaño de la tabla que ha de añadirse a autovacuum_vacuum_threshold, para determinar si se lanza el VACUUM. De manera que, dicho comando se ejecutará si el número de filas obsoletas de una tabla supera:

autovacuum_vacuum_threshold + (autovacuum_vacuum_scale_factor*total filas)

Su valor por defecto es de 0.2, lo que implica que será necesario modificar al menos el 20% de una tabla para ejecutar el VACUUM, sin embargo en entornos de producción y, sobre todo, cuando existen tablas con muchas filas, es conveniente reducir éste valor.

autovacuum_vacuum_threshold

Especifica el número mínimo de filas actualizadas o borradas de una tabla, que provocarán la ejecución del VACUUM. Su valor por defecto es de 50.

Parámetros por defecto de conexión para los clientes

Los siguientes parámetros indican la configuración aplicada al conectarse al motor de base de datos, incluso vía consola.

statement_timeout

Expresa, en milisegundos, el tiempo máximo de ejecución de cualquier comando en base de datos. Su valor por defecto es 0, lo que implica que no existe este "límite superior".

timezone

Establece la zona horaria en la que se encuentra el servidos. Su valor por defecto es unknown, lo que significa que se toma la del sistema operativo.

Manejo de Locks

deadlock_timeout

Cada cuánto tiempo en milisegundos el sistema comprueba si ha ocurrido un deadlock. Este es un proceso lento y que no conviene ejecutarlo en cortos intervalos por ello, en producción, donde se asume que los deadlocks no son comunes, se recomienda aumentar este valor. Lo ideal es que coincida con el tiempo promedio de las transacciones en el servidor puesto que, comprobar antes de que ésta termine si ocurrió un deadlock, únicamente provoca una pérdida de tiempo. Por defecto, su valor es de 1 segundo.

max_locks_per_transaction

Valor utilizado para el cálculo del tamaño de la tabla compartida de bloqueos. Su valor por defecto es de 64, lo que implica que no podrá haber más de 64 objetos diferentes (por ejemplo registros de tablas) bloqueados a la vez, para una determinada sesión. Cada fila de la tabla de bloqueos ocupa unos 270 bytes de memoria compartida y el número total de éstas se calcula mediante la fórmula:

max_locks_per_transaction * (max_connections + max_prepared_transactions)

Bueno, creo que por ahora es suficiente. Espero que os pueda servir de ayuda a la hora de gestionar vuestro servidor de PostgreSQL.

Por favor, para consultas y preguntas sobre problemas y errores sobre el tema, utilizar los foros de este servidor.