Re: sparql performance questions

Hi Denis,

It's hard to answer that question in general because different  
implementations choose different strategies for evaluating SPARQL  
queries. For example, the answer for an in-memory store will be  
different from the answer for a database-backed store that translates  
SPARQL into SQL. For some SPARQL stores it won't matter at all  
because they do a certain amount of query reordering by themselves.  
To get a meaningful answer, you could run some benchmarks or ask the  
people who implemented your SPARQL store of choice.

Best,
Richard


On 19 Jun 2006, at 20:29, Denis Gaertner wrote:

>
> Hi!
>
> I got some questions concerning performance optimization in sparql
> queries. Since I couldn't find any good information on the net about
> this(please correct me if this is wrong) I thought this might be the
> right place for it.
>
> So I am wondering how the structure of a complex query affects the
> processing and query time. You can group Graphpatterns to an  
> arbitrarily
> depth and I'd like to know if a structure which is equivalent maybe to
> something like DNF or CNF in feature sets could help. So for example :
> {
> {?s p "o"}
> UNION
> {?s p2 "o2"}
> }
> {?s p3 "o3"}
>
> becomes
>
> {?s p "o" . ?s p3 "o3"}
> UNION
> {?s p2 "o2" . ?s p3 "o3"}
>
> Now this put in a large scale means breaking down lots of levels into
> fewer. Is this of advantage or is the rdf graph structure not suitable
> for this kind of transformation? Or is it solely a question of
> implementation?
>
> And another thing is about constraints. Is it better to put them  
> into a
> group or to collect them and put them at the end if possible? So for
> instance:
>
> {?s p ?o1 FILTER (?o1...)}
> {?s p2 ?o2 FILTER (?o2...)}
>
> or 					
>
> {?s p ?o1} FILTER (?o1...)
> {?s p2 ?o2} FILTER (?o2...)
>
> or
>
> {?s p ?o1}
> {?s p2 ?o2}
> FILTER (?o1... && ?o2...)
>
> So this is it and since I don't know anything on how these queries are
> processed I am not able to figure that out by myself.
>
> Thanks
>
> Denis
>
>
>
>
>

Received on Tuesday, 20 June 2006 07:51:44 UTC