public class ASTOrderByAggregateFlatteningOptimizer extends Object implements IASTOptimizer
MemorySortOp
does not have to deal
with aggregates. In a nutshell, this is done by introducing aliases for the
aggregate expressions and thus pushing the computation of the aggregates to
where they can already be processed.
Simple example.
Consider this query (sparql11-order-02.rq):
SELECT ?type WHERE { ?subj a ?type } GROUP BY ?type ORDER BY (count(?subj))
It contains aggregate count(?subj) in ORDER BY. The idea is to rewrite it
into this query:
SELECT ?type (count(?subj) as ?cnt)[excludeFromProjection] WHERE { ?subj a
?type } GROUP BY ?type ORDER BY ?cnt
Here ?cnt is an auxiliary alias, i.e, a fresh variable (UUIDs are used as
fresh variable names in the implementation). This query can be computed even
if the sorting does not support aggregates.
Note that the rewritten query is not completely equivalent to the original
one: it will assign ?cnt, which does not occur in the original query. To
rectify this, some variables in a projection are designated as excluded from
the projection outputs: see the label "[excludeFromProjection]" by ?cnt in
the rewritten query (pseudo-SPARQL).
More complex example.
The original query is:
PREFIX ex: Constructor and Description |
---|
ASTOrderByAggregateFlatteningOptimizer() |
Modifier and Type | Method and Description |
---|---|
QueryNodeWithBindingSet |
optimize(AST2BOpContext context,
QueryNodeWithBindingSet input)
Optimize the AST.
|
public ASTOrderByAggregateFlatteningOptimizer()
public QueryNodeWithBindingSet optimize(AST2BOpContext context, QueryNodeWithBindingSet input)
IASTOptimizer
optimize
in interface IASTOptimizer
context
- The evaluation context.input
- The input to the optimizer, consisting of a queryNode and
input binding set.Copyright © 2006–2019 SYSTAP, LLC DBA Blazegraph. All rights reserved.