[
https://issues.apache.org/jira/browse/OAK-1263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13839987#comment-13839987
]
Thomas Mueller commented on OAK-1263:
-------------------------------------
> counted b-tree as index in the content?
Do you mean to extend the PropertyIndex to store the counts? That's possible,
but there are a few problems:
* The PropertyIndex doesn't support reading in sorted order yet, so this would
also need to be implemented.
* The counts would need to be updated which slows down index updates and is a
problem when using multiple cluster nodes (we already do have a problem with
multiple cluster nodes, but that would be in addition to that).
* An efficient counted b-tree would require a b-tree, and the PropertyIndex
isn't actually a b-tree yet but uses a (flat) list. Converting it to a b-tree
would also result in yet more problems if used in a cluster.
> the other option is to do this on the application layer - which is not
> better IMO.
Not better, but possibly easier, because a generic solution is relatively
complicated...
> optimize oak index to support 'fast ORDER BY' queries to support sorting &
> pagination for large set of children
> ---------------------------------------------------------------------------------------------------------------
>
> Key: OAK-1263
> URL: https://issues.apache.org/jira/browse/OAK-1263
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
> Affects Versions: 0.12
> Reporter: Stefan Egli
>
> We have a use case where we'd like to be able to use an index in a
> "pagination-like" fashion. That is, we'd like to be able to have an index on
> a subtree on a certain property, and then run a query which does ORDER BY
> that property combined with OFFSET. That way, essentially allowing pagination
> of child nodes of a particular parent based on 'sorted by a certain property'.
> AFAIU currently the oak index is not optimized to support ORDER BY queries in
> a fast manner. The index keeps 'the child nodes unsorted', ie to process an
> ORDER BY, the child nodes would have to be 'manually sorted' which can result
> in bad performance given a large number of child nodes.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
