Prestandapåverkan av tom LIKE i ett förberett uttalande

Postgres 9.2 eller senare är i allmänhet smart nog att inse att tillståndet

WHERE name LIKE '%%'

är inte selektiv och använder sig av en sekventiell genomsökning som ignorerar GiST-indexet - även med förberedda uttalanden. Du gör betala ett litet pris för det oanvändbara skicket.

I Postgres 9.1 eller tidigare skulle jag bygga en separat fråga för specialfallet.

Jämför Anteckningar avsnittet för PREPARE uttalande i manualen för versionerna 9.1 stark> , 9.2 och 9.3 .

Verifiera dig själv

Förbered satsen och kör EXPLAIN ANALYZE att testa:

PREPARE plan1 (text) AS
SELECT  * FROM file
WHERE   name LIKE $1;

EXPLAIN ANALYZE EXECUTE plan1('%123%');

EXPLAIN ANALYZE EXECUTE plan1('%%');

Planer cachelagras vanligtvis under sessionens varaktighet.

Alternativ fråga

Oavsett vilken version du kör, om du alltid utför en fulltextsökning (jokertecken till vänster och höger), bör denna fråga vara snabbare för en förberedd sats:

SELECT * FROM files WHERE name LIKE ('%' || $1 || '%');

Och skicka mönstret utan tillagda jokertecken (% ), självklart. På så sätt vet Postgres att förvänta sig ett mönster inneslutet i jokertecken vid planeringstillfället.

->SQLfiddle-demo.
Observera den sekventiella skanningen för den tomma LIKE och prestandaskillnaden mellan de två planerna.
SQLfiddle varierar mycket, beroende på belastning etc. En enda körning kanske inte är tillförlitlig. Testa bättre i din miljö och kör varje programsats ett par gånger för att mätta cacheminnet och eliminera brus.