Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance
Дата
Msg-id AANLkTikKaNhHHimcO1XPdwvTCa-HYH4UJAGwgHjTKaQM@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] MIT benchmarks pgsql multicore (up to 48)performance  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-performance
On Thu, Oct 7, 2010 at 1:21 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas <robertmhaas@gmail.com> wrote:
>
>> perhaps it would be possible by, say, increasing the number of
>> lock partitions by 8x.  It would be nice to segregate these issues
>> though, because using pread/pwrite is probably a lot less work
>> than rewriting our lock manager.
>
> You mean easier than changing this 4 to a 7?:
>
> #define LOG2_NUM_LOCK_PARTITIONS  4
>
> Or am I missing something?

Right.  They did something more complicated (and, I think, better)
than that, but that change by itself might be enough to ameliorate the
lock contention enough to see the lsek() issue.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

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

Предыдущее
От: Aaron Turner
Дата:
Сообщение: Re: large dataset with write vs read clients
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Odd behaviour with redundant CREATE statement