[Kde-pim] [Nepomuk] KMail/Akonadi searching

Sebastian TrĂ¼g trueg at kde.org
Thu Jan 19 14:07:55 GMT 2012


Hi Christian,

as most of the code is rather akonadi-specific I can only comment on
small parts. Please tell me if I can help with any additional
information or questions.

In NepomukSearch::hitsAdded you do this query:

select distinct ?r ?reqProp1 where {
   { ?r a ?v2 . FILTER(?r=<%1>) .
     { ?r aneo:akonadiItemId ?reqProp1 . }
   } .
   ?r nao:userVisible ?v1 . FILTER(?v1>0) .
} LIMIT 1"

why not write it as:
select distinct ?r ?reqProp1 where {
   %1 a ?v2 .
   %1 aneo:akonadiItemId ?reqProp1 .
} LIMIT 1

after all you already know the resource. Thus there is no need to check
the visibility or use a filter which might slow down the query (not sure
how good the query optimizer handles this case).

Cheers,
Sebastian


On 01/19/2012 01:43 AM, Christian Mollekopf wrote:
> Hey,
> 
> I spent today to improve the searching situation a bit, but couldn't fix all 
> problems yet. It's a more of a workaround than a real fix as you can see but at 
> least basic searching works this way. A better solution will need changes in 
> some more places and probably nepomuk-core available (As I don't really feel 
> like copying more stuff from the nepomuk repository). 
> 
> Additionally to nepomuksearchengine I also fixed nepomuksearch, although I 
> don't know if it is used at all (I also haven't tested this part).
> 
> I also added on commit to kdepim (cbd7a8777a4bfd89125be4cf58e276b51388adc5) 
> which quotes the search string, because otherwise a searchpattern consisting 
> of several words is not interpreted as one pattern but rather the AND-
> conjunction of each individual word.
> 
> Apart from the current solution being a rather ugly hack, there also exist two 
> other problems:
> 
> - The search collection is indexed and then searched which is probably not 
> what we want. If somebody can tell me how to determine the search collection 
> (by some attribute or so) I could exclude it from the feeder. Another option 
> would be to exclude it by adding a IndexPolicyAttribute to the search 
> collection.
> 
> - Each query gets somehow executed twice. I can't see the call twice on the 
> kmail side, but on the akonadi-server there are always two queries, no idea 
> why.
> 
> Apart from those issues and the feeder not having indexed all emails here it 
> works pretty well. The search itself seems pretty fast: ~1-3 seconds for a 
> query resulting in a small result set, which searches through fulltext/and 
> headers in ~80000 indexed emails. If the result set is large filling the table 
> seems to be much more of a bottleneck than the actual query.
> 
> If the attached fixes are applied to akonadi and we manage to exclude the 
> search collection, we'll have at least half-way decent searching in 4.8.
> 
> Cheers,
> Christian
> 
> 
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
_______________________________________________
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