Postgres 9.2 или по-нова версия като цяло е достатъчно умен, за да разбере, че условието
WHERE name LIKE '%%'
не е селективен и прибягва до последователно сканиране, игнорирайки GiST индекса - дори и с подготвени отчети. Вие правите платете обаче малка цена за безполезното състояние.
В Postgres 9.1 или по-ранна версия бих създал отделна заявка за специалния случай.
Сравнете бележките раздел за PREPARE изявление в ръководството за версиите 9.1
, 9.2
и 9.3
.
Удостоверете се
Подгответе израза и стартирайте EXPLAIN ANALYZE за тестване:
PREPARE plan1 (text) AS
SELECT * FROM file
WHERE name LIKE $1;
EXPLAIN ANALYZE EXECUTE plan1('%123%');
EXPLAIN ANALYZE EXECUTE plan1('%%');
Плановете обикновено се кешират за продължителността на сесията.
Алтернативна заявка
Независимо от версията, която използвате, ако винаги извършвате пълнотекстово търсене (заместващи символи отляво и отдясно), тази заявка трябва да бъде по-бърза за подготвен израз:
SELECT * FROM files WHERE name LIKE ('%' || $1 || '%');
И предайте модела без добавени заместващи знаци (% ), разбира се. По този начин Postgres знае да очаква шаблон, ограден със заместващи символи по време на планиране.
->Демо на SQLfiddle.
Обърнете внимание на последователното сканиране за празния LIKE и разликата в производителността между двата плана.
SQLfiddle варира много в зависимост от натоварването и т.н. Еднократно изпълнение може да не е надеждно. По-добре тествайте във вашата среда и изпълнете всеки оператор няколко пъти, за да наситете кеша и да премахнете шума.
