From: Tor Didriksen
Date: September 7 2010 10:58am
Subject: Re: bzr commit into mysql-next-mr-opt-team branch (tor.didriksen:3215)
 WL#1393
List-Archive: http://lists.mysql.com/commits/117698
Message-Id: <4C861ABF.4010808@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 2010-09-07 11:20, Evgeny Potemkin wrote:
>> +
>> +double get_merge_many_buffs_cost_fast(ha_rows num_buffers, ha_rows 
>> max_n_elems,
>> +                                      ha_rows last_n_elems, uint 
>> elem_size)
> It would be better to place this function near 
> get_merge_many_buffs_cost to
> gradually deprecate and remove the latter.
I agree, but we haven't sorted out library dependencies for unit tests yet
(see note at declaration point)
and the gunit test was very useful
  - the original version had overflow/underflow/NaN problems
  - the original version wasn't very fast, since it looped/incremented 
to get end values


> +  if (FALSE)
> +    fprintf(stdout, "total_cost %e num_buffers %llu max_n_elems 
> %llu\n\n",
> +            total_cost, num_buffers, max_n_elems);
Is it worth converting this into DBUG_PRINT with info level?

Maybe. It should definitely not be like this (if false, printf ....)


> +
> +const char *explain_filesort(THD *thd, JOIN *join, TABLE *table)
It's not worth bothering with. There is WL#5558 which addresses EXPLAIN 
issue.
It's expected to be implemented soon. Sorry, I noticed this too late.

That worklog only has a sketchy HLD.
Do you really think it's easy, and will be implemented in the near future?

There is also WL#1219 btw.

-- didrik