X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org
Received: from localhost (av.hub.org [200.46.204.144])
	by svr1.postgresql.org (Postfix) with ESMTP id AB051D6E69
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue, 13 Sep 2005 12:31:07 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024)
	with ESMTP id 95293-04
	for <pgsql-performance-postgresql.org@localhost.postgresql.org>;
	Tue, 13 Sep 2005 15:31:04 +0000 (GMT)
Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197])
	by svr1.postgresql.org (Postfix) with ESMTP id 2CF4BD8D0A
	for <pgsql-performance@postgresql.org>;
	Tue, 13 Sep 2005 12:31:00 -0300 (ADT)
Received: by wproxy.gmail.com with SMTP id 36so2444532wra
	for <pgsql-performance@postgresql.org>;
	Tue, 13 Sep 2005 08:30:59 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references;
	b=dmyxwjiGAjKmXIwsNF7K7beoSpFOH4yi91/S3bmLNvZyDnc40nl27v2t3uJRxdFj2ZKWt0QXol3jmwv+ccsvJFVZa2GHQ5WCpGGIe0dZctpokeuKmHHvz+kZU4v+4VpVjOMMz/BkTqch3sDPEGOcpbW/uiQCMODPSLNiogxWp4g=
Received: by 10.54.43.21 with SMTP id q21mr560383wrq;
	Tue, 13 Sep 2005 08:30:59 -0700 (PDT)
Received: by 10.54.158.11 with HTTP; Tue, 13 Sep 2005 08:30:59 -0700 (PDT)
Message-ID: <84621a6050913083079ef0559@mail.gmail.com>
Date: Tue, 13 Sep 2005 10:30:59 -0500
From: Brandon Black <blblack@gmail.com>
Reply-To: blblack@gmail.com
To: petrilli@gmail.com, pgsql-performance@postgresql.org
Subject: Re: Performance considerations for very heavy INSERT traffic
In-Reply-To: <59d991c40509122039773cac17@mail.gmail.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_14396_27311434.1126625459081"
References: <84621a6050912140464c380c3@mail.gmail.com>
	<59d991c40509122039773cac17@mail.gmail.com>
X-Virus-Scanned: by amavisd-new at hub.org
X-Spam-Status: No, hits=0.349 required=5 tests=[AWL=-0.180, HTML_20_30=0.504,
	HTML_MESSAGE=0.001, RCVD_BY_IP=0.024]
X-Spam-Level: 
X-Archive-Number: 200509/168
X-Sequence-Number: 14476

------=_Part_14396_27311434.1126625459081
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On 9/12/05, Christopher Petrilli <petrilli@gmail.com> wrote:
>=20
>=20
> 3) Use 8.1 and strongly look at Bizgres. The data partitioning is=20
> critical.


I started looking closer at my options for partitioning (inheritance, union=
=20
all), and at Bizgres today. Bizgres partitioning appears to be basically th=
e=20
same kind of inheritance partitioning one can do in mainline PostgreSQL. Am=
=20
I correct in thinking that the main difference is that they've coded suppor=
t=20
for "enable_constraint_exclusion=3Dtrue" so that the query planner can be m=
ore=20
effective at taking advantage of the partitioning when you've specified=20
CHECK constraints on the child tables? I may go for 8.1 instead in that=20
case, as the main win I'm looking for is that with inheritance I'll be doin=
g=20
inserts into smaller tables instead of ones that grow to unmanageable sizes=
=20
(and that I can drop old child tables instead of delete/vacuum).

------=_Part_14396_27311434.1126625459081
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

<br><br><div><span class=3D"gmail_quote">On 9/12/05, <b class=3D"gmail_send=
ername">Christopher Petrilli</b> &lt;<a href=3D"mailto:petrilli@gmail.com">=
petrilli@gmail.com</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" s=
tyle=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8e=
x; padding-left: 1ex;">
<br>3) Use 8.1 and strongly look at Bizgres. The data partitioning is criti=
cal.</blockquote><div><br>

I started looking closer at my options for partitioning (inheritance,
union all), and at Bizgres today.&nbsp; Bizgres partitioning appears to be
basically the same kind of inheritance partitioning one can do in
mainline PostgreSQL.&nbsp; Am I correct in thinking that the main differenc=
e
is that they've coded support for &quot;enable_constraint_exclusion=3Dtrue&=
quot; so
that the query planner can be more effective at taking advantage of the
partitioning when you've specified CHECK constraints on the child
tables?&nbsp; I may go for 8.1 instead in that case, as the main win I'm
looking for is that with inheritance I'll be doing inserts into smaller
tables instead of ones that grow to unmanageable sizes (and that I can
drop old child tables instead of delete/vacuum).<br>
<br>
</div></div>

------=_Part_14396_27311434.1126625459081--