On Fri, 2003-04-11 at 17:32, Kevin Brown wrote:
The big overhead in the process model on most platforms is in creation
and destruction of processes. PostgreSQL has a relatively high
connection startup cost. But there are ways of dealing with this
problem other than threading, namely the use
Neil Conway wrote:
Furthermore, IIRC PostgreSQL's relatively slow connection creation time
has as much to do with other per-backend initialization work as it does
with the time to actually fork() a new backend. If there is interest in
optimizing backend startup time, my guess would be that
Greg Stark wrote:
Shridhar Daithankar [EMAIL PROTECTED] writes:
But database is not webserver. It is not suppose to handle tons of concurrent
requests. That is a fundamental difference.
And in one fell swoop you've dismissed the entire OLTP database industry.
Have you ever called a
Mark Kirkwood [EMAIL PROTECTED] writes:
I think there is some confusion between many concurrent connections + short
transactions and many connect / disconnect + short transactions in some of
this discussion.
I was intended to clarify that but left it out. In fact I think that's
precisely one
Greg Stark [EMAIL PROTECTED] writes:
However even if you reuse existing database connections, you nonetheless are
still context switching between hundreds or potentially thousands of threads
of execution. The lighter-weight that context switch is, the faster it'll be
able to do that.
It's
