← Back to team overview

maria-developers team mailing list archive

Re: ha_innobase::info_low() n_rows hack


Hi, Aleksey!

On Sep 11, Aleksey Midenkov wrote:
> In ha_innobase::info_low() there is following dirty hack:
> 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():
> every opened empty table will be non-empty!

Is that a problem?

> I don't know what is the problem with join optimizer,

if it notices an empty table it can return an empty result set right

> having storage engine to handle it seems not the right thing to do.

Yes, storage engine's job in this case is to return an approximate (or
exact) number of rows in a table. The API is documented in the

    The number of records in the table.
      0    - means the table has exactly 0 rows
    other  - if (table_flags() & HA_STATS_RECORDS_IS_EXACT)
               the value is the exact number of records in the table
               it is an estimate

So, InnoDB returns "1 row" as an estimate for a "seemingly empty" table.
Nothing's wrong with that.

> 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().

Yes, relying on HA_STATUS_TIME is a hack. A safer solution would be to
return "1 row" for an "seemingly empty" table, unless it was proven to
be empty, under a lock.

Chief Architect MariaDB
and security@xxxxxxxxxxx

Follow ups