Hi Sedat, hi. Please no carbon copy.
Sedat Dilek - 13.10.24, 02:08:13 MESZ: > KMail2 version 6.2.x (24.08.x) uses as default SQLite akonadi-backend. > > With previous KMail I used PostgreSQL akonadi-backend. > > Now, I switched back from SQLite to PostgeSQL backend for akonadi. Why? In my experience so far SQLite3 backend goes circles around PostgreSQL backend regarding performance. It is so much faster. Also the strange delays during POP3 mail retrieval have completely gone. For me it is like having bought a completely new engine for my car – luckily it does not need one cause the existing one works just great. I am still amazed by the difference it made. I did have a few crashes of Akonadi server during heavy indexing load, but I am amazed cause it seems like for the first time ever I can basically leave the indexing agent activated instead of chmod'ing it to 000. I also do not know whether the crashes are related to SQLite3 backend or something else. > KMail2 now complains about a not-defined SENT folder when composing a > NEW email. You need to check sent-mail folder in your identity under "Extended" or something like that (translated from German). Before you do that, look carefully what is set there at the moment. This folder would be the one your sent mails went to. Reason for that is: If you replace the database without using the database migrator, the database IDs for the folders are changed. Akonadi does not use some kind of immutable UUIDs in the configuration that it would store in remote storage as well, but the index number from the database. That is also the reason why, if you change database without migrator and you have local mail filters, it is best to export them, delete them then from KMail configuration, change the database and import them back in once Akonadi scanned for all the local folders. Cause the export is by name of the folder and it is more likely you end up with correct folders this way. Also if KMail is configured about database IDs of folders in filter rules it tends to ask for each filter rules which if you have many folders can take a lot of your time. As you entrust Google with the privacy of your mails you are probably not using local filters. As for the database migrator, I am not yet completely sure whether it is already implemented completely. It is planned for sure. Daniel has been at least partly paid for it by g10 Code GmbH the company behind GnuPG and co. Ah, the tool seems to be called akonadi-db-migrator. It seems it could work. Not sure whether it is safe to use at the moment. The forum thread Migrate akonadi to sqlite from postgres https://discuss.kde.org/t/migrate-akonadi-to-sqlite-from-postgres/7094/3 refers to January and February in KDE PIM https://kontact.kde.org/blog/2024/2024-03-01-kde-pim-january-february-2024/ which hints at that the DB migrator is ready since Akonadi 24.05. We have 24.08.2 so is probably save to use. But no warranties from my side. Better stop Akonadi and make a backup of Akonadi server configuration in ~/.config/akonadi/akonadiserverrc and the database stuff in ~/.local/ share/akonadi before trying to use it. However, in your case it might be easier to just correct the folder settings in identify as you basically switched DB engine anyway already. But the next time you would consider migrating the DB engine, you could use the tool. Best, -- Martin
