From: | Hans-Jürgen Schönig <hs(at)cybertec(dot)at> |
---|---|
To: | Greg Copeland <greg(at)CopelandConsulting(dot)Net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Threaded Sorting |
Date: | 2002-10-04 15:37:16 |
Message-ID: | 3D9DB5AC.5070207@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Threads are not the best solutions when it comes to portability. A
prefer a process model as well.
My concern was that a process model might be a bit too slow for that but
if we had processes in memory this would be wonderful thing.
Using it for small amounts of data is pretty useless - I totally agree
but when it comes to huge amounts of data it can be useful.
It is a mechanism for huge installations with a lot of data.
Hans
>That was a fork IIRC. Threading is not used in baseline PostgreSQL nor
>is there any such plans that I'm aware of. People from time to time ask
>about threads for this or that and are always told what I'm telling
>you. The use of threads leads to portability issues not to mention
>PostgreSQL is entirely built around the process model.
>
>Tom is right to dismiss the notion of adding additional CPUs to
>something that is already I/O bound, however, the concept it self should
>not be dismissed. Applying multiple CPUs to a sort operation is well
>accepted and understood technology.
>
>At this point, perhaps Tom or one of the other core developers having
>insight in this area would be willing to address how readily such a
>mechanism could could be put in place.
>
>Also, don't be so fast to dismiss what the process model can do. There
>is not reason to believe that having a process pool would not be able to
>perform wonderful things if implemented properly. Basically, the notion
>would be that the backend processing the query would solicit assistance
>from the sort pool if one or more processes were available. At that
>point, several methods could be employed to divide the work. Some form
>of threshold would also have to be created to prevent the pool from
>being used when a single backend is capable of addressing the need.
>Basically the idea is, you only have the pool assist with large tuple
>counts and then, only when resources are available and resource are
>available from within the pool. By doing this, you avoid additional
>overhead for small sort efforts and gain when it matters the most.
>
>
>Regards,
>
> Greg
>
>
>
--
*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>
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Copeland | 2002-10-04 15:44:48 | Re: Threaded Sorting |
Previous Message | Greg Copeland | 2002-10-04 15:22:28 | Re: Threaded Sorting |