Re: Spinlock performance improvement proposal - Mailing list pgsql-hackers

From Myron Scott
Subject Re: Spinlock performance improvement proposal
Date
Msg-id Pine.GSO.4.10.10109261428340.563-100000@goldengate.kojoworldwide.com.
Whole thread Raw
In response to Re: Spinlock performance improvement proposal  (mlw <markw@mohawksoft.com>)
List pgsql-hackers

On Wed, 26 Sep 2001, mlw wrote:

> I can only think of two objectives for threading. (1) running the various
> connections in their own thread instead of their own process. (2) running
> complex queries across multiple threads.
> 

I did a multi-threaded version of 7.0.2 using Solaris threads about a year
ago in order to try
and get multiple backend connections working under one java process using
jni.  I used the thread per connection model.

I eventually got it working, but it was/is very messy ( there were global
variables everywhere! ).  Anyway, I was able to get a pretty good speed up
on inserts by scheduling buffer writes from multiple connections on one
common writing thread.  

I also got some other features that were important to me at the time.

1.  True prepared statements under java with bound input and output
variables
2.  Better system utilization a.  fewer Solaris lightweight processes mapped to threads.b.  Fewer open files per
postgresinstallation 
 
3.  Automatic vacuums when system activity is low by a daemon thread.

but there were some drawbacks...  One rogue thread or bad user 
function could take down all connections for that process.  This
was and seems to still be the major drawback to using threads.


Myron Scott
mscott@sacadia.com



pgsql-hackers by date:

Previous
From: Ian Lance Taylor
Date:
Subject: Re: Spinlock performance improvement proposal
Next
From: Martín Marqués
Date:
Subject: pg_dump bug