[
https://issues.apache.org/jira/browse/CALCITE-7549?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18083419#comment-18083419
]
Shikha edited comment on CALCITE-7549 at 5/27/26 7:37 AM:
----------------------------------------------------------
Thanks, that makes sense. I was treating the listener as part of the program
definition, but it is really runtime/session state.
I’m thinking of changing the approach so the listener is not passed to
Programs.of at all. Instead, callers would continue to attach the listener to
the runtime planner for the current planning session:
planner.addListener(listener);
Program program = Programs.of(hepProgram, noDag, metadataProvider);
program.run(planner, rel, traits, materializations, lattices);
Then, inside the existing Programs.of(HepProgram, boolean, RelMetadataProvider)
implementation, when it creates the internal HepPlanner, it would propagate the
listener from the runtime planner passed to Program.run.
if (planner instanceof AbstractRelOptPlanner) {
RelOptListener listener = ((AbstractRelOptPlanner) planner).getListener();
if (listener != null) {
hepPlanner.addListener(listener);
}
}
This keeps Program stateless and reusable, while preserving the listener’s
session lifetime. It also makes the behavior generally useful: any listener
registered on the runtime planner will receive events from the internal HEP
planner used by this program, rather than requiring a special Programs.of
overload with listener.
If this direction sounds reasonable, I’ll remove the new overload and update
the test to register the listener on the planner passed into Program.run, then
verify that HEP rule events are forwarded through that session listener.
was (Author: JIRAUSER313311):
Thanks, that makes sense. I was treating the listener as part of the program
definition, but it is really runtime/session state.
I’m thinking of changing the approach so the listener is not passed to
Programs.of at all. Instead, callers would continue to attach the listener to
the runtime planner for the current planning session:
planner.addListener(listener);
Program program = Programs.of(hepProgram, noDag, metadataProvider);
program.run(planner, rel, traits, materializations, lattices);
Then, inside the existing Programs.of(HepProgram, boolean, RelMetadataProvider)
implementation, when it creates the internal HepPlanner, it would propagate the
listener from the runtime planner passed to Program.run.
This keeps Program stateless and reusable, while preserving the listener’s
session lifetime. It also makes the behavior generally useful: any listener
registered on the runtime planner will receive events from the internal HEP
planner used by this program, rather than requiring a special Programs.of
overload with listener.
If this direction sounds reasonable, I’ll remove the new overload and update
the test to register the listener on the planner passed into Program.run, then
verify that HEP rule events are forwarded through that session listener.
> Add Programs.of overload that accepts RelOptListener
> ----------------------------------------------------
>
> Key: CALCITE-7549
> URL: https://issues.apache.org/jira/browse/CALCITE-7549
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Shikha
> Assignee: Shikha
> Priority: Minor
> Labels: pull-request-available
>
> Programs.of(HepProgram, boolean, RelMetadataProvider) constructs a HepPlanner
> internally with no way to attach a RelOptListener before findBestExp(). This
> makes it impossible to observe rule firings when composing phases via
> Programs.sequence.
> Proposal: Add an overload Programs.of(HepProgram, boolean,
> RelMetadataProvider, RelOptListener) that attaches the listener to the
> internally-constructed HepPlanner before calling setRoot/findBestExp. When
> listener is null, behavior is identical to the existing method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
