Re: One process per session lack of sharing

2016-07-15 11:29 GMT+02:00 <AMatveev(at)bitec(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>