Hi David, I will try to reply briefly to your questions:
A1: Yes there may be plan differences between Volcano and HepPlanner even if you apply the same rules. Volcano advances based on the cost and may not even apply all rules while the HepPlanner exhaustively executes all matching rules till a fixpoint. Moreover, you can get a different plan (for the same rules) even if you use only HepPlanner by changing the order of the rules or the way they match (bottom-up, top-down, etc.). A2: Most production systems use multiphase (more than two) optimization interchanging HepPlanner with VolcanoPlanner. In many cases the HepPlanner is used first applying some well-known heuristics (filter/projection pushdown, etc.) and the result is fed to Volcano. This helps keep optimization times low and allows to incorporate use-case specific logic that is not always possible to achieve if you put all the rules in one phase/planner. A3: Bindable is closer to interpret execution, while Enumerable is compiled execution. There are many articles/papers online explaining the difference between interpreted and compiled execution. Enumerable is used more by third-party projects so it should be more stable than the Bindable convention. A4: I think it is covered by A3. A5: Volcano and HepPlanner do not have any dependency to the storage/filesystem or DBMS where the data may be stored. A6: If something is not necessary for the execution of a plan then it doesn't need to appear in the explain output. Best, Stamatis On Tue, May 4, 2021 at 8:04 AM DAVID DALI SUSANIBAR ARCE <[email protected]> wrote: > Hi Team, > > Please if you could help me to clarify my doubts about using HepPlanner & > VolcanoPlanner for our CBO implementation > > My current Process: > ================== > 1. Generate initial RelNode basic optimization > 2. Use RBO HepPlanner to optimize the initial RelNode applying out of the > box rules (example: ProjectTableScanRule, FilterTableScanRule, others) > > > Proposed next step to replace HepPlanner with VolcanoPlanner: CBO = RBO + > Cost (getStatistic()): > > ============================================================================================== > > 1. Generate initial RelNode basic optimization > > 2. Configure Table (Statistic getStatistic()) to support statistics values > (example: rowcount per tables) > > 3. Instantiate CBO VolcanoPlanner to optimize the RelNode with the same > configured rules that we are using for HepPlanner (example: > ProjectTableScanRule, FilterTableScanRule, others) > Question (1): Are there some differences if we apply exactly the same > initial rules configured for HepPlanner now for VolcanoPlanner? > Question (2): Is it ok to apply volcano planner to initial relNode with > basic optimization? Or Do we should apply volcanoplanner to relnode that > result to apply HepPlaner and then use that output as an input relnode to > apply then volcano planner? > > 4. Change traits, we could use: BindableConvention or EnumerableConvention > Question (3): What could be my process to decided to use BindableConvention > instead of EnumerableConvention? > Question (4): Are these convention BindableConvention or > EnumerableConvention only a 'naming convention'? It means: > LogicalTableScan = BindableTableScan = EnumerableTableScan? > Question (5): Is volcano planner relnode result independently for the > database type (Is volcano planner coupled to the database)? It means at the > end: Is volcanoplanner only consider rules RBO hep planner + cost defined > on getStatistic (rowcount / io / cpu) and any database dependency for the > cpst result? > > 5. Obtain volcano planner relnode with rules and cost thru: return > planner.chooseDelegate().findBestExp() > > 6. In our result for somes volcano planner otimization we are seeing that > BindableTableScan appear. > Question (6): Are there some problems related to show us the "aliases" on > the plan? We are seeing the table, projects but aliases won't appear > - Current: BindableTableScan(table=[[main, supplier]], projects=[[0]]): > rowcount = 5000000.0, cumulative cost = {16666.666666666664 rows, 16666.67 > cpu, 0.0 io}, id = 62 > - Expect: BindableTableScan(table=[[main, supplier]], projects=[[0]], > aliases=[[s_suppkey]]): rowcount = 5000000.0, cumulative cost = > {16666.666666666664 rows, 16666.67 cpu, 0.0 io}, id = 415 > > Thank you in advance for your support. > > Best regards. > > David > > -- > "Este mensaje y sus anexos van dirigidos exclusivamente a la persona o > > entidad que se muestra como destinatario/s y pueden contener datos > personales y/o información confidencial, sometida a secreto profesional o > > cuya divulgación esté prohibida en la legislación > vigente. Que > <http://www.ctic.uni.edu.pe/>da prohibida, toda divulgación, reproducción > u > otra acción > al respecto por parte de personas o entidades distintas al > destinatario/s. Si ha recibido este mensaje por error, por favor, > contáctenos a la siguiente dirección de correo electrónico > [email protected] > <mailto:[email protected]> y proceda a su eliminación. > > > > En cumplimiento a > lo establecido en la Ley de Protección de Datos > Personales - Ley N° 29733, > le informamos que sus datos personales > obtenidos son almacenados bajo la > confidencialidad y las medidas de > seguridad legalmente establecidas y no > serán cedidos ni > compartidos con empresas ni entidades ajenas a la > Universidad Nacional > de Ingeniería. Si lo desea, usted podrá ejercitar los > derechos de > actualización, inclusión, rectificación, supresión u > oposición, enviando > un mensaje al correo electrónico anteriormente > > señalado e indicando en el "Asunto" el derecho que desea ejercer" >
