<p dir="auto">I am not sure if the title is clear enough. The reason for this issue for me is the spatial plugin for neo4j (<a href="https://github.com/neo4j/spatial">https://github.com/neo4j/spatial</a>). If you want to use neo4j with the spatial plugin completly via cypher and the rest api over http, it is not possible to configure an autoindex which takes care of adding node with 'lat' and 'lon' properties to the correct index. Without adding the nodes to the correct index they will be not found when using cypher with a <code class="notranslate">withinDistance</code> query. So after each <code class="notranslate">CREATE</code> cypher query on would have to make an additional call to the REST API.<br>
See here for a complete example / list of actions: <a href="https://gist.github.com/thomasfr/8103037">https://gist.github.com/thomasfr/8103037</a><br>
There is also a related issue on the spatial plugin: <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="24947093" data-permission-text="Title is private" data-url="https://github.com/neo4j-contrib/spatial/issues/125" data-hovercard-type="issue" data-hovercard-url="/neo4j-contrib/spatial/issues/125/hovercard" href="https://github.com/neo4j-contrib/spatial/issues/125">neo4j-contrib/spatial#125</a></p>
<p dir="auto">Is it possible to add more than one auto indexing configuration, with the possibility to define the index type for different node "types", to the neo4.properties file? A node type could be identified via their labels or simply when the node has the configured properties in <code class="notranslate">node_keys_indexable</code>.</p>
<p dir="auto">cheers</p>
<p dir="auto">Using neo 2.0.1, the query:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="match (n:States)
where n.name =~ '.*rul.*'
return n.name order by n.name desc
limit 200"><pre class="notranslate"><code class="notranslate">match (n:States)
where n.name =~ '.*rul.*'
return n.name order by n.name desc
limit 200
</code></pre></div>
<p dir="auto">returns result after 14 secs. Number of n:States nodes is about 450 000, number of nodes fullfilling the condition is about 130 000 and count with the same condition returns in 1 sec. There is index on :States(name).</p>
<p dir="auto">Profiling returns</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="ColumnFilter(symKeys=[&quot;n&quot;, &quot;n.name&quot;], returnItemNames=[&quot;n.name&quot;], _rows=200, _db_hits=0)
Top(orderBy=[&quot;SortItem(Cached(n.name of type Any),false)&quot;], limit=&quot;Literal(200)&quot;, _rows=200, _db_hits=0)
Extract(symKeys=[&quot;n&quot;], exprKeys=[&quot;n.name&quot;], _rows=131072, _db_hits=131072)
Filter(pred=&quot;LiteralRegularExpression(Property(n,name(1)),Literal(.*rul.*))&quot;, _rows=131072, _db_hits=458752)
       NodeByLabel(label=&quot;States&quot;, identifier=&quot;n&quot;, _rows=458752, _db_hits=0)"><pre class="notranslate"><code class="notranslate">ColumnFilter(symKeys=["n", "n.name"], returnItemNames=["n.name"], _rows=200, _db_hits=0)
Top(orderBy=["SortItem(Cached(n.name of type Any),false)"], limit="Literal(200)", _rows=200, _db_hits=0)
Extract(symKeys=["n"], exprKeys=["n.name"], _rows=131072, _db_hits=131072)
Filter(pred="LiteralRegularExpression(Property(n,name(1)),Literal(.*rul.*))", _rows=131072, _db_hits=458752)
       NodeByLabel(label="States", identifier="n", _rows=458752, _db_hits=0)
</code></pre></div>
<p dir="auto">Now, this type of match is very common to all applications - table with filter and ordering, so performance is important.</p>
<p dir="auto">This query probably doesn't use the index (because of the condition) but it should because of the order by.<br>
When running this type of query in MSSQL, server works as follows:</p>
<p dir="auto">Using index scan in descending order goes over every value and evaluates the condition. When number of items fulfilling the condition reaches 200 the work is done and result is returned. In many cases this happens in very short time (enough of items fulfilling the condition is found at the end of indexed items)</p>
<p dir="auto">In  Neo4j with cypher, server probably sorts all items fulfilling the condition and then returns the 200 from the begining.</p>
<p dir="auto">Is there some plan to optimize this type of queries?</p>
<p dir="auto">Thanx and sorry, I'm new to Neo and GitHub :)</p>