Re: [COMMITTERS] pgsql: Make walsender more responsive. - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [COMMITTERS] pgsql: Make walsender more responsive.
Date
Msg-id 201207021953.25468.andres@2ndquadrant.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Make walsender more responsive.  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: [COMMITTERS] pgsql: Make walsender more responsive.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Monday, July 02, 2012 07:19:19 PM Fujii Masao wrote:
> On Mon, Jul 2, 2012 at 10:49 PM, Robert Haas <rhaas@postgresql.org> wrote:
> > Make walsender more responsive.
> > 
> > Per testing by Andres Freund, this improves replication performance
> > and reduces replication latency and latency jitter.  I was a bit
> > concerned about moving more work into XLogInsert, but testing seems
> > to show that it's not a problem in practice.
> > 
> > Along the way, improve comments for WaitLatchOrSocket.
> 
> This commit makes the synchronous replication slow down very much
> when wal_sync_method is set to open_sync or open_datasync. I think
> the attached patch needs to be applied.
Hm. Yes, definitely. No idea why I placed the call there, sorry.

Thats how synchronous_write=off behaved generally till the recent (simple) fix 
btw ;)

> +#define WalSndWakeupProcessRequests()        \
> +    do                                        \
> +    {                                        \
> +        if (wake_wal_senders)                \
> +        {                                    \
> +            wake_wal_senders = false;        \
> +            if (max_wal_senders > 0)        \
> +                WalSndWakeup();                \
> +        }                                    \
> +    } while (0)
> 
> I'm not sure it's really worth doing, but isn't it good idea to test
> max_wal_sender > 0 first to eliminate any CPU cycle in non replication
> case?
I think the difference is ignorable. wake_wal_senders probably has better 
cache locality but is set to true more often, but not that often...

Thanks,

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


pgsql-hackers by date:

Previous
From: Nils Goroll
Date:
Subject: away soon - spinlock->pthread_mutex : first results with Jeff's pgbench+plsql
Next
From: Robert Haas
Date:
Subject: Re: Event Triggers reduced, v1