Re: Multi CPU Queries - Feedback and/or suggestions wanted!
| От | Jeffrey Baker |
|---|---|
| Тема | Re: Multi CPU Queries - Feedback and/or suggestions wanted! |
| Дата | |
| Msg-id | fd145f7d0810202225p30f6191cv33b05da0a0142085@mail.gmail.com обсуждение исходный текст |
| Ответ на | Multi CPU Queries - Feedback and/or suggestions wanted! (Julius Stroffek <Julius.Stroffek@Sun.COM>) |
| Ответы |
Re: Multi CPU Queries - Feedback and/or suggestions wanted!
Re: Multi CPU Queries - Feedback and/or suggestions wanted! |
| Список | pgsql-hackers |
On Mon, Oct 20, 2008 at 12:05 PM, Julius Stroffek <Julius.Stroffek@sun.com> wrote:
I don't see why multiple CPUs can't work on the same node of a plan. For instance, consider a node involving a scan with an expensive condition, like UTF-8 string length. If you have four CPUs you can bring to bear, each CPU could take every fourth page, computing the expensive condition for each tuple in that page. The results of the scan can be retired asynchronously to the next node above.
-jwb
Topics that seem to be of interest and most of them were already
discussed at developers meeting in Ottawa are
1.) parallel sorts
2.) parallel query execution
3.) asynchronous I/O
4.) parallel COPY
5.) parallel pg_dump
6.) using threads for parallel processing
[...]
2.)
Different subtrees (or nodes) of the plan could be executed in parallel
on different CPUs and the results of this subtrees could be requested
either synchronously or asynchronously.
I don't see why multiple CPUs can't work on the same node of a plan. For instance, consider a node involving a scan with an expensive condition, like UTF-8 string length. If you have four CPUs you can bring to bear, each CPU could take every fourth page, computing the expensive condition for each tuple in that page. The results of the scan can be retired asynchronously to the next node above.
-jwb
В списке pgsql-hackers по дате отправления: