Interesting that they opted for a relational rather than a categorical one; the latter is proving to be more flexible [0]. [0] https://www.categoricaldata.net/
Not sure it's comparable to something like Amazon, that has probably dedicated funding.
11–20 of 88 posts
Interesting that they opted for a relational rather than a categorical one; the latter is proving to be more flexible [0]. [0] https://www.categoricaldata.net/
Not sure it's comparable to something like Amazon, that has probably dedicated funding.
Anyone know how this compares to Presto and zetasql?
'SQL’s ORDER BY orders the output data. Similarly, the PartiQL ORDER BY is responsible for turning its input bag into an array.' That is the most important thing for my uses. I deal mostly in time series data, SQL windowing queries are too slow. Turning the set into an array to allow indexing and support easy time series queries is enough for me the use it.
PartiQL> SELECT * FROM [1,2,3] | ===' > --- OK! (86 ms) Jeez. 86ms for this query on this data set? Hope that's not representative of the general performance!
This is on the JVM so the JIT's optimizations probably haven't kicked in yet.
Earlier quoted context omitted.
This is on the JVM so the JIT's optimizations probably haven't kicked in yet.
Who are we kidding? Even without JIT optimizations that seems absurdly slow.
Earlier quoted context omitted.
Who are we kidding? Even without JIT optimizations that seems absurdly slow.
Also, the PartiQL compiler makes heavy use of closures, each of which becomes a class, so the first time a query executes the JVM has to load a few dozen classes--this probably explains the 86ms more than a lack of JIT optimizations alone.
Wasn't part of the whole thing with lambdas that they don't all become individual classes?