Re: sobre vacuum

Alvaro ... postgresql 8.2.1 ???

donde puedo leer sobre estos cambios en el tema de particionado??? soy muy
amante del particionado !!!

Gracias.

Atentamente,

RAUL DUQUE
Bogotá, Colombia

----- Original Message -----
From: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
To: "deepthroat" <dblackbeer(at)gmail(dot)com>
Cc: "lista postgresql" <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Thursday, January 04, 2007 7:36 PM
Subject: Re: [pgsql-es-ayuda] sobre vacuum

> deepthroat escribió:
>> On 1/4/07, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
>
>> >> Se me plantean estas preguntas porque no es facil lidiar con un
>> >> proceso vacuum que tarde mas de 48 horas cuando la BD es gigantesca.
>> >
>> >48 horas? Creo que tienes un problema de configuracion o algo, no puede
>> >demorarse 48 horas. Cuanto pesa tu BD?
>> >
>> 130gb.
>> existe una tabla bastante grande con varios índices con muchos GB de
>> tamaño y procesos que hacen delete y update masivamente en ella.
>
> Ok. Me imagino que el vacuum de esa tabla es lo problematico, no el
> resto. Hace poco me tope con un problema parecido, donde la tabla mas
> grande del sistema es tambien la que sufre la mayor cantidad de updates
> e inserts. Lo malo es que el diseño no es muy bueno, lo cual perjudica
> aun mas. Lamentablemente es un caso patologico para Postgres, y debes
> evitarlo de ser posible. Que tan grande es esa tabla?
>
> Algunas sugerencias:
>
> - en lo posible, trata de cambiar el modelo de manera que los updates y
> deletes ocurran en tablas mas chicas (dividiendo la tabla grande segun
> sea apropiado). No recomiendo que hagas esto si es que viola la
> normalizacion, pero si el diseño es malo entonces es conveniente
> hacerlo y no "sacarle el poto a la jeringa" solo para evitar modificar
> la aplicacion. Es posible que estes pagando muy caro (en I/O
> innecesario, y molestias de VACUUM) con un diseño malo, pero como no
> conozco el diseño es dificil decirlo ;-)
> (Si quieres puedes publicarlo y lo podemos comentar. Todo campo que
> no sea NOT NULL es candidato de ser enviado a otra tabla.)
>
> - trata de utilizar particionamiento (idealmente, con Postgres 8.2.1,
> que es muy superior en este aspecto a los anteriores; pero con 8.1
> tambien podria ser)
>
> - desactiva autovacuum para esta tabla, y hazle vacuum manualmente a la
> hora que mas te acomode. Ademas, ajusta maintenance_work_mem a un
> valor mucho mas alto para que vacuum pueda hacerse mas rapidamente.
>
> Te explico un poco este ultimo comentario. Cuando se hace vacuum de una
> tabla, lo que hace es recorrer el "heap" buscando tuplas que deban
> eliminarse, y almacena los CTIDs (direcciones del heap) de esas tuplas
> en memoria, en un trozo de memoria de tamaño maintenance_work_mem.
> Cuando se llena esa memoria, empieza un recorrido completo de cada uno
> de los indices, buscando todas las referencias a alguno de esos CTIDs, y
> los elimina tambien. Cuando eso esta listo, entonces continua el
> recorrido del heap y vuelve a recolectar maintenance_work_mem CTIDs, y
> vuelve a recorrer completamente todos los indices. Se hace eso hasta
> que el heap se ha recorrido completamente.
>
> Obviamente, cada recorrido de un indice lleva un costo bastante alto,
> por lo que mientras menos veces se haga, mejor. De esto se desprende
> que mientras mas alto sea maintenance_work_mem, menos recorridos se
> hacen, y menos tiempo se tarda el vacuum.
>
> --
> Alvaro Herrera
> http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> ---------------------------(fin del mensaje)---------------------------
> TIP 6: ¿Has buscado en los archivos de nuestra lista de correo?
>
> http://archives.postgresql.org/pgsql-es-ayuda
>