[CALCITE-7549] Add Programs.of overload that accepts RelOptListener#4968
[CALCITE-7549] Add Programs.of overload that accepts RelOptListener#4968shikhae6 wants to merge 1 commit into
Conversation
|
mihaibudiu
left a comment
There was a problem hiding this comment.
We'll probably merge this after the 1.43 release
| * <p>If {@code listener} is not null, it is | ||
| * {@linkplain HepPlanner#addListener(RelOptListener) attached} | ||
| * to the planner before execution. */ | ||
| @SuppressWarnings("deprecation") |
There was a problem hiding this comment.
Can't this be done without calling deprecated functions?
|
I raised some concerns in the jira case. |
|
@shikhae6 Do you think this PR is still needed? |
|
@xiedeyantu I have proposed an alternate way in Jira , awaiting @julianhyde view on it |
|
@julianhyde 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. |



Jira Link
CALCITE-7549
Changes Proposed
When multiple HEP phases are composed via
Programs.sequence, eachphase constructs its
HepPlannerinternally with no hook to attach aRelOptListener. This prevents observing rule firings across sequencedoptimization phases — a requirement for query optimizer tracing and
observability tooling.
This PR adds a new overload to
Programs: