Created attachment 692 [details]
A simple running sum
sum() over (order by "key")
even on data that is already sorted on key (and MonetDB should know that)
appear to be very slow with larger data, seemingly quadratic in the number of tuples rather than linear.
See attached script and log for details.
Created attachment 693 [details]
output of test script
This is a known corner case that can be improved. Is on the TODO list to improve the window functions for these scenarios, but I have been very busy with bug fixes and other performance improvements.
Well, with a "global" Window function, i.e., merely an "order by" but no "partition by", I would not expect quadratic complexity/performance in the first place, but at most n log n, i.e., for the sort ...
After I get done with the alloc-str-branch, which should be around this week, I can go to this. I planning to add 2 more execution scenarios for aggregates as windows functions: cumulative aggregate for your case and segment tree lookup as the more general solution. The naive solution should still be the better solution when the number of rows in the partition is very low.
On window-tunning branch, I added the cumulative aggregate for these cases. The performance should be around nlogn.