# Overview This is a tracking issue for adding support for the `GROUP BY` clause of a `SELECT` statement. This allows aggregations over unique values of a column. # Tasks - [x] add instructions for `GROUP BY` and aggregations - See the [`GroupBy` instruction](https://github.com/SeaQL/otter-sql/blob/21c68e7277f0594f1fe5e62b9e091de9156a5b99/src/ic.rs#L71-L76) - Aggregations are defined in the `expr` for `Project` or `Filter` just like normal non-grouped aggregations - Note: this is most likely subject to change - [x] add `GROUP BY` codegen to the generic dialect - See [this part of the generic codegen](https://github.com/SeaQL/otter-sql/blob/21c68e7277f0594f1fe5e62b9e091de9156a5b99/src/codegen.rs#L271-L276) - [ ] evaluating `GroupBy` instructions and aggregations - from #16, we saw that - `GroupBy` should probably have `input` and `output` registers like `Project` - we need a different table with an efficient index implementation to look up the grouped columns - the `HAVING` clause can re-use aggregations that are already computed and it might be difficult to perform common sub-expression elimination here
Overview
This is a tracking issue for adding support for the
GROUP BYclause of aSELECTstatement. This allows aggregations over unique values of a column.Tasks
GROUP BYand aggregationsGroupByinstructionexprforProjectorFilterjust like normal non-grouped aggregationsGROUP BYcodegen to the generic dialectGroupByinstructions and aggregationsGroupByshould probably haveinputandoutputregisters likeProjectHAVINGclause can re-use aggregations that are already computed and it might be difficult to perform common sub-expression elimination here