I usually do this sort of thing in one query using VALUES. For example
SELECT ?s ?p ?o
WHERE {
VALUES ?s { ns:subj1 ns:subj2 ns:subj3 }
VALUES ?p { ns:prop1 ns:prop2 }
?s ?p ?o .
}
Best regards,
Jim
> On Mar 28, 2020, at 7:30 PM, Mike Welch <[email protected]>
> wrote:
>
> Hi everyone,
>
> We have a use case like the following: given a set of M known URIs
> (typically 10s to a few hundred), fetch the same N (typically 2-10)
> properties for each of them via Fuseki (TDB2).
>
> Does anyone have any benchmarks, rules of thumb, hunches, etc of what would
> be the most optimal approach for packaging and/or parallelizing requests?
> We currently send 1 query per subject URI, so M parallel requests, each
> request containing a UNION of N individual simple patterns:
>
> { ns:subj1 ns:prop1 ?a }
> UNION
> { ns:subj1 ns:prop2 ?b }
> ...
>
> This seems to work pretty well - better than M parallel queries with all
> OPTIONAL patterns, M*N parallel single pattern requests, or 1 giant UNION
> for all M*N things at once, but it was still a somewhat arbitrary choice
> amongst many, many other possibilities. Does anyone have
> any suggestions of what might work better or be more friendly to the
> internal optimizers, with the main goal of minimizing overall latency to
> fetch all M*N things?
>
> Thanks!
> - Mike
