Aqui está parte de uma EXPLAIN ANALYZE do Postgres 9.6:
-> Bitmap Heap Scan on cities (cost=90.05..806.49 rows=265 width=4) (actual time=4.733..45.772 rows=17 loops=1)
Recheck Cond: (regexp_replace(regexp_replace(replace(replace(replace(replace(lower(name), 'ä'::text, 'ae'::text), 'ö'::text, 'oe'::text), 'ü'::text, 'ue'::text), 'ß'::text, 'ss'::text), 'strasse\M'::text, 'strasse'::text, 'g'::text), '\W'::text, ''::text, 'g'::text) % 'coerde'::text)
Rows Removed by Index Recheck: 567
Heap Blocks: exact=497
-> Bitmap Index Scan on city_lookup_index (cost=0.00..89.98 rows=265 width=0) (actual time=4.229..4.229 rows=584 loops=1)
Index Cond: (regexp_replace(regexp_replace(replace(replace(replace(replace(lower(name), 'ä'::text, 'ae'::text), 'ö'::text, 'oe'::text), 'ü'::text, 'ue'::text), 'ß'::text, 'ss'::text), 'strasse\M'::text, 'strasse'::text, 'g'::text), '\W'::text, ''::text, 'g'::text) % 'coerde'::text)
O que Rows Removed by Index Recheck
significa?
Ou em outras palavras: o bitmap não apresenta perdas (apenas exact
páginas), então por que ele contém ponteiros de tupla que foram (presumivelmente) removidos pela nova verificação?
Algumas estratégias de índice não concluem definitivamente que uma tupla atende aos critérios. Eles podem eliminar definitivamente e rapidamente a maioria das tuplas que comprovadamente não atendem aos critérios (de onde vem o ganho de desempenho), mas algumas das que passam podem ser falsos positivos, portanto, precisam ser verificadas novamente.
Acho que você está usando
gin_trgm_ops
, que é um exemplo dessa estratégia de indexação.