Threads are bad - I know ...
I like the idea of a pool of processes instead of threads - from my
point of view this would be useful.
I am planning to run some tests (GEQO, AIX, sorts) as soon as I have
time to do so (still too much work ahead before :( ...).
If I had time I'd love to do something for the PostgreSQL community :(.
As far as sorting is concerned: It would be fine if it was possible to
define an alternative location for temporary sort files using SET.
If you had multiple disks this would help in the case of concurrent
sorts because this way people could insert and index many tables at once
without having to access just one storage system.
This would be an easy way out of the IO limitation ... - at least for
some problems.
Hans
Bruce Momjian wrote:
>
>We haven't thought about it yet because there are too many buggy thread
>implementations. We are probably just now getting to a point where we
>can consider it. However, lots of databases have moved to threads for
>all sorts of things and ended up with a royal mess of code. Threads
>can only improve things in a few areas of the backend so it would be
>nice if we could limit the exposure to threads to those areas; sorting
>could certainly be one of them, but frankly, I think disk I/O is our
>limiting factore there. I would be interested to see some tests that
>showed otherwise.
>
>
--
*Cybertec Geschwinde u Schoenig*
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/1/913 68 09; +43/664/233 90 75
www.postgresql.at <http://www.postgresql.at>, cluster.postgresql.at
<http://cluster.postgresql.at>, www.cybertec.at
<http://www.cybertec.at>, kernel.cybertec.at <http://kernel.cybertec.at>
