немного другой логикой:
Например для if вычисляется сложное знаение, потом сравнивается условие и если оно выполнено, взять вычиленное значение, если не выполнено взять дефолт
Проблема простого if в двойном вычислении.
Например if (number > 17, 10, number)
Вот если nubmer это что-то сложно вычисляемое, можно ли вычислить его 1 раз, прихранить, потом проверить if и потом не считать второй раз в else?
вообще если number выражение даст константу то with можно юзать
with не хранит, при каждом обращении к with будет высчитываться
А это везде так или только у кликхауса?
точно не везде. Postgres по моему матерелизует with Oracle с хинтом тоже
Можно попробовать использовать transform, вместо if. Был опыт его успешного применения под аналогичную задачу
Хотя, пожалуй, под Вашу задачу не выйдет. Но если если все сводится к var number = сложное вычисление if (number > 10) { number = 10 } то кажется, можно обойтись просто least(number, 10)?
Идеально подходит, спасибо)
если у вас вычисление простое типа примера, то делайте двойное вычисление, оно быстрее. костыли имеют смысл если у вас супер multiIf на 500 условий, или вложенные If на 5-10 уровней со сложной математикой/лямбдами
Там вычисление времени между датами, и если оно превышает 30 минут то взять 30 минут, если меньше то взять существующее. Вот выше подсказали least, выглядит лучшим решением)
все правильно вам подсказали
а с чего бы это оно вычисляется два раза? Вы проверяли? Вроде как должно быть 1 раз. Особенно если это явно попросить - if(number > 17, 10, (a+b/c) as number) Можно сделать 1000 раз with/without AS и сравнить.
не проверял, не придемал как проверить, отсюда и вопрос был, но ответ нашелся проще, мне нужно было просто меньшее число и подошла функция least
PostgreSQL начиная с версий 12.х материализует WITH только при явном добавлении указания MATERIALIZED. Поведение по умолчанию же — сворачивание WITH в родительский запрос ("инлайнится", грубо говоря). Однако, это стандартное поведение не выполняется в ряде случаев, информация об этом будет доступна в EXPLAIN. Также возможно и принудительное сворачивание через NOT MATERIALIZED. // Это, конечно же, приведено для информации и никак не противоречит вашему утверждению о том, что "точно не везде" ;)
Обсуждают сегодня