Re: Quick Performance Poll

From: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
To: jim(at)contactbda(dot)com, "Simon Dale" <sdale(at)rm(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Quick Performance Poll
Date: 2006-04-20 15:03:10
Message-ID: C06CF0BE.21E2F%llonergan@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Jim,

On 4/20/06 7:40 AM, "Jim Buttafuoco" <jim(at)contactbda(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Jim Buttafuoco 2006-04-20 15:06:14 Re: Quick Performance Poll
Previous Message Ruben Rubio Rey 2006-04-20 14:54:21 Re: Perfrmance Problems (7.4.6)