First of all is it possible to simplify further to remove the STR
manipulations. These are bound to give any SPARQL query optimizer a 'hard
time'. Perhaps something like this:
SELECT ?c
FROM NAMED <b>
{
GRAPH <b>
{
?c d ?e .
FILTER (?c = ?h) .
{
SELECT ?h
FROM NAMED <i>
WHERE{
GRAPH <i>
{
?j <k> ?h .
?j <l> ?m .
}
}
}
}
}
Secondly, can the FILTER be replaced with a BIND after the correlated
subquery as follows. I have found that I get better query optimization with
this approach
SELECT ?c
FROM NAMED <b>
{
GRAPH <b>
{
?c d ?e .
{
SELECT ?h
FROM NAMED <i>
WHERE{
GRAPH <i>
{
?j <k> ?h .
?j <l> ?m .
}
}
}
BIND(?h as ?c)
}
}
Of course I understand that it might not be possible in your case, so just
regard these as suggestions to try,
Peter
*Peter J. Lawrence*
*inova8*
*Providing answers for users' information questions*
*Mobile:* +1 330 631 3772 | *Phone:* +1 330 342 0582 |*Skype:*
PeterJLawrence
*Email:* peter.lawre...@inova8.com | *Web:* www.inova8.com
*LinkedIn: **http://www.linkedin.com/in/peterjohnlawrence
<http://www.linkedin.com/in/peterjohnlawrence>*
On Thu, Apr 21, 2016 at 2:42 AM, Pantelis Natsiavas <natsia...@gmail.com>
wrote:
> Hello everybody.
>
> I built a SPARQL query using a nested subquery and noticed a huge
> performance penalty. A simplified version of the query follows. Please note
> that in the simplified query presented here I have only replaced URIs in
> order to be more readable and left all the comparisons and conversions in
> place as they could matter to the overall query performance.
>
> SELECT ?a
> FROM NAMED <b>
> {
> GRAPH <b>
> {
> ?c d ?e .
> BIND(REPLACE(STR(?e), "f", "", "i") AS ?g)
> BIND(REPLACE(STR(?c), "f", "", "i") AS ?a)
> FILTER (?g = STR(?h)) .
> {
> *SELECT ?h*
> * FROM NAMED <i>*
> * WHERE{*
> * GRAPH <i>*
> * {*
> * ?j <k> ?h .*
> * ?j <l> ?m .*
> * FILTER (REGEX(STR(?m), "n", "i"))*
> * }*
> * }*
> }
> }
> }
>
> If I execute the above query as a nested query I get a response after 40
> seconds. If I execute the nested query first (shown using bold characters)
> and put the result in the filter of the outer query, I get the result in a
> matter of 3 seconds (total). Given the simplicity of my rationale, I would
> expect a similar logic and performance from virtuoso.
>
> Have you noticed such a performance penalty before? Am I missing
> something? Is there a more efficient way to build the above query? Could
> the above query's performance penalty be caused due to a combination of the
> usage of BIND, REPLACE, STR and nested queries in different graphs?
>
> Please note that I am using Virtuoso Version: 07.20.3214, Build: Oct 14
> 2015 (I built it from source files).
>
> Kind regards,
> Pantelis Natsiavas
>
>
> ------------------------------------------------------------------------------
> Find and fix application performance issues faster with Applications
> Manager
> Applications Manager provides deep performance insights into multiple
> tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial!
> https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
> _______________________________________________
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
