Re: Minor optimisation of XLogInsert() - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Minor optimisation of XLogInsert()
Date
Msg-id CA+TgmoYkuaqevw0hVEssuB=B6gBjnCE1BRzr8DnFaWRhhD1nCw@mail.gmail.com
Whole thread Raw
In response to Re: Minor optimisation of XLogInsert()  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Wed, Nov 16, 2011 at 5:15 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Wed, Nov 16, 2011 at 8:42 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Taking the median of those five results, the patch seems to have sped
>> things up by 0.3%.  At 80 clients:
>
> Thanks for doing that. Even if we fix it as you suggest it seems to
> indicate that the WALInsertLock contention is real rather than false
> contention. Which lends some clues as to how to proceed.

Sure thing.

My general impression from playing around with this over the last 6-7
months is that cache line sharing is just not that big a problem for
us.  In a case like WALInsertLock, I'm fairly certain that we're
actually putting processes to sleep on a regular basis - and the
overhead of a system call to go to sleep and another one to wake up
and the associated context switches dwarfs the cost of passing the
cache line around.  It's far more important to get rid of the sleeping
(which, sadly, is far harder than padding out the data structures).

There are some cases where the cache line really does seem to matter -
e.g. Pavan's PGPROC_MINIMAL patch delivers excellent results on
Itanium - but those seem to be fairly rate FWICT.

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Adding Node support in outfuncs.c and readfuncs.c
Next
From: Tom Lane
Date:
Subject: Re: Configuration include directory