В СУБД PostgreSQL добавлена поддержка распараллеливания запросов
Оригинал взят у mshurutov в В СУБД PostgreSQL добавлена поддержка распараллеливания запросов
Новость, однако с опеннета.
В экспериментальную ветку, на базе которой будет формироваться релиз PostgreSQL 9.6, приняты изменения с реализацией распараллеливания операций последовательного сканирования записей (Sequential Scan), используемых для перебора значений в случае выборки по непроиндексированным полям или при манипуляциях с содержимым полей. Перебор в несколько параллельных потоков позволит существенно увеличить скорость перебора данных на системах с большим числом процессорных ядер. Выигрыш особенно заметен для ресурсоёмких запросов, таких как сопоставление по регулярным выражениям.
Например, выполнение тестового запроса "select * from pgbench_accounts where filler like '%a%'" в обычных условиях занимает 743 мс, в то время как при распараллеливании в четыре потока - 213 мс. При распараллеливании операция сканирования разбивается на части и каждая часть разбирается отдельным обработчиком, после чего результаты работы каждого обработчика объединяются.
Годная, с одной стороны новость, а вот с другой... Распараллеливание GROUP BY, CASE и всего такого прочего - оно было бы совсем хорошо. Кто что думает, уважаемые коллеги?
Новость, однако с опеннета.
В экспериментальную ветку, на базе которой будет формироваться релиз PostgreSQL 9.6, приняты изменения с реализацией распараллеливания операций последовательного сканирования записей (Sequential Scan), используемых для перебора значений в случае выборки по непроиндексированным полям или при манипуляциях с содержимым полей. Перебор в несколько параллельных потоков позволит существенно увеличить скорость перебора данных на системах с большим числом процессорных ядер. Выигрыш особенно заметен для ресурсоёмких запросов, таких как сопоставление по регулярным выражениям.
Например, выполнение тестового запроса "select * from pgbench_accounts where filler like '%a%'" в обычных условиях занимает 743 мс, в то время как при распараллеливании в четыре потока - 213 мс. При распараллеливании операция сканирования разбивается на части и каждая часть разбирается отдельным обработчиком, после чего результаты работы каждого обработчика объединяются.
Годная, с одной стороны новость, а вот с другой... Распараллеливание GROUP BY, CASE и всего такого прочего - оно было бы совсем хорошо. Кто что думает, уважаемые коллеги?