You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The state machine powering the CardinalityOne operator currently assumes totally ordered input timestamps, s.t. when processed in time order (i.e. in the order that consolidate will reveal them), all keys end up in the correct state.
A solution might be to re-implement CardinalityOne as a special kind of arrange. This way we could use the trace handle to lookup the correct last value as of the input time, without having to maintain two traces per attribute.
The existing implementation should get rid of the additional sort and live on as CardinalityOneTotal, or something like that.
The text was updated successfully, but these errors were encountered:
The state machine powering the
CardinalityOne
operator currently assumes totally ordered input timestamps, s.t. when processed in time order (i.e. in the order thatconsolidate
will reveal them), all keys end up in the correct state.In fact, the current implementation is a bit stronger, in that it should still produce correct results on bitemporal inputs, as long as event times increase monotonically per key. This is due to an additional sort by event time after consolidation.
For general partially-ordered inputs this is not safe any longer.
A solution might be to re-implement
CardinalityOne
as a special kind ofarrange
. This way we could use the trace handle to lookup the correct last value as of the input time, without having to maintain two traces per attribute.The existing implementation should get rid of the additional sort and live on as
CardinalityOneTotal
, or something like that.The text was updated successfully, but these errors were encountered: