Re: [SQL] Case Preservation disregarding case - Mailing list pgsql-hackers

From Erik Aronesty
Subject Re: [SQL] Case Preservation disregarding case
Date
Msg-id ccd588d90911050745o4d2e3d83m869e86ae287a1263@mail.gmail.com
Whole thread Raw
In response to Re: [SQL] Case Preservation disregarding case  ("Chuck McDevitt" <cmcdevitt@greenplum.com>)
List pgsql-hackers
An update on pg_comparator as an efficient way to do master-slave replication.<br /><br />I have been using it for 2
yearson a "products" table that has grown from 12,000 rows to 24,000 rows.  There are 3 slaves and 1 master.  It is
sync'edevery 10 minutes.<br /><br />It has never failed or caused problems.<br /><br />On 23039 rows, with under 100
rowschanged, over a 3mbit internet connection, and on a the sync takes 3.3 seconds, 0.94 seconds of which is CPU time
(1.86GHZ 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
anoption.<br /><br />I do not synchronize all the columns ... just the 15 most important ones<br /><br />Average number
ofbytes per row is 284<br /><br /> Primary Key is an autoincrement integer id<br /><br />Databases are all on the
internetat 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
systemburps 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 "replication" (which some say this isn't, and I say
that'sa matter of how you define it) work so well.<br /><br /><br /> 

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: drop tablespace error: invalid argument
Next
From: Erik Aronesty
Date:
Subject: using pg_comparator as replication