Hi Menashè,
> 1. In which cases the "applying index" phrase should I see in the query plan?
There is no simple answer to that question. The query optimizer tries
to select a query plan that is evaluated faster than others. The
following query may illustrate this:
for $p in db:open('db')//person
where $p/country = 'Italy'
and $p/sex = 'female'
return $p
There are at least three ways how this query could e.g. be rewritten:
db:text('db', 'Italy')/parent::country/
parent:person/person[sex = 'female']
db:text('db', 'female')/parent:sex/
parent::person[city = 'Catania']
(db:text('db', 'Italy')/parent::country,
db:text('db', 'female')/parent::sex)/parent::country
In most cases, only one index access will be created will be created
for queries of that pattern. The optimizer also checks the number of
index entries given for a particular keyword. In the given case, the
query would most probably rewritten to the first query plan.
If you have a query with just six conditions, there are more than 50
different ways how your final query plan could look like.
> 2. Only once a value which is mentioned in the query is found in the index, in
> case of "=" condition?
In most cases, exact queries are preferred, because they are usually
more selective than other queries.
> 3. Always, in case of "<" or "<" condition, assuming the specific
> text/attribute has been indexed?
Because none of our index structures is particularly suited for range
queries, such index-driven requests may be slower than sequential
scans. Maybe you remember my last mail: Have you already tried to
store latitudes and longitudes in a fixed-size string representation?
> 4. Everything I see as a reply to index:facets is indexed, right?
I'm not sure what you mean by that?
