Lockerman

5 ms·

1. 1.▲
   by Lockerman 5y ago

   Timescale engineer here The initial drive for this was some of the work we did on Promscale, along with some observations I made when experimenting with potential optimizations for compression. We saw that a bunch of workloads involved expo
2. 2.▲
   by Lockerman 5y ago

   Not yet, right now all datapoints must be known at the during the sort
3. 3.▲
   by Lockerman 5y ago

   > Oh or I see timevector returns a custom datatype, so I suppose the answer is it has to be one of a fixed number of provided types? Exactly! These aren't general arithmetic operators, they're specifically for mapping arithmet
4. 4.▲
   by Lockerman 5y 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=2892011
5. 5.▲
   by Lockerman 5y ago

   a separate implementation
6. 6.▲
   by Lockerman 6y ago

   Timescale engineer here. I'm betting we'll see a nice win; we tend to see write-mostly workloads the UNDO shouldn't be too expensive, and the smaller tuple sizes should be nice. We've built Timescale to be compatible wit
7. 7.▲
   by Lockerman 7y ago

   Hi, Timescale engineer here, do you happen to remember around when/in what version you ran into this bug?