[
https://issues.apache.org/jira/browse/OAK-1902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14041203#comment-14041203
]
Thomas Mueller commented on OAK-1902:
-------------------------------------
(I just found out that the patch is not correct, I'm working on it).
The property "entryCount" is set for the "nodetype" index to Long.MAX_VALUE in
/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/nodetype/write/InitialContent.java
The property "keyCount" is currently not used, but I'd like to introduce it, so
the number of keys of an index (in addition to the number of entries, which is
used for "is not null") can be set.
> NodeTypeIndex is not conversative enough about its cost
> -------------------------------------------------------
>
> Key: OAK-1902
> URL: https://issues.apache.org/jira/browse/OAK-1902
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
> Affects Versions: 1.0, 1.0.1
> Reporter: Justin Edelson
> Assignee: Thomas Mueller
> Fix For: 1.0.2
>
> Attachments: OAK-1902-b.patch, OAK-1902.patch
>
>
> NodeTypeIndexProvider derives its cost from PropertyIndexLookup.
> PropertyIndexLookup has a hardcoded maximum cost (which actually isn't a
> maximum cost, but is more the maximum number of nodes which will be read
> during cost calcuation).
> IMHO, these maximum costs should not be the same. In my experience with
> JCR-based applications, the number of matches for a particular node type is
> far greater than the number of matches for a regular property value.
> As a result, I would suggest that if the maximum cost is reached, a greater
> penalty should be applied to a node type index than a regular property index.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
