Re: Further XLogInsert scaling tweaking

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: Further XLogInsert scaling tweaking
Дата
Msg-id 20130903033240.GE21874@momjian.us
обсуждение исходный текст
Ответ на Further XLogInsert scaling tweaking  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Further XLogInsert scaling tweaking  (Merlin Moncure <mmoncure@gmail.com>)
Re: Further XLogInsert scaling tweaking  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Noah Misch
Дата:
Сообщение: Re: dynamic shared memory
Следующее
От: "Karl O. Pinc"
Дата:
Сообщение: Re: backup.sgml-cmd-v003.patch