Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 695f239

Browse files
bmomjianbmomjian
committed
Add to TODO.detail.
1 parent a5875d7 commit 695f239

File tree

1 file changed

+265
-2
lines changed

1 file changed

+265
-2
lines changed

‎doc/TODO.detail/performance

Lines changed: 265 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -345,7 +345,7 @@ From owner-pgsql-hackers@hub.org Tue Oct 19 10:31:10 1999
345345
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
346346
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id KAA29087
347347
for <maillist@candle.pha.pa.us>; Tue, 19 Oct 1999 10:31:08 -0400 (EDT)
348-
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id KAA27535 for <maillist@candle.pha.pa.us>; Tue, 19 Oct 1999 10:19:47 -0400 (EDT)
348+
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.6 $) with ESMTP id KAA27535 for <maillist@candle.pha.pa.us>; Tue, 19 Oct 1999 10:19:47 -0400 (EDT)
349349
Received: from localhost (majordom@localhost)
350350
by hub.org (8.9.3/8.9.3) with SMTP id KAA30328;
351351
Tue, 19 Oct 1999 10:12:10 -0400 (EDT)
@@ -454,7 +454,7 @@ From owner-pgsql-hackers@hub.org Tue Oct 19 21:25:30 1999
454454
Received: from renoir.op.net (root@renoir.op.net [209.152.193.4])
455455
by candle.pha.pa.us (8.9.0/8.9.0) with ESMTP id VAA28130
456456
for <maillist@candle.pha.pa.us>; Tue, 19 Oct 1999 21:25:26 -0400 (EDT)
457-
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.5 $) with ESMTP id VAA10512 for <maillist@candle.pha.pa.us>; Tue, 19 Oct 1999 21:15:28 -0400 (EDT)
457+
Received: from hub.org (hub.org [216.126.84.1]) by renoir.op.net (o1/$Revision: 1.6 $) with ESMTP id VAA10512 for <maillist@candle.pha.pa.us>; Tue, 19 Oct 1999 21:15:28 -0400 (EDT)
458458
Received: from localhost (majordom@localhost)
459459
by hub.org (8.9.3/8.9.3) with SMTP id VAA50745;
460460
Tue, 19 Oct 1999 21:07:23 -0400 (EDT)
@@ -739,3 +739,266 @@ dirty one in LRU.
739739

740740
Vadim
741741

