database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-12-24 11:21:21 +03:00
Code Activity

Fix for BUG#11044 - "SELECT DISTINCT on indexed column returns inconsistent results"

Browse Source 
The problem was that when there was no MIN or MAX function, after finding the
group prefix based on the DISTINCT or GROUP BY attributes we did not search further
for a key in the group that satisfies the equi-join conditions on attributes that
follow the group attributes. Thus we ended up with the wrong rows, and subsequent
calls to select_cond->val_int() in evaluate_join_record() were filtering those
rows. Hence - the query result set was empty.

The problem occured both for GROUP BY queries without MIN/MAX and for queries
with DISTINCT (which were internally executed as GROUP BY queries).


mysql-test/r/group_min_max.result:
  Added test result for BUG#11044. Notice that the group by query is
  equivalent to the distinct query and both are executed via the same
  algorithm.
mysql-test/t/group_min_max.test:
  Added test for BUG#11044. Notice that the group by query is
  equivalent to the distinct query and both are executed via the
  same algorithm.
sql/opt_range.cc:
  * Use the extended prefix in QUICK_GROUP_MIN_MAX_SELECT::get_next()
    to find keys that satisfy equality conditions in the case when there is
    no MIN or MAX function.
  * Corrected some method comments.
  * Corrected debug printout of cost information.
This commit is contained in:
unknown
2005-06-14 12:52:44 +03:00
parent d0db70270c
commit d87c2dd6bf
3 changed files with 44 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
sql/opt_range.cc
View File

@@ -7612,8 +7612,8 @@ void cost_group_min_max(TABLE* table, KEY *index_info, uint used_key_parts,
*records= num_groups;
DBUG_PRINT("info",
("records=%u, keys/block=%u, keys/group=%u, records=%u, blocks=%u",
table_records, keys_per_block, keys_per_group, records,
("table rows=%u, keys/block=%u, keys/group=%u, result rows=%u, blocks=%u",
table_records, keys_per_block, keys_per_group, *records,
num_blocks));
DBUG_VOID_RETURN;
}
@@ -8120,6 +8120,15 @@ int QUICK_GROUP_MIN_MAX_SELECT::get_next()
DBUG_ASSERT((have_max && !have_min) ||
(have_max && have_min && (max_res == 0)));
}
/*
If this is a just a GROUP BY or DISTINCT without MIN or MAX and there
are equality predicates for the key parts after the group, find the
first sub-group with the extended prefix.
*/
if (!have_min && !have_max && key_infix_len > 0)
result= file->index_read(record, group_prefix, real_prefix_len,
HA_READ_KEY_EXACT);
result= have_min ? min_res : have_max ? max_res : result;
}
while (result == HA_ERR_KEY_NOT_FOUND && is_last_prefix != 0);
@@ -8146,9 +8155,8 @@ int QUICK_GROUP_MIN_MAX_SELECT::get_next()
QUICK_GROUP_MIN_MAX_SELECT::next_min()
DESCRIPTION
Load the prefix of the next group into group_prefix and find the minimal
key within this group such that the key satisfies the query conditions and
NULL semantics. The found key is loaded into this->record.
Find the minimal key within this group such that the key satisfies the query
conditions and NULL semantics. The found key is loaded into this->record.
IMPLEMENTATION
Depending on the values of min_max_ranges.elements, key_infix_len, and
@@ -8232,9 +8240,7 @@ int QUICK_GROUP_MIN_MAX_SELECT::next_min()
QUICK_GROUP_MIN_MAX_SELECT::next_max()
DESCRIPTION
If there was no previous next_min call to determine the next group prefix,
then load the next prefix into group_prefix, then lookup the maximal key of
the group, and store it into this->record.
Lookup the maximal key of the group, and store it into this->record.
RETURN
0 on success