Re: [PATCH 01/16] Overhaul walsender wakeup handling

On Fri, Jun 22, 2012 at 12:35 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> Can you elaborate on that a bit?  What scenarios did you play around
>> with, and what does "win" mean in this context?
> I had two machines connected locally and setup HS and my prototype between
> them (not at once obviously).
> The patch reduced all the average latency between both nodes (measured by
> 'ticker' rows arriving in a table on the standby), the jitter in latency and
> the amount of load I had to put on the master before the standby couldn't keep
> up anymore.
>
> I played with different loads:
> * multple concurrent ~50MB COPY's
> * multple concurrent ~50MB COPY's, pgbench
> * pgbench
>
> All three had a ticker running concurrently with synchronous_commit=off
> (because it shouldn't cause any difference in the replication pattern itself).
>
> The difference in averagelag and cutoff were smallest with just pgbench running
> alone and biggest with COPY running alone. Highjitter was most visible with
> just pgbench running alone but thats likely just because the average lag was
> smaller.

OK, that sounds pretty promising.  I'd like to run a few performance
tests on this just to convince myself that it doesn't lead to a
significant regression in other scenarios.  Assuming that doesn't turn
up anything major, I'll go ahead and commit this.

Can you provide a rebased version?  It seems that one of the hunks in
xlog.c no longer applies.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company