From: | Curt Sampson <cjs(at)cynic(dot)net> |
---|---|
To: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au> |
Cc: | mlw <pgsql(at)mohawksoft(dot)com>, Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>, PGHackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Threads |
Date: | 2003-01-23 15:02:11 |
Message-ID: | Pine.NEB.4.51.0301232355300.547@angelic.cynic.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)cynic(dot)net> +81 90 7737 2974 http://www.netbsd.org
Don't you know, in this new Dark Age, we're all light. --XTC
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-01-23 15:03:28 | Re: Call for objections: put back OIDs in CREATE TABLE AS/SELECT INTO |
Previous Message | Tom Lane | 2003-01-23 14:50:02 | Re: Terrible performance on wide selects |