Feat(optimizer): propagate constants

[georgesittas]

Motivated by SQLite: https://www.sqlite.org/optoverview.html.

Perhaps we can treat casts as "constant expressions" and do the same for them, e.g.

x = CAST(5 AS BIGINT) AND y = x -- => x = CAST(5 AS BIGINT) AND y = CAST(5 AS BIGINT)

[barakalon]

Is replacement right? That takes it a step further than the sqlite rule, which says it just adds the extra predicate.

Do any planners take advantage of column equality in join conditions?

[georgesittas]

I thought SQLite does the variable replacement as well, but I'm not 100% sure. Will need to check their source to verify this assumption.

[barakalon]

The example doesn’t show replacement. I also wonder if there is different behavior on join conditions.

[georgesittas]

Yeah, will dig deeper. Also a good catch, thanks!

[georgesittas]

Btw I've discovered that there are some gnarly cases that are tricky to take care of - mostly because of coercions (e.g. int to string - see SQLite documentation linked below).

I also wonder if there is different behavior on join conditions.

Interestingly, SQLite doesn't seem to implement this transformation for ON clauses of LEFT, RIGHT joins:

      ...
      /* Do not propagate constants on any ON clause if there is a
      ** RIGHT JOIN anywhere in the query */
      x.mExcludeOn = EP_InnerON | EP_OuterON;
    }else{
      /* Do not propagate constants through the ON clause of a LEFT JOIN */
      x.mExcludeOn = EP_OuterON;
      ...

I'll need to understand their code a bit better to make sure this is the case though..

Some documentation on SQLite's implementation can be found here (screenshot of their source code).

On the other hand, MariaDB mentions this transformation in the context of WHERE clauses, but towards the end of the page they also have this (note the remark about ON expressions):

[georgesittas]

Regarding

The example doesn’t show replacement

It's now clear that SQLite does indeed replace the variable with the value:

[georgesittas]

We discussed about this PR in Slack and decided to keep the constant propagation rule opt-in for now, as it's relatively unstable and needs some more investigation / polishing.