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