That sqlite3 metric is interesting indeed. However even after the few upgrades to kdepim and korganizer since I opened this bug, hoping they would fix this critical problem, the problem is still present: korganizer 4:24.12.2-1 kdepim 4:24.12.2+5.158 kdepimruntime 4:24.12.2-1 akonadiserver 4:24.12.2-1
As a sidenote I upgraded my computer to a Ryzen 9 X3D, and I can noticeably see that when moving tasks or events around, it takes a few seconds less. Everything seems to point to the fact that this slow response time is CPU-bound. Not sure if this is related, but that bad Korganizer upgrade also broke at least 2 things: - When using tags with accents in it, Korganizer mangle it so that for instance "é" appears as "é", creating new faulty tags in the tags list. - Sometimes when you edit a calendar task or event, the tags are just plain removed (even if they do not contains any accent), which updates the events on Nextcloud, which are replicated without any tags on the correct Korganizer clients (from Debian stable). This is especially annoying on past meetings with other people where if you want to 'fix' the missing tag, you need to edit the event..which will send the 'update' to every attendees. Not possible in a work environement. To sum up, before having 10k+ event was not a problem, now it is. Where do we go from here? Regards, Alexandre Bonneau Le mardi 14 janvier 2025, 10:17:12 heure de Tahiti Soren Stoutner a écrit : > On Monday, January 13, 2025 7:09:06 PM MST Alexandre Bonneau wrote: > > > > Which database type are you using ? > > > > > > » dlg akonadi > > > rc akonadi-backend-mysql 4:22.12.2-1 > > > ii akonadi-backend-sqlite 4:24.12.0-2 > > I’m a little puzzled that you have 22.x for mysql and 24.x for sqlite. > Testing currently has 24.x for both of them. > > Although this doesn’t directly address your particular bug, which appears to > maybe be something that happens with large amounts of calendar entries, you > might be interested in the discussion about how much faster sqlite runs > compared to postgresql (and possibly mariadb). > > https://lists.debian.org/debian-kde/2024/12/msg00079.html
signature.asc
Description: This is a digitally signed message part.
