Hi Andy,
Thank you for the suggestion of in-config context overrides - I had
not realised that was possible (with the newer style of defining
Fuseki services) - that's really useful.
We'll re-rest the aforementioned 2b & 3b cases.
Regards,
Vilnis
On Fri, 8 Apr 2022 at 11:51, Andy Seaborne wrote
HI,
I just want to see how cardinality estimation can be done
programmatically. whatever query or dataset it may be, but I want to see it
practically.
On Tue, Apr 12, 2022 at 4:33 PM rve...@dotnetrdf.org
wrote:
> Hi
>
> Could you provide more detail about what you are after? The amount of
Hi
Could you provide more detail about what you are after? The amount of triples
that are scanned for a given SPARQL query can vary widely both based on the
query and how that query gets optimised (which can be data dependent)
I don’t think there is anything specifically exposed in the Jena AP
Hi,
I would like to ask about any specific class or method in Jana which
can return a value showing the estimated number of triples for a SPARQL
query?
Regards
--
*Hashim Khan*
I would start by noting that:
1. Our node IDs are not hash bashed. They are 64 bit identifiers which
either represent an inlined value
(https://jena.apache.org/documentation/tdb/architecture.html#inline-values) or
an offset to the actual RDF term in the node table file.
2. We need to do
Hello
While reading the documentation for the architecture of TDB store, we came
across the usage of B-Trees in node tables. As far as we understand, the
architecture uses B-Trees over the MD5 hashes of a node to map Node to
NodeId.
We wanted to ask, why is a B-Tree used in place of a HashMap her
