Re: Tabla TOAST muy grande

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 (<alvherre(at)alvh(dot)no-ip(dot)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)
>