Re: borrado de algunos registros en tablas grandes

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<alvherre(at)alvh(dot)no-ip(dot)org
> <mailto:alvherre(at)alvh(dot)no-ip(dot)org>> 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
>