Re: What is the practical limitation of no multi-threading?

From: "Gregory Wood" <gregw(at)com-stock(dot)com>
To: "Brian Beuning" <bbeuning(at)mindspring(dot)com>
Cc: "PostgreSQL-General" <pgsql-general(at)postgresql(dot)org>
Subject: Re: What is the practical limitation of no multi-threading?
Date: 2001-12-10 16:32:41
Message-ID: 001501c18198$4a554980$7889ffcc@comstock.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> OK I admit it, I am a postgresql newbie. The developers FAQ says the
> postgresql "backend" is not multi-threaded. How serious is this?

Not serious at all... PostgreSQL is not multi-threaded, but it does take
advantage of multiple processes. Each connection spawns a new backend
process that run concurrently with other backend processes.

> 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.

One transaction per connection. But you can have quite a large number of
connections, each with their own process.

> But if every connection gets its own backend, and the backends can run
> in parallel then not being multithreaded is no big deal.

Exactly.

> 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?

Yes, breathe easy :)

Greg

In response to

Browse pgsql-general by date

  From Date Subject
Next Message wsheldah 2001-12-10 16:36:13 Re: Any comments on any of the recent crop of books?
Previous Message Holger Krug 2001-12-10 16:27:08 Re: Limit of sequence