да, я почему то подумал что он что-то не то возвращает, но нет логика одинаковая и правильная везде... а то что вместо групинг() всякие слова параметры, так это "наследие"

Спасибо большое за примеры и дискуссию!🙂 я понимаю логику, порядок выполнения операторов, но я не согласна с тем, что она правильная) точнее не представляю usecase для данных, полученных комбинацией rollup и having в текущей логике. По отдельности все понятно: есть таблица с суммами, есть having, есть отфильтрованный результат. Опять же есть таблица с суммами, есть rollup, есть результат с промежуточными итогами. А вот зачем брать этот результат с промежуточными итогами и часть записей из него выкидывать? В этом случае итоги перестают быть итогами, не?

В любом случае спасибо еще раз!! Дискуссия не для вечера воскресенья, сорри😀

Да, давайте переделаем sql стандарт! Viva la revolucion

Да ну ладно!😀

Нене. давайте сделаем warp drive слетаем в 1998 и расскажем им как надо

>А вот зачем брать этот результат с промежуточными итогами и часть записей из него выкидывать?

чтобы можно было выкидывать по сложным условиям
например (grouping(a) and grouping(b)) and having(sum(c))>100

Убедили!!

серьезно, вот мы такое используем, причем генерирует приложение, а вы говорите уберем это )

Беру свои слова обратно! Я серьезно

Я ограниченно мыслю😬

поздно, мой сарказмохейтеромет расчехлен =)

Да ладно! Вы добрый😀

сделайте уже ишшю на warp drive =) может можно будет слетать и хотя бы передать им технологии памяти и у нас будет достаточно, чтобы мы могли хешджойнить по человечески )))

а то у меня уже partition-wise join issue готовился =)

Я реально не понимаю почему хеш таблицы столько памяти жрут и в словарях и в джойнах и я спрашивал неоднократно в дев чатике. Так вот разразбы кх не понимают почему хеш таблицы должны жрать меньше.

руки дойдут, попрошу сделать  пример хеш джойна в оракле, просто сравнить... там все очень плохо на стороне КХ

просто мы джойним две таблицы фактов хешами и оно ну вообще жрет мизер поверх реально самих данных

ну и партишнwise hash-join - это must-have

Тип данные из одной партиции считываются в хеш-таблицу,а другая партиция к этой таблице джойнится?

да, например таблицы
table1: partitionkey(date) pk datetime, customer
table2: partitionkey(date) pk datetime, customer, order


table2 join table1 using
(date, customer)

будет браться первый сет партишнов из table1 -> hash build -> hash probe из первого партишн table2 в зависимости от памяти (доступной и требуемой)

А UNION интересно как работает по очереди?