Re: Update concurrente

From: "Carlos T(dot) Groero Carmona" <ctonetg(at)gmail(dot)com>
To: Horacio Miranda <hmiranda(at)gmail(dot)com>
Cc: Silvio Bravo Cadó <bravocado(at)gmail(dot)com>, Lista PostgreSql <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: Update concurrente
Date: 2019-12-08 04:21:02
Message-ID: CABh6Tc3je7NvshvEYmjyQWLebdiWER2qtHua8+xJs6+okQ2b1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

Recuerdo que cuando empiezas a dar Normalization la 1FN o la 2FN te dicen
que se deben eliminar los campos calculables como disponibilidad de tu DER.

Al fin y al cabo disponibilidad no es mas que cantidad - Vendido cierto?

Yo prefiriaria solo contar/Sumar lo que has vendido y restarlo por cada
producto antes de mostrar la diaponibilidad, con los indices correcto ese
count deberia ser en ms y llegado a un x% de agotarse se le alerta al
cliente que el.producto puede eatar agotado al finalizar la transaction
como hacen todos los sitios de venta.

Ahora si prefieres hacerlo en la manera en que lo estas haciendo revisa que
no tengas deadlocks que estan haciendo que el proceso se realice lento en
horarios picos.

Revisa el log de postgres a ver si te sice que debes aumentar los locks per
transactions.

En fin creo que debes analizar la configuration y ver si puedes optimizarlo
para que utilize mejor los recursos diaponobles.

>

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message kernel 2019-12-09 08:29:44 Alternativa a pgadmin 4
Previous Message Horacio Miranda 2019-12-06 03:53:14 Re: Update concurrente