A rule was introduced by the 5.1 part of the fix for bug 27531 to
prefer filesort over indexed ORDER BY when accessing all of the rows of a
table (because it's faster). This new rule was not accounting for the
presence of a LIMIT clause.
Fixed the condition for this rule so it will prefer filesort over
indexed ORDER BY only if no LIMIT.
The change_to_use_tmp_fields function leaves the orig_table member of an
expression's tmp table field filled for the new Item_field being created.
Later orig_table is used by the Field::make_field function to provide some
info about original table and field name to a user. This is ok for a field
but for an expression it should be empty.
The change_to_use_tmp_fields function now resets orig_table member of
an expression's tmp table field to prevent providing a wrong info to a user.
The Field::make_field function now resets the table_name and the org_col_name
variables when the orig_table is set to 0.
The optimizer takes different execution paths during EXPLAIN than SELECT,
this fix relates only to EXPLAIN, hence no behavior changes.
The test of sort keys for ORDER BY was prohibited from considering keys
that were mentioned in IGNORE KEYS FOR ORDER BY. This led to two
inconsistencies: One was that IGNORE INDEX FOR GROUP BY and
IGNORE INDEX FOR ORDER BY gave apparently different EXPLAINs; the latter
erroneously claimed to do filesort. The second inconsistency
is that the test of sort keys is called twice, finding a sort key the first
time but not the second time, leading to the mentioned filesort.
Fixed by making the test of sort keys consider all enabled
keys on the table. This test rejects keys that are not covering, and for
covering keys the hint should be ignored anyway.
When storing the VIEW the CREATE VIEW command is reconstructed
from the parse tree. While constructing the command string
the index hints specified should also be printed.
Fixed by adding code to print the index hints when printing a
table in the FROM clause.
The optimizer sets index traversal in reverse order only if there are
used key parts that are not compared to a constant.
However using the primary key as an ORDER BY suffix rendered the check
incomplete : going in reverse order must still be used even if
all the parts of the secondary key are compared to a constant.
Fixed by relaxing the check and set reverse traversal even when all
the secondary index keyparts are compared to a const.
Also account for the case when all the primary keys are compared to a
constant.
The optimization that uses a unique index to remove GROUP BY did not
ensure that the index was actually used, thus violating the ORDER BY
that is implied by GROUP BY.
Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
a unique index over non-nullable field(s). In case GROUP BY ... ORDER BY
null is used, GROUP BY is simply removed.
Currently the Last_query_cost session status variable shows
only the cost of a single flat subselect. For complex queries
(with subselects or unions etc) Last_query_cost is not valid
as it was showing the cost for the last optimized subselect.
Fixed by reseting to zero Last_query_cost when the complete
cost of the query cannot be determined.
Last_query_cost will be non-zero only for single flat queries.
The optimization that uses a unique index to remove GROUP BY, did not
ensure that the index was actually used, thus violating the ORDER BY
that is impled by GROUP BY.
Fixed by replacing GROUP BY with ORDER BY if the GROUP BY clause contains
a unique index. In case GROUP BY ... ORDER BY null is used, GROUP BY is
simply removed.
HEAP tables can't index BIT fields. Due to this when grouping by such fields is
needed they are converted to a fields of the LONG type when temporary table
is being created. But a side effect of this is that a wrong type of BIT
fields is returned to a client.
Now the JOIN::prepare and the create_distinct_group functions are create
additional hidden copy of BIT fields to preserve original fields untouched.
New hidden fields are used for grouping instead.
The bug caused memory corruption for some queries with top OR level
in the WHERE condition if they contained equality predicates and
other sargable predicates in disjunctive parts of the condition.
The corruption happened because the upper bound of the memory
allocated for KEY_FIELD and SARGABLE_PARAM internal structures
containing info about potential lookup keys was calculated incorrectly
in some cases. In particular it was calculated incorrectly when the
WHERE condition was an OR formula with disjuncts being AND formulas
including equalities and other sargable predicates.
Faster thr_alarm()
Added 'Opened_files' status variable to track calls to my_open()
Don't give warnings when running mysql_install_db
Added option --source-install to mysql_install_db
I had to do the following renames() as used polymorphism didn't work with Forte compiler on 64 bit systems
index_read() -> index_read_map()
index_read_idx() -> index_read_idx_map()
index_read_last() -> index_read_last_map()
This patch adds cost estimation for the queries with ORDER BY / GROUP BY
and LIMIT.
If there was a ref/range access to the table whose rows were required
to be ordered in the result set the optimizer always employed this access
though a scan by a different index that was compatible with the required
order could be cheaper to produce the first L rows of the result set.
Now for such queries the optimizer makes a choice between the cheapest
ref/range accesses not compatible with the given order and index scans
compatible with it.
