NB: I work at Timescale. TimescaleDB is a PostgreSQL extension, just to be clear.
Disclosure, I work at Timescale. We are kindred spirits I think! I did this too [0] a while back at a previous company and it actually served as part of the inspiration for our compression work! It's fun, but a bit…
Disclosure, I work at Timescale. Though I didn't write this post, I'd imagine at least part of it is that it's already nearly 4000 words and a 15 minute read and we just didn't want to add another set of things to it,…
And glad you liked the article!
NB: Post author So we thought about doing something like that with multinode where each of the nodes would maintain their own materialization but abandoned it for that very reason it’s very, very difficult to maintain…
NB: Post author Yes. this is generally handled automatically, there may be times though where you want to essentially pause refreshing the view for a while while you do some backfilling and then eventually let it catch…
NB: Post author I'm not 100% sure I understand what you're asking, but essentially something that would look for data modifications and at query time run the query over the older regions as well? If that's what you're…
NB: post author here! Thanks yes! Totally true, was thinking about including some of that but it felt like it opened a can of worms about join types and why certain things would be included and others not (ie inner join…
NB - Timescale person here. Totally true! It's also a much harder problem :) One of the things that we try to focus on at Timescale is figuring out how we can simplify problems based on the specific needs of time-series…
Totally fair and something that I'm actually forming a team to work on! We're starting with some very foundational material [1], that may well be review and it's not as formal / professional as Mongo University or the…
(NB: Post author here) Glad you liked it! Please do give us feedback especially about how it is to use with your library…will be intrigued to see how they interact. Also , cool to hear about the library more generally,…
(NB: Post author here!) This is all true! We have a bit more info on that choice in this post [1]. But in general the Toolkit extension [2] is meant to have a bit of a lighter touch than the core TimescaleDB extension…
Sorry I missed before was out grabbing lunch, answered above!
(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,…
The docs have a bit more on it [1]. The $$ is really just a dollar quoted string[2], you can use any sort of string in there, but dollar quoting just makes it a lot easier to read. On your other question, not right now,…
(NB: post author here) Yep! you got it exactly right! We're doing it for syntax first and then hopefully go back and start doing interesting performance optimizations on top. There are definitely some things we're…
(NB: Post author here) Yeah. It's a bit mind bending I guess. Will try to explain but might just need a longer format thing and we will probably do a piece on this in the future. Essentially, each function returns a…
(NB: Post author here) This is in the TimescaleDB Toolkit extension [1] which is licensed under our community license for now and it's not available on DO. It is available on our cloud service fully managed. You can…
(NB: post author here) We're planning on providing various outputs, json is definitely one format we'd want to support, want to file a github issue with the layout that you'd want and we can start getting some feedback…
(NB: Post author here) We're thinking about doing a post on them at some point in the future! Any specific questions we should answer?
(NB: Post author here) Yeah. CTEs definitely make it a bit easier to read, though some people get more confused by them, especially because they don't exist in all SQL variants. And totally agree with that last bit! We…
(NB: Post author here) So this is a great question and we may do a whole post on this at some point in the future. There are definitely ways to shoot yourself in the foot, but hopefully we can avoid at least some of…
(NB: Post author here) Totally understand the concern, for now, it’s just for a particular datatype, all of the other operations are happening normally inside your query and you can still use window functions... And…
(NB: Post author here) Yes! You can use the `delta()` element followed by a `filter()` with a lambda for looking for negative numbers I think!
(NB: Post author here) We don't have many Haskell programmers, we mostly work in Rust, C and Go, but we're always open to new things... This is pretty Postgres specific. From the beginning Postgres has focused on…
NB: I work at Timescale. TimescaleDB is a PostgreSQL extension, just to be clear.
Disclosure, I work at Timescale. We are kindred spirits I think! I did this too [0] a while back at a previous company and it actually served as part of the inspiration for our compression work! It's fun, but a bit…
Disclosure, I work at Timescale. Though I didn't write this post, I'd imagine at least part of it is that it's already nearly 4000 words and a 15 minute read and we just didn't want to add another set of things to it,…
And glad you liked the article!
NB: Post author So we thought about doing something like that with multinode where each of the nodes would maintain their own materialization but abandoned it for that very reason it’s very, very difficult to maintain…
NB: Post author Yes. this is generally handled automatically, there may be times though where you want to essentially pause refreshing the view for a while while you do some backfilling and then eventually let it catch…
NB: Post author I'm not 100% sure I understand what you're asking, but essentially something that would look for data modifications and at query time run the query over the older regions as well? If that's what you're…
NB: post author here! Thanks yes! Totally true, was thinking about including some of that but it felt like it opened a can of worms about join types and why certain things would be included and others not (ie inner join…
NB - Timescale person here. Totally true! It's also a much harder problem :) One of the things that we try to focus on at Timescale is figuring out how we can simplify problems based on the specific needs of time-series…
Totally fair and something that I'm actually forming a team to work on! We're starting with some very foundational material [1], that may well be review and it's not as formal / professional as Mongo University or the…
(NB: Post author here) Glad you liked it! Please do give us feedback especially about how it is to use with your library…will be intrigued to see how they interact. Also , cool to hear about the library more generally,…
(NB: Post author here!) This is all true! We have a bit more info on that choice in this post [1]. But in general the Toolkit extension [2] is meant to have a bit of a lighter touch than the core TimescaleDB extension…
Sorry I missed before was out grabbing lunch, answered above!
(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,…
The docs have a bit more on it [1]. The $$ is really just a dollar quoted string[2], you can use any sort of string in there, but dollar quoting just makes it a lot easier to read. On your other question, not right now,…
(NB: post author here) Yep! you got it exactly right! We're doing it for syntax first and then hopefully go back and start doing interesting performance optimizations on top. There are definitely some things we're…
(NB: Post author here) Yeah. It's a bit mind bending I guess. Will try to explain but might just need a longer format thing and we will probably do a piece on this in the future. Essentially, each function returns a…
(NB: Post author here) This is in the TimescaleDB Toolkit extension [1] which is licensed under our community license for now and it's not available on DO. It is available on our cloud service fully managed. You can…
(NB: post author here) We're planning on providing various outputs, json is definitely one format we'd want to support, want to file a github issue with the layout that you'd want and we can start getting some feedback…
(NB: Post author here) We're thinking about doing a post on them at some point in the future! Any specific questions we should answer?
(NB: Post author here) Yeah. CTEs definitely make it a bit easier to read, though some people get more confused by them, especially because they don't exist in all SQL variants. And totally agree with that last bit! We…
(NB: Post author here) So this is a great question and we may do a whole post on this at some point in the future. There are definitely ways to shoot yourself in the foot, but hopefully we can avoid at least some of…
(NB: Post author here) Totally understand the concern, for now, it’s just for a particular datatype, all of the other operations are happening normally inside your query and you can still use window functions... And…
(NB: Post author here) Yes! You can use the `delta()` element followed by a `filter()` with a lambda for looking for negative numbers I think!
(NB: Post author here) We don't have many Haskell programmers, we mostly work in Rust, C and Go, but we're always open to new things... This is pretty Postgres specific. From the beginning Postgres has focused on…