Augusto Callejas <acallejas@xxxxxxxxxxxxxxx> writes: > 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. "exact" in that context just means that the bitmap mechanism didn't forget any details about which row TIDs were returned by the index. But the index itself could be lossy, ie it can return some rows that only *might* match the query. The recheck mechanism exists mainly for that purpose --- backstopping a lossy bitmap was something we tacked on later. An example here is that a trigram index will only tell you which rows contain the same trigrams that the query string does. Whether they are in the right order has to be verified by a recheck of the original query operator applied to the real data. regards, tom lane
