I created a GIN index on the following relation and ran an EXPLAIN query on a query, and noticed that despite all heap blocks being exact, that the outermost bitmap heap scan removed 62 rows after recheck. My understanding (mainly from https://paquier.xyz/postgresql-2/postgres-9-4-feature-highlight-lossyexact-pages-for-bitmap-heap-scan) is that if there are only exact pages, then there are only tuples in the bitmap, so I wouldn't expect to see rows being removed by the recheck. I maxed out the work memory just in case the bitmap was hitting a memory threshold where it would have to switch to lossy mode. Why would rows be removed with only exact pages?
For reference, I'm running PostgreSQL 11.9. === SHOW work_mem; work_mem -------------- 2147483647kB CREATE INDEX trgm_idx ON outcomes_development_shard_2.outcomes USING gin ((description || ' ' || title || ' ' || label) gin_trgm_ops); EXPLAIN ANALYSE SELECT COUNT(*) FROM outcomes_development_shard_2.outcomes WHERE (description || ' ' || title || ' ' || label) %> 'multiplicatio'; QUERY PLAN ---------------------------------------------------------------------------------------------------------------------------------------------- Aggregate (cost=126.70..126.71 rows=1 width=8) (actual time=9.197..9.198 rows=1 loops=1) -> Bitmap Heap Scan on outcomes (cost=116.02..126.70 rows=3 width=0) (actual time=0.469..9.186 rows=49 loops=1) Recheck Cond: ((((((description)::text || ' '::text) || (title)::text) || ' '::text) || (label)::text) %> 'multiplicatio'::text) Rows Removed by Index Recheck: 62 Heap Blocks: exact=59 -> Bitmap Index Scan on trgm_idx (cost=0.00..116.02 rows=3 width=0) (actual time=0.303..0.303 rows=111 loops=1) Index Cond: ((((((description)::text || ' '::text) || (title)::text) || ' '::text) || (label)::text) %> 'multiplicatio'::text) Planning Time: 0.111 ms Execution Time: 9.232 ms (9 rows) === Thanks, Augusto -- -- *Augusto Callejas | Senior Software Engineer* *E:* acalle...@instructure.com <http://instructure.com/>