Re: KDEPIM with SQLite3

--nextPart7420583.JVnc33UoxL
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"; protected-headers="v1"
From: Soren Stoutner <[email protected]>
To: [email protected]
Subject: Re: KDEPIM with SQLite3
Date: Sat, 07 Mar 2026 16:26:56 -0700
Message-ID: <8911658.j2yymN00Pa@soren-desktop>
Organization: Debian
In-Reply-To: <6270156.lOV4Wx5bFT@laptop>
MIME-Version: 1.0

On Saturday, February 28, 2026 2:37:22=E2=80=AFPM Mountain Standard Time Ma=
rtin=20
Steigerwald wrote:
> Greetings Soren, greetings.
>=20
> Soren Stoutner - 28.02.26, 21:06:53 CET:
> > On Saturday, February 28, 2026 2:20:29=E2=80=AFAM Mountain Standard Tim=
e Martin
> >=20
> > Steigerwald wrote:
> > > Akonadi SQLite3 continues to be faster and more robust than with
> > > MariaDB or PostgreSQL for me. But unfortunately it is still not
> > > perfect. At least with POP3 mail retrieval there can still be quite
> > > odd delays. With a light IMAP account I have in another setup it
> > > works nicely.
> >=20
> > My personal experience is that with a large IMAP system (125 MiB
> > akonadi.db file) it freezes a lot with SQLite3, particularly when
> > deleting large amounts of emails.  Sometimes those freezes can last
> > minutes, during which, if further deletion of emails is attempted, they
> > GUI continues to display them.  In some instances, the deletions are
> > queued and later processed.  In other instances the deletions are never
> > processed.  I assume it is because the database is being compacted and
> > it takes a while to process.
>=20
> You did not have that with MariaDB or PostgreSQL? Do you see any Akonadi
> process activity? I think SQLite3 should be running within Akonadi's main
> process: /usr/bin/akonadiserver.

Yes, but the pause with MariaDB is more on the order of a second or less.

> Also I do not see any relevant KDEPIM / Akonadi process activity. It is
> just sitting there, idle. Or waiting on=E2=80=A6 whatever.

When this happened to me with SQLite3, there was not significant CPU or dis=
k=20
activity.  I didn=E2=80=99t spend much time looking into it, but my guess i=
s there is=20
some inefficient algorithm that is neither CPU nor disk bound that causes t=
he=20
deal.

=2D-=20
Soren Stoutner
[email protected]
--nextPart7420583.JVnc33UoxL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEJKVN2yNUZnlcqOI+wufLJ66wtgMFAmmstEAACgkQwufLJ66w
tgMlQw//UFljF88DO2g/YB0nKgOu1xUSwBXmyRX5l4BWp3Ao/sKsW7pH1FQ4N3Ku
1Y2z0kh5UfjdatxY16V6P9QUFXMGc/P/VIoSy9d2n8s67C2Zzr8+lUG4dzObtoOu
zv0XHgqJGQ2NNfDHss9IlX9Ns9FNEcvnoYf/TIjNNyBZrPHRx9JT0WMmHvINNm8X
Ef5AKd0EXlHaKk+aeLwzrL9WqDg2OfNUPA6MosywblfK1pNADii1fp3Mxf/PzDA4
xSyEyca5J0i2NMrwsyfqRXk76KLzrwyvkvFQq8mjY9kgud9JqlOFWQ0x5XcwxQT1
GlZiW9pbx8nM9G8wekpXKprAtbZOTzDl9ICSC2bhFvMERGb2UCSfGcrCCTNziumI
AXdnXDPp0S2liNYrIEpQH6QkLBALuTLlkIwK3zG4Rv6rlkeETgx8eC7RWqHEFlhn
fh47ss6aB9L8gbKnoPt9PuLQI56fWumaJIOh0tJi9aOB6RgMK7Hm1R190J54v/L5
GuQxwfQyZ/cJK+ynYeuF6TyPKyj3qCFx1iigIy0Hy1aWKJH8810FtyPpINZnUwo5
2FiXAZO7zNtY1RokUmiq6MOtPdJ4zQF+MGnLf0SfTvX2VqZ2Ng6xDjba46KbpJbj
SgSD35gxeJNxTq3NKYo4LayPZruAb+tNzUzo3mrR9JAvUhMDAso=
=rMy/
-----END PGP SIGNATURE-----

--nextPart7420583.JVnc33UoxL--