742+
From markw@mohawksoft.com Thu Jun 7 14:40:02 2001
743+
Return-path: <markw@mohawksoft.com>
744+
Received: from gromit.dotclick.com (ipn9-f8366.net-resource.net [216.204.83.66])
745+
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f57Ie1c14004
746+
for <pgman@candle.pha.pa.us>; Thu, 7 Jun 2001 14:40:02 -0400 (EDT)
747+
Received: from mohawksoft.com (IDENT:markw@localhost.localdomain [127.0.0.1])
748+
by gromit.dotclick.com (8.9.3/8.9.3) with ESMTP id OAA04973;
749+
Thu, 7 Jun 2001 14:37:00 -0400
750+
Sender: markw@gromit.dotclick.com
751+
Message-ID: <3B1FC9CB.57C72AD6@mohawksoft.com>
752+
Date: Thu, 07 Jun 2001 14:36:59 -0400
753+
From: mlw <markw@mohawksoft.com>
754+
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.4.2 i686)
755+
X-Accept-Language: en
756+
MIME-Version: 1.0
757+
To: Bruce Momjian <pgman@candle.pha.pa.us>,
758+
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
759+
Subject: Re: 7.2 items
760+
References: <200106071503.f57F32n03924@candle.pha.pa.us>
761+
Content-Type: text/plain; charset=us-ascii
762+
Content-Transfer-Encoding: 7bit
763+
Status: OR
764+
765+
Bruce Momjian wrote:
766+
767+
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
768+
> >
769+
> > > Here is a small list of big TODO items. I was wondering which ones
770+
> > > people were thinking about for 7.2?
771+
> >
772+
> > A friend of mine wants to use PostgreSQL instead of Oracle for a large
773+
> > application, but has run into a snag when speed comparisons looked
774+
> > good until the Oracle folks added a couple of BITMAP indexes. I can't
775+
> > recall seeing any discussion about that here -- are there any plans?
776+
>
777+
> It is not on our list and I am not sure what they do.
778+
779+
Do you have access to any Oracle Documentation? There is a good explanation
780+
of them.
781+
782+
However, I will try to explain.
783+
784+
If you have a table, locations. It has 1,000,000 records.
785+
786+
In oracle you do this:
787+
788+
create bitmap index bitmap_foo on locations (state) ;
789+
790+
For each unique value of 'state' oracle will create a bitmap with 1,000,000
791+
bits in it. With a one representing a match and a zero representing no
792+
match. Record '0' in the table is represented by bit '0' in the bitmap,
793+
record '1' is represented by bit '1', record two by bit '2' and so on.
794+
795+
In a table where comparatively few different values are to be indexed in a
796+
large table, a bitmap index can be quite small and not suffer the N * log(N)
797+
disk I/O most tree based indexes suffer. If the bitmap is fairly sparse or
798+
dense (or have periods of denseness and sparseness), it can be compressed
799+
very efficiently as well.
800+
801+
When the statement:
802+
803+
select * from locations where state = 'MA';
804+
805+
Is executed, the bitmap is read into memory in very few disk operations.
806+
(Perhaps even as few as one or two). It is a simple operation of rifling
807+
through the bitmap for '1's that indicate the record has the property,
808+
'state' = 'MA';
809+
810+
811+
From mascarm@mascari.com Thu Jun 7 15:36:25 2001
812+
Return-path: <mascarm@mascari.com>
813+
Received: from corvette.mascari.com (dhcp065-024-161-045.columbus.rr.com [65.24.161.45])
814+
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f57JaOc21943
815+
for <pgman@candle.pha.pa.us>; Thu, 7 Jun 2001 15:36:24 -0400 (EDT)
816+
Received: from ferrari (ferrari.mascari.com [192.168.2.1])
817+
by corvette.mascari.com (8.9.3/8.9.3) with SMTP id PAA25607;
818+
Thu, 7 Jun 2001 15:29:31 -0400
819+
Received: by localhost with Microsoft MAPI; Thu, 7 Jun 2001 15:34:18 -0400
820+
Message-ID: <01C0EF67.5105D2E0.mascarm@mascari.com>
821+
From: Mike Mascari <mascarm@mascari.com>
822+
Reply-To: "mascarm@mascari.com" <mascarm@mascari.com>
823+
To: "'mlw'" <markw@mohawksoft.com>, Bruce Momjian <pgman@candle.pha.pa.us>,
824+
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
825+
Subject: RE: [HACKERS] Re: 7.2 items
826+
Date: Thu, 7 Jun 2001 15:34:17 -0400
827+
Organization: Mascari Development Inc.
828+
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
829+
MIME-Version: 1.0
830+
Content-Type: text/plain; charset="us-ascii"
831+
Content-Transfer-Encoding: 7bit
832+
Status: OR
833+
834+
And in addition,
835+
836+
If you submitted the query:
837+
838+
SELECT * FROM addresses WHERE state = 'OH'
839+
AND areacode = '614'
840+
841+
Then, with bitmap indexes, the bitmaps are just logically ANDed
842+
together, and the final bitmap determines the matching rows.
843+
844+
Mike Mascari
845+
mascarm@mascari.com
846+
847+
-----Original Message-----
848+
From: mlw [SMTP:markw@mohawksoft.com]
849+
850+
Bruce Momjian wrote:
851+
852+
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
853+
> >
854+
> > > Here is a small list of big TODO items. I was wondering which
855+
ones
856+
> > > people were thinking about for 7.2?
857+
> >
858+
> > A friend of mine wants to use PostgreSQL instead of Oracle for a
859+
large
860+
> > application, but has run into a snag when speed comparisons
861+
looked
862+
> > good until the Oracle folks added a couple of BITMAP indexes. I
863+
can't
864+
> > recall seeing any discussion about that here -- are there any
865+
plans?
866+
>
867+
> It is not on our list and I am not sure what they do.
868+
869+
Do you have access to any Oracle Documentation? There is a good
870+
explanation
871+
of them.
872+
873+
However, I will try to explain.
874+
875+
If you have a table, locations. It has 1,000,000 records.
876+
877+
In oracle you do this:
878+
879+
create bitmap index bitmap_foo on locations (state) ;
880+
881+
For each unique value of 'state' oracle will create a bitmap with
882+
1,000,000
883+
bits in it. With a one representing a match and a zero representing
884+
no
885+
match. Record '0' in the table is represented by bit '0' in the
886+
bitmap,
887+
record '1' is represented by bit '1', record two by bit '2' and so
888+
on.
889+
890+
In a table where comparatively few different values are to be indexed
891+
in a
892+
large table, a bitmap index can be quite small and not suffer the N *
893+
log(N)
894+
disk I/O most tree based indexes suffer. If the bitmap is fairly
895+
sparse or
896+
dense (or have periods of denseness and sparseness), it can be
897+
compressed
898+
very efficiently as well.
899+
900+
When the statement:
901+
902+
select * from locations where state = 'MA';
903+
904+
Is executed, the bitmap is read into memory in very few disk
905+
operations.
906+
(Perhaps even as few as one or two). It is a simple operation of
907+
rifling
908+
through the bitmap for '1's that indicate the record has the
909+
property,
910+
'state' = 'MA';
911+
912+
913+
914+
From oleg@sai.msu.su Thu Jun 7 15:39:15 2001
915+
Return-path: <oleg@sai.msu.su>
916+
Received: from ra.sai.msu.su (ra.sai.msu.su [158.250.29.2])
917+
by candle.pha.pa.us (8.10.1/8.10.1) with ESMTP id f57Jd7c22010
918+
for <pgman@candle.pha.pa.us>; Thu, 7 Jun 2001 15:39:08 -0400 (EDT)
919+
Received: from ra (ra [158.250.29.2])
920+
by ra.sai.msu.su (8.9.3/8.9.3) with ESMTP id WAA07783;
921+
Thu, 7 Jun 2001 22:38:20 +0300 (GMT)
922+
Date: Thu, 7 Jun 2001 22:38:20 +0300 (GMT)
923+
From: Oleg Bartunov <oleg@sai.msu.su>
924+
X-X-Sender: <megera@ra.sai.msu.su>
925+
To: mlw <markw@mohawksoft.com>
926+
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
927+
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
928+
Subject: Re: [HACKERS] Re: 7.2 items
929+
In-Reply-To: <3B1FC9CB.57C72AD6@mohawksoft.com>
930+
Message-ID: <Pine.GSO.4.33.0106072234120.6015-100000@ra.sai.msu.su>
931+
MIME-Version: 1.0
932+
Content-Type: TEXT/PLAIN; charset=US-ASCII
933+
Status: OR
934+
935+
I think it's possible to implement bitmap indexes with a little
936+
effort using GiST. at least I know one implementation
937+
http://www.it.iitb.ernet.in/~rvijay/dbms/proj/
938+
if you have interests you could implement bitmap indexes yourself
939+
unfortunately, we're very busy
940+
941+
Oleg
942+
On Thu, 7 Jun 2001, mlw wrote:
943+
944+
> Bruce Momjian wrote:
945+
>
946+
> > > Bruce Momjian <pgman@candle.pha.pa.us> writes:
947+
> > >
948+
> > > > Here is a small list of big TODO items. I was wondering which ones
949+
> > > > people were thinking about for 7.2?
950+
> > >
951+
> > > A friend of mine wants to use PostgreSQL instead of Oracle for a large
952+
> > > application, but has run into a snag when speed comparisons looked
953+
> > > good until the Oracle folks added a couple of BITMAP indexes. I can't
954+
> > > recall seeing any discussion about that here -- are there any plans?
955+
> >
956+
> > It is not on our list and I am not sure what they do.
957+
>
958+
> Do you have access to any Oracle Documentation? There is a good explanation
959+
> of them.
960+
>
961+
> However, I will try to explain.
962+
>
963+
> If you have a table, locations. It has 1,000,000 records.
964+
>
965+
> In oracle you do this:
966+
>
967+
> create bitmap index bitmap_foo on locations (state) ;
968+
>
969+
> For each unique value of 'state' oracle will create a bitmap with 1,000,000
970+
> bits in it. With a one representing a match and a zero representing no
971+
> match. Record '0' in the table is represented by bit '0' in the bitmap,
972+
> record '1' is represented by bit '1', record two by bit '2' and so on.
973+
>
974+
> In a table where comparatively few different values are to be indexed in a
975+
> large table, a bitmap index can be quite small and not suffer the N * log(N)
976+
> disk I/O most tree based indexes suffer. If the bitmap is fairly sparse or
977+
> dense (or have periods of denseness and sparseness), it can be compressed
978+
> very efficiently as well.
979+
>
980+
> When the statement:
981+
>
982+
> select * from locations where state = 'MA';
983+
>
984+
> Is executed, the bitmap is read into memory in very few disk operations.
985+
> (Perhaps even as few as one or two). It is a simple operation of rifling
986+
> through the bitmap for '1's that indicate the record has the property,
987+
> 'state' = 'MA';
988+
>
989+
>
990+
> ---------------------------(end of broadcast)---------------------------
991+
> TIP 6: Have you searched our list archives?
992+
>
993+
> http://www.postgresql.org/search.mpl
994+
>
995+
996+
Regards,
997+
Oleg
998+
_____________________________________________________________
999+
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
1000+
Sternberg Astronomical Institute, Moscow University (Russia)
1001+
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
1002+
phone: +007(095)939-16-83, +007(095)939-23-83
1003+
1004+

0 commit comments

Comments
 (0)