Mike comments

Results 16 comments of


                                            Mike

Difficulties with expressing anti-semi relationships accurately and with acceptable performance

Playing around with other query patterns, it seems like just including OPTIONAL MATCH clauses at all is resulting in most of the performance decay.

Difficulties with expressing anti-semi relationships accurately and with acceptable performance

Here is the first graph.profile I have generated for a query that includes 2 anti-semi joins. ``` MATCH (d3:date)-[]->(f:fact) WHERE ((d3.timestamp >= 1594767600.0 AND d3.timestamp (f) WHERE d1.drug_name IN ['drug...

Difficulties with expressing anti-semi relationships accurately and with acceptable performance

I can actually produce exactly that same execution plan when I reverse the direction of the edges from (d1:drugs)-[]->(f) to (d1:drugs)(f:fact) WHERE ((d3.timestamp >= 1594767600.0 AND d3.timestamp (d1:drugs)` to `(f:fact)->(d1:drugs)`...

Difficulties with expressing anti-semi relationships accurately and with acceptable performance

I also forgot to mention that I am using the latest docker image for RedisGraph pulled down right before I started running these tests.

Difficulties with expressing anti-semi relationships accurately and with acceptable performance

Unfortunately, this was just a contrived example, so we cannot assume that all of the anti-semi relationships will be to the same node type that can be combined together. Given...

Difficulties with expressing anti-semi relationships accurately and with acceptable performance

That would be awesome if batching can get the performance of OPTIONAL MATCH clauses to be comparable to performance of MATCH clauses. If so, this would solve my problems entirely.