Re: Is PostgreSQL multi-threaded?

My $0.02:

Jan Wrote...
> Lincoln Yeoh wrote:
> > At 10:28 PM 29-05-2000 -0400, Joseph Shraibman wrote:
> > >So in other words, it *is* multithreaded.  It just uses heavyweight
> > >threads.
> >
> > I call those ropes ;). A lot more robust, but give your system enough of
> > them it'll hang itself.
>
>     If  performance goes down because of missing computing power,
>     more threads won't make it better.
>

Right.  Except in pathological cases the work done by a thread/process
ought to be a lot more than the work done by the Kernel to switch
the thread or process.

>     You're better off by designing the application to use  pooled
>     DB connections, like AOL-Server for example.
>

An NxM multiplexer for PostgreSQL is something that I've been thinking about
writing for a long time.  Kind of like being able to tune the number
of server processes that Apache runs.

>     Multithreading  is  kinda  Buzzword,  and  many  people today
>     believe it is the  solution  for  all  performance  problems.
>     Well,  starting  a thread is faster, consumes less resources,
>     yada, yada. But they forget about the problems.
>
>     All threads live in the same address  space.  In  PostgreSQL,
>     someone  can  write  his own C functions, and run them in his
>     test database. If such a function is buggy, should it be able
>     to   corrupt   the  memory  of  another  thread  serving  the
>     production DB?
>

Not only are you faced with sharing the memory space, but threaded
programs force the programmer to constantly worry about controlling
access to the critical sections.  Myself, I vastly prefer the Tcl
event-driven model.  When your handler runs, it's got the process:
do what you gotta do and get out of the way.

>     Threads have OS specific limits. Linux  for  example  doesn't
>     support  the POSIX call to set the per thread stack limit. It
>     manages them dynamically up to 2MB. In other OSs you have  to
>     decide what's the estimated required stack size.
>

Arrg.  Stack size.  A giant step backwards.  I spent way too much
of my youth fighting with overflowing stacks and wild pointers in
real-time systems using RT Kernels like PSOS.  Never again.  Not
that I didn't like PSOS, but only for Hard with a Capital H real
time.

>     What  counts  for a DB server is speed and reliability. But I
>     think it's a bad decision to gain  speed  from  mucking  with
>     reliability.
>

Which is what Oracle says.  In 95% of the cases you run your process
communicating with an Oracle "Shadow Process" that accesses the
database for you.  For things like sql loader[1] they link the app directly
with the oracle access libraries to squeeze the last few percent of
performance out of the system.  Otherwise forget it.  Not worth the
trouble.

-- cary

>
> Jan
>
>