In this PR, I have implemented a plan cache for Cypher statements (currently caching the AST of the Cypher parse, but it can be extended to cache execution plans in the future). By parameterizing the numeric values in the query string through rule-based matching during the lexer phase, and then filling the parameters back into the operators during the planner phase. Additionally, this PR addresses some bugs related to parameterized queries.
However, the current plan cache has certain limitations. We do not parameterize queries or literals in the query if:
The query is a CALL statement.
The query contains limit/skip n.
The query contains range literals: ()->[e*..3]->(m).
The items in the return body: return RETURN a,-2,9.78,'im a string'.
The query involves match ... create: MATCH (c {name:$0}) CREATE (p:Person {name:$1, birthyear:$2})-[r:BORN_IN]->(c) RETURN p,r,c.
Part of the reason for these limitations is due to the syntax constraints of Cypher statements themselves, and part of it is due to existing bugs and implementation constraints in TuGraph-DB.
In this PR, I have implemented a plan cache for Cypher statements (currently caching the AST of the Cypher parse, but it can be extended to cache execution plans in the future). By parameterizing the numeric values in the query string through rule-based matching during the lexer phase, and then filling the parameters back into the operators during the planner phase. Additionally, this PR addresses some bugs related to parameterized queries.
However, the current plan cache has certain limitations. We do not parameterize queries or literals in the query if:
n
.Part of the reason for these limitations is due to the syntax constraints of Cypher statements themselves, and part of it is due to existing bugs and implementation constraints in TuGraph-DB.