From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, Chris Browne <cbbrowne(at)acm(dot)org> |
Subject: | Re: plans for bitmap indexes? |
Date: | 2004-10-26 12:19:08 |
Message-ID: | 1098793147.2551.14.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On K, 2004-10-20 at 01:52, Mark Kirkwood wrote:
> I don't believe that read only is required. The update/insert
> performance impact of bimap indexes is however very high (in Oracle's
> implementation anyway) - to the point where many sites drop them before
> adding in new data, and recreated 'em afterwards!
>
> In the advent that there is a benefit for the small on-disk footprint,
> the insert/update throughput implications will need to be taken into
> account.
I repeat here my earlier proposal of making the bitmap indexes
page-level and clustering data automatically on AND of all defined
bitmap indexes.
This would mostly solve this problem too, as there will be only one
insert per page per index (when the first tuple is inserted) and one
delete (when the page gets empty).
This has a downside of suboptimal space usage but this "should not" (tm)
be an issue for large tables, where most combinations of bits will get
enough hits to fill several pages.
Such clustering would also help (probably a lot) all queries actually
using these indexes.
-------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2004-10-26 14:47:40 | Re: Possible make_oidjoins_check Security Issue |
Previous Message | Bernd Helmle | 2004-10-26 12:19:01 | Re: Automatic view update rules |