You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@calcite.apache.org by Vladimir Ozerov <pp...@gmail.com> on 2020/08/11 13:12:46 UTC

RelFieldTrimmer misses optimization opportunity for always false condition

Hi colleagues,

Consider the following query. If the RelFieldTrimmer is applied to this,
then the expression is reduced to an empty LogicalValues:
SELECT field FROM table WHERE TRUE IS FALSE

However, the following query will not be simplified, leaving a table scan
with "always false" filter:
SELECT * FROM table WHERE TRUE IS FALSE

After some debugging I found that the problem is in the following piece of
code in the RelFieldTrimmer:

// If the input is unchanged, and we need to project all columns,
// there's nothing we can do.
if (newInput == input
    && fieldsUsed.cardinality() == fieldCount) {
  return result(filter, Mappings.createIdentity(fieldCount));
}

My question - is it a known issue? Looks like this early return from the
method misses an important optimization opportunity.  Can this check be
removed completely?

Regards,
Vladimir

Re: RelFieldTrimmer misses optimization opportunity for always false condition

Posted by chunwei <ch...@apache.org>.

Thanks for reporting this, Vladimir.  You can file a JIRA for it.

Best,
Chuwnei



On Wed, Aug 12, 2020 at 12:06 AM Julian Hyde <jh...@gmail.com> wrote:

> I’m not entirely sure why RelFieldTrimmer doesn’t touch the “*” case.
> Perhaps because its main job is to trim fields, and so if there’s no field
> trimming to be done, it tries to do no harm.
>
> The main code responsible for pruning empty relational operators is
> PruneEmptyRules. I think you should apply these.
>
> Julian
>
> > On Aug 11, 2020, at 6:13 AM, Vladimir Ozerov <pp...@gmail.com> wrote:
> >
> > Hi colleagues,
> >
> > Consider the following query. If the RelFieldTrimmer is applied to this,
> > then the expression is reduced to an empty LogicalValues:
> > SELECT field FROM table WHERE TRUE IS FALSE
> >
> > However, the following query will not be simplified, leaving a table scan
> > with "always false" filter:
> > SELECT * FROM table WHERE TRUE IS FALSE
> >
> > After some debugging I found that the problem is in the following piece
> of
> > code in the RelFieldTrimmer:
> >
> > // If the input is unchanged, and we need to project all columns,
> > // there's nothing we can do.
> > if (newInput == input
> >    && fieldsUsed.cardinality() == fieldCount) {
> >  return result(filter, Mappings.createIdentity(fieldCount));
> > }
> >
> > My question - is it a known issue? Looks like this early return from the
> > method misses an important optimization opportunity.  Can this check be
> > removed completely?
> >
> > Regards,
> > Vladimir
>

Re: RelFieldTrimmer misses optimization opportunity for always false condition

Posted by Julian Hyde <jh...@gmail.com>.

I’m not entirely sure why RelFieldTrimmer doesn’t touch the “*” case. Perhaps because its main job is to trim fields, and so if there’s no field trimming to be done, it tries to do no harm. 

The main code responsible for pruning empty relational operators is PruneEmptyRules. I think you should apply these.

Julian

> On Aug 11, 2020, at 6:13 AM, Vladimir Ozerov <pp...@gmail.com> wrote:
> 
> Hi colleagues,
> 
> Consider the following query. If the RelFieldTrimmer is applied to this,
> then the expression is reduced to an empty LogicalValues:
> SELECT field FROM table WHERE TRUE IS FALSE
> 
> However, the following query will not be simplified, leaving a table scan
> with "always false" filter:
> SELECT * FROM table WHERE TRUE IS FALSE
> 
> After some debugging I found that the problem is in the following piece of
> code in the RelFieldTrimmer:
> 
> // If the input is unchanged, and we need to project all columns,
> // there's nothing we can do.
> if (newInput == input
>    && fieldsUsed.cardinality() == fieldCount) {
>  return result(filter, Mappings.createIdentity(fieldCount));
> }
> 
> My question - is it a known issue? Looks like this early return from the
> method misses an important optimization opportunity.  Can this check be
> removed completely?
> 
> Regards,
> Vladimir