Hi all, Thanks for all the comments. I have incorporated the feedback into the FLIP document. If there are no further concerns, I'll start a VOTE early next week.
Best, Weiqing On Wed, Jul 8, 2026 at 4:57 PM Weiqing Yang <[email protected]> wrote: > Thanks, Xingcan. I agree that keeping the hint name generic is useful, but > the scope should be explicit so future extensions do not silently change > existing query behavior. Adding a `target` option sounds like a good way to > get both properties. > > For FLIP-497, I would define: `EARLY_FIRE('target'='interval_join', > 'delay'='5s', 'time_mode'='rowtime')` > > where `interval_join` is the only supported target in this FLIP. Future > operators, such as window joins, would need to introduce their own target > value in a separate FLIP. > > One small clarification: `target` scopes the hint to an operator kind > (here, interval joins), not to one specific join when a query contains > several. So it prevents future cross-operator ambiguity, while targeting an > individual join can remain future work if needed. > > I'll update the FLIP doc accordingly before starting the vote. > > Best, > Weiqing > > On Wed, Jul 8, 2026 at 7:57 AM Xingcan Cui <[email protected]> wrote: > >> Hi Weiqing, >> >> Thanks for the explanation! I agree that a generic name is better for >> future reuse. >> >> However, starting with a purely global hint introduces a >> backward-compatibility risk. If a user writes a query today with a global >> EARLY_FIRE hint, and tomorrow we add early-fire support for another >> operator, that same query's behavior will silently change because the hint >> will suddenly apply to both operators. >> >> To prevent future regressions and avoid forcing users to split queries >> into >> views, what if we introduce a target parameter for the hint? >> >> SELECT /*+ EARLY_FIRE('target'='interval_join', 'delay'='5s', >> 'time_mode'='rowtime') */ >> >> Making the target explicit ensures complete predictability for complex >> topologies and safely future-proofs the API without breaking existing >> queries. >> >> What do you think? >> >> Best, >> Xingcan >> >> On Tue, Jul 7, 2026 at 10:58 PM Weiqing Yang <[email protected]> >> wrote: >> >> > Hi Xingcan, >> > >> > Thanks for the question. >> > >> > My intent is to keep EARLY_FIRE as a generic early-emission hint name, >> > while defining and implementing its behavior in FLIP-497 only for SQL >> > interval joins. >> > The reason I'd rather not rename it to something interval-join-specific >> is >> > that the core concepts in the hint, e.g. delay and time_mode, aren't >> > inherently tied to interval joins. They could naturally be reused by >> future >> > emit-capable join operators, such as window joins. >> > For the scope of FLIP-497: EARLY_FIRE is a SQL join hint and is >> implemented >> > only for interval joins. Window-aggregate early fire stays >> config-based, so >> > there's no collision there. If we later add early-fire support for other >> > join-family operators like window joins, that would be handled in a >> > separate FLIP, but I'd expect the same hint name to remain the natural >> fit >> > as long as the behavior follows the same early-emission/correction >> model. >> > Given that, a narrower name like INTERVAL_JOIN_EARLY_FIRE feels a bit >> too >> > specific. >> > >> > Does this address your concern? I'm open to renaming it before the vote, >> > but my current preference is to keep EARLY_FIRE and clarify the scope. >> > >> > Thanks, >> > Weiqing >> > >> > On Tue, Jul 7, 2026 at 5:00 PM Xingcan Cui <[email protected]> wrote: >> > >> > > Hi Weiqing, >> > > >> > > Thanks for picking this back up! >> > > >> > > I only have one question: do you think we will reuse the hint >> > `EARLY_FIRE` >> > > for other operators and control the behahvior of them? If not, maybe >> we >> > > should give it a more specific name. >> > > >> > > Best, >> > > Xingcan >> > > >> > > On Mon, Jul 6, 2026 at 2:41 PM Weiqing Yang <[email protected] >> > >> > > wrote: >> > > >> > > > Thanks for taking another look and +1, Xuyang. >> > > > I'll leave the thread open a couple more days for any further >> comments, >> > > and >> > > > if there are no further concerns I'll start a VOTE. >> > > > >> > > > Best, >> > > > Weiqing >> > > > >> > > > On Mon, Jul 6, 2026 at 1:27 AM Xuyang <[email protected]> wrote: >> > > > >> > > > > Hi, Weiqing. >> > > > > Thanks for restarting this FLIP. Compared to the previous version, >> > the >> > > > > overall approach looks largely unchanged. +1. >> > > > > >> > > > > >> > > > > >> > > > > -- >> > > > > >> > > > > Best！ >> > > > > Xuyang >> > > > > >> > > > > >> > > > > >> > > > > 在 2026-07-06 14:13:22，"Weiqing Yang" <[email protected]> >> 写道： >> > > > > >Hi all, >> > > > > > >> > > > > >Gentle bump on this — I'd love another round of eyes before >> moving >> > to >> > > a >> > > > > >vote. >> > > > > > >> > > > > >The proposal is the same as before at a high level; what's new is >> > that >> > > > the >> > > > > >design has been re-aligned with current master, and the >> > implementation >> > > > now >> > > > > >targets the latest master branch. >> > > > > > >> > > > > >@Xuyang, @Xingcan, @Becket — thank you for the thorough review >> last >> > > > time. >> > > > > >Since you already know this proposal well, I'd really appreciate >> a >> > > quick >> > > > > >check that the points you raised still sit right in the current >> > > version. >> > > > > > >> > > > > >FLIP doc: >> > > > > > >> > > > > >> > > > >> > > >> > >> https://docs.google.com/document/d/1YobpNdnvzSsceniVj4NZWi445gb1-54Rox-D7nPArZo/edit >> > > > > > >> > > > > >Feedback is very welcome! >> > > > > > >> > > > > >Thanks, >> > > > > >Weiqing >> > > > > > >> > > > > >> >> > > > > >> > > > >> > > >> > >> >
