Yes, that's true. cross path meant from different segments of the path. Michael
Am 21.01.2014 um 18:37 schrieb Javad Karabi <[email protected]>: > ah... i think i know what you mean. > that is, that i am comparing me.birth_year, and other.birth_year, both of > which were part of the same path, so splitting it up like you did (via the > WITH me.birth_year) did the trick? > > On Tuesday, January 21, 2014 11:31:24 AM UTC-6, Javad Karabi wrote: > Michael, awesome, thank you. > > just to make sure I understand correctly, in this case, when you say 'cross > path comparison', > what are the 2 paths you are referring to? > > > On Tuesday, January 21, 2014 11:21:32 AM UTC-6, Michael Hunger wrote: > Right, cross path comparisons are not yet used to shortcut path-finding > > so if you rewrite your query to this, it will actually filter down the paths > eagerly > > MATCH (me:Member {id: 11700}) > WITH me, me.birth_year as birth_year > MATCH > (me)-[ra:preferred_store]->(s)<-[rb:preferred_store]-(other)-[rc:ordered]->()<-[rd:product]-(sv:StyleVariant) > WHERE abs(other.birth_year - birth_year ) < {age_difference_range} AND > sv.cached_available = 1 > .... > > > > Am 21.01.2014 um 18:19 schrieb Javad Karabi <[email protected]>: > >> Michael, I apologize, I will send you a copy of the query + profile too. >> In my actual query, I am using a parameter of the cypher query: >> WHERE other.birth_year > (me.birth_year - {age_difference_range}) >> AND other.birth_year < (me.birth_year + {age_difference_range}) >> >> here is the relevant profile portion: >> Filter >> pred="(((Property(other,birth_year(66)) > >> Subtract(Property(me,birth_year(66)),Literal(10)) AND >> Property(other,birth_year(66)) < >> Add(Property(me,birth_year(66)),Literal(10))) AND >> Property(sv,cached_available(71)) == Literal(1)) AND >> hasLabel(sv:StyleVariant(13)))", >> _rows=47, >> _db_hits=4860 >> >> >> >> On Tuesday, January 21, 2014 11:11:57 AM UTC-6, Michael Hunger wrote: >> The problem is cross-path expressions, which are not yet handled in that >> manner >> >> for simple expressions that only contain a single piece of the path (node, >> rel) and things that have been evaluated before (parameters, literals, >> previous computations) WILL be used to shortcut the path evaluation. >> >> but if you do: n1--n2--n3 >> >> and then WHERE n2.foo > n1.bar it will be only applied AFTER the path >> >> if you do: WHERE n1.foo > 10 it will be applied DURING the path traversal >> >> HTH >> >> Michael >> >> Am 21.01.2014 um 18:08 schrieb Javad Karabi <[email protected]>: >> >>> You will notice: >>> "WHERE (Property(NodeIdentifier(),cached_available(71)) == Literal(1)" in >>> the TraversalMatcher() portion, the very first function of the profile.. >>> >>> I believe that this is what is meant when the documentation says that the >>> WHERE clause is not done after, (therefore during) the matching process. >>> >>> However, you will also notice that immediately following that function, is >>> Filter(), which is then filtering based on the ">" and "<" predicates of >>> the query. >>> >>> obviously, the best case scenario would be if the ">" and "<" tests >>> occurred inside TraversalMatcher(), i think >>> >>> On Tuesday, January 21, 2014 11:06:06 AM UTC-6, Javad Karabi wrote: >>> Mark, I have emailed you the query and profile for both cases. >>> >>> On Tuesday, January 21, 2014 10:55:03 AM UTC-6, Javad Karabi wrote: >>> Mark, I would be happy to. Give me a moment and I will post them. >>> >>> Michael, >>> Kernel version >>> >>> neo4j-browser, version: 2.0.0 >>> >>> >>> On Tuesday, January 21, 2014 10:49:37 AM UTC-6, Michael Hunger wrote: >>> Java, what version are you using? >>> >>> 2.0 final? >>> >>> Michael >>> >>> Am 21.01.2014 um 17:29 schrieb Javad Karabi <[email protected]>: >>> >>>> from what I can tell, if there where clause is ">" or "<" (as it is in the >>>> actual query which i am using, not in this example query...) then the >>>> WHERE predicate _is in fact_ a filter, applied _after_ the match. It looks >>>> to me that "TraversalMatcher()" does not apply predicates which involve > >>>> or <, but instead delegates this to "Filter()" after the fact, which does >>>> not correlate with what is stated on the documentation. >>>> >>>> On Tuesday, January 21, 2014 10:25:41 AM UTC-6, Javad Karabi wrote: >>>> (c:Customer)-[:ordered]->(p:Product)-[:category]->(:Category) >>>> >>>> Now, say that there are 2: >>>> c-[:ordered]->(:Product { name: "pants", quantity: 10}) >>>> c-[:ordered]->(:Product { name: "shirt", quantity: 5}) >>>> >>>> Now, say that if I only want to cross the category relationship if the >>>> p.quantity > 6 >>>> >>>> In the most basic way, I would do: >>>> >>>> (c:Customer)-[:ordered]->(p:Product)-[:category]->(cat:Category) >>>> WHERE p.quantity > 6 >>>> >>>> However, I figured that maybe neo4j would (non-optimally) traverse the >>>> entire path _then_ filter where on top of the path. >>>> >>>> So what I did was: >>>> >>>> MATCH (c:Customer)-[:ordered]->(p:Product) >>>> WHERE p.quantity > 6 >>>> WITH p >>>> MATCH p-[:category]->(cat:Category) >>>> >>>> This, I figured, would then allow neo4j to cross out to all the product >>>> nodes, as I would need them anyway in order to filter out the ones which >>>> have a quantity of less than 6. >>>> >>>> >>>> Now... finally to my question. >>>> The following URL: >>>> http://docs.neo4j.org/chunked/stable/query-match.html >>>> states that: >>>> WHERE defines the MATCH patterns in more detail. The predicates are part >>>> of the pattern description, not a filter applied after the matching is >>>> done. >>>> >>>> So, my question is, if the predicates (specifically p.quantity > 6) are >>>> part of the pattern description, and _not_ applied _after_ matching >>>> (therefore applied before or during), then cutting the query with the >>>> WITHs would be a moot point >>>> >>>> So, I would think that >>>> >>>> (c:Customer)-[:ordered]->(p:Product)-[:category]->(cat:Category) >>>> WHERE p.quantity > 6 >>>> >>>> would be sufficient, , as neo4j _would not_ actually traverse to cat, >>>> since it would apply the filter during the match process. >>>> >>>> However, in practice, I notice that using WITH is actually faster. Is >>>> there any possible reason for this? >>>> It may be necessary for me to show my query exactly, I also have the >>>> profile data for the query, which I am currently analyzing >>>> >>>> -- >>>> 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/groups/opt_out. >>> >>> >>> -- >>> 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/groups/opt_out. >> >> >> -- >> 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/groups/opt_out. > > > -- > 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/groups/opt_out. -- 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/groups/opt_out.
