Thank you, Can you explain why " The query engine was modified to try to only use one index if it can."?
I also noticed that even if I query on A and B, and ORDER BY B - it seemed to perform the query on B only, at least in a separate stage. Why is that? -Roi -----Original Message----- From: Jason Huynh [mailto:jhu...@pivotal.io] Sent: Wednesday, August 30, 2017 10:15 PM To: dev@geode.apache.org Subject: Re: Indxes and hints You will probably have to step through debugger for this one.. it really depends on the query. For this query, I expect the query engine to pick one index and run the rest of the criteria on the results of the first index used. My guess is you have created a CompactRangeIndex, and if so, you can see in CompactRangeIndex.java around line 811: if (ok && runtimeItr != null && iterOps != null) { ok = QueryUtils.applyCondition(iterOps, context); } This is where it would apply the older conditions (B and C or A and C depending on which index was selected) The query engine was modified to try to only use one index if it can. The load from disk (again assuming CompactRangeIndex) is probably occurring in MemoryIndexStore.getTargetObject. On Wed, Aug 30, 2017 at 9:21 AM Roi Apelker <roi.apel...@amdocs.com> wrote: > One more question: > > As I am trying to create a situation where the disk is accessed as > least as possible (with a select distinct from X where a=1 and b>10 > and c=true; In which a and b are indexes and c is not, and c is in the > value which is evicted to disk) > > Did I get it right - that if I use a hint on a, or a hint on b, or a > hint on both, it will first do a select on the hinted, and ONLY THEN the > others? > > Can anyone refer me to the code (where the 2 phase search occurs)? > > Where is the value finally loaded from disk? > > Thank you > > Roi > -----Original Message----- > From: Roi Apelker > Sent: Tuesday, August 29, 2017 4:02 PM > To: dev@geode.apache.org > Subject: RE: Indxes and hints > > Thank you Jason :-) > > -----Original Message----- > From: Jason Huynh [mailto:jhu...@pivotal.io] > Sent: Monday, August 28, 2017 7:24 PM > To: dev@geode.apache.org > Subject: Re: Indxes and hints > > Hi Roi, > > Answers are below the questions... > > Question 1. Is it true to say, that the query as it is will load all > the data values from the file, since the field C is part of the value, > which is already persisted to file? > > Depending on if an index is used or not, if an index is used, the > values that are part of the results will need to be loaded to actually > return a result. If an index is not used, then the all the values > would need to be loaded to actually have something to evaluate the filter > criteria on. > > Question 2. If I add a hint on A and B, will it mean that there will > be a > "2 phase search", first the select on A and B, and then, only on the > results, on the field C? (this way, not all records will be loaded > from file, only those that suit the A and B condition) > > Depending on the query, it could use one, or more. If it's a query > with only AND clauses, it should just choose one and then evaluate the > other filters on the subset that is returned from the index. > > Question 3. Is it possible to define an index on a value field? (i.e. > not from the key) - will it work exactly like defining one form the > key or are three any limitations? (again, I am looking to overcome the > situation, where as it seems, the records are loaded unnecessarily > from disk) > > Yes, indexes can be defined on fields in the value. It will work the same. > > > If you are sure you are already using an index in the query and still > loading every value for every execution of that query, there may be > something weird going on... > > On Sun, Aug 27, 2017 at 2:55 AM Roi Apelker <roi.apel...@amdocs.com> > wrote: > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, > > you may review at https://www.amdocs.com/about/email-disclaimer < > https://www.amdocs.com/about/email-disclaimer> > This message and the information contained herein is proprietary and > confidential and subject to the Amdocs policy statement, > > you may review at https://www.amdocs.com/about/email-disclaimer < > https://www.amdocs.com/about/email-disclaimer> > This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
