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@mariadb.org