[
https://issues.apache.org/jira/browse/OAK-9376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17298662#comment-17298662
]
Dawid Iwo Cokan commented on OAK-9376:
--------------------------------------
Hi
Actually I am in touch with Manfred and I suggested this improvement based on
our case, let me share more details about it.
We are implementing a system that supports managing a lot of documents. In
system we store around 100k documents and we perform number of searches. With
that amount of data we assume it can work only when we properly use index. So
any query that will not properly use index is assumed to be incorrect. Not it
happened that in some corner cases our indexes were unable to get the results -
there was a need for OAK to read nodes into memory and perform in memory
filtering.
For instance our index was incorrectly set for one of ordering conditions. When
we performed a search we simply wanted to read first 10 items by given order.
The query had one constraint that match index definition, so in query planner
the index was picked. Although at the end it had to read all nodes into memory
and order them. This is causing the search is very slow, so users don't wait
for it to end assuming it simply fails and retry that leads to overheating a
system. It would be much more convenient to be able to set a max nodes the
query iterator can read, similar like we have for traverse option
> Optionally reject queries with huge result sets
> -----------------------------------------------
>
> Key: OAK-9376
> URL: https://issues.apache.org/jira/browse/OAK-9376
> Project: Jackrabbit Oak
> Issue Type: Wish
> Components: query
> Reporter: Manfred Baedke
> Assignee: Manfred Baedke
> Priority: Minor
>
> In cases where processing a result of a query uses a lot of memory and/or
> time (e.g. where filtering or ordering of many nodes in memory is required),
> an option to set an upper limit to the number of processed nodes and fail the
> query if the limit is exceeded would be useful.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
