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