At 04:39 PM 07-02-2002 -0500, mlw wrote:
>
>There are, AFAIK two reasons to thread PostgreSQL:
>
>(1) Run the multiple connections in their own thread with the assumption
>that this is more efficient for [n] reasons.
>(2) Run a single query across multiple threads, thus parallelizing the
>query engine.
>
>There is a mutant of this as well: (1a) You could have multiple
>processes each with [n] connection threads.
>
>As far as PostgreSQL is concerned, I am dubious that (1) or (1a) will
>provide any real benefit for the amount of work required to accomplish
>it. Work on "pre-forking" would be FAR more productive.
>
>The idea of parallelizing queries could be very worth while. However,
>that being said, creating a set of I/O threads that get blocks from disk
>devices asynchronously, my be enough with a very limited amount of work.
2) seems to be the only good argument for threads so far. 1) may only be
true on certain O/Ses.
That said, are those large single queries typically CPU bound or IO bound
or neither?
If they are IO bound then given my limited understanding it is not easy to
see how spreading the query over additional CPUs is going to help.
I suggest that work on clustering postgresql may result in a more scalable
general solution than threaded postgresql. Looks to be more difficult, but
the benefits seem more tangible.
Cheerio,
Link.