t; > > a max amount of state he's willing to store. This has
>> potential
>> > but
>> > > > > would
>> > > > > > > be a topic for a next FLIP, I added some information on that
>> > under
>> >
> would
> > > > > > > be a topic for a next FLIP, I added some information on that
> > under
> > > > the
> > > > > > > rejected alternatives.
> > > > > > >
> > > > > > > Kind regards,
> > > > &g
hrieb David Radley <
> > > > > > david_rad...@uk.ibm.com>:
> > > > > >
> > > > > > > Hi Gustavo,This sounds like a great idea.
> > > > > > > I notice the link limitations<
> > >
; https://confluentinc.atlassian.net/wiki/spaces/FLINK/pages/4342875697/FLIP-516+Multi-Way+Join+Operator#Limitations
> > > >
> > > > > > in the Flip points outside of the document to something I do not
> > have
> > > > > > access to. Please could y
; have
> > > > > access to. Please could you include the limitations in the flip
> > itself.
> > > > >
> > > > > You mention re ordered binary joins might be less efficient by
> > turning
> > > > > them into a multi join. I wonder wh
re ordered binary joins might be less efficient by
> turning
> > > > them into a multi join. I wonder what the pros and cons are. I
> wonder can
> > > > we use statistics to decide whether we should do a multi way join?
> In this
> > > > case we could hav
; > case we could have an enum configuration something like:
> > > table.optimizer.join= binary-join, multi-join, auto.
> > >
> > > Kind regards, David.
> > >
> > > From: Arvid Heise ar...@apache.org
> > > Date: Monday, 28 April 2025 at 12:47
> >
this
>> case we could have an enum configuration something like:
>> table.optimizer.join= binary-join, multi-join, auto.
>>
>> Kind regards, David.
>>
>>
>> From: Arvid Heise
>> Date: Monday, 28 April 2025 at 12:47
>> To: dev@flink.apache.org
>
ike:
> table.optimizer.join= binary-join, multi-join, auto.
>
> Kind regards, David.
>
>
> From: Arvid Heise
> Date: Monday, 28 April 2025 at 12:47
> To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: [DISCUSS] FLIP-516: Multi-Way Join Operator
> Hi Gustavo,
>
>
ration something like: table.optimizer.join=
binary-join, multi-join, auto.
Kind regards, David.
From: Arvid Heise
Date: Monday, 28 April 2025 at 12:47
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: [DISCUSS] FLIP-516: Multi-Way Join Operator
Hi Gustavo,
the idea and approach LGTM. +1 to p
Hi Gustavo,
the idea and approach LGTM. +1 to proceed.
Best,
Arvid
On Thu, Apr 24, 2025 at 4:58 PM Gustavo de Morais
wrote:
> Hi everyone,
>
> I'd like to propose FLIP-516: Multi-Way Join Operator [1] for discussion.
>
> Chained non-temporal joins in Flink SQL often cause a "big state issue"
11 matches
Mail list logo
