lp:~sergefp/mysql-server/mysql-6.0-opt

Created by Sergey Petrunia on 2009-04-14 and last modified on 2009-06-02
This branch may be out of date, because Launchpad has not been able to access it since 2011-09-10.

mysql-6.0-opt, optimizer team tree

Get this branch:
bzr branch lp:~sergefp/mysql-server/mysql-6.0-opt

Branch merges

Related bugs

Related blueprints

Branch information

Owner:
Sergey Petrunia
Project:
MySQL Server
Status:
Development
Location:
<private server>
Last mirrored:
2011-09-10
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> on 2009-06-02

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.

2739. By Sergey Petrunia on 2009-04-17

Better comments

2738. By Sergey Petrunia on 2009-04-16

Merge mysql-6.0 -> mysql-6.0-opt

2737. By Igor Babaev <email address hidden> on 2009-04-16

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.

2736. By Sergey Petrunia on 2009-04-13

mysql-6.0-opt -> mysql-6.0

2735. By Igor Babaev <email address hidden> on 2009-04-11

Automerge

2734. By Igor Babaev <email address hidden> on 2009-04-04

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.

2733. By Igor Babaev <email address hidden> on 2009-04-02

Corrections after the fix for bug 42740.

2732. By Sergey Petrunia on 2009-03-26

Merge

2731. By Sergey Petrunia on 2009-03-26

Fix typo

Branch metadata

Branch format:
Branch format 6
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.

Subscribers