Cypher would actually start at :FEATURE using an index-lookup on name. and go backwards to thing and then during the traversal filter the rels on the fly by their properties.
Best to try a query plan with "profile" in the neo4j-shell, or you can choose cypher 2.1.experimental as planner to see the difference. The new planner collects statistics about the DB that help it plan better queries. profile match ... profile cypher 2.1.experimental match ... > MATCH (thing:THING)-[rel:hasSource]->(source:SOURCE), > (thing)-[:hasFeature]->(feature:FEATURE) > WHERE feature.name <http://feature.name/> IN ['someFeature', 'someFeature2'] > AND rel:someData = "data" > RETURN thing > Am 27.01.2015 um 14:42 schrieb [email protected]: > > Michael, > > We wouldn't have millions per thing, BUT each thing could have 5-10 hasSource > edges to a different source. So if the first match returned 70k things, the > second match (with the edge property check) could have 350k - 700k hasSources > to filter through. > > The someData example could be a string, double, or bool (someData would all > be the same type, but it potentially could be any one of those). > > Hope it helps. For now, we are focusing on trying to take advantage of node > schema indexes where we can, but hope edge schema index are in the works (and > maybe a case-insensitive flag when creating a string index). > > Thanks again for your time, > Brandon > > > > > > On Monday, January 26, 2015 at 3:36:11 PM UTC-6, Michael Hunger wrote: > The second query should be fine, if you don't have millions of rels of > "hasSource" between thing and source. ? > > What is the someData property in your case? a boolean, numeric value, string > ? > > Good point about the case-insensitive option for schema indexes > > Cheers, Michael > >> Am 26.01.2015 um 15:04 schrieb [email protected] <javascript:>: >> >> Michael, >> >> We may start at Thing or Source (or some other node), but would like to >> refine by some data on hasSource in the WHERE clause (and take advantage of >> an index). An example query could be: >> >> MATCH (thing:THING)-[rel:hasSource]->(source:SOURCE), >> (thing)-[:hasFeature]->(feature:FEATURE) >> WHERE feature.name <http://feature.name/> IN ['someFeature', 'someFeature2'] >> AND rel:someData = "data" >> RETURN thing >> >> or it could be re-written as: >> >> MATCH (thing:THING)-[:hasFeature]->(feature:FEATURE) >> WHERE feature.name <http://feature.name/> IN ['someFeature', 'someFeature2'] >> MATCH (thing)-[rel:hasSource]->(source:SOURCE) >> WHERE rel:someData = "data" >> RETURN thing >> >> >> Hope it helps. >> >> Thanks, >> Brandon >> >> >> >> On Saturday, January 24, 2015 at 5:29:43 PM UTC-6, Michael Hunger wrote: >> Brandon, >> >> what kind of query use-case would you want to support? >> Would you still start at a Thing or Source and then only want to access as >> subset of the relationships? >> Or really lookup :hasSource relationships independent of Source or Thing? >> >> This would help us understand the scope of your question. >> >> Cheers, Michael >> >>> Am 24.01.2015 um 19:20 schrieb bra...@ <>wayblazer.com >>> <http://wayblazer.com/>: >>> >>> Hello, >>> >>> Are edge schema indexes in the works for a future version? The main reason >>> I ask is for modeling data. One use case example is a "thing" can have many >>> "sources" and we really only want unique "things" in the graph. >>> >>> (:THING)-[:hasSource]->(:SOURCE) >>> >>> In this scenario, the bulk of the data lives on the hasSource edge, as the >>> "thing" has multiple sources with slightly different data from each source. >>> The problem is currently you cannot index any of this data as it's an edge. >>> >>> The other option is to have something like this: >>> >>> (:THING)-[:hasSourceData]->(:THINGDATA)-[:hasSource]->(:SOURCE) >>> >>> Then we can index "thing data" properties, but it introduces an extra node >>> and relationship. >>> >>> Just seeing what future schema index options there are planned for Neo4j. >>> >>> Unrelated, I would love to be able to specify a "case insensitive" option >>> for a schema index. >>> >>> Thanks, >>> Brandon >>> >>> -- >>> 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 neo4j+un...@ <>googlegroups.com <http://googlegroups.com/>. >>> 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] <javascript:>. >> 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.
