| From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Bruce Momjian" <bruce(at)momjian(dot)us>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Dann Corbit" <DCorbit(at)connx(dot)com>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, "Jie Zhang" <jzhang(at)greenplum(dot)com>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Josh Berkus" <josh(at)agliodbs(dot)com>, "Gavin Sherry" <swm(at)linuxworld(dot)com(dot)au>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: On-disk bitmap index patch |
| Date: | 2006-07-28 21:43:23 |
| Message-ID: | C0EFD30B.2B307%llonergan@greenplum.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Bruce,
On 7/28/06 1:25 PM, "Bruce Momjian" <bruce(at)momjian(dot)us> wrote:
> What we don't want to happen is for us to release bitmapped indexes, and
> find out later that btree is better in all cases. Then we have to tell
> people not to use bitmapped indexes until we fix it in the next major
> releasse. FYI, that is basically where we are right now with hash
> indexes.
On this thread people have presented results that show clear and irrefutable
evidence that there are use cases where bitmap indexes outperform Btree for
many datatypes on realistic problems, including the TPC-H benchmark.
In many cases the bitmap indexes outperform BTREE by a factor of 50 and are
a tiny fraction of the size and also take dramatically less time to build.
Of the cases presented, we need to have someone specifically address them
and point out why they aren't proof of bitmap index performance. So far
this has not been done, rather there are some unsupported opinions about
other cases that might be problematic.
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2006-07-28 22:05:03 | Re: The vacuum-ignore-vacuum patch |
| Previous Message | Marko Kreen | 2006-07-28 21:13:52 | Re: [HACKERS] [PATCH] Provide 8-byte transaction IDs to user level |