Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit695f239

Browse files
committed
Add to TODO.detail.
1 parenta5875d7 commit695f239

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)

[8]ページ先頭

©2009-2025 Movatter.jp