Re: Tabla con particionado y alta cantidad de UPDATE

El mar., 13 oct. 2020 a las 9:21, Diego (<mrstephenamell(at)gmail(dot)com>) escribió:
>
> Hola, aca Diego con la idea loca de siempre.
>
> Che, supongo que particionaste por triggers y a su vez volviste a usar un 2do trigger para este update... segun mi experiencia, eso se hacia a principio de los 2000 ;P
>
> Que haria yo, si fuera posible, particionaria nativo, por hash y subparticionaria por mes (o semana, o dia dependiendo de las distancias promedio entre insert e insert), recorda que en nativo pordes hacer particion de particion. De esta forma, el update no pasa por el mismo lock que el insert, no se si me explico.
>
> y posta, en pg12, vas a volar con las mejoras en particionamiento, en 13 mucho mas, fijate de considerar actualizar de version.
>
> en fin, chiflame si necesitas ayuda.
>
> Abraxo!
>
>
> On 2020-10-13 09:58, Edwin De La Cruz wrote:
>
>
>
>
> El mar., 13 de octubre de 2020 07:46, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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.
>
>
>
>
>
>

Gracias Diego. Pues inicialmente hace un par de años particionaba con
tablas heredadas y triggers. Ahora con pg10 uso particionado nativo.
Para insertar datos no uso trigger, sino una función, que es el punto
de entrada, que primero verifica que la partición donde se va a
insertar el datos exista, caso contrario crea la partición e inserta
el registro. Tengo particionado por idcliente y esta tabla a su vez
está dividida por meses.

eventos.data -> eventos.data_00001 -> eventos.data_00001_20200101

->eventos.data_00001_20200102

->eventos.data_00001_20200103, etc, etc

De esta forma, si tengo un nuevo cliente o cambio de mes, las tablas
se crean dinámicamente, esto me funciona sin problemas, ahora con el
particionado nativo me ha facilitado mucho el trabajo.

Estoy probando en Heroku con pg12 y me va muy bien, solo que en Heroku
no puedo subir tantos registros. El desempeño se ve afectado a partir
de unos cuantos cientos de miles de registros cuando pruebo en mi
máquina.

Como me aconsejaron, estoy repensando la lógica de la aplicación.

Mis proyectos de software libre en:
Github - edwinspire