Skip to content
Snippets Groups Projects
  • Erik Johnston's avatar
    0d1d3e07
    Speed up `get_unread_event_push_actions_by_room` (#13005) · 0d1d3e07
    Erik Johnston authored
    Fixes #11887 hopefully.
    
    The core change here is that `event_push_summary` now holds a summary of counts up until a much more recent point, meaning that the range of rows we need to count in `event_push_actions` is much smaller.
    
    This needs two major changes:
    1. When we get a receipt we need to recalculate `event_push_summary` rather than just delete it
    2. The logic for deleting `event_push_actions` is now divorced from calculating `event_push_summary`.
    
    In future it would be good to calculate `event_push_summary` while we persist a new event (it should just be a case of adding one to the relevant rows in `event_push_summary`), as that will further simplify the get counts logic and remove the need for us to periodically update `event_push_summary` in a background job.
    0d1d3e07
    History
    Speed up `get_unread_event_push_actions_by_room` (#13005)
    Erik Johnston authored
    Fixes #11887 hopefully.
    
    The core change here is that `event_push_summary` now holds a summary of counts up until a much more recent point, meaning that the range of rows we need to count in `event_push_actions` is much smaller.
    
    This needs two major changes:
    1. When we get a receipt we need to recalculate `event_push_summary` rather than just delete it
    2. The logic for deleting `event_push_actions` is now divorced from calculating `event_push_summary`.
    
    In future it would be good to calculate `event_push_summary` while we persist a new event (it should just be a case of adding one to the relevant rows in `event_push_summary`), as that will further simplify the get counts logic and remove the need for us to periodically update `event_push_summary` in a background job.