9 ms·

(Timescale engineer here) To summarize a bit on what David said here[1]: there are no modifications to the query engine, this is all using Postgres's custom op

• ccleve 5y ago
  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
  • djk447 5y ago
    (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...
    • funcDropShadow 5y ago
      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.
    • ccleve 5y ago
      It does make sense. Thanks.