Re: Threaded Sorting

From: Greg Copeland <greg(at)CopelandConsulting(dot)Net>
To: Hans-Jürgen Schönig <hs(at)cybertec(dot)at>
Cc: PostgresSQL Hackers Mailing List <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Threaded Sorting
Date: 2002-10-04 15:44:48
Message-ID: 1033746289.13005.59.camel@mouse.copelandconsulting.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 2002-10-04 at 10:37, Hans-Jürgen Schönig wrote:
> 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.

Yes, that's the point of having a pool. The idea is not only do you
avoid process creation and destruction which is notoriously expensive on
many platforms, they would sit idle until signaled to begin working on
it's assigned sort operation. Ideally, these would be configurable
options which would include items such as, pool size (maximum number of
processes in the pool), max concurrency level (maximum number of process
from the pool which can contribute to a single backend) and tuple count
threshold (threshold which triggers solicition for assistance from the
sort pool).

> 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

Agreed. Thus the importance of being able to specify some type of
meaningful threshold.

Any of the core developers wanna chime in here on this concept?

Greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-10-04 15:48:33 Re: Potential Large Performance Gain in WAL synching
Previous Message Hans-Jürgen Schönig 2002-10-04 15:37:16 Re: Threaded Sorting