OK, I should have said: in my use-case, this is a competitive advantage (small dataset : 50 million triples, no natural order for the results, no ranking of them, and when we are in the 1000 solutions case, possibility to return to the user hints about how to refine the query, without reading the 1000 solutions. And practical evidences - time measurements - that things are much faster when I don’t read the 1000-n solutions)
fps > Le 23 nov. 2015 à 09:55, james anderson <[email protected]> a écrit : > > good morning; > >> On 2015-11-23, at 09:31, François-Paul Servant >> <[email protected]> wrote: >> >>>> Le 21 nov. 2015 à 17:56, Andy Seaborne <[email protected]> a écrit : >>>> >>>> Hi, >>>> >>>> In the current implementation, then results will be in the same order. >>>> Well, as far as I know. I can't think of anything that will disturb it. >>>> I think you realise the responsibility is yours; it is not guaranteed for >>>> all time. >> >> on the other hand, a triple store implementation that would proudly claim >> that it ensures the stability of the order of iterator results would have a >> competitive advantage over those that do not … ;-) > > on one hand, given the application described in an earlier message, the case > remains to be made that the particular first-n-of-1000 matters. were it to > matter, the order would be a stipulated criteria rather than that contingent > on the storage architecture and/or query implementation and an order > operation would be necessary. > > on the other, the dimensions of advantage remain to be defined. depending on > the actual query, its implementation could involve parallel operations which > yield non-deterministic result orders. in those cases, if the execution time > is the dominant dimension of advantage, a stable, unsorted result would lose > the competition. > > best regards, from berlin, > --- > james anderson | [email protected] | http://dydra.com > > > > >
