Re: Threaded Sorting
От | Greg Copeland |
---|---|
Тема | Re: Threaded Sorting |
Дата | |
Msg-id | 1033746289.13005.59.camel@mouse.copelandconsulting.net обсуждение исходный текст |
Ответ на | Threaded Sorting (Hans-Jürgen Schönig <postgres@cybertec.at>) |
Список | 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
В списке pgsql-hackers по дате отправления: