Re: Threaded Sorting

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>

In response to

Responses

Browse pgsql-hackers by date

  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