Re: Recheck condition
| От | Josh Harrison |
|---|---|
| Тема | Re: Recheck condition |
| Дата | |
| Msg-id | 8d89ea1d0711281120s462f66dfxec0d0af74ad91f02@mail.gmail.com обсуждение исходный текст |
| Ответ на | Recheck condition ("Josh Harrison" <joshques@gmail.com>) |
| Ответы |
Re: Recheck condition
|
| Список | pgsql-general |
>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?? >don't actually match the index condition.
>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
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
В списке pgsql-general по дате отправления: