Odpowiedź zależy od wielu czynników, takich jak wersja Postgresa, kodowanie i lokalizacja — LC_COLLATE w szczególności.
Samo wyrażenie lower(description) LIKE '%abc%' jest zazwyczaj nieco szybszy niż description ILIKE '%abc%' , a oba są nieco szybsze niż równoważne wyrażenie regularne:description ~* 'abc' . Ma to znaczenie w przypadku skanowań sekwencyjnych, w których wyrażenie musi zostać ocenione dla każdego testowanego wiersza.
Ale w przypadku dużych tabel, które pokazujesz w swojej odpowiedzi, z pewnością użyjesz indeksu. W przypadku dowolnych wzorców (nie tylko zakotwiczonych w lewo) proponuję indeks trygramów za pomocą dodatkowego modułu pg_trgm . Następnie mówimy o milisekundach zamiast sekundach, a różnica między powyższymi wyrażeniami jest zerowana.
Indeksy GIN i GiST (przy użyciu gin_trgm_ops lub gist_trgm_ops klasy operatorów) obsługują LIKE (~~ ), ILIKE (~~* ), ~ , ~* (i kilka innych wariantów). Z trygramowym indeksem GIN na description (zwykle większe niż GiST, ale szybsze w przypadku odczytów), w zapytaniu użyto by description ILIKE 'case_insensitive_pattern' .
Powiązane:
- Odmiany wydajności zapytań PostgreSQL LIKE
- Podobne ciągi UTF-8 dla pola autouzupełniania
Podstawy dopasowywania wzorców w Postgresie:
- Dopasowywanie wzorców za pomocą LIKE, SIMILAR TO lub wyrażeń regularnych w PostgreSQL
Podczas pracy ze wspomnianym indeksem trygramów jest zazwyczaj bardziej praktyczne w pracy z:
description ILIKE '%abc%'
Lub z operatorem regexp niewrażliwym na wielkość liter (bez % symbole wieloznaczne):
description ~* 'abc'
Indeks na (description) nie obsługuje zapytań na lower(description) jak:
lower(description) LIKE '%abc%'
I wzajemnie.
Z predykatami na lower(description) wyłącznie , indeks wyrażenia jest nieco lepszą opcją.
We wszystkich innych przypadkach indeks (description) jest preferowany, ponieważ obsługuje oba predykaty rozróżniające wielkość liter i -niewrażliwe.
