RE: configuración postgres 9 vs postgres 8 problema con checkpoints y autovacuum

Excerpts from lgarciam's message of sáb jul 07 12:16:19 -0400 2012:

> checkpoint_segments establece el máximo número de segmentos de wal (wal_buffers), que se pueden crear antes de que ocurra un check_point, lo que significa que si tienes en la configuración que wal_buffers = 64 Kb y checkpoint_segments = 5, solo pueden crearser 5 segmentos de 64 Kb y esta es la razón por la cual ocurren muchos check_points lo que empeora el acceso a disco, pues tendrían que realizarse muchas escrituras a disco contínuamente, por eso mi recomendación es ir incrementando el valor de checkpoint_segments hasta que no te aparezca más el HINT, o comenzar con un valor de 16.

Tienes una pequeña confusión. Los segmentos de WAL no tienen nada que
ver con wal_buffers. Un segmento de WAL es un archivo de 16 MB que se
guarda en el directorio pg_xlog. Este tamaño no es configurable a menos
que recompiles Postgres. wal_buffers solamente indica cuánto espacio
hay en RAM para guardar cosas que deben escribirse en algún segmento de
WAL.

Aparte de este detalle tu explicación es correcta: si tienes checkpoints
muy seguidos el rendimiento decae, por lo tanto hay incrementar tanto
checkpoint_segments como checkpoint_timeout.

> Sobre autocacuum, tenerlo en off, te puede disminuir el rendimiento de
> las consultas, pués, las tuplas muertas no son eliminadas, y cuando se
> recorren las tablas, es necesario revisar su visibilidad (visibility
> map), para saber que tupla debe formar parte del resultado.

Otra pequeña confusión. El "visibility map" es un archivo muy pequeño
que tiene un bit para cada página de cada tabla. Ese bit es 1 si todas
las tuplas son visibles para todos, es decir, si no hay ninguna tupla
muerta. Es 0 si hay al menos una tupla visible. Por lo tanto cuando
hay que "verificar la visibilidad de una tupla" no se usa el "visibility
map" (puesto que a menos que esté en 1 no tiene información suficiente)
sino la información de visibilidad que está junto con la tupla (xmin y
xmax).

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>