From: Ron Mayer <rm_pg@cheapcomplexdevices.com>
Subject: Re: On-disk bitmap index patch
Date: Wed, 02 Aug 2006 11:38:09 -0700
Organization: Hub.Org Networking Services
Lines: 25
Message-ID: <44D0F111.60100@cheapcomplexdevices.com>
References: 
 <D425483C2C5C9F49B5B7A41F8944154757DAC7@postal.corporate.connx.com>
	<809.1154117933@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
To: Tom Lane <tgl@sss.pgh.pa.us>
User-Agent: Thunderbird 1.5.0.4 (X11/20060713)
In-Reply-To: <809.1154117933@sss.pgh.pa.us>
To: pgsql-hackers@postgresql.org

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?