Dear Rose, you may want to read the papers Sara, Alessandro and I wrote on top-k spraql query evaluation [1][2] and to check out our implementation [3] that extends ARQ.
Best Regards, Emanuele [1] http://dx.doi.org/10.1007/978-3-642-35176-1_22 [2] http://dx.doi.org/10.1007/978-3-642-34213-4_10 [3] http://sparqlrank.search-computing.org/home > On 10 Mar 2015, at 10:55, Rose Beck <[email protected]> wrote: > > Sorry for yet another mail. Is there some document from which I can > understand how ORDER BY and LIMIT clause are evaluated by Jena. I read > the documentation here: > http://jena.apache.org/documentation/query/arq-query-eval.html but I > am not able to understand the solution from it. > > On Tue, Mar 10, 2015 at 11:24 AM, Rose Beck <[email protected]> wrote: >> Hi, >> >> I saw the following issue posted on Jena website (which has been >> recently resolved): >> Avoid a total sort for ORDER BY + LIMIT queries >> (https://issues.apache.org/jira/browse/JENA-89). >> >> I am very interested in understanding as to how does Jena-ARQ avoids >> total sort for ORDER BY + LIMIT queries. In the post it is mentioned >> that Jena-ARQ uses priority queue for avoiding a final sort, however >> it is also mentioned that "ARQ's algebra package contains already a >> OpTopN [3] operator. The OpExecutor [4] will need to use a new >> QueryIterTopN instead of QueryIterSort + QueryIterSlice." It is not >> clear now does the priority queue benefit from OpTopN operator and >> QueryIterTopN as the links [3] and [4] mentioned on the website does >> not work, so I am not able to understand their operation and as to how >> do they help in avoiding a total sort. >> >> Can someone please explain how does Jena-ARQ execute the queries >> containing ORDER BY + LIMIT clause. >> >> With Warm Regards, >> Rose > > > > -- > With Warm Regards, > Rose
