Re: Further XLogInsert scaling tweaking

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: Further XLogInsert scaling tweaking
Дата
Msg-id CAHyXU0wzYqCOj7+2KdQo_hQOGRYzMF76FeV72kpQbMdBpd4U1A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Further XLogInsert scaling tweaking  (Bruce Momjian <bruce@momjian.us>)
Ответы Re: Further XLogInsert scaling tweaking  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
On Mon, Sep 2, 2013 at 10:32 PM, Bruce Momjian <bruce@momjian.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Backup throttling
Следующее
От: Andres Freund
Дата:
Сообщение: Re: INSERT...ON DUPLICATE KEY IGNORE