Commit 4a32d2e1 authored by unknown's avatar unknown

join buffer cache usage/not usage is taken

into account to increase the cost of FULL SCAN


sql/sql_select.cc:
  more accurate FULL SCAN cost estimation:
  join buffer cache usage/not usage is taken
  into account to increase the cost
parent 447f3981
...@@ -2133,11 +2133,21 @@ find_best(JOIN *join,table_map rest_tables,uint idx,double record_count, ...@@ -2133,11 +2133,21 @@ find_best(JOIN *join,table_map rest_tables,uint idx,double record_count,
s->table->used_keys && best_key) && s->table->used_keys && best_key) &&
!(s->table->force_index && best_key)) !(s->table->force_index && best_key))
{ // Check full join { // Check full join
/* /* Estimate cost of reading table. */
Estimate cost of reading table. Note, that we don't read a table
on each iteration as in most cases join buffer is in use.
*/
tmp= (double) s->read_time; tmp= (double) s->read_time;
if (s->on_expr) // Can't use join cache
{
/* We have to read the whole table for each record */
tmp*= record_count;
}
else
{
/* We read the table as many times as join buffer becomes full. */
tmp*= (1.0 + floor((double) cache_record_length(join,idx) *
record_count /
(double) thd->variables.join_buff_size));
}
/* /*
In case of full scan we check every row in the table: In case of full scan we check every row in the table:
here we take into account rows read and skipped, as well as rows here we take into account rows read and skipped, as well as rows
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment