current_timestamp () кэширует результаты в предложении WHERE. Это ожидаемое поведение? - PullRequest
Новая
       30

current_timestamp () кэширует результаты в предложении WHERE. Это ожидаемое поведение?

1 голос
/ 16 июня 2020

В Esper онлайн (8.5 - https://esper-epl-tryout.appspot.com/epltryout/mainform.html) Кажется, что однорядный метод current_timestamp () действует как кэшированный, когда он присутствует в разделе WHERE. Я не помню этого поведения раньше (я думаю, что оно переоценивается с каждым событием).

т.е. дано: 

create schema iotEvent(id string, type string, value double);

SELECT current_timestamp().getSecondOfMinute()%2 as zeroorone 
FROM iotEvent 
WHERE current_timestamp().getSecondOfMinute()%2=0

и следующий поток событий: 

iotEvent={id='A', type="pump", value=1.0}
t=t.plus(1 sec)
iotEvent={id='B', type="dump", value=12.0}
t=t.plus(1 sec)
iotEvent={id='C', type="pump", value=4.0}
t=t.plus(1 sec)
iotEvent={id='A', type="dump", value=15.0}
t=t.plus(1 sec)
iotEvent={id='B', type="pump", value=2.0}
t=t.plus(1 sec)
iotEvent={id='A', type="dump", value=3.0}

"zeroorone" в списке выбора итерации значений 0,1,0,1, ... как и ожидалось, но выражение where просто принимает 0 или 1 в зависимости от исходного результата события. В данном случае 0 (так что он соответствует все время).

С другой стороны: 

SELECT current_timestamp().getSecondOfMinute()%2 as zeroorone 
    FROM iotEvent 
    WHERE current_timestamp().getSecondOfMinute()%2=1

Никогда не совпадает.

Мы не видим такого поведения в наши развертывания Esper (версия 7). Изменилось ли что-нибудь в политиках кеширования однострочных методов 8.5? Это желаемое поведение?

Спасибо!

1 Ответ

0 голосов
/ 17 июня 2020

Вероятно, это ошибка из-за более агрессивного планирования индекса фильтра. Ссылка do c - это Анализ выражений фильтра компилятора . Это можно отключить в настройках компилятора.

...