> Am 15.04.2015 um 22:47 schrieb Clark Richey <[email protected]>: > > It’s actually supposed to be a String index.See node value below > > > Node[425]{uniqueID:"Place:a1447d21-1fb2-426f-bba0-e91ddb98ee7b",_type:"Place",confidenceScore:1,dateModified:1428639760183,source:"Ohio > Secretary of State",state:"OH",street1:"P.O. Box 494",city:"West > Union",zip:"45693",lat:38.7945166,lon:-83.5451934,formattedAddress:"West > Union, OH 45693, USA",_geocoded:"true"} > > There are some values that are ’true’ and ‘false’ (as Strings) but there are > other values as well. How does neo determine what type of index to create?
It creates the string index, but afaik it gets information from the index how selective it is, e.g. if it rather stores 4 different values or 4M. > > Results forcing the index are below with changing count to returning nodes > shows the index being used. > -> still a lot of rows which would explain that it chose the label-scan > > neo4j-sh (?)$ explain match (p:Place) using index p:Place(_geocoded) where > p._geocoded = "true" return p;; > +--------------------------------------------+ > | No data returned, and nothing was changed. | > +--------------------------------------------+ > 65 ms > > Compiler CYPHER 2.2 > > Planner COST > > NodeIndexSeek > > +---------------+---------------+-------------+-------------------+ > | Operator | EstimatedRows | Identifiers | Other | > +---------------+---------------+-------------+-------------------+ > | NodeIndexSeek | 2535411 | p | :Place(_geocoded) | > +---------------+---------------+-------------+—————————+ > > > > However, if I do a count it still doesn’t use the index: -> what do you mean? It clearly says NodeIndexSeek ? > > neo4j-sh (?)$ explain match (p:Place) using index p:Place(_geocoded) where > p._geocoded = "true" return count(p); > +--------------------------------------------+ > | No data returned, and nothing was changed. | > +--------------------------------------------+ > 1 ms > > Compiler CYPHER 2.2 > > Planner COST > > EagerAggregation > | > +NodeIndexSeek > > +------------------+---------------+-------------+-------------------+ > | Operator | EstimatedRows | Identifiers | Other | > +------------------+---------------+-------------+-------------------+ > | EagerAggregation | 1592 | count(p) | | > | NodeIndexSeek | 2535411 | p | :Place(_geocoded) | > +------------------+---------------+-------------+-------------------+ > > Clark Richey > [email protected] <mailto:[email protected]> > > > >> On Apr 15, 2015, at 4:35 PM, Michael Hunger >> <[email protected] <mailto:[email protected]>> >> wrote: >> >> Good question, perhaps it decided that the index selectivity was too low as >> it is a boolean index? >> >> You can force it and see how it changes: >> >>> explain >>> match (p:Place) >> using index p:Place(_geocoded) >>> where p._geocoded = "true" >>> return count(p); >> >> >>> Am 15.04.2015 um 22:33 schrieb Clark Richey <[email protected] >>> <mailto:[email protected]>>: >>> >>> Hello, >>> When I run EXPLAIN on this query I can see that the index isn’t being used. >>> See below. However, when I execute the schema command I can see that that >>> index is on-line. (ON :Place(_geocoded) ONLINE) >>> >>> Why isn’t the query performing a nodeIndexSeek? >>> >>> >>> >>> >>> neo4j-sh (?)$ explain match (p:Place)where p._geocoded = "true" return >>> count(p); >>> +--------------------------------------------+ >>> | No data returned, and nothing was changed. | >>> +--------------------------------------------+ >>> 10 ms >>> >>> Compiler CYPHER 2.2 >>> >>> Planner COST >>> >>> EagerAggregation >>> | >>> +Filter >>> | >>> +NodeByLabelScan >>> >>> +------------------+---------------+-------------+--------------------------------+ >>> | Operator | EstimatedRows | Identifiers | >>> Other | >>> +------------------+---------------+-------------+--------------------------------+ >>> | EagerAggregation | 1592 | count(p) | >>> | >>> | Filter | 2535411 | p | p._geocoded == { >>> AUTOSTRING0} | >>> | NodeByLabelScan | 7606234 | p | >>> :Place | >>> +------------------+---------------+-------------+--------------------------------+ >>> >>> >>> >>> --- >>> >>> >>> <fg-logo.png> >>> >>> >>> Clark D. Richey, Jr >>> CHIEF TECHNOLOGY OFFICER >>> 240.252.7507 >>> [email protected] <mailto:[email protected]> >>> WWW.FACTGEM.COM <http://www.factgem.com/> >>> Clark Richey >>> [email protected] <mailto:[email protected]> >>> >>> >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Neo4j" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to [email protected] >>> <mailto:[email protected]>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Neo4j" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] >> <mailto:[email protected]>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "Neo4j" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Neo4j" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
