Inconsistent counts in Virtuoso 7.1 for large graphs - dbpedia

Question

I have an instance of Virtuoso 7.1 running and DBpedia set up as clearly elucidated in this blog. Now I have a very basic requirement of finding some count values. However I am confused by the results of my query:
select count(?s)
where {?s ?p ?o .
FILTER(strstarts(str(?s),"http://dbpedia.org/resource")) }
With this query I'd like to see how many resources are present in DBpedia that have an URI that starts with "http://dbpedia.org/resource". Essentially my hope is to find resources of the kind <http://dbpedia.org/resource/Hillary_Clinton> or <http://dbpedia.org/resource/Bill_Clinton> and so on.
My confusion lies in the fact that Virtuoso returns different results each time.
Now I tried it on two different machines, a local machine and our server. In both cases I see wildly different results. By wildly I would just want you to sample the sizes. They are 1101000, 36314, 328014, 292014.
Also about the execution time out. I did try changing it to 5000 from the default 0 or to 8000. That did not exactly increase the results.
I know DBpedia provides statistics for their dump, but I'd like to do this right in Virtuoso. Why is this anomaly?
Furthermore I saw this discussion as well, where they refer to something that might be related. I would just want to know how to get the counts right for DBpedia in Virtuoso. If not Virtuoso is there any other graph store i.e. Jena, rdf4j, Fuseki, which would do this right?

Answer 1

First thing -- Virtuoso 7.1 is very old (shipped 2014-02-17). I'd strongly advise updating to a current build, 7.2.4 (version string 07.20.3217) or later, whether Commercial or Open Source.
Now -- the query you're running has to do a lot of work to produce your result. It has to check every ?s for your string, and then tot up the count. That's going to need a (relatively) very long time to run; exactly how long is dependent on the runtime environment and total database size, among other significant factors.
HTML headers (specifically, X-SQL-Message) will include notice of such query timeouts, as seen here —
$ curl -LI "http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=SELECT+COUNT%28%3Fs%29+%0D%0AWHERE%0D%0A++%7B++%3Fs++%3Fp++%3Fo++.+%0D%0A+++++FILTER%28strstarts%28str%28%3Fs%29%2C%22http%3A%2F%2Fdbpedia.org%2Fresource%22%29%29+%0D%0A++%7D+&format=text%2Fhtml&CXML_redir_for_subjs=121&CXML_redir_for_hrefs=&timeout=3000000&debug=on"
HTTP/1.1 200 OK
Date: Tue, 06 Sep 2016 16:39:44 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 128
Connection: keep-alive
Server: Virtuoso/07.20.3217 (Linux) i686-generic-linux-glibc212-64 VDB
X-SPARQL-default-graph: http://dbpedia.org
X-SQL-State: S1TAT
X-SQL-Message: RC...: Returning incomplete results, query interrupted by result timeout. Activity: 12.43M rnd 13.28M seq 0 same seg 8.023M same pg 3.369M same par 0 disk 0 spec disk 0B / 0 m
X-Exec-Milliseconds: 121040
X-Exec-DB-Activity: 12.43M rnd 13.28M seq 0 same seg 8.023M same pg 3.369M same par 0 disk 0 spec disk 0B / 0 messages 0 fork
Expires: Tue, 13 Sep 2016 16:39:44 GMT
Cache-Control: max-age=604800
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: HEAD, GET, POST, OPTIONS
Access-Control-Allow-Headers: DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Accept-Encoding
Accept-Ranges: bytes
On your own instance, you can set larger or even infinite timeouts (e.g., MaxQueryExecutionTime) to ensure that you always get the most complete result available.