>
> But my main point is to present these results, to show that we have a very
> useful tool to pin-point these performance issues, and to start discussion in
> more detail (and I have plenty more of those).
Nice work.
>
> Another is my_hash_sort_simple(). This is not a regression, but Oprofile s
>Description:
InnoDB: Error: row_search_for_mysql() is called without
ha_innobase::external_lock()
>How-To-Repeat:
create table foo ( data int );
create temporary table tmp_foo (select * from foo limit 0);
insert into tmp_foo (data) values (1);
lock table
Kristian Nielsen writes:
Some additional info found from analysis so far:
> 39k mysql_select
This seems mostly caused by expensive JOIN constructor, as Wlad mentioned.
> 16k JOIN::choose_subquery_plan
This is caused by unnecessary C++ object construction (thanks,
Timour!). Moving
Coincidentally, I'm running the some performance comparisons of 5.2 vs 5.3
with a sampling profiler (it is not an oprofile, and is not perf, and I do
not think anyone but me will run it)
I'm running the simplest possible benchmark here - sysbench 0.5 using
prepared SELECT 1 statement, 64 users. Its
I have been analysing the performance difference between MariaDB 5.5.21 and
MySQL 5.5.21 using oltp.lua in sysbench 0.5. It turns out that MySQL has about
8% higher tps in this benchmark when running CPU bound. (See below for links to
blog posts that started this).
I took the base sysbench run and
5 matches
Mail list logo
