From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Further XLogInsert scaling tweaking |
Date: | 2013-09-03 13:22:40 |
Message-ID: | CAHyXU0wzYqCOj7+2KdQo_hQOGRYzMF76FeV72kpQbMdBpd4U1A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 2, 2013 at 10:32 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> 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?
+1 -- that is, I think it should be.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-09-03 13:26:54 | Re: INSERT...ON DUPLICATE KEY IGNORE |
Previous Message | Andres Freund | 2013-09-03 12:51:55 | Re: Backup throttling |