Re: [pgsql-es-ayuda] Tamaño en tabla toast para tipo de dato bytea

Gracias por su ayuda, en realidad si se hacen muchos updates y a la vez no.
La forma en que ingresamos los datos es en pedazos, es decir de 100kb,
entonces checando con la funcion length los ultimos 20 archivos ingresados
son de 4 y 5 MB cada uno, si actualizamos en pedazos de 100 kb, entonces
hacemo 40 y 50 updates por cada imagen cargada. Segun entiendo como
funciona postgres, por cada update o delete deja la fila anterior y crea
una nueva, marcando la anterior como fila sin uso, entonces viene el vacuum
y la marca como espacio disponible para reuso de postgres y ya hasta el
final si uno quiere un vacuum full que libera el espacio inclusive para el
sistema operativo. Si este es realmente el funcionamiento, tal vez tantos
updates esten causando el problema engrosando el espacio.

Voy a probar con lo que comenta Lazaro haciendo un vacuum full a ver que
resultado me arroja. Se supone que esta carriendo el autovacuum, que
diferencia existe entre este y programar un vacuum con un cron cada dia? Y
es normal que el vacuum sobre una tabla con datos bytea tarde tanto, aun
cuando esta el autovacuum activado?, quiero decir el proceso llevaba dos
horas y no veia para cuando terminaba.

Como quiera gracias por su ayuda y voy a probar lo que me recomiendan.

On Fri, Feb 10, 2012 at 8:55 AM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>wrote:

>
> Excerpts from Ivan Perales M.'s message of vie feb 10 04:47:58 -0300 2012:
>
> > El problema es el siguiente, tengo el mismo sistema corriendo en dos
> redes
> > separadas, ambos corren postgresql 8.3.14. Tengo una tabla con el tipo de
> > datos bytea para cargar cualquier tipo de archivo, y hasta donde se se
> han
> > cargado archivos de word, excel, imagenes en formato jpg, png, etc. El
> > funcionamiento esta de lujo. El problema viene con la tabla toast que se
> > crea para el almacen. En uno de los dos sistemas, llevan aproximadamente
> > cargados 350 registros, y el resultado que me da la funcion
> > pg_total_relation_size es de aprox 756 megas, en lo cual estoy de
> acuerdo,
> > ya que seguramente los usuarios cargan imagenes que salen directamente de
> > la camara digital las cuales andan desde 2 hasta 6 megas. Pero en el otro
> > sistema, le han dado un uso un poco mas grande, han cargado 4005
> registros,
> > pero el tamaño de la tabla toast llega hasta los 60 GB!, no lo puedo
> creer,
> > aunque cargaran imagenes de 10 megas, las matematicas me dicen que
> deberian
> > ser 39.1 GB, y eso es exagerandole ya que no creo que las imagenes pasen
> de
> > 2 megas. No encontre una funcion para obtener el tamaño de una columna o
> de
> > una fila asi que no pude obtener el tamaño de cada celda en especifico,
> > pero se me hace increible. Si dumpeo la base con pg_dump y la restauro
> con
> > psql -f, el tamaño de la tabla toast regresa a 17 GB, que es lo que yo
> > supondria correcto. Al cabo de una semana, despues de agregar un par de
> > cientos de archivos, la base vuelve a subir varias decenas de GB's. Esto
> > jamas me habia ocurrido, solo esta en particular lo hace. Intente correr
> > vacuum de forma manual pero se tarda mucho tiempo, eh esperado hasta 2
> > horas y no veo que termine. No se si sea ese el tiempo que se lleve. El
> > autovacuum en esta version viene activado de forma predeterminada y asi
> lo
> > he dejado. Tenia la base corriendo desde abril del 2011 y no habia tenido
> > este problema. Hace como 1 mes por varios error que no lograba depurar en
> > la programacion del sistema, habilite el log del postgresql y asi lo
> deje,
> > 4 semanas despues la tabla toast ocupaba 250 GB. Deshabilite el log,
> > restaure desde un dump y de empezar con 16 GB a una semana despues ya va
> en
> > 60 GB. Ya se que suendo medio paranoico pero esto comenzo desde que
> > habilite el log. Ya deshabilite el log pero sigue haciendo lo mismo.
>
> Hmm. ¿se hace mucho update o delete de las columnas bytea una vez que
> los han ingresado? Si no es así, es extraño que la tabla crezca tanto,
> quizás el problema sea otro.
>
> Puedes saber cuánto pesan realmente las imágenes:
> select length(imagen) from latabla;
>
> y con eso puedes calcular más o menos qué tanto espacio deberían estar
> realmente usando.
>
> Dado que son imágenes probablemente comprimidas en origen, ¿no sería
> conveniente desactivar la compresión en la columna? No es que tenga
> nada que ver con el problema, pero te puede ahorrar tiempo de CPU.
>
> Lo del log obviamente no tiene ninguna relación con el problema.
>
> --
> Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
>

--
Lindolfo Iván Perales Mancinas
Cel. 481-126-2700
Solo existen 10 tipos de personas en el mundo, las que saben binario y las
que no.