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
> > > > >
> > > > >>
> > > >
> > >
> >
>
