| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Sergey E(dot) Koposov" <math(at)sai(dot)msu(dot)ru> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: performance of bitmap scans in nested loop joins |
| Date: | 2005-05-05 03:48:24 |
| Message-ID: | 18748.1115264904@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Sergey E. Koposov" <math(at)sai(dot)msu(dot)ru> writes:
> On Fri, 29 Apr 2005, Tom Lane wrote:
>> The latter is (or should be) doing slightly *less* work, so why is it
>> taking almost twice as much time? Can you get gprof profiles of the
>> two cases?
> I've got them. I attached two files with a little bit truncated output of
> gprof.
I figured out part of the problem: I had made nodeBitmapIndexscan
re-open the index on each call, thinking that that would save amrescan
calls. But an amrescan is a whole lot cheaper than index open/close,
so that was a bad tradeoff.
This seems to account for about half of the slowdown you exhibited.
I'm not sure where the other half went ... gprof isn't turning up
any obvious candidates.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Oleg Bartunov | 2005-05-05 04:05:01 | 'infinity' in GiST index |
| Previous Message | Tatsuo Ishii | 2005-05-05 03:33:37 | Re: bitmap scan and explain analyze |