Re: On-disk bitmap index patch

From: "Luke Lonergan" <llonergan(at)greenplum(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>, "Jie Zhang" <jzhang(at)greenplum(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: On-disk bitmap index patch
Date: 2006-07-27 03:55:38
Message-ID: C0ED874A.2AFBB%llonergan@greenplum.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

On 7/26/06 7:26 AM, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> I wonder
> whether they oughtn't use 16-bit instead of 8-bit HRL_WORDs

We tried variations from 8-bit to 32-bit and came to the conclusion that
8-bit was a better match for the more general case. For the moment I forget
exactly why (maybe Jie or Ayush will recall). It's a #define I believe, so
you can play with it to find out.

There's a lot more to be done with this - I think we've got some big gains
ahead.

BTW - lots of excitement here at OSCON about bitmap index, and there's a
fellow who is using the current Bizgres version, but wants *higher*
cardinality support, so I discussed Jie's thoughts about implementing
binning on values, basically combining bit vectors into value bins as the
cardinality increases.

I am still puzzled why our index creation time increases so dramatically as
we approach cardinality 10,000. I know that we found that index page
traversal for append began to take a lot of time as we started to increase
the number of bitvector pages - we had talked about aggregating the append
operations into groups before they were implemented to sequentialize the
access.

- Luke

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-07-27 05:03:38 Re: GUC with units, details
Previous Message Mark Kirkwood 2006-07-27 02:00:18 Re: On-disk bitmap index patch