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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)