MySQL Lists are EOL. Please join:

List:Falcon Storage Engine« Previous MessageNext Message »
From:Lars-Erik Bjørk Date:January 16 2009 8:25am
View as plain text  
Hi all!

Yesterday, I looked briefly at
(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_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?


StorageInterface::scan_time()Lars-Erik Bjørk16 Jan