Greg Copeland <[EMAIL PROTECTED]> writes:
> ... I can understand why
> addressing the seemingly more common I/O bound case would receive
> priority, however, I'm at a loss as to why the other would be completely
> ignored.
Bruce already explained that we avoid threads because of portability and
robustness considerations.
The notion of a sort process pool seems possibly attractive. I'm
unconvinced that it's going to be a win though because of the cost of
shoving data across address-space boundaries. Another issue is that
the sort comparison function can be anything, including user-defined
code that does database accesses or other interesting stuff. This
would mean that the sort auxiliary process would have to adopt the
database user identity of the originating process, and quite possibly
absorb a whole lot of other context information before it could
correctly/safely execute the comparison function. That pushes the
overhead up a lot more.
(The need to allow arbitrary operations in the comparison function would
put a pretty substantial crimp on a thread-based approach, too, even if
we were willing to ignore the portability issue.)
Still, if you want to try it out, feel free ... this is an open-source
project, and if you can't convince other people that an idea is worth
implementing, that doesn't mean you can't implement it yourself and
prove 'em wrong.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
