Re: Reasoning behind process instead of thread based - Mailing list pgsql-general

From Thomas Hallgren
Subject Re: Reasoning behind process instead of thread based
Date
Msg-id 4180C6C7.1000708@mailblocks.com
Whole thread Raw
In response to Reasoning behind process instead of thread based arch?  (nd02tsk@student.hig.se)
List pgsql-general
nd02tsk@student.hig.se wrote:

>So Thomas, you say you like the PostgreSQL process based modell better
>than the threaded one used by MySQL. But you sound like the opposite. I'd
>like to know why you like processes more.
>
>
Ok, let me try and explain why I can be perceived as a scatterbrain :-).

PostgreSQL is a very stable and well functioning product. It is one of
the few databases out there that has a well documented way of adding
plugins written in C and quite a few plugins exists today. You have all
the server side languages, (PL/pgsql PL/Perl, PL/Tcl, PL/Java, etc.),
and a plethora of custom functions and other utilities. Most of this is
beyond the control of the PostgreSQL core team since it's not part of
the core product. It would be extremely hard to convert everything into
a multi-threaded environment and it would be even harder to maintain the
very high quality that would be required.

I think PostgreSQL in it's current shape, is ideal for a distributed,
Open Source based conglomerate of products. The high quality core firmly
controlled by the core team, in conjunction with all surrounding
features, brings you DBMS functionality that is otherwise unheard of in
the free software market. I believe that this advantage is very much due
to the simplicity and bug-resilient single-threaded design of the
PostgreSQL.

My only regret is that the PL/Java, to which I'm the father, is confined
to one connection only. But that too has some advantages in terms of
simplicity and reliability.

So far PostgreSQL
At present, I'm part of a team that develops a very reliable
multi-threaded system (a Java VM). In this role, I've learned a lot
about how high performance thread based systems can be made. If people
on this list wants to dismiss multi-threaded systems, I feel they should
do it based on facts. It's more than possible to build a great
multi-threaded server. It is my belief that as PostgreSQL get more
representation in the high end market where the advantages of
multi-threaded solutions get more and more apparent, it will find that
the competition from a performance standpoint is sometimes overwhelming.

I can't say anything about MySQL robustness because I haven't used it
much. Perhaps the code quality is indeed below what is required for a
multi-threaded system, perhaps not. I choose PostgreSQL over MySQL
because MySQL lacks some of the features that I feel are essential,
because it does some things dead wrong, and because it is dual licensed.

Hope that cleared up some of the confusion.

Regards,
Thomas Hallgren



pgsql-general by date:

Previous
From: Martijn van Oosterhout
Date:
Subject: Re: Reasoning behind process instead of thread based
Next
From: Thomas Hallgren
Date:
Subject: Re: Reasoning behind process instead of thread based