Vous n'êtes pas identifié(e).
Bonjour,
je cherche à écrire une requête qui ne tape que sur une seule table et une seule colonne ...
Ma table DEVICE contient environ 50 000 lignes, présente une colonne "sn" de type character varying(255) et est indexée.
Je dois rechercher les lignes de cette table qui commencent par telle, ou telle, ou telle, ou telle, ... valeur. Cette liste de valeurs possibles peut être grande (2000, 3000 valeurs).
La requête ressemblerait à ceci :
SELECT DEVICE WHERE sn like '0021%' or sn like '12B0%' or sn like '0000%' or sn like '26FF%' or sn like '65FA%' ...
Les valeurs recherchées n'ont pas de logique particulière, cela correspond à des numéros de séries.
En pratique il y a environ 8-10 lignes qui sont retournées pour chaque clause (ex : il y a 10 lignes en base qui commencent par '0021')
Voyez vous une manière d'optimiser une telle requête ? (via une jointure, autre ?)
Merci par avance pour votre aide.
Christophe
Hors ligne
Petit complément, j'ai aussi pensé à une piste sur les regexp, cela pourrait s'écrire :
SELECT DEVICE WHERE sn ~ '^0021|^12B0|^0000|^26FF|^65FA...'
Et j'ai peur que la chaine construite soit trop longue.
Hors ligne
Optimiser par rapport à quoi ? quel est le problème ?
Guillaume.
Hors ligne
Ma question est de savoir comment faire que ma requête ne devienne pas trop couteuse avec le temps et de voir comment gérer au mieux la problématique du multi valeurs.
Vaut il mieux faire un select avec 3000 "OR" : SELECT DEVICE WHERE sn like '0021%' or sn like '12B0%' or sn like '0000%' or sn like '26FF%' or sn like '65FA%' ...
ou alors, vaut il mieux faire un select avec une regexp qui liste les 3000 numéros de séries possibles : "SELECT DEVICE WHERE sn ~ '^0021|^12B0|^0000|^26FF|^65FA...' "
ou y a t il plus performant (jointure ?) ?
Vu que la colonne est indexée, il doit bien y avoir une manière optimisée de faire la recherche.
Merci par avance pour vos lumières.
Hors ligne
À ma connaissance, une liste OR ou une expression rationnelle ne changera pas grand chose. L'espression rationnelle a peu de chance d'utiliser un index mais une grosse liste OR non plus.
De toute façon, si vous avez 2000 filtres, chacun ramenant 10 lignes en moyenne, cela donne 20000 lignes en tout, soit 40% de la table. Peu de chances dans ce cas que PostgreSQL passe par un parcours d'index, il y a trop d'enregistrements à récupérer.
Guillaume.
Hors ligne
Merci Gleu pour vos précisions.
Hors ligne
