<br><div class="gmail_quote">On Mon, Mar 7, 2011 at 12:33 PM, Ignacio Serantes <span dir="ltr">&lt;<a href="mailto:kde@aynoa.net" target="_blank">kde@aynoa.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div class="gmail_quote"><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br>
</div></div>As a first hacky query optimization you might try to use<br>
<br>
?r a ?y .<br>
?y nao:userVisible ?visiblity .<br>
filter(regex(?visibility),&#39;true&#39;)) .<br>
<br>
looks weird but should do wonders because almost all resources are visible.<br></blockquote><div><br></div></div></div><div><div>I&#39;m not following you I&#39;m in my job so I can&#39;t test this but are you told me that your query is faster than this one:</div>



<div><br></div><div>?r a ?y . </div><div>?y nao:userVisible &quot;true&quot;^^&lt;<a href="http://www.w3.org/2001/XMLSchema#boolean" target="_blank">http://www.w3.org/2001/XMLSchema#boolean</a>&gt;</div><div><br></div><div>


Looks really weird :).</div></div></div></blockquote><div><br></div><div>Umm, probably I misunderstand you :(. I do this group of tests:</div><div><br></div><div><div><font face="&#39;courier new&#39;, monospace">Test #01 [TestUsingFilter]:  23292 results in   5.98952699 seconds</font></div>


<div><font face="&#39;courier new&#39;, monospace">Test #02 [TestUsingFilter]:  23292 results in   6.63734818 seconds</font></div><div><font face="&#39;courier new&#39;, monospace">Test #03 [TestUsingFilter]:  23292 results in   5.96942902 seconds</font></div>


<div><font face="&#39;courier new&#39;, monospace">Test #04 [TestUsingFilter]:  23292 results in   6.54467010 seconds</font></div><div><font face="&#39;courier new&#39;, monospace">Test #05 [TestUsingFilter]:  23292 results in   6.11729908 seconds</font></div>


<div><font face="&#39;courier new&#39;, monospace">Test #06 [ TestUsingEqual]:  23292 results in   4.62860608 seconds</font></div><div><font face="&#39;courier new&#39;, monospace">Test #07 [ TestUsingEqual]:  23292 results in   4.75821495 seconds</font></div>


<div><font face="&#39;courier new&#39;, monospace">Test #08 [ TestUsingEqual]:  23292 results in   5.15577602 seconds</font></div><div><font face="&#39;courier new&#39;, monospace">Test #09 [ TestUsingEqual]:  23292 results in   5.10496998 seconds</font></div>


<div><font face="&#39;courier new&#39;, monospace">Test #10 [ TestUsingEqual]:  23292 results in   5.12364006 seconds</font></div></div><div><br></div><div>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:</div>


<div><br></div><div><div><font face="&#39;courier new&#39;, monospace">&lt;SPARQL&gt;</font></div><div><font face="&#39;courier new&#39;, monospace">Enabled = No</font></div>
<div><font face="&#39;courier new&#39;, monospace">Name = TestUsingFilter</font></div><div><font face="&#39;courier new&#39;, monospace">DisplayResultSets = No</font></div>
<div><font face="&#39;courier new&#39;, monospace">&lt;QUERY&gt;</font></div><div><font face="&#39;courier new&#39;, monospace">SELECT DISTINCT *</font></div><div><font face="&#39;courier new&#39;, monospace">WHERE {</font></div>


<div><font face="&#39;courier new&#39;, monospace">    ?r a ?y .</font></div><div><font face="&#39;courier new&#39;, monospace">    ?y nao:userVisible ?z .</font></div><div>
<font face="&#39;courier new&#39;, monospace">        FILTER(REGEX(?z, &quot;true&quot;)) .</font></div><div><font face="&#39;courier new&#39;, monospace">}</font></div><div>
<font face="&#39;courier new&#39;, monospace"><br></font></div><div><font face="&#39;courier new&#39;, monospace">&lt;SPARQL&gt;</font></div><div><font face="&#39;courier new&#39;, monospace">Enabled = No</font></div>
<div><font face="&#39;courier new&#39;, monospace">Name = TestUsingEqual</font></div><div><font face="&#39;courier new&#39;, monospace">DisplayResultSets = No</font></div>
<div><font face="&#39;courier new&#39;, monospace">&lt;QUERY&gt;</font></div><div><font face="&#39;courier new&#39;, monospace">SELECT DISTINCT *</font></div><div><font face="&#39;courier new&#39;, monospace">WHERE {</font></div>


<div><font face="&#39;courier new&#39;, monospace">    ?r a ?y .</font></div><div><font face="&#39;courier new&#39;, monospace">    ?y nao:userVisible &quot;true&quot;^^&lt;<a href="http://www.w3.org/2001/XMLSchema#boolean" target="_blank">http://www.w3.org/2001/XMLSchema#boolean</a>&gt; .</font></div>


<div><font face="&#39;courier new&#39;, monospace">}</font></div></div><div><font face="&#39;courier new&#39;, monospace"><br></font></div><div>Could you explain better because I&#39;m misunderstand you.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



The optimization I was talking about is inference on client level. (As I<br>
mentioned I am not doing much on the DB level yet.) It creates a<br>
nao:userVisible value for each resource. Thus, one can test the<br>
visibility directly on the resource. That combined with the filter above<br>
is a big performance improvement. Obviously it is hacky and a view as<br>
you mention seems a much better solution.<br></blockquote><div><br></div></div><div>The view system could be a better solution but only several test will demonstrate it.</div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<br>
Actually there is no dedicated index for nao:userVisible yet. The DB is<br>
totally generic. We are only beginning with the optimization. Your input<br>
is very very helpful.</blockquote><div><br></div></div><div>And you don&#39;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.</div>


</div></blockquote><div><br></div><div>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 &quot;check this&quot; I am meaning that is necessary consult Virtuoso behavior with this kind of indexes.</div>


<div><br></div><div>Sorry when I sounds rude but when I write in English sometimes I have not much time to write and less to recheck :).</div><div> </div></div><br>-- <br>Cheers,<div>Ignacio</div><div><br></div><br>