Re: 7.2 items

Поиск
Список
Период
Сортировка
От mlw
Тема Re: 7.2 items
Дата
Msg-id 3B1FC9CB.57C72AD6@mohawksoft.com
обсуждение исходный текст
Ответ на Re: 7.2 items  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Re: 7.2 items  (Oleg Bartunov <oleg@sai.msu.su>)
Список 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 по дате отправления:

Предыдущее
От: Roberto Fichera
Дата:
Сообщение: Re: Re: Acucobol interface
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: AW: Re: [SQL] behavior of ' = NULL' vs. MySQL vs. Stand ards