Not being multithreaded may only be a big deal if your application connects
and disconnects from the database at high rates. In that situation, such an
application would suffer the poorer performance of multiprocess servers like
Postgres since it is significantly more time consuming to copy the memory
management unit (mmu) state, or at least to load a new program image (the
backend), than with threads which share mmu state and program image.
Bob
On Friday 07 December 2001 09:05 pm, Brian Beuning wrote:
> 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
