From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: On-disk bitmap index patch |
Date: | 2006-08-02 18:38:09 |
Message-ID: | 44D0F111.60100@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Both of these pages say up front that they are considering read-only
> data.
Can I assume read-mostly partitions could use the read-I/O
efficient indexes on update-intensive partitions of the same
table could use b-tree indexes?
All of my larger (90GB+) tables can have partitions that are either
almost read-only (spatial data updated one state/country at
a time, about quarterly) or are totally read-only (previous
months and years historical data).
> So one of the questions that has to be answered (and the
> submitters have been entirely mum about) is exactly how bad is the
> update performance? If it's really awful that's going to constrain
> the use cases quite a lot, whereas merely "a bit slower than btree"
> wouldn't be such a problem.
Once we have easy-to-use partitioning, would it be the case that
many larger tables will have near-read-only partitions that could
use I/O friendlier indexes (GIN? Hash? Bitmap?)? Any examples
of a large data set that can't be partitioned into hot areas and
read-mostly areas?
From | Date | Subject | |
---|---|---|---|
Next Message | Rocco Altier | 2006-08-02 18:45:03 | Buildfarm failure - asp |
Previous Message | Joe Conway | 2006-08-02 18:10:11 | Re: Values list-of-targetlists patch for comments (was Re: |