group-by on time returns data out of order

[client9]

I'm using ubuntu package, downloaded today.

I have something putting stats in every 10s.

select * from idle limit 100'
1384345429000 51715
1384345419000 51609
1384345409000 51502
1384345399000 51397
1384345389000 51291
1384345379000 51185
1384345369000 51079
1384345359000 50968
1384345349000 50866
1384345339000 50761
1384345329000 50654
1384345319000 50549
1384345309000 50443
1384345299000 50337
1384345289000 50230
etc

everything nice, time descending, sequence descending

when I use group by, the timestamps come "mostly decreasing"

for example using the following query:

select count(value) from idle group by time(10s) limit 50

we get this. first col is time, second is difference from previous (should always be positive), third is count. Make no difference if I group by different time values.

1384345510000 185252.398926 1
1384345480000 30000 1
1384345450000 30000 1
1384345340000 110000 1
1384345300000 40000 1
1384345250000 50000 1
1384345160000 90000 1
1384345640000 -480000 1   <-- ??
1384345610000 30000 1
1384345270000 340000 1
1384345210000 60000 1
1384345530000 -320000 1 <-- ??
1384345260000 270000 1
1384345660000 -400000 1 <-- ??
1384345570000 90000 1

what's going on here?

[jvshahid]

Fixed. Please give it another try and reopen if the issue is still reproducible with the latest version.

[client9]

seems to work perfectly.

I was surprised you had to do a sort... but looks like you are doing a mini-map-reduce on the parts. interesting!

thanks,

1384394690000 10000 99
1384394680000 10000 99.1
1384394670000 10000 99
1384394660000 10000 98.9
1384394650000 10000 99.1
1384394640000 10000 99.1
1384394630000 10000 99.1
1384394620000 10000 99
1384394610000 10000 99
1384394600000 10000 99.1
1384394590000 10000 99.2
1384394580000 10000 99.1
1384394570000 10000 99.1
1384394560000 10000 99
1384394550000 10000 99.1
1384394540000 10000 99.1

[jvshahid]

There are definitely some optimizations that can be applied here. I'm
inclined not to prematurely optimize given that the code base is still
young and changes very rapidly. Once the code base is mature enough we'll
run benchmarks and take care of the bottlenecks and inefficient code paths.
On Nov 13, 2013 9:06 PM, "Nick Galbreath" notifications@github.com wrote:

seems to work perfectly.

I was surprised you had to do a sort... but looks like you are doing a
mini-map-reduce on the parts. interesting!

thanks,

1384394690000 10000 99
1384394680000 10000 99.1
1384394670000 10000 99
1384394660000 10000 98.9
1384394650000 10000 99.1
1384394640000 10000 99.1
1384394630000 10000 99.1
1384394620000 10000 99
1384394610000 10000 99
1384394600000 10000 99.1
1384394590000 10000 99.2
1384394580000 10000 99.1
1384394570000 10000 99.1
1384394560000 10000 99
1384394550000 10000 99.1
1384394540000 10000 99.1

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/45#issuecomment-28453801
.