[jira] [Created] (CALCITE-3764) AggregateCaseToFilterRule handles NULL values correctly

2020-01-31 Thread Julian Hyde (Jira)
Julian Hyde created CALCITE-3764:


 Summary: AggregateCaseToFilterRule handles NULL values correctly
 Key: CALCITE-3764
 URL: https://issues.apache.org/jira/browse/CALCITE-3764
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde


{{AggregateCaseToFilterRule}} handles NULL values correctly. It converts

{code:sql}
SELECT COUNT(CASE WHEN b THEN NULL ELSE 1 END) FROM t
{code}
to
{code:sql}
SELECT COUNT(*) FILTER (WHERE b IS FALSE) FROM t
{code}
which fails to count rows where {{b}} is UNKNOWN, so it should convert to
{code:sql}
SELECT COUNT(*) FILTER (WHERE b IS NOT TRUE) FROM t
{code}




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CALCITE-3763) RelBuilder.aggregate should prune unused fields from the input, if the input is a Project

2020-01-31 Thread Julian Hyde (Jira)
Julian Hyde created CALCITE-3763:


 Summary: RelBuilder.aggregate should prune unused fields from the 
input, if the input is a Project
 Key: CALCITE-3763
 URL: https://issues.apache.org/jira/browse/CALCITE-3763
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde


{{RelBuilder.aggregate}} should prune unused fields from the input, if the 
input is a {{Project}}.

Pruning fields during the planning process is desirable, but often cannot do it 
- we are applying a {{RelOptRule}} that has to return the same fields, or we 
don't want to add an extra Project do so the pruning. But when we are in 
{{RelBuilder.aggregate}} and the input is a Project, neither of those 
limitations apply. We already have a Project, we are just making it narrower; 
and we know what fields the {{Aggregate}} will produce.

For example,
{code:sql}
SELECT deptno, SUM(sal) FILTER (WHERE b)
FROM (
  SELECT deptno, empno + 10, sal, job = 'CLERK' AS b
  FROM emp)
GROUP BY deptno
{code}
becomes
{code:sql}
SELECT deptno, SUM(sal) FILTER (WHERE b)
FROM (
  SELECT deptno, sal, job = 'CLERK' AS b
  FROM emp)
GROUP BY deptno
{code}

If there are no fields used, remove the {{Project}}. (A {{RelNode}} with no 
fields is not allowed.)
{code:sql}
SELECT COUNT(*) AS C
FROM (
 SELECT deptno, empno + 10, sal, job = 'CLERK' AS b
 FROM emp)
{code}
becomes
{code:sql}
SELECT COUNT(*) AS c
FROM emp
{code}

Add an option {{RelBuilder.Config.pruneInputOfAggregate}}, default true, so 
that people can disable this rewrite if it causes problems.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (CALCITE-3762) AggregateProjectPullUpConstantsRule causes fields to be out of order

2020-01-31 Thread hezhang (Jira)
hezhang created CALCITE-3762:


 Summary: AggregateProjectPullUpConstantsRule causes fields to be 
out of order
 Key: CALCITE-3762
 URL: https://issues.apache.org/jira/browse/CALCITE-3762
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.16.0, 1.10.0
Reporter: hezhang
 Fix For: 1.16.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)