[Nepomuk] Re: Presentation, queries and other stuff

Sebastian Trueg trueg at kde.org
Mon Mar 21 12:57:44 CET 2011


On 03/07/2011 10:48 PM, Ignacio Serantes wrote:
> 
> On Mon, Mar 7, 2011 at 12:33 PM, Ignacio Serantes <kde at aynoa.net
> <mailto:kde at aynoa.net>> wrote:
> 
> 
>         As a first hacky query optimization you might try to use
> 
>         ?r a ?y .
>         ?y nao:userVisible ?visiblity .
>         filter(regex(?visibility),'true')) .
> 
>         looks weird but should do wonders because almost all resources
>         are visible.
> 
> 
>     I'm not following you I'm in my job so I can't test this but are you
>     told me that your query is faster than this one:
> 
>     ?r a ?y . 
>     ?y nao:userVisible "true"^^<http://www.w3.org/2001/XMLSchema#boolean>
> 
>     Looks really weird :).
> 
> 
> Umm, probably I misunderstand you :(. I do this group of tests:
> 
> Test #01 [TestUsingFilter]:  23292 results in   5.98952699 seconds
> Test #02 [TestUsingFilter]:  23292 results in   6.63734818 seconds
> Test #03 [TestUsingFilter]:  23292 results in   5.96942902 seconds
> Test #04 [TestUsingFilter]:  23292 results in   6.54467010 seconds
> Test #05 [TestUsingFilter]:  23292 results in   6.11729908 seconds
> Test #06 [ TestUsingEqual]:  23292 results in   4.62860608 seconds
> Test #07 [ TestUsingEqual]:  23292 results in   4.75821495 seconds
> Test #08 [ TestUsingEqual]:  23292 results in   5.15577602 seconds
> Test #09 [ TestUsingEqual]:  23292 results in   5.10496998 seconds
> Test #10 [ TestUsingEqual]:  23292 results in   5.12364006 seconds
> 
> and Filter() is slow as expected, 2 seconds between the quickest using
> equal and the slowest using Filter(). Here are the test cases I used:
> 
> <SPARQL>
> Enabled = No
> Name = TestUsingFilter
> DisplayResultSets = No
> <QUERY>
> SELECT DISTINCT *
> WHERE {
>     ?r a ?y .
>     ?y nao:userVisible ?z .
>         FILTER(REGEX(?z, "true")) .
> }
> 
> <SPARQL>
> Enabled = No
> Name = TestUsingEqual
> DisplayResultSets = No
> <QUERY>
> SELECT DISTINCT *
> WHERE {
>     ?r a ?y .
>     ?y nao:userVisible "true"^^<http://www.w3.org/2001/XMLSchema#boolean> .
> }
> 
> Could you explain better because I'm misunderstand you.

I am not sure. In any case Nepomuk does use "? ... . ? nao:userVisible
1" now which is much faster.

>         The optimization I was talking about is inference on client
>         level. (As I
>         mentioned I am not doing much on the DB level yet.) It creates a
>         nao:userVisible value for each resource. Thus, one can test the
>         visibility directly on the resource. That combined with the
>         filter above
>         is a big performance improvement. Obviously it is hacky and a
>         view as
>         you mention seems a much better solution.
> 
> 
>     The view system could be a better solution but only several test
>     will demonstrate it.
> 
> 
>         Actually there is no dedicated index for nao:userVisible yet.
>         The DB is
>         totally generic. We are only beginning with the optimization.
>         Your input
>         is very very helpful.
> 
> 
>     And you don't need to create it because boolean indexes are a lost
>     of time and even could degrade db performance. You must check this
>     in Virtuoso documentation.
> 
> 
> Sorry, I think that I explain bad this. With b-tree indexes columns with
> low cardinality could not be beneficed by an index but index must be
> maintained by dbms but, with compound indexes or with bitmapped indexes,
> like Oracle ones, you obviously could obtain better performance with and
> index in many cases. So, with "check this" I am meaning that is
> necessary consult Virtuoso behavior with this kind of indexes.
> 
> Sorry when I sounds rude but when I write in English sometimes I have
> not much time to write and less to recheck :).
>  
> 
> -- 
> Cheers,
> Ignacio
> 
> 
> 
> 
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk


More information about the Nepomuk mailing list