Why This Problem Occurs Generally
Virtuoso’s SPARQL query optimiser does not execute queries directly — it first translates SPARQL into SQL and then selects an execution plan by estimating the cost of different join orders and access strategies. These estimates are based on runtime statistics collected independently on each cluster node.
Because each node collects its own statistics through random sampling of data distribution, and because those samples are taken at different times and under different load conditions, each node builds a slightly different statistical model of the data — even when the underlying RDF data is logically identical across nodes. When the optimiser on a given node produces a poor cost estimate for a particular join, it may choose a suboptimal plan that causes orders-of-magnitude slower execution compared to a node that estimated more accurately.
This is not unique to Virtuoso — all cost-based query optimisers share this characteristic. However it is particularly pronounced in RDF/SPARQL engines because the entire dataset is stored in a single table with a small number of indexes, meaning the optimiser has less structural guidance and relies more heavily on statistical estimates of S/P/O/G value distributions to make planning decisions.
The practical consequence is that any query which gives the optimiser significant freedom to choose its own join order is at risk of plan variation across nodes.
How to Write SPARQL Queries That Avoid This
The general principle is to reduce the optimiser’s freedom to make poor choices by anchoring the query to efficient, index-based access paths as early as possible. The following practices achieve this:
1. Use direct range filters on indexed predicates rather than computed values
Avoid deriving filter variables through BIND or functions:
# Avoid — forces full scan, no index use
BIND(YEAR(?dateValue) AS ?year)
FILTER (?year = 2024)
# Prefer — direct range enables index seek
FILTER (?dateValue >= "2024-01-01"^^xsd:date &&
?dateValue < "2025-01-01"^^xsd:date)
2. Use VALUES instead of FILTER ... IN for constant equality matching
VALUES binds variables to known constants before the join executes, giving the optimiser a definite starting point:
# Avoid — evaluated as a runtime expression
FILTER (?categoryType IN (ex:typeA, ex:typeB))
# Prefer — resolved to index lookups on constants
VALUES ?categoryType { ex:typeA ex:typeB }
3. Only join what you need in the projection
Every triple pattern in the query body is a join the engine must execute, regardless of whether the variable appears in the SELECT. Patterns involving large predicates (high-cardinality relationships like tenders, financial values, participants) can multiply intermediate result sizes by millions of rows:
# Remove or comment out triple patterns whose variables are not in SELECT
# ex:hasRelatedParty ?participant ;
# ex:hasTransactionValue ?amount .
If existence needs to be confirmed without retrieving values, use FILTER EXISTS { ... }rather than an open join.
4. Place the most selective triple pattern first
Virtuoso uses the ordering of triple patterns as a hint when statistics are ambiguous. Leading with the pattern that binds the fewest results (typically a specific typed node or a narrow date/value range) reduces the size of intermediate results that subsequent joins must process.
5. Use GRAPH ?g { ... } to scope joins
Placing patterns inside a named graph block constrains the search space and helps the optimiser avoid cross-graph scans. This is particularly effective in datasets where data is partitioned by notice or document graph.
6. Keep filters close to the triple patterns that bind their variables
Place each FILTER immediately after the last triple pattern that binds all variables referenced in it. This allows the engine to prune rows as early as possible in the join sequence rather than accumulating large intermediate sets.
Summary
| Practice | Why It Helps |
| Range filters on dates/values | Enables index seek, removes scan dependency on statistics |
VALUES for constants |
Anchors join to known nodes, removes runtime expression evaluation |
| Remove unused triple patterns | Eliminates large joins that inflate intermediate results |
| Most selective pattern first | Guides join order when statistics are uncertain |
Scope with GRAPH |
Reduces search space, limits cross-graph scans |
| Filters adjacent to binding patterns | Prunes results early, reduces intermediate set sizes |
Queries written following these practices give the optimiser less room to make poor decisions and produce consistent, predictable execution plans regardless of how node-level statistics happen to be distributed at any given time.