From: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
---|---|
To: | Jie Zhang <jzhang(at)greenplum(dot)com> |
Cc: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Bitmap index thoughts |
Date: | 2006-12-27 10:58:55 |
Message-ID: | 459251EF.7030700@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Jie Zhang wrote:
> The "bitmap data segment" sounds good in terms of space. The problem is that
> one bitmap is likely to occupy more pages than before, which may hurt the
> query performance.
We could have segments of say 1/5 of page. When a bitmap grows larger
than that, the bitmap would be moved to a page of its own. That way we
wouldn't get unnecessary fragmentation with large bitmaps, but small
bitmaps would be stored efficiently.
> I have been thinking along the lines of increasing the
> number of last bitmap words stored in each LOV item, but not to occupy one
> page. This may prevent some cases Gavin indicated here, but not all.
That sounds like more special cases and complexity. I like the segment
idea more.
But actually I'm not convinced we need to worry about efficient storage
of small bitmaps at all. The typical use case for bitmap indexes is
large tables with small number of distinct values, and the problem
doesn't really arise in that scenario. Let's keep it simple for now, we
can enhance it in later releases.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Gavin Sherry | 2006-12-27 11:10:49 | Re: Bitmap index thoughts |
Previous Message | Heikki Linnakangas | 2006-12-27 10:49:12 | Re: Bitmap index thoughts |