agora inbox for [email protected]
help / color / mirror / Atom feedFrom: Ron Mayer <[email protected]>
To: Tom Lane <[email protected]>
Subject: Re: On-disk bitmap index patch
Date: Wed, 02 Aug 2006 11:38:09 -0700
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <D425483C2C5C9F49B5B7A41F8944154757DAC7@postal.corporate.connx.com>
<[email protected]>
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?
view thread (53+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: On-disk bitmap index patch
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox