Gracias diego, En realidad, el historico de cada movimiento se guarda, pero el cache de la cantidad actual es obligatorio, ya que si no, me forzaria a estarlo calculando cada que el usuario lo consulte o exporte a excel, y ya que pueden ser hasta 5 mil registros, seria mucho tiempo perdido. Mi duda mas que nada iba sobre el performance en postgres por tener muchas tuplas marcadas como basura para el autovacuum, ya que segun yo los 700 bytes si es una cantidad considerable de datos, multiplicada por algunos miles de updates diarios entre todas los registros de la tabla, podrian haber decenas de megabytes o incluso hasta cientos marcados como basura y no se que tanto impacte el performance de postgres por el autovacuum.
Gracias por tu tiempo. On Mon, Jan 13, 2020 at 6:29 AM Diego <mrstephenam...@gmail.com> wrote: > Hola Ivan, > > Creo que te vas a encontrar con un problema, si es que ya no lo viste, y > es que no vas a poder llevar el histórico de movimientos y cantidades. > Imaginate preguntando cuanto tenia de tal cosas tal dia del pasado... > > Mi recomendación es uqe no actualices, sino que insertes en una tabla > detalle los valores. con fecha desde, hasta y demás cosas que te sirvan > para auditar. Esto, llegado el caso se puede particionar e ir depurando. > > Pero bueno, quizas te convenga crear una función que administre el > guardado de este dato, y luego vas cambiando el diseño de las tablas. > > No se si me explico bien... > > > > On 11/1/20 13:35, Ivan Perales M. wrote: > > Buenos días a todos, > > Tengo una tabla con poco más de 30 columnas, unos campos son integer (y > algunos con foreign key) otros mas text, boolean y decimal. Esta tabla > tiene 3 campos que son actualizados cada cierto tiempo, en particular la > existencia total de un producto en inventario (cuando esta en uso se > actualizará a lo mucho unas 5 veces en un dia y puede durar hasta semanas > en que no se mueva). Hay un nuevo requerimiento donde se agregue otras dos > columnas para llevar la existencia actual de otras situaciones, pero esta > situación si actualizaría la tabla mas seguido, de ser unas 5 pasaria tal > vez a algunos cientos en un mismo día. > > Ya que postgres marca como eliminada la tupla y agrega una nueva, ésto > podria ocasionar algun impacto en el performance? tanto para los selects > (por tener tanta fragmentación de datos) y para vacuum (al tener mas datos > que limpiar)? Será un mejor escenario si se sacan todas las columnas que se > actualizarían constantemente a una nueva tabla y que solo se actualize > esta? tal vez cambiando el fill factor de la tabla? El promedio en tamaño > de cada fila es de 700 bytes. > > Gracias > > -- > Lindolfo Iván Perales Mancinas > Solo existen 10 tipos de personas en el mundo, las que saben binario y las > que no. > > -- Lindolfo Iván Perales Mancinas Solo existen 10 tipos de personas en el mundo, las que saben binario y las que no.
