claudevdm commented on PR #34824: URL: https://github.com/apache/beam/pull/34824#issuecomment-2850810697
> > > Just out of curiosity, what's wrong with not having a PaneInfoCoder. I see the issue #34826, but does FastPrimitiveCoder still work? > > > > > > FastPrimitiveCoder ends up falling back to PickleCoder and much bigger encodings. PaneInfoCoder encodes it using 1 byte. > > I don't get why we need to expose `PaneInfoCoder` because I don't think we want cx to use it (or mess with it). `PaneInfoCoder` should implicitly be part of `WindowValueCoder` according to runner api proto ( > > https://github.com/apache/beam/blob/c9a0e9081543953ae581b4b0e6bc1a2045405a47/model/pipeline/src/main/proto/org/apache/beam/model/pipeline/v1/beam_runner_api.proto#L938 > > ). > I may be missing some important piece of background in #34348, but regarding > > https://github.com/apache/beam/blob/c9a0e9081543953ae581b4b0e6bc1a2045405a47/sdks/python/apache_beam/transforms/util.py#L955 > > can we do the following? > > ```python > return key, window.GlobalWindows.windowed_value(value, timestamp, pane_info) > ``` > > In this case, the coder of this output will be `KVCoder[KeyCoder, WindowedValueCoder[GlobalWindowCoder, ValueCoder]]`, instead of `KVCoder[KeyCoder, TupleCoder[ValueCoder, TimeStampCoder, PaneInfoCoder]]`. That logic specifically avoids the window param for performance reasons https://github.com/apache/beam/pull/4933. See the comments > # In this (common) case we can use a trivial trigger driver > # and avoid the (expensive) window param. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
