Re: tsearch2, large data and indexes

On Tue, Apr 22, 2014 at 12:57 AM, Ivan Voras <ivoras(at)freebsd(dot)org> wrote:

> On 22 April 2014 08:40, Heikki Linnakangas <hlinnakangas(at)vmware(dot)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