Fuseki: Performance question regarding non-related query conditions

[Bardo Nelgen]

Hi all,

I recently got quite surprised that running a larger CONSTRUCT query
(choosing rdf/xml for output) on Fuseki, combining results from multiple
non-related parts of a graph like

CONSTRUCT { ?s ?p ?o . ?a ?b ?c.}
WHERE { ?s ?p ?o . ?a ?b ?c.}

took significantly longer (e.g. 2 seconds vs. 18 seconds…) using
thequery itself, than by simply query-constructing each statement
separately and afterwards combining the queries’ results as plain XML.

Is this due to the approach (like the processor being "not intended"
for it…) or will there more likely be some fault with my query, that
makes the processor running circles looking for possible matches where
there are none ?

As always, thanks for any suggestions, hints or resources.

Best,

Bardo

[Bardo Nelgen]

Thanks a lot, James — that was the hint I needed / feared. ;-)

— Bardo

On 2016-03-31, at 18:44, Bardo Nelgen
Hi all,
I recently got quite surprised that running a larger CONSTRUCT query
(choosing rdf/xml for output) on Fuseki, combining results from
multiple non-related parts of a graph like
CONSTRUCT { ?s ?p ?o . ?a ?b ?c.}
WHERE { ?s ?p ?o . ?a ?b ?c.}

your query produces a cartesian join of the statements in the repository.
the cardinality can turn out to be quite large.

took significantly longer (e.g. 2 seconds vs. 18 seconds…) using
thequery itself, than by simply query-constructing each statement
separately and afterwards combining the queries’ results as plain XML.
Is this due to the approach (like the processor being "not intended"
for it…) or will there more likely be some fault with my query, that
makes the processor running circles looking for possible matches
where there are none ?
As always, thanks for any suggestions, hints or resources.
Best,
Bardo

---
http://dydra.com