Re: How to avoid a GIN recheck condition

Alexis <alexis(at)bernard(dot)io> writes:
> I have a GIN index but the planner rechecks the condition. When many rows
> are foud in the index that is very slow:

You're assuming a fact not in evidence, namely that the recheck condition
is being used at runtime. The planner will *always* attach a recheck
condition to a bitmap heap scan, but it only gets used if
(1) the index opclass reports that its result is lossy, or
(2) the bitmap bloats to the point where it has to be stored lossily.

I see no weights in your query so (1) isn't happening, and it seems
unlikely that (2) is happening if the rowcount estimate is on target.
Lacking EXPLAIN ANALYZE results, it's hard to speculate further.

regards, tom lane