You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#35889990: Setting secondary_engine to OFF causes offload issues with executing queries from stored procedures Bug#35988564: CREATE TEMPORARY TABLE failure after Table_ref::restore_properties
The problem is that when reaching the function RapidOptimize(), the value of LEX::using_hypergraph_optimizer is not consistent with the value of the session variable use_old_optimizer. The problem is a missing setting of LEX::using_hypergraph_optimizer in the execution of a query. It was only synchronized with the hypergraph optimizer setting in preparation of a query, which is sufficient for regular statements which always perform both preparation and execution, but not for stored procedures that have separate preparation and execution. The solution is to add this setting. But this revealed another problem: sometimes execution is out of sync with the current preparation. An optimization with the hypergraph optimizer requires that the preparation is also performed with settings specific to the hypergraph optimizer. This may happen e.g if the value of the session variable use_secondary_engine is switched from "off" or "on" to "forced" either between a preparation and execution (for prepared statements) or between two executions (for prepared statements and stored procedure statements) The solution to this is to track the current preparation state versus the one desired (the optimizer switch setting). It is now checked that the value of using_hypergraph_optimizer matches the current optimizer switch setting just after opening tables and before optimizing such statements, in which case we call ask_to_reprepare(). During optimization we set using_hypergraph_optimizer according to the optimizer switch. The test rapid.pfs_secondary has an increased reprepare count because we now detect more often that an optimization requires a new preparation. In addition, a test case was added to cover the problem described in bug#35988564. Change-Id: Ibf158576ec4cd1edde655d41f7c8bf2813e208ee
0 commit comments