2016-07-15 11:29 GMT+02:00 <amatv...@bitec.ru>:
> >>>> 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'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.
> And may be the right start is to fix the Faq
> >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 (email@example.com)
> To make changes to your subscription: