Skip site navigation (1) Skip section navigation (2)

Re: Reasoning behind process instead of thread based

From: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>
To: Scott Marlowe <smarlowe(at)qwest(dot)net>
Cc: nd02tsk(at)student(dot)hig(dot)se, pgsql-general(at)postgresql(dot)org
Subject: Re: Reasoning behind process instead of thread based
Date: 2004-10-27 17:13:12
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-general
> On some operating systems, like Windows and Solaris, processes are
> expensive, while threads are cheap, so to speak.  this is not the case
> in Linux or BSD, where the differences are much smaller, and the
> multi-process design suffers no great disadvantage.

Even on Windows or Solaris you can use techniques like persistent 
connections or connection pooling to eliminate the process overhead.

> Actually, if it were converted to multi-threaded tomorrow, it would
> still be true, because the postgresql engine isn't designed to split off
> queries into constituent parts to be executed by seperate threads or
> processes.  Conversely, if one wished to implement it, one could likely
> patch postgresql to break up parts of queries to different child
> processes of the current child process (grand child processes so to
> speak) that would allow a query to hit multiple CPUs.

I would be curious as to what this would actually gain. Of course there
are corner cases but I rarely find that it is the CPU that is doing all 
the work, thus splitting the query may not do you any good.

In theory I guess being able to break it up and execute it to different
CPUs could cause the results to process faster, but I wonder if it would
be a large enough benefit to even notice?

>>"We also provide MySQL Server as an embedded multi-threaded library that
>>you can link into your application to get a smaller, faster,
>>easier-to-manage product."
>>Do PostgreSQL offer anything similar?

No, it isn't really designed to do that. Like Oracle also is not a 
database you would Embed.

> pick PostgreSQL, it's generally considered a bad thing to have a
> database crash mid transaction.  PostgreSQL is more robust about crash
> recovery, but still...
> That's another subject that shows up every x months, an embedded version
> of PostgreSQL. Basically, the suggestion is to use something like
> SQLlite, which is built to be embedded, and therefore has a much lower
> footprint than PostgreSQL could ever hope to achieve.  No one wants
> their embedded library using up gobs of RAM and disk space when it's
> just handling one thread / process doing one thing.  It's like
> delivering Pizzas with a Ferrari, you could do it, it just eouldn't make
> a lot of sense.
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org

Command Prompt, Inc., home of PostgreSQL Replication, and plPHP.
Postgresql support, programming shared hosting and dedicated hosting.
+1-503-667-4564 - jd(at)commandprompt(dot)com -
Mammoth PostgreSQL Replicator. Integrated Replication for PostgreSQL

Attachment: jd.vcf
Description: text/x-vcard (640 bytes)

In response to

pgsql-general by date

Next:From: Froggy / Froggy Corp.Date: 2004-10-27 17:29:05
Subject: Problème de thread Postgresql [environnement apache/php]
Previous:From: Michael FuhrDate: 2004-10-27 17:01:39
Subject: Re: Reasoning behind process instead of thread based arch?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group