Hello Eric,
1. Indexes.
Single bitmap index PGOS is sufficient as soon as all your queries
specify graphs in use (via FROM clauses) and do not contain unbound
predicates in triple patterns (even more, all predicates are constants
in your samples).
Other indexes are for cases of unbound P and/or unbound G; that cases
are quite common for dbpedia and other "very heterogeneous" data sets
(unbound P) and for data sets in public access (G can be bound there but
it stays unbound because clients are not enough competent).
2. Understanding the bottleneck.
Next release of Virtuoso Open Source will cite query cost data in
'explain' outputs. This will make more informative performance hints.
(The release should happen some about this weekend. If it is delayed due
to components not related to SPARQL I'll send you a binary for your
platform.)
In addition, you may use function sparql_to_sql_text whose argument is
the text of the SPARQL query (without leading SPARQL keyword) and the
returned value is the result of SPARQL-to-SQL front-end compiler. I.e.
that is the query that will actually be compiled and executed. The
output looks ugly but that's the text that is actually executed so it is
worth seeing.
3. Give more hints to the SPARQL compiler.
When you're using two FROM clauses in a statement that consists of 8
triple patterns, you may know for some patterns that matching triples
come from one specific graph, not from both of them. It is advisable to
wrap that patters into GRAPH my-first-graph { ... } or GRAPH
my-second-graph { ... } group graph patterns, eliminating the need for
redundand lookups in unrelated graphs.
Best Regards,
Ivan Mikhailov,
OpenLink Software.
http://virtuoso.openlinksw.com
