Postgres 9.2 of hoger is over het algemeen slim genoeg om te beseffen dat de aandoening
WHERE name LIKE '%%'
is niet selectief en neemt zijn toevlucht tot een sequentiële scan die de GiST-index negeert - zelfs met voorbereide verklaringen. Jij doe betaal echter een kleine prijs voor de nutteloze toestand.
In Postgres 9.1 of eerder zou ik een aparte query maken voor het speciale geval.
Vergelijk de Opmerkingen sectie voor de PREPARE verklaring in de handleiding voor de versies 9.1
, 9.2
en 9.3
.
Verifieer uzelf
Bereid de instructie voor en voer EXPLAIN ANALYZE uit om te testen:
PREPARE plan1 (text) AS
SELECT * FROM file
WHERE name LIKE $1;
EXPLAIN ANALYZE EXECUTE plan1('%123%');
EXPLAIN ANALYZE EXECUTE plan1('%%');
Plannen worden over het algemeen in de cache opgeslagen voor de duur van de sessie.
Alternatieve zoekopdracht
Ongeacht de versie die u gebruikt, als u altijd een volledige tekstzoekopdracht uitvoert (jokertekens links en rechts), zou deze zoekopdracht sneller moeten zijn voor een voorbereide verklaring:
SELECT * FROM files WHERE name LIKE ('%' || $1 || '%');
En geef het patroon door zonder toegevoegde jokertekens (% ), natuurlijk. Op deze manier weet Postgres tijdens de planning een patroon te verwachten dat is ingesloten in jokertekens.
->SQLfiddle-demo.
Let op de sequentiële scan voor de lege LIKE en het prestatieverschil tussen de twee plannen.
SQLfiddle varieert veel, afhankelijk van de belasting enz. Een enkele run is mogelijk niet betrouwbaar. Test beter in uw omgeving en voer elke instructie een paar keer uit om de cache te verzadigen en ruis te elimineren.