I have been following your work with great interest. I believe I spoke to someone from Greenplum at linux world in
Boston a couple of weeks ago.
---------- Original Message -----------
From: "Luke Lonergan" <llonergan@greenplum.com>
To: jim@contactbda.com, "Simon Dale" <sdale@rm.com>, pgsql-performance@postgresql.org
Sent: Thu, 20 Apr 2006 08:03:10 -0700
Subject: Re: [PERFORM] Quick Performance Poll
> Jim,
>
> On 4/20/06 7:40 AM, "Jim Buttafuoco" <jim@contactbda.com> wrote:
>
> > First of all this is NOT a single table and yes I am using partitioning and
> > the constaint exclusion stuff. the largest
> > set of tables is over 2T. I have not had to rebuild the biggest database yet,
> > but for a smaller one ~1T the restore
> > takes about 12 hours including many indexes on both large and small tables
>
> You would probably benefit greatly from the new on-disk bitmap index feature
> in Bizgres Open Source. It's 8.1 plus the sort speed improvement and
> on-disk bitmap index.
>
> Index creation and sizes for the binary version are in the table below (from
> a performance report on bizgres network. The version in CVS tip on
> pgfoundry is much faster on index creation as well.
>
> The current drawback to bitmap index is that it isn't very maintainable
> under insert/update, although it is safe for those operations. For now, you
> have to drop index, do inserts/updates, rebuild index.
>
> We'll have a version that is maintained for insert/update next.
>
> - Luke
>
> # Indexed Columns Create Time (seconds) Space Used (MBs)
> BITMAP BTREE BITMAP BTREE
> 1 L_SHIPMODE 454.8 2217.1 58 1804
> 2 L_QUANTITY 547.2 937.8 117 1804
> 3 L_LINENUMBER 374.5 412.4 59 1285
> 4 L_SHIPMODE, L_QUANTITY 948.7 2933.4 176 2845
> 5 O_ORDERSTATUS 83.5 241.3 5 321
> 6 O_ORDERPRIORITY 108.5 679.1 11 580
> 7 C_MKTSEGMENT 10.9 51.3 1 45
> 8 C_NATIONKEY 8.3 9.3 2 32
------- End of Original Message -------
