Query: Refactor GroupBy aggregate to avoid dependency on Requires Materialization

Question

Query: Refactor GroupBy aggregate to avoid dependency on Requires Materialization

smitpatel opened this issue 6 years ago · 9 comments

Answer 1 · 2018-05-22T23:06:31.000Z

@smitpatel is there a more general issue for "delayed requires materialization" that we talked about in planning or is this the one?

Answer 2 · 2018-05-22T23:27:55.000Z

@divega - We don't have tracking issue for that separately. Could be part of #7520

Answer 3 · 2018-05-22T23:33:47.000Z

@smitpatel ok, let's chat when we have a chance about how to best track it. If you add it to the list in #7520 that would be a good start.

Answer 4 · 2018-05-24T18:45:46.000Z

@divega - #11215 I added note to that issue.

Answer 5 · 2018-05-24T22:31:18.000Z

Make sure to test case in #11813

Answer 6 · 2018-06-12T23:52:42.000Z

Moved this into 2.2 since we believe it will help stabilize query. If, when working on it. it looks like it is going to have the opposite effect. then we should reconsider.

Answer 7 · 2019-06-05T23:40:05.000Z

We do not have requires materialization visitor anymore. So this is no longer needed. We can do needful when we re-implement group by aggregate.

Answer 8 · 2019-06-06T18:56:08.000Z

@smitpatel what does it exactly mean? Could you explain in simple terms?

Answer 9 · 2019-06-06T20:40:26.000Z

In old pipeline, we had to determine in advance if we need to materialize entity or we can server eval. For GroupBy when you are applying aggregate, entity materialization is not required. But with mixed mode evaluation, it was not possible to determine in all cases, if we can translate to SQL group by since some client function or not mapped property can cause client eval. Hence we were having issues when advance determination was incorrect. This issue was tracking it. Now in new pipeline we don't do advance determination of materialization so this issue is no longer relevant.