ha_innodb.cc:

  Fix bug #12779 : never give a row count estimate of 0 to the MySQL query optimizer, as then left join optimizer may beleive it KNOWS that the table is empty; note that this fix may change query optimization of many other queries where one table is empty; note that the proper fix would be to make the query optimizer to know that the row count estimates it receives really are just estimates, it cannot assume they are certain
parent c6ee26ab
......@@ -4109,6 +4109,7 @@ ha_innobase::info(
dict_table_t* ib_table;
dict_index_t* index;
ha_rows rec_per_key;
ib_longlong n_rows;
ulong j;
ulong i;
......@@ -4151,7 +4152,30 @@ ha_innobase::info(
}
if (flag & HA_STATUS_VARIABLE) {
records = (ha_rows)ib_table->stat_n_rows;
n_rows = ib_table->stat_n_rows;
/* Because we do not protect stat_n_rows by any mutex in a
delete, it is theoretically possible that the value can be
smaller than zero! TODO: fix this race.
The MySQL optimizer seems to assume in a left join that n_rows
is an accurate estimate if it is zero. Of course, it is not,
since we do not have any locks on the rows yet at this phase.
Since SHOW TABLE STATUS seems to call this function with the
HA_STATUS_TIME flag set, while the left join optizer does not
set that flag, we add one to a zero value if the flag is not
set. That way SHOW TABLE STATUS will show the best estimate,
while the optimizer never sees the table empty. */
if (n_rows < 0) {
n_rows = 0;
}
if (n_rows == 0 && !(flag & HA_STATUS_TIME)) {
n_rows++;
}
records = (ha_rows)n_rows;
deleted = 0;
data_file_length = ((ulonglong)
ib_table->stat_clustered_index_size)
......
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