Christopher Browne a écrit :
> Jeff Trout <threshar at torgo.978.org> writes:
>   
>> I've run some of the queries that show up in explain, which seem to
>> be coming out sane.  I'm just wondering if there is something I
>> should be looking into about speeding it up, or if I should
>> investigate something like log shipping.  (I've got a master and 3
>> slaves.  2 of the slaves can lag a bit, 1 of the slaves should be
>> about <=1s )
>>     
>
> I don't think log shipping would help anything here, from two perspectives:
>
> 1.  It still requires having a regular subscriber around; all it
> therefore buys you is the ability for *EXTRA* copies to be made more
> cheaply.
>
> 2.  There shouldn't be anything about log shipping itself that would
> provide any extra efficiencies.
>
>   
>> Should I look into perhaps seeing if those slow notify... queries
>> were trying to run at the same time as that log switch?
>>     
>
> If things are too slow, about the only thing that has been observed (I
> can't call it verified) that is argued to make a difference is to
> increase the number of tuples processed at a time.
>
> You *might* get a benefit by increasing the parameter
> "SLON_DATA_FETCH_SIZE", presently set to 10, in slon.h, to some
> moderately larger number.  
>   

I played a time with that, and also with removing the 'seqscan off' from 
slony source. 
The seqscan off come probably from long time ago ? Is it still necessary ?

> I would expect it to be a Bad Thing to increase it to >> 1000, as this
> would seem likely to make memory usage increase, with little
> concommittant potential for improvement. 
>
> Assuming that fiddling with this *does* provide potential for
> improvement for heavy-update sites, I would expect increasing it to
> something like 50 to be the "conservative" approach...
>
> However, that assumes that this could be a fruitful improvement, which
> has yet to be verified...
>
> For the most part, if you are finding things "too slow," then I would
> be more inclined to point firstly at the ideas of:
>
>  - Tune Thy Database
>   and
>  - If Thine Database Be Tuned, then Upgrade Thine Hardware.
>
> Performance of replication is mostly an emergent property falling from
> how heavily loaded your systems are, and whether they actually have
> the "bandwidth" free to cope with replication.
>
> There isn't any obvious "Go Faster" flag - if there were, we'd have either:
> a) Set it as a default, or
> b) Noticed that it was a significant config parameter worth fiddling with.
>