To tak, jak czytasz z jjanes gdzie indziej:indeks wyrażenia jest brany pod uwagę tylko wtedy, gdy wyrażenie jest dokładnie dopasowane w predykacie zapytania. Planer zapytań Postgres nie jest sztuczną inteligencją. Szybko przekreśliłoby to cel szybkiego tworzenia zapytań, jeśli planowanie ich trwałoby zbyt długo.
Możesz trochę zoptymalizować swój indeks, jeśli jest to jakaś pociecha. left() jest prostsze i szybsze niż substring() :
CREATE INDEX record_changes_log_detail_old_value_ix_btree
ON record_changes_log_detail (left(old_value,1024) text_pattern_ops);
Ponadto istnieje maksymalny rozmiar wiersza wynoszący 2704 bajtów dla indeksów btree, a nie "limit 2172 znaków na B-drzewa" .
Co najważniejsze, tylko w przypadku sprawdzania równości, jak sugeruje twoje pytanie, indeks btree na wartości skrótu przy użyciu md5(old_value) lub hashtext(old_value) byłoby dużo bardziej wydajny. Jeśli tak, pamiętaj, aby bronić się przed kolizjami haszowania tak:
SELECT *
FROM record_changes_log_detail
WHERE hashtext(old_value) = hashtext('Gold Kerrison Neuro')
AND old_value = 'Gold Kerrison Neuro';Pierwszy predykat zapewnia szybki dostęp do indeksu. Drugi wyklucza fałszywe alarmy. Zderzenia powinny być niezwykle rzadkie. Ale możliwe. A możliwość rośnie wraz z wielkością stołu.
Powiązane:
- Zapytanie SELECT z DISTINCT na strukturze tabeli dla wykresów jest bardzo wolne
- Jaki jest optymalny typ danych dla pola MD5?
- Wyszukiwanie pełnotekstowe w CouchDB
Lub indeks haszowy, o którym już myślałeś:
- Dlaczego indeks skrótu Postgres 11 jest tak duży?
(Tutaj nie musisz się martwić o kolizje haszowania; obsługiwane wewnętrznie.)
