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