[Kde-pim] Kmail2: Akonadi memory requirements

Ingo Klöcker kloecker at kde.org
Sat Sep 11 16:07:31 BST 2010


On Friday 10 September 2010, Martin Steigerwald wrote:
> Am Freitag 10 September 2010 schrieb Volker Krause:
> > On Thursday 09 September 2010 09:56:09 Stephan Mueller wrote:
> And what about:
> > Another issue is that it seems this database only grows and never
> > shrinks. I.e. when I delete an email (i.e. remove it from trash or
> > delete it without moving it to trash), the database does not get
> > smaller.
> 
> I was concerned about this with Nepomuk already. I excluded some
> scary directories like my kernel collection for my ThinkPad T42
> which had several kernel source trees and my complete ~/Mail, as I
> believed, Nepomuk will receive mails for indexing via Akonadi in the
> future - and since I wanted to see Nepomuk be able to finish a
> complete scan of my home directory at least *once*. Nepomuk indeed
> reduced the number of files in the index, but Virtuoso didn't shrink
> the database. With further indexing it even grew bigger. It had 2.2
> GiB as I removed the kernel tree directory and now it as 2,8 GiB. It
> didn't seem as that Virtuose reused old entries.

Just a small comment:
Nepomuk's file indexer strigi is totally unrelated to Akonadi and 
Virtuoso is totally unrelated to MySQL. I suggest asking questions about 
Nepomuk and Virtuoso on their mailing lists.

FWIW, I have disabled file indexing completely because even after 
excluding my svn checkouts the file indexer still killed the performance 
of my computer after every start for quite some time.


> Even with todays harddisk sizes I think saving storage requirements
> is important. Especially as SSD's aren't that big yet. With the 160
> GB harddisk I had before I bought the largest 2,5 inch PATA disk
> from Western Digital with 320 GiB I didn't activate desktop search
> due storage contraints.
> 
> So will there be an easy way to optimize databases and clean out
> stale entries?

I googled a bit. Apparently, MySQL (in contrast to PostgreSQL) doesn't 
need to be vacuumed. It seems MySQL should somehow take care of this 
automatically. (?) Again, I suggest asking this question on the 
appropriate mailing list if you want to get a definitive answer.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100911/1eff7323/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/


More information about the kde-pim mailing list