Forums PostgreSQL.fr

Marc Cousin

Membre

Re : Vitesse Postgres

Ok. Si vous pouvez avoir plusieurs signatures différentes pour un même algorithme, je comprends mieux.

Un dernier point: pouvez vous avoir plusieurs ids différents pour la même signature ? sinon, autant stocker directement la signature.

---

Marc.

kris_le_parisien

Membre

Re : Vitesse Postgres

Ok. merci.

Pour les signatures, chacune d'elles a identifiant unique (on a crée cette relation, pour identifier de manière unique les résultats de chaque algorithme). Il n'y a donc qu'un seul ID pour une signature. Je n'ai pas très bien compris quand vous dites stocker directement la signature.

J'ai oublié de préciser que toutes les signatures ne sont pas toutes utilisées (le véritable mot est: entraînées) par un cluster. C'est le cas pour seulement certaines d'entre elles. 1 signature peut être utilisée par plusieurs clusters.
Votre suggestion était peut-être de placer les attributs de signatures directement dans ClustersSignature. Mais la précision que j'ai rajoutée l'en empêche, je pense.

merci beaucoup pour votre aide.

Dernière modification par kris_le_parisien (03/03/2011 19:03:21)

kris_le_parisien

Membre

Re : Vitesse Postgres

Bonjour,

j'aurais une question à propos des colonnes contenant des valeurs très grosses.
J'ai ainsi une colonne appelée sig_vector contenant des valeurs de type bytea:

exemple de la valeur d'une ligne:
1.11498E+02, 1.35706E+02, 2.88843E+02, 1.30191E+02, 1.89009E+02, 1.88747E+02, 1.16372E+03, 1.71711E+02, 1.84266E+02, 2.83373E+02, 2.02455E+03, 2.50216E+02, 2.94586E+02, 4.01803E+02, 2.74225E+03, 3.59621E+02, 2.37780E+02, 4.26430E+02, 4.90676E+03, 3.64694E+02

Quelque soit la requête SELECT, quand je rajoute la colonne sig_vector, ça me ralentit énormément les temps d'exécution.

Sauriez- vous si en modifiant la valeur d'un paramètre on peut diminuer ce temps?

Exemple:

SELECT id_image, id_signature, norm_x, norm_y, scale_numbers, quadrant  ---> 11 279 ms en ayant augmenté le paramètre work_mem à 5MB
FROM  sig_gab,signature, image
where signature.image_id_image = image.id_image
and signature.id_signature = sig_gab.signature_id_signature order by time

SELECT id_image, id_signature, norm_x, norm_y, scale_numbers, quadrant,sig_vector --> 55 450 ms quelque soit la valeur de work_mem
FROM  sig_gab,signature, image
where signature.image_id_image = image.id_image
and signature.id_signature = sig_gab.signature_id_signature order by time;

résultats du explain analyse:

"Sort  (cost=66346.27..66685.69 rows=135769 width=292) (actual time=1671.917..1869.361 rows=137058 loops=1)"
"  Sort Key: image."time""
"  Sort Method:  external merge  Disk: 40928kB"
"  ->  Hash Join  (cost=7606.65..36207.42 rows=135769 width=292) (actual time=135.894..1105.050 rows=137058 loops=1)"
"        Hash Cond: (signature.image_id_image = image.id_image)"
"        ->  Merge Join  (cost=8.85..15113.99 rows=137058 width=284) (actual time=0.101..568.280 rows=137058 loops=1)"
"              Merge Cond: (sig_gab.signature_id_signature = signature.id_signature)"
"              ->  Index Scan using fk_sig_gab_signature on sig_gab  (cost=0.00..9058.56 rows=137058 width=280) (actual time=0.058..184.511 rows=137058 loops=1)"
"              ->  Index Scan using signature_pkey on signature  (cost=0.00..50013.17 rows=1645065 width=8) (actual time=0.036..170.357 rows=137059 loops=1)"
"        ->  Hash  (cost=5214.58..5214.58 rows=137058 width=12) (actual time=135.720..135.720 rows=137058 loops=1)"
"              ->  Seq Scan on image  (cost=0.00..5214.58 rows=137058 width=12) (actual time=0.014..76.676 rows=137058 loops=1)"
"Total runtime: 1939.968 ms"

Marc Cousin

Membre

Re : Vitesse Postgres

La colonne est probablement stockée en dehors de la table (ça s'appelle le mécanisme TOAST) sous Postgres.

Donc quand vous n'accédez pas à cette colonne, il n'a pas besoin d'aller la chercher, ce qui est plus rapide. Il n'y a rien à faire pour rendre ça plus rapide: vous accédez à davantage de données, ça prend donc plus de temps.

---

Marc.

kris_le_parisien

Membre

Re : Vitesse Postgres

oui je crois que c'est ça. Pour chacune de mes tables contenant des éléments de type bytea, une table TOAST lui est associé.

- J'ai vu qu'il y avait aussi l'insertion d'objets larges (dans pg_largeobject) . Je voudrais savoir si cela ne concernait que l'insertion de fichier depuis un autre programme (exemple une image au format jpeg depuis une application écrite en C) dans la base?
- Si il y a un moyen d'utiliser cette méthode, pour juste insérer de grosses données (comme de volumineux  résultats de calculs, mais pas des fichiers), cela serait - t - il plus efficace que la méthode TOAST?

- Dans ma table sig_gab: La colonne Sig_vector de type bytea a un stockage de type EXTENDED.
Si je change le type de stockage pour EXTERNAL, mes requêtes (SELECT surtout) sur cette colonne sera -t- elle plus rapide, malgré un espace de stockage plus grand (corrigez- moi au cas où j'ai mal compris la définition )?

Si l'on choisit la méthode EXTERNAL, il y a -t-il un moyen d'estimer l'espace de stockage liée à la table TOAST? (Etant donnée n lignes dans la table sig_gab (sig_vector est non nulle), et qu'il est indiqué largeur moyenne de colonne sig_vector = 263)?

merci d'avance

Dernière modification par kris_le_parisien (18/03/2011 20:15:29)

Marc Cousin

Membre

Re : Vitesse Postgres

largeobject et toast vont avoir la même performance (ça marche pareil, derrière). La plupart du temps on utilise des bytea, les performances sont les mêmes et c'est le plus souvent plus simple à manipuler. Accéder à la colonne bytea, ou à un large object dont l'oid sera stockée dans la table, ça sera le même coût.

Le passage d'extended à external pourrait être plus rapide mais j'en doute. À moins que vos données se compressent vraiment très mal.

Pour la taille de stockage en  external, je ne me suis jamais posé la question, désolé
Mais il y a de toutes façons un surcoût par rapport à la taille réelle de la colonne, ne serait-ce que parce qu'il y a des index dans le toast.

---

Marc.

kris_le_parisien

Membre

Re : Vitesse Postgres

En effet,

quelque soit la stratégie de stockage utilisé, on a toujours les mêmes temps d’exécution.

merci beaucoup pour vos réponses