From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | AMatveev(at)bitec(dot)ru |
Cc: | Dave Cramer <pg(at)fastcrypt(dot)com>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: One process per session lack of sharing |
Date: | 2016-07-18 14:03:46 |
Message-ID: | CAM-w4HO-ugmAmrQXRE_mYCswi11xWGrZTjuvqS8W_X2q4FdYTQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jul 18, 2016 at 2:41 PM, <AMatveev(at)bitec(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-07-18 14:05:25 | Re: DO with a large amount of statements get stuck with high memory consumption |
Previous Message | Jan Wieck | 2016-07-18 13:59:15 | Re: DO with a large amount of statements get stuck with high memory consumption |