View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0007993||VALENTINA SERVER||Database||public||2017-06-28 14:55||2017-07-13 13:37|
|Reporter||Chris Zakrewsky||Assigned To||Ivan Smahin|
|Priority||high||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version||7.3.x|
|Summary||0007993: Slow query feature (badly needed)|
|Description||When prototyping a new database schema it is very difficult to find out where the most time is/will be actually spent before the cursor is returning the results.|
This is especially complicated issue when the API mode is intermixed with the SQL mode style programming. There is not a whole lot basis to perform SQL optimizing by hand without having some meaningful statistics at hand.
There are two main areas affected:
1. The latency (lapsed time between initiating the query on the client side and the moment the server side actually is starting execution of the query against the tables)
2. The bandwidth (lapsed time between server side actually starting execution of the query against tables and is ready for returning the results, for example in the cursor)
It would be very helpful to be able to separate statistics in such way that both areas could be gauged separately.
The latency stats should also lapse the time spent in opening/closing connections and similar chores.
The aim is to identify bottlenecks in client-server solutions, where the database is one part and the API another.
|Tags||No tags attached.|
|2017-06-28 14:55||Chris Zakrewsky||New Issue|
|2017-07-06 07:55||Ivan Smahin||Assigned To||=> Ivan Smahin|
|2017-07-06 07:55||Ivan Smahin||Status||new => assigned|
|2017-07-13 10:31||Chris Zakrewsky||Note Added: 0009798|
|2017-07-13 13:37||Ivan Smahin||Status||assigned => resolved|
|2017-07-13 13:37||Ivan Smahin||Fixed in Version||=> 7.3.x|
|2017-07-13 13:37||Ivan Smahin||Resolution||open => fixed|