Re: any way to get rid of Bitmap Heap Scan recheck?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Sergei Shelukhin <realgeek(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: any way to get rid of Bitmap Heap Scan recheck?
Date: 2007-05-19 18:10:06
Message-ID: 14748.1179598206@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Sergei Shelukhin <realgeek(at)gmail(dot)com> writes:
> The query is very slow (3 minutes on test data), here's what takes all
> the time, from explain results:

>> Bitmap Heap Scan on tag (cost=897.06..345730.89 rows=115159 width=8)
> Recheck Cond: ((name)::text = 'blah'::text)
> -> Bitmap Index Scan on tag_idxn
> (cost=0.00..897.06 rows=115159 width=0)
> Index Cond: ((name)::text =
> 'blah'::text)

It's usually a good idea to do EXPLAIN ANALYZE on troublesome queries,
rather than trusting that the planner's estimates reflect reality.

> The query without recheck will run like up to 100 times faster
> according to overall query plan.

Sorry, but you have no concept what you're talking about. The
difference between indexscan and heap scan estimates here reflects
fetching rows from the heap, not recheck costs. Even if it were
a good idea to get rid of the recheck (which it is not), it wouldn't
reduce the costs materially.

If the table is fairly static then it might help to CLUSTER on that
index, so that the rows needed are brought together physically.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2007-05-19 18:12:35 Re: Efficient recursion
Previous Message Heikki Linnakangas 2007-05-19 18:05:17 Re: any way to get rid of Bitmap Heap Scan recheck?