Re: [PATCH] Use MAP_HUGETLB where supported (v3)

Поиск
Список
Период
Сортировка
От Sergey Konoplev
Тема Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Дата
Msg-id CAL_0b1uJFkwcbrnU=yP5PAC5n8HYXjfkZMVrXWwFL938DPVWZg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Oct 30, 2013 at 8:11 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Sergey Konoplev <gray.ru@gmail.com> writes:
>> On Tue, Oct 29, 2013 at 9:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> Say what?  There's never been any hugepages support in Postgres.
>
>> There were an ability to back shared memory with hugepages when using
>> <=9.2. I use it on ~30 servers for several years and it brings 8-17%
>> of performance depending on the memory size. Here you will find
>> several paragraphs of the description about how to do it
>> https://github.com/grayhemp/pgcookbook/blob/master/database_server_configuration.md.
>
> What this describes is how to modify Postgres to request huge pages.
> That's hardly built-in support.

I wasn't talking about a built-in support. It was about an ability (a
way) to back sh_buf with hugepages.

> In any case, as David already explained, we don't do feature additions
> in minor releases.  We'd be especially unlikely to make an exception
> for this, since it has uncertain portability and benefits.  Anything
> that carries portability risks has got to go through a beta testing
> cycle before we'll unleash it on the masses.

Yes, I got the idea. Thanks both of you for clarification.

-- 
Kind regards,
Sergey Konoplev
PostgreSQL Consultant and DBA

http://www.linkedin.com/in/grayhemp
+1 (415) 867-9984, +7 (901) 903-0499, +7 (988) 888-1979
gray.ru@gmail.com



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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: Fast insertion indexes: why no developments