Hernan Saltiel wrote:
> 
> 
> Yes, it does!
> We're working to insert massive records, almos 1 millon in a single batch.
> This is why I'm concerned about performance issues.
> Thanks a lot, and best regards,

Slony's performance when replicating a large insert batch isn't great.

Depending on the total size of the table (and other factors) you might 
want to drop the table from replication and resubscribe the table after 
you've added the rows to the master.   Slony replicates the initial data 
with a 'copy' which is faster than the the million individual SQL 
statements that will be otherwise performed.





> HeCSa.
>  
> 
> 
> 
>      >
>      > On Mon, Jun 14, 2010 at 6:01 PM, Steve Singer
>      > <ssinger at ca.afilias.info <mailto:ssinger at ca.afilias.info>> wrote:
>      >         Hernan Saltiel wrote:
>      >
>      >                 How can I meassure how much is too much use of my
>      >                 hardware when Slony is in place?
>      >                 I can meassure the CPU, memory, disk IO, and network
>      >                 use, but how much is needed in order to let Slony
>     work
>      >                 well?
>      >                 Is there any way to calculate this on a transaction
>      >                 number and size basis?
>      >                 Thanks!
>      >
>      >
>      >         The other thing you should look into is if your having
>      >         performance issues on your database from
>     improper/insufficient
>      >         vacuuming.  Back in the 8.0 days vacuuming issues where
>     pretty
>      >         common (I think 8.0 was before auto-vacuum or at least before
>      >         auto-vacuum got good).
>      >
>      >         Are your application tables bloated?
>      >         Are your slony tables bloated?
>      >         Are your vacuum processes taking a long time?
>      >         If your've had vacuum issues in the past have you
>     exceeded the
>      >         size you've allocated to the free-space map.
>      >
>      >         Vacuuming the entire database through a single "VACUUM"
>      >         command launched from cron is somtimes not the best approach,
>      >         sometimes you need to issue individual vacuum commands on a
>      >         per table basis where some tables get hit frequently (maybe a
>      >         few times an hour) while others might only get vacuumed
>     once a
>      >         week.   It all depends on the acccess patterns to the tables
>      >         and with older versions of postgresql the DBA is often
>     left to
>      >         figure this out on their own.
>      >
>      >         Also slony should be issuing vacuum commands against the
>     slony
>      >         tables so you probably don't want 'other' vacuum commands
>     that
>      >         regularly get run to duplicate the work.
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >                     > Can someone point me where should i look into
>      >                 and how to improve
>      >                    replication
>      >                     > performance.
>      >
>      >                    More / faster drives and controllers.
>      >
>      >                     > As of now there is no chance for upgradation of
>      >                 version.
>      >
>      >                    That would be the first thing I'd recommend.
>      Since
>      >                 you can't do it,
>      >                    you're gonna have to have faster hardware,
>      >                 specifically the IO
>      >                    subsystem.
>      >                    _______________________________________________
>      >                    Slony1-general mailing list
>      >
>      >                    Slony1-general at lists.slony.info
>     <mailto:Slony1-general at lists.slony.info>
>      >                 <mailto:Slony1-general at lists.slony.info
>     <mailto:Slony1-general at lists.slony.info>>
>      >
>      >
>      >                
>      http://lists.slony.info/mailman/listinfo/slony1-general
>      >
>      >
>      >
>      >
>      >                 --
>      >                 HeCSa
>      >
>      >
>      >
>      >                
>     ------------------------------------------------------------------------
>      >
>      >
>      >                 _______________________________________________
>      >                 Slony1-general mailing list
>      >                 Slony1-general at lists.slony.info
>     <mailto:Slony1-general at lists.slony.info>
>      >                
>     http://lists.slony.info/mailman/listinfo/slony1-general
>      >
>      >
>      >
>      >         --
>      >         Steve Singer
>      >         Afilias Canada
>      >         Data Services Developer
>      >         416-673-1142
>      >
>      >
>      >
>      > --
>      > HeCSa
>      > _______________________________________________
>      > Slony1-general mailing list
>      > Slony1-general at lists.slony.info
>     <mailto:Slony1-general at lists.slony.info>
>      > http://lists.slony.info/mailman/listinfo/slony1-general
>     --
>     Brad Nicholson  416-673-4106
>     Database Administrator, Afilias Canada Corp.
> 
> 
> 
> 
> 
> -- 
> HeCSa


-- 
Steve Singer
Afilias Canada
Data Services Developer
416-673-1142