Fwd: borrado de algunos registros en tablas grandes

[Hellmuth Vargas]

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<stephenam...@inbox.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 <alvhe...@alvh.no-ip.org> <alvhe...@alvh.no-ip.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 Herrerahttps://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

Re: borrado de algunos registros en tablas grandes

[Edwin Quijada]

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 <alvhe...@alvh.no-ip.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 Herrerahttps://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

Re: borrado de algunos registros en tablas grandes

[Stephen Amell]

Por lo de "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.", me ha pasado 
tambiem y aprovecho a preguntarle a quienes ya usan el Postgres 10: 
¿Saben si con la nueva forma de particionar tablas esto sigue retornando 
0 o si ya retorna el valor del id en los serial?



On 2018-01-18 17:43, Hellmuth Vargas wrote:

Hola Avaro

Mil gracias así procederé entonces

El 18 de enero de 2018, 15:34, Alvaro Herrera> escribió:


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/
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

Re: borrado de algunos registros en tablas grandes

[Hellmuth Vargas]

Hola Avaro

Mil gracias así procederé entonces

El 18 de enero de 2018, 15:34, Alvaro Herrera
escribió:

> 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 Herrerahttps://www.2ndQuadrant.com/
> 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

Re: borrado de algunos registros en tablas grandes

[Alvaro Herrera]

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 Herrerahttps://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services