The answer depends on the definition of "wrong". Rules may produce non-equivalent operators, the validator may accidentally change how type is deduced for a specific expression, metadata may cause incorrect cost calculation and pruning of promising plans, leading to a hang in a downstream application.
Correctness and plan quality of real optimizers depend on all these components together. Versioning of only one type of the component (e.g., RelNode) is likely to be insufficient for an advanced optimizer, as there are many other sources of regressions. At the same time, some projects may definitively benefit from even limited versioning. With this in mind, IMO if we decide to add such versioning, it should be non-intrusive (i.e., require little to no efforts to disable it completely), so that the downstream projects retain enough flexibility on how to manage the optimizer's quality. Regards, Vladimir. вт, 14 дек. 2021 г. в 12:01, Vladimir Sitnikov <[email protected] >: > >some direct or indirect changes (metadata, rules, validator, etc) > >may cause changes to plans around the given RelNode in the downstream > >project > > Do you think changes like "metadata, rules, validator" can cause "wrong > results" issues? > What could be the issues caused by "metadata, rules, validator" changes? > > I know ObjectWeb ASM bytecode manipulation library uses the concepts of > versions for quite some time, and it seems to work for them. > > As you subclass, say, ClassVisitor, you have to pass the API version which > your visitor supports. > Then ASM fails in the runtime if the visitor happens to be applied with a > too recent bytecode. > > >and gets the source code of the test that he includes into his project and > CI > > Source code and bytecode parsing could be an alternative option (for other > cases), however, it is not clear how to tell > if the rule in question has been updated to support the new Project/Filter > contract. > > Vladimir >
