Thanks Jincheng,
I think approach 3 there is no ambiguity in the semantics and can better
explain a deterministic result, although it is not so easy to use.
So I'm +1 to approach 3.
Best,
Jark
On Fri, 5 Jul 2019 at 18:13, jincheng sun wrote:
> Hi,
>
> @Kurt @Jark thanks again for your comments
Hi,
@Kurt @Jark thanks again for your comments.
@Kurt
Separating key and non-key for UDTAGG can definitely provide more
information for the system, however, it will also add more burden to our
users and bring some code reuse problems. BTW, approach 3 can also be used
to separate UDTAGG into keyed
Hi Hequn,
> If the TopN table aggregate function
> outputs three columns(rankid, time, value), either rankid or rankid+time
could be
> used as the key. Which one to be chosen is more likely to be decided by
the user
> according to his business.
In this case, the TopN table aggregate function shoul
Hi Kurt and Jark,
Thanks a lot for your great inputs!
The keys of the query may not strongly be related to the UDTAGG.
It may also be related to the corresponding scenarios that a user wants to
achieve.
For example, take TopN again as an example. If the TopN table aggregate
function
outputs thre
Hi jingcheng,
I agree with Kurt's point. As you said "the user must know the keys of the
output of UDTAGG clearly".
If I understand correctly, the key information is strongly relative to the
UDTAGG implementation.
Users may call `flatAggregate` on a UDTAGG instance with different keys
which may re
Hi Jincheng,
Thanks for the clarification. I think you just pointed out my concern by
yourself:
> When a user uses a User-defined table aggregate function (UDTAGG), he
must understand the behavior of the UDTAGG, including the return type and
the characteristics of the returned data. such as the k
Hi All,
@Kurt Young one user-defined table aggregate function
can be used in both with(out) keys case, and we do not introduce any other
aggregations. just like the explanation from @Hequn.
@Hequn Cheng thanks for your explanation!
One thing should be mentioned here:
When a user uses a User-d
Hi Kurt,
Thanks for your questions. Here are my thoughts.
> if I want to write such kind function, should I make sure that this
function is used with some keys?
The key information may not be used. We can also use RetractSink to emit
the table directly.
> If I need a use case to calculate topn
Hi Jincheng,
Thanks for the clarification. Take 'TopN' for example, if I want to write
such kind function,
should I make sure that this function is used with some keys? If I need a
use case to calculate
topn without key, should I write another function or I can reuse previous
one.
I'm not sure ab
Hi Kurt,
Thanks for your questions, I am glad to share my thoughts here:
My question is, will that effect the logic ofTableAggregateFunction user
> wrote? Should the user know that there will a key and make some changes to
> this function?
No, the keys information depends on the implementation
Hi,
I have a question about the key information of TableAggregateFunction.
IIUC, you need to define
something like primary key or unique key in the result table of
TableAggregateFunction, and also
need a way to let user configure this through the API. My question is, will
that effect the logic of
Hi hequn, Thanks for the reply! I think `withKeys` solution is our better
choice!
Hequn Cheng 于2019年6月26日周三 下午5:11写道：
> Hi Jincheng,
>
> Thanks for raising the discussion!
> The key information is very important for query optimizations. It would be
> nice if we can use upsert mode to achieve be
Hi Jincheng,
Thanks for raising the discussion!
The key information is very important for query optimizations. It would be
nice if we can use upsert mode to achieve better performance.
+1 for the `withKeys` proposal. :)
Best, Hequn
On Wed, Jun 26, 2019 at 4:37 PM jincheng sun
wrote:
> Hi all
13 matches
Mail list logo
