Det är precis som du läser från jjanes någon annanstans:ett uttrycksindex beaktas bara om uttrycket matchas exakt i frågepredikatet. Postgres frågeplanerare är inte en AI. Det skulle snabbt motverka syftet att göra frågor snabbt om det tar för lång tid att planera dem.
Du kan optimera ditt index lite, om det är någon tröst. left() är enklare och snabbare än substring() :
CREATE INDEX record_changes_log_detail_old_value_ix_btree
ON record_changes_log_detail (left(old_value,1024) text_pattern_ops);
Det finns också en maximal radstorlek på 2704 byte för btree-index, inte en "2172 teckenbegränsning på B-träd" .
Viktigast av allt, för enbart jämställdhetskontroller, som din fråga antyder, ett btree-index på ett hashvärde med md5(old_value) eller hashtext(old_value) skulle vara mycket mer effektiv. Om du gör det, kom ihåg att försvara dig mot hashkollisioner som så:
SELECT *
FROM record_changes_log_detail
WHERE hashtext(old_value) = hashtext('Gold Kerrison Neuro')
AND old_value = 'Gold Kerrison Neuro';Det första predikatet ger dig snabb indexåtkomst. Den andra utesluter falska positiva resultat. Kollisioner bör vara extremt sällsynta. Men möjligt. Och möjligheten växer med storleken på bordet.
Relaterat:
- SELECT-fråga med DISTINCT på en tabellstruktur för grafer är mycket långsam
- Vilken är den optimala datatypen för ett MD5-fält?
- Fulltextsökning i CouchDB
Eller ett hashindex som du redan har tänkt på dig själv:
- Varför är ett Postgres 11-hashindex så stort?
(Här behöver du inte oroa dig för hashkollisioner, hanteras internt.)