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

From AMatveev@bitec.ru
Subject One process per session lack of sharing
Date
Msg-id 942824238.20160712165757@bitec.ru
Whole thread Raw
Responses Re: One process per session lack of sharing  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: One process per session lack of sharing  (Craig Ringer <craig@2ndquadrant.com>)
Re: One process per session lack of sharing  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
Hi

Is  there  any  plan  to  implement  "session  per  thread" or "shared
sessions between thread"?
We  have analyzed  the  ability to contribute  pgSql to jvm bytecode compiler but with
current   thread   model  this  idea  is  far  from optimal.(Vm can be different of course.
But currently we use oracle and jvm is important for us)

We have faced with some lack of sharing resources.
So in our test memory usage per session:
Oracle: about 5M
MSSqlServer: about 4M
postgreSql: about 160М

It's discussed on pgsql-general@postgresql.org:
http://www.mail-archive.com/pgsql-general@postgresql.org/msg206452.html


>I think the "problem" that he is having is fixable only by changing how
>PostgreSQL itself works. His problem is a PL/pgSQL function which is 11K
>lines in length. When invoked, this function is "compiled" into a large
>tokenized parse tree. This parse tree is only usable in the session which
>invoked the the function. Apparently this parse tree takes a lot of memory.
>And "n" concurrent users of this, highly used, function will therefore
>require "n" times as much memory because the parse tree is _not_
>shareable.  This is explained in:
>https://www.postgresql.org/docs/9.5/static/plpgsql-implementation.html#PLPGSQL-PLAN-CACHING

Next  interesting  answer(from  Karl  Czajkowski  <karlcz@isi.edu>  in
private):
>  But, I search the
> archives of the mailing list, and when others have previously
> suggested such caching or reuse, it was immediately shot down by core
> developers.





pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: IMPORT FOREIGN SCHEMA can't be run in in pl/pgsql due to INTO
Next
From: Tom Lane
Date:
Subject: Re: One process per session lack of sharing