Re: One process per session lack of sharing
| От | Vladimir Sitnikov |
|---|---|
| Тема | Re: One process per session lack of sharing |
| Дата | |
| Msg-id | CAB=Je-EV0-XgvyPnYVKW5n3npmYuu5QDStPPFeDzAT2Xz56m9A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: One process per session lack of sharing (Craig Ringer <craig@2ndquadrant.com>) |
| Ответы |
Re: One process per session lack of sharing
Re: One process per session lack of sharing |
| Список | pgsql-hackers |
Craig>That moves work further away from the DB, which has its own costs, and isn't something you're likely to be happy with if you're looking at things like optimising PL/PgSQL with a bytecode compiler. But it's the best we have right now.
What if JVM was started within a background worker?
Then JVM can spawn several threads that serve PL requests on a "thread per backend" basis.
Craig>You may be able to greatly reduce that cost if you can store your cached compiled data in a shared memory segment created by your extension.
Craig>This will get a bit easier with the new dynamic shared memory infrastructure, but it's going to be no fun at all to make that play with the JVM. You'll probably need a lot of JNI.
There's https://github.com/jnr/jnr-ffi that enables to call C functions without resorting to writing JNI wrappers.
Vladimir
В списке pgsql-hackers по дате отправления: