Re: Threads - Mailing list pgsql-hackers

From Curt Sampson
Subject Re: Threads
Date
Msg-id Pine.NEB.4.51.0301232355300.547@angelic.cynic.net
Whole thread Raw
In response to Re: Threads  (Christopher Kings-Lynne <chriskl@familyhealth.com.au>)
Responses Re: Threads
List pgsql-hackers
On Sat, 4 Jan 2003, Christopher Kings-Lynne wrote:

> Also remember that in even well developed OS's like FreeBSD, all a
> process's threads will execute only on one CPU.

I would say that that's not terribly well developed. Solaris will split
a single processes' threads over multiple CPUs, and I expect most other
major vendors Unixes will as well. In the world of free software, the
next release of NetBSD will do the same. (The scheduler activations
system, which support m userland to n kernel threads mapping, was
recently merged from its branch into NetBSD-current.)

From my experience, threaded sorts would be a big win. I managed to
shave index generation time for a large table from about 12 hours to
about 8 hours by generating two indices in parallel after I'd added a
primary key to the table. It would have been much more of a win to be
able to generate the primary key followed by other indexes with parallel
sorts rather than having to generate the primary key on one CPU (while
the other remains idle), wait while that completes, generate two more
indices, and then generate the last one .

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC
 


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Terrible performance on wide selects
Next
From: Tom Lane
Date:
Subject: Re: Call for objections: put back OIDs in CREATE TABLE AS/SELECT INTO