Re: One process per session lack of sharing - Mailing list pgsql-hackers

From Greg Stark
Subject Re: One process per session lack of sharing
Date
Msg-id CAM-w4HO-ugmAmrQXRE_mYCswi11xWGrZTjuvqS8W_X2q4FdYTQ@mail.gmail.com
Whole thread Raw
In response to Re: One process per session lack of sharing  (AMatveev@bitec.ru)
Responses 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>)
List 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 by date:

Previous
From: Jan Wieck
Date:
Subject: Re: DO with a large amount of statements get stuck with high memory consumption
Next
From: Merlin Moncure
Date:
Subject: Re: DO with a large amount of statements get stuck with high memory consumption