Sean Chittenden wrote:
>PostgreSQL will never be single proc, multi-threaded, and I don't
>think it should be for reliability's sake. See my above post,
>however, as I think I may have a better way to handle "lots of
>connections" without using threads. -sc
>
never is a VERY long time ... Also, the single proc/multiple proc thing
does not have to be exclusive. Meaning you could "tune" the system so
that it could do either.
I have developed a single process server that handled thousands of
connections. I've also developed a single process database (a while
back) that handled multiple connections but I'm not sure I would do it
the "hard" way again as the cost of writing the code for keeping context
was not insignificant, although there are much better ways of doing it
than how I did it 15 years ago.
What you talk about is very fundamental and I would love to have another
go at it .... however you're right that this won't happen any time
soon. Connection pooling is a fundamentally flawed way of overcoming
this problem. A different design could render a significantly higher
feasable connection count.
G
