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
