Be more agressive about purging old room event_push_actions

[erikjohnston]

There's no reason to keep a months worth of notifications after they've been read. While the pushers do use the table, they shouldn't be needing to send anything that has already been read.

We keep a months worth of highlights so that the notification API still works.

[erikjohnston]

Actually, the API does allow you to paginate on plain notifications, though I don't think anybody uses it.

[ara4n]

isn't this precisely what the notification tab does in riot/web?

…

-- Matthew Hodgson Matrix.org

On 1 Feb 2017, at 19:22, Erik Johnston ***@***.***> wrote: Actually, the API does allow you to paginate on plain notifications, though I don't think anybody uses it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[erikjohnston]

@ara4n They are just highlights I thought?

[NegativeMjark]

Capitalise "OR" please.

[NegativeMjark]

Apart from the capitalisation LGTM.

The query plans before and after are:

 Delete on event_push_actions  (cost=0.70..8.72 rows=1 width=6)
   ->  Index Scan using event_push_actions_rm_tokens on event_push_actions  (cost=0.70..8.72 rows=1 width=6)
         Index Cond: ((user_id = '?'::text) AND (room_id = '?'::text) AND (topological_ordering < ?) AND (stream_ordering < ?))

 Delete on event_push_actions  (cost=0.70..8.73 rows=1 width=6)
   ->  Index Scan using event_push_actions_rm_tokens on event_push_actions  (cost=0.70..8.73 rows=1 width=6)
         Index Cond: ((user_id = '?'::text) AND (room_id = '?'::text) AND (topological_ordering < ?))
         Filter: (((stream_ordering < ?) AND (highlight = 1)) OR (highlight = 0))

I don't think it matters that we're losing the stream_ordering from the index cond, since it'll need to scan for topological_ordering < ? in either case, and this should help performance because more of the stuff matching topological_ordering < ? will be deleted.