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

Re: Reasoning behind process instead of thread based

From: "Jim C(dot) Nasby" <decibel(at)decibel(dot)org>
To: Marco Colombo <pgsql(at)esiway(dot)net>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Reasoning behind process instead of thread based
Date: 2004-10-28 22:47:10
Message-ID: 20041028224710.GG55164@decibel.org (view raw or flat)
Thread:
Lists: pgsql-general
On Thu, Oct 28, 2004 at 02:44:55PM +0200, Marco Colombo wrote:
> I think that it would be interesting to discuss multi(processes/threades)
> model vs mono (process/thread).  Mono as in _one_ single process/thread
> per CPU, not one per session.  That is, moving all the "scheduling"
> between sessions entirely to userspace.  The server gains almost complete
> control over the data structures allocated per session, and the resources
> allocated _to_ sessions.

This is how DB2 and Oracle work. Having scheduling control is very
interesting, but I'm not sure it needs to be accomplished this way.
There are other advantages too; in both products you have a single pool
of sort memory; you can allocate as much memory to sorting as you want
without the risk of exceeding it. PostgreSQL can't do this and it makes
writing code that wants a lot of sort memory a real pain. Of course this
could probably be solved without going to a 'mono process' model.
-- 
Jim C. Nasby, Database Consultant               decibel(at)decibel(dot)org 
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"

In response to

pgsql-general by date

Next:From: Ed L.Date: 2004-10-28 22:51:05
Subject: Re: determine sequence name for a serial
Previous:From: Tom LaneDate: 2004-10-28 22:39:39
Subject: Re: Derived tables?

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