Re: getting the most of out multi-core systems for repeated complex SELECT statements
В списке pgsql-performance по дате отправления:
| От | Vitalii Tymchyshyn |
|---|---|
| Тема | Re: getting the most of out multi-core systems for repeated complex SELECT statements |
| Дата | |
| Msg-id | 4D4FC351.4000105@gmail.com обсуждение исходный текст |
| Ответ на | Re: getting the most of out multi-core systems for repeated complex SELECT statements (Chris Browne <cbbrowne@acm.org>) |
| Список | pgsql-performance |
Hi, all My small thoughts about parallelizing single query. AFAIK in the cases where it is needed, there is usually one single operation that takes a lot of CPU, e.g. hashing or sorting. And this are usually tasks that has well known algorithms to parallelize. The main problem, as for me, is thread safety. First of all, operations that are going to be parallelized, must be thread safe. Then functions and procedures they call must be thread safe too. So, a marker for a procedure must be introduced and all standard ones should be checked/fixed for parallel processing with marker set. Then, one should not forget optimizer checks for when to introduce parallelizing. How should it be accounted in the query plan? Should it influence optimizer decisions (should it count CPU or wall time when optimizing query plan)? Or can it simply be used by an operation when it can see it will benefit from it. Best regards, Vitalii Tymchyshyn
В списке pgsql-performance по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера