[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi db schema change needed to store search folder queryStrings
From:       Milian Wolff <mail () milianw ! de>
Date:       2012-02-24 12:28:06
Message-ID: 1898843.xY1IGiPJgj () minime
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 24 February 2012 09:52:37 Will Stephenson wrote:
> On Thursday 23 Feb 2012 22:26:49 Shaheed Haque wrote:
> > Is the extra storage really a concern? I suppose the pimitemtable is
> > probably going to have most entries by far. That seems to have a
> > handful of columns which might be strings (and 9 in total). Even if I
> > had a million records, we are talking a handful of MB.
> > 
> > That seems perfectly reasonable...Or have I misunderstood?
> 
> Multiplying the number of rows by the number of QString columns and summing
> it across all tables gives me (2 imap accounts, about 2.5GB mail in total
> on the servers) an additional 1455755 bytes for the storage. Then I assume
> indexed columns count double, which gives another 872906 * 2 bytes as there
> are 2 indices on parttable.name (which contains a lot of repeated entries,
> perhaps it would make sense to normalize this out into its own table?).
> 
> That's 3201567 extra bytes in theory.  I'm not a database guy so don't know
> how that translates into real extra storage, memory footprint (indexes stay
> in memory, right?) and performance.  Can someone better informed comment?

VARBINARY has variable length, hence it will only use as much as it actually 
needs. The number you pass it is the maximum size.

Bye
-- 
Milian Wolff
mail@milianw.de
http://milianw.de
["signature.asc" (application/pgp-signature)]

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]