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:19:15 |
Message-ID: | e9b17cde05072607195417a4e5@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Hola al hacer:
cluster valoracion.svavaluo
Me da el siguiente error:
ERROR: no hay un Ãndice de ordenamiento definido para la tabla «svavaluo»
Segun la documentacion
puedo omitir un indice y solo especificar la tabla, pero al parecer no
me funciona esto, esta tabla tiene 12 indices diferentes cada uno de
ellos necesarios por diferentes motivos, entonces lo que no entiendo
es el mensaje, ahora bien si yo la fuerzo a que se reordene por un
indice especifico, entonces que pasa con los otros indices ????
Saludos a todos
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)
>
> --
> 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 | Edwin Quijada | 2005-07-26 14:20:13 | RE: Consulta fuera de topico |
Previous Message | Martín Marqués | 2005-07-26 14:12:51 | Re: Vacuumdb |