Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop state_events and rejections tables #11496

Open
3 of 5 tasks
matrixbot opened this issue Dec 19, 2023 · 0 comments
Open
3 of 5 tasks

Drop state_events and rejections tables #11496

matrixbot opened this issue Dec 19, 2023 · 0 comments

Comments

@matrixbot
Copy link
Collaborator

matrixbot commented Dec 19, 2023

This issue has been migrated from #11496.


Both state_events and rejections are tables which add a single piece of data to a subset of events (state_key and reason, respectively).

I believe this would better handled with nullable columns in the events table:

  • state_events and rejections are never read from without a join to events, so we can save a join whereever we read from them
  • it's not like adding the data to events is going to transform it from a small, cacheable table to something huge (so I don't expect much difference in the case where we don't join to rejections or state_events). In any case, when we look in events we normally want the rejection status too.
  • obviously, populating three tables (and maintaining two extra indexes) is extra work to do when storing events.

However, getting from here to there is not an easy task by any means, and will take quite a bit of work to do in a way that doesn't break backwards compatibility. Here are the tasks as far as I can see them:

  • disambiguate any references to the state_key column, in preparation for adding new columns to events: Dummy issue #11497
  • Add state_key and rejection_reason columns to events, and populate them for all new events: Dummy issue #11792
  • Add a background update to populate state_key and rejection_reason for all existing events: Dummy issue #13215
  • Add some code which determines if the background update has completed, and if so, sets a flag which makes reads use the new columns instead of joining to the old tables.
  • Add some more code which drops the old tables and stops populating them.

Each of those steps will require SCHEMA_VERSION and/or SCHEMA_COMPAT version updates to ensure that we never break compatibility with the previous Synapse release.

@matrixbot matrixbot changed the title Dummy issue Drop state_events and rejections tables Dec 21, 2023
@matrixbot matrixbot reopened this Dec 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant