The outer-join benchmarks runtime was highly influenced by the "insert
order" that isn't deterministic. This was the case because the
result-set is quite large (5e7), but the HTTP soft limit was applied
(1e4) - this means that if the input-order of the data being fed into
the nested-loop operation happened to result in early matches the
runtime was a lot faster than if the opposite was the case.
Due to that we often saw large gaps in the runtime. (E.g. from usual
40ms to 150ms; in some cases even larger)
This commit introduces a more sensible data set for joins. (Although
rather small; which is why the old set is still kept, but the queries
are adapted)
The outer-join benchmarks runtime was highly influenced by the "insert order" that isn't deterministic. This was the case because the result-set is quite large (5e7), but the HTTP soft limit was applied (1e4) - this means that if the input-order of the data being fed into the nested-loop operation happened to result in early matches the runtime was a lot faster than if the opposite was the case.
Due to that we often saw large gaps in the runtime. (E.g. from usual 40ms to 150ms; in some cases even larger)
This commit introduces a more sensible data set for joins. (Although rather small; which is why the old set is still kept, but the queries are adapted)