Vous n'êtes pas identifié(e).
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.
Hors ligne
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)
Hors ligne
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"
Hors ligne
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.
Hors ligne
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)
Hors ligne
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.
Hors ligne
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
Hors ligne
