Ian,
It may not be being truncated. Some but not all of the sparql compilation
entries from trace_on() are truncated but it's only the debug output that
is being truncated, not the query itself. This has caused me confusion
before.
Not guaranteed to work but you might try an alternate construct
Hi Rose,
You could use the Virtuoso SQL Procedural Language to write a procedure for
query execution and recording of execution times etc as detailed at:
http://docs.openlinksw.com/virtuoso/sqlprocedures.html
Or if you use Java, C or other scripting language like PHP, perl etc these can
Thanks Hugh,
We don't have a problem with this but I'm a bit ignorant when it comes to
the sql implications of some sparql constructs and I wanted to get some
idea of the potential pitfalls.
It sounds like the construct I was intending is potentially problematic
right now but will be fine in the f
Hi Rose,
The unix "top" command can be use to monitor the memory used by Virtuoso in
total, the Virtuoso status() command can also be used to see how many of the
allocated buffers (as set in the iNI file) are being "used" at any given time.
In that document you refer to the memory taken is ba
Hi Maria,
Virtuoso 7 query profiling enables query memory usage and many other resources
to be monitored as detailed at:
http://docs.openlinksw.com/virtuoso/databaseadmsrv.html#readingqueryprofile
Best Regards
Hugh Williams
Professional Services
OpenLink Software, Inc. //
Hi
Note sure what clearing the kernel cache has to do with this behaviour, but I
do not see negative differences taking a sample query like counting triples:
SQL> explain('sparql select count(*) where {?s ?p ?o}');
REPORT
VARCHAR
_
