[Maria-developers] mysql 5.6, 5.7
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 Spadim
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
+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. 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
it's a nice feature not a must have feature trace what mariadb is doing in optimizer, some time (in bugs or performace problem) is nice to see what is going wrong, and why a must have feature, for me, is lock partition prune i have many myisam table with lock problem and partition lock prune can solve it, today i changed the some codes to use union, but i will change it to only use partitions when partition lock is enabled the memcache is a nice feature too since i can remove nosql servers (memcached) from processlist and use more memory in mariadb server maybe a benchmark (if possible) about handler socket and memcached could be nice, i think today we can only do this in mysql server, but it's a nice information, sometimes is easier to change programs to use handler protocol instead of using memcached protocol, but it must give near performace with time i can do this benchmark, but not now, i will mark it in my todo list
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
nice, but, debug trace put a file in system, could it be returned via sql and remove the file? (just an idea) 2013/6/18 Igor Babaev <igor@askmonty.org>
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
_______________________________________________ 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
-- Roberto Spadim SPAEmpresarial
hum, there's something that show the "cost" of each optimization in mariadb, like the mysql optimizer_trace? i'm thinking about the MDEV-350<https://mariadb.atlassian.net/browse/MDEV-350> about self tune coeficients, the first task is find all constants that are used in "cost" values
participants (3)
-
Igor Babaev -
Roberto Spadim -
Zardosht Kasheff