From: | "deepthroat" <dblackbeer(at)gmail(dot)com> |
---|---|
To: | deepthroat <dblackbeer(at)gmail(dot)com>, "lista postgresql" <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: sobre vacuum |
Date: | 2007-01-05 11:27:54 |
Message-ID: | 1f3528fc0701050327o78628c64sc9c0e6c7c19c816c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
> 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?
Creo que sumando indices aprox. 60 Gb
> 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).
Si, en un principio se penso en realizar los procesos en una tabla
clon. Pero notamos que el volumen de la tabla no perjudicaba en
absoluto la performance. Por lo que la idea quedo absolutamente
deprecated.
> 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.)
No es que sea mal diseño, creo, pero hay datos de liquidacion de
haberes de una decena de años. Y es alentador ver que funciona bien
excepto ahora por el vacuum claro.
> - 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).
Ok. Suponiendo que puedo referenciar los datos en conjunto llamando a
la tabla de nivel superior.
> - desactiva autovacuum para esta tabla, y hazle vacuum manualmente a la
> hora que mas te acomode.
Esta documentado esto en algun lado?
> Ademas, ajusta maintenance_work_mem a un
> valor mucho mas alto para que vacuum pueda hacerse mas rapidamente.
Vere que pasa con esto primero.
Desde ya agradecido.
--
Alfredo "Debianita" Dell'Orto
From | Date | Subject | |
---|---|---|---|
Next Message | Sonia Malave | 2007-01-05 12:09:43 | Ayuda! |
Previous Message | Raúl Andrés Duque | 2007-01-05 04:18:39 | Re: Problemas con crosstab |