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 engine.
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. Regards, Igor.
Just my $.02.
-Zardosht
On Mon, Jun 17, 2013 at 10:37 PM, Igor Babaev <igor@askmonty.org> 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 features) Roberto,
Why do you NEED the optimizer tracer?
Regards, Igor.
-- Roberto Spadim
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~maria-developers Post to : maria-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-developers More help : https://help.launchpad.net/ListHelp