Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.8
Description
MDEV-13498 fixed a bug that DELETE with CASCADE was very slow due to a Galera-related check even when Galera was not enabled.
After that fix, the operation is still slow when Galera is enabled.
When I notified seppo about MDEV-13498, on August 17 he mentioned that the purpose of this condition is to avoid evaluating a potentially expensive condition. Now it seems that evaluating this filtering condition may cost more than the cost of evaluating the supposedly-expensive condition.
I suggested the use of a lossy filter that would use a much simpler and faster data structure and algorithm than the std::find() on the std::deque, something like a hash table. This lossy filter would be allowed to fail safely, causing unnecessary evaluation of the supposedly-expensive condition.
Attachments
Issue Links
- is blocked by
-
MDEV-13498 DELETE with CASCADE constraints takes long time and then crashes the instance with Signal 6
- Closed
- relates to
-
MDEV-15611 Due to the failure of foreign key detection, Galera slave node killed himself.
- Closed