maria-developers team mailing list archive

[Aleksey Midenkov <midenok@xxxxxxxxx>]

In ha_innobase::info_low() there is following dirty hack:

/*
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 optimizer 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 && !(flag & HA_STATUS_TIME)) {
        n_rows++;
}


It is very old (from 5.0 or earlier) and bug-prone. Because in
ha_innobase::open():

info(HA_STATUS_NO_LOCK | HA_STATUS_VARIABLE | HA_STATUS_CONST);

every opened empty table will be non-empty! I don't know what is the problem
with join optimizer, but having storage engine to handle it seems not
the right thing to do. Moreover, relying on HA_STATUS_TIME in this is definitely
wrong. We can make join optimizer to ignore "0 rows case" for all
storage engines.
Is it big win from "1 row case" anyway? Or we can make new flag HA_JOIN_STAT
and use it in make_join_statistics().