Комментарии 11
вопросы:
1. Если сейчас у нас стандартно есть один скан на сервере выполняется за время Х, при паралельном скане — он выполняется быстрее, но как я понимаю — уже при паралелизме в 5 прироста дальнейшего нет. Означает ли это, что если у нас есть 4-5 или больше одновременных запросов со сканами на сервере — то включение паралелизма не ускорит процесс?
2. Как на счет параллел сорт???
3. Как на счет параллел индекс скан?
4. При джоинах — есть ли выйгрышь, если джоийним с фулсканами??
1. Если сейчас у нас стандартно есть один скан на сервере выполняется за время Х, при паралельном скане — он выполняется быстрее, но как я понимаю — уже при паралелизме в 5 прироста дальнейшего нет. Означает ли это, что если у нас есть 4-5 или больше одновременных запросов со сканами на сервере — то включение паралелизма не ускорит процесс?
2. Как на счет параллел сорт???
3. Как на счет параллел индекс скан?
4. При джоинах — есть ли выйгрышь, если джоийним с фулсканами??
+1
В теории, если у вас работает одновременно 5 запросов на сервере при включении например: set max_parallel_degree = 4; и при условии что у вас 4 ядра, ресурсы должны распределиться на 4 ядра и запросы должны выполняться быстрее.
Что касается сортировок агрегаций и index scan – то скорее всего разработчики будут над ними работать в будущем, но пока этого нет.
Что касается сортировок агрегаций и index scan – то скорее всего разработчики будут над ними работать в будущем, но пока этого нет.
0
Спасибо!!! Очень нужная вещь. Открываются новые возможности для PostgreSQL в аналитических запросах.
0
Очень люблю PostgreSQL, но, как мне кажется, зря он пошёл в этом направлении.
Существуют аналитические СУБД, которые изначально были построены с расчетом на параллельное выполнение запросов на множестве ядер или даже множестве серверов. Там всё заточено под это: и способ хранения, и компрессия, и протоколы, и планы выполнения.
А тут такой Постгрес выходит и говорит, что он теперь поддерживает 5% подобных функций, а через годик-другой будет поддерживать 20%. И то путём титанических усилий по переделке ядра, которое никогда не задумывалось для параллельного выполнения.
Ну и какой практический смысл в этом? Я бы лучше сконцентрировался на том, в чём PG по-настоящему силён, а аналитику оставил бы для специализированных продуктов.
Существуют аналитические СУБД, которые изначально были построены с расчетом на параллельное выполнение запросов на множестве ядер или даже множестве серверов. Там всё заточено под это: и способ хранения, и компрессия, и протоколы, и планы выполнения.
А тут такой Постгрес выходит и говорит, что он теперь поддерживает 5% подобных функций, а через годик-другой будет поддерживать 20%. И то путём титанических усилий по переделке ядра, которое никогда не задумывалось для параллельного выполнения.
Ну и какой практический смысл в этом? Я бы лучше сконцентрировался на том, в чём PG по-настоящему силён, а аналитику оставил бы для специализированных продуктов.
0
Зря вы так, популярные аналитические продукты Vertica, Gpreenplum, netezza, Postgres-XL и т.п. базируются на PG. Они то уж найдут этой фиче применения в будущем.
0
ну так они уже ушли далеко вперед. О чем и речь, в них уже все это есть. Паралельный и скан и сорт и поиск и группировка и джоины!!!
Т.е. в общем-то это либо PG будет у них заимствовать, либо будет просто их догонять.
Т.е. в общем-то это либо PG будет у них заимствовать, либо будет просто их догонять.
0
Да, но там эта задача решается запуском сразу нескольких инстансов postgresql на одной ноде. Например хотите что бы на каждом узле распараллеливание было равно 5 — запускается 5 postgresql серверов на ноде и каждый молотит свой кусок данных.
У такого подхода есть свои минусы, накладные расходы, нельзя «на лету» менять степень параллелизма.
У такого подхода есть свои минусы, накладные расходы, нельзя «на лету» менять степень параллелизма.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Параллельный Sequential Scan Commited