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
-
Activity
Transition | Time In Source Status | Execution Times |
---|
|
2m 37s | 1 |
|
13d 23h 25m | 1 |
|
4h 41m | 1 |
|
4h 15m | 1 |
|
22h 12m | 2 |
|
3d 15h 29m | 1 |
|
6m 33s | 1 |