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