Postgres 9.2 ou version ultérieure est généralement assez intelligent pour se rendre compte que la condition
WHERE name LIKE '%%'
n'est pas sélectif et recourt à une analyse séquentielle en ignorant l'index GiST - même avec des déclarations préparées. Vous faites payer un petit prix pour la condition inutile, cependant.
Dans Postgres 9.1 ou une version antérieure, je créerais une requête distincte pour le cas particulier.
Comparez les Notes section pour le PREPARE déclaration dans le manuel pour les versions 9.1
, 9.2
et 9.3
.
Vérifiez-vous
Préparez l'instruction et exécutez EXPLAIN ANALYZE tester :
PREPARE plan1 (text) AS
SELECT * FROM file
WHERE name LIKE $1;
EXPLAIN ANALYZE EXECUTE plan1('%123%');
EXPLAIN ANALYZE EXECUTE plan1('%%');
Les plans sont généralement mis en cache pendant la durée de la session.
Requête alternative
Quelle que soit la version que vous utilisez, si vous effectuez toujours une recherche plein texte (caractères génériques à gauche et à droite), cette requête devrait être plus rapide pour une instruction préparée :
SELECT * FROM files WHERE name LIKE ('%' || $1 || '%');
Et passez le modèle sans ajout de caractères génériques (% ), bien sûr. De cette façon, Postgres sait s'attendre à un modèle entouré de caractères génériques au moment de la planification.
->Démo SQLfiddle.
Notez l'analyse séquentielle pour le LIKE vide et la différence de performances entre les deux plans.
SQLfiddle varie beaucoup, en fonction de la charge, etc. Une seule exécution peut ne pas être fiable. Mieux vaut tester dans votre environnement et exécuter chaque instruction plusieurs fois pour saturer le cache et éliminer le bruit.
