On 03/07/2011 10:48 PM, Ignacio Serantes wrote: > > On Mon, Mar 7, 2011 at 12:33 PM, Ignacio Serantes <[email protected] > <mailto:[email protected]>> 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 > [email protected] > https://mail.kde.org/mailman/listinfo/nepomuk _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
