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

Re: Threads

From: mlw <pgsql(at)mohawksoft(dot)com>
To: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>
Cc: PGHackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Threads
Date: 2003-01-03 20:47:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Please no threading threads!!!

Has anyone calculated the interval and period of "PostgreSQL needs 
threads" posts?

The *ONLY* advantage threading has over multiple processes is the time 
and resources used in creating new processes.

That being said, I admit that creating a threaded program is easier than 
one with multiple processes, but PostgreSQL is already there and working.

Drawbacks to a threaded model:

(1) One thread screws up, the whole process dies. In a multiple process 
application this is not too much of an issue.

(2) Heap fragmentation. In a long uptime application, such as a 
database, heap fragmentation is an important consideration. With 
multiple processes, each process manages its own heap and what ever 
fragmentation that exists goes away when the connection is closed.  A 
threaded server is far more vulnerable because the heap has to manage 
many threads and the heap has to stay active and unfragmented in 
perpetuity. This is why Windows applications usually end up using 2G of 
memory after 3 months of use. (Well, this AND memory leaks)

(3) Stack space. In a threaded application they are more limits to stack 
usage. I'm not sure, but I bet PostgreSQL would have a problem with a 
fixed size stack, I know the old ODBC driver did.

(4) Lock Contention. The various single points of access in a process 
have to be serialized for multiple threads. heap allocation, 
deallocation, etc all have to be managed. In a multple process model, 
these resources would be separated by process contexts.

(5) Lastly, why bother? Seriously? Process creation time is an issue 
true, but its an issue with threads as well, just not as bad. Anyone who 
is looking for performance should be using a connection pooling 
mechanism as is done in things like PHP.

I have done both threaded and process servers. The threaded servers are 
easier to write. The process based severs are more robust. From an 
operational point of view, a "select foo from bar where x > y" will take 
he same amount of time.

In response to

  • Threads at 2003-01-03 15:24:11 from Shridhar Daithankar


  • Re: Threads at 2003-01-03 21:34:10 from Greg Copeland
  • Re: Threads at 2003-01-04 05:33:20 from Christopher Kings-Lynne

pgsql-hackers by date

Next:From: Dann CorbitDate: 2003-01-03 20:52:48
Subject: Re: Threads
Previous:From: Tom LaneDate: 2003-01-03 20:37:56
Subject: Re: Upgrading rant.

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