On 01/19/2012 03:34 PM, Ignacio Serantes wrote: > On Thu, Jan 19, 2012 at 3:07 PM, Sebastian Trüg <[email protected]> wrote: >> 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 >> > > I think you forgot the AS clause if the ?r column with a value is required. > > SELECT DISTINCT %1 AS ?r ?reqProp1 > WHERE { > %1 a ?v2 . > %1 aneo:akonadiItemId ?reqProp1 . > } LIMIT 1 > > My apologies if I'm wrong :).
Oh, yeah, right. But since they already have the resource I doubt they rely on it being in the query result. Still it is a good hint. :) Cheers, Sebastian >> 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 >>> [email protected] >>> https://mail.kde.org/mailman/listinfo/nepomuk >> _______________________________________________ >> Nepomuk mailing list >> [email protected] >> https://mail.kde.org/mailman/listinfo/nepomuk > > > _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
