Re: 7.2 items - Mailing list pgsql-hackers

From mlw
Subject Re: 7.2 items
Date
Msg-id 3B1FC9CB.57C72AD6@mohawksoft.com
Whole thread Raw
In response to Re: 7.2 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Re: 7.2 items  (Oleg Bartunov <oleg@sai.msu.su>)
List pgsql-hackers
Bruce Momjian wrote:

> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> >
> > > Here is a small list of big TODO items.  I was wondering which ones
> > > people were thinking about for 7.2?
> >
> > A friend of mine wants to use PostgreSQL instead of Oracle for a large
> > application, but has run into a snag when speed comparisons looked
> > good until the Oracle folks added a couple of BITMAP indexes.  I can't
> > recall seeing any discussion about that here -- are there any plans?
>
> It is not on our list and I am not sure what they do.

Do you have access to any Oracle Documentation? There is a good explanation
of them.

However, I will try to explain.

If you have a table, locations. It has 1,000,000 records.

In oracle you do this:

create bitmap index bitmap_foo on locations (state) ;

For each unique value of 'state' oracle will create a bitmap with 1,000,000
bits in it. With a one representing a match and a zero representing no
match. Record '0' in the table is represented by bit '0' in the bitmap,
record '1' is represented by bit '1', record two by bit '2' and so on.

In a table where comparatively few different values are to be indexed in a
large table, a bitmap index can be quite small and not suffer the N * log(N)
disk I/O most tree based indexes suffer. If the bitmap is fairly sparse or
dense (or have periods of denseness and sparseness), it can be compressed
very efficiently as well.

When the statement:

select * from locations where state = 'MA';

Is executed, the bitmap is read into memory in very few disk operations.
(Perhaps even as few as one or two). It is a simple operation of rifling
through the bitmap for '1's that indicate the record has the property,
'state' = 'MA';



pgsql-hackers by date:

Previous
From: Roberto Fichera
Date:
Subject: Re: Re: Acucobol interface
Next
From: Peter Eisentraut
Date:
Subject: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards