Re: Minor optimisation of XLogInsert()

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Minor optimisation of XLogInsert()
Date: 2011-11-17 01:39:05
Message-ID: CA+TgmoYkuaqevw0hVEssuB=B6gBjnCE1BRzr8DnFaWRhhD1nCw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 16, 2011 at 5:15 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Wed, Nov 16, 2011 at 8:42 PM, Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-11-17 01:52:35 Re: Configuration include directory
Previous Message Tom Lane 2011-11-17 00:29:50 Re: Adding Node support in outfuncs.c and readfuncs.c