Comments 11
вопросы:
1. Если сейчас у нас стандартно есть один скан на сервере выполняется за время Х, при паралельном скане — он выполняется быстрее, но как я понимаю — уже при паралелизме в 5 прироста дальнейшего нет. Означает ли это, что если у нас есть 4-5 или больше одновременных запросов со сканами на сервере — то включение паралелизма не ускорит процесс?

2. Как на счет параллел сорт???
3. Как на счет параллел индекс скан?
4. При джоинах — есть ли выйгрышь, если джоийним с фулсканами??
В теории, если у вас работает одновременно 5 запросов на сервере при включении например: set max_parallel_degree = 4; и при условии что у вас 4 ядра, ресурсы должны распределиться на 4 ядра и запросы должны выполняться быстрее.
Что касается сортировок агрегаций и index scan – то скорее всего разработчики будут над ними работать в будущем, но пока этого нет.
вообще я как-то смутно представляю себе связь скорости фулскана и количества ядер. У меня все в голове в диски упирается.
Спасибо!!! Очень нужная вещь. Открываются новые возможности для PostgreSQL в аналитических запросах.
Очень люблю PostgreSQL, но, как мне кажется, зря он пошёл в этом направлении.

Существуют аналитические СУБД, которые изначально были построены с расчетом на параллельное выполнение запросов на множестве ядер или даже множестве серверов. Там всё заточено под это: и способ хранения, и компрессия, и протоколы, и планы выполнения.

А тут такой Постгрес выходит и говорит, что он теперь поддерживает 5% подобных функций, а через годик-другой будет поддерживать 20%. И то путём титанических усилий по переделке ядра, которое никогда не задумывалось для параллельного выполнения.

Ну и какой практический смысл в этом? Я бы лучше сконцентрировался на том, в чём PG по-настоящему силён, а аналитику оставил бы для специализированных продуктов.
Зря вы так, популярные аналитические продукты Vertica, Gpreenplum, netezza, Postgres-XL и т.п. базируются на PG. Они то уж найдут этой фиче применения в будущем.
ну так они уже ушли далеко вперед. О чем и речь, в них уже все это есть. Паралельный и скан и сорт и поиск и группировка и джоины!!!
Т.е. в общем-то это либо PG будет у них заимствовать, либо будет просто их догонять.
Да, но там эта задача решается запуском сразу нескольких инстансов postgresql на одной ноде. Например хотите что бы на каждом узле распараллеливание было равно 5 — запускается 5 postgresql серверов на ноде и каждый молотит свой кусок данных.
У такого подхода есть свои минусы, накладные расходы, нельзя «на лету» менять степень параллелизма.
верно, но степень параллелизма и так уже достаточна. Пример — наша база, 24 физических сервера и на каждом 4 инстанса (+4 резервных) = 96 степень параллелизма. Это и так весьма немало. Уже сейчас узкое место — межсетевой обмен данными на нодах.
А какая СУБД если не секрет? И на что похожа модель данных?
P.S.: Не вижу больших проблем с межсетевым обменом при правильном моделировании структуры.
Only those users with full accounts are able to leave comments. Log in, please.