Configuracin intermedia de postgresql.

conf
Sb, 24/12/2011 - 12:03 doctore

En primer lugar sera recomendable, para todos los usuarios que quieran proseguir con la lectura de este pequeo manual, que echaran previamente un vistazo a Configuracin bsica, donde el webmaster introduce muchos de los conceptos que cualquiera que pretenda administrar esta base de datos necesitar conocer, y expone una visin global de los ficheros implicados en esta, en ocasiones, ardua tarea. Esta entrada pretende ir un paso ms all en determinados parmetros del archivo de configuracin de PostgreSQL, postgresql.conf, con la sana intencin de que el lector entienda qu significan y las implicaciones que puede conllevar su modificacin. As pues pongmonos manos a la obra, ofreciendo los entresijos de gran parte de las opciones de dicho archivo en su versin 9.0.

Conexiones y autenticacin
En esta seccin es posible configurar las opciones de acceso desde un punto de vista de los servicios levantados por el motor, adems es importante subrayar que, en su configuracin inicial, PostgreSQL slo puede ser accedido desde socket unix, sin puertos TCP/IP abiertos. authentication_timeout Define el tiempo que un cliente tiene para completar la autenticacin antes de que se desconecte automticamente, de forma predeterminada son 60 segundos. Un valor adecuado sera entre 15 y 30 segundos, de esa forma nos evitaramos usuarios que establecen conexiones sin autenticarse y que ocupan conexiones que no podrn ser usadas por otros. listen_addresses Establece las direcciones desde las que se escucharn conexiones a PostgreSQL. Por defecto es *, lo que implica que permitir peticiones desde cualquier IP, aunque puede indicar direcciones especficas si desea filtrar esto. Sin embargo, es importante recalcar que este parmetro no sirve para posibilitar la conexin, nicamente para indicar desde dnde se permite la peticin. max_connections Indica el nmero de conexiones simultneas permitidas, su valor por defecto es 100. El aumento de este nmero 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 mximo nmero de conexiones que estn 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 conexin a la base de datos, a pesar de que mltiples usuarios normales estn utilizndola.

Uso de recursos
En esta seccin se puede especificar la cantidad de recursos que PostgreSQL est autorizado a consumir. Tambin en ste apartado se tratarn los parmetros que controlan el background writer, proceso que se encarga de actualizar los cambios llevados a cabo, de forma que, la informacin 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 parmetrocheckpoint_segments provoca la actualizacin real en base de datos, durante el intervalo en el que ste tiene lugar, el background writer puede haber actualizado la misma informacin 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 elbackground writer. Su valor por defecto es de 200 ms. bgwriter_lru_maxpages En cada ejecucin del background writer, cuntos buffers sern actualizados (en Linux teclee: show block_size; para conocer el tamao en bytes de cada uno). Su valor por defecto es de 100 y, poniendo 0 deshabilitaramos 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 tamao 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 nmero mximo 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 cada 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 opcin est deshabilitada, si por el contrario, la emplea, es probable que desee tener tantas como max_connections, de modo que cada sesin pueda llegar a tener una

operacin preparada en espera. Aumentar este valor implica alrededor de 600 bytes de memoria por incremento, adems de lo ya comentado en el parmetro max_locks_per_transaction. shared_buffers Este es un parmetro muy importante, que establece y define el tamao 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 disminucin de ste permite ahorrar recursos del sistema en un sistema con poca carga, su aumento se puede mejorar el rendimiento en un sistema de produccin muy utilizado. En un servidor dedicado podemos empezar con un 25% del total de nuestra memoria (nunca ms del 33%). Estos buffers (en Linux teclee: show block_size; para conocer el tamao 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 tamao mximo 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 sesin 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 lmite 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 parmetro, lo recomendable en grandes servidores es mantener valores que no superen los 10ms. vacuum_cost_limit Durante la ejecucin 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 parmetro establece el nmero de stas operaciones que provocarn que el VACUUM duerma el tiempo establecido porvacuum_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 informacin sobre las transacciones y cambios realizados en la base de datos, as como para garantizar la integridad de los mismos. Tambin emplea estos

archivos para reparar automticamente posibles inconsistencias en la base de datos despus de una cada sbita del servidor. Estos ficheros tienen un nombre nico, un tamao 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 ejecucin del pto. de chequeo actual (ver checkpoint_segments) durante el perodo 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 mximo de 0.9) puede sobrecargar las operaciones de E/S debido a que el volcado de operaciones pendientes a la base de datos sera mayor. checkpoint_segments Este parmetro 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 llamadossegmentos del WAL. Teniendo en cuenta que el valor por defecto de dicho parmetro 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 recuperacin ms lenta ante un fallo en cualquiera de las transacciones, por esta razn, para sistemas de escritura masiva, valores desde 32 (punto de chequeo cada 512 MB) a 256 (cada 128 GB) son los ms populares. checkpoint_timeout Si bien el parmetro checkpoint_segments serva para indicar la cantidad de memoria del WAL que provoca un pto. de chequeo, ste parmetro lo establece en cuanto al tiempo. Su valor por defecto son 5 minutos. fsync Con esta opcin a on, PostgreSQL llama a fsync() para asegurarse de que los datos son grabados a disco fsicamente despus de cada COMMIT por transaccin. Esto puede hacer que el rendimiento sea algo menor sin embargo, garantiza que el clster de base de datos se pueda recuperar a un estado coherente, despus de un fallo en el sistema operativo o un accidente de hardware. synchronous_commit Especifica si despus de que una transaccin realice un COMMIT, espera a guardar los registros WAL en disco antes de dar por vlidas las operaciones (vercheckpoint_segments). El valor por defecto y, el ms 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 informacin generada para el WAL en una transaccin tpica, ya que los datos se escriben en el disco en cada confirmacin de la

