Re: [HACKERS] One process per session lack of sharing

Hi > Using TLS will slow down things noticeably though. So if we were to go > there, we'd have to make up for some constant slowdown. I can not understand why? I've read https://msdn.microsoft.com/en-us/library/windows/desktop/ms686749(v=vs.85).aspx and

Re: [HACKERS] One process per session lack of sharing

Hi >So I think as long as process and thread have different function in OS, >use process like thread will have overhead in practice. But There are other negative things. I think parallel oriented library usually do not work with process. So Jvm integration is not exception. It is

Re: [HACKERS] One process per session lack of sharing

Hi > 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 I think even if I was the leader in OS development, I could not correctly answer your question. So just let discuss. Ok, I agree with you that

Re: [HACKERS] One process per session lack of sharing

Hi > This https://github.com/davecramer/plj-new is a very old project > that did work at one time which attempted to do RPC calls to the jvm to > address exactly this problem. > However "cheaply" calling jvm from sql or vice-versa is not really possible. > I do like the idea of the background

Re: [HACKERS] One process per session lack of sharing

Hi > There's https://github.com/jnr/jnr-ffi that enables to call C > functions without resorting to writing JNI wrappers. I have not said that you are wrong. It's the dark side of "like seprate process" They can cheaply call sql from jvm. And they can't cheaply call jvm from sql. Jvm in oracle

Re: [HACKERS] One process per session lack of sharing

Hi > I admit that it is risky, but I think there are things that could be > done to limit the risk. I don't believe we can indefinitely continue > to ignore the potential performance benefits of making a switch like > this. Breaking a thirty-year old code base irretrievably would be > sad, but

Re: [HACKERS] One process per session lack of sharing

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

Re: [HACKERS] One process per session lack of sharing

Hi > Such a host delegate process could be explicitly built with > multithread support and not 'infect' the rest of the code with its > requirements. > > Using granular RPC is nice for isolation but I am concerned that the > latencies might be high. I agree with you. Moreover I think that

Re: [HACKERS] One process per session lack of sharing

Hi > This is true, only when data are immutable and in memory. Elsewhere it is > false idea. For case whenthe server works 24x7 and you need ability to fix bugs(or update) on the fly in any app code. It's usual. -- Sent via pgsql-hackers mailing list

Re: [HACKERS] One process per session lack of sharing

Hi > but parallel processing doesn't requires threading support - see PostgreSQL > 9.6 features. To share dynamic execution code between threads much more easy(If sharing this code between process is possible). There is many other interaction techniques between threads which is

Re: [HACKERS] One process per session lack of sharing

Hi > If amatveev (username, unsure of full name) wants to improve > PL/PgSQL performance and the ability of a JVM to share resources > between backends, then it would be more productive to focus on that than on > threading. Note, I've statred this post with https://www.postgresql

Re: [HACKERS] One process per session lack of sharing

Hi > Can be nice, if we can help to all Oracle users - but it is not > possible in this world :( - there is lot of barriers - threading is > only one, second should be different design of PL/SQL - it is based > on out processed, next can be libraries, JAVA integration, and lot > of others. I

Re: [HACKERS] One process per session lack of sharing

Hi > I disagree - there is lot of possible targets with much higher > benefits - columns storage, effective execution - compiled > execution, implementation of temporal databases, better support for > dynamic structures, better support for XML, JSON, integration of connection > pooling, ... Off

Re: [HACKERS] One process per session lack of sharing

Hi Is there any plan to implement "session per thread" or "shared sessions between thread"? > I'm personally not absolutely opposed to threading, but you'll find > it hard to convince anyone it's worth the huge work required to > ensure that everything in PostgreSQL is done

Re: [HACKERS] One process per session lack of sharing

Hi > It's mostly working, but there are workloads where it > fails badly - and competing database products survive a number of > scenarios where we just fall on our face. > So, I actually think it would be a good idea to think about this. Just to think. http://www.tiobe.com/tiobe_index The

Re: [HACKERS] One process per session lack of sharing

Hi > On Tue, Jul 12, 2016 at 9:18 AM, Tom Lane wrote: >> amatv...@bitec.ru writes: >>> Is there any plan to implement "session per thread" or "shared >>> sessions between thread"? >>... >> so >> there's not that much motivation to do a ton of work inside the database

Re: [HACKERS] One process per session lack of sharing

Hi > amatv...@bitec.ru writes: >> Is there any plan to implement "session per thread" or "shared >> sessions between thread"? > No, not really. The amount of overhead that would add --- eg, the need > for locking on what used to be single-use caches --- makes the benefit > highly

[HACKERS] One process per session lack of sharing

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