Hi all!
Yesterday, I looked briefly at http://bugs.mysql.com/bug.php?id=33489
(Falcon queries misinterpret max_join_size). As written by Philip in the
report, max_join_size must be set to about 1000 times greater value than
the actual join_size being used, f. ex, when doing select * (no joins)
on a table with 10 rows, max_join_size (if set) must be set to 10 000.
This seems to be because of a magic number (at least magic to me :) ):
double StorageInterface::scan_time(void)
{
DBUG_ENTER("StorageInterface::scan_time");
DBUG_RETURN((double)stats.records * 1000); // <---- This one
}
If I understand correctly, this method is used by the optimizer to
predict the number of IOs needed to read a given table, in order to
select the most efficient access method. It is also used to check if we
will exceed the max_join_size.
Does anybody now the rationale behind choosing (number of records *
1000) ?
myisam, does the following:
virtual double scan_time()
{ return ulonglong2double(stats.data_file_length) / IO_SIZE + 2; }
For a table with 3 records, myisam will return 2.005 whereas falcon
returns 3000.
If we return a number that is too high, can this also lead the optimizer
to choose suboptimal solutions?
/Lars-Erik
| Thread |
|---|
| • StorageInterface::scan_time() | Lars-Erik Bjørk | 16 Jan |