From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | AMatveev(at)bitec(dot)ru |
Cc: | Craig Ringer <craig(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: One process per session lack of sharing |
Date: | 2016-07-15 10:05:43 |
Message-ID: | CAFj8pRABpYgaMsHZ=Rf8bcVZSEKBhHrhsPThjOY1MWuZ+AioDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
>
From | Date | Subject | |
---|---|---|---|
Next Message | AMatveev | 2016-07-15 10:20:36 | Re: One process per session lack of sharing |
Previous Message | AMatveev | 2016-07-15 09:29:27 | Re: One process per session lack of sharing |