Fwd: borrado de algunos registros en tablas grandes

Hola lista

El problema radicaba (porque como lo manifiesta Edwin en PostgreSQL 10, con
la implementación de particionamiento se subsano) en lo siguiente: para
implementar particiones la forma generalizada era acudir al mecanismo de
herencia (insertando en la tabla base) y por medio de trigers (o rules) se
redirecciona el registro a la tabla apropiada. Cuando se hace así el
resultado de la operación es 0 registros insertados (pues no inserta en la
base sino en algunas de sus hijos), Hibernate para verificar que la
transacción de llevo a cabo de forma exitosa revisa el resultado de la
operación y al devolver 0 asume que fue fallida.

El 22 de febrero de 2018, 06:54, Stephen Amell<StephenAmell(at)inbox(dot)lv>
escribió:

> Me imagino que sera porque Hibernate utiliza los valores de los serial que
> se perdían con el particionamiento; aunque tengo entendido que ya en
> postgres 10 esto no pasa.
>
>
>
> On 2018-02-21 20:45, Edwin Quijada wrote:
>
> Solo por curiosidad que hace Hibernate para que no se pueda aplicar un
> particionamiento.? Entiendo que si ya la tabla esta llena es un poco
> dificil por el caso de mover los archivos pero aun no entiendo lo que dices
> sobre Hibernate.
>
>
> Otra cosa, tu IVR lo estas haciendo con asterisk y libreria de asterik-agi
> de Java? Tambien trabajo con ello y me gustaria consultarte algo
>
>
> Gracias
>
>
> ------------------------------
> *From:* Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> <alvherre(at)alvh(dot)no-ip(dot)org>
> *Sent:* Thursday, January 18, 2018 8:34 PM
> *To:* Hellmuth Vargas
> *Cc:* Lista Postgres ES
> *Subject:* Re: borrado de algunos registros en tablas grandes
>
> Hellmuth Vargas escribió:
> > Hola Lista
> >
> > tengo un servidor PostgreSQL 9.4 en el cual se registra el log de un IVR
> > (atención telefónica automatizada por menús) donde la tabla ya esta
> > pesando 162GB, se tiene informacion desde el 2015 y se desea conservar en
> > linea solo el ultimo año (por cuestiones de espacio y rendimiento), la
> > aplicación que inserta estos datos esta implementada con Hibernate por lo
> > tanto no es posible implementar particiones pues al insertar regresa 0
> > registros y falla la aplicación. Se esta realizando un proceso nocturno
> > para mover los registros mas viejos de un año y y borrar los mismos de la
> > tabla en cuestión. Dado el tamaño de la tabla, las características de la
> > maquina y que el servicio es 7x24 no es posible ejecutar un VACUUM FULL
> > para recuperar el espacio sino se ejecuta un VACUUM ANALYZE, por lo tanto
> > los datos nuevos deben insertarse en los bloques marcados como libres por
> > el vacuum, esto afectaría el rendimiento de las operaciones que se hagan
> en
> > la tabla (bloat, entre otros aspectos)?
>
> Pienso que lo más barato sería acceder la BD directamente al hacer el
> insert. Como debería ser una operación muy específica, no hay que
> modificar toda la aplicación sino sólo una pequeña parte.
>
> Dicho esto, la verdad es que aplicar particionamiento post-facto es
> operacionalmente bastante complicado -- vas a requerir varios bloqueos
> en las tablas existentes para mover datos y establecer el ambiente
> inicial, así que no sé qué tan factuble sea en tu caso.
>
> Respecto a tu idea: Yo creo que es factible.
> Ejecutar VACUUM después de cada DELETE liberará el espacio para que los
> insert futuros puedan usarlo. No se liberará espacio al sistema
> operativo, pero esto no debería tener importancia. Ejemplo: si haces
> los DELETE de los registros de más de 104 semanas de edad una vez a la
> semana, en un tiempo no muy largo deberías llegar a un estado
> estacionario en el cual los nuevos inserts de cada semana van usando el
> espacio liberado por los de la semana X-104 que se acaban de borrar --
> sin efecto negativo en el rendimiento.
>
> --
> Álvaro Herrera https://www.2ndQuadrant.com/
> Professional PostgreSQL | 2ndQuadrant <https://www.2ndquadrant.com/>
> www.2ndquadrant.com
> Stay in touch with us. Subscribe to our monthly newsletter to hear the
> latest developments from 2ndQuadrant and related technologies. We’ll also
> send you any ...
>
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
>

--
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate

--
Cordialmente,

Ing. Hellmuth I. Vargas S.
Esp. Telemática y Negocios por Internet
Oracle Database 10g Administrator Certified Associate
EnterpriseDB Certified PostgreSQL 9.3 Associate