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
Should we fully safeguard against queries getting too far ahead of backtracking? By limiting the end timestamp or filtering events when too far ahead. Noting that it also still needs to handle gaps bigger than the backtracking window in some way, otherwise will be stuck.
Possible optimisation to disable backtracking while queries have fallen behind. We would expect any delayed writes to already be there, when queries are further behind the backtracking window from current time already, so backtracking could be disabled to reduce load and give queries more opportunity to catch up, and then reactivate backtracking when query results are closer to current time again.
Should we fully safeguard against queries getting too far ahead of backtracking? By limiting the end timestamp or filtering events when too far ahead. Noting that it also still needs to handle gaps bigger than the backtracking window in some way, otherwise will be stuck.
Possible optimisation to disable backtracking while queries have fallen behind. We would expect any delayed writes to already be there, when queries are further behind the backtracking window from current time already, so backtracking could be disabled to reduce load and give queries more opportunity to catch up, and then reactivate backtracking when query results are closer to current time again.
See #69 (comment) for discussion.
The text was updated successfully, but these errors were encountered: