Implemented in branch groupbyoptimization.
The implementation approach is as follows:

 A new class ASTSimpleGroupByAndCountOptimizer.java **
The classe implements the core optimization step, which optimizes
<code>
SELECT (COUNT as ?count) ?z WHERE { ?x rdf:type ?z } GROUP BY ?z
</code>
and similar patterns. The optimizer aims at establishing an execution plan that applies a combination of distinct term scan pattern (to efficiently compute the distinct values for the group variable) and fast range count pattern to efficiently calculate the COUNT, without materialization of the variables on which the COUNT operation is performed.
The basic idea is to
replace the GROUP BY pattern through a SELECT DISTINCT subquery to calculate the distinct bindings for variable ?z first, and
(ii) use a fast range count operator to efficiently calculate the COUNT.
Note that the subquery produced in step may (where possible) be optimized by the ASTDistinctTermScanOptimizer, i.e. if possible the subquery producing the ?z bindings will be replaced by a distinct term scan in a later optimization step.

 As part of the fix, the ASTDistinctTermScanOptimizer has been adjusted. **
Previously, the optimizer only applied to SELECT DISTINCT ?var { tp } where the triple pattern contains variables only. However, distinct term scans are also applicable for triple patterns containing constants whenever the concatenation of the constants and the distinct variable is matched by an existing index. The getApplicableKeyOrderIfExists method checks for such an index being available. In case an index is found, the triple pattern is annotated with the index for later optimization (we must make sure to use exactly this index for the distinct term scan operation.

 The enhancement of the ASTDistinctTermScanOptimizer **
> to deal with triple patterns containing constants required adjustments to the DistinctTermScanOp, which now switches between a DistinctTermAdvancer (in case there are no constants in the tp) and a DistinctMultiTermAdvancer (in case there are one or more constants). Further, code was added to account for the fact that we are not necessarily iterating over the first iv encoded in the key in case we're dealing with constants.

 Addition test case and adjustments **
New test cases were implemented in TestSimpleGroupByAndCountOptimizer, as well as minor adjustments/fixes to existing test cases added; adjustments basically come due to the facts that the DistinctTermScanOptimizer now adds query hints (namely, the key order to use) and (ii) that some test cases for the DistinctTermScanOptimizer now succeed in applying the optimization (for triple patterns containing constants)

 A minor bug in the FastRangeCountOp was fixed (the solution set was not properly passed) **
Implemented in branch groupbyoptimization.
The implementation approach is as follows:
The classe implements the core optimization step, which optimizes
<code>
SELECT (COUNT as ?count) ?z WHERE { ?x rdf:type ?z } GROUP BY ?z
</code>
and similar patterns. The optimizer aims at establishing an execution plan that applies a combination of distinct term scan pattern (to efficiently compute the distinct values for the group variable) and fast range count pattern to efficiently calculate the COUNT, without materialization of the variables on which the COUNT operation is performed.
The basic idea is to
replace the GROUP BY pattern through a SELECT DISTINCT subquery to calculate the distinct bindings for variable ?z first, and
(ii) use a fast range count operator to efficiently calculate the COUNT.
Note that the subquery produced in step may (where possible) be optimized by the ASTDistinctTermScanOptimizer, i.e. if possible the subquery producing the ?z bindings will be replaced by a distinct term scan in a later optimization step.
Previously, the optimizer only applied to SELECT DISTINCT ?var { tp } where the triple pattern contains variables only. However, distinct term scans are also applicable for triple patterns containing constants whenever the concatenation of the constants and the distinct variable is matched by an existing index. The getApplicableKeyOrderIfExists method checks for such an index being available. In case an index is found, the triple pattern is annotated with the index for later optimization (we must make sure to use exactly this index for the distinct term scan operation.
> to deal with triple patterns containing constants required adjustments to the DistinctTermScanOp, which now switches between a DistinctTermAdvancer (in case there are no constants in the tp) and a DistinctMultiTermAdvancer (in case there are one or more constants). Further, code was added to account for the fact that we are not necessarily iterating over the first iv encoded in the key in case we're dealing with constants.
New test cases were implemented in TestSimpleGroupByAndCountOptimizer, as well as minor adjustments/fixes to existing test cases added; adjustments basically come due to the facts that the DistinctTermScanOptimizer now adds query hints (namely, the key order to use) and (ii) that some test cases for the DistinctTermScanOptimizer now succeed in applying the optimization (for triple patterns containing constants)