Details
-
Task
-
Status: Open (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
Description
In the optimizer we sometimes remove items from a query and then later, when query is finished, we add the items back in their original position to be able to do re-execution of the original query (but possible with new parameters).
Instead of removing top level items (that are always of type bool) that we may have to add back (not basic constants), we could wrap the original item with another item:
Item_removeable(original_item) of type bool
That would have 2 states: Active and true or false
When state is active, it would execute the corresponding action val(), val_bool() on the original item (like Item_ref() is doing)
- When state is 'true' then it would always return true
- When state is 'false' then it would always return false
This item would have the property:
- When created it would have state 'removed' and always return true.
- After query processing, during Item_removable->cleanup() it would change state to 'active'
- Item_removable->set_state would set the state to true or false.
Attachments
Issue Links
- relates to
-
MDEV-28621 group by optimization incorrectly removing subquery where subject buried in a function
-
- Closed
-
Activity
The benefit is mainly that it easier to restore things with Item_removable than change_item_tree().
We can also print at any time the original tree and the modified tree, which is impossible now.
We have in the past forgot to add things to the change item tree. I thought that having Item_removable()
could potentially make things a bit easier in some cases that what we have now.
So if we use this, we replace ITEM_X with Item_removable(ITEM_X).
What is the benefit of using Item_removable as opposed to just using Item_int? We could
If instead of removing GROUP BY we change it to have Item_removable, we will also have to fix the optimizer to add the logic that "GROUP BY Item_removable() means no grouping"