>>>> 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
>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 (firstname.lastname@example.org)
To make changes to your subscription: