From: | Mario Soto Cordones - Venezuela <msotocl(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | pgsql-es postgresql <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Vacuumdb |
Date: | 2005-07-26 14:26:10 |
Message-ID: | e9b17cde0507260726426f0114@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
El 25/07/05, Alvaro Herrera<alvherre(at)alvh(dot)no-ip(dot)org> escribió:
> On Mon, Jul 25, 2005 at 03:06:07PM -0400, Mario Soto Cordones - Venezuela wrote:
> > Hola Lista tengo la siguiente consulta, tengo una base de datos con
> > muchas tablas, una de ellas tiene aproximadamente 5 millones de
> > registros y tambien varios indices..... Al hacer el vacuumdb -z -v -a
> > -f , cuando llega a esta tabla se demora casi 12 horas en
> > completarlo.... Y los discos se vuelven locos trabajando, alguien
> > tiene alguna idea de como poder hacer esto mas rapido ya que por lo
> > general debo parar el vacuumdb ya que el sistema se torna
> > inaccesiblemente lento, trate de hacer un pg_resetxlog pero el
> > resultado es el mismo
>
> Primero que nada, pg_resetxlog no tiene nada que ver con el problema.
>
> Segundo, lo mas probable es que cada vez que ejecutas vacuum y lo cortas
> despues de un tiempo de ejecucion, vayas "echando a perder" cada vez mas
> la tabla y los indices, porque van acumulando tuplas obsoletas y el
> problema es cada vez peor.
>
> Tercero, en este momento estas en una situacion critica e indeseable, la
> cual es importante evitar en el futuro. Si eliminas o actualizas muchas
> tuplas de esa tabla, quizas seria conveniente que ejecutaras vacuumdb
> sin -f (es decir vacuum no full), con una frecuencia mayor que un dia.
>
> Cuarto, para salir del problema actual, tienes al menos tres
> alternativas:
>
> 1. aumentar maintenance_work_mem o vacuum_mem (dependiendo de la
> version) a un valor bastante alto, usando SET, y luego ejecutar el
> vacuum full sobre esa tabla. Ojo que el incremento debe ser solo para
> la conexion que ejecuta el vacuum full. Dejalo todo el tiempo que
> necesite, no lo cortes antes de que haya terminado.
>
> 2. no usar vacuum, sino CLUSTER. Esto es mejor que vacuum, porque este
> ultimo empeora la situacion de los indices, en cambio cluster reescribe
> toda la tabla y los indices desde cero. Yo diria que esta es tu mejor
> apuesta. Dejalo corriendo todas las horas que necesite.
>
> 3. Haz un pg_dump -t de esa tabla, luego la cargas en una tabla nueva,
> borras la antigua y le cambias el nombre a la nueva. (Esto es casi
> exactamente lo mismo que hacer CLUSTER)
>
Creo que esta es la mejor opcion, por tiempo, que creen ustedes ????
> --
> Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
> <Schwern> It does it in a really, really complicated way
> <crab> why does it need to be complicated?
> <Schwern> Because it's MakeMaker.
>
--
cordialmente,
Ing. Mario Soto Cordones
From | Date | Subject | |
---|---|---|---|
Next Message | Martín Marqués | 2005-07-26 14:36:22 | Re: Vacuumdb |
Previous Message | Ing. Jhon Carrillo - Caracas, Venezuela | 2005-07-26 14:25:25 | Maximo de argumentos en una function |