El mar., 13 oct. 2020 a las 9:21, Diego (<mrstephenam...@gmail.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
> <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.
>
>
>
>
>
>
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
