-
-
Notifications
You must be signed in to change notification settings - Fork 104
fix: Save msgs to key-contacts migration state and run migration periodically (#6956) #6981
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
Conversation
I measured again: without a limit, the migration takes 11.2s in total on my db (up from 5.6s when migrating only 10_000 messages). This result is similar to when I measured previous times (in previous measurements, without a limit, it took 13 resp. 14s, up from ~5 resp. 7 seconds with just 10_000 migrated messages). Therefore, I do think that doing things in background here is worth the effort, also because on Android, migrations are done on the main thread, and the system will ask the user whether to kill DC if it takes too long. |
Instead of migrating 10k contacts, can we only keep the table creation inside the migration and move actual from_id updates to some other place? Beginning of the inbox loop, for example, or housekeeping (which is however not run frequently enough, maybe we should schedule it to run after migration at least). There, always migrate 1k messages starting from the highest row ID on each run, until we reach row id 0. |
7860582
to
b6b8391
Compare
This comment was marked as outdated.
This comment was marked as outdated.
b6b8391
to
c840c7f
Compare
c840c7f
to
9ba9fd4
Compare
…LECT + Replace LIKE with GLOB, the latter is case-sensitive.
…odically (#6956) Save: - (old contact id) -> (new contact id) mapping. - The message id starting from which all messages are already migrated. Run the migration from `housekeeping()` for at least 500 ms and for >= 1000 messages per run.
9ba9fd4
to
717015a
Compare
See commit messages. This makes #6956 non-blocker at least. But i wonder if we need a background process to convert messages: if i replace
10_000
withu64::MAX
(i.e. convert all messages), the migration only takes extra 800 ms for my database. Please test on your dbs, maybe mine isn't huge enough.EDIT: Added a background process to
housekeeping()
. Fix #6956