I wrote:
> ... 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
On Thu, 5 May 2005, Tom Lane wrote:
> "Sergey E. Koposov" <[EMAIL PROTECTED]> 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
"Sergey E. Koposov" <[EMAIL PROTECTED]> 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
On Wed, 4 May 2005, Tom Lane wrote:
>
> 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
"Sergey E. Koposov" <[EMAIL PROTECTED]> 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
On Fri, 29 Apr 2005, Tom Lane wrote:
> >-> Index Scan using ipix_idx on q3c (cost=0.01..9686.37 rows=35
> > width=48) (actual time=0.006..0.006 rows=0 loops=300)
> > Index Cond: ((q3c.ipix >= ("outer".ipix - 1000)) AND (q3c.ipix <=
> > ("outer".ipix - 993)))
>
> >
"Sergey E. Koposov" <[EMAIL PROTECTED]> writes:
> I'd like to report about suprising (for me) results of performance testing of
> bitmap indexes in nested loop join plans.
I'm surprised too. There's something weird in the indexscans
themselves:
>-> Index Scan using ipix_idx on q3c (cost=
Hello All,
I'd like to report about suprising (for me) results of performance testing of
bitmap indexes in nested loop join plans.
I have the table q3c
test=# \d q3c
Table "public.q3c"
Column | Type | Modifiers
++---
ipix | bigint |
errbox | box|
ra
