Query execution in ARQ is based on nested iterators so QueryIterTopN will always apply over another iterator
A PriorityQueue is used internally as temporary storage within QueryIterTopN while it exhausts the inner iterator allowing it to only use at most the limit amount of storage in the priority queue plus whatever temporary storage the inner iterator(s) may need. There is still a "total sort" in the sense that every possible solution has to be compared to see if it should be placed into the priority queue however there is not a "total sort" in the sense of needing to materialise all possible solutions into memory and then sort. Rob p.s. Please don't post identical questions to both users@ and dev@ - one list is sufficient as the developers are on both lists. As a general rule general support questions should go to users@ and technical/architecture questions like this should go to dev@ On 10/03/2015 05:54, "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
