Re: Postgres with pthread

Поиск
Список
Период
Сортировка
От Alexander Korotkov
Тема Re: Postgres with pthread
Дата
Msg-id CAPpHfdsvg-cgMi95a-CAyirbEk8hfoaaGGAi1OU1cSYd7v68BQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Postgres with pthread  (konstantin knizhnik <k.knizhnik@postgrespro.ru>)
Список pgsql-hackers
On Sat, Dec 9, 2017 at 1:09 AM, konstantin knizhnik <k.knizhnik@postgrespro.ru> wrote:
I am not going to show stack traces of all 1000 threads.
But you may notice that proc array lock really seems be be a bottleneck.

Yes, proc array lock easily becomes a bottleneck on multicore machine with large number of connections.  Related to this, another patch helping to large number of connections is CSN.  When our snapshot model was invented, xip was just array of few elements, and that cause no problem.  Now, we're considering threads to help us handling thousands of connections.  Snapshot with thousands of xips looks ridiculous.  Collecting such a large snapshot could be more expensive than single index lookup.

These two patches threads and CSN are both complicated and require hard work during multiple release cycles to get committed.  But I really hope that their cumulative effect can dramatically improve situation on high number of connections.  There are already some promising benchmarks in CSN thread.  I wonder if we already can do some cumulative benchmarks of threads + CSN?

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

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

Предыдущее
От: legrand legrand
Дата:
Сообщение: Re: Partition pruning for Star Schema
Следующее
От: Alexander Korotkov
Дата:
Сообщение: Re: CUBE seems a bit confused about ORDER BY