[ 
https://issues.apache.org/jira/browse/CALCITE-5894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752182#comment-17752182
 ] 

Julian Hyde commented on CALCITE-5894:
--------------------------------------

Here is a sketch for the new metadata:
{code:java}
public abstract class BuiltInMetadata {
   // ...

   public interface FunctionalDependency extends Metadata {
       /** Returns whether column is functionally dependent on columns. */
       Boolean functionallyDetermine(ImmutableBitSet columns, int column);
   }
}
{code}

If {{columns}} contains a unique key (per 
{{BuiltInMetadata.areColumnsUnique(columns, false)}}) then 
{{functionallyDetermine(columns, column)}} will return true for all values of 
{{column}}.

In the previous paragraph, {{ignoreNulls = false}} because null values do 
matter in sorting.

It would be implemented in a new {{class RelMdFunctionalDependency}}.

For an expression e, the columns functionally determine e if they determine 
every column in e.

> Add SortRemoveRedundantRule to remove redundant sort fields if sort fields 
> contains unique key
> ----------------------------------------------------------------------------------------------
>
>                 Key: CALCITE-5894
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5894
>             Project: Calcite
>          Issue Type: New Feature
>            Reporter: JingDas
>            Assignee: JingDas
>            Priority: Minor
>
> In some scene, Sort fields can be reduct, if sort fields contain unique key
> For example
> {code:java}
> SELECT ename, salary FROM Emp
> order by empno, ename{code}
> where `empno` is a key,  `ename` is redundant since `empno` alone is 
> sufficient to determine the order of any two records.
> So the SQL can be optimized as following:
> {code:java}
> SELECT name, Emp.salary FROM Emp
> order by empno{code}
> For another example:
> {code:java}
> SELECT e_agg.c, e_agg.ename
> FROM
> (SELECT count(*) as c, ename, job FROM Emp GROUP BY ename, job) AS e_agg
> ORDER BY e_agg.ename, e_agg.c {code}
> Although `e_agg.ename` is not a key but field `ename` is unique and not null, 
> it can be optimized as following:
> {code:java}
> SELECT e_agg.c, e_agg.ename
> FROM (SELECT count(*) as c, ename, job FROM Emp GROUP BY ename, job) AS e_agg
> ORDER BY e_agg.ename{code}
> Sorting is an expensive operation, however. Therefore, it is imperative that 
> sorting
> is optimized to avoid unnecessary sort field.
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to