Let’s suppose that the information in HepRelVertex could somehow be moved into the RelNode. (Since the data structure is a DAG it seems plausible.) Now each RelNode would contain mutable state that relates to the HEP planner’s algorithm. That state needs to be managed (e.g. reinitialized when starting a new planner phase). It also makes RelNodes mutable, which seems to give permission for people to start adding more mutable state.
Also, remember that RelNodes and RelRules can be used, unchanged, by VolcanoPlanner. Externalizing the state makes this possible. When I started my career writing C, external lists seemed an extravagant use of memory. If a particular struct needed to be a member of 3 kinds of list, you added 3 pairs of next/previous pointers to each struct. One fewer indirection to get your data, but hours of debugging to manage the lifecycle. Internal state is usually a false economy. > On Feb 20, 2024, at 11:57 PM, Alessandro Solimando > <alessandro.solima...@gmail.com> wrote: > > Hi Ayaka, > I agree with Benchao, you can look at this article to get a sense on why a > data structure allowing node substitution is useful in query planning: > https://www.querifylabs.com/blog/memoization-in-cost-based-optimizers > > Best regards, > Alessandro > >> On Wed, 21 Feb 2024 at 05:55, Benchao Li <libenc...@apache.org> wrote: >> >> Ayaka, >> >> Per my understanding, HepRelVertex is used to make RelNode changeable >> easily, you can see more about HepRelVertex#replaceRel, it is used to >> change one RelNode to another after some rules applied and new equal >> node produced. In this way, we can easily change subgraphs of the >> original DAG after performing some RBO rules. >> >> >> Ayaka Kamisato <cyborgz1...@gmail.com> 于2024年2月19日周一 19:29写道： >>> >>> I'm studying Calcite recently and I found that RelNode Tree would be >>> converted to a DAG composed by HepRelVertex and Edge before the RBO rules >>> execution, and I don't understand why this step is necessary since >> RelNode >>> tree is a DAG essentially. >> >> >> >> -- >> >> Best, >> Benchao Li >>
