Chris Isaacson cisaacson
Mon Jun 13 13:50:56 PDT 2005
Hello all,
 
I've been testing the duration of slony 1.0.5's initial copy of a
database with 59 tables.  58 of the tables have less than 10K rows while
the other table has ~24mil rows.  In both cases the slave host database
was an empty schema with no data.
 
As a baseline, I did an ordinary pg_dump from the masterhost, piping the
result over a 1GB LAN to psql on the slavehost.  
 
<slavehost>$ pg_dump --host=<masterhost> --username=<xxx> <dbname> |
psql <dbname> <username>
 
This dump/restore took 2h22m14s.
 
After deleting all the data from slave host, I installed slony 1.0.5 on
both hosts and subscribed to all the tables.  The slon log on the
slavehost reports the initial subscribe set(s) copy for the same
database taking 7h7m.  Any idea why slony's initial snapshot of the
database takes 3x as long as an ordinary dump/restore?  Is there any way
to use dump/restore and bypass slony's initial snapshot operation?
 
Any guidance would be greatly appreciated.
 
Chris Isaacson
Tradebot Systems, Inc.
cisaacson at tradebotsystems.com <mailto:cisaacson at tradebotsystems.com> 
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20050613/1f7834bc/attachment.html


More information about the Slony1-general mailing list