Re: One process per session lack of sharing
От | james |
---|---|
Тема | Re: One process per session lack of sharing |
Дата | |
Msg-id | 4c31772e-4feb-2f81-9bc0-a4f324ecacde@mansionfamily.plus.com обсуждение исходный текст |
Ответ на | Re: One process per session lack of sharing (Craig Ringer <craig@2ndquadrant.com>) |
Ответы |
Re: One process per session lack of sharing
Re: One process per session lack of sharing |
Список | pgsql-hackers |
On 15/07/2016 09:28, Craig Ringer wrote: > I don't think anyone's considering moving from multi-processing to > multi-threading in PostgreSQL. I really, really like the protection > that the shared-nothing-by-default process model gives us, among other > things. > As I understand it, the main issue is that it is hard to integrate extensions that use heavyweight runtimes and are focussed on isolation within a virtual machine. Its not just Perhaps it would be possible for the postmaster (or a delegate process) to host such a runtime, and find a way for a user process that wants to use such a runtime to communicate with it, whether by copying function parameters over RPC or by sharing some of its address space explicitly to the runtime to operate on directly. Such a host delegate process could be explicitly built with multithread support and not 'infect' the rest of the code with its requirements. Using granular RPC is nice for isolation but I am concerned that the latencies might be high.
В списке pgsql-hackers по дате отправления: