Aim is to be able to access aggregates via JNI w/ greater efficiency of not having to pull back all the hit values via get_qualified_ints etc.
I started by just attempting to add support for fastbit_build_result_set and passing a select clause with aggregates. But : 1) this returns the aggregate for teh wrong column (e.g. if asking for sum(colB) it would return a sum for a different column as was visible by returned aggregate and the debug logging showing access to said other column (apparently lexicographically selected) 2) as one starts tracing where that went wrong, one realizes this method will return a record with those aggreagtes for each hit as that is what the result set would contain -- given that it seem inefficient and based on query.h comment "If any additional functions are needed in the select clause, use the function ibis::table::select instead of using this class" I turned to that >From there I took the thula example as a better starting point over tcapi and did manage do get the functionality of thula doQuery into the capi and access it via JNI. However I want to make certain what would be the best way to proceed now that I have validated this was feasible. 1) do you agree ibis::table.select is optimal for the case of wanting a couple of aggregates over a couple of columns (not necessarily teh same as in the where clause) for a set of where clauses against a table? 2) do you have recommendation on how to best expose this -- adding the table facade to FastBitQuery seems cleanest but for now I'm just exposing a specialized function 3) do you any arguments against a count(*) to the select clause to have one complete select response instead of having to mix in a separate request for num hits? -- it appears if using table.select I won't need to use the query interface and the table mechanisms are separate for computing hits 4) any concerns with this approach on memory cleanup or optimizations given that these queries will be run within a long lived container? Thx in advance
_______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
