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 { ?o }
and
SELE
Hi Hugh.
Hi Timo,
Is the performance difference the same following repeat execution of the
prepared statement with URI binding ?
Yes.
it would still worth seeing some pseudo code showing how the prepared statement
is being set and the parameters passed to it ?
The PreparedStatement is creat
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
Hi Timo,
Is the performance difference the same following repeat execution of the
prepared statement with URI binding ?
it would still worth seeing some pseudo code showing how the prepared statement
is being set and the parameters passed to it ?
Best Regards
Hugh Williams
Professional Service
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(??)`
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
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 We
