[jira] [Commented] (CALCITE-5286) Join with parameterized LIMIT throws AssertionError "not a literal"

[Ulrich Kramer (Jira)]

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

Ulrich Kramer commented on CALCITE-5286:
----------------------------------------

Hi [~jiajunbernoulli],

it's quite hard to reproduce this. It only occurs when the Join can't be pushed 
down and therefore both sides of the Join are presorted.
 The plan must look like this to reproduce this issue
{code}
Sort
    Join
        Sort(limit=?)
        Sort
{code}

In this case {{RelMdUtil.alreadySmaller}} calls {{mq.getMaxRowCount}} and this 
will fail because the inner {{Sort}} uses a dynamic parameter.

I think you need to add the same test as in {{RelMdUtil.alreadySmaller}}

{code}
    if (
    if (... || offset instanceof RexDynamicParam || fetch instanceof 
RexDynamicParam) {
      return false;
    }
{code}

to {{RelMdMaxRowCount.java:210}}

{code}
 if (!(sort.fetch == null || sort.offset instanceof RexDynamicParam || fetch 
sort.instanceof RexDynamicParam)) {
    return (double) RexLiteral.intValue(sort.fetch);
}
{code}


> Join with parameterized LIMIT throws AssertionError "not a literal"
> -------------------------------------------------------------------
>
>                 Key: CALCITE-5286
>                 URL: https://issues.apache.org/jira/browse/CALCITE-5286
>             Project: Calcite
>          Issue Type: Bug
>            Reporter: Ulrich Kramer
>            Assignee: Jiajun Xie
>            Priority: Major
>
> A query like the following one
> {code:java}
> select T."name", T."valueLeverId", T."type", T."ID", T."parentId" 
> from (
>   SELECT VD."id" as ID, VD."name", VD."typeId", VD."type", VD."valueLeverId", 
> VD."valueLever", VD."parentId", VDtoSC."VDtoSC_List"
>       FROM VD 
>       LEFT JOIN VDtoSC 
>       ON VD."id" = VDtoSC."Value_Driver_ID"
> ) AS T
> where T."ID" = ? limit ?
> {code}
> fails with
> {code:java}
> findValue:1208, RexLiteral (org.apache.calcite.rex)
> intValue:1183, RexLiteral (org.apache.calcite.rex)
> getMaxRowCount:207, RelMdMaxRowCount (org.apache.calcite.rel.metadata)
> getMaxRowCount_$:-1, GeneratedMetadata_MaxRowCountHandler 
> (org.apache.calcite.rel.metadata.janino)
> getMaxRowCount:-1, GeneratedMetadata_MaxRowCountHandler 
> (org.apache.calcite.rel.metadata.janino)
> getMaxRowCount:277, RelMetadataQuery (org.apache.calcite.rel.metadata)
> alreadySmaller:914, RelMdUtil (org.apache.calcite.rel.metadata)
> checkInputForCollationAndLimit:887, RelMdUtil 
> (org.apache.calcite.rel.metadata)
> onMatch:138, SortJoinTransposeRule (org.apache.calcite.rel.rules)
> onMatch:223, VolcanoRuleCall (org.apache.calcite.plan.volcano)
> drive:59, IterativeRuleDriver (org.apache.calcite.plan.volcano)
> findBestExp:523, VolcanoPlanner (org.apache.calcite.plan.volcano)
> lambda$standard$3:276, Programs (org.apache.calcite.tools)
> run:-1, Programs$$Lambda$2787/0x000000080121f9c0 (org.apache.calcite.tools)
> run:336, Programs$SequenceProgram (org.apache.calcite.tools)
> transform:373, PlannerImpl (org.apache.calcite.prepare)
> {code}
> The 2 tables are located in a schema where joins can't be pushed down.
> See also CALCITE-5048  --
> CALCITE-2061
>  



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