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
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 |