Every connection gets its own backend. Concurrent connections work
fine, and transactions can progress concurrently as long as the rows
that you want to update are unique.
Basically, the fact that PostgreSQL is not multi-threaded is not a big
deal (unless you want to run it on Windows or some other operating
system with a massively expensive fork()).
Jason
Brian Beuning <bbeuning@mindspring.com> writes:
> OK I admit it, I am a postgresql newbie. The developers FAQ says
> the postgresql "backend" is not multi-threaded. How serious is
> this?
>
> If this means only one transaction at a time can make progress or
> the entire DBMS server is blocked on every disk I/O then that is
> very bad.
>
> But if every connection gets its own backend, and the backends can
> run in parallel then not being multithreaded is no big deal.
>
> Here is the bottom line. Our app runs on multiple machines (we call
> them sinks) hitting one DBMS server for data. We expect the sinks
> to be able to all make progress at the same time. Each sink fetchs
> some data, goes compute bound for .2 to .4 seconds, and then sends a
> bunch of INSERT/UPDATE/DELETE to the DBMS. Will our sinks be able
> to run concurrently?
>
> Thanks,
> Brian Beuning
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster