Re: Let's make PostgreSQL multi-threaded

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Let's make PostgreSQL multi-threaded
Дата
Msg-id 20230607213721.al3etgcgtija3ytz@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Let's make PostgreSQL multi-threaded  ("Jonathan S. Katz" <jkatz@postgresql.org>)
Ответы Re: Let's make PostgreSQL multi-threaded  (Hannu Krosing <hannuk@google.com>)
Re: Let's make PostgreSQL multi-threaded  (Jose Luis Tallon <jltallon@adv-solutions.net>)
Re: Let's make PostgreSQL multi-threaded  (Robert Haas <robertmhaas@gmail.com>)
Re: Let's make PostgreSQL multi-threaded  (David Geier <geidav.pg@gmail.com>)
Список pgsql-hackers
Hi,

On 2023-06-05 13:40:13 -0400, Jonathan S. Katz wrote:
> 2. While I wouldn't want to necessarily discourage a moonshot effort, I
> would ask if developer time could be better spent on tackling some of the
> other problems around vertical scalability? Per some PGCon discussions,
> there's still room for improvement in how PostgreSQL can best utilize
> resources available very large "commodity" machines (a 448-core / 24TB RAM
> instance comes to mind).

I think we're starting to hit quite a few limits related to the process model,
particularly on bigger machines. The overhead of cross-process context
switches is inherently higher than switching between threads in the same
process - and my suspicion is that that overhead will continue to
increase. Once you have a significant number of connections we end up spending
a *lot* of time in TLB misses, and that's inherent to the process model,
because you can't share the TLB across processes.


The amount of duplicated code we have to deal with due to to the process model
is quite substantial. We have local memory, statically allocated shared memory
and dynamically allocated shared memory variants for some things. And that's
just going to continue.


> I'm purposely giving a nonanswer on whether it's a worthwhile goal, but
> rather I'd be curious where it could stack up against some other efforts to
> continue to help PostgreSQL improve performance and handle very large
> workloads.

There's plenty of things we can do before, but in the end I think tackling the
issues you mention and moving to threads are quite tightly linked.


Greetings,

Andres Freund



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: v16 fails to build w/ Visual Studio 2015
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Let's make PostgreSQL multi-threaded