Comments 8
Поясните пож-та, что значит "receipt_dttm для чека уникально" - то есть для всех товаров в одном чеке время одинаково? Также по "receipt_id относится только к одному магазину" - все товары в одном чеке относятся к одному магазину?
Я про greenplum ничего не знаю) Перераспределение внутри запроса - это считается нормальная практика? Терабайты гоняются по сети каждый раз при запросе, не выглядит оптимальным.
А если другой человек другой запрос выполнит, снова перераспределение? А если это параллельно.
Добрый день
"receipt_dttm для чека уникально" - то есть для всех товаров в одном чеке время одинаково? Да, одно значение даты времени для одного чека
Также по "receipt_id относится только к одному магазину" - это означает, что значения receipt_id не пересекается в рамках нескольких магазинов. По сути (receipt_id, plu_id) - PK
Перераспределение внутри запроса - это считается нормальная практика? Если перераспределение не удается избежать делается перераспределение.
Практика нормальная Greenplum это про OLAP нагрузку и количество активных пользователей обычно ограничено.
Если запрос такой проблемный, а число уникальных чеков аддитивно по дням и ТК, то почему бы не сделать пред агрегат по store_id, calendar_dk, plu_group_id и обновлять только дельту дней, которая явно меньше месяца, а в отчете брать сумму за нужный период и нужные ТК?
plu_group_id и store_group_id это входящие в запрос параметры. Можно по разному подготовить группы магазинов и группы товаров. В данном случае пред агрегат не рабочее решение.
Кейс оптимизации запросов для Greenplum