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.
You're better off by designing the application to use pooled
DB connections, like AOL-Server for example.
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?
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.
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.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
