>Some indexes are inexact, i.e. they may sometimes return tuples that
>don't actually match the index condition.
What causes an index to be inexact. When you create an index and vacuum it regularly, it is suppose to be correct....right??
>This also happens with bitmap
>scans, because it'll return anything in the bitmap which will probably
>be more than what you asked for. The recheck just means that the
>planner retests the index condition on the result to make sure you only
>get the rows you wanted
So does recheck condition affect the performance of the queries since it basically rechecks the condition?
Also does it goes to the heap to retest ?
For example for this query
explain analyze select count(*) from foo where foo_id=1 I get the following plan
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------
Aggregate (cost=1949.84..1949.85 rows=1 width=0) (actual time=7.996..7.996 rows=1 loops=1)
-> Bitmap Heap Scan on foo (cost=277.45..1924.94 rows=9959 width=0) (actual time=1.903..5.270 rows=10020 loops=1)
Recheck Cond: (foo_id = 1::numeric)
-> Bitmap Index Scan on foo_pk (cost=0.00..274.96 rows=9959 width=0) (actual time=1.864..1.864 rows=10020 loops=1)
Index Cond: (foo_id = 1::numeric)
Total runtime: 8.062 ms
Can you please explain to me with respect to this example what is happening here? This is a small table but for big tables the performance is not very good. Does recheck condition brings down the query performance?
Thanks
josh
