Query plans

[ricardo_lopes]

Hi! Im using Neo4j 4.3.1

I want to check if two consecutively executed queries used the same execution plan (literally the same like checking if a transaction is equal to another by id comparison).
How can i check if a plan is being re-used?

[dana_canzano]

@ricardo.lopes

provided you submit query again it should not be replanned with the following exceptions
a. for some reason you have disable the query plan cache dbms.query_cache_size
b. the underlying data for the query has changed significantly enough such that the planner determines it should be replanned.
to

2021-10-22 19:00:47.881+0000 INFO  id:6 - 387 ms: (planning: 386, waiting: 0) - 20080 B - 1 page hits, 0 page faults - bolt-session bolt    neo4j-cypher-shell/v4.3.6               client/127.0.0.1:38380  server/127.0.0.1:7687>  neo4j -  - MATCH ... .... .... .....

and the planning: 386 should occur on the 1st entry but the 2nd should report planning: 0

but why ? are you suspecting the 2nd run of the same query is running a different plan?

[Bennu]

Hi @dana.canzano !

Is there any particular configuration in order allow this log planning info?

I'm using Enterprise 4.2 and it doesn't show this info. Is there any way to get the start streaming info as well?

Thanks in advance,

Bennu

[ricardo_lopes]

@dana.canzano
I was trying to understand the query plan caching in Neo4j so i ran a quick test with query parameters (100 merges with the same query parameter). For most of them the planning was 0 after the first one, but in some cases planning returned 8 as you can see below.
Used query -> MERGE(:HOST{IP:$ip1})

query 803 spent 19 in planning and 813 spent 8 in planning. They are the same query.

[dana_canzano]

@ricardo.lopes

it could be because the data has changed significantly enough that the planner determined it needed to replan the query. When this happens your logs\debug.log will report a message similar to

2021-03-08 09:43:16.854+0000 INFO [o.n.c.i.ServerExecutionEngine] Discarded stale query from the query cache:  match n return n ... ... ...

[ricardo_lopes]

@dana.canzano
I see, I will verify after running tests. Thank you