Hi, Will, Thanks for the report. There was a couple of problem with the ordering function that caused this problem you've observed.
- as you've observed, the values of s are all 1s, which causes the ordering function attempting to order with other columns. In this process, the ordering flag "DESC" is not carried appropriately. The updated code attempts to keep the option "DESC" when the user has specified "DESC" to all order by keys. In your case, you have one order by key and one specification of "DESC", so the "DESC" flag is preserved for all sorting operation. See if you agree with this logical and let us know. - there was another bug in the code that causes the sorting procedure itself to only work for ASCENDING order. This problem was hidden because the test case intended to catch this was not thoroughly examined until now -- thanks for bring this problem up to our attention. A fix has been checked into the SVN repository as SVN revision 853. Please give it a try when you get the chance. Thanks again. John PS: you can access the source code following the instruction at https://code.lbl.gov/scm/?group_id=44 On 4/17/16 6:25 PM, Will Glozer wrote: > Hello, > > When FastBit is asked to use descending sort on an aggregation column > with 1 distinct value it attempts to sort by all columns and in doing > so breaks the row ordering. Here's an example input CSV: > > 11,43,0 > 11,43,1 > 13,43,0 > 13,43,1 > 17,43,0 > 17,43,1 > 19,43,1 > 19,97,1 > > Load: > > `ardea -d test -m "a:int,b:int,c:int" -t test.csv` > > Query: > > `ibis -d test -q "select a, b, sum(c) as s from test where 1=1 order > by s desc limit 1000"` > > 19, 43, 1 > 19, 43, 1 > 17, 43, 1 > 13, 43, 1 > 11, 97, 1 > > Thanks, > Will > > > > _______________________________________________ > FastBit-users mailing list > [email protected] > https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users > _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
