DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:content-type;
	b=FPhoqmKT0zaq1XXPk/sRfLwTCW3YnpoH6eBP1F8V9MqZutD+38PzfjgvfGPHfl99gV
	oa4wwOPnFfvZfIWnrZ06R8LAKh4o3mAfXCnQFvgkwh5yau7AehPj4N/x1pQqWyAE0SoG
	vU8EykSLAGhtICHRhifzO+zU/6nfXCBiRyFbg=
MIME-Version: 1.0
In-Reply-To: <EB48EBF3B239E948AC1E3F3780CF8F88012F88DD@MI8NYCMAIL02.Mi8.com>
References: <200610271623.37525.beauh@bluefrogmobile.com>
	<1162003132.687.8.camel@pampa>
	<200610301928.51255.beauh@bluefrogmobile.com>
	<23177.1162265010@sss.pgh.pa.us>
	<EB48EBF3B239E948AC1E3F3780CF8F88012F88DD@MI8NYCMAIL02.Mi8.com>
Date: Thu, 5 Nov 2009 10:45:24 -0500
Message-ID: <ccd588d90911050745o4d2e3d83m869e86ae287a1263@mail.gmail.com>
Subject: Re: [SQL] Case Preservation disregarding case
From: Erik Aronesty <erik@q32.com>
To: pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary=0016e6d58b2fb07c750477a19da4

--0016e6d58b2fb07c750477a19da4
Content-Type: text/plain; charset=ISO-8859-1

An update on pg_comparator as an efficient way to do master-slave
replication.

I have been using it for 2 years on a "products" table that has grown from
12,000 rows to 24,000 rows.  There are 3 slaves and 1 master.  It is sync'ed
every 10 minutes.

It has never failed or caused problems.

On 23039 rows, with under 100 rows changed, over a 3mbit internet
connection, and on a the sync takes 3.3 seconds, 0.94 seconds of which is
CPU time (1.86 GHZ intel dual core).  Most of the time is waiting for the
network.   And that could be sped up considerably with compression (maybe
5-10 times for my data)... I don't think the postgres communications
protocol considers compression an option.

I do not synchronize all the columns ... just the 15 most important ones

Average number of bytes per row is 284

Primary Key is an autoincrement integer id

Databases are all on the internet at cheap colocation centers with suppsedly
10mbit high speed connections that realistically get about 3 mbit.

I ship a backup and restore of the table every week... in case there are
tons of changes and the system burps when there are too many.... I also
schedule scripts that might make lots of changes to happen before the
dump/restore.

In my 15 years as a DBA, I have never had "replication" (which some say this
isn't, and I say that's a matter of how you define it) work so well.

--0016e6d58b2fb07c750477a19da4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

An update on pg_comparator as an efficient way to do master-slave replicati=
on.<br><br>I have been using it for 2 years on a &quot;products&quot; table=
 that has grown from 12,000 rows to 24,000 rows.=A0 There are 3 slaves and =
1 master.=A0 It is sync&#39;ed every 10 minutes.<br>
<br>It has never failed or caused problems.<br><br>On 23039 rows, with unde=
r 100 rows changed, over a 3mbit internet connection, and on a the sync tak=
es 3.3 seconds, 0.94 seconds of which is CPU time (1.86 GHZ intel dual core=
).=A0 Most of the time is waiting for the network.=A0=A0 And that could be =
sped up considerably with compression (maybe 5-10 times for my data)... I d=
on&#39;t think the postgres communications protocol considers compression a=
n option.<br>
<br>I do not synchronize all the columns ... just the 15 most important one=
s<br><br>Average number of bytes per row is 284<br>
<br>
Primary Key is an autoincrement integer id<br>
<br>Databases are all on the internet at cheap colocation centers with
suppsedly 10mbit high speed connections that realistically get about 3
mbit.<br>
<br>
I ship a backup and restore of the table every week... in case
there are tons of changes and the system burps when there are too
many.... I also schedule scripts that might make lots of changes to happen
before the dump/restore.<br><br>In my 15 years as a DBA, I have never had &=
quot;replication&quot; (which some say this isn&#39;t, and I say that&#39;s=
 a matter of how you define it) work so well.<br><br><br>

--0016e6d58b2fb07c750477a19da4--