Hacker News new | ask | show | jobs
by Lockerman 1698 days ago
(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 operator support.

https://news.ycombinator.com/item?id=28920110
1 comments
ccleve 1698 days 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

link
djk447 1697 days 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...

link
funcDropShadow 1697 days 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.

link
ccleve 1697 days ago
It does make sense. Thanks.
link