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
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 |