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 21:01:47 |
Message-ID: | 25658.1115326907@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Sergey E. Koposov" <math(at)sai(dot)msu(dot)ru> writes:
> And I coadded the "flat profiles" of first two (index scan) queries and
> compared it with the flat profile of bitmap scan:
Thanks, I had been thinking of doing that same calculation but hadn't
got round to it yet. It looks like the bitmap case is actually a little
ahead on buffer access (as you'd expect) and btree work (which is
surprising because it ought to be dead even; are these numbers very
repeatable?). Where we are losing is mostly on the actual manipulation
of the bitmaps (particularly hash_seq_search which is done in
tbm_begin_iterate; and it looks like memory allocation for the bitmap
hashtables is nontrivial too). I had already had a TODO item to look
into speeding up hash_seq_search ... will see what I can find.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2005-05-05 21:03:11 | Re: [pgsql-hackers-win32] snprintf causes regression tests |
Previous Message | Marc G. Fournier | 2005-05-05 20:59:37 | Re: 'kitchen sink' downloads (Was: Re: [pgsql-advocacy] |