Re: Further XLogInsert scaling tweaking - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Further XLogInsert scaling tweaking
Date
Msg-id 20130903033240.GE21874@momjian.us
Whole thread Raw
In response to Further XLogInsert scaling tweaking  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Responses Re: Further XLogInsert scaling tweaking
Re: Further XLogInsert scaling tweaking
List pgsql-hackers
On Mon, Sep  2, 2013 at 10:14:03AM +0300, Heikki Linnakangas wrote:
> diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
> index 39c58d0..28e62ea 100644
> --- a/src/backend/access/transam/xlog.c
> +++ b/src/backend/access/transam/xlog.c
> @@ -428,8 +428,14 @@ typedef struct XLogCtlInsert
>      uint64        CurrBytePos;
>      uint64        PrevBytePos;
>  
> -    /* insertion slots, see above for details */
> -    XLogInsertSlotPadded *insertSlots;
> +    /*
> +     * Make sure the above heavily-contended spinlock and byte positions are
> +     * on their own cache line. In particular, the RedoRecPtr and full page
> +     * write variables below should be on a different cache line. They are
> +     * read on every WAL insertion, but updated rarely, and we don't want
> +     * those reads to steal the cache line containing Curr/PrevBytePos.
> +     */
> +    char        pad[128];

Do we adjust for cache line lengths anywhere else?  PGPROC?  Should it
be a global define?

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: dynamic shared memory
Next
From: "Karl O. Pinc"
Date:
Subject: Re: backup.sgml-cmd-v003.patch