Die Antwort hängt von vielen Faktoren wie Postgres-Version, Kodierung und Gebietsschema ab - LC_COLLATE insbesondere.
Der bloße Ausdruck lower(description) LIKE '%abc%' ist typischerweise etwas schneller als description ILIKE '%abc%' , und beide sind etwas schneller als der entsprechende reguläre Ausdruck:description ~* 'abc' . Dies ist wichtig für sequentielle Scans, bei denen der Ausdruck für jede getestete Zeile ausgewertet werden muss.
Aber Für große Tabellen, wie Sie sie in Ihrer Antwort demonstrieren, würde man sicherlich einen Index verwenden. Für beliebige Muster (nicht nur links-verankert) schlage ich einen Trigram-Index mit dem Zusatzmodul pg_trgm vor . Dann sprechen wir von Millisekunden statt Sekunden und der Unterschied zwischen den obigen Ausdrücken wird aufgehoben.
GIN- und GiST-Indizes (unter Verwendung des gin_trgm_ops oder gist_trgm_ops Operatorklassen) unterstützen LIKE (~~ ), ILIKE (~~* ), ~ , ~* (und einige weitere Varianten) gleichermaßen. Mit einem Trigramm-GIN-Index auf description (normalerweise größer als GiST, aber schneller für Lesevorgänge), würde Ihre Abfrage description ILIKE 'case_insensitive_pattern' verwenden .
Verwandte:
- Änderungen der PostgreSQL LIKE-Abfrageleistung
- Ähnliche UTF-8-Strings für das Autocomplete-Feld
Grundlagen für den Musterabgleich in Postgres:
- Mustervergleich mit LIKE, SIMILAR TO oder regulären Ausdrücken in PostgreSQL
Bei der Arbeit mit besagtem Trigram-Index ist es typisch praktischer zu handhaben:
description ILIKE '%abc%'
Oder mit dem case-insensitiven Regexp-Operator (ohne % Platzhalter):
description ~* 'abc'
Ein Index auf (description) unterstützt keine Abfragen auf lower(description) wie:
lower(description) LIKE '%abc%'
Und umgekehrt.
Mit Prädikaten auf lower(description) ausschließlich , der Ausdrucksindex ist die etwas bessere Option.
In allen anderen Fällen ein Index auf (description) ist vorzuziehen, da es beides unterstützt case-sensitive und -insensitive Prädikate.
