Re: Re: 7.2 items

From: Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
To: mlw <markw(at)mohawksoft(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: 7.2 items
Date: 2001-06-07 19:38:20
Message-ID: Pine.GSO.4.33.0106072234120.6015-100000@ra.sai.msu.su
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I think it's possible to implement bitmap indexes with a little
effort using GiST. at least I know one implementation
http://www.it.iitb.ernet.in/~rvijay/dbms/proj/
if you have interests you could implement bitmap indexes yourself
unfortunately, we're very busy

Oleg
On Thu, 7 Jun 2001, mlw wrote:

> Bruce Momjian wrote:
>
> > > Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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';
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://www.postgresql.org/search.mpl
>

Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Ivar Helbekkmo 2001-06-07 19:42:32 Re: [HACKERS] Re: behavior of ' = NULL' vs. MySQL vs. Standards
Previous Message mlw 2001-06-07 19:38:17 Re: Acucobol interface