Thread: Threads
Hi Everybody. As well, a few have been asking about multi-threading. Marc has told me about the past discussions on it. I'm interested in re-opening some discussion on it, as we may eventually have funding to do help with it. Would it not be advantageous to use threading in the PostgreSQL backend? Many servers make use of threading to increase throughput by performing IO and computations concurrently. (While one thread is waiting for the disk to respond to an IO request, another processes the last chunk of data). As well, threads tend to have a lower process switching time, so that may help a bit on heavily loaded systems. (Of course, it would tend to be a combination of forking and threading. Threading benefits have limits). Any thoughts? Duane
> As well, a few have been asking about multi-threading.
> Any thoughts?
Threads within a client backend might be interesting. imho a
single-process multi-client multi-threaded server is just asking for
trouble, putting all clients at risk for any single misbehaving one.
Particularly with our extensibility features, where users and admins
can add functionality through code they have written (or are trying to
write ;) having each backend isolated is A Good Thing.
istm that many of the cases for which multi-threading is proposed (web
serving always comes up) can be solved using persistant connections or
other techniques.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Duane Currie <dcurrie@sandman.acadiau.ca> writes:
> Would it not be advantageous to use threading in the PostgreSQL backend?
Just so you don't break the code for non-threaded platforms.
I believe mysql *requires* working thread support, which is one reason
it is not so portable as Postgres... we should not give up that advantage.
BTW, I'm not convinced that threading would improve performance very
much within a single backend. It might be a win as a substitute for
multiple backends, ie, instead of postmaster + N backends you have just
one process with a bunch of threads. (But on the downside of *that* is
that a backend crash now takes down your postmaster along with
everything else...)
regards, tom lane
On 03-Aug-99 Thomas Lockhart wrote: >> As well, a few have been asking about multi-threading. >> Any thoughts? I completly agree with Thomas. Mutiprocess server is also more convenient for managing and more portable > > Threads within a client backend might be interesting. imho a > single-process multi-client multi-threaded server is just asking for > trouble, putting all clients at risk for any single misbehaving one. > Particularly with our extensibility features, where users and admins > can add functionality through code they have written (or are trying to > write ;) having each backend isolated is A Good Thing. > > istm that many of the cases for which multi-threading is proposed (web > serving always comes up) can be solved using persistant connections or > other techniques. > > - Thomas > > -- > Thomas Lockhart lockhart@alumni.caltech.edu > South Pasadena, California --- Dmitry Samersoff, dms@wplus.net, ICQ:3161705 http://devnull.wplus.net * There will come soft rains ...
On Tue, 3 Aug 1999, Tom Lane wrote:
> Duane Currie <dcurrie@sandman.acadiau.ca> writes:
> > Would it not be advantageous to use threading in the PostgreSQL backend?
>
> Just so you don't break the code for non-threaded platforms.
>
> I believe mysql *requires* working thread support, which is one reason
> it is not so portable as Postgres... we should not give up that advantage.
Just curious here, but out of all the platforms we support, are there any
remaining that don't support threads?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker <scrappy@hub.org> writes:
> Just curious here, but out of all the platforms we support, are there any
> remaining that don't support threads?
Pretty much all of the older ones, I imagine --- I know HPUX 9 does not.
Of course HPUX 9 will be a dead issue by the end of the year, because
HP isn't going to fix its Y2K bugs; I wonder whether there is a similar
forcing function for old SunOS and other systems?
But still, I believe there are several different flavors of thread
packages running around, so we will be opening a brand new can of
portability worms. We'd best keep a "no threads" fallback option...
regards, tom lane
On Tue, Aug 03, 1999 at 02:18:07PM +0000, Thomas Lockhart wrote: > > As well, a few have been asking about multi-threading. > > Any thoughts? > > Threads within a client backend might be interesting. [...] Hmm, what about threads in the frontend? Anyone know if libpq is thread safe, and if not, how hard it might be to make it so? Ross -- Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> NSBRI Research Scientist/Programmer Computer and Information Technology Institute Rice University, 6100 S. Main St., Houston, TX 77005
On Tue, 3 Aug 1999, Tom Lane wrote:
> The Hermit Hacker <scrappy@hub.org> writes:
> > Just curious here, but out of all the platforms we support, are there any
> > remaining that don't support threads?
>
> Pretty much all of the older ones, I imagine --- I know HPUX 9 does not.
>
> Of course HPUX 9 will be a dead issue by the end of the year, because
> HP isn't going to fix its Y2K bugs; I wonder whether there is a similar
> forcing function for old SunOS and other systems?
HPUX9 won't be that dead. It's still the highest version the 300
series machines will run and the Y2K problems in it aren't enough
to force alot of folks to upgrade the hardware and OS. We're still
using HPUX8 on a number of our test stands and they even pass enuf
Y2K to keep 'em going (RMB can't do the dates but the system can).
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
On Tue, 3 Aug 1999, Tom Lane wrote:
> But still, I believe there are several different flavors of thread
> packages running around, so we will be opening a brand new can of
> portability worms. We'd best keep a "no threads" fallback option...
Sounds reasonable, but is it feasible? I think the general thread right
now is to go with partial threading, but how hard is it going to be to
implement even partial threading will maintaining the no-thread features?
Basically just massive #ifdef blocks? *raised eyebrow*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
> Hmm, what about threads in the frontend? Anyone know if libpq is thread
> safe, and if not, how hard it might be to make it so?
It is not; the main reason why not is a brain-dead part of the API that
exposes modifiable global variables. Check the mail list archives
(probably psql-interfaces, but maybe -hackers) for previous discussions
with details. Earlier this year I think, or maybe late 98.
regards, tom lane
> On Tue, Aug 03, 1999 at 02:18:07PM +0000, Thomas Lockhart wrote: > > > As well, a few have been asking about multi-threading. > > > Any thoughts? > > > > Threads within a client backend might be interesting. [...] > > Hmm, what about threads in the frontend? Anyone know if libpq is thread > safe, and if not, how hard it might be to make it so? > I believe it is thread-safe. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes: > > Hmm, what about threads in the frontend? Anyone know if libpq is thread > > safe, and if not, how hard it might be to make it so? > > It is not; the main reason why not is a brain-dead part of the API that > exposes modifiable global variables. Check the mail list archives > (probably psql-interfaces, but maybe -hackers) for previous discussions > with details. Earlier this year I think, or maybe late 98. hmmm... usually this is repairable by creating wrapper functions which index the variables by thread id, and enforcing the use of the functions... (maybe something for a wish list...) Duane
Hi all Small intrusion in the Threads discussion 1) don' t forget other OS .. the linux is not the only one (for now :-) ) For example check the performance under Solaris http://www2.linuxjournal.com/lj-issues/issue70/3184.html 2) unfortunatly some platforms that had no threads (but is a few) or an incompatible threads library (the major .. ) On the informix doc i read : To most effectively utilize system resources, a configurable pool of database server processes calledvirtual processors schedule and manage user requests across multiple CPUs and disks. User requests are represented by lightweight mechanisms called threads. Each thread consists of a single sequential flow of control that represents part of a discrete task within a database server process. For example, a processing-intensive request such as a multi-table join can be divided into multiple database threads (subtasks) and spread across all the available virtual processors in the system. Could be intresting: One process for connection client ,but composed with many threads (similar to apache 2.0) - No crash all the system- Better performance in sql execution (i hope) I think will be the way for the future (Postgresql 8.0 ? ) , i know is not simple