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@xxxxxxxxxxxxx> To: jim@xxxxxxxxxxxxxx, "Simon Dale" <sdale@xxxxxx>, pgsql-performance@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx> 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 -------
