Hi Pantelis, Are you saying the query runs successfully against some other older Virtuoso SPARQL endpoint but it returning no results against this newer 3214 build you are using from Oct 2015 ? If so what is the version and build data of this earlier build.
You need to profile the query and see were the time is being take ie in
compilation or execution , by running it from isql with the “set profile on”
option run to generate a query profile as detailed at:
http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtTipsAndTricksAanalyzingSPARQLQuery
There are also some suggestion on how to optimise queries detailed at:
http://virtuoso.openlinksw.com/dataspace/doc/dav/wiki/Main/VirtQueryOptDiagnostic
I would suggest particularly trying the “Enable_Joins_Only = 1” option in the
“[Flags]” section of the INI which is the new default for the latest 3215
builds released this month, I would also recommend you update to ...
Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc. // http://www.openlinksw.com/
Weblog -- http://www.openlinksw.com/blogs/
LinkedIn -- http://www.linkedin.com/company/openlink-software/
Twitter -- http://twitter.com/OpenLink
Google+ -- http://plus.google.com/100570109519069333827/
Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers
> On 29 Dec 2015, at 09:08, Pantelis Natsiavas <natsia...@gmail.com> wrote:
>
> The [SPARQL] settings section of my virtuoso.ini file initially had a
> value for MaxQueryCostEstimationTime. I have just commented it out and
> now I don't get the error anymore.
>
> However, I actually get no response on my query. I use the web interface
> and when I click "Execute" button, I get no response. The web interface
> does not give me a sign of executing my query. I only get a timeout
> after half an hour.
>
> Could you suggest any way to improve performance by avoiding or changing
> the "OPTIONAL" clauses?
>
> Once more, thank you very much.
>
> Kind regards,
> Pantelis Natsiavas
>
>
> On 28/12/2015 05:56 μμ, Hugh Williams wrote:
>> Hi Pantelis,
>>
>> Do you have “MaxQueryCostEstimationTime” set in the “[SPARQL]” section of
>> the INI file, which is normally commented out by default ? As the
>> "MaxQueryCostEstimationTime” should never be set in the INI file in
>> production use as the Cost Optimizer estimates are generally not accurate
>> and this is more a development/debugging param. Thus the only one that
>> should be set to control query execution time is “MaxQueryExecutionTime".
>>
>> Best Regards
>> Hugh Williams
>> Professional Services
>> OpenLink Software, Inc. //http://www.openlinksw.com/
>> Weblog --http://www.openlinksw.com/blogs/
>> LinkedIn --http://www.linkedin.com/company/openlink-software/
>> Twitter --http://twitter.com/OpenLink
>> Google+ --http://plus.google.com/100570109519069333827/
>> Facebook --http://www.facebook.com/OpenLinkSoftware
>> Universal Data Access, Integration, and Management Technology Providers
>>
>>> On 28 Dec 2015, at 12:13, Pantelis Natsiavas<natsia...@gmail.com> wrote:
>>>
>>> Hi everybody.
>>>
>>> I use a Virtuoso instance installed on ubuntu (Virtuoso version:
>>> 07.20.3214, Build: Oct 14 2015), in order to execute sparql queries. My
>>> queries are quite complex and make heavy use of the "OPTIONAL" pattern.
>>> While I have used the same queries on another virtuoso endpoint (not
>>> controlled by me) I cannot seem to use them on mine. I keep getting the
>>> message
>>>
>>> "Virtuoso 42000 Error The estimated execution time 0 (sec) exceeds the
>>> limit of 18000 (sec)."
>>>
>>> As you see, I have changed the timeout parameters in the virtuoso.ini file
>>> and put an irrational value (18000 seconds!!!). Still, it seems that the
>>> engine would refuse to execute my query.
>>>
>>> My questions are:
>>> 1. Is the value "0" mentioned as execution time a special value or is it
>>> just a bug? Is it logical to assume that the virtuoso estimates that the
>>> query would require infinite time to execute?
>>> 2. Are there any other configurations that I could do in order to improve
>>> situation?
>>> 3. Is there anything that I should keep in mind when I use the "OPTIONAL"
>>> sparql query pattern? I mean, is there a documented (even informally) way
>>> of improving the performance of queries using OPTIONAL clauses?
>>>
>>> Kind regards,
>>> Pantelis Natsiavas
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Virtuoso-users mailing list
>>> Virtuoso-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------
_______________________________________________ Virtuoso-users mailing list Virtuoso-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtuoso-users
