Re: [PATCH 01/16] Overhaul walsender wakeup handling
От | Andres Freund |
---|---|
Тема | Re: [PATCH 01/16] Overhaul walsender wakeup handling |
Дата | |
Msg-id | 201206261606.08758.andres@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: [PATCH 01/16] Overhaul walsender wakeup handling (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [PATCH 01/16] Overhaul walsender wakeup handling
|
Список | 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@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. 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
В списке pgsql-hackers по дате отправления: