2016-07-15 11:29 GMT+02:00 <amatv...@bitec.ru>: > 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 thread-safely > It's clear for me, I understand that organizing that work is really very > hard. It's work for new segment of market in long perspective. > For most open source project this is very difficult. In some case > it may be not possible at all. > > But in the most cases there is proverb: "We make the road by walking on > it" > > It's very important just to start. >
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, ... There is only few use cases - mostly related to Oracle emulation when multi threading is necessary - and few can be solved better - PLpgSQL to C compilation and similar techniques. The organization of work is hard, but pretty harder is doing this work - and doing it without impact on current code base, current users. MySQL is thread based database - is better than Postgres, or there is more users migrated from Orace? Not. Regards Pavel > > And may be the right start is to fix the Faq > > https://wiki.postgresql.org/wiki/FAQ#Why_does_PostgreSQL_use_so_much_memory.3F > >Why does PostgreSQL use so much memory? > >Despite appearances, this is absolutely normal > It's not normal. It's "as is". You should use pgBouncer. See "Re: > [HACKERS] One process per session lack of sharing" > And it is why > >there are workloads where it > >fails badly - and competing database products survive a number of > >scenarios where we just fall on our face > > > > Er.... yeah, it really is. It's not just the mechanical changes. > > It's verifying that everything's correct on all the supported > > platforms. Ensuring that all the C library stuff we do is > > thread-safe, all the SSL stuff, etc. Getting rid of all the > > function-static variable use. Lots more. > In the most cases the work can be done part by part. > May be there is such parts. It's not necessary to do everything at once. > > > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers >
