Re: Tabla con particionado y alta cantidad de UPDATE

Saludos cordiales.
Si efectivamente uso un trigger para hacer los updates. El explain en
este momento no lo tengo a mano, pero recuerdo que hace un recorrido
por todas las tablas de la partición, que al momento son cerca de 20.

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.

Ahora, para el usuario hay una vista donde solo puede observar los
"eventos" cuyo estado está en alarma y que no hayan recibido una
"restauración".

Con este ejemplo el flujo de la aplicación es la siguiente:
1) Se recibe el "evento" y se hace un INSERT en la tabla marcando en
el campo estado = "ABIERTO".
2) Con un trigger AFTER INSERT se verifica si hay un evento(os)
anterior(es) al que se lo deba cambiar de estado a "CERRADO" y en un
campo se almacena el ID del evento que lo cerró.
3) Luego con otro trigger se notifica al usuario por medio de otro
proceso (este funciona sin novedad).

Mis proyectos de software libre en:
Github - edwinspire
El dom., 11 oct. 2020 a las 0:59, Jaime Casanova
(<jaime(dot)casanova(at)2ndquadrant(dot)com>) escribió:
>
> On Sat, 10 Oct 2020 at 14:48, Edwin De La Cruz <edwinspire(at)gmail(dot)com> wrote:
> >
> [...]
> >
> > He realizado un particionado por HASH de la tabla en 10 partes, lo
> > cual me ha funcionado relativamente bien. Sin embargo la aplicación
> > creció y me veo en la necesidad de separar los datos por "Clientes", y
> > a su vez particionar estos por meses del año, quedando de la siguiente
> > manera:
> >
> [...]
> >
> > Lamentablemente con este esquema he visto una reducción notable de la
> > base de datos, he pasado de una transaccionalidad de 2500 inserts por
> > minuto a tan solo 500.
> >
>
> Saludos Edwin,
>
> En realidad no nos dices suficiente, podrías ejecutar un EXPLAIN
> ANALYZE del INSERT en la tabla padre? y un EXPLAIN ANALYZE del UPDATE.
>
> Dices que por cada INSERT hay un UPDATE, eso ocurre en un trigger?
> Además, personalmente pienso que eso es señal de un mal diseño...
> porque necesitas un UPDATE por cada INSERT en primer lugar?
>
> --
> Jaime Casanova www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services