https://bugs.kde.org/show_bug.cgi?id=322083
Bug ID: 322083 Summary: CollectionSync always start a database transaction, even when no update needs to be done Classification: Unclassified Product: Akonadi Version: unspecified Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdepim-bugs@kde.org Reporter: alexpigna....@gmail.com Disclaimer: I'm not expert in akonadi codebase, so the terminology might not be 100% correct. CollectionSync derives from TransactionSequence, which means that all the Jobs added are wrapped in a database transaction. This probably make sense to guarantee correctness in case of concurrent updates. The problem is that a transaction is started even in the case when no updates needs to be made. The effect of this is that mysql (when it is the backend) is no longer able to optimize the load of the local collection data and needs to write book-keeping data on the log. This means that in the very frequent case of no updates needed (so, theoretically read only operation) mysqld will still be writing to disk, with an effect on system performance and battery usage. I'm not sure what could be a good solution to this problem, my guess is that it could make sense to operate in two phases: 1) Load the local collection without starting a transaction and compare with the remote one to see if anything needs to be updated 2) If needed, start a transaction and do the complete sync. This will cause overhead when updates are needed, but hopefully this is balanced by the optimization of the read only case. I think another possible solution would be to use explicit table locks, but akonadi currently seems to have no concept of locking. Reproducible: Always Steps to Reproduce: 1. Add an IMAP resource that is polled regularly 2. Watch akonadi mysqld process with strace, grep for 'pwrite' Actual Results: I can see write operations happening when apparently no new mails are arriving Expected Results: Read only operations should be read-only -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Kdepim-bugs mailing list Kdepim-bugs@kde.org https://mail.kde.org/mailman/listinfo/kdepim-bugs