Hi,
It works without an index but it doesn't work with an index.
When I revert changes, it takes INDEX_THRESHOLD_SIZE default value(100). And if
the entry that matches the condition is not in that resultset it will not be
printed.
Without index:
gfsh>query --query="SELECT e.key, e.value from /e
Mario,
There is similar test/example added by you in QueryWithRangeIndexDUnitTest.
testQueryWithWildcardAndIndexOnAttributeFromHashMap()
When I run that test (on develop); I see the results as expected:
*
Command result for :
Result : true
Limit : 100
Rows: 1
Query
I think https://github.com/apache/geode/pull/7010 may have changed what that
property represented. I believe it was some arbitrary threshold to abort using
index look ups (if the intermediate results were small, it was deemed faster to
just iterate through and not do a lookup – at least from my
As an fyi, in the past we disabled applying limits at the index level for range
indexes.
I’m surprised in this case that we would add all the entries to the
intermediate results instead of applying the filter first and checking the
condition before adding to the intermediate results..
I would
Jakov,
I'm not sure about the coordinator / non-coordinator behavior you're
describing, but I see the other behavior. It doesn't seem quite right.
Here is a detailed explanation of what I see.
LocatorLoadSnapshot.getServerForConnection increments the LoadHolder's
connections which updates its
