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

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: [PATCH 01/16] Overhaul walsender wakeup handling
Date: 2012-06-26 14:06:08
Message-ID: 201206261606.08758.andres@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tuesday, June 26, 2012 04:01:26 PM Robert Haas wrote:
> On Fri, Jun 22, 2012 at 12:35 PM, Andres Freund <andres(at)2ndquadrant(dot)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.
Independent testing would be great, its definitely possible that I oversaw
something although I obviously don't think so ;).

> Can you provide a rebased version? It seems that one of the hunks in
> xlog.c no longer applies.
Will do so. Not sure if I can finish it today though, I am in the midst of
redoing the ilist and xlogreader patches. I guess tomorrow will suffice
otherwise...

Thanks!

Andres

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2012-06-26 15:06:35 Re: Reporting WAL file containing checkpoint's REDO record in pg_controldata's result
Previous Message Kohei KaiGai 2012-06-26 14:04:41 Re: WIP Patch: Selective binary conversion of CSV file foreign tables