Vous n'êtes pas identifié(e).
Pages : 1
"Limit (cost=161978.97..161978.99 rows=10 width=59) (actual time=7892.944..7892.945 rows=10 loops=1)"
" -> Sort (cost=161978.97..161979.68 rows=284 width=59) (actual time=7892.942..7892.943 rows=10 loops=1)"
" Sort Key: (min(price.price))"
" Sort Method: top-N heapsort Memory: 18kB"
" -> HashAggregate (cost=161969.28..161972.83 rows=284 width=59) (actual time=7892.705..7892.808 rows=414 loops=1)"
" -> Nested Loop (cost=0.00..161647.46 rows=42910 width=59) (actual time=42.308..7881.205 rows=24334 loops=1)"
" -> Seq Scan on product (cost=0.00..21700.56 rows=284 width=55) (actual time=42.281..7222.542 rows=489 loops=1)"
" Filter: (search @@ plainto_tsquery('coca'::text))"
" -> Index Scan using price_num_product_idx on price (cost=0.00..490.88 rows=151 width=12) (actual time=0.199..1.336 rows=50 loops=489)"
" Index Cond: (price.num_product = product.num_product)"
"Total runtime: 7893.049 ms"
Les temps de réponse restent similaires a l'index BTREE..
CREATE INDEX product_tsv_idx
ON product
USING btree
(tsv);
Que ce soit les 48, ou la totalités, le temps d'exec est quasiment le même.
Les 48, c'est un besoin de pagination seulement, ce pourrait etre les 1000, 500 etc.. Et c'est sur un critere de date (les 48 contenant le texte, ordonnés par date DESC).
C'est une recherche qui varie, sur 2 millions de lignes au total, il y a en moyenne 500 a 1000 retours positifs sur le filtre, et je n'affiche que les premiers.
L'index est un BTREE
En fait, sous Postgres, j'avais un champ de type tsvector, qui était la concaténation de 3 autres champs de la même table.
Sous SQL Server, ce champ était indéxé en Recherche de texte intégral (Menu Création..).
Une même requête avec jointure, filtre sur un mot, puis tri pour obtenir les 48 premiers, prend 2500Ms sous PG, et entre 6 et 50ms sous SQL Server (meme nombre de ligne, meme schema de base).
Je ne saurais me l'expliquer à moi même ..
Vous me croirez ou non, la meme recherche full text sur SQL SERVER 2008 prends entre 6 et 50 ms grace à l'utilisation de la clause CONTAINS().
autrement dit, pour de la recherche full text, postgreSQL à encore du boulot à faire.
CDT.
OK.
Merci
Bonjour,
Merci pour votre réponse.
Celle-ci me parait étrange car ce sur quoi je trie est bien un entier, et non du full text?
Bonjour à tous.
Je vous écrit car je suis confronté a une requête plutôt longue dans le temps d'exécution.
C'est une requete qui cherche dans une colonne de type tsvector, et qui doit renvoyer les 48 premières lignes contenant 'coca'
Il y a un index sur la colonne tsv.
SELECT *
FROM PRODUCT
WHERE product.tsv @@ plainto_tsquery('coca')
LIMIT 48 OFFSET 0
Temps d'éxécution : 245Ms, donc plutot bon.
Mais la ou cela se complique, c'est lorsque j'essaie de trier par num_product desc:
C'est un champ de type bigint, ou il y a un index mis en place
SELECT *
FROM PRODUCT
WHERE product.tsv @@ plainto_tsquery('coca')
ORDER BY num_product DESC
LIMIT 48 OFFSET 0
Temps d'éxecution : 2500Ms, et la cela devient trop long pour l'utilisateur..
avez vous des idées d'optimisation possible?
Cordialement
Pages : 1
