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

(NB Post author)

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...

Am I right, that functional pipelines substantially decreases the possibilities of the query planner to consider different plans for execution? I am a long-term functional programmer and avid user of advanced PostgreSQL features. But I've always looked at this dichotomy the other way around. How to bring the capability to choose implementations dynamically based on actual statistics to functional programming?

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.

It does make sense. Thanks.