[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-general
Subject:    Re: bitmap heap scan exact/lossy blocks and row removal
From:       Tom Lane <tgl () sss ! pgh ! pa ! us>
Date:       2020-12-24 0:57:02
Message-ID: 748833.1608771422 () sss ! pgh ! pa ! us
[Download RAW message or body]

Augusto Callejas <acallejas@instructure.com> 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 understandi=
ng
> (mainly from
> https://paquier.xyz/postgresql-2/postgres-9-4-feature-highlight-lossyexa=
ct-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


[prev in list] [next in list] [prev in thread] [next in thread]