Re: One process per session lack of sharing - Mailing list pgsql-hackers

From AMatveev@bitec.ru
Subject Re: One process per session lack of sharing
Date
Msg-id 399390854.20160715122927@bitec.ru
Whole thread Raw
In response to Re: One process per session lack of sharing  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: One process per session lack of sharing  (Pavel Stehule <pavel.stehule@gmail.com>)
List pgsql-hackers
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.

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.





pgsql-hackers by date:

Previous
From: Dmitriy Sarafannikov
Date:
Subject: Re: [HACKERS] [PERFORM] 9.4 -> 9.5 regression with queries through pgbouncer on RHEL 6
Next
From: Pavel Stehule
Date:
Subject: Re: One process per session lack of sharing