Re: Scaling shared buffer eviction

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Scaling shared buffer eviction
Дата
Msg-id CA+TgmoYOkGZjqNTOyH27H0DxJnfYORCbfyYFcwh9b9sbRCowYw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Scaling shared buffer eviction  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Scaling shared buffer eviction
Re: Scaling shared buffer eviction
Список pgsql-hackers
On Fri, May 16, 2014 at 10:51 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:


Thrds (64)Thrds (128)
HEAD4556217128
HEAD + 645790432810
V1 + 6410555781011
HEAD + 1285838332997
V1 + 128110705114544

I haven't actually reviewed the code, but this sort of thing seems like good evidence that we need your patch, or something like it.  The fact that the patch produces little performance improvement on it's own (though it does produce some) shouldn't be held against it - the fact that the contention shifts elsewhere when the first bottleneck is removed is not your patch's fault.

In terms of ameliorating contention on the buffer mapping locks, I think it would be better to replace the whole buffer mapping table with something different.  I started working on that almost 2 years ago, building a hash-table that can be read without requiring any locks and written with, well, less locking than what we have right now:

http://git.postgresql.org/gitweb/?p=users/rhaas/postgres.git;a=shortlog;h=refs/heads/chash

I never got quite as far as trying to hook that up to the buffer mapping machinery, but maybe that would be worth doing.

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

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: CREATE REPLICATION SLOT fails on a timeout
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Scaling shared buffer eviction