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