More informative query time

[jmatak]

Query time consists of the total time needed to create a session in the client, execute the query and fetch the results via Bolt protocol. As a result, I would like to configure to see a more granular breakdown of query time, with more information about query processing and execution without taking the time needed to fetch it from the server.

[gitbuda]

Yes, at the moment mgconsole is just printing out the "wall_time" in the following format:

N rows in set (0.001 sec)

While the underlying client actually has the following info available:

• cost_estimate
• parsing_time
• planning_time
• query_execution_time

I think the mgconsole should be extended in two ways:

1. By default, the output should be N rows in set (round trip in 0.001 sec) (to make it clear what is the time about)
2. Add, e.g., --varbose-query flag where the other stuff would also be printed out

[gitbuda]

There is also another angle, from the client's perspective there are many viable times to present:

• round trip or time for the results being available
• time to make data consumable
• time to consume the data (in this case, printing them out)

[jmatak]

That seems like useful information! However, from the benchmarking perspective, there is currently no way to measure performance from client. Adding that in some way would help me as a developer to better understand queries.

[gitbuda]

That seems like useful information! However, from the benchmarking perspective, there is currently no way to measure performance from client. Adding that in some way would help me as a developer to better understand queries.

What exactly would be helpful to measure and print out?

[jmatak]

That seems like useful information! However, from the benchmarking perspective, there is currently no way to measure performance from client. Adding that in some way would help me as a developer to better understand queries.

What exactly would be helpful to measure and print out?

The pure query execution time, and planning time. The closest information to this is a PROFILE query that breaks that information by different execution cursors.

[gitbuda]

Done in #36