| From: | Mark Kirkwood <markir(at)coretech(dot)co(dot)nz> |
|---|---|
| To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
| Cc: | 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-19 22:52:24 |
| Message-ID: | 41759AA8.3000502@coretech.co.nz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Simon Riggs wrote:
>
>>I believe that the benefit of on-disk bitmap indexes is supposed to be
>>reduced storage size (compared to btree).
>>
>>
>>
>The main problem is the need for the table to be read-only. Until we have
>partitioning, we wouldn't be able to easily guarantee parts of a table as
>being (effectively) read-only.
>
>
>
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.
cheers
Mark
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-10-19 23:05:05 | Re: plans for bitmap indexes? |
| Previous Message | Tom Lane | 2004-10-19 22:43:39 | Re: tsearch2 windows make failure |