Asi como dices Alvaro, es un desastre, fue un desarrollo rápido durante la pandemia, que luego no fue corregido. Si, la idea es llevar los registros antiguos a otra tabla que pueda ser consultada como un historial, esa es la forma creo que salvar esta situación, por que reducir o comprimir no lo hace el vacuum
Gracias El vie, 28 jul 2023 a las 8:59, Alvaro Herrera (<alvhe...@alvh.no-ip.org>) escribió: > Diego Ayala escribió: > > buen dia Francisco, si, tienes razon, mi calculo esta mal, en realidad > son > > 1.2MB por cada columna JSON 1,2MB x 545800=654.960MB que son 69 GB solo > > para esa columna, y el total de la tabla es 72GB, que corresponden al > resto > > de las columnas. > > Usando esta función para estimar el tamaño total de esa columna > > > > select pg_size_pretty(sum(pg_column_size(evento.datos))) FROM > pliego.evento > > Eso suena más razonable. Comprimir un JSON gigante a ~10% del tamaño > original podría ser creíble si suponemos que hay muchísima redundancia > en los datos. Un JSON de 1.2MB seguramente debe ser un absoluto > desastre de diseño, así que una redundancia tan alta podría ser > alcanzable. > > El otro número no tenía ningún sentido. > > > Estoy evaluando eliminar registros anteriores a 1 año para liberar > espacio > > Me imagino que cuando dices "eliminar" quieres decir "mover los datos > antiguos a otra tabla con información histórica". > > -- > Álvaro Herrera Breisgau, Deutschland — > https://www.EnterpriseDB.com/ > "The Gord often wonders why people threaten never to come back after > they've > been told never to return" (www.actsofgord.com) >
