Postgres 9.2 nebo novější je obecně dostatečně chytrý, aby si uvědomil, že podmínka
WHERE name LIKE '%%'
není selektivní a uchýlí se k sekvenčnímu skenování ignorujícímu index GiST – dokonce i s připravenými výpisy. děláte zaplatit malou cenu za zbytečný stav.
V Postgresu 9.1 nebo starším bych vytvořil samostatný dotaz pro speciální případ.
Porovnejte Poznámky sekce pro PREPARE prohlášení v příručce pro verze 9.1
, 9.2
a 9.3
.
Ověřte se
Připravte příkaz a spusťte EXPLAIN ANALYZE testovat:
PREPARE plan1 (text) AS
SELECT * FROM file
WHERE name LIKE $1;
EXPLAIN ANALYZE EXECUTE plan1('%123%');
EXPLAIN ANALYZE EXECUTE plan1('%%');
Plány jsou obecně ukládány do mezipaměti po dobu trvání relace.
Alternativní dotaz
Bez ohledu na verzi, kterou používáte, pokud vždy provádíte fulltextové vyhledávání (zástupné znaky vlevo a vpravo), tento dotaz by měl být rychlejší pro připravený příkaz:
SELECT * FROM files WHERE name LIKE ('%' || $1 || '%');
A předat vzor bez přidaných zástupných znaků (% ), samozřejmě. Tímto způsobem Postgres ví, že v době plánování očekává vzor uzavřený v zástupných znacích.
->Ukázka SQLfiddle.
Všimněte si sekvenčního skenování prázdného LIKE a rozdílu ve výkonu mezi těmito dvěma plány.
SQLfiddle se hodně liší v závislosti na zatížení atd. Jedno spuštění nemusí být spolehlivé. Raději otestujte ve svém prostředí a spusťte každý příkaz několikrát, abyste nasytili mezipaměť a odstranili šum.