The reality is also that your case seems to be a bit unuusal. To be 3.5s
I'd guess you are hitting the POS (or quad equivalent) index cold. Or
something else is interacting with it (named graphs+union?)
Yes, I noticed after my initial email that later queries run much
faster... now it's around 300ms which is much better. Still a bit slow
but manageable.
This is what was discovered before - the cost of scanning and filtering
isn't that high and why outlier cases may be measurable faster, the bulk
of queries will be marginally faster. There is always a lot of things
that can be done; it comes down to contributions and priorities.
And the cost of the join? and of the CONSTRUCT? And if Fuseki, the HTTP
costs which vary from trivial to a lot depending on result sizes.
connection caching. The point is "it is complicated" and that means
however good the point improvement is, it may not have a significant
overall benefit.
Investigation needed before jumping into implementation.
(I don't see how it works with dynamic inference.)
On 30/08/2020 10:46, Élie Roux wrote:
Checking whether there is one first.
Ok, I'll do that
Turns out there's already a 2011 issue about that:
https://issues.apache.org/jira/browse/JENA-144
I'm wondering if opening another issue about a request for a new API
function would be relevant? Something in the lines of what Andy
proposed:
StmtIterator listStatements(Resource s, Property p, RDFNode omin, RDFNode omax)
as well as perhaps a new
Interface RangedObjectSelector
ARQ does not use the Model API. It's an extension to the ARQ algebra,
OpExecutor, and subclasses, and one or more optimization Transforms to
detect the case in a query.
Overall, this isn't an API issue - it's the cost of implementing that
API vs not doing something elsewhere.
Andy
?
Best,
