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
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? |