When checking !isIRI(?o) and !isBlank(?o).
I see a significant performance difference when compared with another repository.
Andrea
which repository? does it mean a different triple store? how does the whole query look like?
Usually, FILTER is just applied after computing the intermediate resultset, e.g. by means of joins. if you compare to other triple stores, then indeed the query optimizer might work differently. But seeing the query, how should anybody be able to give hints on optimization?
Hi Andrea,
Indeed, Stardog does not currently have any index structures to detect whether a certain node is an IRI, blank node, or a literal. Thus, as Lorenz said, it has to apply the filter to every solution computed by its argument. The best way to optimize queries with such filters is to add other selective patterns to the query, so the filter becomes less expensive.
However, in the extreme case where you just have select * { ?s ?p ?o . filter( isIri(?o) ) } there’s little you can do currently. We’re aware of this issue and plan to address it in the 6.0 release cycle.
Best,
Pavel
Here’s another idea. If it’s not an IRI and it’s not a blank node than it must be a literal so you might be able to rewrite it using full text search. Although I’m not sure if by “and” you were talking about both in a single query or multiple queries that might use one or the other.
Pavel, You exactly expressed my query issue. I am using queries as integrity constraint checking - across multiple types of repos. So, I am basically asking for all triples where the predicate is an ObjectProperty and the the object is not an IRI or a blank node.
Looking forward to the 6.0 release! 
Andrea
We have removed all our rdfs:range ICV rules because of this. One of our rules was checking around 300 000 triples and was using 400 ms per transaction.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.