[jira] [Commented] (CALCITE-1048) Make metadata more robust

2020-09-25 Thread chunfeng pei (Jira) 


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

chunfeng pei commented on CALCITE-1048:
---

A new Jira ticket is opened as discussed above. 

https://issues.apache.org/jira/browse/CALCITE-4281

> Make metadata more robust
> -
>
> Key: CALCITE-1048
> URL: https://issues.apache.org/jira/browse/CALCITE-1048
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Following CALCITE-794, make metadata more robust and performant, so we can 
> safely derive metadata from a large RelNode graph.



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

[jira] [Commented] (CALCITE-1048) Make metadata more robust

2020-09-25 Thread Julian Hyde (Jira) 


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

Julian Hyde commented on CALCITE-1048:
--

[~ChunfengPei], Yes, please log a separate JIRA case for getMaxRowCount, and 
fully describe the problem.

This seems very closely related to CALCITE-3963. (Note that I mention 'fold' 
operator in both cases.)

> Make metadata more robust
> -
>
> Key: CALCITE-1048
> URL: https://issues.apache.org/jira/browse/CALCITE-1048
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Priority: Major
>
> Following CALCITE-794, make metadata more robust and performant, so we can 
> safely derive metadata from a large RelNode graph.



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

[jira] [Commented] (CALCITE-1048) Make metadata more robust

2018-03-07 Thread zhen wang (JIRA) 

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

zhen wang commented on CALCITE-1048:


and probably relates to CALCITE-1862 as well. 

> Make metadata more robust
> -
>
> Key: CALCITE-1048
> URL: https://issues.apache.org/jira/browse/CALCITE-1048
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>Priority: Major
>
> Following CALCITE-794, make metadata more robust and performant, so we can 
> safely derive metadata from a large RelNode graph.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CALCITE-1048) Make metadata more robust

2017-11-13 Thread Julian Hyde (JIRA) 

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

Julian Hyde commented on CALCITE-1048:
--

Basically, yes.

I was thinking of doing the same thing in a more abstract way, namely providing 
a "[fold|https://en.wikipedia.org/wiki/Fold_(higher-order_function)]" function.

> Make metadata more robust
> -
>
> Key: CALCITE-1048
> URL: https://issues.apache.org/jira/browse/CALCITE-1048
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Following CALCITE-794, make metadata more robust and performant, so we can 
> safely derive metadata from a large RelNode graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CALCITE-1048) Make metadata more robust

2017-11-12 Thread weijie.tong (JIRA) 

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

weijie.tong commented on CALCITE-1048:
--

[~julianhyde] Since 
[CALCITE-794|https://issues.apache.org/jira/browse/CALCITE-794] has solved the 
possible stack-overflow problems (If I don't misunderstand that jira.), I think 
we could refactor the RelSubset's methods like this:

{code:java}
 public Double getMaxRowCount(RelSubset rel, RelMetadataQuery mq) {
Double lowest = Double.POSITIVE_INFINITY;
for (RelNode node : rel.getRels()) {
  Double maxRowCount = mq.getMaxRowCount(node);
  if (maxRowCount == null) {
continue;
  }
  if (lowest.compareTo(maxRowCount) > 0) {
lowest = maxRowCount;
  }
}
return lowest;
  }
{code}

What do you think about this ?

> Make metadata more robust
> -
>
> Key: CALCITE-1048
> URL: https://issues.apache.org/jira/browse/CALCITE-1048
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Following CALCITE-794, make metadata more robust and performant, so we can 
> safely derive metadata from a large RelNode graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CALCITE-1048) Make metadata more robust

2017-11-11 Thread Julian Hyde (JIRA) 

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

Julian Hyde commented on CALCITE-1048:
--

I don't remember what exactly we planned to do to fix this case; at a minimum, 
remove hacks such as the one you found.

Clearly RelMdMaxRowCount of a RelSubset should be the lowest max-row-count of 
any relational expression in that subset. Each kind of metadata should have a 
way of deriving a subset's value from the constituent rel values; in the case 
of RelMdMaxRowCount the roll-up function is "min".

I think that will handle Sort+limit automatically, I fear that if you put it in 
place it will cause some stack-overflow problems. 

> Make metadata more robust
> -
>
> Key: CALCITE-1048
> URL: https://issues.apache.org/jira/browse/CALCITE-1048
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Following CALCITE-794, make metadata more robust and performant, so we can 
> safely derive metadata from a large RelNode graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (CALCITE-1048) Make metadata more robust

2017-11-09 Thread Aman Sinha (JIRA) 

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

Aman Sinha commented on CALCITE-1048:
-

The comments in RelMdMaxRowCount point to this JIRA: 
{noformat}
  public Double getMaxRowCount(RelSubset rel, RelMetadataQuery mq) {
// FIXME This is a short-term fix for [CALCITE-1018]. A complete
// solution will come with [CALCITE-1048].
Util.discard(Bug.CALCITE_1048_FIXED);
...
  }
{noformat}

It seems the goal of this JIRA is much broader and I am not sure of its status. 
  For the RelSubset's  max row count, should we consider adding specific 
implementations similar to what was done for CALCITE-1018 (for sort with limit) 
?  For example,  if the RelSubset contains Aggregate with no group-by it will 
have a max rowcount of 1.  

> Make metadata more robust
> -
>
> Key: CALCITE-1048
> URL: https://issues.apache.org/jira/browse/CALCITE-1048
> Project: Calcite
>  Issue Type: Bug
>Reporter: Julian Hyde
>Assignee: Julian Hyde
>
> Following CALCITE-794, make metadata more robust and performant, so we can 
> safely derive metadata from a large RelNode graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)