From: Josh Berkus <josh@agliodbs.com>
Reply-To: josh@agliodbs.com
Organization: Aglio Database Solutions
To: "Stacy White" <harsh@computer.org>
Subject: Re: Partitioned table performance
Date: Wed, 15 Dec 2004 10:25:02 -0800
User-Agent: KMail/1.7.1
Cc: pgsql-performance@postgresql.org
References: <000a01c4da74$84e072e0$0200a8c0@grownups>
	<200412102152.40442.josh@agliodbs.com>
	<001f01c4e26c$99719680$0200a8c0@grownups>
In-Reply-To: <001f01c4e26c$99719680$0200a8c0@grownups>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200412151025.02262.josh@agliodbs.com>

Stacy,

> Thanks again for the reply. =A0So it sounds like the answer to my original
> question is that it's expected that the pseudo-partitioning would introdu=
ce
> a fairly significant amount of overhead. =A0Correct?

Correct.   For that matter, Oracle table partitioning introduces significan=
t=20
overhead, from what I've seen.  I don't think there's a way not to.

Generally, I counsel people that they only want to consider=20
pseudo-partitioning if they have one axis on the table which is used in 90%=
=20
or more of the queries against that table.

What would improve the situation significantly, and the utility of=20
pseudo-partitioning, is the ability to have a single index span multiple=20
partitions.   This would allow you to have a segmented index for the=20
partitioned axis, yet still use an unsegmented index for the other columns.=
 =20
However, there's a *lot* of work to do to make that happen.

=2D-=20
=2D-Josh

Josh Berkus
Aglio Database Solutions
San Francisco