transaccin. En un entorno de produccin una buena aproximacin podra ser entre 1 y 16 MB. wal_sync_method Mtodo empleado para actualizar las operaciones pendientes a los ficheros de segmentos WAL, aunque si la opcin 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

opcin 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 funcin realmente escribir sus datos en disco (existen plataformas en donde aun con la opcin fsync, no se puede asegurar que los datos realmente se escribieron en disco). open_sync escribe en los archivos WAL con open() y la opcin O_SYNC.

No todas las opciones estn disponibles en todas las plataformas. La instalacin de PostgreSQL detectar automticamente cul 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 mdulo de un motor de base de datos que decide como realizar fsicamente la operacin. PostgreSQL permite la modificacin del comportamiento por defecto del planificador, impidiendo que realice ciertas operaciones como: bsqueda 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 examinarn las restricciones de todas las tablas, a off, ninguna. Su valor por defecto es partition, lo que implica que nicamente se examinarn cuando se trate de una tabla en la que se haya empleado la herencia. effective_cache_size Parmetro 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 debera configurar en base a la memoria que quede tras establecer el valor de:shared_buffers, sistema operativo y otras aplicaciones, adems tenga en cuenta el nmero esperado de consultas simultneas 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 mximo aconsejable un 66% del total). geqo

PostgreSQL incorpora dentro de su analizador de consultas que incluyen JOINs, un algoritmo gentico para su optimizacin, o Generic Query Optimization, para el cual existen opciones que permiten ajustar su comportamiento. Los algoritmos genticos son una optimizacin heurstica que opera de forma nodeterminstica, el set de soluciones posibles para el problema se denomina poblacin, mientras que el grado de adaptacin de un individuo se llama ajuste. Las coordenadas del individuo dentro del espacio de soluciones se representa porcromosomas y un gen es una subseccin de un cromosoma, el cual codifica el valor de un nico parmetro dentro de la optimizacin. Para obtener la solucin se simula la recombinacin y mutacin de los individuos, realizndose la seleccin natural en base a aquel individuo que presenta en promedio un mayor grado de adaptacin que sus ancestros. El valor por defecto de esta opcin es on. geqo_threshold Establece el nmero de elementos del FROM de una consulta que provocarn el uso del optimizador gentico (ver geqo). Su valor por defecto es 12 ya que, para consultas ms 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 quedndose, posteriormente, con la mejor de ellas. seq_page_cost Especifica el coste de leer una nica pgina de base de datos en disco de forma secuencial, cuando la informacin se encuentra contigua en l. Se trata de una estimacin 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 ms rpido que el acceso secuencial.

Registro de errores y log

PostgreSQL permite configurar de forma exhaustiva el cmo, cundo y dnde logear lo que sucede. client_min_messages Controla los niveles de mensajes (cantidad de informacin) que se enva al cliente. Los valores aceptados son: DEBUG5, DEBUG4, DEBUG3, DEBUG2, DEBUG, LOG,NOTICE, W ARNING, ERROR, FATAL y PANIC. Cada nivel incluye todos los que le siguen y cuanto ms a la izquierda est, menos informacin se enva. El valor predeterminado es NOTICE.

DEBUG[5..1] informacin detallada para los desarrolladores.

INFO proporciona informacin implcitamente solicitada por el usuario,

por ejemplo, al ejecutar VACUUM VERBOSE.

NOTICE informacin 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 transaccin.

ERROR informa de un error que ha causado que aborte un comando. LOG informacin interesante para los administradores, por ejemplo, la
actividad de los puntos de chequeo. FATAL errores que han producido que aborte la sesin.

PANIC errores que han producido que aborten todas las sesiones del
servidor.

log_destination Indica la salida a la que irn dirigidos los mensajes de log. Por defecto,

stderr.

log_directory Cuando logging_collector est habilitado, este parmetro determina el directorio en el que los archivos de logs se crearn. Se puede especificar como una ruta absoluta o relativa al directorio de datos del clster. log_error_verbosity Gestiona el nivel de detalle que se incluye en cada mensaje aadido al log del servidor. Los valores aceptados son: TERSE, DEFAULT y VERBOSE, cuanto ms a la izquierda est, ms informacin se enva. log_filename Cuando logging_collector est habilitado, este parmetro define los nombres de los archivos de logs creados. El valor se trata como unpatrn strftime, por lo que se las variables de tiempo debern escaparse empleando% (%Y = ao, %m = mes, %d = da, etc.). log_line_prefix Cadena en formato printf, cuya

informacin equivalente se incluye al comienzo de cada nueva lnea del archivo de log. Cada valor ha de escaparse mediante el carcter %, y aquellos que no se reconozcan sern ignorados. Algunos de stos parmetros slo estarn disponibles cuando exista una sesin, por lo que no se incluir su informacin asociada cuando se loguee informacin de procesos del sistema.
log_lock_waits Cuando ocurre un deadlock en el sistema, ste siempre se registra. Sin embargo, poniendo a on este parmetro cada vez que el detector de deadlocks se ponga en marcha (ver deadlock_timeout), y determine que no existe tal, se logear informacin 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 ms tiempo, en milisegundos, que el especificado en dicho parmetro 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 almacenarn 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 ms a la izquierda est, menos informacin se enva. 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 opcin en PANIC, lo que har que prcticamente nada se registre (verclient_min_messages). log_min_messages Establece los niveles de mensajes (cantidad de informacin) que se enva 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 ms a la izquierda est, menos informacin se enva. El valor predeterminado es WARNING (ver client_min_messages). log_rotation_age Cuando logging_collector est habilitado, determina el tiempo de vida mximo en minutos de un archivo de log individual, despus de ste tiempo un nuevo fichero ser creado. Establecer a 0 para deshabilitar la creacin basada en el tiempo de los archivos de logs nuevos. log_rotation_size Cuando logging_collector est habilitado, determina el tamao mximo en KB de un archivo de log individual, despus de alcanzar este volumen un nuevo fichero ser creado. Establecer a 0 para deshabilitar la creacin basada en el tamao de los archivos de logs nuevos. log_statement Controla qu sentencias SQL se loguearn. Los valores aceptados son: none, ddl,mod y all, cada nivel incluye a los precedentes.

ddl registra todas las sentencias de definicin de datos como: CREATE,

ALTER yDROP

mod registra las incluidas en ddl y adems las modificaciones de datos

como:INSERT, UPDATE, DELETE, TRUNCATE y COPY FROM. Tambin 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 aadir al final del mismo, cualquier archivo de log existente con el mismo nombre que aquel en el que deba agregar la informacin. Sin embargo, el truncamiento se producir slo cuando un nuevo fichero se abra debido a la rotacin en funcin del tiempo, no durante el inicio del servidor o por una rotacin basada en el tamao. Por ejemplo, si quisiramos mantener un log con lo que ha pasado los ltimos 7 das, teniendo un archivo diario: log_server.Mon, log_server.Tue, etc. deberemos establecer la siguiente configuracin: 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 diseado 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 atrs.

Estadsticas de ejecucin
Las siguientes opciones permiten configurar que estadsticas son recolectadas de forma constante por PostgreSQL. stas tienen la funcin de ayudar a los administradores del sistema, a tener una idea ms detallada sobre lo que est sucediendo en el servidor. Cuando la recoleccin de estadsticas est habilitada, la informacin que genera se puede ver a travs de la familia de vistas pg_stat y pg_statio. track_activities Habilita la recopilacin de informacin del comando que se est ejecutando actualmente. Esta opcin est activada por defecto. track_activity_query_size Indica el nmero 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 recoleccin de estadsticas sobre la actividad de la base de datos. Esta opcin est activada por defecto, para que demonios como el autovacuum puedan trabajar correctamente. track_functions Establece el comportamiento a la hora de registrar la invocacin de funciones y su tiempo de ejecucin. El valor por defecto es none, lo que implica que no se guarda ninguna informacin al respecto. Otros valores aceptados son: pl, se

