Re: One process per session lack of sharing

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: One process per session lack of sharing
Дата
Msg-id CAM-w4HO-ugmAmrQXRE_mYCswi11xWGrZTjuvqS8W_X2q4FdYTQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: One process per session lack of sharing  (AMatveev@bitec.ru)
Ответы Re: One process per session lack of sharing  (AMatveev@bitec.ru)
Re: One process per session lack of sharing  (AMatveev@bitec.ru)
Re: One process per session lack of sharing  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Mon, Jul 18, 2016 at 2:41 PM,  <AMatveev@bitec.ru> wrote:
> And  I  will  be  really happy when there are processors with infinite
> performance and memory with infinite size.
>:)))

Well for what it's worth there's no theoretical difference between
multi-process and multi-threaded. They're just two different APIs to
create shared memory and other kernel data structures and they both
allow all the sharing you want.  In the API Postgres uses everything
starts out non-shared and we explicitly set up the parts we want
shared. In the other nearly everything starts shared though it's
possible to unshare parts. Once they're set up the CPU and MMU don't
really care what kernel API was used to set them up.

In other words, there's no theoretical reason you couldn't have adapt
a JVM to create a large shared memory segment using mmap or SysV
shared memory and live entirely within that including the Java stacks
and object allocations and so on. The net result of what's running on
the CPU can actually end up being exactly equivalent (though I suspect
a natural implementation would end up being slightly different) and
there are pros and cons to each API.

-- 
greg



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

Предыдущее
От: Jan Wieck
Дата:
Сообщение: Re: DO with a large amount of statements get stuck with high memory consumption
Следующее
От: Merlin Moncure
Дата:
Сообщение: Re: DO with a large amount of statements get stuck with high memory consumption