On 10/8/2004 10:11 AM, Vivek Khera wrote:
> On Oct 6, 2004, at 11:51 AM, Vivek Khera wrote:
> 
>> Well, I'm now convinced that something is wrong.  There's just no way 
>> in heck it should take 6 days to replicate my large table across two 
>> machines, even if they are cheap-o IDE disks... :-)
>>
> 
> Well, there was a way in heck (Where's Phil with his spoon?):
> 
> DEBUG2 remoteWorkerThread_2: 3448517395 bytes copied for table 
> public.msg_recipients
>   [[ several SYNC events here... ]]
> DEBUG2 remoteWorkerThread_2: 617457.234 seconds to copy table 
> public.msg_recipients
> 
> based on the current table that's copying (about 40% the size of the 
> big one) it finished around 4am today.  Solid 7 days + 4 hours or so.  
> So I figure around tuesday I'll be all replicated in my test! :-)

Do you have any idea where and what the bottleneck of that copy process 
is? I can't imagine that it is either CPU or disk IO on the provider 
(master). I can however imagine that with various indexes, it can be 
memory or disk on the subscriber. Building lots of indexes on the fly 
works better with large shared buffer configs, as they don't even need 
to be copied in and out of kernel disk buffers.


Jan


> 
> 
> Vivek Khera, Ph.D.
> +1-301-869-4449 x806
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Slony1-general mailing list
> Slony1-general at gborg.postgresql.org
> http://gborg.postgresql.org/mailman/listinfo/slony1-general


-- 
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#================================================== JanWieck at Yahoo.com #