| From: | "Luke Lonergan" <llonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Mark Wong" <markw(at)osdl(dot)org>, "Jie Zhang" <jzhang(at)greenplum(dot)com>, "Ayush Parashar" <aparashar(at)greenplum(dot)com> |
| Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, swm(at)linuxworld(dot)com(dot)au, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bitmap index status |
| Date: | 2006-09-25 20:43:32 |
| Message-ID: | C13D8D84.2947%llonergan@greenplum.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Mark,
On 9/25/06 11:32 AM, "Mark Wong" <markw(at)osdl(dot)org> wrote:
> Yeah, basically gather as many stats as I can to accurately profile the
> overall system performance. I thought it would be appropriate to use a
> TPC-H based workload as one measuring stick to use for bitmap indexes.
Note that the TPC-H queries don't follow the typical good use case for
bitmap indexes. You'd like to see queries that use multiple AND and OR
clauses, otherwise there may be no benefit.
Also, DBT-3/TPC-H on Postgres right now does not benefit from indices
overall. The planner has limitations WRT selectivity estimates and other
limitations that cause it to choose index access poorly for the query
workload. We have two new features coming (for 8.3) that fix this, but for
now we find that indexes are a net loss, in some queries a huge loss.
If you look at the whitepaper that Ayush Parashar published, he uses the
TPC-H data with some targeted queries that showcase the best use-cases for
bitmap index.
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zdenek Kotala | 2006-09-25 20:56:38 | Re: pg_dump data in BKI format |
| Previous Message | Andrew Dunstan | 2006-09-25 19:55:31 | Re: pg_dump data in BKI format |