Re: Minor optimisation of XLogInsert()

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.

> One possible explanation is that I don't believe that what you've done
> here is actually sufficient to guarantee alignment on cache-line
> boundary - ShmemAlloc() only guarantees MAXALIGN alignment unless the
> allocation is at least BLCKSZ bytes.  So depending on exactly how much
> shared memory gets allocated before XLogCtlData gets allocated, it's
> possible that the change could actually end up splitting all of the
> things you're trying to put on their own cache line across two cache
> lines.  Might be worth fixing that and running this through its paces
> again.
>
> (I wonder if we shouldn't just align every shared memory allocation to
> 64 or 128 bytes.  It wouldn't waste much memory and it would make us
> much more resistant to performance changes caused by minor
> modifications to the shared memory layout.)

I'll look at that, thanks for the suggestion.

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