Re: On-disk bitmap index patch

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Jie Zhang <jzhang(at)greenplum(dot)com>, pgsql-hackers(at)postgresql(dot)org, Luke Lonergan <LLonergan(at)greenplum(dot)com>
Subject: Re: On-disk bitmap index patch
Date: 2006-07-25 18:38:36
Message-ID: 44C6652C.1020203@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

> (I'm also wondering whether this
> doesn't overlap the use-case for GIN.)

It does not. GIN is strictly for multi-value fields. I can think of
applications where either GIN or Bitmaps would be an option, but for the
majority, they wouldn't.

One particular compelling situation for on-disk bitmaps is for terabyte
tables where a btree index would not fit into memory. Index
performance for an index which is 10x or more the size of RAM really
sucks ... I can come up with some test results if you doubt that.

Also note that "low cardinality" is relative. For a 1 billion row
table, a column with 10,000 values is "low-cardinality", having around
100,000 rows per value ... but that's still 0.01% of the table per
value, making index use still applicable.

--Josh

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gevik Babakhani 2006-07-25 18:43:51 Re: root/administartor user check option.
Previous Message Hannu Krosing 2006-07-25 18:36:13 Re: On-disk bitmap index patch