Is this just syntactic sugar, then?
Is this:
SELECT device_id, timevector(ts, val) -> sort() -> delta() -> abs() -> sum() as volatility
the same as this?
SELECT device_id, sum(abs(delta(sort(timevector(ts, val))))) as volatility
Is this:
SELECT device_id, timevector(ts, val) -> sort() -> delta() -> abs() -> sum() as volatility
the same as this?
SELECT device_id, sum(abs(delta(sort(timevector(ts, val))))) as volatility
Kinda. It's close to that, except in order to make it do that we had to actually make the functions return special types so it's more equivalent to something like
SELECT device_id, apply(sum, apply(abs, apply(delta, apply(sort, timevector(ts, val))))))
Where each of the items in there is an instance of our special "PipelineElement" type, which defines the function it's applying.
Does that make any sense at all? Not sure if I'm explaining this well...
Would you say that the reduced flexibility of the query planner --- if I am right about that --- is not important to the target use cases of Timescale? I guess typical timeseries data models are a well understood subset of all relational data models. Therefore the set of useful plans is smaller than usual, I guess.