lp:~sergefp/mysql-server/mysql-6.0-opt
mysql-6.0-opt, optimizer team tree
- Get this branch:
- bzr branch lp:~sergefp/mysql-server/mysql-6.0-opt
Branch merges
Related source package recipes
Branch information
- Location:
- <private server>
- Last mirrored:
- Next mirror:
- Disabled
Updating branch...
Launchpad is processing new changes to this branch which will be available in a few minutes. Reload to see the changes.
Recent revisions
- 2740. By Igor Babaev <email address hidden>
-
Fixed bug #45092.
When the descriptors of the data fields stored in a join buffer
are created first the descriptors of the the fields used in
building access keys are constructed. The construction is done
with a call of the function add_table_data_fields_ to_join_ cache.
One of the parameters of this function, namely field_set, specifies
for what fields the descriptors are to be constructed. This function
is called once again for the remaining fields.
As the function adds new elements to the array of the field
descriptors it has to save the number of the descriptors that
has been already built in order to be able continue adding them
later. The same is true for the array of pointers to the field
descriptors that is created for blob fields.
However the length of this array was not been saved. As a result,
when the remaining blob fields were processed the pointers to
their field descriptors overwrote the pointers to the descriptors
of the blob fields used to build the access keys. - 2737. By Igor Babaev <email address hidden>
-
Fixed bug #44250.
When the BKA algorithm is used for a join operation the records
from the employed join buffer are uploaded into the join records
buffers in order the pushdown condition to be checked. In a general
case the records are uploaded not in the same order as they have
been written into the join buffer. As a consequence when all
matches for the records in the join buffer have been found the
record buffers only incidentally may contain the fields of the last
record put into the join buffer. This breaks the proper flow of
the BKA algorithm in the cases when incremental join buffers are
employed. To fix this problem the values of the the fields of the
last record written into the buffer are restored in record buffer
just before the join buffer is reset for the next portion of records.
These fields were restored in the previous code, but erroneously
the restoration happened in the JOIN_CACHE::join_records method
during the invocation of the function join_matching_records.
The fact is the succeeded call of next_cache->join_records may
overwrite that last record fields. This may lead to wrong result
sets or even memory corruption if blob values are written into
the join buffer. The test case reported in the bug demonstrated
such a corruption.
The submitted fix moved the restoration of the fields of the last
record into the code of JOIN_CACHE::join_records. This restoration
is performed before the join buffer is reset for writing or reading.
A reset for reading is needed when an outer join operation is executed. - 2734. By Igor Babaev <email address hidden>
-
Fixed bug #44019.
This bug happened when incremental (linked) join buffers were
employed to join several tables.
If some fields stored in one of such incremental join buffers
are used to build keys to access tables that follow the next
joined table, then offsets of these fields are saved at the
very end of the records stored in the join buffer.
These offsets allow us to read only those record fields that
are needed for building key values.
Each field whose offset is saved gets its own unique number
that determines the position of the offset for the field in
the sequence of field offsets stored for a record.
In a general case the order of the offsets in the sequence
does not comply with the order of the corresponding fields.
This fact was ignored by the code of the function
JOIN_CACHE:: write_record_data.
Branch metadata
- Branch format:
- Branch format 6
- Repository format:
- Bazaar repository format 2a (needs bzr 1.16 or later)
