You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Weiqing Yang <ya...@gmail.com> on 2026/06/20 03:26:19 UTC
[DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Hi all,
I would like to restart the discussion thread for FLIP-497: Early Fire
Support for Flink SQL Interval Join.
As some of you may recall, this FLIP was originally proposed and went to a
vote last year. Because the thread has been open for over a year, I am
following the community's recommendation to kick off a fresh discussion
(Previous voting thread: Link
<https://lists.apache.org/thread/mw0tqgg1yx0mn8tf6msrgdtqbpdpgtpt>). This
will ensure the design is fully aligned with the current state of the
project and give everyone a chance to review it with fresh eyes.
The proposal itself is unchanged from the previous round, where it received
positive feedback and no outstanding objections (Link
<https://lists.apache.org/thread/dcn78blz7cqmmyypw897w0dvf6l58cnt>).
*Motivation (Recap)*:
In many streaming applications, particularly real-time analytics and
monitoring systems, it is valuable to obtain partial results earlier rather
than waiting for full join conditions to finalize. For Flink SQL interval
joins, results are typically delayed until watermarks ensure no more
matches can occur. This delay can be challenging for scenarios that require
fast feedback. Early fire support addresses this by emitting intermediate
results speculatively and using retractions or updates to maintain eventual
consistency and ensure correctness. This approach can, however, change an
append-only stream into a potentially update stream, so the planner and
downstream components must be able to handle retraction/upsert messages.
Proposal document (aligned with latest master branch): Link
<https://docs.google.com/document/d/1YobpNdnvzSsceniVj4NZWi445gb1-54Rox-D7nPArZo/edit?tab=t.0#heading=h.yp9ng89zwc1z>
Previous discussion thread: Link
<https://lists.apache.org/thread/p3w90rprdtv3vyjog3vl0rql5fvm703j>
Current implementation status: Following recent feedback from the
community, I have converted the existing implementation PR (Link
<https://github.com/apache/flink/pull/28353>) to a draft.
I welcome your renewed feedback, architectural insights, and any questions
to help refine this feature before we move toward a new voting phase.
Thanks,
Weiqing
Re: Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Yuepeng Pan <pa...@apache.org>.
Hi, Weiqing.
Thanks for re-pushing forward with this FLIP.
The content of the new edition +1 to me.
Best,
Yuepeng Pan
Xingcan Cui <xi...@gmail.com> 于2026年7月8日周三 07:59写道：
> 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 <ya...@gmail.com>
> 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 <xy...@163.com> 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" <ya...@gmail.com> 写道：
> > > >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
> > > >
> > > >>
> > >
> >
>
Re: Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Weiqing Yang <ya...@gmail.com>.
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 <ya...@gmail.com>
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 <xi...@gmail.com> 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 <ya...@gmail.com>
>> 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 <xi...@gmail.com> 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 <yangweiqing001@gmail.com
>> >
>> > > 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 <xy...@163.com> 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" <ya...@gmail.com>
>> 写道：
>> > > > > >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
>> > > > > >
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
Re: Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Weiqing Yang <ya...@gmail.com>.
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 <xi...@gmail.com> 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 <ya...@gmail.com>
> 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 <xi...@gmail.com> 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 <ya...@gmail.com>
> > > 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 <xy...@163.com> 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" <ya...@gmail.com>
> 写道：
> > > > > >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
> > > > > >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
Re: Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Xingcan Cui <xi...@gmail.com>.
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 <ya...@gmail.com>
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 <xi...@gmail.com> 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 <ya...@gmail.com>
> > 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 <xy...@163.com> 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" <ya...@gmail.com> 写道：
> > > > >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
> > > > >
> > > > >>
> > > >
> > >
> >
>
Re: Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Weiqing Yang <ya...@gmail.com>.
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 <xi...@gmail.com> 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 <ya...@gmail.com>
> 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 <xy...@163.com> 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" <ya...@gmail.com> 写道：
> > > >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
> > > >
> > > >>
> > >
> >
>
Re: Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Xingcan Cui <xi...@gmail.com>.
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 <ya...@gmail.com>
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 <xy...@163.com> 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" <ya...@gmail.com> 写道：
> > >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
> > >
> > >>
> >
>
Re: Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Weiqing Yang <ya...@gmail.com>.
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 <xy...@163.com> 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" <ya...@gmail.com> 写道：
> >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
> >
> >>
>
Re:Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Xuyang <xy...@163.com>.
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" <ya...@gmail.com> 写道：
>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
>
>>
Re: [DISCUSS] (Restarted) FLIP-497: Early Fire Support for Flink SQL Interval Join
Posted by Weiqing Yang <ya...@gmail.com>.
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
>