davidkohn88

> Let's not merge this before we are sure there are no performance regressions, since we're presenting performance numbers for 2.7.0 and we wouldn't want to risk invalidating them this...

The simple way to do this is to write the following sort of join: ```SQL CREATE TABLE foo ( time timestamptz, id int, val double precision); CREATE INDEX on foo(id,...

> I am also very interested in this "as_of" join, what would be the best solution for now? The joins above ( https://github.com/timescale/timescaledb/issues/271#issuecomment-865231568) are reasonable solutions for now and should...

I think this is most likely related to the parse/bind inefficiency: https://github.com/timescale/timescaledb/blob/10b3da03ec207a153f01b569879608df4c50698a/tsl/src/data_node_dispatch.c#L195 Note that we generate predefined prepared statements and both generating them on the access and parsing them on...

Ugh. Well, that's annoying. I wonder if a custom serialization type that wasn't an array and an unpacking function that had the proper information would work? It'd follow the same...

Yea...those array functions leave a lot to be desired. And the behaviour of all multi-dimensional arrays is truly weird. It'd either be a container type, we could do this for...

That's true, but the `ON CONFLICT` case is incredibly important, a lot of people use it and it's a huge benefit to the product. The other options are all much,...

While I appreciate the concerns from @fabriziomello and @gayyappan, and I agree that some of these are weird edge cases, I think that these checks are entirely unnecessary and potentially...

These may be safely disregarded for now, it's a bit difficult to remove the messages as they are multi-line and determining whether the warnings are ones that can be disregarded...

There are already some functions that do this, but for me, I think I'd prefer something simpler as a starting point that didn't have so many damn options namely, `interval_to_seconds`...