On Tue, Apr 22, 2014 at 12:57 AM, Ivan Voras <ivo...@freebsd.org> wrote:
> On 22 April 2014 08:40, Heikki Linnakangas <hlinnakan...@vmware.com>
> wrote:
> > On 04/20/2014 02:15 AM, Ivan Voras wrote:
> >> More details: after thinking about it some more, it might have
> >> something to do with tsearch2 and indexes: the large data in this case
> >> is a tsvector, indexed with GIN, and the query plan involves a
> >> re-check condition.
>
I think bitmap scans always insert a recheck, do to the possibility of
bitmap overflow.
But that doesn't mean that it ever got triggered. In 9.4., explain
(analyze) will report on the overflows.
> Yes, I've read about tsearch2 and GIN indexes and there shouldn't be a
> recheck condition - but there is.
> This is the query:
>
> SELECT documents.id, title, raw_data, q, ts_rank(fts_data, q, 4) AS
> rank, html_filename
> FROM documents, to_tsquery('document') AS q
> WHERE fts_data @@ q
> ORDER BY rank DESC LIMIT 25;
>
> And here is the explain analyze: http://explain.depesz.com/s/4xm
> It clearly shows a bitmap index scan operation is immediately followed
> by a recheck operation AND that the recheck operation actually does
> something, because it reduces the number of records from 61 to 58
> (!!!).
>
That could be ordinary visibility checking, not qual rechecking.
Cheers,
Jeff