almacena para los procedimientos almacenados y funciones SQL y las hechas en C.

all que, adems, aade las

stats_temp_directory Almacena el directorio en donde se almacenarn temporalmente las estadsticas, antes de guardarlas en base de datos. Su valor por defecto es: pg_stat_tmp.

Parmetros del autovacuum

A partir de la versin 8.1 de PostgreSQL, existe un subproceso separado denominadoautovacuum, encargado de revisar peridicamente la tablas con modificaciones considerables, informacin sta que suministra el recolector de estadsticas, que lo ayudan a llevar a cabo las tareas: VACUUM y ANALYZE. El demonio en realidad se compone de mltiples procesos que estn, 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 nmero mximo de trabajadores simultneos se establece con la opcinautovacuum_max_workers, de modo que, si hubiese ms 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 nmero mximo de trabajadores, dicha base de datos se encolara a la espera de que uno de los trabajadores fuese liberado. Es importante tener en cuenta que, si existen tablas de gran tamao y cuya actividad (INSERT, UPDATE, DELETE) es bastante alta, puede llegar a absorber en exceso a los trabajadores del

autovacuum. Tambin ha de saber que el nmero de trabajadores

no cuenta para el cmputo 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 opcin track_counts. autovacuum_analyze_scale_factor Especifica la fraccin del tamao de la tabla que ha de aadirse aautovacuum_analyze_threshold, para determinar si se lanza el ANALYZE. De manera que, dicho comando se ejecutar si el nmero 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 produccin y, sobre todo, cuando existen tablas con muchas filas, es conveniente reducir ste valor. autovacuum_analyze_threshold Establece el nmero mnimo de filas insertadas, actualizadas o borradas de una tabla, que provocarn la ejecucin del ANALYZE. Su valor por defecto es de 50. autovacuum_freeze_max_age PostgreSQL introduce el concepto de marca de tiempo para las transacciones oXID (Identificador de transaccin), 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 podra, potencialmente, provocar prdida de informacin debido a que, datos introducidos con un intervalo temporal muy distante, compartiesen el mismo XID y si, por ejemplo, realizsemos un ROLLBACK de la ltima transaccin, borraramos tambin los cambios de aquella con igual XID, pero efectuada X meses o aos antes. Por esta razn, el contenido de este parmetro es el nico que provocar la ejecucin 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 nmero mximo 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 mnimo 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 automtico debe dormir entre ejecuciones. Su valor por defecto es 20ms aunque, si se emplea -1, se utilizar el establecido por el parmetro vacuum_cost_delay. autovacuum_vacuum_cost_limit Lmite en el nmero de operaciones que pueden llevar a cabo los trabajadores delautovacuum. Su valor por defecto es -1, lo que implica que se emplearvacuum_cost_limit para establecer este parmetro. Tenga presente que dicho valor de distribuir proporcionalmente entre los trabajadores que estn ejecutndose actualmente, es decir, si hemos indicado 180 y tenemos 3 trabajadores, el lmite de cada uno ser de 60. autovacuum_vacuum_scale_factor Especifica la fraccin del tamao de la tabla que ha de aadirse aautovacuum_vacuum_threshold, para determinar si se lanza el VACUUM. De manera que, dicho comando se ejecutar si el nmero 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 produccin y, sobre todo, cuando existen tablas con muchas filas, es conveniente reducir ste valor. autovacuum_vacuum_threshold Especifica el nmero mnimo de filas actualizadas o borradas de una tabla, que provocarn la ejecucin del VACUUM. Su valor por defecto es de 50.

Parmetros por defecto de conexin para los clientes

Los siguientes parmetros indican la configuracin aplicada al conectarse al motor de base de datos, incluso va consola. statement_timeout Expresa, en milisegundos, el tiempo mximo de ejecucin de cualquier comando en base de datos. Su valor por defecto es 0, lo que implica que no existe este "lmite 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 cunto tiempo en milisegundos el sistema comprueba si ha ocurrido undeadlock. Este es un proceso lento y que no conviene ejecutarlo en cortos intervalos por ello, en produccin, 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 prdida de tiempo. Por defecto, su valor es de 1 segundo. max_locks_per_transaction Valor utilizado para el clculo del tamao de la tabla compartida de bloqueos. Su valor por defecto es de 64, lo que implica que no podr haber ms de 64 objetos diferentes (por ejemplo registros de tablas) bloqueados a la vez, para una determinada sesin. Cada fila de la tabla de bloqueos ocupa unos 270 bytes de memoria compartida y el nmero total de stas se calcula mediante la frmula: max_locks_per_transaction * (max_connections + max_prepared_transactions)