Коротко о потреблении памяти в #Greenplum.

Greenplum очень "жадно" выделяет оперативу для запросов. Главный параметр, на который он ориентируется, это concurrency в ресурсной группе. Если в дефолт группе стоит concurrency=10 и прилетает 2-3 тяжелых запроса, он не выделит много памяти, так как ждет еще 10 подключений.

На картинке иллюстрация прогона пака запросов из репозитория.

Прогон в 3 вариантах.

1. 32 GB памяти на сегмент concurrency=10. Выделено ок. 3 ГБ

2. 32 GB памяти на сегмент, concurrency=4. Выделено ок. 6 ГБ

3. 64 GB памяти на сегмент, concurrency=4. Выделено ок. 21 ГБ.

Пак запросов с транзакциями эфира - до 4 млрд строк.

Простое уменьшение параллелизма приводит к увеличению эффективной памяти в 2 раза. Хотя казалось бы, других запросов нет и 80% shared_quota.

Увеличение памяти ВМ в 2 раза ведет к увеличению эффективной памяти в 3,5 раза. Эффект нелинейный. Хотя казалось бы, свободной памяти более 50%

Какие выводы

Если есть тяжелые запросы, обязательно выделите ресурсную группу с малым concurrency и отдавайте их туда.
Это актуально для ELT и для Ad-Hoc.

Также полезно научиться переносить запросы внутри сессии между рес. группами.