[
https://issues.apache.org/jira/browse/JENA-1988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17227995#comment-17227995
]
Martin Pekár commented on JENA-1988:
------------------------------------
We hope to decrease the time take to access nodes. We don't want to search the
entire index, but rather split the index into multiple indexes, one for each
type. In this way, we should be able to only search a smaller index given that
we know the type of the node we search for.
The cache you mention, is that the _ObjectFile_? I guess this should be split
also in order to decrease access time.
> Separating B+ tree into different Node representations.
> -------------------------------------------------------
>
> Key: JENA-1988
> URL: https://issues.apache.org/jira/browse/JENA-1988
> Project: Apache Jena
> Issue Type: Question
> Components: TDB
> Affects Versions: Jena 3.16.0
> Reporter: Martin Pekár
> Priority: Blocker
> Labels: features, newbie, performance, test
> Fix For: Jena 3.16.0
>
> Attachments: NodeTableNative.java
>
>
> In a project to optimize the indexing, I am trying to have 4 indexes, one for
> each Node type (variable, literal, URI and blank). To implement this, I added
> 4 copies of the _nodeHashToId_ Index instance in the _NodeTableNative_ class.
> Then, for every operation on the _nodeHashToId_, for example using
> _containsNode()_ in the NodeTableNative class, I first check the type of Node
> given as parameter and then check for existence in the appropriate
> _nodeHashToId_ copy.
> Now, for some reason I get a NullPointerException when running the tests.
> Many of these exceptions appear in the _BufferChannelFile_ class in the
> _size()_ method because the call to _file.channel()_ return null.
> My question is then, is _NodeTableNative___ even the right place to implement
> this optimization, and second, if it is the right place to implement, can you
> help me understand why this exception is thrown?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
