Julian Hyde commented on CALCITE-1933:

Why are you providing it via Schema? I think this should be a new kind of 
planner metadata, via RelMetadataQuery. There is already a mechanism to add 

> Cost estimation for expression evaluate
> ---------------------------------------
>                 Key: CALCITE-1933
>                 URL: https://issues.apache.org/jira/browse/CALCITE-1933
>             Project: Calcite
>          Issue Type: New Feature
>            Reporter: Ted Xu
>            Assignee: Julian Hyde
> Expression evaluate performance is different one to another based on its 
> operator type and underlying execution engine. For example, a regex pattern 
> matching (e.g., col like 'foo%bar%') may requires 100 times more cost 
> compares to a simple comparison (e.g., col > 3). Currently we don't have this 
> kind of differentiation.
> Expression cost will grant following applications:
> 1. Improved predicate push down: predicates can be pushed down to the right 
> position based on row count and its own cost.
> 2. Predicate ordering rule: predicate with different order, e.g.,
> {code:sql}
> col1 like 'foo%bar%' and col2 > 3
> col2 > 3 and col1 like 'foo%bar%'
> {code}
> may have different performance, introducing a predicate ordering rule will 
> help find a better one.
> The cost of each RexCall / RexAggCall is provided by Schema, stored in an 
> external metadata service.

This message was sent by Atlassian JIRA

Reply via email to