Very cool work, look forward to contribute.
-Original Message-
From: Chiwan Park [mailto:chiwanp...@apache.org]
Sent: Friday, January 8, 2016 9:36 AM
To: dev@flink.apache.org
Subject: Re: Effort to add SQL / StreamSQL to Flink
Really good! Many people want to use SQL. :)
> On Jan 8, 201
Really good! Many people want to use SQL. :)
> On Jan 8, 2016, at 2:36 AM, Kostas Tzoumas wrote:
>
> Wow! Thanks Fabian, this looks fantastic!
>
> On Thu, Jan 7, 2016 at 4:35 PM, Stephan Ewen wrote:
>
>> Super, thanks for that detailed effort, Fabian!
>>
>> On Thu, Jan 7, 2016 at 3:40 PM, Ma
Wow! Thanks Fabian, this looks fantastic!
On Thu, Jan 7, 2016 at 4:35 PM, Stephan Ewen wrote:
> Super, thanks for that detailed effort, Fabian!
>
> On Thu, Jan 7, 2016 at 3:40 PM, Matthias J. Sax wrote:
>
> > Pretty cool!
> >
> > On 01/07/2016 03:05 PM, Fabian Hueske wrote:
> > > Hi everybody,
Hi Martin,
thanks for your input!
On 7 January 2016 at 09:36, Martin Junghanns
wrote:
> Hi,
>
> this would be a very nice addition! I had a glimpse look into the PC
> implementation and the two library algorithms and when you get the
> idea, it is easy to follow what's happening. The benchmark
Hi everybody,
in the last days, Timo and I refined the design document for adding a SQL /
StreamSQL interface on top of Flink that was started by Stephan.
The document proposes an architecture that is centered around Apache
Calcite. Calcite is an Apache top-level project and includes a SQL parser
Hi Arjun,
welcome to the Flink community :-)
On Thu, Jan 7, 2016 at 5:40 AM, Arjun Rao wrote:
> Hi,
>
> I am new to Apache Flink and I really like the look of the API. I have been
> working with Storm for the past year and have questions about the
> DataStream API among others.
>
> 1. What are
Hi,
+1
I think it would be a good idea to separate the 2 state backends. I think
you are right in most cases the new partitioned state implementations will
benefit from this as it removes a lot of additional overhead (although
sometimes it's nice to have the 2 together, for instance if they both
Hi,
I’m currently examining ways to 1) change the window operators to use the
partitioned state abstraction for window state and 2) implement state backends
for managed memory/out-of-core state.
I think it would be helpful to pull the state backend apart. Right now, for
example, the DbStateBack
Hi,
this would be a very nice addition! I had a glimpse look into the PC
implementation and the two library algorithms and when you get the
idea, it is easy to follow what's happening. The benchmark results are
also very promising.
I got some questions about partitions:
1) I was wondering if the
