maria-developers team mailing list archive
Mailing list archive
Re: mysql 5.6, 5.7
On 06/17/2013 07:51 PM, Zardosht Kasheff wrote:
> +1 on the optimizer tracing. I have found it useful. We've had a
> couple of instances where we looked at where an InnoDB query plan and
> TokuDB query plan diverge for some query, and it showed us bugs in our
But as an engine developer you could look into the debug trace as well.
The debug trace contains much more info.
We noticed that with >4-way joins optimizer trace becomes absolutely
useless as one has to look through a huge amount of lines, while with
<4-way joins the optimizer related info can be easily extracted from the
debug trace. The most important: the optimizer trace does not actually
explain WHY the chosen alternative is REALLY better than rejected ones:
the calculation of the costs remains under the cover.
> Just my $.02.
> On Mon, Jun 17, 2013 at 10:37 PM, Igor Babaev <igor@xxxxxxxxxxxx> wrote:
>> On 06/17/2013 04:24 PM, Roberto Spadim wrote:
>>> hi guys, i was reading mysql 5.6 and 5.7 manual
>>> i know that mariadb is very different (a bit) than mysql internally
>>> there's a mysql merge issue or something like that i can see what will
>>> be merged and what not?
>>> i like the partition lock prune, memcache and optimizer tracer of mysql
>>> 5.6, but today i'm not using it in mariadb (not a problem, but it's nice
>> Why do you NEED the optimizer tracer?
>>> Roberto Spadim
>>> Mailing list: https://launchpad.net/~maria-developers
>>> Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~maria-developers
>>> More help : https://help.launchpad.net/ListHelp
>> Mailing list: https://launchpad.net/~maria-developers
>> Post to : maria-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~maria-developers
>> More help : https://help.launchpad.net/ListHelp