El mar., 13 de octubre de 2020 07:46, Alvaro Herrera <
alvhe...@alvh.no-ip.org> escribió:
> Edwin De La Cruz escribió:
>
> > Voy a explicar de forma ańaloga como funciona el ingreso de datos,
> > pensemos en un sistema de alarma:
> > 1) Cuando se abre una puerta se genera un evento de "alarma".
> > 2) Ahora cuando se cierra la puerta se genera un evento de
> > "Restauración de alarma", lo cual cancela ("ACTUALIZA EL ESTADO") del
> > evento anterior.
>
> Hm, yo apoyo lo que dice Jaime, a saber, que el diseño no es el adecuado.
> Sugiero pasar un par de horas pensando en un diseño que te permita
> implementar tus necesidades sin requerir estas operaciones de doble
> efecto.
>
> Hay modificaciones al motor Postgres que todavía están pendientes para
> que tablas particionadas tengan rendimiento parecido a tablas normales.
> Algunas están en pg11, otras en pg12 y 13, pero todavía hay propuestas
> en pg14. Lo que trato de argumentar es que no esperes que el
> rendimiento con tablas particionadas sea equivalente, porque mientras
> esas optimizaciones no estén, no lo es.
>
>
>
Gracias, por responder, pues la verdad la aplicación tiene algunos años
funcionando así pero el nivel de transacciones era muy bajo. Ahora que la
aplicación creció en transacciones y usuarios me topé con este
inconveniente. El cuello de botella son los UPDATE en cada INSERT.
Luego de desvelarme un par de noches y meditarlo con mi almohada decidí
desactivar el Trigger, perderé algunas características actuales de mi
aplicación en favor de una mayor velocidad para recibir registros en las
tablas.
Como les comenté la aplicación recibe "alarmas" y por la naturaleza de las
mismas deben procesarse a la mayor velocidad posible. Esta base es parte de
una PWA para seguridad comunitaria que la tengo en GitHub.
Gracias a todos por su ayuda.
