Hi Rui,
I'm glad that the fix was useful.
Thanks,
Igor
On Thu, Dec 12, 2019 at 8:16 PM Rui Wang wrote:
> Absolutely. Thanks lgor for the contribution! :)
>
>
> -Rui
>
> On Wed, Dec 11, 2019 at 10:54 PM Stamatis Zampetakis
> wrote:
>
> > So basically thanks to Igor :)
> >
> > On Wed, Dec 11,
Absolutely. Thanks lgor for the contribution! :)
-Rui
On Wed, Dec 11, 2019 at 10:54 PM Stamatis Zampetakis
wrote:
> So basically thanks to Igor :)
>
> On Wed, Dec 11, 2019 at 9:56 PM Rui Wang wrote:
>
> > Thanks Stamatis's suggestion. Indeed a recent effort in [1] enhanced the
> > support
So basically thanks to Igor :)
On Wed, Dec 11, 2019 at 9:56 PM Rui Wang wrote:
> Thanks Stamatis's suggestion. Indeed a recent effort in [1] enhanced the
> support that reconstructs ROW in the top SELECT, which is supposed to solve
> the problem.
>
>
>
> [1]:
Thanks Stamatis's suggestion. Indeed a recent effort in [1] enhanced the
support that reconstructs ROW in the top SELECT, which is supposed to solve
the problem.
[1]: https://jira.apache.org/jira/browse/CALCITE-3138
On Mon, Dec 9, 2019 at 3:21 PM Rui Wang wrote:
> Hello,
>
> Sorry for the
Hello,
Sorry for the long delay on this thread. Recently I heard about requests on
how to deal with STRUCT without flattening it again in BeamSQL. Also I
realized Flink has already disabled it in their codebase[1]. I did try to
remove STRUCT flattening and run unit tests of calcite core to see
It might not be minor, but it’s worth a try. At optimization time we treat all
fields as fields, regardless of whether they have complex types (maps, arrays,
multisets, records) so there should not be too many problems. The flattening
was mainly for the benefit of the runtime.
> On Sep 5,
Thanks for your helpful response! It seems like disabling the flattening
will at least affect some rules in optimization. It might not be a minor
change.
-Rui
On Wed, Sep 5, 2018 at 4:54 AM Stamatis Zampetakis
wrote:
> Hi Rui,
>
> Disabling flattening in some cases seems reasonable.
>
> If I
Hi Rui,
Disabling flattening in some cases seems reasonable.
If I am not mistaken, even in the existing code it is not used all the time
so it makes sense to become configurable.
For example, Calcite prepared statements (CalcitePrepareImpl) are using the
flattener only for DDL operations that
Flattening was introduced mainly because the original engine used flat
column-oriented storage. Now we have several ways to executing,
including generating java code.
Adding a mode to disable flattening might make sense.
On Tue, Sep 4, 2018 at 12:52 PM Rui Wang wrote:
>
> Hi Community,
>
> While
Hi Community,
While trying to support Row type in Apache Beam SQL on top of Calcite, I
realized flattening Row logic will make structure information of Row lost
after Projections. There is a use case where users want to mix Beam
programming model with Beam SQL together to process a dataset. The
10 matches
Mail list logo
