On 01/05/2014 03:05 PM, Tory M Blue wrote:
>
>
> I believe so, based on how fast I get the copy statement, meaning that
> it copied the table over and the 5+hours has to be the index creation.
>
> I did some tests today with my query DB's, which used to take 2-4 hours
> to replicate (from a ground up (drop/add)). Took 25 minutes today. So I
> think giving slony resources to create the indexes is vital, I had it
> set to 100MB, set it to 2000MB today and reduced the vacuum processes
> from 5 to 3 (just to be sure) and this really seems to help. I won't be
> able to test this on my insert db's for a bit (have to wait for a
> scheduled maintenance).
>
> Droppping indexes on a production node before replicating, that seems
> like a really bad idea, it would cause my production system to drop to
> it's knees or fall over while trying to replicate to the secondary. The
> indexes are required and I really can't remove them. Now maybe you are
> meaning that I move the index creation to the end of the addnode, vs
> doing it immediately upon a table creation?
>

I am not saying you should drop the indexes from your master, just this 
replica.  Slony disables those indexes during the COPY anyway.  If you 
have any applications querying this table on the replica being rebuilt 
then I'd expect those queries to be blocked behind the copy anyway. 
Moving index-creation for this table to the end of the addnode would 
have the same effect, you could then create multiple indexes on the 
table in parallel (I'm assuming that the table has multiple indexes).

But it sounds like tuning the memory settings are enough for you.


> thanks again I appreciate the assistance this group has given!
>
> Tory