This rule is used to deal with this kind of pattern of cypher:
match (A)-[r1]->(B)
match (B)-[r2]->(C)
The two match pattern have the same B, default logic will produce a join, this rule change join to expand(for each B, find it's C).
This optimization rule is a temporary rule to handle LDBC queries, but without careful thought.
This rule need a new physical plan PhysicalExpandFromNode but it has similar logic with PhysicalExpand, and I don't want to translate PhysicalExpandFromNode to execution plan, maybe there's a better way to do it.
I used to think join was always an inefficient operator, but now I don't think so...
What changes were proposed in this pull request?
as title
Why are the changes needed?
This rule is used to deal with this kind of pattern of cypher:
The two match pattern have the same B, default logic will produce a
join, this rule changejointoexpand(for each B, find it's C).This optimization rule is a temporary rule to handle LDBC queries, but without careful thought.
This rule need a new physical plan
PhysicalExpandFromNodebut it has similar logic withPhysicalExpand, and I don't want to translatePhysicalExpandFromNodeto execution plan, maybe there's a better way to do it.I used to think join was always an inefficient operator, but now I don't think so...
Does this PR introduce any user-facing change?
No