Skip to content
  • Evgeny Potemkin's avatar
    da32646e
    Bug#14640176 WRONG OUTPUT FOR QUERY ON DERIVED TABLE WITH ICP · da32646e
    Evgeny Potemkin authored
    In order to pick best access method for a derived table optimizer creates
    fake keys, one per each table joined to the derived one. Fields of derived
    table are marked appropriately. After picking best index fields weren't
    unmarked and that confused ICP code and led to pushing into storage engine a
    condition that couldn't be used as a part of ICP. In its turn this led to a
    wrong result.
    
    Now TABLE::use_index remove marking from all fields that aren't used in the
    index picked for the derived table.
    To ease tracking of such bugs and show more info on automatically created
    keys JSON EXPLAIN now prints array of used key parts and labels it as
    'used_key_parts'. The only exception is when several indexes are used for a
    single table (e.g. in index merge). In this case nothing is printed.
    da32646e
    Bug#14640176 WRONG OUTPUT FOR QUERY ON DERIVED TABLE WITH ICP
    Evgeny Potemkin authored
    In order to pick best access method for a derived table optimizer creates
    fake keys, one per each table joined to the derived one. Fields of derived
    table are marked appropriately. After picking best index fields weren't
    unmarked and that confused ICP code and led to pushing into storage engine a
    condition that couldn't be used as a part of ICP. In its turn this led to a
    wrong result.
    
    Now TABLE::use_index remove marking from all fields that aren't used in the
    index picked for the derived table.
    To ease tracking of such bugs and show more info on automatically created
    keys JSON EXPLAIN now prints array of used key parts and labels it as
    'used_key_parts'. The only exception is when several indexes are used for a
    single table (e.g. in index merge). In this case nothing is printed.
Loading