Re: One process per session lack of sharing

On 16 July 2016 at 00:43, james <james(at)mansionfamily(dot)plus(dot)com> wrote:

> 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.
>

It is, and the JVM supports that, but it's so costly that it would
eliminate most of the benefits this user is seeking from the kind of
sharing they want. It also needs at least a minimal JVM running in the
target backends.

The issue here is an architectural mismatch between PostgreSQL and the JVM,
made worse by the user's very stored-proc-heavy code. Some other runtime
that's designed to co-operate with a multiprocessing environment could well
be fine, but the JVM isn't. At least, the Sun/Oracle/OpenJDK JVM isn't.

They could explore doing their bytecode compilation for another runtime
that's more friendly toward multiprocessing (maybe Mono? Haven't tried)
and/or look at using PostgreSQL's shared memory facilities within their
target runtime. It's not like this is insoluible without completely
rebuilding PostgreSQL.

For them it'd be great if PostgreSQL used multi-threading instead of
multi-processing, but it doesn't, and it's not likely to. So they've got to
find other solutions to their difficulties within PostgreSQL or use another
product.

Such a host delegate process could be explicitly built with multithread
> support and not 'infect' the rest of the code with its requirements.
>

Not if it lives in the postmaster. It'd have to be forked and communicated
with at one remove.

Using granular RPC is nice for isolation but I am concerned that the
> latencies might be high.
>

Yep. When your goal is performance and you're trying to move stuff closer
to the DB and out of an appserver, it's likely counterproductive.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services