Je to přesně tak, jak jste četli z jjanes jinde:index výrazu se bere v úvahu pouze tehdy, pokud se výraz přesně shoduje v predikátu dotazu. Plánovač dotazů Postgres není AI. Pokud by plánování trvalo příliš dlouho, rychle by to zmařilo účel rychlého provádění dotazů.
Pokud je to útěchou, můžete svůj index trochu optimalizovat. left() je jednodušší a rychlejší než substring() :
CREATE INDEX record_changes_log_detail_old_value_ix_btree
ON record_changes_log_detail (left(old_value,1024) text_pattern_ops);
K dispozici je také maximální velikost řádku 2704 bajtů pro indexy btree, nikoli "limit 2172 znaků na B-stromech" .
A co je nejdůležitější, pouze pro kontroly rovnosti, jak naznačuje vaše otázka, je btree index na hash hodnotě pomocí md5(old_value) nebo hashtext(old_value) by bylo hodně Efektivnější. Pokud tak učiníte, nezapomeňte se bránit kolizím hash takhle:
SELECT *
FROM record_changes_log_detail
WHERE hashtext(old_value) = hashtext('Gold Kerrison Neuro')
AND old_value = 'Gold Kerrison Neuro';První predikát vám poskytuje rychlý přístup k indexu. Druhý vylučuje falešné poplachy. Srážky by měly být extrémně vzácné. Ale možné. A možnost roste s velikostí stolu.
Související:
- VYBRAT dotaz s DISTINCT na strukturu tabulky pro grafy je velmi pomalý
- Jaký je optimální datový typ pro pole MD5?
- Fulltextové vyhledávání v CouchDB
Nebo hash index, o kterém jste již uvažovali:
- Proč je hash index Postgres 11 tak velký?
(Zde se nemusíte obávat kolizí hash, je řešeno interně.)