I agree, this would be a good optimization. Please log a JIRA case for it. The only reason we don’t do it now is because the code path for creating regular aggregates (e.g. “select count(x) from t”) is different than the code path for creating windowed aggregates (e.g. “select count(x) over (…) from t”).
Probably you should add the optimization to RexBuilder.makeOver, so at least it is happening at the same time as RexBuilder.addAggCall. Add tests to SqlToRelConverterTest. In your tests, make sure that “avg(x) over w” is translated to “sum(x) over w / count(*) over w” if “x” is NOT NULL; we make that optimization in non-windowed AVG, and it is a useful one. Julian > On Jan 7, 2018, at 4:00 AM, jincheng sun <[email protected]> wrote: > > Hi Julian, > > I'm a bit confused by the different optimization of COUNT (1) in OVER window > and tumble window. > > When we parse a SQL: > > select COUNT(1) from T tumble(rowtime, interval 2 seconds) > > In RexBuild.addAggCall will do the optimize as follows: > > if(aggCall.getAggregation() instanceof SqlCountAggFunction && > !aggCall.isDistinct()) { > List rex = aggCall.getArgList(); > List index = nullableArgs(rex, aggArgTypes); > if(!index.equals(rex)) { > aggCall = aggCall.copy(index, aggCall.filterArg); > } > } > After the code logic above, the COUNT(1) -> COUNT(). > But when we parser a SQL: > select COUNT(1) OVER(...) from T. > we do not do the optimize, So, I want to know why not optimize the parameter > of COUNT (1) in OVER window? > If we need do the optimize, can we do the optimize after SqlToRelConverter? > > Best, Jincheng >
