Reasoning behind process instead of thread based arch? - Mailing list pgsql-general

From nd02tsk@student.hig.se
Subject Reasoning behind process instead of thread based arch?
Date
Msg-id 3647.130.243.12.138.1098892576.squirrel@130.243.12.138
Whole thread Raw
Responses Re: Reasoning behind process instead of thread based  (Doug McNaught <doug@mcnaught.org>)
Re: Reasoning behind process instead of thread based  ("Scott Marlowe" <smarlowe@qwest.net>)
Re: Reasoning behind process instead of thread based arch?  (Michael Fuhr <mike@fuhr.org>)
List pgsql-general
Hello!

I have a couple of final ( I hope, for your sake ) questions regarding
PostgreSQL.

I understand PostgreSQL uses processes rather than threads. I found this
statement in the archives:

"The developers agree that multiple processes provide
more benefits (mostly in stability and robustness) than costs (more
connection startup costs). The startup costs are easily overcome by
using connection pooling.
"

Please explain why it is more stable and robust? More from the above
statement:

"Also, each query can only use one processor; a single query can't be
executed in parallel across many CPUs. However, several queries running
concurrently will be spread across the available CPUs."

And it is because of the PostgreSQL process architecture that a query
can't be executed by many CPU:s right? Although I wonder if this is the
case in MySQL. It only says in their manual that each connection is a
thread.

Also, MySQL has a library for embedded aplications, the say:

"We also provide MySQL Server as an embedded multi-threaded library that
you can link into your application to get a smaller, faster,
easier-to-manage product."

Do PostgreSQL offer anything similar?

Thank you for your time.

Tim




pgsql-general by date:

Previous
From: "NTPT"
Date:
Subject: Exact or less specific match ?
Next
From: Jerry LeVan
Date:
Subject: Psycopg difficulty...