On Fri, 2003-01-03 at 19:34, Tom Lane wrote:
> "Serguei Mokhov" <mokhov@cs.concordia.ca> writes:
> >>> (1) One thread screws up, the whole process dies. In a
> >>> multiple process application this is not too much of an issue.
>
> > (1) is an issue only for user-level threads.
>
Umm. No. User or system level threads, the statement is true. If a
thread kills over, the process goes with it. Furthermore, on Win32
platforms, it opens a whole can of worms no matter how you care to
address it.
> Uh, what other kind of thread have you got in mind here?
>
> I suppose the lack-of-cross-thread-protection issue would go away if
> our objective was only to use threads for internal parallelism in each
> backend instance (ie, you still have one process per connection, but
> internally it would use multiple threads to process subqueries in
> parallel).
>
Several have previously spoken about a hybrid approach (ala Apache).
IIRC, it was never ruled out but it was simply stated that no one had
the energy to put into such a concept.
> Of course that gives up the hope of faster connection startup that has
> always been touted as a major reason to want Postgres to be threaded...
>
> regards, tom lane
Faster startup, should never be the primary reason as there are many
ways to address that issue already. Connection pooling and caching are
by far, the most common way to address this issue. Not only that, but
by definition, it's almost an oxymoron. If you really need high
performance, you shouldn't be using transient connections, no matter how
fast they are. This, in turn, brings you back to persistent connections
or connection pools/caches.
--
Greg Copeland <greg@copelandconsulting.net>
Copeland Computer Consulting