Forums PostgreSQL.fr

Geo-x

Membre

Table obèse...mais pourquoi ?

Bonjour @ tous.

Comme vous pouvez le constaer j'ai une table obèse mais je ne sais absolument pas pourquoi... J'ai une table1 qui contient plus de 100 000 enregistrements et qui ne pose aucun souci de gestion, et à côté j'ai cette fameuse table2 qui compte le même nombre de colonne que table1, et qui ne compte que 54 000 enregistrements et qui pourtant pose d'énormes souci de lenteurs.

J'ai testé le VACUUM, l'indexage etc... mais rien n'y fait.

Existe-t-il une façon d'identifier la source du problème?

Par avance merci de votre aide.

Geo-x

rjuju

Administrateur

Re : Table obèse...mais pourquoi ?

Bonjour,

Tout dépend de quel est le problème exactement. Qu'entendez-vous par obèse ? Avez-vous comparé la volumétrie de ces deux tables ?

---

Julien.
https://rjuju.github.io/

Geo-x

Membre

Re : Table obèse...mais pourquoi ?

Bonsoir rjuju.

J'ai tenté de sauvegarder ma table en SQL et cette sauvegarde a généré un fichier .sql pesant...30 Go...!

En revanche je n'ai pas tenté la comparaison avec l'autre table en terme d'enregistrement mais juste en terme d'ouverture des 100 premières lignes et là, c'est édifiant.

Geo-x

gleu

Administrateur

Re : Table obèse...mais pourquoi ?

Il va falloir donner franchement BEAUCOUP plus de détails. Quelle est la taille de la table, quelle nombre d'enregistrements elle a, quel est sa définition (colonnes) ? avec ça, on pourra juger si elle est grosse ou pas. Le fait que la sauvegarde SQL fasse 30 Go ne veut absolument rien dire, surtout si elle contient des objets binaires.

---

Guillaume.

Geo-x

Membre

Re : Table obèse...mais pourquoi ?

Bonjour gleu.

Je vais tenter de répondre à vos questions.

Ma table contient 53 872 enregistrements pour 77 colonnes dont voici les différents types :

"USER-DEFINED" (correspond au type geometry (Polygon))
"character"
"character varying"
"double precision"
"integer"
"text"

En terme de taille, si je l'interroge de la façon suivante :

SELECT
   relname as "Table",
   pg_size_pretty(pg_total_relation_size(relid)) As "Size",
   pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) as "External Size"
   FROM pg_catalog.pg_statio_user_tables ORDER BY pg_total_relation_size(relid) DESC;

J'obtiens le résultat de 665Mb en Size et 642Mb en External Size.

Si ils vous manquent des informations n'hésitez pas.

Cordialement.

Geo-x

Geo-x

Membre

Re : Table obèse...mais pourquoi ?

Autre fait étrange.

Je viens d'effectuer une requête qui m'a pris 134 567 ms, là ou cette même requête avec un EXPLAIN ANALYZE m'indique :

"Seq Scan on "9_parcelle"  (cost=0.00..3590.40 rows=15355 width=4043020) (actual time=0.026..23.919 rows=15385 loops=1)"
"  Filter: (surface < 500::double precision)"
"Total runtime: 24.524 ms"

gleu

Administrateur

Re : Table obèse...mais pourquoi ?

Concernant la taille, je ne la trouve pas si énorme que ça. 1,3 Go, c'est rien. J'étais aujourd'hui chez un client dont une table faisait 13 Go. ET là-aussi, ce n'est pas une grosse table.

Concernant votre deuxième commentaire, où voyez-vous qu'elle a pris 134567 ms ? dans pgAdmin je parie ?

---

Guillaume.

Geo-x

Membre

Re : Table obèse...mais pourquoi ?

Affirmatif, sur PG Admin c'est le temps que cette requête met.
Par ailleurs lorsque je lis cette table à partir du logiciel FME, il me faut environ quatre heures pour lire à peine les enregistrements.

En fait, je suis tout simplement en train de me demander si le problème ne vient pas des géométries présentes dans ma table.
Je continue à creuser et vous fait un retour si je trouve des réponses.

gleu

Administrateur

Re : Table obèse...mais pourquoi ?

La réponse est simple : c'est le temps de transférer les informations du serveur vers pgAdmin, et le temps pour pgAdmin d'afficher ces informations dans son grid. La requête est très rapide du côté de PostgreSQL, c'est très lent du côté des clients. Du coup, votre logiciel FME est encore plus lent que pgAdmin, ce qui est une performance en soi !

---

Guillaume.