Bug #118717 Setting the SQL_ATTR_QUERY_TIMEOUT statement attribute is very expensive
Submitted: 25 Jul 10:21 Modified: 25 Jul 12:20
Reporter: Pierre le Riche Email Updates:
Status: Analyzing Impact on me:
None 
Category:Connector / ODBC Severity:S2 (Serious)
Version:9.4 OS:Any
Assigned to: MySQL Verification Team CPU Architecture:Any
Tags: max_execution_time, SQLSetStmtAttr

[25 Jul 10:21] Pierre le Riche
Description:
When setting the SQL_ATTR_QUERY_TIMEOUT attribute on a statement handle the ODBC driver calls the set_query_timeout function, which executes a "set @@max_execution_time=..." query every time it is called. This causes an unnecessary server round-trip when the new value is the same as the value already set for the session.

Since the ODBC driver documentation states that the default timeout for a new statement should always be 0 (infinite), it is not unusual for a different timeout to be set on every new statement created. With the MySQL ODBC driver this is currently very expensive when working over high latency connections.

How to repeat:
1) Create a statement
2) Call SQLSetStmtAttrW(AStatementHandle1, SQL_ATTR_QUERY_TIMEOUT, 10, SQL_IS_UINTEGER)
3) Create a second statement
4) Call SQLSetStmtAttrW(AStatementHandle2, SQL_ATTR_QUERY_TIMEOUT, 10, SQL_IS_UINTEGER) on the second statement
5) Note that in both steps 2 and 4 the driver executes a "set @@max_execution_time=10000" query. It should only happen once.

Suggested fix:
The driver should cache the current value of the max_execution_time variable for the session and avoid executing a query if the requested value matches the current value.