maria-developers team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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():
> 
> info(HA_STATUS_NO_LOCK | HA_STATUS_VARIABLE | HA_STATUS_CONST);
> 
> 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
away.

> 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
handler.h:

  /*
    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
             else
               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.

Regards,
Sergei
Chief Architect MariaDB
and security@xxxxxxxxxxx