From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Ivan Perales M(dot) <ivan(dot)perales(at)gmail(dot)com> |
Cc: | Ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Tamaño en tabla toast para tipo de dato bytea |
Date: | 2012-02-10 19:40:14 |
Message-ID: | 1328902694-sup-5494@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Excerpts from Ivan Perales M.'s message of vie feb 10 16:12:34 -0300 2012:
> 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.
Esa es una idea bastante mala. ¿por qué lo hacen así? ¿Se puede evitar?
Sería mucho más sensato hacer solamente un insert con todos los datos de
una sola vez.
> 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
Justamente.
> 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.
El vacuum full no debería realmente ser necesario. Ya hemos hablado
aquí muchas veces de eso; revisa los archivos anteriores.
--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2012-02-10 20:36:59 | RE: Tamaño en tabla toast para tipo de dato bytea |
Previous Message | Ivan Perales M. | 2012-02-10 19:12:34 | Re: [pgsql-es-ayuda] Tamaño en tabla toast para tipo de dato bytea |