Hi all, Can we discuss how we write summaries for Jira cases? In my opinion it’s really important, because summaries become commit messages, and commit messages become release notes, which is how most people figure out what is in Calcite. I spend a lot of my time working with people to write good summaries.
I’d like some feedback on whether this approach is useful. And to try to teach people how to do it for themselves. Consider this case https://issues.apache.org/jira/browse/CALCITE-4983 <https://issues.apache.org/jira/browse/CALCITE-4983>. (I chose a still current case because it doesn’t yet have an ‘answer’.) The current summary is > In SubstitutionVisitor's unifyAggregates, if Aggregate has > grouping sets, we need to handle the condition needs to pull up. It describes the cause but it doesn’t describe the problem (or the symptoms the user sees). If you take your car into your mechanic the cause is ‘Leaky gasket results in oil dripping onto hot manifold’ but the problem is ‘Smoke comes from hood when engine gets hot’. Do you agree that the second description is much more useful? In this case, the author came up with an example: > Here is an example: > > sql: select empid, deptno from emps group by grouping sets ((empid, > deptno),(empid)) > mv: select empid, count(distinct deptno) from emps where empid>100 > group by grouping sets ((empid, deptno), (empid)) > > the result plan is: > > LogicalCalc(expr#0..2=[{inputs}], deptno=[$t1], EXPR$1=[$t2]) > LogicalAggregate(group=[{0, 1}], groups=[[{0, 1}, {0}]], > EXPR$1=[COUNT(DISTINCT $1)]) > EnumerableTableScan(table=[[hr, MV0]]) > > We can see that this plan doesn't handle the condition empid>100 I think it’s a great example. I especially like the last line, where the author pointed out what was wrong. I suggest the following summary: > Incorrect plan for query that has GROUPING SETS and WHERE Do you think the summary is more useful? Can it be improved? Julian
