To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Stacy White" <harsh@computer.org>,
	"Alvaro Herrera" <alvherre@dcc.uchile.cl>,
	"PFC" <lists@boutiquenumerique.com>,
	"Josh Berkus" <josh@agliodbs.com>, pgsql-performance@postgresql.org
Subject: Re: What needs to be done for real Partitioning?
References: <200503191202.38089.josh@agliodbs.com>
	<op.snwojdwith1vuj@localhost> <20050319225624.GA8467@dcc.uchile.cl>
	<3404.1111277153@sss.pgh.pa.us>
	<002a01c52d87$543d1010$0200a8c0@grownups>
	<14172.1111359709@sss.pgh.pa.us>
In-Reply-To: <14172.1111359709@sss.pgh.pa.us>
From: Greg Stark <gsstark@mit.edu>
Organization: The Emacs Conspiracy; member since 1992
Date: 20 Mar 2005 22:47:43 -0500
Message-ID: <871xa9fyn4.fsf@stark.xeocode.com>
Lines: 26
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Tom Lane <tgl@sss.pgh.pa.us> writes:

> Global indexes would seriously reduce the performance of both vacuum and
> cluster for a single partition, and if you want seq scans you don't need
> an index for that at all.  So the above doesn't strike me as a strong
> argument for global indexes ...

I think he means some sort of plan for queries like

  select * from invoices where customer_id = 1

where customer 1 only did business with us for two years. One could imagine
some kind of very coarse grained bitmap index that just knows which partitions
customer_id=1 appears in, and then does a sequential scan of those partitions.

But I think you can do nearly as well without using global indexes of any
type. Assuming you had local indexes on customer_id for each partition and
separate histograms for each partition the planner could conclude that it
needs sequential scans for some partitions and a quick index lookup expecting
0 records for other partitions.

Not as good as pruning partitions entirely but if you're doing a sequential
scan the performance hit of a few index lookups isn't a problem.

-- 
greg