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-27 10:33:02 |
Message-ID: | 201206271233.03267.andres@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tuesday, June 26, 2012 04:06:08 PM Andres Freund wrote:
> 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...
Ok, attached are two patches:
The first is the rebased version of the original patch with
WalSndWakeupProcess renamed to WalSndWakeupProcessRequests (seems clearer).
The second changes WalSndWakeupRequest and WalSndWakeupProcessRequests into
macros as you requested before. I am not sure if its a good idea or not.
Anything else?
Greetings,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Overhaul-walsender-wakeup-handling.patch | text/x-patch | 8.4 KB |
0002-Change-WalSndWakeupProcessRequests-and-WalSndWakeupR.patch | text/x-patch | 3.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Florian Pflug | 2012-06-27 11:21:49 | Re: [v9.3] Row-Level Security |
Previous Message | Nils Goroll | 2012-06-27 10:10:47 | Re: experimental: replace s_lock spinlock code with pthread_mutex on linux |