Hi Ivan.
Thanks for the explanation. My queries are quite simple and I have huge
performance differences. It looks index activation is very much
dependent if an value binding is given inline or via prepared statement
binding.
For example if I use the query
SELECT * WHERE { <test:res1> <test:pred> ?o }
and
SELECT * WHERE { `iri(??)` `iri(??)` ?o } with the related bindings,
does the PSOG index (or equivalent) get used in both cases?
Br,
Timo Westkämper
On 03/29/2011 08:03 AM, Ivan Mikhailov wrote:
Hello Timo,
When parameter values are placed right into the text of the query, the
compiler has a chance to gather statistics about amounts of the specific
combinations of P and O in indexes and chose the best plan specially for
these statistics. With `iri(??)` it can only make some "average" plan
that may or may not match the best possible for actual parameter values.
This effect is most visible for
GRAPH `iri(??)` {...}
instead of
GRAPH<URI1> {...}
or
FROM<URI1> {...}
especially if RDF Views or graph-level access control are configured,
but other parts of triples are not free from the effect as well.
This does not mean that the use of parameters is unconditionally bad.
1. If the query is quite selective even with ?variable instead of
`iri(??)` or<URI1> in some place then adding condition of form
`iri(??)` will not make it worse.
2. If the parameter is used in an index-unfriendly FILTER condition then
it does not differ from placing a constant there.
3. It may happen that `iri(??)` and<URI1> result in same execution
plan, no matter what is exact value of<URI1>. It may or may not be
guessed in advance, but it's a possible case anyway.
So there are cases when parameter passing cuts compilation costs without
any ill effects, there are opposite examples too. There's no universal
recommendation pro or contra, only hints.
Best Regards
Ivan Mikhailov
OpenLink Software
http://virtuoso.openlinksw.com
On Mon, 2011-03-28 at 17:09 +0300, Timo Westkämper wrote:
Hi.
The problem seems to be more general and not just related to predicates.
I have for example this query :
SELECT DISTINCT ?dimension WHERE { ?item ?_c3 ?_c4 , ?_c5 , ?dimension }
which I transform into the following query
sparql
SELECT DISTINCT ?dimension WHERE { ?item `iri(??)` `iri(??)` ,
`iri(??)` , ?dimension }
with URI bindings for the three parameters.
The execution time for this approach is ~ 3s.
When I create the query instead like this :
SELECT DISTINCT ?dimension WHERE { ?item<URI1> <URI2> ,<URI3> ,
?dimension }
I get an execution time of ~ 1s.
Does usage of prepared statements for SPARQL cause these issues or maybe
something else?
Br,
Timo Westkämper
On 03/28/2011 12:20 PM, Hugh Williams wrote:
Hi Timo,
Can you please provide more details on this issue possibly with some pseudo
code to demonstrate what is being done ? Are you getting the expected
performance benefits when using prepared statements to bind variables to
literal values but not when binding variables to predicates, for example ?
Best Regards
Hugh Williams
Professional Services
OpenLink Software
Web: http://www.openlinksw.com
Support: http://support.openlinksw.com
Forums: http://boards.openlinksw.com/support
Twitter: http://twitter.com/OpenLink
On 28 Mar 2011, at 08:40, Timo Westkämper wrote:
Hi.
I have noticed that when using SPARQL over JDBC as prepared statements I
get a huge performance penalty when binding variables acting as
predicates via prepared statements.
I'd like to bind all node constants via prepared statements. How can I
avoid the performance penalty?
Br,
Timo Westkämper
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users
