Discussion :

[Arnaoud]

Bonjour,

J ai une souci de taille sur ma base de données du à un attribut binaire de quelques dizaines de kilo octets (type bytea).

J'ai donc remanié ces données avant de les stocker.

Au vu de ses données, je suis censé avoir un gain de 2,5 à 3.

Pourtant, lorsque je regarde la taille de la table, le gain est quasi inexistant.
La taille du TOAST associé à cette table reste élevé.

A titre indicatif: Par compression avec winzip le toast de 45 mega passe à 300 kilos. comme si ce fichier etait bien vide

J'ai quelques connaissances en Postgres mais je ne suis pas un expert.
Pouvez vous m'aider.

Cordialement,

Arnaud

[bustaf]

Bonjour
????
(ne pas oublier que rélpages n’est mis à
jour que par l’utilisation des commandes VACUUM et ANALYZE.)

????
build indices

[Arnaoud]

Je te remercie par avance.

Effectivement,
J'ai fait un ANALYZE et VACUUM FULL avant d'avancer ces tailles de disques.

[bustaf]

Bonjour
J'ai regardé un peu dans une base ou plusieurs tables sont impliquées avec
avec TOAST
Pour vérifier si cela compresse vraiment j'ai utilisé (du -a /rep_de_la_base > fichier.txt) et
des (diff)sur les .txt pour comparer après suivant les différentes options de la commande
alter table set storage (MAIN,EXTENDED etc ..
Il y a une compression mais comme je n'ai pas le nombre, la taille, ou le % de champs contraints (toast)
dans cette base impossible d'évaluer un taux.(les tables sont importantes et les tailles de ces champs types sont très variables < 2 Ko & > 2Ko).
Il vaut mieux lire le fichier source C pour voir vraiment ce qu'il fait ...
Bon courage ...

[Arnaoud]

Je te remercie pour la réponse.

L'utilisation de "alter storage set MAIN" m'a donné que peu de satisfaction à première vue.

Je vais voir ce sue je peux faire avec le fichier source.

Arnaud

[bustaf]

Bonjour
Pour vous (45Mo) MAIN ou EXTENDED c'est pareil... il decoupe forcement ..
Questions ?
Vous avez une table avec un type champs de 45 Mo environ ?
et vous evaluez la compression sur un toast-oids d'un enregistrement spécifique que vous
avez identifié via pg_class ou par l'oid ?

[Arnaoud]

Je profite de ce post pour refaire un résumé en te répondant.

J'ai une table avec un attribut data. Cette table ne contient que des données négligeable par rapport à data.
Je travaille avec une bases contenant 1000 data pour mes tests. Ces 1000 data font 45 mégas.

Que je mette cet attribut en Main ou en extended je ne gagne pas de place.

Que je mettent mes data normalement ou après un remaniement, la table prend respectivement 45 puis 40 Mo.

Pour annoncer ces chiffres, j'effectue un full vacuum puis je regarde directement sur le système les tailles des fichiers contenant la table. Si je regarde avec PgAdminIII j'arrive aux mêmes chiffres.

Le problème est que 45 Mo pour si peu de données c est beaucoup trop.
Je rappelle que si je zippe ces fichiers aux niveaux système, je me retrouve avec un fichier zip de quelques centaines de kilos.

Je te remercie de tes réponses et du temps que tu passe à comprendre mes problèmes.

[bustaf]

Bonjour
J'ai regardé le source ......
Le developpeur explique qu'il n'y a aucune chance d'obtenir un gain
de compression si les champs (tartinés ) dépassent les plages
1Ko <-> 1Mo....
La tartine sans trop de beurre... pour rester mince
Bon courage ......